Mailman 3 March 2009 - Python-Dev

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
by Jess Austin March 27, 2009

March 27, 2009

On Tue, Mar 3 at 19:25:21 Guido van Rossum <guido(a)python.org> wrote: > On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon <brett(a)python.org> wrote: >> >> >> On Tue, Mar 3, 2009 at 05:13, <rdmurray(a)bitdance.com> wrote: >>> >>> On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote: >>>> >>>> On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: >>>>> >>>>> > > ?PS.: so is datetime.datetime a builtin then? :) >>>>> > > ?Another historic accident. Like socket.socket. :-( >>>>> > >>>>> ?A pity this stuff wasn't addressed for 3.0. Way too late now, though. > > A pity indeed. > >>>> It may be too late to rename the existing accidents, but why not add >>>> consistently-named aliases (socket.Socket, datetime.DateTime, etc) and >>>> strongly encourage their use in new code? >> >> Or make the old names aliases for the new names and start a >> PendingDeprecationWarning on the old names so they can be switched in the >> distant future? > > +1, if it's not done in a rush and only for high-visibility modules -- > let's start with socket and datetime. > > We need a really long lead time before we can remove these. I > recommend starting with a *silent* deprecation in 3.1 combined with a > PR offensive for the new names. I've uploaded a patch for the datetime module with respect to this issue at http://bugs.python.org/issue5530 . I would appreciate it if experienced developers could take a look at it and provide some feedback. Since I've only been hacking on CPython for about a month, please be kind! I'm happy to make changes to this. As it stands now, the patch changes the current objects to have CapWords names, and subclasses these objects to provide objects with the old names. Use of methods (including __new__) of the derived objects causes PendingDeprecations (if one has warning filters appropriately set). A warning: this patch requires the patch to the test refactoring at Issue 5520 to completely apply. It will fail one test without the patch at Issue 5516. Both of these are (inexpertly) linked from the roundup page for this issue. I hope this will be helpful. cheers, Jess Austin

5 12

Re: [Python-Dev] "setuptools has divided the Python community"
by P.J. Eby March 27, 2009

March 27, 2009

At 11:27 PM 3/26/2009 +0000, Paul Moore wrote: >What I'd really like is essentially some form of "virtual filesystem" >access to stuff addressed relative to a Python package name, Note that relative to a *Python package name* isn't quite as useful, due to namespace packages. To be unambiguous as to the targeted resource, one needs to be able to reference a specific project, and that requires you to go off the name of a module *within* a package. For example, 'zope.somemodule' rather than just 'zope'. To put it another way, you don't want to use a module that comes from an __init__.py as your origin point, but rather, some other .py file within the package. Then you can talk to that module's loader without fear of ambiguity. > rather >than to a filesystem path. How much filesystem functionality is >required is somewhat up for debate, but the basic listdir, get >(text/binary) contents, open (text/binary) stream would be a good >start (as Guido pointed out). "isdir" and "exists" would also be nice; pkg_resources provides those, plus listdir and string/stream.

3 2

notes from "2 to 3 porting" session of Python Language Summit at PyCon
by Trent Mick March 26, 2009

March 26, 2009

My notes from the "2 to 3 porting" session of Python Language Summit at PyCon. There were some agreements in this session that people wanted recorded. Happy to provide clarification in my notes aren't clear. ---- ## python 2 to 3 migration - 2to3 distutils flag (part of install or sdist) - 2to3 is slow: lots of room for speedup (esp. on the matching) - 3to2 - good, wanted, needed: esp. by module authors - brett: volunteers? silence. Benjamin? Google SOC. Jesse volunteered to mentor. - decision: want to look into it - Want target compat 2.x (which "x"). Can be done by selecting appropriate fixers. - some discussion of dict views, etc. - 2.x branch: - decision: 18 to 24 month btwn releases. - decision: 2.7 (2.6?) *might* be the end of the 2.x line. - 3.1: - in alpha now - a2 during the sprints (Brett channeling Benjamin) - MvL still has a couple PEPs he wants to propose - Jython: considering targetting 3.2 next, *then* maybe 2.7 - 3.1 will be the one exception to 18-24 mos. - on "18-24 mo": start a release date PEP with a feature freeze date stake in the ground when the prev ver is released - 3.0: special case, not doing 5 years of security releases... - hence 3.1 being released soon - linux distro guys are fine with that - extension docs for porting still missing: - brett: Benjamin has a draft - PortingToPy3k in the wiki - Gerhard: doing it against svn - the other Python implementations: what ver to target - depends on their audiences - Jython leaning on the latest 3 - IronPython doesn't want a moving target - skip 3.0 and go for 3.1 - python2 & python3 binaries: - make install should do it - "python3" for new and forever - or "python2" for Python 2.x release? Thomas: bad idea because usage of "python2" in the shebang line will only work on newer systems ---- Trent -- Trent Mick trentm at gmail.com trentm at activestate.com

1 0

Python svn post-commit hook?
by skip＠pobox.com March 26, 2009

March 26, 2009

I'm trying to get the powers that be at work to enable post-commit hooks for our Subversion repositories. Here's the default, sans comments: REPOS="$1" REV="$2" commit-email.pl "$REPOS" "$REV" commit-watchers(a)example.org log-commit.py --repository "$REPOS" --revision "$REV" Does Python's post-commit.tmpl do more (or less) than this? If it's substantially different, can someone mail me a copy of what's installed? Thanks, Skip

2 1

Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
by P.J. Eby March 26, 2009

March 26, 2009

At 12:20 PM 3/26/2009 -0700, Guido van Rossum wrote: >By brittle I meant again having to be aware of those details of the >mechanism that exist because of syntactic limitations, e.g. >accidentally writing "return X" instead of "yield Return(X)". In that case, you'd either have a syntax error under the current rules (because you're using yield in the same function), or else you'd have a normal function (no yields) that worked in the way you expect it to. IIRC, the example I gave would treat a non-Return(), non-generator value as a value to be passed back into the current generator, such that if you defined a function f, and did: g = yield f() and f was not a generator or did not return one, then the above is equivalent to: g = f() and is not an error. Granted, this can fail if f() can return some other sort of iterator, but arguably that's an error in the *caller*, which should not use yield to call such a function -- and the need to distinguish the type of function you're calling is still present in PEP 380, i.e., you still need to know whether the function you're calling is a generator with a special return mechanism.

