Re: [Python-Dev] 2.6 object.__init__ & deling __new__

At 04:11 PM 7/14/2009 -0500, Benjamin Peterson wrote: 4. When __init__() is overridden, and the subclass __init__() calls object.__init__(), the latter should complain about excess arguments; ditto for __new__(). Actually, this rule is a PITA, because there's no good way to get rid

Re: [Python-Dev] 2.6 object.__init__ & deling __new__

At 07:29 PM 7/15/2009 +1200, Greg Ewing wrote: P.J. Eby wrote: In effect, 2.6 forces you to have a common known base class *other* than 'object' in order to write co-operative classes. :-( You have to do that anyway if you want to make cooperative calls to any method *other* tha

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 11:10 AM 7/15/2009 +0100, Paul Moore wrote: I propose that before the current prototype is turned into a final (spec and) implementation, the PEP 302 extensions are extracted and documented as an independent protocol, purely part of PEP 376. (This *helps* implementers, as they can write suppor

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 04:14 PM 7/15/2009 +0100, Paul Moore wrote: Look - I really, really don't mind if people use setuptools. Honest. But I do mind if core python gets changed to support little bits of what setuptools does, adding complexity to deal with issues that setuptools handles, but without making it possib

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 05:16 PM 7/15/2009 +0200, Joachim König wrote: f you have m different versions of n packages then you could have n**m different combinations for an application so you need a possiblilty to select one combination from n**m possible ones at application startup time. Is this really worth it? Ob

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 04:59 PM 7/15/2009 +0100, Paul Moore wrote: - Virtualenv isn't a workaround (I don't know virtualenv, I'll take your word for it) It's not one for system package maintainers because it would effectively be managing multiple instances of 'python'. Really not a suitable solution. - I do

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 07:07 PM 7/15/2009 +0200, Tarek Ziadé wrote: Part of the rejection of setuptools is because of that and because you don't bless anyone to maintain the project code base, or do releases, neither to communicate clearly on what's its roadmap. Jim Fulton and Ian Bicking have been official

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 06:40 PM 7/15/2009 +0100, Paul Moore wrote: And of course, someone has to do the clean-up. It seems to me that the fact that people are more inclined to reinvent the code than to try to understand the existing codebase and pick out the relevant bits, says something important about how easy it

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]

At 04:07 PM 7/18/2009 -0400, Jim Jewett wrote: Michael Foord wrote: >> I agree. People with versioning issues *should* be using virtualenv. Tarek Ziadé replied (and several people later agreed) > Let's remove site-packages from Python then. What about those people *without* versioning issues?

Re: [Python-Dev] Update to Python Documentation Website Request

At 08:09 PM 7/24/2009 -0400, David Lyon wrote: Presently it used pkg_resources to read the list of packages installed which is part of setuptools. I was told it was the "right" and only way to read a list of packages. "Right" is relative, but right now it is certainly the *only* way to read a

Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote: [Jeffrey E. McAninch, PhD] I very often want something like a try-except conditional expression similar to the if-else conditional. An example of the proposed syntax might be: x = float(string) except float('nan') or possibly x = float(

Re: [Python-Dev] Excluding the current path from module search path?

At 04:59 PM 8/25/2009 +0100, Chris Withers wrote: Hi All, I'm being bitten by this issue: http://bugs.python.org/issue1734860 I'm not sure I agree with Daniel's closing of it so thought I'd ask here... Am I right in thinking that the general idea is that "the current working directory at the

Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

At 09:33 AM 8/31/2009 -0700, Guido van Rossum wrote: Of course, tracking down all the code objects in the return value of marshal.load*() might be a bit tricky -- API-wise I still think that making it an argument to marshal.load*() might be simpler. Also it would preserve the purity of code objec

Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

At 01:39 PM 8/31/2009 -0700, Brett Cannon wrote: On Mon, Aug 31, 2009 at 12:59, Brett Cannon wrote: > On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou wrote: >> Brett Cannon python.org> writes: >>> >>> I will plan to take this approach then; >>> http://bugs.python.org/issue6811 will track all of th

Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

At 02:57 PM 8/31/2009 -0700, Brett Cannon wrote: Ignoring that 'new' is not in Python 3.x (luckily 'types' is), I want a proper solution that doesn't require reconstructing every code object that I happen to import. Practicality beats purity. ;-) (Especially if it allows importlib to run on

Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?

At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote: Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. Both classm

Re: [Python-Dev] clarification on PEP 3124 status

At 08:29 AM 9/13/2009 +0200, Martin v. Löwis wrote: > Could somebody please clarify the status of PEP 3124? At > http://ftp.python.org/dev/peps/ , it is listed as "under > consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it > has been deferred. This isn't really contradictory. "

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote: Hello Here's a wrapup of the Distutils-SIG discussion we had on the "static metadata" topic. I realize that it's a good thing to send in. python-dev such wrapup on distutils design decisions, to keep everyone informed and get more feedback when re

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

At 08:12 PM 9/22/2009 +0200, Tarek Ziadé wrote: If you are talking about another solution than using setup.cfg with conditional expressions, please start a new thread that demonstrates how it will work, we all want the best solution of course. I already did that, on the distutils-sig. Or more

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

At 02:20 PM 9/23/2009 +0200, Tarek Ziadé wrote: If you take the time to read everything you'll see that there were no real alternative design proposed, You did not respond to repeated requests (from more than one person), for clarification regarding the requirements that your proposal was try

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote: While it's great to have Philipp being part of our distutils design discussions, for his experience, I am not concerned of not having him in this "internal consensus" since Setuptools is not maintained anymore. He said some months ago, he would wor

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

r python 3. So let me make it clear that when you say "Tarek appears" it is something I have never said but rather something you are thinking like being the truth. Now for the Distribute work , your patches are very welcome. It s a community project. On Sep 23, 2009 10:47 PM, "

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

At 07:05 PM 9/23/2009 -0700, Guido van Rossum wrote: On Wed, Sep 23, 2009 at 6:57 PM, P.J. Eby wrote: > Once again, I'd like for the badgering to stop. Thanks. Tarek already agreed to that ("Fine with me. Let's move forward"). I hope you will stop badgering him too.

[Python-Dev] "PIL" vs. "Imaging" (was Re: eggs now mandatory for pypi?)

At 01:26 PM 10/5/2009 +0200, Jens W. Klein wrote: And as far as I understand PIL is not the problem, but the packaging/ setuptools. For the records: PIL is a great piece of software and I dont want to miss it. Actually, the problem is that the package is called "PIL" in Pypi, but the actual in

Re: [Python-Dev] Package install failures in 2.6.3

At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote: Setuptools development has been discontinued for a year, and does patches on Distutils code. Some of these patches are sensitive to any change made on Distutils, wether those changes are internal or not. Setuptools is also not the only thing out

Re: [Python-Dev] Package install failures in 2.6.3

At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. Subclassing is not monkeypatching, so if you consider the above to be a gen

Re: [Python-Dev] Package install failures in 2.6.3

At 11:21 AM 10/5/2009 -0700, Brett Cannon wrote: I have to admit I find it really disheartening that we are letting an unmaintained project dictate how we fix a bug. Setuptools was not the only project broken by this change. See: http://bugs.python.org/issue7020#msg93355 Apparently, I'm no

Re: [Python-Dev] Package install failures in 2.6.3

At 08:22 PM 10/5/2009 +0100, Michael Foord wrote: I'm intrigued as to whether setuptools does monkey patch distutils or subclass though, they are fundamentally different concepts. It does both; however, the specific issue under discussion is purely a subclassing problem, and one which pywin32

Re: [Python-Dev] comments vs spam in PyPI [was: eggs now mandatory for pypi?]

At 01:43 PM 10/6/2009 +0900, Stephen J. Turnbull wrote: IMO it would be better to design developer-specific mechanisms rather than a generic commenting vehicle, cf. Fred Drake's thinking. For example, having a packages reddit (nb: open source, written in Python), where people can upvote or dow

Re: [Python-Dev] eggs now mandatory for pypi?

At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote: Note how the package name is mangled... easy_install requires this. The file name also doesn't tell you that the above is for a UCS2 Python build. Again, easy_install fails with that information added to the "py2.6" version marker. Btw, every co

Re: [Python-Dev] a new setuptools release?

At 02:45 PM 10/6/2009 +0100, Chris Withers wrote: To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.

Re: [Python-Dev] eggs now mandatory for pypi?

At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote: Chris Withers wrote: > Well yeah, and the only sane way I can think to handle this is to have a > metadata file that gets uploaded with each distribution that covers all > these things (and the other things that other people need) and then have >

Re: [Python-Dev] a new setuptools release?

At 12:16 PM 10/6/2009 -0700, Guido van Rossum wrote: I think at this point the community should not be forced wait for you to get a new supply of round tuits. The wait has been too long already. You can stay on in an advisory role, but I don't think it's reasonable to block development or decisio

Re: [Python-Dev] a new setuptools release?

At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote: suggest nobody hold their breath waiting for setuptools 0.7. I've never suggested or implied otherwise. But, if you like Distribute so much, why not just add it directly to the stdlib? ;-) AFAIK, the only reason they've had multiple rele

Re: [Python-Dev] eggs now mandatory for pypi?

At 10:17 PM 10/6/2009 +0200, M.-A. Lemburg wrote: P.J. Eby wrote: > At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote: >> It goes a bit in the direction of what we had in mind with writing >> for our clients: a tool that looks at the Python installation and >> automati

Re: [Python-Dev] a new setuptools release?

being sarcastic or ironic, you are mistaken. At 01:22 PM 10/7/2009 -0400, Scott Dial wrote: P.J. Eby wrote: > At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote: >> suggest nobody hold their breath waiting for setuptools 0.7. > > I've never suggested or implied otherwise. >

Re: [Python-Dev] a new setuptools release?

At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip. Note that both PyPM and pip use setuptools as an important piece of their implementation (as does bui

Re: [Python-Dev] a new setuptools release?

At 08:23 PM 10/7/2009 +, Vinay Sajip wrote: P.J. Eby writes: > * Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6 I'm new to this particular discussion so feel free to correct me if I'm wrong, but ISTM that Distribute 0.6.x differs markedly from setup

Re: [Python-Dev] a new setuptools release?

At 10:46 PM 10/7/2009 +0200, M.-A. Lemburg wrote: P.J. Eby wrote: > At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: >> Having more competition will also help, e.g. ActiveState's PyPM looks >> promising (provided they choose to open-source it) and then there's >&g

Re: [Python-Dev] On track for Python 2.6.4 final this Sunday?

At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: Are we on track to release 2.6.4 final this Sunday or do we need another rc? Yesterday, Tarek committed another setuptools related fix and said that he was going to run a bunch of build tests locally. Tarek, how did that go? FWIW, that change

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

At 05:16 PM 10/13/2009 +0200, Tarek Ziadé wrote: Yes the doctest was pretty fuzzy about what is an extension name. It's will be improved in 2.7. The current code is doing os.path.join()'s to join the Extension name with the build path, leading to the collateral damage you are mentioning. To fix

Re: [Python-Dev] On track for Python 2.6.4 final this Sunday?

At 05:42 PM 10/13/2009 +0200, M.-A. Lemburg wrote: FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

At 12:51 AM 11/4/2009 -0500, Glyph Lefkowitz wrote: With the 2.x series, users and operating systems seem to move on fairly rapidly, because dependencies generally continue to work if you upgrade just one version. This isn't quite as formal a requirement as I would like (warnings get generated,

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

At 11:27 PM 11/4/2009 +, Floris Bruynooghe wrote: You have time to read this thread but no time to read "What's New In Python 3"? Given that the average developer using tons of existing libraries on 2.x is unlikely to see any killer benefits in moving to 3.x, it's a natural attitude t

Re: [Python-Dev] PyPI front page

At 08:33 PM 11/12/2009 -0500, Ian Bicking wrote: On Thu, Nov 12, 2009 at 7:52 PM, Antoine Pitrou <solip...@pitrou.net> wrote: Ben Finney benfinney.id.au> writes: > > There's a problem with the poll's placement: on the front page of the > PyPI

Re: [Python-Dev] PyPI comments and ratings, *really*?

At 09:45 AM 11/14/2009 +0100, Martin v. Löwis wrote: Paul Moore wrote: > 2009/11/13 Tres Seaver : >> I can see the information about the poll, and a link to view the >> results, without logging in. >> >> http://pypi.python.org/pypi >> >> (second paragraph there). That paragraph tells you that y

Re: [Python-Dev] PyCon Keynote

At 03:15 PM 1/26/2010 +1100, David Lyon wrote: With all due respect, that process is a bit like a black magic approach. Maybe the capability is there, but it isn't very well documented and it isn't obvious. I don't see what's so hard about: 1. Zip up your application in myapp.zip with a __main

Re: [Python-Dev] Executing zipfiles and directories (was Re: PyCon Keynote)

At 01:08 AM 1/27/2010 -0800, Glenn Linderman wrote: Of course, if you want to create a ZIP named .py package that is an application installer, you could do that, too. It might be handy for the case where not everything in the application can be a .py, .pyc, or .pyo... shared libraries cannot b

Re: [Python-Dev] Improved Traceback Module

At 02:33 PM 1/28/2010 +0100, Benjamin Schweizer wrote: Hello, I've updated the traceback.py module; my improved version dumps all local variabes from the stack trace, which helps in debugging rare problems. You can find details in my latest blog post here: http://benjamin-schweizer.de/improve

Re: [Python-Dev] Improved Traceback Module

At 11:01 AM 1/28/2010 -0600, s...@pobox.com wrote: pje> If you look for a local variable in each frame containing a format pje> string, let's say __trace__, you could apply that format string to pje> a locals+globals dictionary for the frame, in place of dumping all pje> the loca

Re: [Python-Dev] Improved Traceback Module

At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote: Hello pje, On Thu, Jan 28, 2010 at 12:43:13PM -0500, P.J. Eby wrote: > At 11:01 AM 1/28/2010 -0600, s...@pobox.com wrote: > >> pje> If you look for a local variable in each frame containing a format >> p

Re: [Python-Dev] Improved Traceback Module

At 01:24 AM 1/30/2010 +0100, Ludvig Ericson wrote: On 28 jan 2010, at 22:47, P.J. Eby wrote: > At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote: >> >> I like the idea of configuring the list of variables with using a >> convention like __trace__, though this requir

Re: [Python-Dev] __file__

At 10:40 PM 2/3/2010 +, Michael Foord wrote: Isn't __file__ usually baked into .pyc files at compile time? (At least I assumed that from the incorrect tracebacks on Windows when you ship just .pyc files.) That's code.co_filename, which is not necessarily the same as __file__.

Re: [Python-Dev] Proposal for virtualenv functionality in Python

At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows.

Re: [Python-Dev] Proposal for virtualenv functionality in Python

At 02:41 PM 2/20/2010 -0500, Ian Bicking wrote: Virtualenv uses copies when it can't use symlinks. Â A copy (or hard link) seems appropriate on systems that do not have symlinks. Â It would seem reasonable that on Windows it might look in the registry to find the actual location where Python wa

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 01:10 PM 3/7/2010 +1100, Brian Quinlan wrote: On 7 Mar 2010, at 03:04, Phillip J. Eby wrote: At 05:32 AM 3/6/2010, Brian Quinlan wrote: Using twisted (or any other asynchronous I/O framework) forces you to rewrite your I/O code. Futures do not. Twisted's "Deferred" API has nothing to do w

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote: P.J. Eby wrote: > (Personally, I think it would be better to just drop the ambitious title > and scope, and go for the "nice task queue" scope. I imagine, too, that > in that case Jean-Paul wouldn't need to worry ab

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote: On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby wrote: > At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote: >> >> P.J. Eby wrote: >> > (Personally, I think it would be better to just drop the ambitious title >> > and

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 10:59 AM 3/7/2010 -0800, Jeffrey Yasskin wrote: So is it that you just don't like the idea of blocking, and want to stop anything that relies on it from getting into the standard library? Um, no. As I said before, call it a "parallel task queue" or "parallel task manager" or something to t

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote: I'm +0 to allow these comparisons, being "Decimal(1) < .3" the same as "Decimal(1) < Decimal.from_float(.3)" Does Decimal.from_float() use the "shortest decimal representation" approach? If not, it might be confusing if a number that prints a

Re: [Python-Dev] Why is nan != nan?

At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote: But they're not -- they're *signals* for "your calculation has gone screwy and the result you get is garbage", so to speak. You shouldn't even think of a specific NAN as a piece of specific garbage, but merely a label on the *kind* of garbage

Re: [Python-Dev] Proposing PEP 376

At 11:51 PM 4/1/2010 +0200, Tarek Ziadé wrote: Hello, On behalf of the distutils-SIG, I'd like to propose PEP 376 for inclusion. This PEP is about defining a standard for installed Python projects. http://www.python.org/dev/peps/pep-0376/ Very nice; I have only a few questions/suggestions, an

Re: [Python-Dev] Proposing PEP 376

At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote: 2010/4/2 P.J. Eby : [...] > > * Paths under the base installation location are relative to the base > * Paths not under the base installation location, but under the installation > prefix, are also stored relative to the base, IF the b

Re: [Python-Dev] Proposing PEP 376

At 12:48 AM 4/4/2010 +0200, Tarek Ziadé wrote: The implementation so far will load zip files founded in the paths, see ZippedDistributionDir/ZippedDistribution. I was saying that it doesn't support sys.path entries of the form: "some/path/to/somezipfile.zip/subdir1" Python works correctly f

Re: [Python-Dev] Proposing PEP 376

At 04:40 PM 4/7/2010 +0200, Tarek Ziadé wrote: On Wed, Apr 7, 2010 at 4:35 PM, P.J. Eby wrote: > At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote: >> >> 2010/4/2 P.J. Eby : >> [...] >> > >> > * Paths under the base installation location are relative to t

Re: [Python-Dev] Proposing PEP 376

At 11:33 AM 4/7/2010 -0500, Ian Bicking wrote: On Wed, Apr 7, 2010 at 9:40 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote: so for the PEP : - sys.prefix -> the installation prefix provided by --prefix at installation time - site-packages -> the installation libdir,

Re: [Python-Dev] Proposing PEP 376

At 12:51 PM 4/7/2010 -0500, Ian Bicking wrote: On Wed, Apr 7, 2010 at 12:45 PM, P.J. Eby <<mailto:p...@telecommunity.com>p...@telecommunity.com> wrote: Examples under debian:   docutils/__init__.py      ->   located in /usr/local/lib/python2.6/site-packages/ Â

Re: [Python-Dev] Very Strange Argument Handling Behavior

At 04:51 PM 4/16/2010 -0500, Benjamin Peterson wrote: That won't work. You could put non-string keys in a dictionary and remove them, but the dictionary would still be in the less optimized state. That only means it's slower on uncommon cases and the case where you're about to get an exception

Re: [Python-Dev] argparse ambiguity handling

At 03:27 PM 4/20/2010 -0400, Neal Becker wrote: I have a preference to allow at least exact matches to succeed even in the case of ambiguity - mainly because I accidentally created this already once, and I feel it's better to at least work somewhat. Not sure if there is any more elegant solution

Re: [Python-Dev] PEP 376

At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote: Hello, I think I went through all the latest feedback regarding PEP 376. There will be still some work of course, on the implementation side (for instance the Zip issues described by PJE). But I would like to go ahead and propose PEP 376 for acce

Re: [Python-Dev] Sumo

At 11:41 PM 5/26/2010 +0100, Paul Moore wrote: I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) Actually, sumo distributions *have* been created; it's just

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 09:29 PM 5/29/2010 +0200, Martin v. Löwis wrote: Am 29.05.2010 21:06, schrieb P.J. Eby: At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote: In it he says that PEP 382 is being deferred until it can address PEP 302 loaders. I can't find any follow-up to this. I don't see any dis

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 03:44 PM 5/29/2010 -0700, Brett Cannon wrote: On Sat, May 29, 2010 at 12:29, "Martin v. Löwis" wrote: > Am 29.05.2010 21:06, schrieb P.J. Eby: >> >> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote: >>>> >>>> In it he says that PEP 382 is

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 05:59 PM 5/30/2010 -0700, Brett Cannon wrote: Is it wise to modify __path__ post-import? Today people can make sure that __path__ is set to what they want before potentially reading it in their __init__ module by making the pkgutil.extend_path() call first. This would actually defer to after t

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 06:18 PM 5/30/2010 -0700, Brett Cannon wrote: On Sun, May 30, 2010 at 00:40, P.J. Eby wrote: > > Which would completely break one of the major use cases of the PEP, which is > precisely to ensure that you can install two pieces of code to the same > namespace without either one

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 09:24 AM 5/31/2010 +0200, Martin v. Löwis wrote: Is this really how it works today? Shouldn't it abort here if there is an ImportError? Oops. You're right - I was confusing find_module with the path_hooks protoocol. >else: ># errors here should propagate >

Re: [Python-Dev] Implementing PEP 382, Namespace Packages

At 01:19 PM 5/31/2010 -0700, Brett Cannon wrote: But as long as whatever mechanism gets exposed allows people to work from a module name that will be enough. The path connection is not required as load_module is the end-all-be-all method. If we have a similar API added for .pth files that works o

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

At 05:22 PM 6/18/2010 +, l...@rmi.net wrote: So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the

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

At 10:55 PM 6/19/2010 +0900, Stephen J. Turnbull wrote: They really don't care that writing Python 3 was fun, and that programming in Python 3 is more fun than ever. That doesn't compensate for even one lingering str/bytes bogosity to most of them, and since they don't get paid for fixing Pyth

Re: [Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)

At 01:00 AM 6/21/2010 +0900, Steve Holden wrote: If there is such a disconnect we should think about remedying it: a large "Python 2 or 3?" button could link to a reasoned discussion of the pros and cons as evinced in this thread. That way people will end up with the right version more often (and

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

At 10:57 AM 6/20/2010 -0700, Guido van Rossum wrote: The problem comes exactly where you find it: when *porting* existing code that uses aforementioned ways to alleviate the pain, you find that the hacks no longer work and a properly layered design is needed that clearly distinguishes between whi

Re: [Python-Dev] bytes / unicode

At 07:33 PM 6/20/2010 -0400, Terry Reedy wrote: Do you have in mind any tools that could and should operate on both, but do not? From http://mail.python.org/pipermail/web-sig/2009-September/004105.html : """The problem which arises is that unquoting of URLs in Python 3.X stdlib can only be don

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

At 08:08 AM 6/21/2010 +1000, Nick Coghlan wrote: Perhaps if people could identify which specific string methods are causing problems? __getitem__(int) returns an integer rather than a bytestring, so anything that manipulates individual characters can't be given bytes and have it work. That

Re: [Python-Dev] bytes / unicode

At 11:47 PM 6/20/2010 +0200, Antoine Pitrou wrote: On Sun, 20 Jun 2010 14:40:56 -0400 "P.J. Eby" wrote: > > Actually, I would say that it's more that (in the network protocol > case) we *have* bytes, some of which we would like to *treat* as > text, yet do not wish

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

At 10:20 PM 6/21/2010 +1000, Nick Coghlan wrote: For the idea of avoiding excess copying of bytes through multiple encoding/decoding calls... isn't that meant to be handled at an architectural level (i.e. decode once on the way in, encode once on the way out)? Optimising the single-byte codec cas

Re: [Python-Dev] bytes / unicode

At 10:51 PM 6/21/2010 +1000, Nick Coghlan wrote: It may be that there are places where we need to rewrite standard library algorithms to be bytes/str neutral (e.g. by using length one slices instead of indexing). It may be that there are more APIs that need to grow "encoding" keyword arguments th

Re: [Python-Dev] bytes / unicode

At 01:08 AM 6/22/2010 +0900, Stephen J. Turnbull wrote: But if you need that "everywhere", what's so hard about def urljoin_wrapper (base, subdir): return urljoin(str(base, 'latin-1'), subdir).encode('latin-1') Now, note how that pattern fails as soon as you want to use non-ISO-8859-1 langu

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

At 11:43 AM 6/21/2010 -0400, Barry Warsaw wrote: On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote: >Something that may make sense to ease the porting process is for some >of these "on the boundary" I/O related string manipulation functions >(such as os.path.join) to grow "encoding" keyword-only a

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

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 = ebytes(b, 'euc-jp')``). As long as the coercion rules force str+ebytes (or str % ebytes, ebytes % str, etc.) to result in another eb

Re: [Python-Dev] bytes / unicode

At 05:49 PM 6/21/2010 +0100, Michael Foord wrote: Why is your proposed bstr wrapper not practical to implement outside the core and use in your own libraries and frameworks? __contains__ doesn't have a converse operation, so you can't code a type that works around this (Python 3.1 shown): >>

Re: [Python-Dev] bytes / unicode

At 12:56 PM 6/21/2010 -0400, Toshio Kuratomi wrote: One comment here -- you can also have uri's that aren't decodable into their true textual meaning using a single encoding. Apache will happily serve out uris that have utf-8, shift-jis, and euc-jp components inside of their path but the textual

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

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] 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 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 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 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] 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] 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 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

<    1   2   3   >