Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenveypjen...@underboss.org
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Am 09.11.2011 09:25, schrieb Stefan Behnel:
Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenveypjen...@underboss.org
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1
On Wed, 09 Nov 2011 10:44:50 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Am 09.11.2011 09:25, schrieb Stefan Behnel:
Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenveypjen...@underboss.org
summary:
First of all, thanks for having upgraded this huge part (codecs) to the new
Unicode API!
+static int
+unicode_widen(PyObject **p_unicode, int maxchar)
+{
+PyObject *result;
+assert(PyUnicode_IS_READY(*p_unicode));
+if (maxchar = PyUnicode_MAX_CHAR_VALUE(*p_unicode))
+
Hi,
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
On Wed, Nov 9, 2011 at 8:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 09 Nov 2011 10:44:50 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I recommend reverting the change. I fail to see why quoting the name
improves readability.
It does if the name is Throatwobbler Mangrove.
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
Terry Reedy wrote:
On 11/8/2011 10:49 AM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately).
Instead of copypaste the test manually between versions, has anybody
a better workflow?.
If a bug is fixed in
On Wed, Nov 9, 2011 at 8:59 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
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
accordingly).
Wait a minute, there's
On Tue, 08 Nov 2011 13:51:44 -0500
Terry Reedy tjre...@udel.edu wrote:
On 11/8/2011 10:49 AM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately).
Instead of copypaste the test manually between versions, has
On Wed, Nov 9, 2011 at 4:51 AM, Terry Reedy tjre...@udel.edu wrote:
If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0, so
perhaps it should not be added there. NEWS could just refer back to previous
sections. Then 3.3.0 News would only be new features and the occasional
I see this as inevitable. By the time the parser sees 'yield' it has
made its choices; the 'from' keyword cannot modify that. So whenever
yield expr must be parenthesized, yield from expr must too. (And
yes, there are parsing systems that don't have this restriction. But
Python's does and we like
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections wink, I'll commit this taking the next available
number.
Cheers,
-Barry
PEP: 405
Title: Python 2.8 Release Schedule
2011/11/9 Barry Warsaw ba...@python.org:
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections wink, I'll commit this taking the next available
number.
Cheers,
-Barry
Hi,
2011/11/9 Barry Warsaw ba...@python.org
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here.
Do we need to designate a release manager?
--
Amaury Forgeot d'Arc
___
Python-Dev
Le Mercredi 9 Novembre 2011 17:18:45 Amaury Forgeot d'Arc a écrit :
Hi,
2011/11/9 Barry Warsaw ba...@python.org
I think we should have an official pronouncement about Python 2.8, and
PEPs are as official as it gets 'round here.
Do we need to designate a release manager?
On Nov 09, 2011, at 05:18 PM, Amaury Forgeot d'Arc wrote:
2011/11/9 Barry Warsaw ba...@python.org
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here.
Do we need to designate a release manager?
I'd happily serve as the
Benjamin Peterson wrote:
2011/11/9 Barry Warsaw ba...@python.org:
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections wink, I'll commit this taking the next available
On Nov 09, 2011, at 11:18 AM, Benjamin Peterson wrote:
I don't know why this PEP is necessary, but I think a more appropriate
title would be 2.x is in maintenance only mode.
Okay, it's a little tongue-in-cheek, but the practical reason is that I want
it to be the top hit when someone searches
On 11/9/2011 6:28 AM, Nick Coghlan wrote:
So bug fixes should be recorded in both places - the 3.3a1 notes
record the deltas against 3.2.0, not against whatever the latest
release of 3.2 happens to be when 3.3 is released.
OK, I see that now.
Idea 2: If What's New in Python 3.3 Alpha 1? had
On 11/9/2011 11:14 AM, Barry Warsaw wrote:
I think we should have an official pronouncement about Python 2.8,
http://python.org/download/releases/2.7.2/ (and similar) already say:
The Python 2.7 series is scheduled to be the last major version in the
2.x series before 2.x moves into an
On Wed, Nov 9, 2011 at 10:14, Barry Warsaw ba...@python.org wrote:
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections wink, I'll commit this taking the next available
On Wed, Nov 9, 2011 at 10:14, Barry Warsaw ba...@python.org wrote:
I think we should have an official pronouncement about Python 2.8, and
PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections wink, I'll commit this taking the next available
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
I recommend reverting the change. I fail to see why quoting the name
improves readability.
It does if the name is Throatwobbler Mangrove.
But that can't be - the type name ought to be an identifier, so it can't
have spaces. It might be possible to create deliberately confusing error
+1 for Cardinal Biggles as release manager.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Nov 09, 2011, at 08:58 PM, Paul Moore wrote:
I see why people feel that something more precise and/or formal would
get the message across better, but the mildly tongue-in-cheek tone
isn't really inappropriate for a language named after Monty Python :-)
*Thank you* :)
+1 for Cardinal Biggles
Le mercredi 9 novembre 2011 22:03:52, vous avez écrit :
Should we:
* 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
On Thu, Nov 10, 2011 at 5:14 AM, Terry Reedy tjre...@udel.edu wrote:
On 11/9/2011 6:28 AM, Nick Coghlan wrote:
So bug fixes should be recorded in both places - the 3.3a1 notes
record the deltas against 3.2.0, not against whatever the latest
release of 3.2 happens to be when 3.3 is released.
Guido van Rossum wrote:
I see this as inevitable. By the time the parser sees 'yield' it has
made its choices; the 'from' keyword cannot modify that. So whenever
yield expr must be parenthesized, yield from expr must too.
This is patently untrue, because by version of the grammar
allows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/11/11 19:51, Terry Reedy wrote:
If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0,
so perhaps it should not be added there. NEWS could just refer back
to previous sections. Then 3.3.0 News would only be new features
and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/11 12:28, Nick Coghlan wrote:
The 3.2.x maintenance release sections are not present in the 3.3
NEWS file - it jumps straight from 3.2 to 3.3a1.
So bug fixes should be recorded in both places - the 3.3a1 notes
record the deltas against
On Wed, 09 Nov 2011 23:21:35 +0100
Jesus Cea j...@jcea.es wrote:
On 08/11/11 19:51, Terry Reedy wrote:
If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0,
so perhaps it should not be added there. NEWS could just refer back
to previous sections. Then 3.3.0 News would only be
On 10 November 2011 09:13, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
This is patently untrue, because by version of the grammar
allows 'f(yield from x)', while disallowing 'f(yield x)'.
I made a conscious decision to do that, and I'm a bit alarmed
at this decision being overridden at the
After a quick search on Google codesearch (before it disappears!), I don't
think that encoding a Unicode string to its internal PEP-393 representation
would satisfy any program. It looks like wchar_t* is a better candidate.
Ok. Making it Py_UNICODE, documenting that, and deprecating the
On Thu, Nov 10, 2011 at 7:55 AM, Barry Warsaw ba...@python.org wrote:
+1 for Cardinal Biggles as release manager.
Now you need to persuade Vinay to let you trade PEP numbers with the
pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an
opportunity to pass up :)
Getting boring for a
On Wed, Nov 9, 2011 at 2:13 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I see this as inevitable. By the time the parser sees 'yield' it has
made its choices; the 'from' keyword cannot modify that. So whenever
yield expr must be parenthesized, yield from expr
On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:
Now you need to persuade Vinay to let you trade PEP numbers with the
pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an
opportunity to pass up :)
Brilliant suggestion! Vinay? :)
Getting boring for a moment, I suggest including
On 10/11/11 05:18, Amaury Forgeot d'Arc wrote:
Do we need to designate a release manager?
I nominate John Cleese. Although he's undoubtedly a busy
man, this shouldn't take up too much of his time.
--
Greg
___
Python-Dev mailing list
On 10 November 2011 11:05, Barry Warsaw ba...@python.org wrote:
On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:
Now you need to persuade Vinay to let you trade PEP numbers with the
pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an
opportunity to pass up :)
Brilliant
On 10/11/11 12:11, Guido van Rossum wrote:
Actually it is valid, meaning yield (expr, expr) in any context
where yield expr is valid
Hmmm, it seems you're right. I was testing it using my patched
yield-from version of Python, where it has apparently become a
syntax error. I didn't mean to
On 10/11/11 11:43, Tim Delaney wrote:
We have precedent for being more restrictive initially, and relaxing those
restrictions later.
I suggest that the more restrictive implementation go in now so that people
can start playing with it. If the discussion comes to a consensus on more
relaxed
On Thu, Nov 10, 2011 at 8:32 AM, Antoine Pitrou solip...@pitrou.net wrote:
FYI, Twisted has chosen a totally different approach:
http://twistedmatrix.com/trac/wiki/ReviewProcess#Newsfiles
“[...] If we just let each author add to the NEWS files on every
commit, though, we would run into lots
On Thu, Nov 10, 2011 at 10:35 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
On 10/11/11 11:43, Tim Delaney wrote:
We have precedent for being more restrictive initially, and relaxing those
restrictions later.
I suggest that the more restrictive implementation go in now so that
people
On 10/11/11 14:50, Nick Coghlan wrote:
I'd actually be amenable to making it legal to omit
the extra parentheses for both yield yield from in the single
argument case where there's no ambiguity...
The way your patch tried to do it also allowed f(yield
from x, 1) which strikes me as being far
Jesus Cea writes:
A bit of discipline and, voila, automatic flawless merges! :-)
Doesn't work that way, sorry. The discipline required is isomorphic to
that required by threaded programs. See multiple threads on
python-ideas for why that is less than automatic or flawless. :-)
Antoine's
On Thu, 10 Nov 2011 12:49:48 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
A bit of discipline and, voila, automatic flawless merges! :-)
Doesn't work that way, sorry. The discipline required is isomorphic to
that required by threaded programs. See multiple threads on
python-ideas
47 matches
Mail list logo
