Mailman 3 April 2005 - Python-Dev

longobject.c & ob_size
by Michael Hudson April 6, 2005

April 6, 2005

Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? It seems to me that the top bit of ob_digit[0] is always 0, for example, and I'm sure this would result no less convolution in longobject.c it'd be considerably more localized convolution. Cheers, mwh -- <glyph> CDATA is not an integration strategy. -- from Twisted.Quotes

4 5

Re: [Python-checkins] python/dist/src/Modules mathmodule.c, 2.74, 2.75
by Tim Peters April 6, 2005

April 6, 2005

[mwh(a)users.sourceforge.net] > Modified Files: > mathmodule.c > Log Message: > Add a comment explaining the import of longintrepr.h. > > Index: mathmodule.c ... > #include "Python.h" > -#include "longintrepr.h" > +#include "longintrepr.h" // just for SHIFT The intent is fine, but please use a standard C (not C++) comment. That is, /*...*/, not //.

1 0

Mail.python.org
by Grant Olson April 5, 2005

April 5, 2005

Not a big deal, but I noticed that https://mail.python.org/ is live and shows a generic "Welcome to your new home in cyberspace!" message. One of the webmasters may want to automatically redirect to http://mail.python.org. -Grant

2 1

Re: [Python-Dev] hierarchicial named groups extension to the re library
by ottrey＠py.redsoft.be April 4, 2005

April 4, 2005

