Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:42 PM, Stephen J. Turnbull step...@xemacs.org wrote: +- E -- downstream developer -+ | | | +--+ V source - build - A - B -+- C - D - | END USER | + | +--+ A | | +- F - OS distro -+ According to your diagram, the build-A is the only part where describing meta-data can be possible so that everyone benefit from it - which is what I believe Tarek is working on, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: That's all good. I just don't think that a presentation in terms of code in-lining is a good idea. I was trying to describe it in a way that would give some insight into *why* the various aspects of the formal definition are the way they are. The inlining concept seemed like an elegant way of doing that. However, I've since realized that it's not quite as unambiguous as I thought it was when a return value is involved. I'll see if I can find another approach. some languages *do* work that way (e.g. macro languages and Algol-60), Algol-60 doesn't actually work that way, they just used a similar trick to define certain aspects of the semantics (although in that case I agree there were better ways they could have defined it). I'm asking you to use a different word, since inlining to me has pretty strong connotations of textual substitution. That's not what it usually means, as far as I can see. When you declare a function 'inline' in C, you're not asking for a blind textual substitution. Rather, you're asking the compiler to generate whatever code is needed to get the same effect as an actual call. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Nick Coghlan wrote: I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API. Having made that decision, though, couldn't the result just be re-used for any future renaming exercises of this kind? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Nick Coghlan wrote: Although the PEP may still want to mention how one would write *tests* for these things. Will the test drivers themselves need to be generators participating in some kind of trampoline setup? I don't see that tests are fundamentally different from any other code that wants to call a value-returning generator and get the value without becoming a generator itself. So if it's to be mentioned in the PEP at all, a general solution might as well be given (whether it's to use a trampoline or just write the necessary next() and except code). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Trying to think of a better usage example that combines send() with returning values, I've realized that part of the problem is that I don't actually know of any realistic uses for send() in the first place. Can anyone point me to any? Maybe it will help to inspire a better example. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging Survey first results + Summit schedule
Le Thursday 26 March 2009 04:58:51 Tarek Ziadé, vous avez écrit : - Here are the first results for the packaging survey: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ How do you remove a package ? Wow, 275 hits for manually and 79 for fail at uninstallation -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Greg Ewing wrote: Nick Coghlan wrote: Although the PEP may still want to mention how one would write *tests* for these things. Will the test drivers themselves need to be generators participating in some kind of trampoline setup? I don't see that tests are fundamentally different from any other code that wants to call a value-returning generator and get the value without becoming a generator itself. So if it's to be mentioned in the PEP at all, a general solution might as well be given (whether it's to use a trampoline or just write the necessary next() and except code). Agreed the problem is more general than just testing - but a test driver is potentially interesting in that you probably want the same test suite to be able to test both normal code and the cooperative multitasking code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Greg Ewing wrote: Nick Coghlan wrote: I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API. Having made that decision, though, couldn't the result just be re-used for any future renaming exercises of this kind? Maybe - the problem with taking that decision and trying to get a general rule out of it is that there were plenty of reasonable arguments on all sides (there were more than just 2 options, which made the choice all the more challenging). It wouldn't take many changes in the specifics of a situation for the best answer to be different from what we ended up doing in the threading case. The precedent would add weight to the idea of doing the same thing again, but I don't think it would be enough on its own to completely decide the matter. So the only general rule I really got out of that experience was actually let's not do this again if we can possibly avoid it :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Revised**8 PEP on Yield-From
Here's a new draft of the PEP. I've added a Motivation section and removed any mention of inlining. There is a new expansion that incorporates recent ideas, including the suggested handling of StopIteration raised by a throw() call (i.e. if it wasn't the one thrown in, treat it as a return value). Explicit finalization is performed if the delegating generator is closed, but not when the subiterator completes itself normally. PEP: XXX Title: Syntax for Delegating to a Subgenerator Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing greg.ew...@canterbury.ac.nz Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 2.7 Post-History: Abstract A syntax is proposed for a generator to delegate part of its operations to another generator. This allows a section of code containing 'yield' to be factored out and placed in another generator. Additionally, the subgenerator is allowed to return with a value, and the value is made available to the delegating generator. The new syntax also opens up some opportunities for optimisation when one generator re-yields values produced by another. Motivation == A Python generator is a form of coroutine, but has the limitation that it can only yield to its immediate caller. This means that a piece of code containing a ``yield`` cannot be factored out and put into a separate function in the same way as other code. Performing such a factoring causes the called function to itself become a generator, and it is necessary to explicitly iterate over this second generator and re-yield any values that it produces. If yielding of values is the only concern, this can be performed without much difficulty using a loop such as :: for v in g: yield v However, if the subgenerator is to interact properly with the caller in the case of calls to ``send()``, ``throw()`` and ``close()``, things become considerably more difficult. As will be seen later, the necessary code is very complicated, and it is tricky to handle all the corner cases correctly. A new syntax will be proposed to address this issue. In the simplest use cases, it will be equivalent to the above for-loop, but it will also handle the full range of generator behaviour, and allow generator code to be refactored in a simple and straightforward way. Proposal The following new expression syntax will be allowed in the body of a generator: :: yield from expr where expr is an expression evaluating to an iterable, from which an iterator is extracted. The iterator is run to exhaustion, during which time it yields and receives values directly to or from the caller of the generator containing the ``yield from`` expression (the delegating generator). Furthermore, when the iterator is another generator, the subgenerator is allowed to execute a ``return`` statement with a value, and that value becomes the value of the ``yield from`` expression. In general, the semantics can be described in terms of the iterator protocol as follows: * Any values that the iterator yields are passed directly to the caller. * Any values sent to the delegating generator using ``send()`` are passed directly to the iterator. If the sent value is None, the iterator's ``next()`` method is called. If the sent value is not None, the iterator's ``send()`` method is called. Any exception resulting from attempting to call ``next`` or ``send`` is raised in the delegating generator. * Exceptions passed to the ``throw()`` method of the delegating generator are forwarded to the ``throw()`` method of the iterator. If the iterator does not have a ``throw()`` method, its ``close()`` method is called if it has one, then the thrown-in exception is raised in the delegating generator. Any exception resulting from attempting to call these methods (apart from one case noted below) is raised in the delegating generator. * The value of the ``yield from`` expression is the first argument to the ``StopIteration`` exception raised by the iterator when it terminates. * ``return expr`` in a generator causes ``StopIteration(expr)`` to be raised. Fine Details The implicit GeneratorExit resulting from closing the delegating generator is treated as though it were passed in using ``throw()``. An iterator having a ``throw()`` method is expected to recognize this as a request to finalize itself. If a call to the iterator's ``throw()`` method raises a StopIteration exception, and it is *not* the same exception object that was thrown in, its value is returned as the value of the ``yield from`` expression and the delegating generator is resumed. Enhancements to StopIteration - For convenience, the ``StopIteration`` exception will be given a ``value`` attribute that
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum guido at python.org writes: That's stating it a little too strongly. Phillip has shown how with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. It remains to be seen whether Twisted and other libraries (Kamaelia?) can benefit from this PEP. There seems to be a misunderstanding as to how generators are used in Twisted. There isn't a global trampoline to schedule generators around. Instead, generators are wrapped with a decorator (*) which collects each yielded value (it's a Deferred object) and attaches to it a callback which resumes (using send()) the execution of the generator whenever the Deferred finally gets its value. The wrapped generator, in turn, looks like a normal Deferred-returning function to outside code. Therefore, there is no nesting problem and yield from doesn't seem to be useful here. This has been confirmed to me by a Twisted developer on IRC (he pointed out, however, a streaming XML parser where yield from could save a couple of lines of code). (*) inlineCallbacks: http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.defer.html#inlineCallbacks http://enthusiasm.cozy.org/archives/2009/03/python-twisteds-inlinecallbacks Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Mar 25, 2009, at 11:02 PM, Nick Coghlan wrote: That is, the full workflow that should really be happening is something like the following: Developer(s) | V (distutils/setuptools/pip/zc.buildout/etc) | V Here's a small FYI for this point in the diagram. Perhaps some people are not aware of zc.sourcerelease. http://pypi.python.org/pypi/zc.sourcerelease/ It allows you to take a zc.buildout based project and pack it into a tarball with all the eggs the project depends on packed with it. buildout-source-release projectdir_or_repo_path buildout.cfg You can drop the resulting tarball into SOURCES directory and a corresponding .spec file into SPECS directory and build an RPM package. The RPM is then used to install the application. Thus, zc.buildout is used for development (package management) and zc.sourcerelease + rpmbuild for distribution. I know this does not solve problems that many mentioned in this thread, but it could solve a distribution problem for people who use zc.buildout but were not aware of zc.sourcerelease. As I said above, this was just an info for anyone interested in this particular workflow. Common Python packaging spec | V Packager(s)/Distributor(s) | V (Windows MSI/Mac OS X bundle/Linux RPM/Linux DEB/etc) | V End User Installation ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
2009/3/25 Tennessee Leeuwenburg tleeuwenb...@gmail.com: I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python If none of these includes managing packages (... similar to apt, yum, and equivalent ;) pls include it ... and I mean it from a higher level of abstraction; i.e. disregarding the nature of the «thing» (pkg, mdl, web framew, plugin, console app, GUI, sci-tool, and so on ... made with Py ;) The prime limitation of setuptools appears to me to come when there are conflicts. IMO the prime limitation of setuptools (for installing pkgs ... and so on ..) appears to me when I want to control what I've installed (... a broader situation, i.e. it includes the specific case when there are conflicts ... and many others ... like removal, etc ... ). For issues where there are conflicts, where I have been sufficiently motivated, setting up a virtualenv has more than met my needs. I dont think this should be *THE* option ... In fact, that's and *awesome* piece of functionality. But shouldnt be the only one ... not everybody (... devs users ...) will be open to setup a virtual env in order to install a Py app ... even myself ... I'd do it if I really need it ... else it is just painful and non-sense to force me to do it ... and I dont think it'd be right either ... For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. On my ubuntu machine, this happens. The Ubuntu packages take care of things very satisfactorily and I don't see how anyone would have a problem with it. Well I do ... my example is as follows (... it actually happened few days ago ...) : - I maintain many Trac instances in many different places ... - I updated some of them to Trac 0.11.1 ... - One of these was a host running Ubuntu Hardy ... and AFAIK there are no official debs for Ubuntu Hardy, including backports ... but only for Intrepid ;) - So I removed Trac 0.10 and installed Trac 0.11, this time using setup.py since I didnt have stdeb (... or equivalent ;) at hand ... - Few months later there was a problem with that server ... - Since I'm used to use apt+dpkg I didnt find Trac among the list of installed soft and I completely forgot about all the previous steps (... believe me my memory sucjks ... :S ...), I though Trac was removed and I installed trac 0.10 once again from a local repo ... - Results ... conflicts everywehere and time spent in finding out what was wrong ... Besides I hosted multiple Trac instances in that single machine (... that's why I package plugins as egg files ... most of the time I face this situation, and I always try to do it as portable as possible to decrease maintainance effort ... ;) - ... and the solution was to remove trac (pkg egg) folder, and this is ugly (... at least these days in XXI century ... and me thinking in taking control over the whole Emperor Vader's fleet ... I want all their spaceships and vessels ... ;) but ... what if the installation includes some other files placed somewhere else ... they remain there and they'r useless ... and you possibly wont ever know they'r still there ... if you dont use apt or similar ... ;) Perhaps an automated updates site could be configured such that there was a package for a variety of Python + some extra modules scenarios. AFAIK PyPI offers some kwalitee (cheesecake) metrics and this includes installability ... perhaps these metrics could be extended to consider whether it is possible or not to automatically build packages for a particular platform (debs, rpms, win_inst), and ... as a side-effect, additional service or maybe because of the devs manually uploading the «platform-specific pkgs» ... include those packages in PyPI ... (no debs allowed in there ... yet ;) Perhaps I'm going too far up to this point ... and I'm just dreaming ... but, beyond all these ... perhaps easy_install could just be a little bit smarter and do things as follows : 1 - Detect the platform of the target host (i.e. the OS | distro in the «machine» where the app | framework | ... will be installed ) 2 - Find out if there is a specific install package for this OS | distro in PyPI ( ... or the downloads site ...) 3 - Install the specific install package ... 4 - If either 2 or 3 goes wrong ... fall-back to installing the source distro as usual (... perhaps notifying «the user» of what's going on and asking him about whether to proceed or not ...) Doing nothing but this (... and allowing to upload debs to PyPI, together with including (b|s)dist commands for debs ... in order to get the
[Python-Dev] Py plugins architecture - Trac [WAS:] setuptools has divided the Python community
On Wed, Mar 25, 2009 at 6:08 PM, Barry Warsaw ba...@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: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
David Cournapeau wrote: I won't argue for setuptools' implementation of multi-version. It sucks. But multi-version can be done well. Sonames in C libraries are a simple system that does this better. I would say simplistic instead of simple :) what works for C won't necessarily work for python - and even in C, library versioning is not used that often except for a few core libraries. Library versioning works in C because C model is very simple. It already breaks for C++. I'm not sure what you're talking about here. Library versioning is used for practically every library on a Linux system. My limited exposure to the BSDs and Solaris was the same. (If you're only talking Windows, well; does windows even have Sonames?) I can name only one library that isn't versioned in Fedora right now and may have heard of five total. Perhaps you are thinking of library symbols? If so, there are only a few libraries that are using that. But specifying backwards compatibility via soname is well known and ubiquitous. More high-level languages like C# already have a more complicated scheme (GAC) - and my impression is that it did not work that well. The SxS for dll on recent windows to handle multiple version is a nightmare too in my (limited) experience. Looking at C#/Mono/.net for examples is perfectly horrid. They've taken inferior library versioning and bad development practices and added technology (the GAC) as the solution. If you want an idea of what python should avoid at all costs, look to that arena for your answer. * Note that setuptools' multi-version implementation shares some things in common with the GAC. For instance, using directories to separate versions instead of filenames. setuptools' implementation could be made better by studying the GAC and taking things like caching of lookups from it but I don't encourage this... I think the design itself is flawed. -Toshio signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@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. So the code inside the package can use these files seamessly no matter what the system is and no matter where the files have been placed by the packager. This has been discussed already but not clearly defined. 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 (I am proposing these somewhat redundant APIs since for some loader implementations the stream APIs are natural and the string APIs should be built on top of that, while for other loaders the string APIs are natural and the stream APIs would have to wrap a StringIO instance around this. Providing all four APIs means that the application can use the API that is most natural for *it*, which avoids double wrapping.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote: ISTR that the motivation for adding new syntax is that the best you can do using a trampoline library is still pretty cumbersome to use when you have to write a lot of tasks and subtasks, and when using tasks is just a tool for getting things done rather than an end goal in itself. I agree that the motivation and the comparison should be added to the PEP (perhaps moving the trampoline sample *implementation* to a reference or an appendix, since it is only the appearance of the trampoline-*using* code that matters). In particular, it should explain why these choices are so costly as to justify new syntax and a complex implementation: * decorator clearly identifying intent to create a task vs. no indication of task-ness * yield Return(value) vs. return value * result = yield subgenerator() vs. result = yield from subgenerator() Especially since the first two differences arguably make the non-yield from code clearer, and the third makes it more compact. with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. On the cumbersome side, there are only three differences, as I've shown above... and one of them uses less syntax than the PEP. I'm not sure what you mean by brittle. Twisted and PEAK have both had generator-based tasks for ages, and have been used in production for years, even before generators had send()/throw() -- the addition of yield expressions made it possible to get rid of the one previous brittleness, where you needed to do things like: yield subgenerator(); result = resume() in order to pass values or exceptions in. Since send()/throw() was added, the need to call a function after each yield was eliminated, at least from PEAK and my newer Trellis library; haven't looked at Twisted's tasks in a while. I believe there are other generator-based task libraries available on PyPI, but can't comment on their robustness. (The existence of throw(), by the way, makes it possible to produce tracebacks that look *exactly* as if you had called a series of functions, rather than iterating over a bunch of generators. The sample code I gave should do this correctly, as it was created by yanking out working, tested code from my Trellis library, and cutting out all the Trellis-specific bits.) If someone can find any semantic differences between the code I posted and the yield-from proposal (apart from the absence of the for x in y: yield x part of the functionality), I'd like to know about it... and it should go in the PEP. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote: Guido van Rossum guido at python.org writes: That's stating it a little too strongly. Phillip has shown how with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. It remains to be seen whether Twisted and other libraries (Kamaelia?) can benefit from this PEP. They don't get any new features, and would require (possibly significant) changes in order to be able to take advantage of the syntax. And they *still* wouldn't be able to do away with their trampolines -- the new trampolines would just be able to avoid the need for a generator stack, if they previously had one to begin with. From your description, it sounds like Twisted's version of this doesn't even use a stack. (Note: by trampoline I mean, thing that processes yielded values and manages the resumption of the generator, which need not be global. The example trampoline I posted earlier is also implemented as a decorator, and could be trivially extended via a lookup table to handle deferreds, delayed calls, or whatever else you wanted it to support as yield targets.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
Guido van Rossum wrote: On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@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. So the code inside the package can use these files seamessly no matter what the system is and no matter where the files have been placed by the packager. This has been discussed already but not clearly defined. 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. I'd be very happy if resource didn't encompass that type of thing, though... then we could have a separate interface that addressed the issues with them. I'll be at PyCon (flying in late tonight, though, and leaving Sunday) if Tarek and others want to get ahold of me to discuss possible ways to address what's a resource, what's not, and what we would need to handle the different cases. -Toshio signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Thu, Mar 26, 2009 at 10:07 AM, P.J. Eby p...@telecommunity.com wrote: At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote: ISTR that the motivation for adding new syntax is that the best you can do using a trampoline library is still pretty cumbersome to use when you have to write a lot of tasks and subtasks, and when using tasks is just a tool for getting things done rather than an end goal in itself. I agree that the motivation and the comparison should be added to the PEP (perhaps moving the trampoline sample *implementation* to a reference or an appendix, since it is only the appearance of the trampoline-*using* code that matters). In particular, it should explain why these choices are so costly as to justify new syntax and a complex implementation: * decorator clearly identifying intent to create a task vs. no indication of task-ness * yield Return(value) vs. return value * result = yield subgenerator() vs. result = yield from subgenerator() Especially since the first two differences arguably make the non-yield from code clearer, and the third makes it more compact. with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. On the cumbersome side, there are only three differences, as I've shown above... and one of them uses less syntax than the PEP. I wasn't talking about keystrokes so much as to having to remember to use thes incantations and understand what they do and what their limitations are. I'm not sure what you mean by brittle. Twisted and PEAK have both had generator-based tasks for ages, and have been used in production for years, even before generators had send()/throw() -- the addition of yield expressions made it possible to get rid of the one previous brittleness, where you needed to do things like: yield subgenerator(); result = resume() in order to pass values or exceptions in. Since send()/throw() was added, the need to call a function after each yield was eliminated, at least from PEAK and my newer Trellis library; haven't looked at Twisted's tasks in a while. I believe there are other generator-based task libraries available on PyPI, but can't comment on their robustness. (Well here is Greg's requested use case for .send(). :-) 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). (The existence of throw(), by the way, makes it possible to produce tracebacks that look *exactly* as if you had called a series of functions, rather than iterating over a bunch of generators. The sample code I gave should do this correctly, as it was created by yanking out working, tested code from my Trellis library, and cutting out all the Trellis-specific bits.) If someone can find any semantic differences between the code I posted and the yield-from proposal (apart from the absence of the for x in y: yield x part of the functionality), I'd like to know about it... and it should go in the PEP. I'll leave this up to Greg. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote: 2009/3/26 Toshio Kuratomi a.bad...@gmail.com: 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__). 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. Think: the package-y flavor of os.listdir(os.path.dirname(package.__file__)) Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScvV8HEjvBPtnXfVAQIvdQP/dwzTsPLVtM4eAKLRfzJHG7mToNVDgHNn 4L6Kh99sScVOpeYPw8tltX5YAFwDeysIiDl3L8ynS/iN4/RIVsssO97vK3nENQxE myQVfapmY0yhYrCJSYLthkaOoADB4D8pBTCbvVRwT7B4DXuVhxGpebWFVi+gSWNi ZZjDjUQ9fSk= =REBP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry Reedy wrote: 5. Much of this discussion reminds me of the debates between lumping and splitting of taxonomic categories in biology. Like that debate, it will continue forever. Funny, I was thinking the same thing, only with respect to paleoanthropology: chunkers and splitters are perpetually at war there, too. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJy9ZX+gerLs4ltQ4RAsOMAJ4tC4gn8QVGkQmYfEkftKIRJ2PTvACgs614 D6mUasLwphIRTJttkSdZjyA= =T6Tv -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Thu, Mar 26, 2009 at 10:19 AM, P.J. Eby p...@telecommunity.com wrote: At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote: Guido van Rossum guido at python.org writes: That's stating it a little too strongly. Phillip has shown how with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. It remains to be seen whether Twisted and other libraries (Kamaelia?) can benefit from this PEP. They don't get any new features, and would require (possibly significant) changes in order to be able to take advantage of the syntax. Well yes if you want to maintain backwards compatibility there wouldn't be any advantage. The point of the new syntax is clearly that (eventually) they can stop having their own wrappers, decorators and helpers (for this purpose). And they *still* wouldn't be able to do away with their trampolines -- the new trampolines would just be able to avoid the need for a generator stack, if they previously had one to begin with. From your description, it sounds like Twisted's version of this doesn't even use a stack. Whether yo need a trampoline or not depends on other needs of a framework. There is some clear low-hanging fruit for Greg's proposal where no trampoline or helpers are needed -- but where currently refactoring complex code containing many yield statements is cumbersome due to the nee to write each subroutine call as for x in subroutine(): yield x -- being able to replace this with yield from subroutine() is a conceptual advantage to me that is not proportional to the number of characters saved. (Note: by trampoline I mean, thing that processes yielded values and manages the resumption of the generator, which need not be global. The example trampoline I posted earlier is also implemented as a decorator, and could be trivially extended via a lookup table to handle deferreds, delayed calls, or whatever else you wanted it to support as yield targets.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 12:22 PM, Barry Warsaw ba...@python.org wrote: On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote: 2009/3/26 Toshio Kuratomi a.bad...@gmail.com: 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__). 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. Think: the package-y flavor of os.listdir(os.path.dirname(package.__file__)) Good idea. Can I suggest that API this takes a glob-style pattern? (Or to be fully general, a list of patterns and a list of exclusion patterns.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tennessee Leeuwenburg wrote: I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python The prime limitation of setuptools appears to me to come when there are conflicts. Other than that, for packages where it is available, I have never had an issue with the functioning of setuptools. It's Just Fine. For issues where there are conflicts, where I have been sufficiently motivated, setting up a virtualenv has more than met my needs. In fact, that's and *awesome* piece of functionality. Agreed. I find the isolation provided by virtualenv to be essential to the work I do. For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. On my ubuntu machine, this happens. The Ubuntu packages take care of things very satisfactorily and I don't see how anyone would have a problem with it. I don't know what the situation is under Windows, however systems such as the Enthought Python Suite do provide kitchen-sink-included Python distributions. Perhaps an automated updates site could be configured such that there was a package for a variety of Python + some extra modules scenarios. For installing applications, I would presume that app developers would generally take care of this themselves, through the use of an MSI or .deb file in order to protect their dependencies somewhat. For anyone looking to extend their interpreter for some specific task, virtualenv and setuptools should do the job, and the developer can just go the extra mile to do the work to get it right themselves. Perhaps the most under-served use case is people who want a kitchen-sink-included distribution, to be managed by their system packages. Either they are not away of systems such as EPS or are opposed to it in principle. Were time and effort no obstacle, I would suggest that it may be worth Python.org offering to host and/or maintain a variety of Python distributions available for installation which include various standard extensions. The model that eclipse takes, with a base system and plugins, but with flavoured versions available (i.e. Scientic Python Distribution to include SciPy, Numpy and MatPlotLib for example). Thoughts? I like the summary, and the idea of 'contrib' distributions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJy9ib+gerLs4ltQ4RAreJAJ938Tf9sQH5T4JikxZUa36MVhp7FwCdH1Qe GEKtcoFn8GQWlrfU1qmMkGM= =lKBr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-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. Think: the package-y flavor of os.listdir(os.path.dirname(package.__file__)) Good idea. Can I suggest that API this takes a glob-style pattern? (Or to be fully general, a list of patterns and a list of exclusion patterns.) Good idea. Thinking back on my typical use cases, a glob style pattern would be enough. Usually I'm asking give me all the .py files in this package or I'm looking for the .txt files in this path. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScvZjnEjvBPtnXfVAQKtIQP9HVCkFI8o0bHbUxA+lS3CUa2NzyeKgs9j MKWjC9yOT+oMhZXa0CZJfzmjwjn7Bum5+7W4TWNsMQPWfCPWl/D6oQlBI/UXa66d VQpjA05PkxEgMuvmFMGwpMiG2h668kKBKvbKUVsxNIJI3fvBj1TyYpVpQKVNHNep xnEPyWK9ylM= =YhoQ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: setuptools has divided the Python community
On Thu, Mar 26, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@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?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw ba...@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. Think: the package-y flavor of os.listdir(os.path.dirname(package.__file__)) Good idea. Can I suggest that API this takes a glob-style pattern? (Or to be fully general, a list of patterns and a list of exclusion patterns.) Good idea. Thinking back on my typical use cases, a glob style pattern would be enough. Usually I'm asking give me all the .py files in this package or I'm looking for the .txt files in this path. I think shutil.copytree new ignore mechanism handles this use case pretty well (see the ignore_patterns factory in http://docs.python.org/library/shutil.html) Maybe we could use the same pattern. Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw ba...@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?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote: For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. In fact, I think it /has/ to. I'll go further and say that I'm very wary of using easy_install and the like to install non-distro provided packages into the system Python. Many Linux distros require a functioning system Python to operate and the distros (should) take great care to make sure that if you install package X for application Y, you won't break essential system service Z. Once you start installing your own stuff in the system Python's site-packages, you break the warranty. Exactly: I never use easy_isntall to put packages into the system python. in fact, I only use it inside a virtalenv-generated isolated environment. What about the proposal I made about the smarter easy_install ... isn't that just enough ? -- 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? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 2:41 PM, Tarek Ziadé wrote: I think shutil.copytree new ignore mechanism handles this use case pretty well (see the ignore_patterns factory in http://docs.python.org/library/shutil.html) Maybe we could use the same pattern. That works for me! Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScvcTHEjvBPtnXfVAQLEAAP+MmMW3yzIYK5mT+YauzReV10UYFDkLhvT ALbKI6+NFKu6aMYBWe70QqXYxmau3XpZyUD6qzg32t7J2kTJfoLWRCAzv9XLv6/0 Qu33AVZ7yYasSW/tbpHeDvBYsJAM3ANjYRCI4v1G35gZ8HFgdQwEnviYNW1nB/yt 3lguOFPoT6c= =/CuU -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:47 PM, Olemis Lang ole...@gmail.com wrote: On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote: For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. In fact, I think it /has/ to. I'll go further and say that I'm very wary of using easy_install and the like to install non-distro provided packages into the system Python. Many Linux distros require a functioning system Python to operate and the distros (should) take great care to make sure that if you install package X for application Y, you won't break essential system service Z. Once you start installing your own stuff in the system Python's site-packages, you break the warranty. Exactly: I never use easy_isntall to put packages into the system python. in fact, I only use it inside a virtalenv-generated isolated environment. What about the proposal I made about the smarter easy_install ... isn't that just enough ? -- 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? I apologize but I was sending a few messages before and I didnt post them to the list ... sorry I'll do it right now ... sorry if you receive multiple copies ... :( -- 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? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] setuptools has divided the Python community
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou solip...@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-m...@lists.ubuntu.com
Original-Maintainer: Debian python-debian Maintainers
pkg-python-debian-ma...@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
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 2:43 PM, Olemis Lang 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 ? E.g. find all the doctests under foo.bar.docs Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScvc9XEjvBPtnXfVAQJT8AP/QhT6Pm4xEL+Bas96cD9waGOTcy1NIYoj kiWGGbp3VGlXrEaRqDx0f0J51IIQ+VZJMu2M2tMKGMXX4ePrLoJsEavGduN34jat KvBN43ZbIlgOFcojSmz9pSjGSUw9T7URHUavnS+psz0SipYceWbCghpML/ORtZml i+bVUwPvRFg= =9k5E -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote: For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. In fact, I think it /has/ to. I'll go further and say that I'm very wary of using easy_install and the like to install non-distro provided packages into the system Python. Many Linux distros require a functioning system Python to operate and the distros (should) take great care to make sure that if you install package X for application Y, you won't break essential system service Z. Once you start installing your own stuff in the system Python's site-packages, you break the warranty. Exactly: I never use easy_isntall to put packages into the system python. in fact, I only use it inside a virtalenv-generated isolated environment. But how each application use 'Python the interpreter' ? application = an interpreter + a list of paths + a script to run your application. Isolating everything with virtualenv or zc.buildout is a way to go, but what is really important is not where each package you use is located but how Python see and load them. So if we, for once, forget about the central site-packages and define some kind of configuration process that is run when every script is launched to decide what packages should be loaded, we could seperate python the interpreter from python the pile of packages If some kind of API + configuration file could adress this need, maybe things could be simpler. You wouldn't fight against a central site-packages or a per-user site-packages. You would have to explicitely provide it Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
{{{
[x for x in dir(pkg_resources) if all(y in x for y in ['dir',
'resource_'])]
['resource_isdir', 'resource_listdir']
BTW, under a better name, I would support putting pkg_resources in the
stdlib.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBScvdH3EjvBPtnXfVAQKDvQP7B8/POejfswQ8A+Xl4+XJQiO8xHpyPUbC
wpja12gXhamSvBxgoKnFCeTzMgdEoaeK838CR4yvn9YBM7hzJWW0seODG7JpmxGp
w9RXDaf1BuFuxdtTZ8qsoNzRtFQ0LOEh5HtnHYVcpwDHg9FMOKu4cNX19BpvrerU
xwx60X5lsfg=
=mKi4
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olemis Lang wrote: On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote: For case one, where I want to install additional functionality into my system Python interpreter forever, it would be great to have my system manage this. In fact, I think it /has/ to. I'll go further and say that I'm very wary of using easy_install and the like to install non-distro provided packages into the system Python. Many Linux distros require a functioning system Python to operate and the distros (should) take great care to make sure that if you install package X for application Y, you won't break essential system service Z. Once you start installing your own stuff in the system Python's site-packages, you break the warranty. Exactly: I never use easy_isntall to put packages into the system python. in fact, I only use it inside a virtalenv-generated isolated environment. What about the proposal I made about the smarter easy_install ... isn't that just enough ? A shared 'site-packages' directory can't possible be sane for an arbitrary number of applications: the versions / dependencies installed to satisfy one app's requirements are going to conflict eventually with those needed by another. I treat the 'system' library stuff as the provicne of the package manager, and keep my own apps in their own, isolated environments, as created by one or more of: - a separately-compiled Python - a virtualenv - zc.builtout. Note that the kind of applications I work on tend to be the sort which will run as server apps, and which will (in production) be the entire rasion d'etre for the machine they run on, which makes the cost of isolation tiny compared to the consequences of failed isolation. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJy95m+gerLs4ltQ4RApPNAJ4oMvr9fLMBvL0/zsUUNsEHXBLZPgCbB+bX AUmLUGUKJusiH5BhvAtdKy8= =Snse -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 s...@pobox.com wrote: Tres Exactly: I never use easy_isntall to put packages into the system Tres python. in fact, I only use it inside a virtalenv-generated Tres isolated environment. While standing in line for lunch today, someone (don't know his name) suggested that easy_install needs an --i-am-an-idiot flag which would have to be used to force it to install packages in to the system's space. That was Jacob Kaplan-Moss, I think. In my case, the fact that you have to type 'sudo' to make it happen is a sufficient reminder. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJy+B0+gerLs4ltQ4RAiO6AKCGE5277fUhoXYveYqY4CL8dVE7UQCeKbq8 ehCd8UJovafXT/y6dggLKWY= =OwUF -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 2:43 PM, Olemis Lang 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 ? E.g. find all the doctests under foo.bar.docs Could you explain this a little more pls ? You mean ... using doctest finders in a module (even inside a zip file ;) that's already loaded ? Sure ... else I dont understand ... -- 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? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
2009/3/26 Barry Warsaw ba...@python.org: BTW, under a better name, I would support putting pkg_resources in the stdlib. Last time I looked it was an incredibly complicated piece of code that would have to be refactored considerably before it would be maintainable by the core developers. I never did manage to get a good understanding of the code, but I expect that a lot of the complexity exists so that it works for all Python versions. The stdlib version shouldn't need this -- it should only care about providing a stable API that works with the current version. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python svn post-commit hook?
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-watch...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote: There is some clear low-hanging fruit for Greg's proposal where no trampoline or helpers are needed -- but where currently refactoring complex code containing many yield statements is cumbersome due to the nee to write each subroutine call as for x in subroutine(): yield x -- being able to replace this with yield from subroutine() is a conceptual advantage to me that is not proportional to the number of characters saved. Right - I don't object to the concept of yield from -- I'm -0 on that. What I don't like is the confusion of adding return values to generators, at least using the 'return' statement. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python svn post-commit hook?
2009/3/26 s...@pobox.com: 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-watch...@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? It's not that different: #!/bin/sh /data/repos/projects/hooks/mailer.py commit $@ /data/repos/projects/hooks/svn_buildbot.py --repository $1 --revision $2 --bbport 9020 /dev/null /data/repos/projects/hooks/svn_buildbot.py --repository $1 --revision $2 --bbport 9070 /dev/null if (svnlook changed -r $2 $1|grep peps) then touch /data/website-build/build/status/pepqueued fi -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote: 2009/3/26 Barry Warsaw ba...@python.org: BTW, under a better name, I would support putting pkg_resources in the stdlib. Last time I looked it was an incredibly complicated piece of code that would have to be refactored considerably before it would be maintainable by the core developers. I never did manage to get a good understanding of the code, but I expect that a lot of the complexity exists so that it works for all Python versions. The stdlib version shouldn't need this -- it should only care about providing a stable API that works with the current version. As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) The other significant source of complexity is dynamic management of namespace packages; specifically, trying to handle the situation where new sys.path entries (e.g. .egg files added as plugins) need to have their contents added to existing sys.modules __path__ entries. This is perhaps another feature that could be dropped from the stdlib version, given a way to interop with pkg_resources or a replacement. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote: On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 2:43 PM, Olemis Lang 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 ? E.g. find all the doctests under foo.bar.docs Could you explain this a little more pls ? You mean ... using doctest finders in a module (even inside a zip file ;) that's already loaded ? Sure ... else I dont understand ... Here's a concrete example. I have a bunch of .sql files inside the mailman.database package. Their file names encode a sort order. I want to load each one in order and apply them to my database. I'd like to be able to find all these .sql files (which are intermixed with .py files in the same package) without having to use os.listdir() because that forces the package to live on the file system. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScv4SnEjvBPtnXfVAQIVXgP/eBYSmfYHkebECPVDmCpewZVC9ydi4WdI agKW41CKPh6PwFFSq35u41KjXEIBIvAcVM9wbYy3zUieTdY+RVe2ceQM/fGILzny bsd2uLuNHMh0af2fen8JaY1DIbKfKrO3Ea4puvr7Uw1EGjN5IShA0WSgWpO5Ggs7 OKkhmXlPe0A= =sLWb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 3:14 PM, Olemis Lang wrote: On Thu, Mar 26, 2009 at 2:53 PM, Barry Warsaw ba...@python.org wrote: BTW, under a better name, I would support putting pkg_resources in the stdlib. ... or a subset of it ? or integrating its features with PEP 302 ? ... Sounds interesting to me ... /me thinking aloud ... perhaps unifying these features with loaders in standard PEP 302 is the way ... :-§ ... dont see the point of having an isolated module for doing what loaders should do ... including that there are plans to do it already ... thereby duplicating functionality in loaders and ResourceManager, and so on ... And'u ? What d'u think ? Let me clarify my position: I just want the functionality (preferably in the stdlib); I don't really care how it's spelled (except please not pkg_resource.whatever() :). Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScv4o3EjvBPtnXfVAQLDQQQAsW6so3MMUgGQHndEAkESZSIFNlyTPPtr ZfAtRcS3y1v+f6qrab7hxY+GTNKhAJnnWEtKbDwzG5NcFMttCKAJQyFr7HL1tvAA 9dbbskN3qjFtjTQ5tz/DJb87pWtFfuisWGp6DWxaUKCVOYWohXxpE/KyGj8KXjOK d+YAPJeLtDM= =Lg0j -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] notes from 2 to 3 porting session of Python Language Summit at PyCon
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
2009/3/26 Barry Warsaw ba...@python.org: Let me clarify my position: I just want the functionality (preferably in the stdlib); I don't really care how it's spelled (except please not pkg_resource.whatever() :). Agreed. My one major reservation is that conceptually, the whole pkg_resource infrastructure seems stunningly complex (at this point PJE pops up to point out that it's not, really, and I'm confusing pkg_resource with setuptools, or eggs, or some such - let's just say it makes my head hurt, and defer judgement on whether that's a comment about pkg_resource or my head :-)) What I'd really like is essentially some form of virtual filesystem access to stuff addressed relative to a Python package name, 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). I know of one or two packages that might benefit from write access (clearly not available for all loaders - zipfiles and URLs couldn't do it, but the filesystem and something like a database could...) But that's just details - the principle still applies. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
At 11:27 PM 3/26/2009 +, 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GPython?
An ars technica articla just linked to in a python-list post http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars calls the following project Google launched http://code.google.com/p/unladen-swallow/wiki/ProjectPlan (Though the project page does not really claim that.) I am sure some people here might find this interesting. I'd love to have a faster CPython, but this note: Will probably kill Python Windows support (for now). would kill merger back into mainline (for now) without one opposing being 'conservative'. If one adds type annotations so that values can be unboxed, would not Cython, etc, do even better for speedup? tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby p...@telecommunity.com wrote: At 11:27 PM 3/26/2009 +, 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. Hm, aren't you thinking of top-level package where I wrote package? I would hope that there's always at least one level of subpackage under a namespace package. Or we could make that a requirement when distributing code + data files. If it really is a common habit to have single-file modules with associated data files directly rooted under a namespace package, we could change the API to allow passing in a module and have it be interpreted as find the data as sibling files of this module. But when given a package I would still prefer that it would look inside the package. But to avoid ambiguities when something that's a module in one version but a package in another I would really prefer to avoid this. 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. Yes, I forgot to re-read PEP 302 when I wrote that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Antoine Pitrou wrote: There seems to be a misunderstanding as to how generators are used in Twisted. There isn't a global trampoline to schedule generators around. Instead, generators are wrapped with a decorator (*) which collects each yielded value (it's a Deferred object) and attaches to it a callback which resumes (using send()) the execution of the generator whenever the Deferred finally gets its value. This sounds like an architecture that was developed to work around the lack of anything like yield-from in the language. You can't expect to improve something like that by stuffing yield-from into the existing framework, because the point of yield-from is to render the framework itself unnecessary. To take full advantage of it, you need to step back and re-design the whole thing in a different way. In the case of Twisted, I expect the new design would look a lot like my generator scheduling example. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On Thu, Mar 26, 2009 at 4:33 PM, P.J. Eby p...@telecommunity.com wrote: At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote: 2009/3/26 Barry Warsaw ba...@python.org: BTW, under a better name, I would support putting pkg_resources in the stdlib. Last time I looked it was an incredibly complicated piece of code that would have to be refactored considerably before it would be maintainable by the core developers. I never did manage to get a good understanding of the code, but I expect that a lot of the complexity exists so that it works for all Python versions. The stdlib version shouldn't need this -- it should only care about providing a stable API that works with the current version. As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) The other significant source of complexity is dynamic management of namespace packages; specifically, trying to handle the situation where new sys.path entries (e.g. .egg files added as plugins) need to have their contents added to existing sys.modules __path__ entries. This is perhaps another feature that could be dropped from the stdlib version, given a way to interop with pkg_resources or a replacement. We had a pretty long discussion about this during the packages session at the language workshop today at PyCon. Tarek should probably report more extensively on this (hopefully he won't take it straight to distutils-sig) but in summary, the plan is roughly: - standardize more metadata, especially including dependencies, and APIs for accessing the metadata and dependencies - there should be an API to get metadata for a package without actually executing any of the package's installation script - this will go into the stdlib for Python 2.7 and 3.1 - it will be provided as separately downloadable backports for prior versions (maybe using a bootstrap not unlike ez_install) - keep distutils, but start deprecating certain higher-level functionality in it (e.g. bdist_rpm) - don't try to provide higher-level functionality in the stdlib, but instead let third party tools built on top of these core APIs compete It will be a while, but once this is a reality, it should be easy enough for the existing crop of tools (like setuptools, pip, zc.buildout) to be retargeted for the new API, and the benefit would be that for *consumers* of packages it doesn't matter which tool was used. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2009, at 10:07 PM, Guido van Rossum wrote: If it really is a common habit to have single-file modules with associated data files directly rooted under a namespace package, we could change the API to allow passing in a module and have it be interpreted as find the data as sibling files of this module. But when given a package I would still prefer that it would look inside the package. But to avoid ambiguities when something that's a module in one version but a package in another I would really prefer to avoid this. Yes, it should look inside a package. Very often, a data directory will be made a package through the addition of a __init__.py just so the data can be found. There are often no other py files in such data packages. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScxF/nEjvBPtnXfVAQJSrQP/UutsevR7ZL62snMQP++rb0lC8R7u5Uva KlZkYnro0Y9jzlld1CnAGxMtmzFHYvo7iwfQ6uHEzpDehwN+dqwxnkefTT42X5OT 3o3prDFSdIsBlQdC4JIUn5wxLfHR2LLEB3RL7RROmPfJmhM0+hzidsI0i9rBb84U B41I6O2+2jI= =aZ43 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPython?
On Thu, Mar 26, 2009 at 18:05, Terry Reedy tjre...@udel.edu wrote: An ars technica articla just linked to in a python-list post http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars calls the following project Google launched http://code.google.com/p/unladen-swallow/wiki/ProjectPlan (Though the project page does not really claim that.) I am sure some people here might find this interesting. I'd love to have a faster CPython, but this note: Will probably kill Python Windows support (for now). would kill merger back into mainline (for now) without one opposing being 'conservative'. Well, that's for now. It is brand new and still under active development. View it as a long term development branch. This is not about to replace CPython suddenly since work on Unladen just started. If one adds type annotations so that values can be unboxed, would not Cython, etc, do even better for speedup? Nope as Unladen is planning to re-implement the eval loop, something Cython doesn't optimize without the need to suddenly start adding type annotations to code. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Guido van Rossum wrote: I'll gladly take that as an added rationalization of my plea not to change datetime. In the case of datetime, could perhaps just the module name be changed so that it's not the same as a name inside the module? Maybe call it date_time or date_and_time. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised**8 PEP on Yield-From
On Thu, Mar 26, 2009 at 5:21 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Here's a new draft of the PEP. I've added a Motivation section and removed any mention of inlining. There is a new expansion that incorporates recent ideas, including the suggested handling of StopIteration raised by a throw() call (i.e. if it wasn't the one thrown in, treat it as a return value). Explicit finalization is performed if the delegating generator is closed, but not when the subiterator completes itself normally. Submitted to SVN. I'll try to critique later. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby p...@telecommunity.com wrote: At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote: There is some clear low-hanging fruit for Greg's proposal where no trampoline or helpers are needed -- but where currently refactoring complex code containing many yield statements is cumbersome due to the nee to write each subroutine call as for x in subroutine(): yield x -- being able to replace this with yield from subroutine() is a conceptual advantage to me that is not proportional to the number of characters saved. Right - I don't object to the concept of yield from -- I'm -0 on that. What I don't like is the confusion of adding return values to generators, at least using the 'return' statement. Well, after thinking about it some more I think I am going to have to take an executive decision and override your opposition. :-) I wasn't keen on this myself at the outset, but it's growing on me, and I am finding Greg's motivation for wanting to do it this way pretty strong. I'm +1 on yield from and +0 on return values in generators. That +0 could turn into a +1 if there was a way to flag this as an error (at runtime), at least if the return is actually executed: def g(): yield 42 return 43 for x in g(): print x# probably expected to print 42 and then 43 Perhaps the exception used in this case could be a different exception than StopIteration? Regular iteration could either just pass this exception through or explicitly check for it (a single pointer comparison could usually suffice), depending on whether it would be a subclass of StopIteration. Greg, what do you think? (There could be good reasons not to complexificate it this way too.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPython?
On Thu, Mar 26, 2009 at 8:05 PM, Terry Reedy tjre...@udel.edu wrote: An ars technica articla just linked to in a python-list post http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars calls the following project Google launched http://code.google.com/p/unladen-swallow/wiki/ProjectPlan (Though the project page does not really claim that.) Hi, I'm the tech lead for Unladen Swallow. Jeffrey Yasskin and Thomas Wouters are also working on this project. Unladen Swallow is Google-sponsored, but not Google-owned. This is an open-source branch that we're working on, focused on performance, and we want to move all of our work upstream as quickly as possible. In fact, right now I'm adding a last few tests before putting our cPickle patches up on the tracker for further review. I am sure some people here might find this interesting. I'd love to have a faster CPython, but this note: Will probably kill Python Windows support (for now). would kill merger back into mainline (for now) without one opposing being 'conservative'. To clarify, when I wrote 'conservative', I wasn't being disparaging. A resistance to change can certainly be a good thing, and something that I think is very healthy in these situations. We certainly have to prove ourselves, especially given some of the fairly radical things we're thinking of [1]. We believe we can justify these changes, but I *do* want to be forced to justify them publicly; I don't think python-dev would be doing its job if some of these things were merely accepted without discussion. In particular, Windows support is one of those things we'll need to address on our end. LLVM's Windows support may be spotty, or there may be other Windows issues we inadvertently introduce. None of the three of us have Windows machines, nor do we particularly want to acquire them :), and Windows support isn't going to be a big priority. If we find that some of our patches have Windows issues, we will certainly fix those before proposing their inclusion in CPython. If one adds type annotations so that values can be unboxed, would not Cython, etc, do even better for speedup? Possibly, but we want to see how far we can push the current language before we even start thinking of tinkering with the language spec. Assigning meaning to function annotations is something that PEP 3107 explicitly avoids, and I'm not sure Unladen Swallow (or anyone else) would want to take the plunge into coming up with broadly-acceptable type systems for Python. That would be a bikeshed discussion of such magnitude, you'd have to invent new colors to paint the thing. Collin Winter [1] - http://code.google.com/p/unladen-swallow/wiki/ProjectPlan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: I'll gladly take that as an added rationalization of my plea not to change datetime. In the case of datetime, could perhaps just the module name be changed so that it's not the same as a name inside the module? Maybe call it date_time or date_and_time. I don't think that's advisable ATM -- again, something we should have done for 3.0, but now it's too late. I really don't want to set a trend where 3.1 is backwards incompatible with 3.0 *except* in cases where we were really planning to kill something in 3.0 and accidentally forgot to quite remove it completely (like cmp()). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 10:39 PM 3/26/2009 -0500, Guido van Rossum wrote: That +0 could turn into a +1 if there was a way to flag this as an error (at runtime), at least if the return is actually executed: def g(): yield 42 return 43 for x in g(): print x# probably expected to print 42 and then 43 Perhaps the exception used in this case could be a different exception than StopIteration? Regular iteration could either just pass this exception through or explicitly check for it (a single pointer comparison could usually suffice), depending on whether it would be a subclass of StopIteration. Could we at least have some syntax like 'return from yield with 43', to distinguish it from a regular return, clarify that it's returning a value to a yield-from statement, and emphasize that you need a yield-from to call it? If it doesn't have some sort of variant syntax, the error message for the return exception is going to need to be rather verbose in order to be clear. However, if there is a variant syntax, then an error message like 'return from yield' without 'yield from' might be clear enough, and we can keep the current error for returning values in generators. That way, the paired special syntax is clearly identifiable as coroutine/microthread control flow, in a way that's both TOOOWTDI and EIBTI. One remaining quirk or missing piece: ISTM there needs to be a way to extract the return value without using a yield-from statement. I mean, you could write a utility function like: def unyield(geniter): try: while 1: geniter.next() except GeneratorReturn as v: return v.value OTOH, I suppose this function is still a trampoline, just one that doesn't actually do anything except return an eventual exit value. I suppose you could do a slightly improved one thus: def unyield(geniter, value=None, func=lambda v: v) try: while 1: value=func(geniter.send(value)) except GeneratorReturn as v: return v.value And drop it into itertools or some such. It's sort of like an all-purpose map/reduce for generators, so that all you need to do is pass in a function to do whatever processing you need (e.g. I/O waiting) on the values yielded. You could also use another generator's send() method as the function passed in, in which case you'd basically have a pair of coroutines... and whichever returned a value first would end up as the return value of the overall function. That'd probably be pretty useful for the sort of simple (non I/O) coroutines Greg seems to have in mind. Or, these could just be examples in the PEP, I suppose. They're not terribly difficult to write... but then I might be biased since I've written a ridiculous number of coroutine trampolines for Python generators over the last how-many-ever years Python has had generators. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote: You can't expect to improve something like that by stuffing yield-from into the existing framework, because the point of yield-from is to render the framework itself unnecessary. But it doesn't. You still need *something* that processes the yielded values, since practical frameworks have various things to yield to - i/o, time, mouse clicks, whatever. Correctly dealing with the call stack part is tedious to implement, sure, but it's not really the focal point of a microthreading framework. Usually, you need to have some way to control which microthreads are actually to be executing, vs. the ones that are waiting for a particular time, an I/O operation, or some other sort of event. None of that stuff goes away just by taking care of the call stack. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
Guido van Rossum wrote: Can I suggest that API this takes a glob-style pattern? Globs would be nice to have, but the minimum needed is some kind of listdir-like functionality. Globbing can be built on that if need be. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPython?
On Thu, Mar 26, 2009 at 11:40 PM, Collin Winter coll...@gmail.com wrote: In fact, right now I'm adding a last few tests before putting our cPickle patches up on the tracker for further review. Put me in the nosy list when you do; and when I get some free time, I will give your patches a complete review. I've already taken a quick look at cPickle changes you did in Unladen and I think some (i.e., the custom memo table) are definitely worthy to be merged in the mainlines. Cheers, -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
Olemis Lang wrote: ... well ... it is too long ... :-§ ... perhaps it is better this way ... --lmdtbicdfyeiwdimoweiiiapiyssiansey ... :P Isn't that the name of a town in Wales somewhere? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPython?
On Thu, Mar 26, 2009 at 11:26 PM, Alexandre Vassalotti alexan...@peadrop.com wrote: On Thu, Mar 26, 2009 at 11:40 PM, Collin Winter coll...@gmail.com wrote: In fact, right now I'm adding a last few tests before putting our cPickle patches up on the tracker for further review. Put me in the nosy list when you do; and when I get some free time, I will give your patches a complete review. I've already taken a quick look at cPickle changes you did in Unladen and I think some (i.e., the custom memo table) are definitely worthy to be merged in the mainlines. Will do, thanks for volunteering! jyasskin has already reviewed them internally, but it'll be good to put them through another set of eyes. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
P.J. Eby wrote: As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) Could you comment on why they couldn't use such an API? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: (Well here is Greg's requested use case for .send(). :-) There was a complaint that my return-value-with-send example was too much of a coroutine scenario, so I was hoping to find something un-coroutine-like. But if coroutines are the main uses for send in the first place, then it seems my example is fine as it is. BTW, I've thought of an answer as to why one would want to write a parser using send(). In the non-send() version I had to make the scanner a global variable in order to avoid passing it around among all the parsing functions. The send() technique avoids having to do either of those things. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
P.J. Eby wrote: And they *still* wouldn't be able to do away with their trampolines -- It's not really about doing away with trampolines anyway. You still need at least one trampoline-like thing at the top. What you do away with is the need for creating special objects to yield, and the attendant syntactic clumisiness and inefficiencies. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
P.J. Eby wrote: In particular, it should explain why these choices are so costly as to justify new syntax and a complex implementation: If avoiding trampolines was the only reason for yield-from, that mightn't be enough justification on its own. But it addresses several other use cases as well. The justification for yield-from is the total of all those. * decorator clearly identifying intent to create a task vs. no indication of task-ness Currently the only indication that a function is a generator rather than an ordinary function is the presence of a 'yield' buried somewhere in the body. Some people complained about that back when generators were being designed, but we seem to have gotten used to it. I don't anticipate any worse problem here. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised**8 PEP on Yield-From
Nick Coghlan wrote: Since correctly written generators are permitted to convert GeneratorExit to StopIteration, the 'yield from' expression should detect when that has happened and reraise the original exception. I'll have to think about that a bit, but you're probably right. it is also necessary to block close() in order to share an iterator. That's a typo -- I meant to say 'throw' and 'close' there, I think. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
On 26 Mar, 07:22 pm, ba...@python.org 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. Think: the package-y flavor of os.listdir(os.path.dirname(package.__file__)) FWIW, the Twisted spelling of this is: from twisted.python.modules import getModule getModule(__name__).filePath.parent().listdir() (and yes, this works with zip files) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] return from a generator [was:PEP 380 (yield from a subgenerator) comments]
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote: What I don't like is the confusion of adding return values to generators, at least using the 'return' statement. At Fri Mar 27 04:39:48 CET 2009, Guido van Rossum replied: I'm +1 on yield from and +0 on return values in generators. def g(): yield 42 return 43 for x in g(): print x# probably expected to print 42 and then 43 I still don't see why it needs to be a return statement. Why not make the intent of g explicit, by writing either def g(): yield 42 yield 43 or def g(): yield 42 raise StopIteration(43) -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: That +0 could turn into a +1 if there was a way to flag this as an error (at runtime), at least if the return is actually executed: def g(): yield 42 return 43 for x in g(): print x# probably expected to print 42 and then 43 Perhaps the exception used in this case could be a different exception than StopIteration? Would checking that the value is None be sufficient? Or do you want to distinguish between 'return' and 'return None'? That would feel rather strange to me. I'm inclined to regard this as an unnecessary complication. People are already trained to think of 'return' and 'yield' as quite different things. I don't know why they would suddenly start using 'return' when they mean 'yield'. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
