Mailman 3 May 2013 - Python-ideas

Let's be more orderly!
by Jonathan Eunice 23 May '13

23 May '13

Python’s nicely evolved its standard data structures. Bringing set into the core, adding OrderedDict (and friends), and establishing collections ABCs—all these up-level common facilities, broadly improving program clarity and correctness. I’d like Python to take the next step, especially regarding ordering. Using a compatible, separate implementation for OrderedDict is a fine way to gracefully extend the language, but it leaves ordering only half-accomodated. Consider: OrderedDict(a=2, b=3, c=7) yields: OrderedDict([('a', 2), ('c', 7), ('b', 3)]) The items are immediately disordered, having been jumbled passing through a conventional dict. One can initialize using a list of items, of course, but that reminds me of the line from NetHack: “You enter what seems to be an older, more primitive world.” Everyone rightly accepts doing a bit more specification for truly “extra” data structure features—persistence, say. And if falling back to lists of tuples is the best that can be done for ordered structures, well, okay. We’ll live with it. But from an app developer’s point of view, ordering is a basic, essential property. It seems like something that should be gracefully accommodated, as a built-in, rather than as “an extra” or something that requires falling back to Late Medieval Python. kwargs arrived in 1.4, back in 1996, right? So I propose that kwargs, at least, default to an ordered mapping rather than a pure hash mapping. Ideally, {...} literals would also be ordered. I suspect this will be an unpopular idea among implementers, for whom unordered dict is a pervasive and long-optimized tool. But this is a correctness, or at least a consistency, issue. I don’t see any elegant alternative way to initialize ordered data structures unless the modern Python initialization idiom(s), esp. kwargs, themselves observe order. Historically, sort features were usually unstable because that’s easier to implement and faster to run. Over time, stable sort has become the norm, either as an option (e.g. GNU’s sort --stable, Perl’s use sort 'stable' as of 5.8) or implicitly (e.g. Python’s sorted, as of 2.2). Over time, getting better results proved more broadly important than getting near-correct results faster; and both by code optimization and system improvement, the associated time or space cost of stable ordering was mooted. I’d like the same to happen for Python mappings. It’s my understanding that Ruby 1.9 has recently made this shift.

14 33

frozenset literals
by Hua Lu 21 May '13

21 May '13

This is similar to another proposal: http://mail.python.org/pipermail/python-3000/2008-January/011798.html Anyway, I was using ast.literal_eval and attempted to use frozenset({...}) as a key in a dictionary, which failed, because frozenset isn't a literal (though putting frozenset in the environment would be a security risk). I am currently working around this with tuples, but I'd like a literal for representing frozensets as well. I also use frozensets elsewhere in the code in ways similar to Raymond's original suggestion. Perhaps something like f{...} for declaring frozenset( comprehension)? literals?

15 31

Allowing comments after line continuations
by Bruce Leban 17 May '13

17 May '13

At Chris Angelico's suggestion, starting another thread on this: The \ line continuation does not allow comments yet statements that span multiple lines may need internal comments. Also spaces after the \ are not allowed but trailing spaces are invisible to the reader but not to the parser. If you use parenthesis for continuation then you can add comments but there are cases where parenthesis don't work, for example, before in a with statement, as well as the current discussion of using \ to make implicit string concatenation explicit. So I propose adopting this rule for trailing \ continuation: The \ continuation character may be followed by white space and a comment. If a comment is present, there must be at least one whitespace character between the \ and the comment. That is: x = y + \ # comment allowed here z with a as x, \ # comment here may be useful b as y, \ # or here c as z: \ # or here pass x = y + # syntax error z Two reasons for requiring a space after the backslash: (1) make the backslash more likely to stand out visually (and we can't require a space before it) (2) \# looks like it might be an escape sequence of some sort while I don't think \ # does, making this friendlier to readers. I'm not passionate about that detail if the rest of the proposal flies. --- Bruce Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security

16 22

sqlite3
by Henshaw, Andy 17 May '13

17 May '13

Very minor nitpick, but can we deprecate the name "sqlite3" in favor of "sqlite"? I'm guessing that the "sqlite3" name is derived from the example program that can manage SQLite files. However, it appears that the proper name of the database system is SQLite (or "sqlite"). When I first started using this module, I remember wondering if there was another version that I should be using. -- Andy

8 11

Re: [Python-ideas] Implicit string literal concatenation considered harmful?
by Vernon D. Cole 17 May '13