Nicolas Fleury <nidoizo at yahoo.com> wrote: > > ottrey at py.redsoft.be wrote: > >>>>import re2 > >>>>buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping' > >>>>regex='^((?P<verse>(?P<number>\d+) (?P<activity>[^,]+))(, )?)*$' > >>>>pat2=re2.compile(regex) > >>>>x=pat2.extract(buf) > >>>>x > > > > {'verse': [{'number': '12', 'activity': 'drummers > > drumming'}, {'number': '11', 'activity': 'pipers > > piping'}, {'number': '10', 'activity': 'lords a-leaping'}]} > > Is a dictionary the good container or should another class be used? > Because in the example the content of the "verse" group is lost, > excluding its sub-groups. Something like a hierarchic MatchObject could > provide access to both information, the sub-groups and the group itself. Yes, very good point. Actually it ~is~ a container (that uses dict as it's base class). (I probably should add the following lines to the example.) >>> type(x) <class 're2._Match'> >>> x._value '12 drummers drumming, 11 pipers piping, 10 lords a-leaping' >>> x.verse[0]._value '12 drummers drumming' Josiah Carlson jcarlson at uci.edu wrote: > If one wanted to match the API of the re module, one should use > pat2.findall(buf), which would return a list of 'hierarchical match > objects' Well, that would be something I'd want to discuss here. As I'm not sure if I actually ~want~ to match the API of the re module. > Also, should it be limited to named groups? I have given that some thought as well. Internally un-named groups are recursively given the names _group0, _group1 etc as they are found. And then those groups are recursively matched. And in the final step the resulting _Match object is compressed and those un-named groups are discarded. IMO If you don't bother to name a group then you probably aren't going to be interested in it anyway - so why keeping a reference to it? eg. If you only wanted to extract the numbers from those verses... >>> regex='^(((?P<number>\d+) ([^,]+))(, )?)*$' >>> pat2=re2.compile(regex) >>> x=pat2.extract(buf) >>> x {'number': ['12', '11', '10']} Before the compression stage the _Match object actually looked like this: {'_group0': {'_value': '12 drummers drumming, 11 pipers piping, 10 lords a-leaping', '_group0': [{'_value': '12 drummers drumming, ', '_group1': ', ', '_group0': {'_value': '12 drummers drumming', '_group1': 'drummers drumming', 'number': '12'}}, {'_value': '11 pipers piping, ', '_group1': ', ', '_group0': {'_value': '11 pipers piping', '_group1': 'pipers piping', 'number': '11'}}, {'_value': '10 lords a-leaping', '_group0': {'_value': '10 lords a-leaping', '_group1': 'lords a-leaping', 'number': '10'}}]}} But the compression algorithm collected the named groups and brought them to the surface, to return the much nicer looking: {'number': ['12', '11', '10']} NB. There are also a few other tricks up the sleeve of re2. eg. It allows for named groups to be repeated in different branches of a named group hierarchy, without the name redefinition error that the re library will complain about. eg. >>> pat1=re2.compile( '(?P<parents>(?P<mother>(?P<name>[\w ]+)),(?P<father>(?P<name>[\w ]+)))' ) >>> pat1.extract('Mum,Dad') {'parents': {'father': {'name': 'Dad'}, 'mother': {'name': 'Mum'}}} > I find the feature very interesting, but being used to live without it, > I have difficulty evaluating its usefulness. Yes - this is a good point too, because it ~is~ different from the re library. re2 aims to do all that searching, grouping, iterating and collecting and constructing work for you. > However, it reminds me how much at first I found strange that only the > last match was kept, so I think, FWIW, that on a purist point of vue the > functionality would make sense in the stdlib in some way or another. Actually that "last match only" confusion was part of the motivation for writing it in the first place. > For .verse[1] or .verse[2] to make sense, it implies that the pattern is > something like... > ((?P<verse>... )(?P<verse>...)) > ... which it isn't. Good pickup! You've seen through my smoke and mirrors. ;-) That list of verses was actually created in the compression stage. (The stage that I failed to mention in my first post.) ie. The regex was: ((?P<verse>(?P<number>\d+) (?P<activity>[^,]+))(, )?)* Which returns an un-named list of verse groups. Something like: {'_group0': [ {'verse': {'number': '12', 'activity': 'drummers drumming'}, {'verse': {'number': '11', 'activity': 'pipers piping'}}, {'verse': {'number': '10', 'activity': 'lords a-leaping'}}]} But the compression algorithm discarded that '_group0' key and brought the 'verse' groups to the surface, then grouped them together in one 'verse' list. ie. to make: {'verse': [{'number': '12', 'activity': 'drummers drumming'}, {'number': '11', 'activity': 'pipers piping'}, {'number': '10', 'activity': 'lords a-leaping'}]} > > Also, should it be limited to named groups? > > Probably not. I would suggest using matchobj.group(i) semantics to > match the standard re module semantics, though only allow returning > items in the current level of the hierarchy. That is, one could use > x.verse.group(1) and get back '12', but x.group(1) would return '12 > pipers piping' Actually, I ~would~ like to limit it to just named groups. I reckon, if you're not going to bother naming a group, then why would you have any interest in it. I guess its up for discussion how confusing this "new" way of thinking could be and what drawbacks it might have. Regards. Chris.

3 3

New bug, directly assigned, okay?
by Irmen de Jong April 2, 2005

April 2, 2005

I just added a new bug on SF (1175396) and because I think that it is related to other bugs that were assigned to Walter Doerwald, I assigned this new bug directly to Walter too. Is that good practice or does someone else usually assign SF bugs to people? --Irmen

2 2

python-dev Summary for 2005-03-16 through 2005-03-31 [draft]
by Brett C. April 1, 2005

April 1, 2005

OK, so here is my final Summary. Like to send it out some time this weekend so please get corrections in ASAP. -------------------------------- ===================== Summary Announcements ===================== --------------- My last summary --------------- So, after nearly 2.5 years, this is my final python-dev Summary. Steve Bethard, Tim Lesher, and Tony Meyer will be taking over for me starting with the April 1 - April 15 summary (and no, this is not an elaborate April Fool's). I have learned a ton during my time doing the Summaries and I appreciate python-dev allowing me to do them all this time. Hopefully I will be able to contribute more now in a programming capacity thanks to having more free time. -------------------- PyCon was fantastic! -------------------- For those of you who missed PyCon, you missed a great one! It is actually my favorite PyCon to date. Already looking forward to next year. -------------------- Python fireside chat -------------------- Scott David Daniels requested a short little blurb from me expounding on my thoughts on Python. Not one to pass on an opportunity to just open myself and possibly shoot myself in the foot, I figured I would take up the idea. So hear we go. First, I suspect Python 3000 stuff will start to make its way into Python. Stuff that doesn't break backwards compatibility will most likely start to be implemented as we head toward the Python 2.9 barrier (Guido has stated several times that there will never be a Python 2.10). Things that are not backwards-compatible will most likely end up being hashed out in various PEPs. All of this will allow the features in Python 3000 to be worked in over time so there is not a huge culture shock. As for things behind the scenes, work on the back-end will move forward. Guido himself has suggested that JIT work should be looked into (according to an interview at http://www.devsource.com/article2/0,1759,1778272,00.asp). I know I plan to fiddle with the back-end to see if the compiler can be made to do more work. Otherwise I expect changes to be made, flame wars to come and go, and for someone else to write the python-dev Summaries. =) ========= Summaries ========= ---------------- Python 2.4.1 out ---------------- Anthony Baxter, on behalf of python-dev, has released `Python 2.4.1`_. .. _Python 2.4.1: http://www.python.org/2.4.1/ Contributing threads: - `RELEASED Python 2.4.1, release candidate 1 <http://mail.python.org/pipermail/python-dev/2005-March/051992.html>`__ - `RELEASED Python 2.4.1, release candidate 2 <http://mail.python.org/pipermail/python-dev/2005-March/052270.html>`__ - `BRANCH FREEZE for 2.4.1 final, 2005-03-30 00:00 UTC <http://mail.python.org/pipermail/python-dev/2005-March/052444.html>`__ - `RELEASED Python 2.4.1 (final) <http://mail.python.org/pipermail/python-dev/2005-March/052467.html>`__ ----------------- AST branch update ----------------- I, along with some other people, sprinted on the AST branch at PyCon. This led to a much more fleshed out design document (found in Python/compile.txt in the AST branch), the ability to build on Windows, and applying Nick Coghlan's fix for hex numbers. Nick also did some more patch work and asked how AST work should be tagged. There is now an AST category on SourceForge that people should use to flag things as for the AST. They should also, by default, assign such items to me ("bcannon" on SF). We have also taken to flagging threads on the AST with "[AST]" as the first item in the subject line. There was also a slight discussion/clarification on the functions named marshal_write_*() that output a byte format for the AST that is supposed to be agnostic of implementation. This will most likely end up being used as the way to pass AST objects back and forth between C and Python code. But with the name collision of the word "marshal" with the actual 'marshal' module, it needs to be changed. I have suggested - byte_encode - linear_form - zephyr_encoding - flat_form - flat_prefix - prefix_form while Nick Coghlan suggsted - linear_ast - bytestream_ast Obviously I prefer "form" and Nick prefers "ast". With Nick's reply being independent of mine it will most likely have "linear" or "byte" in the name. With the patches for descriptors and generator expressions sitting on SF, syntactic support for all of Python 2.4 should get applied shortly. After that it will come down to bug hunting and such. There is a todo list in the design doc for those interested in helping out. Contributing threads: - `Procedure for AST Branch patches <http://mail.python.org/pipermail/python-dev/2005-March/052308.html>`__ - `[AST] A somewhat less trivial patch than the last one. . . <http://mail.python.org/pipermail/python-dev/2005-March/052336.html>`__ - `[AST] question about marshal_write_*() fxns <http://mail.python.org/pipermail/python-dev/2005-March/052340.html>`__ ------------------------------------------------------- Putting docstrings before function declarations is ugly ------------------------------------------------------- The idea of moving docstrings after a 'def' was proposed, making it like most other practices in other languages. But very quickly people spoke up against the suggestion. A main argument was people just like the current way much better. I personally like the style so much that even in my C code I put the comment for all functions after the first curly brace, indented to match the flow of code. There was also an issue of ambiguity. How do you tell where the docstring for a module is when there is a function definition with a comment right after?:: """Module doc""" """Fxn doc""" def foo(): pass There is an ambiguity there thanks to constant string concatenation. In the end no one seemed to like the idea. Contributing threads: - `docstring before function declaration <http://mail.python.org/pipermail/python-dev/2005-March/052406.html>`__ ------------------------------------------- PyPI improvements thanks to PyCon sprinting ------------------------------------------- Thanks to the hard work of Richard Jones, "Fred Drake, Sean Reifschneider, Martin v. Löwis, Mick Twomey, John Camara, Andy Harrington, Andrew Kuchling, David Goodger and Ian Bicking (with Barry Warsaw in a supporting role)" accordinng to Richard, there are a bunch of new features to PyPI_ (pronounced "pippy" to prevent name clashes with PyPy). These improvements include using reST_ for descriptions, a new 'upload' feature for Distutils (requires Python 2.5), ability to sign releases using OpenPGP (requires Python 2.5), metadata fields are now expected to be UTF-8 encoded, interface cleanup, and saner URLs for projects (e.g., http://www.python.org/pypi/roundup/0.8.2). .. _PyPI: http://www.python.org/pypi/ Contributing threads: - `New PyPI broken package editing <http://mail.python.org/pipermail/python-dev/2005-March/052360.html>`__ - `Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4 <http://mail.python.org/pipermail/python-dev/2005-March/052362.html>`__ ------------------------------- Decorators for class statements ------------------------------- The desire to have decorators applied to class statements was brought up once again. Guido quickly responded, though, stating that unless a compelling use case that showed them much more useful than metaclasses it just would not happen. Contributing threads: - `@decoration of classes <http://mail.python.org/pipermail/python-dev/2005-March/052369.html>`__ =============== Skipped Threads =============== + itertools.walk() + Problems with definition of _POSIX_C_SOURCE + thread semantics for file objects Assume nothing is thread-safe + Draft PEP to make file objects support non-blocking mode. + Faster Set.discard() method? + __metaclass__ problem + Example workaround classes for using Unicode with csv module... + Change 'env var BROWSER override' semantics in webbrowser.py + bdist_deb checkin comments + Python 2.4 | 7.3 The for statement + Patch review: all webbrowser.py related patches up to 2005-03-20 + webbrowser.py: browser >/dev/null 2>&1 + C API for the bool type? + Shorthand for lambda + FYI: news items about Burton Report on P-languages + using SCons to build Python + 64-bit sequence and buffer protocol + Pickling instances of nested classes + python.org/sf URLs aren't working?

3 3

Pickling instances of nested classes
by Walter Dörwald April 1, 2005

April 1, 2005

Currently instances of nested classes can't be pickled. For old style classes unpickling fails to find the class: >>> import cPickle >>> class Foo: ... class Bar: ... pass ... >>> cPickle.loads(cPickle.dumps(Foo.Bar())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'Bar' For new style classes, pickling itself fails: >>> class Foo(object): ... class Bar(object): ... pass ... >>> cPickle.loads(cPickle.dumps(Foo.Bar())) Traceback (most recent call last): File "<stdin>", line 1, in ? cPickle.PicklingError: Can't pickle <class '__main__.Bar'>: attribute lookup __main__.Bar failed I think this should be fixed (see below for use cases). There's an old bug report open for this (http://www.python.org/sf/633930). Classes would need access to their fully qualified name (starting from the module level) (perhaps in a new class attribute __fullname__?) and the pickle machinery would have to use this name when storing class names instead of __name__. The second part should be easy to implement. The first part is harder. It can't be done by changing meta classes, because classes are created "inside out", i.e. in: class Foo: class Bar: class Baz: pass when Baz class is created, the Bar class hasn't been assigned a name yet. Another problem is that it should only be done for classes *defined* inside other classes, i.e. in class Foo: pass class Bar: Baz = Foo Foo should remain unchanged. For this I guess the parser would have to be changed to somehow keep a stack of currently "open" class definitions, so the __fullname__ attribute (or dict entry) can be set once a new class statement is encountered. Of course the remaining interesting question is if this change is worth it and if there are use cases for it. Possible use cases require that: 1) There's a collection of name objects in the scope of a class. 2) These objects are subclasses of other (nested or global) classes. 3) There are instances of those classes. There are two use cases that immediately come to mind: XML and ORMs. For XML: 1) Those classes are the element types and the nested classes are the attributes. 2) Being able to define those attributes as separate classes makes it possible to implement custom functionality (e.g. for validation or for handling certain attribute types like URLs, colors etc.) and 3) Those classes get instantiated when an XML tree is created or parsed. A framework that does this (and my main motivation for writing this :)) is XIST (see http://www.livinglogic.de/Python/xist/). For the ORM case: Each top level class defines a table and the nested classes are the fields, i.e. something like this: class person(Table): class firstname(Varchar): "The person's first name" null = False class lastname(Varchar): "The person's last name" null = False class password(Varchar): "Login password" def validate(self, value): if not any(c.islower() for c in value) and \ not any(c.isupper() for c in value) and \ not any(c.isdigit() for c in value): raise InvalidField("password requires a mix of upper and lower" "case letters and digits") Instances of these classes are the records read from the database. A framework that does something similar to this (although AFAIK fields are not nested classes is SQLObject (http://sqlobject.org/) So is this change wanted? useful? implementable with reasonable effort? Or just not worth it? Bye, Walter Dörwald

3 8

RE: [Python-checkins] python/dist/src/Lib/logging handlers.py, 1.19, 1.19.2.1
by Raymond Hettinger April 1, 2005

April 1, 2005

> Tag: release24-maint > handlers.py > Log Message: > Added optional encoding argument to File based handlers and improved error > handling for SysLogHandler Are you sure you want to backport an API change and new feature? Raymond

2 1