Mailman 3 May 2011 - Python-ideas

triple-quoted strings and indendation
by Matthias Lehmann 14 May '11

14 May '11

Hi all, two times in one day I read about the problems of triple-quoted strings and indendation (one time on stackoverflow, one time one this list). Python is well known for its readability and its use of idendation to this end. But with triple-quoted strings, nice indendation is not possible without the need to post-process the resulting string. Problem ======= Most often, the desired result of >>> some_string = """Hello ... World.""" is simply Hello World instead of Hello World. Idea ===== What about the idea, to use a string-flag to indicate, that the triple-quoted string is to be trimmed. Like: >>> some_string = t"""Hello ... World.""" This would blend in with the 'u' and 'r' flags that already exist. The triple-quoted string is trimmed to remove all whitespace up to the column where the first line of the string started OR all common whitespace of the subsequent lines, if the subsequent lines start on a column before the first line. The second rule makes it possible to also write: >>> some_string = t"""Hello ... World.""" Pros ===== The advantages above textwrap.dedent are: 1) textwrap.dedent only removes whitespace common to ALL lines, so to achieve the desired result, one has to add an additional newline >>> some_string = """ ... Hello ... World.""" >>> result = textwrap.dedent(some_string)[1:] 2) Also, it does not work, if one actually does want some common whitespace before all lines: >>> some_string = """ ... Hello ... Wold.""" >>> result = textwrap.dedent(some_string)[1:] gives again Hello World which is not, what I wanted. But >>> some_string = t""" Hello ... World.""" would give Hello World. 3) And finally to quote a post from earlier today "I know about textwrap.dedent, but having to use a Python function call to code a literal has always made me uncomfortable." Problems ========= Common indendation style for triple-quoted string (as far as I know) is >>> foo = """blubber ... bla""" (align to first quote-char) but with this auto-trimming, it would look better to use >>> foo = t"""blubber ... bar""" (align to first char after triple quotes) The other stlye would still work, though - as long as one does not want to preserve leading whitespace. Maybe the t flag could also cause a leading and trailing newline to be removed, so that >>> foo = t""" ... Hallo ... World. ... """ would also result in Hello World. Maybe something like this has been proposed before - please be kind, if it is an old hat. Mat <javascript:void(0);>

8 19

Re: [Python-ideas] Suggestion for Style Guide for Python Code PEP 8
by Weeble 13 May '11

13 May '11

On 12.05.2011 15:44, Rahul Amaram wrote: > The preferred way for checking if a key (k) exists in a dictionary (d) > is "if k in d". This is faster than "if k in d.keys()" and this has > superseded "d.has_key(k)" While 'k in d' is the right way to do it, I feel the claim it's faster that 'k in d.keys()' is somewhat weak. While this is technically true, it's a constant overhead, not some cost linear in the size of the collection - at least in Python 3 - because .keys() returns a view. >>> timeit("'1234567' in d", "d=dict((str(x),x) for x in range(5000000))") 0.09317641210044993 >>> timeit("'1234567' in d.keys()", "d=dict((str(x),x) for x in range(5000000))") 0.1938305479460105 >>> timeit("'1234567' in dkeys", "dkeys=dict((str(x),x) for x in range(5000000)).keys()") 0.0903750153983367 So "x in d.keys()" is slower than "x in d", but only by the cost of a method lookup. I don't see any reason ever to recommend using "x in d.keys()", but I think it's misleading to say that this is because of performance reasons, assuming that we are talking about Python 3. (I also completely agree with everything Georg said, FWIW.)

1 0

Allow 'import star' with namespaces
by Brendan Moloney 11 May '11

11 May '11

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

10 20

EuroPython: Early Bird will end in 2 days!
by Palla 11 May '11

11 May '11

Hi all, If you plan to attend, you could save quite a bit on registration fees! Buy your ticket now! http://ep2011.europython.eu/registration/ The end of Early bird is on May 12th, Friday, 23:59:59 CEST. We'd like to ask to you to forward this post to anyone that you feel may be interested. We have an amazing lineup of tutorials, events and talks. We have some excellent keynote speakers and a very complete partner program... but early bird registration ends in 2 days! Right now, you still get discounts on talks and tutorials so if you plan to attend Register Now: http://ep2011.europython.eu/registration/ While you are booking, remember to have a look at the partner program and our offer for a prepaid, data+voice+tethering SIM. All the best, -- ->PALLA

1 0

1_000_000
by Matt Chaput 08 May '11

08 May '11

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

20 41

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

08 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 08 May '11

08 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 07 May '11

07 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