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. (Actua
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/
..
> 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
Un
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 th
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 prob
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" wrote:
>>
>> Require
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
Python
2009/5/1 Eric Smith :
> 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 e
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
Michael Foord wrote:
MRAB wrote:
Benjamin Peterson wrote:
2009/5/1 MRAB :
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
___
Python-D
MRAB wrote:
Benjamin Peterson wrote:
2009/5/1 MRAB :
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
Benjamin Peterson wrote:
2009/5/1 MRAB :
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
On 01May2009 18:38, Martin v. L?wis 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 or the bytes a
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 (possi
2009/5/1 MRAB :
> 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 -
> 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 th
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. t
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,
>> 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" pack
>>> 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 complete
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
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 d
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 com
> 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 -
> 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 or the bytes are faithfully
> transmitted from one system to another
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"
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
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 fo
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 t
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
Average
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 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 regenera
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 -
Following-up to my own post to correct a major error:
On Thu, Apr 30, 2009 at 11:44 PM, Zooko O'Whielacronx 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 same byte stri
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
b
During Guido's review, we discovered that PEP 382 doesn't
deal with PEP 302 loaders; I believe that it should, though.
Rather than coming up with an ad-hoc design, I propose to
defer the PEP to Python 3.2 - unless somebody can propose
a straight-forward design with not too many new interfaces.
FW
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 strin
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
38 matches
Mail list logo
