Re: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning

At 05:03 PM 8/12/2011 -0400, Glyph Lefkowitz wrote: Are there any rules about passing invalid identifiers to __import__ though, or is that just less likely? :) I suppose you have a point there. ;-) I still like the idea of a 'marker' file. It would be great if there were a new marker like

Re: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning

At 01:09 PM 8/12/2011 -0400, Glyph Lefkowitz wrote: Upon further reflection, PEP 402 _will_ make dealing with namespace packages from this code considerably easier: we won't need to do AST analysis to look for a __path__ attribute or anything gross like that improve correctness; we can just loo

Re: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning

At 02:02 PM 8/11/2011 -0400, Glyph Lefkowitz wrote: Rather than a one-by-one ad-hoc consideration of which attribute should be set to None or empty strings or "" or what have you, I'd really like to see a discussion in the PEP saying what a package really is vs. what a module is, and what one c

Re: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning

At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote: Hi, I've read PEP 402 and would like to offer comments. Thanks. Minor: I would reserve "packaging" for packaging/distribution/installation/deployment matters, not Python modules. I suggest "Python package semantics". Changing to "Python pac

Re: [Python-Dev] Import lock considered mysterious

At 02:48 PM 7/22/2011 +0200, Antoine Pitrou wrote: See http://bugs.python.org/issue9260 There's a patch there but it needs additional sophistication to remove deadlocks when doing concurrent circular imports. I don't think that approach can work, as PEP 302 loaders can currently assume the g

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 03:04 AM 7/22/2011 +0200, Antoine Pitrou wrote: The additional confusion lies in the fact that a module can be shadowed by something which is not a module (a mere global variable). I find it rather baffling. If you move x.py to x/__init__.py, it does *exactly the same thing* in current ver

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 12:59 PM 7/21/2011 -0700, Reliable Domains wrote: I assume that the implicit extend_virtual_paths() would be smart enough to only do real work if there are virtual packages to do it in, so much of the performance costs (bunch of stats) are bounded by the existence of and number of virtual pa

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 11:52 AM 7/21/2011 +1000, Nick Coghlan wrote: Trying to change how packages are identified at the Python level makes PEP 382 sound positively appealing. __path__ needs to stay :) In which case, it should be a list, not a sentinel. ;-) Even better would be for these (and sys.path) to be l

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 03:09 PM 7/20/2011 -0700, Glenn Linderman wrote: On 7/20/2011 6:05 AM, P.J. Eby wrote: At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote: When I read about creating __path__ from sys.path, I immediately thought of the issue of programs that extend sys.path, and the above is the

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 03:22 PM 7/20/2011 -0600, Eric Snow wrote: On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby wrote: > > So, yeah, actually, that's looking pretty sweet. Basically, we just have to > throw a virtual_package_paths dict into the sys module, and do the above > along with the

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 01:35 PM 7/20/2011 -0600, Eric Snow wrote: This is a really nice solution. So a virtual package is not imported until a submodule of the virtual package is successfully imported Correct... (except for direct import of pure virtual packages). Not correct. ;-) What we do is avoid creati

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 12:37 PM 7/20/2011 -0400, Erik wrote: The best solution I can think of would be to have a way for a module to mark itself as "finalized" (I'm not sure if that's the best term--just the first that popped into my head). This would prevent its __path__ from being created or extended in any way.

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 08:56 AM 7/20/2011 -0700, Jeff Hardy wrote: On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby wrote: > The biggest likely exception to the above would be when a piece of > code tries to check whether some package is installed by importing > it. If this is done *only* by importing a top-lev

Re: [Python-Dev] [Python-checkins] peps: Restore whitespace characters lost via email transmission.