1 0

"setuptools has divided the Python community"
by Olemis Lang March 26, 2009

March 26, 2009

2009/3/26 Toshio Kuratomi <a.badger(a)gmail.com>: > Guido van Rossum wrote: >> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: >>> I think Distutils (and therefore Setuptools) should provide some APIs >>> to play with special files (like resources) and to mark them as being special, >>> no matter where they end up in the target system. >> >> Yes, this should be done. PEP 302 has some hooks but they are optional >> and not available for the default case. [...] >> >> - Open as a binary stream >> - Open as a text stream >> - Get contents as a binary string >> - Get contents as a text string >> > Depending on the definition of a "resource" there's additional > information that could be needed. For instance, if resource includes > message catalogs, then being able to get the base directory that the > catalogs reside in is needed for passing to gettext. > Well ... considering my experience with Babel (... gettext is similar too ;) & bundling message catalogs (.MO ...) for Trac plugins needing i18n support (... I even wrote some kind of i18n architecture for Trac < 0.12 ... ;), pkg_resources handles these cases too ... dont remember very well right now how but I think it is some knid of {{{ >>> import pkg_resources >>> help(pkg_resources.resource_filename) resource_filename(self, package_or_requirement, resource_name) method of pkg_resources.ResourceManager instance Return a true filesystem path for specified resource }}} Don't know whether this is enough or not ... but anyway ... it's already there, and many people should be using things like this ... Is it a bad idea to keep it there too ? I mean together with open/get features mentioned by GvR ... Q: Will pkg_resources.ResourceManager or equivalent remain ? AFAIK this is to load resources from multiple sources ... FS, zip | egg files and so on ... CMIIW ... ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- 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

"setuptools has divided the Python community"
by Olemis Lang March 26, 2009

March 26, 2009

