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 … [View More]

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' … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]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? [View Less]

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 … [View More]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? [View Less]

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 … [View More]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: [View Less]

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 … [View More]

2 1