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 string 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
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
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
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 package
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
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
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
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
At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote:
On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby p...@telecommunity.com 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
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 such
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
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
At 08:56 AM 7/20/2011 -0700, Jeff Hardy wrote:
On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby p...@telecommunity.com 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
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.
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
At 03:22 PM 7/20/2011 -0600, Eric Snow wrote:
On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby p...@telecommunity.com 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
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 workaround
if anybody else can shoot
holes in it, or come up with useful solutions to open
questions. I'll be very interested to see Guido's reaction to it. :)
So, without further ado, here it is:
PEP: XXX
Title: Simplified Package Layout and Partitioning
Version: $Revision$
Last-Modified: $Date$
Author: P.J. Eby
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
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.)
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 p...@telecommunity.com 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 works
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'
DATE,
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
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
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
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
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
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?
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 something
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-1http://docs.python.org/dev/whatsnew/3.2.html#pep--python-web-server-gateway-interface-v1-0-1
to see if it
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,
At 07:47 AM 12/2/2010 -0800, Guido van Rossum wrote:
On Wed, Dec 1, 2010 at 8:45 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou
solip...@pitrou.net wrote:
Oh, about ICU:
Actually, I remember you saying that locale should
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
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
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
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 happens
without any special
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
At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote:
On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby p...@telecommunity.com 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 doesn't show
At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote:
On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby p...@telecommunity.com 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 p...@telecommunity.com wrote:
At 12:36 PM 9/27/2010 -0700, Brett Cannon
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
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
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org 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
*original* PEP 333 and I'm
-- 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 p...@telecommunity.com wrote:
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw
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
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
P.J. Eby http://mail.python.org/mailman/listinfo/python-devpje
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 good too! It doesn't really need to
turn 5 or 6
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=85014r2=85013pathrev=85014
For that matter, if anybody wants to take a crack at updating Python
3's
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
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
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,
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.comchr...@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 good idea to have
At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote:
On Tue, 21 Sep 2010 12:09:44 -0400
P.J. Eby p...@telecommunity.com 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, without
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
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
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 this
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
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
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
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
At 11:50 PM 9/15/2010 +0200, Dirkjan Ochtman wrote:
On Wed, Sep 15, 2010 at 21:18, P.J. Eby p...@telecommunity.com 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
At 09:22 AM 9/16/2010 +1000, James Mills wrote:
On Thu, Sep 16, 2010 at 9:06 AM, Chris McDonough chr...@plope.com 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
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
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
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
At 10:13 AM 8/24/2010 -0500, Benjamin Peterson wrote:
2010/8/24 James Y Knight f...@fuhm.net:
On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
2010/8/24 P.J. Eby p...@telecommunity.com:
At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a business case of throwing anything other
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
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
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,
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
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
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
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
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
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
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
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.comp...@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...@telecommunity.comp...@telecommunity.com
At 08:49 AM 8/1/2010 -0400, Kevin Jacobs jac...@bioinformed.com wrote:
On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing
mailto:greg.ew...@canterbury.ac.nzgreg.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
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
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
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
At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org 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
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
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
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
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.comp...@telecommunity.com wrote:
What does is not a package actually mean in that context?
The module is a module but not a package.
Um... that's not any clearer. Are you
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
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
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
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
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
encoded-bytes type
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
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 come
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.
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 almost
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
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
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
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
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
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):
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
1 - 100 of 282 matches
Mail list logo