On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: >> Paul Moore <p.f.moore <at> gmail.com> writes: >>> >>> 3. Setuptools, unfortunately, has divided the Python distribution >>> community quite badly. >> >> Wait a little bit, and it's gonna be even worse, now that buildout and pip seem >> to become popular. For example, the TurboGears people are considering switching >> from setuptools to pip... >> >> Combined with >> the current trend that everything must be exploded into lots of interdependent >> but separately packaged libraries (the paste/pylons syndrome... try pulling >> something like TurboGears2 and see how many third-party packages it installs), I >> fear this is going to generate a very painful user/developer experience :-( >> > > I think we are in a point in Python development where we need to clearly define > how dependencies work. +1 > And this has to be defined in Python (in Distutils) > for the sake of standardization. > Well, I mentionned I did it using apt + insinstall support ... but I'd love to have all these things in Python ... with or without relying on OS-specific infrastructure for managing pkgs, deps and so on ... It is possible to have two approaches : - a thin layer on top of OS-specific (dpkg + apt, rpm + yum, wininstall, mac os ... ) pkg managers so that distutils be able to use them directly whille still keeping a single model from the end-user perspective ... At least there exists some kind of python-debian pkg ... {{{ $ apt-cache show python-debian Package: python-debian Priority: optional Section: universe/devel Installed-Size: 268 Maintainer: Ubuntu MOTU Developers <ubuntu-motu(a)lists.ubuntu.com> Original-Maintainer: Debian python-debian Maintainers <pkg-python-debian-maint(a)lists.alioth.debian.org> Architecture: all Version: 0.1.9 [...] Depends: python (>= 2.4), python-support (>= 0.7.1) Recommends: python-apt [...] Size: 43662 [...] Description: python modules to work with Debian-related data formats This package provides python modules that abstract many formats of Debian related files. Currently handled are: * Debtags information (debian_bundle.debtags module) * debian/changelog (debian_bundle.changelog module) * Packages files, pdiffs (debian_bundle.debian_support module) * Control files of single or multple RFC822-style paragraphs, e.g debian/control, .changes, .dsc, Packages, Sources, Release, etc. (debian_bundle.deb822 module) * Raw .deb and .ar files, with (read-only) access to contained files and meta-information [...] }}} Since there are a lot such systems (at least for Linux ...) ... this could also mean that it could be very complex to handle all this diversity ... However there are a few which are highly influential ... but this is certainly a concern ... - A fully fledged implementation from scratch so that distutils be in charge, all apps be consistent with Py-std ... and users have potentially two pkg systems (.. the built-in and the Py-specific ;) ; and I say potentially since it's quite sudden so far and perhaps there is a way to smoothly integrate both systems (which are potentially many of them ;) > I think the Language Summit tomorrow is a good place to discuss about > these problems, Hope it be available (recorded ?) some day so as to hear some opinions ... ;) > and to make sure pip, setuptools and zc.buildout rely on the same > standards and pieces. > Oh yes ! +1 > PEP 376 is my first attempt to make it happen, and my goal is to see another > pre-PEP coming out of thea language summit, adressing the dependencies problem. > ;) > I can't hear that setuptools has divided the Python community. Said like this ... some might think that setuptools is responsible for someone else's choices and actions ... and I dont think so ... > It has provided > solutions to real problems we had in web development. It's unperfect, > and it has to be > fixed and integrated into Python. But it should not be done outside Python imho. > I mostly agree with all this, but I would like to know something ... in case a single pkg management sys be ready for Py (... I mean integrated into Py ...) and so on ... Why will we need distutils comands like : bdist_msi bdist_wininst bdist_rpm <... more «non-standard» candidates like py2exe, stdeb, ...> ? Will all this still be necessary and maintained ? As long as installing /uninstalling them be handled correctly in built-in as well as Py systems (considering the duplicate «package repositories» ...) ... I think this could be fine ... but details are details ... ;) > If you had worked with Zope 5 years ago, you would understand what > setuptools and > zc.buildout brought to these communities. And today's experience is a > whole less painful trust me. > Yes ... setuptools has undoubtedly its own value ... :o) > But I agree that the sizes of the packages are too small now, and it has gone > to far. Installing a web app like Plone is scary (+100 packages) > > But this is the responsability of Zope, TG, etc to distribute their packages in > bigger pieces I guess. > I do think so ... The same happens with Trac plugins. In case of browsing the archive of trac-users mailing list anyone can realize that there are many related plugins people'd like to install at once to get the whole functionality. Nowadays in some cases they have to install ... *a loooot* and then configure ... *a loooot* in order to get the whole thing working out ... and there are tiny but useful plugins ... Besides further contributions seldom end-up with potential interoperability issues and related features might not be tested as a whole ... And things that should be in core (e.g. AccountManager plugin ... since it seems there is no way to log out if it's not installed ... ;) are not still there (... took some time until trac-devs decided to incorporate it during PyCon'09 sprint ... ;) But this unification is definitely up to the plugin & framew devs ... IMO -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- 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

Fwd: "setuptools has divided the Python community"
by Olemis Lang March 26, 2009

March 26, 2009