At 04:21 PM 7/20/2011 +0200, Éric Araujo wrote: FYI, reST uses three-space indents, not four (so that blocks align nicely under the leading two dots + one space), so I think the change was intentional. The “Documenting Python” guide tells this (in the standard docs), and I think it applies

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 10:40 AM 7/20/2011 -0400, Neal Becker wrote: I wonder if this fixes the long-standing issue in OS vendor's distributions. In Fedora, for example, there is both arch-specific and non-arch directories: /usr/lib/python2.7 + /usr/lib64/python2.7, for example. Pure python goes into /usr/lib/pyt

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote: When I read about creating __path__ from sys.path, I immediately thought of the issue of programs that extend sys.path, and the above is the "workaround" for such programs. but it requires such programs to do work, and there are a lot of suc

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote: On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote: > So, without further ado, here it is: I pushed this version up to the PEPs repo, so it now has a number (402) and can be read in prettier HTML format: http://www.python.org/dev/peps/pep-0

[Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

sion: $Revision$ Last-Modified: $Date$ Author: P.J. Eby Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Jul-2011 Python-Version: 3.3 Post-History: Replaces: 382 Abstract This PEP proposes an enhancement to Python's package importing to: * Surprise users of o

Re: [Python-Dev] EuroPython Language Summit report

At 12:32 PM 6/25/2011 -0400, R. David Murray wrote: So your proposed code would allow me, when writing a generator in my code, do something that would allow me to yield up all the values from an arbitrary generator I'm calling, over which I have no control (ie: I can't modify its code)? With a

Re: [Python-Dev] EuroPython Language Summit report

At 10:46 AM 6/25/2011 +1000, Nick Coghlan wrote: Indeed, PEP 380 is *really* hard to do properly without language support. No, it isn't. You add a decorator, a 'from_' class, and a 'return_' function, and there you go. (See my previous code sketches here in early PEP 380 discussions.) Pyt

Re: [Python-Dev] Python 3.x and bytes

At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote: On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it wor

Re: [Python-Dev] Python 3.x and bytes

At 03:11 PM 6/13/2011 -0700, Ethan Furman wrote: Nick Coghlan wrote: > Agreed, but: > > EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\rCDFILMN' > > is a shorter way to write the same thing. > > Going two per line makes it easier to mentally map the characters: > > EOH, CHAR = b'\rC' > D

Re: [Python-Dev] Python jails

At 06:23 PM 6/10/2011 -0600, Sam Edwards wrote: I have a couple remaining issues that I haven't quite sussed out: [long list of questions deleted] You might be able to answer some of them by looking at this project: http://pypi.python.org/pypi/RestrictedPython Which implements the necessary

Re: [Python-Dev] python and super

At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretica

Re: [Python-Dev] PEP 396, Module Version Numbers

At 03:24 PM 4/10/2011 +, exar...@twistedmatrix.com wrote: On 04:02 am, p...@telecommunity.com wrote: At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: This is an often-overlooked case, I think. The unspoken assumption is often that ``setup.py`` is a suitable place for the overall version strin

Re: [Python-Dev] PEP 396, Module Version Numbers

At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: This is an often-overlooked case, I think. The unspoken assumption is often that ``setup.py`` is a suitable place for the overall version string, but this is not the case when that string must be read by non-Python programs. If you haven't used the

Re: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP, CONTINUE_LOOP

At 08:25 AM 3/12/2011 -0500, Eugene Toder wrote: Right, I'm not suggesting to remove all blocks, only SETUP_LOOP blocks. Do you see the problem in that case? I think you guys are forgetting about FOR_ITER, listcomps, and the like. That is, IIRC, the reason loops use the block stack is because

Re: [Python-Dev] PEP 395: Module Aliasing

At 05:35 PM 3/4/2011 +, Michael Foord wrote: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Er, what? That's news to me. Could you file a bug report about what doesn't work, specifically? ___

Re: [Python-Dev] PEP 3333: wsgi_string() function

At 09:43 AM 1/7/2011 -0500, James Y Knight wrote: On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: > I don't understand why you are attached to this horrible hack > (bytes-in-unicode). It introduces more work and more confusing than > using raw bytes unchanged. > > It doesn't work and so somethi

