headers
Roy Hyunjin Han | 5 May 2011 16:37
Picon
Gravatar

Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?

>> 2011/4/29 Roy Hyunjin Han <starsareblueandfaraway@...>:
>> It would be convenient if replacing items in a dictionary returns the
>> new dictionary, in a manner analogous to str.replace().  What do you
>> think?
>>
>>    # Current behavior
>>    x = {'key1': 1}
>>    x.update(key1=3) == None
>>    x == {'key1': 3} # Original variable has changed
>>
>>    # Possible behavior
>>    x = {'key1': 1}
>>    x.replace(key1=3) == {'key1': 3}
>>    x == {'key1': 1} # Original variable is unchanged
>>
> 2011/5/5 Giuseppe Ottaviano <giuott@...>:
> In general nothing stops you to use a proxy object that returns itself
> after each method call, something like
>
> class using(object):
>    def __init__(self, obj):
>        self._wrappee = obj
>
>    def unwrap(self):
>        return self._wrappee
>
>    def __getattr__(self, attr):
>        def wrapper(*args, **kwargs):
>            getattr(self._wrappee, attr)(*args, **kwargs)
>            return self
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roy Hyunjin Han | 5 May 2011 16:42
Picon
Gravatar

Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?

>>    # Possible behavior
>>    x = {'key1': 1}
>>    x.replace(key1=3) == {'key1': 3}
>>    x == {'key1': 1} # Original variable is unchanged
>>
> 2011/5/5 Giuseppe Ottaviano <giuott@...>:
> class using(object):
>    def __init__(self, obj):
>        self._wrappee = obj
>
>    def unwrap(self):
>        return self._wrappee
>
>    def __getattr__(self, attr):
>        def wrapper(*args, **kwargs):
>            getattr(self._wrappee, attr)(*args, **kwargs)
>            return self
>        return wrapper

The only thing I would add is obj.copy(), to ensure that the original
dictionary is unchanged.

class using(object):
    def __init__(self, obj):
        self._wrappee = obj.copy()
Permalink | Reply | 0 comments |
headers
Roy Hyunjin Han | 5 May 2011 17:19
Picon
Gravatar

Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?

2011/5/5 Giuseppe Ottaviano <giuott@...>:
>> The only thing I would add is obj.copy(), to ensure that the original
>> dictionary is unchanged.
>>
>> class using(object):
>>    def __init__(self, obj):
>>        self._wrappee = obj.copy()
>
> My example was just a proof of concept, there are many other things
> that may need to be taken care of (for example, non-callable
> attributes).
> BTW, the copy should be done outside. If the object is copied, I'd say
> "using" is a poor choice of name for the proxy.

You're right, I would need to do more work to get it to mimic the
underlying object.  I think I will stick with Oleg's suggestion to
subclass dict for now; it's great for unit tests.  Thanks for the
idea, though.

class ReplaceableDict(dict):
   def replace(self, **kwargs):
       'Works for replacing string-based keys'
       return dict(self.items() + kwargs.items())
Permalink | Reply | 0 comments |
headers
Brendan Moloney | 5 May 2011 23:41
Favicon

Allow 'import star' with namespaces

Hello,

I posted this on python-dev, but was told that this is the more appropriate list.

Currently if I do:

$ import pkg

Then all of the public subpackages/submodules are not automatically pulled into the 'pkg' namespace. I
can do:

$ from pkg import *

To get all of the public subpackages/submodules, but that dumps them all into the current namespace. Why
not allow:

$ import pkg.*

This would allow easier interactive use (by eliminating the need to import individual
subpackages/submodules) while keeping the 'pkg' namespace around.

Thanks,
Brendan Moloney
Permalink | Reply | 20 comments |
headers
Benjamin Peterson | 6 May 2011 00:00
Favicon
Gravatar

Re: Allow 'import star' with namespaces

Brendan Moloney <moloney <at> ...> writes:
> This would allow easier interactive use (by eliminating the need to import
individual
> subpackages/submodules) while keeping the 'pkg' namespace around.

import * is generally frowned upon, so encouraging its use by extending it is
not a good idea.
Permalink | Reply | 19 comments |
headers
Brendan Moloney | 6 May 2011 00:24
Favicon

Re: Allow 'import star' with namespaces

Benjamin Peterson [benjamin@...] wrote:
> import * is generally frowned upon, so encouraging its use by extending it is
> not a good idea.

Well it is frowned upon precisely because it pollutes the current namespace. This change would eliminate
that issue.
Permalink | Reply | 18 comments |
headers
dag.odenhall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org | 6 May 2011 09:20
Picon
Gravatar

Re: Allow 'import star' with namespaces

On 6 May 2011 00:24, Brendan Moloney <moloney@...> wrote:
> Benjamin Peterson [benjamin@...] wrote:
>> import * is generally frowned upon, so encouraging its use by extending it is
>> not a good idea.
>
> Well it is frowned upon precisely because it pollutes the current namespace. This change would eliminate
that issue.

I like this idea, except it's inconsistent with from-import-star, the
latter which does *not* get you sub-packages or modules.
Permalink | Reply | 17 comments |
headers
Georg Brandl | 6 May 2011 09:44
Picon
Gravatar

Re: Allow 'import star' with namespaces

On 06.05.2011 09:20, dag.odenhall@... wrote:
> On 6 May 2011 00:24, Brendan Moloney <moloney@...> wrote:
>> Benjamin Peterson [benjamin@...] wrote:
>>> import * is generally frowned upon, so encouraging its use by extending it is
>>> not a good idea.
>>
>> Well it is frowned upon precisely because it pollutes the current namespace. This change would
eliminate that issue.
> 
> I like this idea, except it's inconsistent with from-import-star, the
> latter which does *not* get you sub-packages or modules.

And that's for a reason: it's not easy (I think it's even impossible, because
for example individual submodules can change __path__) to determine all
importable submodules of a package.

So ``import pkg.*`` would not have any behavior other than ``import pkg``.

Georg
Permalink | Reply | 16 comments |
headers
Matt Chaput | 6 May 2011 19:51
Picon
Gravatar

1_000_000

Not sure if this has been proposed before: A syntax change to allow 
underscores as thousands separators in literal numbers to improve 
readability, e.g.:

   for i in range(1, 1_000_000):
     pass

I believe D allows this and while it's a small thing it really is much 
more readable.

Worth a PEP?

Thanks,

Matt
Permalink | Reply | 42 comments |
headers
Bill Janssen | 6 May 2011 21:11
Favicon

thoughts on regular expression improvements

I've been doing a lot of RE hacking lately, and some possible
improvements suggest themselves.

1.  Multiple occurrences of a named group

Right now, you can compose RE's with

   x = re.compile("...")
   y = re.compile("..." + x.pattern + "...")

But if x contains named groups, you run into trouble if you have
something like

   z = re.compile("..." + x.pattern + "..." + x.pattern + "...")

which can easily happen if x could occur at various places in z.  The
issue is that a named group is only allowed once, which isn't a bad
error-prevention mechanism, but it would be nice if it could occur more
than once (in alternative subexpressions), perhaps enabled by a another
RE flag.

2.  Easier composition.

Writing

   y = re.compile("..." + x.pattern + "...")

seems a tad groty, to use a term from my childhood, and affords the RE
engine no purchase on the composition, which can be an issue if the
flags for x are different from the flags for y.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane