Re: [Python-Dev] Ordering keyword dicts
On 06/09/2013 10:13 PM, Alexander Belopolsky wrote: On Sun, May 19, 2013 at 1:47 AM, Guido van Rossum mailto:[email protected]>> wrote: I'm slow at warming up to the idea. My main concern is speed -- since most code doesn't need it and function calls are already slow (and obviously very common :-) it would be a shame if this slowed down function calls that don't need it noticeably. And we could remove this bit from the docs... """ The OrderedDict constructor and update() method both accept keyword arguments, but their order is lost because Python’s function call semantics pass-in keyword arguments using a regular unordered dictionary. """ Here is an idea that will not affect functions that don't need to know the order of keywords: a special __kworder__ local variable. The use of this variable inside the function will signal compiler to generate additional bytecode to copy keyword names from the stack to a tuple and save it in __kworder__. I like the idea of an ordered dict acting the same as a regular dict with an optional way to access order. It also will catch uses of unordered dicts in situations where an ordered dict is expected by having the ordered key words accessed in a way that isn't available in unordered dicts. I don't care for a magic local variable inside of a function. With that feature, an OrderedDict constructor, for example can be written as > def odict(**kwargs): return OrderedDict([(key, kwargs[key]) for key in __kworder__]) There is two situations where this would matter... The packing of arguments when **kwargs is used in the function definition, and the unpacking of arguments when **kwargs is used in the function call. By having the unpackng side also work with ordered dicts, maybe we could then replace the many *very common* occurrences of (*args, **kwargs) with just (**all_args) or (***all_args). :) It's the unordered nature of dictionaries that requires *args to be used along with **kwargs when forwarding function arguments to other functions. Another variation of this is to have a way to forward a functions "signature name space" to another function directly and bypass the signature parsing those cases. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3 metaclasses, doctest, and unittest
I just wanted to take a minute and say THANK YOU to everyone involved in getting Python 3 to where it is today. It is so much easier to use, especially metaclasses (nearly pulled my hair out trying to get Enum working on Py2!). Also a big thank you to the doctest folks as it was invaluable in getting my Py2 examples correct, and, of course, the unittest folks as I would have been lost without those. Thank you thank you thank you. -- ~Ethan~ P.S. I'll get a backported package on PyPI after the code commit for 3.4. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new Plan 9 (and family) port of v2.7.5
I have a set of patches I've developed based on the 2.7 branch that provides a working port of Python 2.7.5 to Plan 9 386 and amd64 builds (an arm version is mostly working, but will need a few more updates before being hauled off on the wagon). Most of the changes, including mkfiles, are local to a Plan9 subdirectory. There are a few changes to Lib/*.py files specifically site.py and sysconfig.py to make living in a semi-POSIX world tolerable with many current Python modules. Because Plan 9 does not have shared libraries, we must link in all the C modules we want at build time. This means that I've included specific targets to pull in Mercurial sources during the compilation and linking phases. That brings us up to a current version of Mercurial 2.6.2. There is no ssh support for cloning, but we do have a viable version of https: using TLS/SSLv3 that has worked well with bitbucket. That said, I can prepare a patch from my mq work area and submit it upstream in one of various ways for review. Is there a preferred method that does not require an initial `hg clone ssh://[email protected]/cpython`? acme# pwd /usr/jas/src/cmd/cpython acme# hg sum parent: 83814:75a6bbf41cc8 plan9 qbase qtip update setup base install locations branch: 2.7 commit: 8 unknown (clean) update: 37 new changesets, 2 branch heads (merge) mq: 1 applied ac -jas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