Re: [Python-Dev] PEP 3333: wsgi_string() function

At 04:00 PM 1/6/2011 -0800, Raymond Hettinger wrote: Can you please take a look at http://docs.python.org/dev/whatsnew/3.2.html#pep--python-web-server-gateway-interface-v1-0-1 to see if it accura

Re: [Python-Dev] PEP 3333: wsgi_string() function

At 03:44 AM 1/4/2011 +0100, Victor Stinner wrote: Hi, In the PEP , I read: -- import os, sys enc, esc = sys.getfilesystemencoding(), 'surrogateescape' def wsgi_string(u): # Convert an environment variable to a WSGI "bytes-as-unicode" string return u.encode(enc, esc).dec

Re: [Python-Dev] ICU

At 07:47 AM 12/2/2010 -0800, Guido van Rossum wrote: On Wed, Dec 1, 2010 at 8:45 PM, Alexander Belopolsky wrote: > On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou wrote: >> >> Oh, about ICU: >> >>> > Actually, I remember you saying that locale should ideally be replaced >>> > with a wrapper a

Re: [Python-Dev] constant/enum type in stdlib

At 11:31 AM 11/23/2010 -0500, Barry Warsaw wrote: On Nov 23, 2010, at 03:15 PM, Michael Foord wrote: >(Well, there is a third option that takes __name__ and sets the constants in >the module automagically. I can understand why people would dislike that >though.) Personally, I think if you want

Re: [Python-Dev] Issue 10194 - Adding a gc.remap() function

At 10:24 AM 10/26/2010 -0700, Peter Ingebretson wrote: I have a relatively large application written in Python, and a specific use case where it will significantly increase our speed of iteration to be able to change and test modules without needing to restart the application. If all you really

Re: [Python-Dev] Exposing pkguitl's import emulation (was Re: [Python-checkins] r85538 - python/branches/py3k/Doc/library/pkgutil.rst)

At 08:03 AM 10/18/2010 +1000, Nick Coghlan wrote: I'm a little dubious about exposing these officially. They're mainly a hack to get some parts of the standard library working (e.g. runpy) in the absence of full PEP 302 support in the imp module, not really something we want to encourage anyone e

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby wrote: > At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: >> >> On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote: >> > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrot

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote: > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: >> >> All fixed. > > Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but > python.org still d

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. ___ Python-Dev mailing list Python-De

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 01:22 PM 9/27/2010 -0400, Terry Reedy wrote: On 9/26/2010 9:38 PM, P.J. Eby wrote: At 11:15 AM 9/27/2010 +1000, Ben Finney wrote: You misunderstand me; I wasn't asking how to *add* a link, but how to turn OFF the automatic conversion of the phrase "PEP 333" that happ

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 11:15 AM 9/27/2010 +1000, Ben Finney wrote: "P.J. Eby" <<http://mail.python.org/mailman/listinfo/python-dev>pje at telecommunity.com> writes: > (For that matter, if anybody knows how to make it not turn *every* PEP > reference into a link, that'd be go

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 02:59 PM 9/26/2010 -0400, Terry Reedy wrote: You could mark added material is a way that does not conflict with rst or html. Or use .rst to make new text stand out in the .html web verion (bold, underlined, red, or whatever). People familiar with 333 can focus on the marked sections. New rea

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

-- maybe mark up the differences in PEP so people can easily tell what was added. And move PEP 333 to Final status. --Guido On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby wrote: > At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote: >> >> On Sun, Sep 26, 2010 at 12:47 PM, Barry Wa

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote: On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw wrote: > On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote: > >> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote: >>> I'm happy approving Final status for the >>&g

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote: I'm happy approving Final status for the *original* PEP 333 and I'm happy to approve a new PEP which includes PJE's corrections. Can we make it PEP , then? ;-) That number would at least communicate that it's the same thing, but for Py

Re: [Python-Dev] WSGI is now Python 3-friendly

At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote: Don't see this as a new spec. See it as a procedural issue. As a procedural issue, PEP 333 is an Informational PEP, in "Draft" status, which I'd like to make Final after these amendments. See http://www.wsgi.org/wsgi/Amendments_1.0, which

Re: [Python-Dev] WSGI is now Python 3-friendly

At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote: This is a very laudable initiative and I approve of the changes -- but I really think it ought to be a separate PEP rather than pretending it is just a set of textual corrections on the existing PEP 333. With the exception of the bytes change

Re: [Python-Dev] WSGI is now Python 3-friendly

At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote: It seems like it will end up different enough to be a different specification, closely related to the original, but different enough to trip up all the people maintaining current WSGI servers and apps. The only actual *change* to the spec is mand

[Python-Dev] WSGI is now Python 3-friendly

I have only done the Python 3-specific changes at this point; the diff is here if anybody wants to review, nitpick or otherwise comment: http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014&r2=85013&pathrev=85014 For that matter, if anybody wants to take a crack at updating Python 3'

Re: [Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote: On Tue, 21 Sep 2010 12:09:44 -0400 "P.J. Eby" wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a good idea to have a backup plan that would allow the Python 3 > stdlib to move forward, with

Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote: On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough <<mailto:chr...@plope.com>chr...@plope.com> wrote: On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a

[Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

While the Web-SIG is trying to hash out PEP 444, I thought it would be a good idea to have a backup plan that would allow the Python 3 stdlib to move forward, without needing a major new spec to settle out implementation questions. After all, even if PEP 333 is ultimately replaced by PEP 444,

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

At 06:06 PM 9/18/2010 +0200, Martin v. Löwis wrote: Am 18.09.10 17:49, schrieb P.J. Eby: At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote: In the specific case of tl.eggdeps, the dependency information is only used to create printable graphs. If this turns out to be slightly incorrect

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote: In the specific case of tl.eggdeps, the dependency information is only used to create printable graphs. If this turns out to be slightly incorrect, people would notice if they try to use the packages in question. By the way, just providing t

Re: [Python-Dev] 3.x as the official release

At 10:18 PM 9/16/2010 +0200, Éric Araujo wrote: Le 15/09/2010 21:45, Tarek Ziadé a écrit : > Could we remove in any case the wsgiref.egg-info file ? Since we've > been working on a new format for that (PEP 376), that should be > starting to get used in the coming years, it'll be a bit of a >

Re: [Python-Dev] standards for distribution names

At 12:08 PM 9/16/2010 +0100, Chris Withers wrote: ...I'd thought that the "correct names" for distributions would have been documented in one of: http://www.python.org/dev/peps/pep-0345 http://www.python.org/dev/peps/pep-0376 http://www.python.org/dev/peps/pep-0386 ...but having read them, I d

Re: [Python-Dev] standards for distribution names

At 12:08 PM 9/16/2010 +0100, Chris Withers wrote: Following on from this question: http://twistedmatrix.com/pipermail/twisted-python/2010-September/022877.html ...I'd thought that the "correct names" for distributions would have been documented in one of: ... Where are the standards for thi

Re: [Python-Dev] PEP 444 aka "Web3" (was Re: how to decide on a Python 3 design for wsgiref)

At 09:22 AM 9/16/2010 +1000, James Mills wrote: On Thu, Sep 16, 2010 at 9:06 AM, Chris McDonough wrote: > Comments and competing specs would be useful. Can I post comments here ? :) Please, let's put any spec-detail commentary on the Web-SIG instead (commenting here on process issues related

Re: [Python-Dev] 3.x as the official release

At 11:50 PM 9/15/2010 +0200, Dirkjan Ochtman wrote: On Wed, Sep 15, 2010 at 21:18, P.J. Eby wrote: > If I were to offer a suggestion to a PEP author or dictator wanting to get > something out ASAP, it would probably be to create a compromise between the > "flat" model (my per

Re: [Python-Dev] 3.x as the official release

At 11:12 PM 9/15/2010 +0200, Éric Araujo wrote: Unless I remember wrong, the intent was not to break code that used pkg_resources.require('wsgiref') More precisely, at the time it was done, setuptools was slated for inclusion in Python 2.5, and the idea was that when modules moved from PyPI

Re: [Python-Dev] 3.x as the official release

At 11:11 AM 9/15/2010 -0700, Guido van Rossum wrote: Given that wsgiref is in the stdlib, I think we should hold up the 3.2 release (and even the first beta) until this is resolved, unless we can convince ourselves that it's okay to delete wsgiref from the stdlib (which sounds unlikely but may no

Re: [Python-Dev] 'hasattr' is broken by design

At 08:58 PM 8/25/2010 +0300, Michael Foord wrote: If your proxy class defines __call__ then callable returns True, even if the delegation to the proxied object would cause an AttributeError to be raised. Nope. You just have to use delegate via __getattribute__ (since 2.2) instead of __getatt

Re: [Python-Dev] 'hasattr' is broken by design

At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote: Consider an object that is trying to be a transparent proxy for another object, and behave as much as possible as though it really were the other object. Should an attribute statically defined on the proxied object be considered dynamically defined o

Re: [Python-Dev] 'hasattr' is broken by design

At 10:13 AM 8/24/2010 -0500, Benjamin Peterson wrote: 2010/8/24 James Y Knight : > > On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote: > >> 2010/8/24 P.J. Eby : >>> >>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: >>>> >>>

Re: [Python-Dev] 'hasattr' is broken by design

At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and FYI, best practice for __getattr__ is generally to bail with an AttributeError as soon as you see

Re: [Python-Dev] 'hasattr' is broken by design

At 06:12 PM 8/23/2010 -0400, Yury Selivanov wrote: BTW, is it possible to add new magic method __hasattr__? Maybe not in Python 3.2, but in general. In order to do this properly, you'd need to also add __has__ or __exists__ (or some such) to the descriptor protocol; otherwise you break descr

Re: [Python-Dev] 'hasattr' is broken by design

At 12:02 AM 8/24/2010 +0300, Michael Foord wrote: For properties there is *no reason* why code should be executed merely in order to discover if the attribute exists or not. That depends on what you mean by "exists". Note that a property might raise AttributeError to signal that the attribute

Re: [Python-Dev] 'hasattr' is broken by design

At 12:47 PM 8/23/2010 -0700, Raymond Hettinger wrote: As your example shows, property() defeats this intent by actually executing the code. A better behavior would not run the code at all. It would check the dictionaries along the MRO but not execute any descriptors associated with a given key

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote: If you look at the proposal, it is really just about adding a new data store to manage a certain package type called "plugins". Next time around, someone will want to see support for "skins" or "themes". Then perhaps identify "script" packages, or

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote: Since you are into comparing numbers, you might want to count the number of Zope plugins that are available on PyPI and its plugin system has been around much longer than setuptools has been. I don't think that proves anything, though. Actually,

Re: [Python-Dev] PEP 382 progress: import hooks

At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote: On Fri, Jul 23, 2010 at 09:54, P.J. Eby <<mailto:p...@telecommunity.com>p...@telecommunity.com> wrote: At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote: On Thu, Jul 22, 2010 at 19:19, P.J. Eby <<mailto:p...@t

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote: If that's the case, then it would be better to come up with an idea of how to make access to that meta-data available in a less I/O intense way, e.g. by having pip or other package managers update a central SQLite database cache of the data found o

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 09:03 PM 8/2/2010 +0100, Michael Foord wrote: Ouch. I really don't want to emulate that system. For installing a plugin for a single project the recommended technique is: * Unpack the source. It should provide a setup.py. * Run: $ python setup.py bdist_egg Then you wil

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 05:08 PM 8/2/2010 +0200, Éric Araujo wrote: I wonder if functions in pkgutil or importlib could allow one to iterate over the plugins (i.e. submodules and subpackages of the namespace package) without actually loading then. See pkgutil.walk_packages(), available since 2.5. It has to load

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 01:10 PM 8/2/2010 +0200, Tarek Ziadé wrote: I don't have a specific example in mind, and I must admit that if an application does the right thing (provide the right configuration file), this activate feature is not useful at all. So it seems to be a bad idea. Well, it's not a *bad* idea as s

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 01:53 PM 8/2/2010 +, exar...@twistedmatrix.com wrote: On 01:27 pm, m...@egenix.com wrote: exar...@twistedmatrix.com wrote: This is also roughly how Twisted's plugin system works. One drawback, though, is that it means potentially executing a large amount of Python in order to load plugi

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

At 09:24 PM 8/1/2010 -0700, Guido van Rossum wrote: I don't understand all the details and corner cases (e.g. the concatenation of stacks It's just to ensure that you never have From's iterating over other From's, vs. just iterating whatever's at the top of the stack. which seems to have t

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote: but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to dis

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

At 08:49 AM 8/1/2010 -0400, Kevin Jacobs wrote: On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: I have updated my prototype yield-from implementation to work with Python 3.1.2. My work is primarily on the management and analy

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote: .. > * Registration - How do third party plugins declare themselves to exist, and > be enabled? Part of this seems to me to include interface declarations > too. Is installation of the plug

Re: [Python-Dev] unexpected import behaviour

At 11:50 PM 7/30/2010 +0400, Oleg Broytman wrote: On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote: > can anyone think of a case where someone has > been annoyed that, having imported that same module twice via > symlinks, they have had problems relating to modules being independ

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

At 03:34 PM 7/30/2010 +0100, Michael Foord wrote: Automatic discoverability, a-la setuptools entry points, is not without its problems though. Tarek outlines some of these in a more recent blog post: FWIW, it's not discovery that's the problem, but configuring *which* plugins you wish to have

Re: [Python-Dev] Thoughts fresh after EuroPython

At 04:29 PM 7/25/2010 +1000, Nick Coghlan wrote: So, while I can understand Guido's temptation (PEP 380 *is* pretty cool), I'm among those that hope he resists that temptation. Letting these various ideas bake a little longer without syntactic support likely won't hurt either. Well, if somebody

Re: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)

At 08:21 PM 7/24/2010 -0700, Guido van Rossum wrote: FWIW, the thing that was harder to debug when I tried to write some code involving generators and a trampoline recently, was thinking of a function as a generator without actually putting a yield in it (because a particular version of a corouti

Re: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)

At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote: - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it coul

Re: [Python-Dev] PEP 382 progress: import hooks

At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote: On Thu, Jul 22, 2010 at 19:19, P.J. Eby <<mailto:p...@telecommunity.com>p...@telecommunity.com> wrote: What does "is not a package" actually mean in that context? The module is a module but not a package. Um...

Re: [Python-Dev] PEP 382 progress: import hooks

At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote: At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks. Basically, a fin

Re: [Python-Dev] bytes / unicode

At 03:53 PM 6/27/2010 +1000, Nick Coghlan wrote: We could talk about this even longer, but the most effective way forward is going to be a patch that improves the URL parsing situation. Certainly, it's the only practical solution for the immediate problems in 3.2. I only mentioned that I "hate

Re: [Python-Dev] bytes / unicode

At 12:43 PM 6/27/2010 +1000, Nick Coghlan wrote: While full support for third party strings and byte sequence implementations is an interesting idea, I think it's overkill for the specific problem of making it easier to write str/bytes agnostic functions for tasks like URL parsing. OTOH, to wri

Re: [Python-Dev] bytes / unicode

At 12:42 PM 6/26/2010 +0900, Stephen J. Turnbull wrote: What I'm saying here is that if bytes are the signal of validity, and the stdlib functions preserve validity, then it's better to have the stdlib functions object to unicode data as an argument. Compare the alternative: it returns a unicode

Re: [Python-Dev] bytes / unicode

At 01:18 AM 6/26/2010 +0900, Stephen J. Turnbull wrote: It seems to me what is wanted here is something like Perl's taint mechanism, for *both* kinds of strings. Am I missing something? You could certainly view it as a kind of tainting. The part where the type would be bytes-based is indeed

Re: [Python-Dev] bytes / unicode

At 04:49 PM 6/25/2010 +0900, Stephen J. Turnbull wrote: P.J. Eby writes: > This doesn't have to be in the functions; it can be in the > *types*. Mixed-type string operations have to do type checking and > upcasting already, but if the protocol were open, you could make an &

Re: [Python-Dev] bytes / unicode

At 05:12 PM 6/24/2010 +0900, Stephen J. Turnbull wrote: Guido van Rossum writes: > For example: how we can make the suite of functions used for URL > processing more polymorphic, so that each developer can choose for > herself how URLs need to be treated in her application. While you have co

Re: [Python-Dev] bytes / unicode

At 08:34 PM 6/22/2010 -0400, Glyph Lefkowitz wrote: I suspect the practical problem here is that there's no CharacterString ABC That, and the absence of a string coercion protocol so that mixing your custom string with standard strings will do the right thing for your intended use.

Re: [Python-Dev] bytes / unicode

At 07:41 AM 6/23/2010 +1000, Nick Coghlan wrote: Then my example above could be made polymorphic (for ASCII compatible encodings) by writing: [x for x in seq if x.endswith(x.coerce("b"))] I'm trying to see downsides to this idea, and I'm not really seeing any (well, other than 2.7 being almos

Re: [Python-Dev] email package status in 3.X

At 04:04 PM 6/21/2010 -0400, Barry Warsaw wrote: On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote: >OTOH, one potential problem with having the encoding on the bytes object >rather than the ebytes object is that then you can't easily take bytes from a >socket and then say what enc

Re: [Python-Dev] email package status in 3.X

At 03:29 PM 6/21/2010 -0400, Toshio Kuratomi wrote: On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote: > At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote: > >What do you think of making the encoding attribute a mandatory part of > >creating an ebyte object? (ex: ``eb =

Re: [Python-Dev] email package status in 3.X

At 03:08 AM 6/22/2010 +0900, Stephen J. Turnbull wrote: Barry Warsaw writes: > Would it make sense to have "encoding-carrying" bytes and str > types? I think the answer is "no", though, because (1) it would constitute an attractive nuisance (the default would be abused, it would work fine in

Re: [Python-Dev] email package status in 3.X

At 02:58 AM 6/22/2010 +0900, Stephen J. Turnbull wrote: Nick alluded to the The One Obvious Way as a change in architecture. Specifically: Decode all bytes to typed objects (str, images, audio, structured objects) at input. Do no manipulations on bytes ever except decode and encode (both to tex

Re: [Python-Dev] email package status in 3.X

At 01:36 PM 6/21/2010 -0400, Terry Reedy wrote: On 6/21/2010 11:43 AM, Barry Warsaw wrote: This is probably a stupid idea, and if so I'll plead Monday morning mindfuzz for it. Would it make sense to have "encoding-carrying" bytes and str types? On 2009-11-5 I posted 'Add encoding attribute t

Re: [Python-Dev] bytes / unicode

At 10:29 AM 6/21/2010 -0700, Guido van Rossum wrote: Perhaps there are more situations where a polymorphic API would be helpful. Such APIs are not always so easy to implement, because they have to be careful with literals or other constants (and even more so mutable state) used internally -- but

  1   2   3   >