On Thu, Mar 26, 2009 at 1:54 PM, Guido van Rossum <guido(a)python.org> wrote: > 2009/3/26 Toshio Kuratomi <a.badger(a)gmail.com>: >> Guido van Rossum wrote: >>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: >>>> I think Distutils (and therefore Setuptools) should provide some APIs >>>> to play with special files (like resources) and to mark them as being special, >>>> no matter where they end up in the target system. >>> >>> Yes, this should be done. PEP 302 has some hooks but they are optional >>> and not available for the default case. A simple wrapper to access a >>> resource file relative to a given module or package would be easy to >>> add. It should probably support four APIs: >>> >>> - Open as a binary stream >>> - Open as a text stream >>> - Get contents as a binary string >>> - Get contents as a text string >>> >> Depending on the definition of a "resource" there's additional >> information that could be needed. For instance, if resource includes >> message catalogs, then being able to get the base directory that the >> catalogs reside in is needed for passing to gettext. > > Well the whole point is that for certain loaders (e.g. zip files) > there *is* no base directory. If you do need directories you won't be > able to use PEP-302 loaders, and you can just use > os.path.dirname(<some_module>.__file__). > Oops didnt see this msg ... AFAICR ... this is the kind of reasons ResourceManager is there for in pkg_resources ... CMIIW anyway ... However GvR was talking about PEP 302 loaders ... well ... the only thing I can say is that bundling message catalogs in egg files (they 'r zip files anyway ;) and using them with Babel (... similar to gettext ... I think ...) works fine for me using the aforementioned functions in pkg_resources ... About whether PEP 302 loaders should (look like | implement functions in) pkg_resources.ResourceManager or not ... I'm not very sure ... ... and I'm talking about ... {{{ >>> [x for x in dir(pkg_resources) if 'resource_' in x] ['resource_exists', 'resource_filename', 'resource_isdir', 'resource_listdir', 'resource_stream', 'resource_string'] }}} -- 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? -- 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

Py plugins architecture - Trac [WAS:] "setuptools has divided the Python community"
by Olemis Lang March 26, 2009

March 26, 2009

On Wed, Mar 25, 2009 at 6:08 PM, Barry Warsaw <barry(a)python.org> wrote: > On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote: > >> Yes you're right, Trac requires .egg files for local plugins installs >> (... in /plugins folder ;) so that not all environments but only one >> be able to use the plugin ... but that's not exactly what I'm saying, >> since setuptools AFAIK *MUST* be already there ... so Trac depends on >> setuptools. > > I've not looked at Trac's plugin architecture, but I wonder, how much of it > is generic enough to be useful for any application? I've found setuptools > entry points difficult to work with for plugins, and I think the Python > ecosystem could benefit from more shared wisdom, if not code, in designing > plugin frameworks for applications. > Well ... I'm not pretty sure about following this here (py-dev) however, I'll do my best effort to try to explain a little about it and provide you some pointers ... ;) - Trac plugin architecture (... which is a little bit «meta» ...) is based on a few classes (... and more of them under the hood ... ;) 1 - Interface ... includes the protocol used to interact with the specific plugin 2 - Component ... The base class for implementing the plugin functionality ... 3 - ComponentManager ... represents something managing many components | plugins ... (e.g. Trac environments are «represented» as instances of trac.env.Environment class and it is nothing but a direct descendant of ComponentManager ... ;). 4 - ExtensionPoint ... to access all the plugins implenting an specific interface ... 5 - A few other «cosmetic» features like Configurable items and classes (i.e. descriptors ;) to access configuration options ... In theory people can implement their own descendants of ComponentManager and do things the way they want to (... at least Noah K. -trac dev- has mentioned that he has used Trac architecture for «his own apps» ... and I have, but only for «my own» *web* apps ... I have no experience about desktop or GUI or other apps ...) ... It relies on pkg_resources entry points support in order to «load» the plugins ... Besides you can read Trac docs for further details ... AFAIK they'll attend to PyCon'09 ... talks (... hopefully recorded ;) + sprint ... PS: Edgewall guys have also done a great job in building another great package for i18n ... and AFAICR it is based on a simpler pluggable architecture relying on setuptools too ... (... CMIIW anyway ;) I am talking about Babel ... -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:

1 0

Packaging Survey first results + Summit schedule
by Tarek Ziadé March 26, 2009

March 26, 2009

Hi, Sorry for the cross-post, but it seemed appropriate since packaging is being discussed in python-dev tonight, - Here are the first results for the packaging survey: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ - And tomorrow's Summit schedule for the packaging part : http://tarekziade.wordpress.com/2009/03/26/pycon-language-summit-is-tomorro… Please comment (in the appropriate list or in my blog) if you have something you would like to say or see addressed during the Summit and you are unable to be present. (I am already trying to summarize what has been said in python-dev today but I am not sure I'll be able to read everything before tomorrow) Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

2 1