To download Python 3.2 visit:
http://www.python.org/download/releases/3.2/
It's a bit confusing that the download link is to 3.2 and not 3.2.2.
Cheers,
Hagen
___
Python-Dev mailing list
Python-Dev@python.org
Ok, I thought there was also a form normalized (denormalized?) to
decomposed form. But I'll take your word.
If I understood the example correctly, he needs a mixed form, with some
characters decomposed and some composed (depending on which one looks
better in the given font). I agree that this
[...] some text drawing engines draw decomposed characters (o
followed by ̈ - ö) differently compared to their composite
equivalents (ö) and this may be perceived as better or worse. I'd
like to offer an option to replace some decomposed characters with
their composite equivalent before
EOH = b'\r'[0]
CHAR = b'C'[0]
DATE = b'D'[0]
FLOAT = b'F'[0]
INT = b'I'[0]
LOGICAL = b'L'[0]
MEMO = b'M'[0]
NUMBER = b'N'[0]
This is not beautiful code.
You still have the alternative
EOH = ord('\r')
CHAR = ord('C')
...
which looks fine to me.
Cheers,
Hagen
3.2.1b1 was already merged back. (And 3.2.1rc1 will also be merged back
soon, since there will be a 3.2.1rc2.)
Thanks for the clarification! :-)
Cheers,
Hagen
___
Python-Dev mailing list
Python-Dev@python.org
On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.
Shouldn't there be a tag v3.2.1rc1 in the hg repo?
Cheers,
Hagen
___
Python-Dev mailing list
Python-Dev@python.org
P.S. Shouldn't makes it sound as if there was a mistake.
Well, I thought there was. When do these tags get merged into cpython
then? v3.2.1b1 is there, but v3.2.1rc1 isn't:
http://hg.python.org/cpython/tags
Cheers,
Hagen
___
Python-Dev mailing list
It's not a matter of dependence on iteration order, but of
reproducibility (in my case there were minor numerical differences due
to different iteration orders).
Can you give a code example? I don’t understand your case.
It's a bit involved (that's why it took me a while to locate the
Hi,
I just hunted down a change in behaviour between Python 3.1 and 3.2 to
possibly changed iteration order of sets due to the optimization in
issue #8685. Of course, this order shouldn't be relied on in the first
place, but the side effect of the optimization might be worth mentioning
in What's
Code with any dependence on the iteration order of unordered collections
(other than the guarantee that d.keys() and d.values() match at any
given time as long as d is unchanged) is buggy.
It's not a matter of dependence on iteration order, but of
reproducibility (in my case there were minor
During PEP 3003 discussion, it was suggested to handle it on a case by
case basis, but I don't see discussion of the upgrade to 6.0.0 in PEP
3003.
It's covered by As the standard library is not directly tied to the
language definition it is not covered by this moratorium.
How is this
Ow... I've always assumed that seek() is essentially free, because
that's how a typical OS kernel implements it. If seek() is bad on
GzipFile, how hard would it be to fix this?
I'd imagine that there's no easy way to make arbitrary seeks on a
GzipFile fast. But wouldn't it be enough to
Why not? Since the I/O speed problem is fixed, I have no idea what you
are referring to. Please do be concrete.
There's still a performance issue with pickling, but if issue 3873 could
be resolved, Python 3 would actually be faster there.
- Hagen
signature.asc
Description: OpenPGP digital
Your problem is easily explained however: the second argument to
p.findall() should be an offset, not a flag set. (You are confusing
re.findall() and p.findall().)
I filed a doc bug for this:
http://bugs.python.org/issue8785
Cheers,
Hagen
signature.asc
Description: OpenPGP digital
This behavior seems pretty strange to me, indeed PyPy gives the
TypeError for both attempts. I just wanted to confirm that it was in
fact intentional.
Oleg already answered why f(**{1:3}) raises a TypeError. But your
question seems to be rather why dict(**{1:3}) doesn't.
For functions
be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
I think the tag is correct. Note that the concept of tagging is
different in Mercurial, where a tag can only refer to a revision
previous to the one where it is
Part of the justification for the new with-statement syntax was
that nested() doesn't have a way to finalize the constructors
if one of them fails.
I think the problem was a little bit more subtle: nested() gets passed
managers, so their __init__()s should all have run when the first
context
Unlike a full DeprecationWarning, a PendingDeprecationWarning is ignored
by default. You have to switch them on explicitly via code or a command
line switch in order to see them.
Sorry, I should have made myself more familiar with the warnings
mechanism before writing. In that case I'm fine
I actually almost asked for that to be changed to a
PendingDeprecationWarning when it was first added - Benjamin, do you
mind if I downgrade this warning to a pending one post rc2?
I'm not sure what that would buy us. For the use case I mentioned it
would be just as annoying to get a
The semantic change actually needed to make nested() more equivalent to
the multi-with statement is for it to accept zero-argument callables
that create context managers as arguments rather than pre-created
context managers.
It seems to me that both passing callables which return managers and
contextlib.nested has recently been deprecated on grounds of being
unnecessary now that the with statement accepts multiple context
managers. However, as has been mentioned before
(http://mail.python.org/pipermail/python-dev/2009-May/089359.html), that
doesn't cover the case of a variable
I'd prefer Counter to refuse non-numerical values right away as the
present behaviour may hide bugs (e.g. a forgotten string-int
conversion). Any opinions? (And what about negative values or floats?)
Please file a report on bugs.python.org so that there's a record of this
issue.
Done:
I just noticed that while the docs say that Counts are allowed to be
any integer value including zero or negative counts,
collections.Counter doesn't perform any check on the types of count
values. Instead, non-numerical values will lead to strange behaviour or
exceptions later on:
c =
Ludvig Ericson wrote:
Well, I was trying to be funny and was under the impression that Python
3.0 had Unicode identifiers, but apparently it doesn't. (I used …, not ...)
It does, but they may not contain characters of the category
Punctuation, other:
import unicodedata
Is there some reason no set tp_hash for rangeobject to
PyObject_HashNotImplemented ?
http://bugs.python.org/issue4701
- Hagen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
If the Unicode APIs only have correct unicode, sure. If not you'll
get errors translating to UTF-8 (and the byte APIs are supposed to
pass bad names through unaltered.) Kinda ironic, no?
As far as I can see all Python Unicode strings can be encoded to UTF-8,
even things like lone surrogates
26 matches
Mail list logo
