I've taken the liberty of explicitly CCing Martin just incase he missed
the thread with all the noise regarding PEP383.
If there are no objections from Martin
It's fine with me - I just won't have time to look into the details of
that change.
Regards,
Martin
Zooko O'Whielacronx wrote:
[snip...]
Would it be possible for Python unicode objects to have a flag
indicating whether the 'python-escape' error handler was present? That
would serve the same purpose as my failed_decode flag above, and would
basically allow me to use the Python APIs directory
On Thu, 30 Apr 2009 at 23:44, Zooko O'Whielacronx wrote:
Would it be possible for Python unicode objects to have a flag
indicating whether the 'python-escape' error handler was present? That
Unless I'm misunderstanding something, couldn't you implement what you
need by looking in a given
James Y Knight writes:
in python. It seems like the most common reason why people want to use
SJIS is to make old pre-unicode apps work right in WINE -- in which
case it doesn't actually affect unix python at all.
Mounting external drives, especially USB memory sticks which tend to
be
Following-up to my own post to correct a major error:
On Thu, Apr 30, 2009 at 11:44 PM, Zooko O'Whielacronx zoo...@gmail.com wrote:
Folks:
My use case (Tahoe-LAFS [1]) requires that I am *able* to read arbitrary
binary names from the filesystem and store them so that I can regenerate
the
I've just noticed an oddity in the key in PEP 0. Most letters are used
more than once. Wouldn't it be clearer if different letters were used
for Accepted and Active instead of them both being 'A', for example?
- A - Accepted proposal
- R - Rejected proposal
W - Withdrawn proposal
- D -
Zooko O'Whielacronx wrote:
Following-up to my own post to correct a major error:
On Thu, Apr 30, 2009 at 11:44 PM, Zooko O'Whielacronx zoo...@gmail.com wrote:
Folks:
My use case (Tahoe-LAFS [1]) requires that I am *able* to read arbitrary
binary names from the filesystem and store them so
ACTIVITY SUMMARY (04/24/09 - 05/01/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2190 open (+34) / 15527 closed (+29) / 17717 total (+63)
Open issues with patches: 861
M.-A. Lemburg wrote:
If the package really requires adding one or more directories on sys.path (e.g.
because it has not yet been structured to support dotted-name import), a path
configuration file named package.pth can be placed in either the site-python or
site-packages directory.
...
A
M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
The PEP provides a way to solve this use case by giving both developers
and users a standard at hand which they can
P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and ll.*,
although I'd guess from the PyPI listings that perhaps Django is. (It
seems that base packages are more likely to use a 'base-extension'
naming pattern, vs. the 'namespace.project' pattern used by pure
In either of the proposals on the table, what code would I write and
where to have a base package with a set of add-on packages?
I don't quite understand the question. Why would you want to write code
(except for the code that actually is in the packages)?
PEP 382 is completely declarative -
Martin v. Löwis wrote:
In either of the proposals on the table, what code would I write and
where to have a base package with a set of add-on packages?
I don't quite understand the question. Why would you want to write code
(except for the code that actually is in the packages)?
PEP 382 is
Where you just want a damned valid email and stop making my life
hard!:
Message['Subject']='Some text'
Yes. In which case I propose we guess the encoding as 1) ascii, 2)
utf-8, 3) wtf?
Well, we're talking about Python 3 here right? In which case the above
involves only unicode, so why do
Stephen J. Turnbull wrote:
str(message['Subject'])
Yes for unstructured headers like Subject. For structured headers...
hmm.
Well, suppose we get really radical here. *People* see email as
(rich-)text. So ... message['Subject'] returns an object, partly to
be consistent with
In either of the proposals on the table, what code would I write and
where to have a base package with a set of add-on packages?
I don't quite understand the question. Why would you want to write code
(except for the code that actually is in the packages)?
PEP 382 is completely declarative
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern, vs. the 'namespace.project' pattern
used by pure packages.)
At 05:35 PM 5/1/2009 +0100, Chris Withers wrote:
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern,
At 07:41 PM 5/1/2009 +0200, Martin v. Löwis wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern, vs. the
Actually, if you are using only the distutils, you can do this by
listing only modules in the addon projects; this is how the ll.* tools
are doing it. That only works if the packages are all being installed
in the same directory, though, not as eggs.
Right: if all portions install into the
2009/5/1 MRAB goo...@mrabarnett.plus.com:
I've just noticed an oddity in the key in PEP 0. Most letters are used
more than once. Wouldn't it be clearer if different letters were used
for Accepted and Active instead of them both being 'A', for example?
- A - Accepted proposal
- R - Rejected
Zooko O'Whielacronx wrote:
Following-up to my own post to correct a major error:
Is it true that
srcbytes.encode(srcencoding, 'python-escape').decode('utf-8',
'python-escape') will always produce srcbytes ? That is my Requirement
If you start with bytes, decode with utf-8b to unicode
Benjamin Peterson wrote:
2009/5/1 MRAB goo...@mrabarnett.plus.com:
I've just noticed an oddity in the key in PEP 0. Most letters are used
more than once. Wouldn't it be clearer if different letters were used
for Accepted and Active instead of them both being 'A', for example?
- A - Accepted
MRAB wrote:
Benjamin Peterson wrote:
2009/5/1 MRAB goo...@mrabarnett.plus.com:
I've just noticed an oddity in the key in PEP 0. Most letters are used
more than once. Wouldn't it be clearer if different letters were used
for Accepted and Active instead of them both being 'A', for
example?
-
On May 1, 2009, at 5:55 PM, Michael Foord wrote:
P for Proposal (to replace Active Proposal)? Every active PEP is a
proposal...
+1
Maybe even s/Active/Proposed/g ?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
On 01May2009 18:38, Martin v. L?wis mar...@v.loewis.de wrote:
| Okay, I am wrong about this. Having a flag to remember whether I had to
| fall back to the utf-8b trick is one method to implement my requirement,
| but my actual requirement is this:
|
| Requirement: either the unicode string
Michael Foord wrote:
MRAB wrote:
Benjamin Peterson wrote:
2009/5/1 MRAB goo...@mrabarnett.plus.com:
I've just noticed an oddity in the key in PEP 0. Most letters are used
more than once. Wouldn't it be clearer if different letters were used
for Accepted and Active instead of them both being
When checking in, I get:
Transmitting file data .svn: Commit failed (details follow):
svn: Can't create directory
'/data/repos/projects/db/transactions/72186-1.txn': Read-only file system
With 'svn up', I get:
svn: Can't find a temporary directory: Internal error
2009/5/1 Eric Smith e...@trueblade.com:
When checking in, I get:
Transmitting file data .svn: Commit failed (details follow):
svn: Can't create directory
'/data/repos/projects/db/transactions/72186-1.txn': Read-only file system
With 'svn up', I get:
svn: Can't find a temporary directory:
What's the status of yield from? There's still a small window open for
a patch to be checked into 3.1's branch. I haven't been following the
python-ideas threads, so I'm not sure if it's ready yet.
--
Regards,
Benjamin
___
Python-Dev mailing list
Folks:
Being new to the use of gmail, I accidentally sent the following only
to MvL and not to the list. He promptly replied with a helpful
counterexample showing that my design can suffer collisions. :-)
Regards,
Zooko
On Fri, May 1, 2009 at 10:38 AM, Martin v. Löwis mar...@v.loewis.de
Alas, I haven't been following it either recently. Too bad, really,
because before I left (now three weeks ago) it was already pretty
close. We could perhaps even check in Greg's patch (which I tried and
looked like a solid implementation of his proposal at the time) and
finagle it for b2. One
On May 1, 2009, at 9:42 PM, Zooko O'Whielacronx wrote:
Yep, I reversed the order of encode() and decode(). However, my whole
statement was utterly wrong and shows that I still didn't fully get it
yet. I have flip-flopped again and currently think that PEP 383 is
useless for this use case and
..
leaving just 'Rejected' and 'Replaced' to be disambiguated.
'X' or 'Z' for Rejected? Looks like a perfect start for a bikeshed
discussion. :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Barry Warsaw writes:
On May 1, 2009, at 5:55 PM, Michael Foord wrote:
P for Proposal (to replace Active Proposal)? Every active PEP is a
proposal...
+1
Maybe even s/Active/Proposed/g ?
Shouldn't that be
s/Active/Proposed/g
duck /
Alexander Belopolsky writes:
..
leaving just 'Rejected' and 'Replaced' to be disambiguated.
'X' or 'Z' for Rejected? Looks like a perfect start for a bikeshed
discussion. :-)
The Japanese contingent suggests O (UPPERCASE LATIN LETTER O) for
accepted and X for rejected. (Actually
37 matches
Mail list logo