17 May '13

on Fri, 17 May 2013 18:49:14 +1000 Steven D'Aprano wrote: > > Concatenating strings on the same line is a legitimate thing to do, > because you can mix different quoting types. In my opinion, there's no > really clean way to build string literals containing multiple types of > quotation marks, but implicit concatenation works and is useful. Here's a > contrived example: > > > s = "'Aren't you supposed to be " '"working"?' "', he asked with a wink." > > True. But I had to paste your example into the interpreter to figure out where the literals ended and started. s = "'Aren't you supposed to be " ... '"working"?' ... "', he asked with a wink." Is easier to read and understand. So is: s = "'Aren't you supposed to be " + '"working"?' + "', he asked with a wink." Which works today, if you don't mind doing it at run time. You can also use: s = """'Aren't you supposed to be "working"? ', he asked with a wink.""" Which also works fine, although the triple-double single-single combination is a bit frightening to look at. -- Vernon Cole

1 0

Re: [Python-ideas] Implicit string literal concatenation considered harmful?
by Vernon D. Cole 17 May '13

17 May '13

Terry Jan Reedy wrote: > > To me, having the \ below escape the newline that occurs 60 characters > later is 'counter-intuitive'. > > a + \ # a very long comment that seems to go on and on forever > > It appears that my intuition is far different. I distinctly remember that when I was first learning Python and read that you _cannot_ put a comment after a line continuation -- my comment was: "What?? Why not?" Followed by: "Oh, well, if _that_ is the only thing wrong with the language I will probably use it a lot." +1 for \ # Can I vote more than once? On the other hand, implicit string literal concatenation is so obscure that, when I really needed it a week or two ago, I went back to the documentation to make sure that it was really part of Python, and not some other syntax that I was remembering. (Sometimes I have trouble keeping my Grandchildren sorted out, too.) I could not locate it in the docs and so solved the problem another way. This discussion has helped restore my faith in my memory. +1 for deprecating it -- in Python 4. Mark it as bad code smell as soon as there is an alternative. Do we need an _explicit_ string literal concatenation operator? Yes, we do, in order to deprecate the implicit, and as we all know: "Explicit is better than implicit." +1 What should that operator be? '+' is obvious. Too obvious. I would always wonder, somewhere deep down inside my soul: did the compiler _really_ optimize the expression, or is it being evaluated at run time, every time it passes through the loop? I would avoid using it in practice for that reason alone. I don't like the use of a dot, because, at my age, it is getting pretty hard to tell them apart from a comma. Besides, '.' is already pretty busy being an attribute marker and the marker which differentiates a float from an int. My favorite candidate so far is the humble, under used, ellipses. Does it even _have_ an operator precedence? I don't know, because in ten years of Python coding I have never used it. I have used "if someFeature is NotImplemented:" and I think that reads pretty well. Ellipses, on the other hand, I have never found a use for. I know it exists, but... And, as you see, a native English speaker indicates that there is something else missing, to be filled in later, when an ellipses appears at the end of something. Not all good ideas come from the Dutch ... sometimes they come from Antipodes. +1 for "..." -- Vernon Cole

2 1

MacroPy Final Report, Request for Feedback
by Haoyi Li 16 May '13

16 May '13

Hey All, I'd like to announce the release of MacroPy 0.1.7 ( https://github.com/lihaoyi/macropy). MacroPy is an implementation of Syntactic Macros in the Python Programming Language, which we used to implement a pretty impressive list of demo macros: - Case Classes <https://github.com/lihaoyi/macropy#case-classes>, easy Algebraic Data Types from Scala - Pattern Matching <https://github.com/lihaoyi/macropy#pattern-matching> from the Functional Programming world - Tail-call Optimization<https://github.com/lihaoyi/macropy#tail-call-optimization> - String Interpolation<https://github.com/lihaoyi/macropy#string-interpolation>, a common feature, and Pyxl<https://github.com/lihaoyi/macropy#pyxl-integration>, which is basically XML interpolation. - Tracing <https://github.com/lihaoyi/macropy#tracing> and Smart Asserts<https://github.com/lihaoyi/macropy#smart-asserts>, from every programmer's wildest dreams. - PINQ to SQLAlchemy<https://github.com/lihaoyi/macropy#pinq-to-sqlalchemy>, a clone of LINQ to SQL from C# - Quick Lambdas <https://github.com/lihaoyi/macropy#quick-lambdas> from Scala and Groovy - Parser Combinators<https://github.com/lihaoyi/macropy#parser-combinators>, inspired by Scala's - JS Snippets <https://github.com/lihaoyi/macropy#js-snippets>, cross compiling snippets of Python into equivalent Javascript Along with a really nice readme which serves both as a demonstration of the capabilities of macros <https://github.com/lihaoyi/macropy#macropy>, and also as an introduction to the macro-writing process<https://github.com/lihaoyi/macropy#detailed-guide> . This is probably going to be the last release that bundles all these demos together; future releases will begin properly breaking up the various macros into their own projects, and nicely polishing the core infrastructure into a solid foundation for others to build upon. We think that this is a pretty cool project, and can serve as a easy way for people to prototype modifications to the python language. We're looking forward to your feedback and welcome contributions =) -Haoyi

