On Thu, 10 Nov 2011 12:49:48 +0900
"Stephen J. Turnbull" 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 for why t
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 sugg
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
On Thu, Nov 10, 2011 at 10:35 AM, Greg Ewing
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
>> can start play
On Thu, Nov 10, 2011 at 8:32 AM, Antoine Pitrou 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 of spurious conf
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 synta
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 November 2011 11:05, Barry Warsaw 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 suggestion!
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
Python-Dev@pytho
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 includin
On Wed, Nov 9, 2011 at 2:13 PM, Greg Ewing 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" must too.
>
> This
On Thu, Nov 10, 2011 at 7:55 AM, Barry Warsaw 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 moment, I sugg
> 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 10 November 2011 09:13, Greg Ewing 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 last moment with no
>
On Wed, 09 Nov 2011 23:21:35 +0100
Jesus Cea 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 new
-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 aga
-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 th
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 'f(
On Thu, Nov 10, 2011 at 5:14 AM, Terry Reedy 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.
>
> OK, I
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
> >
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 Biggl
> +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
>> 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
m
> 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 10:14, Barry Warsaw 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 , I'll commit this taking the next available
> number.
+1 on h
On Wed, Nov 9, 2011 at 10:14, Barry Warsaw 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 , I'll commit this taking the next available
> number.
>
> Cheers,
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 extende
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 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
Benjamin Peterson wrote:
2011/11/9 Barry Warsaw :
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 , I'll commit this taking the next available
number.
Cheers,
-Barry
P
On Nov 09, 2011, at 05:18 PM, Amaury Forgeot d'Arc wrote:
>2011/11/9 Barry Warsaw
>
>> 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 un-release manag
Le Mercredi 9 Novembre 2011 17:18:45 Amaury Forgeot d'Arc a écrit :
> Hi,
>
> 2011/11/9 Barry Warsaw
>
> > 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?
random.choice() shou
Hi,
2011/11/9 Barry Warsaw
> 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 mailing list
Pytho
2011/11/9 Barry Warsaw :
> 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 , I'll commit this taking the next available
> number.
>
> Cheers,
> -Barry
>
> PEP: 405
> Ti
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 , I'll commit this taking the next available
number.
Cheers,
-Barry
PEP: 405
Title: Python 2.8 Release Schedule
Version: $
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 li
On Wed, Nov 9, 2011 at 4:51 AM, 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 occasional
> ambiguous item not f
On Tue, 08 Nov 2011 13:51:44 -0500
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 copy&paste the test manually between versions, has anybod
On Wed, Nov 9, 2011 at 8:59 PM, Greg Ewing 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 nothing in the PEP
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 copy&paste the test manually between versions, has anybody
> >a better workflow?.
>
> If a bug i
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 parenthe
On Wed, Nov 9, 2011 at 8:19 PM, Antoine Pitrou wrote:
> On Wed, 09 Nov 2011 10:44:50 +0100
> "Martin v. Löwis" wrote:
>> I recommend reverting the change. I fail to see why quoting the name
>> improves readability.
>
> It does if the name is "Throatwobbler Mangrove".
The readability argument doe
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 (Py_U
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))
> +
On Wed, 09 Nov 2011 10:44:50 +0100
"Martin v. Löwis" 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 Jenvey
> summary:
> quote the
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 Jenvey
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c
Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenvey
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python/bl
47 matches
Mail list logo
