Mailman 3 March 2009 - Python-Dev

mentoring Roundup work
by Stefan Seefeld 28 Mar '09

28 Mar '09

Hello, I have just applied to be considered as GSoC mentor with the PSF, notably work on Roundup. (My ID is 'stefan') I'm a long-term Roundup user and contributor. My recent contributions include the XMLRPC interface, as well as many bug fixes and enhancements. I also spearheaded the migration of python.org from the sf.net bug tracker(s) to bugs.python.org. Please let me know if there are any mailing lists or other channels I should connect to to follow-up. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
by P.J. Eby 28 Mar '09

28 Mar '09

At 06:52 AM 3/28/2009 -0500, Guido van Rossum wrote: > > 2. In addition to the "yield from" syntax for delegating to a > > subgenerator, also add new syntax for returning values from > > subgenerators so that the basic "return X" can continue to trigger > > SyntaxError. > > > > Since option 2 would most likely lead to a bikeshed discussion of epic > > proportions, I'm currently a fan of option 1 ;) > >Me too. It also seems option 2 doesn't help us decide what it should >do: I still think that raising StopIteration(value) would be >misleading to vanilla users of the generators. Agreed. (I still think new syntax is a plus, though, as it helps to clearly signal both the intent to make the generator a "subtask" and the need to call it with yield-from. Readability counts.)

1 0

PEP 380 (yield from a subgenerator) comments
by Nick Coghlan 28 Mar '09

28 Mar '09

I really like the PEP - it's a solid extension of the ideas introduced by PEP 342. The two changes I would suggest is that the PEP be made more explicit regarding the fact that the try/finally block only enclose the yield expression itself (i.e. no other parts of the containing statement) and that the caching comment be updated with a list of specific semantic elements that the caching should not affect. For the first part, I would prefer if the example was changed to use capitals for the variant non-keyword parts of the statement: RESULT = yield from EXPR And that it formally expanded to: _i = iter(EXPR) try: _u = _i.next() while 1: try: _v = yield _u except Exception, _e: _m = getattr(_i, 'throw', None) if _m is not None: _u = _m(_e) else: raise else: if _v is None: _u = _i.next() else: _u = _i.send(_v) except StopIteration, _e: _expr_result = _e.value finally: _m = getattr(_i, 'close', None) if _m is not None: _m() RESULT = _expr_result I believe writing it that way would make it clearer that the scope of the try/finally block doesn't include the assignment part of the statement. For the second part, the specific semantics that I believe should be noted as not changing even if an implementation chooses to cache the bound methods are these: - The "send" and "throw" methods of the subiterator should not be retrieved if those methods are never called on the delegating generator - If "send" is called on the delegating generator and the subiterator has no "send" method, then an appropriate "AttributeError" should be raised in the delegating generator - If retrieving the "next", "send" or "throw" methods from the subiterator results in an exception then the subiterator's "close" method (if it has one) should still be called Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

11 52

version compare function into main lib
by anatoly techtonik 28 Mar '09

28 Mar '09

Greetings, Correct me if I wrong, but shouldn't Python include function for version comparisons? The problem of splitting a string like "10.3.40-beta" into tuple for cmp() seems to be dead simple, but the code gets bulky with excepting errors arised from converting resulting strings for arithmetic comparison. No wonder people advise to use ready distutils.version module, but that's not good to introduce such dependency for main program logic. What do you think about adding cmpversions(first, second, strict=false) based on distutils into main lib? Will it be more appropriate to isolate the function into "versions" module? Should it be rewritten to remove re dependency in this case? Distutils version comparisons: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/ve… --anatoly t.

8 13

Partial 2to3?
by skip＠pobox.com 28 Mar '09

28 Mar '09

Following up on yesterday's conversation about 2to3 and 3to2, I wonder if it's easily possible to run 2to3 with a specific small subset of its fixers? For example, people not wanting to make the 2->3 leap yet might still be interersted in the exception handling changes ("except Foo as exc")? Thx, -- Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/

4 3

Version strings
by "Martin v. Löwis" 28 Mar '09

28 Mar '09

I just collected the version strings of versions that got released to PyPI, and put up the list on http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions Most of them probably fit into any schema we come up with, but there are certainly some unconventional ones: 1 to 3 1.* Verrsion 1 working proof of concept Regards, Martin

2 1

"setuptools has divided the Python community"
by Olemis Lang 28 Mar '09

28 Mar '09

On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw <barry(a)python.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote: > >>> One thing that /would/ be helpful though is the ability to list all the >>> resources under a specific package path. This is (I think) one use case >>> that pkg_resource fails to support and it's the one place that I've had >>> to >>> drop down to file system introspection. >>> Really ... ? What are all these for ? {{{ >>> [x for x in dir(pkg_resources) if all(y in x for y in ['dir', 'resource_'])] ['resource_isdir', 'resource_listdir'] }}} -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?

4 11

Bug#521275: Acknowledgement (colored prompt conflicts with cursor positioning)
by owner＠bugs.debian.org 27 Mar '09

27 Mar '09

Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Matthias Klose <doko(a)debian.org> If you wish to submit further information on this problem, please send it to 521275(a)bugs.debian.org, as before. Please do not send mail to owner(a)bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 521275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521275 Debian Bug Tracking System Contact owner(a)bugs.debian.org with problems

2 1

Re: [Python-Dev] My summit notes (packaging)
by Tarek Ziadé 27 Mar '09

27 Mar '09

2009/3/27 P.J. Eby <pje(a)telecommunity.com>: > Also, it's quite likely that platform-specific dependencies may exist as > well. It might be possible to accommodate these things with a sufficiently > flexible format, but currently, the only way to handle them with > distutils/setuptools is in the setup script. > Yes, we are working on these particular issues when some metadata require some code to run. But most of the time, a package is able to express its dependencies in a static file. Regards Tarek

1 0

"setuptools has divided the Python community"
by Olemis Lang 27 Mar '09

27 Mar '09

On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake <fdrake(a)acm.org> wrote: > On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote: >> >> One of the motivations for deprecating this (and for using this >> specific example) was that Matthias Klose, the Python packager for >> Debian, said he never uses bdist_rpm. > > Given that Debian doesn't use RPMs, Only if using alien ... but ... > isn't that expected? > ... yes I assume that the best way for building debs is not building an RPM first so ... > I'm actually in favor of removing the bdist_* from the standard library, and > allowing 3rd-party tools to implement whatever they need for the distros. > But I don't think what you're presenting there supports it. > I agree ... BTW ... bdist_rpm is also there in Windows, and viceversa, bdist_wininst is also the in FC | RH ... and noione needs that, except devs willing to build RPMs in order to provide their own installers ... but most of the use cases for distutils bdist_* cmds come from similar situations ... IMHO ... and the OS of users of a pkg doesnt match the OS of the devs. The later may even have different OSs installed ... ;) I mean, who is gonna use bdist_* if not devs or distro maintainers or somebody trying to build an installable artifact (... RPM, DEB, MSI, ...) for users having their own OS-flavors ? -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?

1 0

Python-Dev March 2009