1 0

Provide a more informative message on socket's bind() and connect*()
by Giampaolo Rodola' 16 May '13

16 May '13

Consider the following: >>> import socket >>> s = socket.socket() >>> addr = ('', 8080) >>> s.bind(addr) Traceback (most recent call last): File "foo.py", line 29, in <module> s.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 98] Address already in use Problem here is that the information about the address passed to bind() is lost. While playing with Tulip I noticed some effort was put into providing a more informative message: https://code.google.com/p/tulip/source/browse/tulip/base_events.py?spec=svn… https://code.google.com/p/tulip/source/browse/tulip/base_events.py?spec=svn… I thought that maybe it makes sense to do that straight into the socket module by either overriding bind() (and also connect() and connect_ex()) or perhaps by providing a brand new PyErr_SetFromErrnoWithMsgObject() which can also be used elsewhere. Thoughts? --- Giampaolo

1 0

Anonymous blocks (again):
by Juancarlo Añez 15 May '13

15 May '13

Hello, I've banged my self against the wall, and there simply isn't a pythonic way to make a context manager iterate over the yielded-to block of code. I've had to resource to this in Grako[*]: def block(): self.rule() self.ast['rules'] = self.last_node closure(block) But what I think would be more pythonic is: closure( def: self.rule() self.ast['rules'] = self.last_node ) Or, better yet (though I know I can't have it): with positive_closure(): self.rule() self.ast['rules'] = self.last_node The thing is that a "closure" needs to call the given block repeatedly, while remaining in control of the context of each invocation. The examples given above would signal the closure to be over with an exception. The convoluted handling of exceptions on context manager's __exit__ make it impossible (for me) to construct a context manager that can call the yield-to block several times. Anyway, the anonymous def syntax, with or without parameters, is a given, and a solution for many qualms about the Python way of things. [*] https://bitbucket.org/apalala/grako -- Juancarlo *Añez*

16 52

Syntax for easy binding __name__, __module__, __qualname__ to arbitrary objects
by Piotr Duda 14 May '13

14 May '13

In discussion about http://www.python.org/dev/peps/pep-0435/ being mentioned problems with enums created with functional syntax: - need for explicit pass of type name to "function" that create enum type: Animals = Enum('Animals', 'dog cat bird') which violates DRY - pickling which requires __module__ atribute to be set, proposed solutions for this was either use non-portable and fragile _getframe hack, or explicit pass module name: Animals = Enum('animals.Animals', 'dog cat bird') aside violating DRY, this solution also has other problems, it won't work correctly if module is executed directly, and will break if pickling nested classes from http://www.python.org/dev/peps/pep-3154/ will be implemented (it may by bypassed by either provide separate arguments for module and type name, or using different separator for separating module and class name) These also apply for other objects like NamedTuple or mentioned NamedValues. To solve these problems I propose to add simple syntax that assigns these attributes to arbitrary object: def name = expression other possible forms may be: def name from expression class name = expression class name from expression name := expression # new operator which would be equivalent for: _tmp = expression _tmp.__name__ = 'name' _tmp.__qualname__ = ... # corresponding qualname _tmp.__module__ = __name__ # apply decorators if present name = _tmp with new syntax declaring Enum will look like def Animals = Enum('dog cat bird') as pointed by Larry it may be done using existing syntax in form: @Enum('dog cat bird') def Animals(): pass but it's ugly, and may by confusing. Other examples: def MyTuple = NamedTuple("a b c d") def PI = NamedValue(3.1415926) -- 闇に隠れた黒い力弱い心を操る

20 34