Mailman 3 May 2011 - Python-ideas

proposal: module-level __init__
by Daniel Holth 07 May '11

07 May '11

__all__ is very useful when doing import *, which is frowned upon. As an alternative, allow modules to contain a function called __init__ that defines that module's exported symbols by way of the global statement. By importing modules that are used, but not intended to be exported, inside the __init__ function, programmers avoid cases such as the unintentional 'somemodule.sys' (referring to a module by its non-canonical name) that makes it harder to refactor larger projects. Before: __all__ = ['a', 'b'] import sys def a(): pass def b(): pass def c(): pass After: def __init__(): global a, b import sys def a(): pass def b(): pass def c(): pass __init__()

2 1

AttributeError: __exit__
by Daniel Holth 07 May '11

07 May '11

I just learned about Python internals from The ZODB transaction module. In Python < 2.7, the module works as a transaction manager. More or less: manager = Foo() __exit__ = manager.__exit__ __enter__ = manager.__enter__ After Python 2.7, it doesn't work. import transaction with transaction: pass >>> AttributeError: __exit__ It should be obvious to even the most casual observer that the exception is because, after Python 2.7, the with: statement has its own opcode that bypasses transaction.__getattribute__('__exit__') -> transaction.__dict__['__exit__']. Instead, CPython calls special_lookup(), looks for __exit__ on the module type, not the instance, doesn't find it, and raises the AttributeError. Instead, import sys sys.__exit__ >>> AttributeError: 'module' object has no attribute '__exit__' The interpreter should at least explain the AttributeError in the same way as it does when the user triggers it directly.

2 2

thoughts on regular expression improvements
by Bill Janssen 07 May '11

07 May '11

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. If the first argument to re.compile could be a tuple or list, you could write y = re.compile(["...", x, "..."]) and the engine could see that "..." is a string, and that x is a RE, and could inspect x as necessary. 3. Edit distances. The RE engine TRE (http://laurikari.net/tre/about/) supports fuzzy matching of strings, using edit distances. One can write an expression like "(total){~2}" which would any string that's "total" with no more than two edit errors. You can also specify insertions, deletions, and substitution limits separately with "+", "-", and "#". That would be nice to have... Bill

2 4

Re: [Python-ideas] 1_000_000
by Laura Creighton 07 May '11

07 May '11

If you disallow variable names of the form _<some number> you will break a huge amount of my automatically generated code. Admittedly, it wouldn't be hard to change things so that the generated variables are now X<some number> instead, but that happens to be the way I have written it now. Laura

1 0

Re: [Python-ideas] 1_000_000
by Kirubakaran 06 May '11

06 May '11

Ah, thanks. Sorry, I don't know how I failed to see that. On Fri, May 6, 2011 at 2:30 PM, Andre Roberge <andre.roberge(a)gmail.com>wrote: > I believe that the original suggestion was meant to be more general than > the specific suggestions for powers of 10. For example, consider the > following hypothetical: > > for i in range(1, 1_111_111_111, 1024): > pass > > where the _ really helps in figuring out the size. > > André > > > On Fri, May 6, 2011 at 6:26 PM, Kirubakaran <kirubakaran(a)gmail.com> wrote: > >> (fixed typo) >> How about range(10**6) ? >> >> - Kirubakaran. >> >> >> On Fri, May 6, 2011 at 2:25 PM, Kirubakaran <kirubakaran(a)gmail.com>wrote: >> >>> How about range(10**60) ? >>> >>> - Kirubakaran. >>> >>> >>> On Fri, May 6, 2011 at 2:24 PM, Antoine Pitrou <solipsis(a)pitrou.net>wrote: >>> >>>> On Fri, 6 May 2011 23:06:18 +0200 >>>> "dag.odenhall(a)gmail.com" >>>> <dag.odenhall(a)gmail.com> wrote: >>>> > On 6 May 2011 19:51, Matt Chaput < >>>> matt-KKMwxO2wslj3fQ9qLvQP4Q(a)public.gmane.org> wrote: >>>> > > 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. >>>> > >>>> > Ruby too. >>>> > >>>> > You could also use e-notation[1]: 1e6, in your example. In many >>>> > situations it's even more readable because you don't need to "count >>>> > the zeros". This is already supported in Python. >>>> >>>> Yes, but it gives a float, not an integer: >>>> >>>> >>> for i in range(0, 1e6): pass >>>> ... >>>> Traceback (most recent call last): >>>> File "<stdin>", line 1, in <module> >>>> TypeError: 'float' object cannot be interpreted as an integer >>>> >>>> >>>> Regards >>>> >>>> Antoine. >>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas(a)python.org >>>> http://mail.python.org/mailman/listinfo/python-ideas >>>> >>> >>> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> http://mail.python.org/mailman/listinfo/python-ideas >> >> >

1 0

Re: [Python-ideas] [Python-Dev] What if replacing items in a dictionary returns the new dictionary?
by Roy Hyunjin Han 05 May '11

05 May '11

2011/5/5 Giuseppe Ottaviano <giuott(a)gmail.com>: >> 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())

1 0

Re: [Python-ideas] [Python-Dev] What if replacing items in a dictionary returns the new dictionary?
by Roy Hyunjin Han 05 May '11

05 May '11

>> 2011/4/29 Roy Hyunjin Han <starsareblueandfaraway(a)gmail.com>: >> 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(a)gmail.com>: > 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 > return wrapper > > > d = dict() > print using(d).update(dict(a=1)).update(dict(b=2)).unwrap() > # prints {'a': 1, 'b': 2} > l = list() > print using(l).append(1).append(2).unwrap() > # prints [1, 2] Cool! I never thought of that. That's a great snippet. I'll forward this to the python-ideas list. I don't think the python-dev people want this discussion to continue on their mailing list.

1 1