Re: [Python-Dev] [Python-checkins] cpython: quote the type name for improved readability
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/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -1121,7 +1121,7 @@
return NULL;
if (!PyIter_Check(it)) {
PyErr_Format(PyExc_TypeError,
- "%.200s object is not an iterator",
+ "'%.200s' object is not an iterator",
it->ob_type->tp_name);
return NULL;
}
What about displaying the repr of the type object?
While I agree that this is more readable, quoted type names are rather rare
if not pretty much unprecedented in core exception messages, so this is
definitely not the only place that would need changing.
However, note that arbitrarily changing exception messages always breaks
someone's doctests, so my personal preference would be to keep it as it was.
... and I just noticed that it did break a doctest in Cython's regression
test suite. Should I change the test, or will this be taken back?
Stefan
___
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
Re: [Python-Dev] [Python-checkins] cpython: quote the type name for improved readability
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 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -1121,7 +1121,7 @@
return NULL;
if (!PyIter_Check(it)) {
PyErr_Format(PyExc_TypeError,
- "%.200s object is not an iterator",
+ "'%.200s' object is not an iterator",
it->ob_type->tp_name);
return NULL;
}
>>>
>>> What about displaying the repr of the type object?
>>
>> While I agree that this is more readable, quoted type names are rather
>> rare
>> if not pretty much unprecedented in core exception messages, so this is
>> definitely not the only place that would need changing.
>>
>> However, note that arbitrarily changing exception messages always breaks
>> someone's doctests, so my personal preference would be to keep it as
>> it was.
>
> ... and I just noticed that it did break a doctest in Cython's
> regression test suite. Should I change the test, or will this be taken
> back?
I recommend reverting the change. I fail to see why quoting the name
improves readability.
Regards,
Martin
___
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
Re: [Python-Dev] [Python-checkins] cpython: quote the type name for improved readability
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 type name for improved readability
>
> files:
> Python/bltinmodule.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
> --- a/Python/bltinmodule.c
> +++ b/Python/bltinmodule.c
> @@ -1121,7 +1121,7 @@
> return NULL;
> if (!PyIter_Check(it)) {
> PyErr_Format(PyExc_TypeError,
> - "%.200s object is not an iterator",
> + "'%.200s' object is not an iterator",
> it->ob_type->tp_name);
> return NULL;
> }
> >>>
> >>> What about displaying the repr of the type object?
> >>
> >> While I agree that this is more readable, quoted type names are rather
> >> rare
> >> if not pretty much unprecedented in core exception messages, so this is
> >> definitely not the only place that would need changing.
> >>
> >> However, note that arbitrarily changing exception messages always breaks
> >> someone's doctests, so my personal preference would be to keep it as
> >> it was.
> >
> > ... and I just noticed that it did break a doctest in Cython's
> > regression test suite. Should I change the test, or will this be taken
> > back?
>
> I recommend reverting the change. I fail to see why quoting the name
> improves readability.
It does if the name is "Throatwobbler Mangrove".
Regards
Antoine.
___
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
Re: [Python-Dev] [Python-checkins] cpython: Change decoders to use Unicode API instead of Py_UNICODE.
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))
> +return 0;
> +result = PyUnicode_New(PyUnicode_GET_LENGTH(*p_unicode),
> + maxchar);
> +if (result == NULL)
> +return -1;
> +PyUnicode_CopyCharacters(result, 0, *p_unicode, 0,
> + PyUnicode_GET_LENGTH(*p_unicode));
> +Py_DECREF(*p_unicode);
> +*p_unicode = result;
> +return 0;
> +}
PyUnicode_CopyCharacters() result must be checked. If you are sure that the
call cannot fail, use copy_characters() which uses assertions in debug mode (
and no check in release mode).
> -#ifndef DONT_MAKE_RESULT_READY
> -if (_PyUnicode_READY_REPLACE(&v)) {
> -Py_DECREF(v);
> -return NULL;
> -}
> -#endif
Why did you remove this call from PyUnicode_DecodeRawUnicodeEscape(),
_PyUnicode_DecodeUnicodeInternal(), PyUnicode_DecodeASCII() and
PyUnicode_DecodeCharmap()? It may reuse latin1 characters singletons to share
a little bit more memory (there is already a special case for empty string).
"_PyUnicode_READY_REPLACE" is maybe not the best name :-)
Victor
___
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
[Python-Dev] unicode_internal codec and the PEP 393
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_UCS1*, Py_UCS2* or Py_UCS4*), whereas it was a fixed size with Python <= 3.2 (Py_UNICODE*). 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 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 self.assertEqual(str(u.encode(encoding),encoding), u) AssertionError: '\ud800\udc01\ud840\udc02\ud880\udc03\ud8c0\udc04\ud900\udc05' != '\U00030003\U00040004\U00050005' Victor ___ 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
Re: [Python-Dev] [Python-checkins] cpython: quote the type name for improved readability
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 doesn't really sell me, but the consistency one does: Python 3.2: >>> iter(1) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable >>> next(1) Traceback (most recent call last): File "", line 1, in TypeError: int object is not an iterator We generally do quote the type names in error messages, so this change is just bringing next() into line with other operations: >>> 1 + '' Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 accordingly). 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 clarity. -- Greg ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 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 fixed before. In this case, we would have to *remove* entries from Misc/NEWS after merging to 3.3, right? ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 as accepted that > mentions any such restriction. It doesn't need to be mentioned in the PEP - it's inherited due to the fact that the PEP builds on top of yield expressions. There is no excuse for the two expressions being inconsistent in their parenthesis requirements when they are so similar syntactically. For ordinary yield expressions, "f(yield x, y)" has to be disallowed since it is genuinely ambiguous (does it mean "f(yield (x, y))" or "f((yield x), y)"?), and it then becomes something of a pain to allow any yield argument other than an unparenthesised tuple when a yield expression is provided as the sole argument to a call. So, from my point of view, it is absolutely a requirement that 'yield from' expressions be parenthesised in the multiple argument case. The previous grammar allowed confusing constructs like "f(yield from x, y)" (interpreting it as "f((yield from x), y) while still issuing a syntax error (as expected) for "yield from x, y". You *could* try to make a case that we should allow "f(yield from x)", but it isn't then clear to the casual reader why that's OK and "f(yield x)" gets disallowed. And that brings us back to the complexity of creating a special yield expression variant that's allowed as the sole argument to a function call without additional parentheses, but without introducing ambiguity into the grammar. It's simpler and cleaner to just make the rules for the two constructs identical - if it's a subexpression, you have to add the extra parentheses, if it's a statement or the sole expression on the RHS of an assignment, you don't. That said, it's likely *possible* to make those parentheses optional in the single argument call case (as we do for generator expressions), but do you really want to hold up the PEP 380 implementation for a minor detail like that? Besides, since it would affect the grammar definition for ordinary yield expressions as well, it might even need a new PEP. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 anybody > > a better workflow?. > > 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. So people who download 3.3 would also have to download 3.2 to get the complete list of changes? That's confusing. ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 fixed before. 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 3.2.0, not against whatever the latest release of 3.2 happens to be when 3.3 is released. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 it that way.) At the same time, "yield expr, expr" works; but does "yield from expr, expr" mean anything? Finally, glad to see work on this PEP proceeding; I'm looking forward to using the fruits of that labor! --Guido On Wed, Nov 9, 2011 at 3:21 AM, Nick Coghlan wrote: > 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 as accepted that >> mentions any such restriction. > > It doesn't need to be mentioned in the PEP - it's inherited due to the > fact that the PEP builds on top of yield expressions. There is no > excuse for the two expressions being inconsistent in their parenthesis > requirements when they are so similar syntactically. > > For ordinary yield expressions, "f(yield x, y)" has to be disallowed > since it is genuinely ambiguous (does it mean "f(yield (x, y))" or > "f((yield x), y)"?), and it then becomes something of a pain to allow > any yield argument other than an unparenthesised tuple when a yield > expression is provided as the sole argument to a call. > > So, from my point of view, it is absolutely a requirement that 'yield > from' expressions be parenthesised in the multiple argument case. The > previous grammar allowed confusing constructs like "f(yield from x, > y)" (interpreting it as "f((yield from x), y) while still issuing a > syntax error (as expected) for "yield from x, y". > > You *could* try to make a case that we should allow "f(yield from x)", > but it isn't then clear to the casual reader why that's OK and > "f(yield x)" gets disallowed. And that brings us back to the > complexity of creating a special yield expression variant that's > allowed as the sole argument to a function call without additional > parentheses, but without introducing ambiguity into the grammar. > > It's simpler and cleaner to just make the rules for the two constructs > identical - if it's a subexpression, you have to add the extra > parentheses, if it's a statement or the sole expression on the RHS of > an assignment, you don't. > > That said, it's likely *possible* to make those parentheses optional > in the single argument call case (as we do for generator expressions), > but do you really want to hold up the PEP 380 implementation for a > minor detail like that? Besides, since it would affect the grammar > definition for ordinary yield expressions as well, it might even need > a new PEP. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
[Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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: $Revision$ Last-Modified: $Date$ Author: Barry Warsaw Status: Final Type: Informational Content-Type: text/x-rst Created: 2011-11-09 Python-Version: 2.8 Abstract This document describes the development and release schedule for Python 2.8. Release Schedule The current schedule is: - 2.8 final Never Official pronouncement == There will never be an official Python 2.8 release. Upgrade path The official upgrade path from Python 2.7 is to Python 3. Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 > Title: Python 2.8 Release Schedule 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". > Version: $Revision$ > Last-Modified: $Date$ > Author: Barry Warsaw > Status: Final > Type: Informational > Content-Type: text/x-rst > Created: 2011-11-09 > Python-Version: 2.8 -- Regards, Benjamin ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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() should help in this case. Victor ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 manager. :) -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 PEP: 405 Title: Python 2.8 Release Schedule 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". I think somebody searching will more easily find "Python 2.8 Release Schedule" rather than "2.x is in maintenance only mode". ~Ethan~ ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 for "Python 2.8". Cheers, -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 two major sections" NEW FEATURES and BUG FIXES (since 3.2.0) with duplicated subheaders, and if the subheaders were tagged, like Core and Builtins -- Features Core and Builtins -- Fixes and if the subheaders for 3.2.z, z>=1 had the latter tags, then the context for merges of bug fixes would not be disturbed by the interposition of feature items. There would only be a problem when the first merge of a subsection for a 3.2.z, z>=2 release is not the first item in the corresponding section for 3.3.0alpha1. Idea 3: Someone else suggested a file-specific merge. If the 3.2.z patch simply inserts an item under "Some Header", with no deletions, the custom merge inserts the item under the first occurrence of "Some Header" in the 3.3 file. Ignoring what comes after in both files should prevent new feature items from blocking the merge. Otherwise, use the normal merge. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 extended maintenance period. If Guido is ready to "pound the final nail in the coffin", delete 'scheduled to be', and change "series before 2.x moves into" to "series. 2.x is in", fine with me. I am not sure a PEP is also needed, but OK, with revision. and PEPs are as official as it gets 'round here. > Thus I propose the following. If there are no objections, There are ;-). The title is misleading, and the whole thing reads like an April Fools Joke. If I were looking for information, I would be slightly annoyed. PEP: 405 Title: Python 2.8 Release Schedule Title: Python 2.8 Will Never Happen tells anyone searching what they need to know immediately. They would only need to click on a link if they wanted to know 'why'. Version: $Revision$ Last-Modified: $Date$ Author: Barry Warsaw Guido should be the first author. Status: Final Type: Informational So let us be informative from the title on. Content-Type: text/x-rst Created: 2011-11-09 Python-Version: 2.8 Abstract This document describes the development and release schedule for Python 2.8. More non-informative teasing. Instead, I suggest replacing everything with short, sweet, and informative. Rationale = For backward-compatibility reasons, the Python 2 series is burdened with several obsolete and duplicate features that were removed in Python 3. In addition, the primary character set was expanded from ascii to unicode. While bug fixes continue for 2.7, new developments go into Python 3.x versions. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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, > -Barry > > PEP: 405 > Title: Python 2.8 Release Schedule > Version: $Revision$ > Last-Modified: $Date$ > Author: Barry Warsaw > Status: Final > Type: Informational > Content-Type: text/x-rst > Created: 2011-11-09 > Python-Version: 2.8 > > > Abstract > > > This document describes the development and release schedule for Python > 2.8. > > > Release Schedule > > > The current schedule is: > > - 2.8 final Never > > > Official pronouncement > == > > There will never be an official Python 2.8 release. > > > Upgrade path > > > The official upgrade path from Python 2.7 is to Python 3. > > > Copyright > = > > This document has been placed in the public domain. > > > > .. > Local Variables: > mode: indented-text > indent-tabs-mode: nil > sentence-end-double-space: t > fill-column: 70 > coding: utf-8 > End: +1. post it as-is. ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 having a PEP +0 on posting it as it stands 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 :-) +1 for Cardinal Biggles as release manager. Paul ___ 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
Re: [Python-Dev] unicode_internal codec and the PEP 393
> 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 > (Py_UNICODE*). The current status is the way it is because we (Torsten and me) didn't bother figuring out the purpose of the internal codec. > 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 real representation (Py_UCS1*, Py_UCS2 or Py_UCS4* string) It's described as "Return the internal representation of the operand". That would suggest that the last choice (i.e. return the real internal representation) would be best, except that this doesn't round-trip. Adding a prefix byte indicating the kind (and perhaps also the ASCII flag) would then be closest to the real representation. As that is likely not very useful, and might break some applications of the encoding (if there are any at all) which might expect to pass unicode-internal strings across Python versions, I would then also deprecate the encoding. Regards, Martin ___ 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
Re: [Python-Dev] [Python-checkins] cpython: quote the type name for improved readability
>> 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 messages, though, such as py> class your:pass ... py> next(your()) Traceback (most recent call last): File "", line 1, in TypeError: your object is not an iterator Regards, Martin ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
> +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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 as release manager. Brilliant! -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] unicode_internal codec and the PEP 393
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 real representation (Py_UCS1*, Py_UCS2 or Py_UCS4* string)
>
> It's described as "Return the internal representation of the operand".
> That would suggest that the last choice (i.e. return the real internal
> representation) would be best, except that this doesn't round-trip.
> Adding a prefix byte indicating the kind (and perhaps also the ASCII
> flag) would then be closest to the real representation.
>
> As that is likely not very useful, and might break some applications
> of the encoding (if there are any at all) which might expect to
> pass unicode-internal strings across Python versions, I would then
> also deprecate the encoding.
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.
Programs use maybe unicode_internal to decode strings coming from libraries
using wchar_t* (and no PyUnicodeObject).
taskcoach, drag & drop code using wxPython:
data = self.__thunderbirdMailDataObject.GetData()
# We expect the data to be encoded with 'unicode_internal',
# but on Fedora it can also be 'utf-16', be prepared:
try:
data = data.decode('unicode_internal')
except UnicodeDecodeError:
data = data.decode('utf-16')
=> thunderbirdMailDataObject.GetData() result type should be a Unicode, not
bytes
hydrat, tokenizer:
def bytes(str):
return filter(lambda x: x != '\x00', str.encode('unicode_internal'))
=> this algorithm is really strange...
djebel, fscache/rst.py
class RstDocument(object):
...
def __init__(self, path, options={}):
opts = {'input_encoding': 'euc-jp',
'output_encoding': 'unicode_internal',
'doctitle_xform': True,
'file_insertion_enabled': True}
...
doctree = core.publish_doctree(source=file(path, 'rb').read(),
...,
settings_overrides=opts)
...
content = parts['html_body'] or u''
if not isinstance(content, unicode):
content = unicode(content, 'unicode_internal')
if not isinstance(title, unicode):
title = unicode(title, 'unicode_internal')
...
=> I don't understand this code
Victor
___
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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 see that now. > > Idea 2: If "What's New in Python 3.3 Alpha 1?" had two major sections" NEW > FEATURES and BUG FIXES (since 3.2.0) with duplicated subheaders, and if the > subheaders were tagged, like > Core and Builtins -- Features > Core and Builtins -- Fixes > and if the subheaders for 3.2.z, z>=1 had the latter tags, then the context > for merges of bug fixes would not be disturbed by the interposition of > feature items. There would only be a problem when the first merge of a > subsection for a 3.2.z, z>=2 release is not the first item in the > corresponding section for 3.3.0alpha1. Alas, things sometimes don't divide that cleanly - sometimes an API change/addition is part of fixing a bug rather than a new feature in its own right. A custom merge function along the lines of the one you suggest (i.e. if it's after a section header in 3.2.x Misc/NEWS, add it after the first occurrence of the same header in 3.3) is probably the way to go. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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(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 debate. At the same time, "yield expr, expr" works; Um, no, that's a syntax error in any context, as far as I can see. but does "yield from expr, expr" mean anything? In my current grammar, it's a syntax error on its own, but 'f(yield from x, y)' parses as 'f((yield from x), y)', which seems like a reasonable interpretation to me. What's not quite so reasonable is that if you have an expression such as f(x) + g(y) and you decide to turn f into a generator, the obvious way to rewrite it would be yield from f(x) + g(y) but that unfortunately parses as yield from (f(x) + g(y)) If I'd thought about this more at the time, I would probably have tried to make the argument to yield-from something further down in the expression hierarchy, such as a power. That might be tricky to achieve while keeping the existing behaviour of 'yield', though. -- Greg ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
-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 occasional ambiguous item not fixed before. I am confused. My usual usage case is this: 1. I fix something in 3.2. 2. I merge that fix into 3.3. Everything goes smooth except Misc/NEWS. 3. Recover the original 3.3 Misc/NEWS, and add manually what I added to the 3.2 Misc/NEWS. Mark the file as "resolved" and commit. I would like to avoid (3). A custom merge script is an option, but seems complicated and error prone. I have the feeling that structuring Misc/NEWS in the right way could solve it automatically. Something like adding patches to be up-ported/merged at the end of the section, 3.3 only patches be added at the beginning, so they don't conflict. A bit of discipline and, voila, automatic flawless merges! :-) - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTrr87plgi5GaxT1NAQL5GgQAnKsWb4TM1oXXo4Dg84XFIHoKpxQQwRWq oKFIaddNOaZ3wp+ccR0G2aoi+LX2BrsEn3sBL7RXRXVFPludGDvonWcvHar/2DLw E52jDytiMd0gED5TkyqPdck3s6NhUCaZz1qfncI9jHkb2/rznXiBK0mLD+suRleu f+AQ6yoPD2o= =ruC4 -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
-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 3.2.0, not against whatever the latest > release of 3.2 happens to be when 3.3 is released. But fixes in 3.2.x should be incorporated to 3.3, and be in the Misc/NEWS. The general rule is that everything committed to 3.2 is merged to 3.3 (with very few exceptions, managed via dummy merges, like changing the version from "3.2.2" to "3.2.3") - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTrr9oZlgi5GaxT1NAQIPUAP/YQJ4gG1ES0x2LiFN8Hinvk9snUqHJMjC GrgjTGeqAcFBt6vZxVC7UujKwync4BSVPtXX/Fogzj/P3yjN2hNRf/YoL5kHqIID W8HdY0n8ncfiy3ekgpa3i+8Ie4lnSw4OxnxEZMnGkKoH38HCPaRmH1yvcGQsy2yL ZgTwVOM/eUk= =bNy+ -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 features > > and the occasional ambiguous item not fixed before. > > I am confused. My usual usage case is this: > > 1. I fix something in 3.2. > 2. I merge that fix into 3.3. Everything goes smooth except Misc/NEWS. > 3. Recover the original 3.3 Misc/NEWS, and add manually what I added > to the 3.2 Misc/NEWS. Mark the file as "resolved" and commit. > > I would like to avoid (3). You can avoid (3) by resolving the conflict by hand instead. It isn't as smooth as if the merge had gone through without any conflict, but I find it relatively painless in practice. 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 conflicts. To avoid this, we have come up with a scheme involving separate files for each change. Changes must be accompanied by an entry in at least one topfiles directory. [...] An entry must be a file named .. You should replace with the ticket number which is being resolved by the change (if multiple tickets are resolved, multiple files with the same contents should be added)” Regards Antoine. ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 > debate. 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 syntax, that can be added later (either in 3.3 or a later release). Tim Delaney ___ 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
Re: [Python-Dev] unicode_internal codec and the PEP 393
> 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 encoding sounds fine to me as well. Regards, Martin ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 suggest including the following new section just before the copyright section: And Now For Something Completely Different = Sorry, sorry, that's just being too silly. While the language may be named after a British comedy troupe (and the overall tone of this PEP reflects that), there are some serious reasons that explain why there won't be an official 2.8 release from the CPython development team. If a search for "Python 2.8" brought you to this document, you may not be aware of the underlying problems in the design of Python 2.x that led to the creation of the 3.x series. First and foremost, Python 2.x is a language with ASCII text at its core. The main text manipulation interfaces, the standard I/O stack and many other elements of the standard library are built around that assumption. While Unicode is supported, it's quite clearly an added on feature rather than something that is fundamental to the language. Python 3.x changes that core assumption, instead building the language around Unicode text. This affects the builtin ``str`` type (which is now Unicode text rather than 8-bit data), the standard I/O stack (which now supports Unicode encoding concepts directly), what identifier and module names are legal (with most Unicode alphanumeric characters being supported) and several other aspects of the language. With the text handling and associated I/O changes breaking backwards compatibility *anyway*, Guido took the opportunity to finally eliminate some other design defects in Python 2.x that had been preserved solely for backwards compatibility reasons. These changes include: - complete removal of support for "classic" (i.e. pre-2.2 style) class semantics - the separate ``int`` (machine level integer) and ``long`` (arbitrarily large) integer types have been merged into a single ``int`` type (that supports arbitrarily large values) - integer division now promotes non-integer results to binary floating values automatically - the error prone ``except Exception, exc:`` syntax has been removed (in favour of the more explicit ``except Exception as exc:``) - ``print`` and ``exec`` are now ordinary functions rather than statements - the backtick based ```x``` alternate spelling of ``repr(x)`` has been removed - the ``<>`` alternate spelling of ``!=`` has been removed - implicit relative imports have been removed - star imports (i.e. ``from x import *``) are now permitted only in module level code - implicit ordering comparisons between objects of different types have been removed - list comprehensions no longer leak their iteration variables into the surrounding scope - many APIs that previously returned lists now return iterators or lightweight views instead (e.g. ``map`` produces an iterator, ``range`` creates a virtual sequence, ``dict.keys`` a view of the original dict) - iterator advancement is now via a protocal-based builtin (``next()`` invoking ``__next__()``) rather than an ordinary method call - some rarely needed builtins have been relocated to standard library modules (``reduce`` is now ``functools.reduce``, ``reload`` is now ``imp.reload``) - some areas of the standard library have been rearranged in an attempt to make the naming schemes more intuitive More details on the backwards incompatible changes relative to the 2.x series can be found in the `Python 3.0 What's New`_ document. With the 3.x Unicode based architecture providing a significantly better foundation for a language with a global audience, all new features will appear solely in the Python 3.x series. However, as detailed elsewhere, the 2.7 release will still be supported with bug fixes and maintenance releases for several years. .. _`Python 3.0 What's New`: http://docs.python.org/py3k/whatsnew/3.0.html -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 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 > debate. We're having the debate now. :-) I can't find anywhere in the PEP where it says what the operator priority of "yield from" is, so you can't blame me for thinking the priority should be the same as for "yield". >> At the same time, "yield expr, expr" works; > > Um, no, that's a syntax error in any context, as far as I > can see. Actually it is valid, meaning "yield (expr, expr)" in any context where "yield expr" is valid (please let me know if there are any contexts where that isn't true): >>> def foo(): ... yield 1, 1 ... >>> def foo(): ... if (yield 1, 1): pass ... >>> def foo(): ... bar((yield 1, 1)) ... >>> def foo(): ... x = yield 1, 1 ... >> but does "yield from expr, expr" mean anything? > > In my current grammar, it's a syntax error on its own, > but 'f(yield from x, y)' parses as 'f((yield from x), y)', > which seems like a reasonable interpretation to me. Once you realize that "yield from x, y" has no meaning, sure. But without thinking deeper about that I can't prove that we'll never find a meaning for it. We had a similar limitation for "with a, b:" -- initially it was illegal, eventually we gave it a meaning. > What's not quite so reasonable is that if you have an > expression such as > > f(x) + g(y) > > and you decide to turn f into a generator, the obvious > way to rewrite it would be > > yield from f(x) + g(y) > > but that unfortunately parses as > > yield from (f(x) + g(y)) Well duh. :-) > If I'd thought about this more at the time, I would > probably have tried to make the argument to yield-from > something further down in the expression hierarchy, > such as a power. That might be tricky to achieve > while keeping the existing behaviour of 'yield', > though. IMO that would be the wrong priority for a keyword-based operator. Note that 'not' also has a very low priority. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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 the following new >section just before the copyright section: You have a very good point. I think I'd like a shorter 'serious' section though. Let me see what I can put together. -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule
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! Vinay? :) 410 Gone would be more appropriate IMO. But 404 does have more mindshare. Tim Delaney ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 break it, sorry! -- Greg ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 syntax, that can be added later (either in 3.3 or a later release). That's fair enough. I'll shut up now. -- Greg ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 conflicts. To avoid > this, we have come up with a scheme involving separate files for each > change. > > Changes must be accompanied by an entry in at least one topfiles > directory. [...] > An entry must be a file named .. You should > replace with the ticket number which is being resolved > by the change (if multiple tickets are resolved, multiple files with > the same contents should be added)” An approach like that would also have the virtue of avoiding conflicts if you set up a NEWS file change in a feature branch that ends up being in use for longer than you originally thought. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 playing with it. If the discussion comes to a consensus on more >> relaxed syntax, that can be added later (either in 3.3 or a later >> release). > > That's fair enough. I'll shut up now. No worries - given the dance you had to go through in the Grammar file to make it work in the first place, I should have realised you'd done it deliberately. (The mention of the 'yield_from' node in the doc patch I was reviewing is actually what got me looking into this). As I said earlier, 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 (following the generator expression precedent), but that's a tricky change given the parser limitations. The way your patch tried to do it also allowed "f(yield from x, 1)" which strikes me as being far too confusing to a human reader, even if the parser understands it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
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 too confusing Since 'yield from' is intended mainly for delegating to another generator, the 'x' there will usually be a function call, so you'll be looking at something like f(yield from g(x), 1) which doesn't look very confusing to me, but maybe I'm not impartial enough to judge. In any case, I'm now pursuing cofunctions as a better way of doing lightweight threading, so this issue probably doesn't matter so much. -- Greg ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 suggestion looks to be analogous to STM. ___ 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
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
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 that is less than automatic or flawless. :-) > > Antoine's suggestion looks to be analogous to STM. It's more like shared-nothing, actually. (but that's not my suggestion, just a mention of how another project deals with the issue; I find the current situation quite manageable myself) Regards Antoine. ___ 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
