In issue 5920, Mark Dickinson raises an issue having to do with
float.__format__ and how it handles the default format presentation type
(that is, none of 'f', 'g', or 'e') versus how str() works on floats:
I agree with him that the current behavior is confusing and should be
changed. I'm going to make this change, unless anyone objects. Please
comment on the issue itself if you have any feedback.
(sent only to python-dev, as I am not a subscriber of tahoe-dev)
> [Tahoe] currently uses utf-8 for its internal storage (note: nothing to
> do with reading or writing files from external sources -- only for
> storing filenames in the decentralized storage system which is
> accessed by Tahoe clients), and we can't start putting non-utf-8-valid
> sequences in the "filename" slot because other Tahoe clients would
> then get a UnicodeDecodeError exception when trying to read those
So what do you do when someone has an existing file whose name is
supposed to be in utf-8, but whose actual bytes are not valid utf-8?
If you have somehow solved that problem, then you're already done --
the PEP's encoding is a no-op on anything that isn't already invalid
If you have not solved that problem, then those clients will already
be getting a UnicodeDecodeError; all the PEP does is make it at least
possible for them to recover.
> Requirement 1 (unicode): Each filename that you see needs to be valid
> unicode (it is stored internally in utf-8).
(repeating) What does Tahoe do if this is violated? Do you throw an
exception right there and not let them copy the file to tahoe? If so,
then that same error correction means that utf8b will never differ
from utf-8, and you have nothing to worry about.
> Requirement 2 (faithful if unicode):
Doesn't the PEP meet this?
> Requirement 3 (no file left behind):
Doesn't the PEP also meet this? I thought the concern was just that
the name used would not be valid unicode, unless the original name was
itself valid unicode.
> Possible Requirement 4 (faithful bytes if not unicode, a.k.a.
Doesn't the PEP also support this? (Only) the invalid bytes get
escaped and therefore must be unescaped, but the escapement is
> 3. (handling collisions) In either case 2.a or 2.b the resulting
> unicode string may already be present in the directory.
This collision is what the use of half-surrogates (as the escape
characters) avoids. Such collisions can't be present unless the data
was invalid unicode, in which case it was the result of an escapement
(unless something other than python is creating new invalid
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.
this is just a short notice that Mattias Brändström and I have finished a
patch to implement the previously discussed and mostly warmly welcomed
extension to with's syntax, allowing
with A() as a, B() as b:
to be written instead of
with A() as a:
with B() as b:
This syntax was chosen (over "with A(), B() as a, b:") because it has more
syntactical similarity to the written-out version. Also, our current uses
of "as" all have only one expression on the right.
The patch implements it as a simple AST transformation, which guarantees
semantic equivalence. It is at <http://codereview.appspot.com/53094>.
If there is no strong opposition, I will commit it and port it to py3k
before 3.1 enters beta stage.
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
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 - Deferred proposal
F - Final proposal
-> A - Active proposal
-> D - Draft proposal
-> R - Replaced proposal
----- Forwarded message from "\"Martin v. L?wis\"" <martin(a)v.loewis.de> -----
> Date: Sat, 02 May 2009 08:18:56 +0200
> From: "\"Martin v. L?wis\"" <martin(a)v.loewis.de>
> To: Aahz <aahz(a)pythoncraft.com>
> CC: pydotorg(a)python.org
> Subject: Re: [Pydotorg] FWD: [Python-Dev] svn down?
>> Benjamin Peterson reports being unable to ssh to dinsdale
> I have rebooted the machine; it seems now to be working again.
----- End forwarded message -----
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/
"Typing is cheap. Thinking is expensive." --Roy 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 error
We're in the process of forward-porting the recent (massive) json updates to
3.1, and we are also thinking of dropping remnants of support of the bytes type
in the json library (in 3.1, again). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it nevertheless. We're also
thinking of dropping the "encoding" argument in the various APIs, since it is
Under the new situation, json would only ever allow str as input, and output str
as well. By posting here, I want to know whether anybody would oppose this
(knowing, once again, that bytes support is already broken in the current py3k
The bug entry is: http://bugs.python.org/issue4136
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.
FWIW, my own approach would be to add two new interfaces to
1. extend the package path according to .pth files available
to the loader (alternatively, provide the contents of the
.pth files of the package in question)
2. search for and execute a package initialization module.