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 = colle
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: http://
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 numbe
> 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
> 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 Pending
> 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
> 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 inser
> 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 impl
> 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 signa
> 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
> 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 optim
>> 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
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
>> 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 t
> 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
http://mail.python.
> 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 maili
> 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
http://mail.python.org/mailman/listinf
> 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
__
> 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 surrogate
>> As far as I can see all Python Unicode strings can be encoded to UTF-8,
>> even things like lone surrogates because Python doesn't care about them.
>> So both the Unicode API and the binary API would be fail-safe on Windows.
>
> Python is broken and needs to be fixed.
>
> http://bugs.python.or
> 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:
http://
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
>>> unicodedata.c
>> [...] 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 equ
> 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
> 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
http://mail.python.org/mailman/li
27 matches
Mail list logo
