> changeset: 0feb5a5dbaeb
> user: Antoine Pitrou <solipsis(a)pitrou.net>
> date: Sun Nov 13 01:02:02 2011 +0100
> Fix memory leak with FLUFL-related syntax errors (!)
I don’t think it is allowed to criticize FLUFL-related code. As the
FLUFL is flawless, so are flufly things. I hear the PSU has been
notified; a messenger will come t
The original message was received at Mon, 14 Nov 2011 12:56:42 +0200
from ghaering.de [22.214.171.124]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
while talking to python.org.:
>>> MAIL From:firstname.lastname@example.org
<<< 501 gh(a)ghaering.de... Refused
On Sun, 13 Nov 2011 22:33:28 +0100
barry.warsaw <python-checkins(a)python.org> wrote:
> +And Now For Something Completely Different
So, is the release manager a man with two noses?
> +Strings and bytes
> +Python 2's basic original string type are called 8-bit strings, and
> +they play a dual role in Python 2 as both ASCII text and as byte
> +arrays. While Python 2 also has a unicode string type, the
> +fundamental ambiguity of the core string type, coupled with Python 2's
> +default behavior of supporting automatic coercion from 8-bit strings
> +to unicodes when the two are combined, often leads to `UnicodeError`s.
> +Python 3's standard string type is a unicode, and Python 3 adds a
> +bytes type, but critically, no automatic coercion between bytes and
> +unicodes is provided. Thus, the core interpreter, its I/O libraries,
> +module names, etc. are clear in their distinction between unicode
> +strings and bytes. This clarity is often a source of difficulty in
> +transitioning existing code to Python 3, because many third party
> +libraries and applications are themselves ambiguous in this
> +distinction. Once migrated though, most `UnicodeError`s can be
First class unicode (*) support also makes Python much friendlier to
non-ASCII natives when it comes to things like filesystem access or
(*) even though Tom Christiansen would disagree, but perhaps we can
settle on first and a half
> +In Python 3, star imports (e.g. ``from x import *``) are only
> +premitted in module level code.
On 11/13/2011 5:52 PM, eli.bendersky wrote:
> changeset: 73541:87ecfd5cd5d1
> branch: 2.7
> parent: 73529:c3b063c82ae5
> user: Eli Bendersky<eliben(a)gmail.com>
> date: Mon Nov 14 01:02:20 2011 +0200
> Normalize the keyword arguments documentation notation in re.rst. Closes issue #12875
> -.. function:: compile(pattern[, flags=0])
> +.. function:: compile(pattern, flags=0)
This issue and the patch are about parameters with *default* arguments,
which makes a corresponding argument in a call *optional*. For Python
functions, both required and optional arguments can be passed by
position (unless disabled) or keyword. Which is to say, for Python
functions, any argument can be a keyword argument. I suspect I am not
the only person somewhat confused when people use 'keyword' to mean
'optional' or 'default'.
Hello everyone and Benjamin,
Currently, memoryview objects are unhashable:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'memoryview'
Compare with Python 2.7:
memoryviews already support equality comparison:
>>> b"" == memoryview(b"")
If the original object providing the buffer is hashable, then it
seems to make sense for the memoryview object to be hashable. This came
while porting Twisted to Python 3.
What do you think?
The PS: at the top of Misc/ACKS says:
PS: In the standard Python distribution, this file is encoded in UTF-8
and the list is in rough alphabetical order by last names.
However, the last 3 names in the list don't appear to be part of that
alphabetical order. Is this somehow intentional, or just a mistake?
The unicode_internal decoder doesn't decode surrogate pairs and so
test_unicode.UnicodeTest.test_codecs() is failing on Windows (16-bit wchar_t).
I don't know if this codec is still revelant with the PEP 393 because the
internal representation is now depending on the maximum character (Py_UCS1*,
Py_UCS2* or Py_UCS4*), whereas it was a fixed size with Python <= 3.2
* Drop this codec (public and documented, but I don't know if it is used)
* Use wchar_t* (Py_UNICODE*) to provide a result similar to Python 3.2, and
so fix the decoder to handle surrogate pairs
* Use the real representation (Py_UCS1*, Py_UCS2 or Py_UCS4* string)
The failure on Windows:
FAIL: test_codecs (test.test_unicode.UnicodeTest)
Traceback (most recent call last):
File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_unicode.py", line
1408, in test_codecs
Nick Coghlan wrote:
> In reviewing Zbyszek's doc updates and comparing them against the Grammar, I
> discovered a gratuitous change in the implementation: it allows a bare (i.e. no
> parentheses) 'yield from' as an argument to a function.
> I'll add a new test to ensure "yield from x" requires parentheses whenever
> "yield x" requires them (and fix the Grammar file on the implementation branch
Wait a minute, there's nothing in the PEP as accepted that
mentions any such restriction.
My intention was that it should be as easy as possible to
replace any function call 'f(x)' with 'yield from f(x)'.
If parentheses are required, then instead of
f(yield from g(x))
we would have to write
f((yield from g(x)))
I can't see how this is an improvement in readability or