Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Thu, 8 Sep 2016 14:20:53 -0700 Victor Stinner wrote: > 2016-09-08 13:36 GMT-07:00 Guido van Rossum : > > IIUC there's one small thing we might still want to change somewhere > > after 3.6b1 but before 3.6rc1: the order is not preserved when you > > delete some keys and then add some other keys. Apparently PyPy has > > come up with a clever solution for this, and we should probably adopt > > it, but it's probably best not to hurry that for 3.6b1. > > Very good news: I was wrong, Raymond Hettinger confirmed that the > Python 3.6 dict *already* preserves the items order in all cases. In > short, Python 3.6 dict = Python 3.5 OrderedDict (in fact, OrderedDict > has a few more methods). Is it an official feature of the language or an implementation detail? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Fri, Sep 9, 2016 at 10:55 AM, Antoine Pitrou wrote: > On Thu, 8 Sep 2016 14:20:53 -0700 > Victor Stinner wrote: >> 2016-09-08 13:36 GMT-07:00 Guido van Rossum : >> > IIUC there's one small thing we might still want to change somewhere >> > after 3.6b1 but before 3.6rc1: the order is not preserved when you >> > delete some keys and then add some other keys. Apparently PyPy has >> > come up with a clever solution for this, and we should probably adopt >> > it, but it's probably best not to hurry that for 3.6b1. >> >> Very good news: I was wrong, Raymond Hettinger confirmed that the >> Python 3.6 dict *already* preserves the items order in all cases. In >> short, Python 3.6 dict = Python 3.5 OrderedDict (in fact, OrderedDict >> has a few more methods). > > Is it an official feature of the language or an implementation detail? > > Regards > > Antoine. I think an implementation detail (although I'm not opposed to having it mentioned in the spec), but using the same/similar approach for sets should be mostly relatively simple, no? PyPy has a pure python OrderedDict which is a wrapper around dict. For 3.6 it needs an adjustement since new methods showed up ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-09-02 - 2016-09-09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5568 (-62) closed 34233 (+166) total 39801 (+104) Open issues with patches: 2402 Issues opened (64) == #17602: mingw: default sys.path calculations for windows platforms http://bugs.python.org/issue17602 reopened by martin.panter #26513: platform.win32_ver() broken in 2.7.11 http://bugs.python.org/issue26513 reopened by steve.dower #27778: PEP 524: Add os.getrandom() http://bugs.python.org/issue27778 reopened by martin.panter #27938: PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for http://bugs.python.org/issue27938 reopened by haypo #27942: Default value identity regression http://bugs.python.org/issue27942 opened by Kay.Hayen #27943: pstats.Stats: missing the source OS setting argument in strip_ http://bugs.python.org/issue27943 opened by Jaroslav #27945: Various segfaults with dict http://bugs.python.org/issue27945 opened by tehybel #27946: issues in elementtree and elsewhere due to PyDict_GetItem http://bugs.python.org/issue27946 opened by tehybel #27948: f-strings: allow backslashes only in the string parts, not in http://bugs.python.org/issue27948 opened by eric.smith #27950: Superfluous messages when running make http://bugs.python.org/issue27950 opened by xiang.zhang #27951: the reply's additional "Re:" is ok http://bugs.python.org/issue27951 opened by saifmega #27952: Finish converting fixcid.py from regex to re http://bugs.python.org/issue27952 opened by serhiy.storchaka #27954: makesetup does not take into account subdirectories http://bugs.python.org/issue27954 opened by David D #27955: getrandom() syscall returning EPERM make the system unusable. http://bugs.python.org/issue27955 opened by iwings #27963: null poiter dereference in set_conversion_mode due uncheck _ct http://bugs.python.org/issue27963 opened by minhrau #27965: Automatic .py extension when saving with IDLE on OSX http://bugs.python.org/issue27965 opened by InfiniteHybrid #27966: PEP-397 documents incorrect registry path http://bugs.python.org/issue27966 opened by mhammond #27971: utf-16 decoding can't handle lone surrogates http://bugs.python.org/issue27971 opened by lazka #27972: Confusing error during cyclic yield http://bugs.python.org/issue27972 opened by Max von Tettenborn #27973: urllib.urlretrieve() fails on second ftp transfer http://bugs.python.org/issue27973 opened by Sohaib Ahmad #27976: Deprecate building with bundled copy of libffi on non-Darwin P http://bugs.python.org/issue27976 opened by zach.ware #27977: smtplib send_message does not correctly handle unicode address http://bugs.python.org/issue27977 opened by r.david.murray #27978: Executor#shutdown with timeout http://bugs.python.org/issue27978 opened by Patrik Dufresne #27979: Remove bundled libffi http://bugs.python.org/issue27979 opened by zach.ware #27981: Reference leak in fp_setreadl() of Parser/tokenizer.c http://bugs.python.org/issue27981 opened by haypo #27984: singledispatch register should typecheck its argument http://bugs.python.org/issue27984 opened by amogorkon #27986: make distclean clobbers Lib/plat-darwin/* http://bugs.python.org/issue27986 opened by zach.ware #27987: obmalloc's 8-byte alignment causes undefined behavior http://bugs.python.org/issue27987 opened by benjamin.peterson #27989: incomplete signature with help function using typing http://bugs.python.org/issue27989 opened by David E. Franco G. #27990: Provide a way to enable getrandom on Linux even when build sys http://bugs.python.org/issue27990 opened by ncoghlan #27991: In the argparse howto there is a misleading sentence about sto http://bugs.python.org/issue27991 opened by py.user #27992: In the argparse there is a misleading words about %(prog)s val http://bugs.python.org/issue27992 opened by py.user #27994: In the argparse help(argparse) prints weird comments instead o http://bugs.python.org/issue27994 opened by py.user #27995: Upgrade Python 3.4 to OpenSSL 1.0.2h on Windows http://bugs.python.org/issue27995 opened by scw #27997: ImportError should be raised consistently from import machiner http://bugs.python.org/issue27997 opened by eric.snow #27998: Remove support of bytes paths in os.scandir() http://bugs.python.org/issue27998 opened by serhiy.storchaka #27999: Make "global after use" a SyntaxError http://bugs.python.org/issue27999 opened by levkivskyi #28000: Build fails on AIX with _LINUX_SOURCE_COMPAT flag http://bugs.python.org/issue28000 opened by sarterm #28001: test.support.open_urlresource should work from an installed Py http://bugs.python.org/issue28001 opened by zach.ware #28002: Some f-strings do not round trip through Tools/parser/test_unp http://bugs.python.org/issue28002 opened by eric.smith #28004: Optimize bytes.
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Fri, 9 Sep 2016 at 01:58 Antoine Pitrou wrote: > On Thu, 8 Sep 2016 14:20:53 -0700 > Victor Stinner wrote: > > 2016-09-08 13:36 GMT-07:00 Guido van Rossum : > > > IIUC there's one small thing we might still want to change somewhere > > > after 3.6b1 but before 3.6rc1: the order is not preserved when you > > > delete some keys and then add some other keys. Apparently PyPy has > > > come up with a clever solution for this, and we should probably adopt > > > it, but it's probably best not to hurry that for 3.6b1. > > > > Very good news: I was wrong, Raymond Hettinger confirmed that the > > Python 3.6 dict *already* preserves the items order in all cases. In > > short, Python 3.6 dict = Python 3.5 OrderedDict (in fact, OrderedDict > > has a few more methods). > > Is it an official feature of the language or an implementation detail? > It depends on the context. **kwargs is now defined to be an ordered mapping and PEP 520 has been updated to drop __definition_order__ and to say that cls.__dict__ is an ordered mapping. Otherwise we have not made dict itself ordered everywhere. And there has been discussion to rip out the C code for OrderedDict and change the Python code to subclass dict so it only has to provide its additions to the dict API. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Friday, September 9, 2016 4:52:21 PM EDT Brett Cannon wrote: > On Fri, 9 Sep 2016 at 01:58 Antoine Pitrou wrote: > > On Thu, 8 Sep 2016 14:20:53 -0700 > > > > Victor Stinner wrote: > > > 2016-09-08 13:36 GMT-07:00 Guido van Rossum : > > > > IIUC there's one small thing we might still want to change somewhere > > > > after 3.6b1 but before 3.6rc1: the order is not preserved when you > > > > delete some keys and then add some other keys. Apparently PyPy has > > > > come up with a clever solution for this, and we should probably adopt > > > > it, but it's probably best not to hurry that for 3.6b1. > > > > > > Very good news: I was wrong, Raymond Hettinger confirmed that the > > > Python 3.6 dict *already* preserves the items order in all cases. In > > > short, Python 3.6 dict = Python 3.5 OrderedDict (in fact, OrderedDict > > > has a few more methods). > > > > Is it an official feature of the language or an implementation detail? > > It depends on the context. **kwargs is now defined to be an ordered mapping > and PEP 520 has been updated to drop __definition_order__ and to say that > cls.__dict__ is an ordered mapping. Otherwise we have not made dict itself > ordered everywhere. > > And there has been discussion to rip out the C code for OrderedDict and > change the Python code to subclass dict so it only has to provide its > additions to the dict API. Are there any downsides to explicitly specifying that all dicts are ordered? People will inevitably start relying on this behaviour, and this will essentially become the *de-facto* spec, so alternative Python implementations will have to follow suit anyway. Elvis ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
I've been asked about this. Here's my opinion on the letter of the law in 3.6: - keyword args are ordered - the namespace passed to a metaclass is ordered by definition order - ditto for the class __dict__ A compliant implementation may ensure the above three requirements either by making all dicts ordered, or by providing a custom dict subclass (e.g. OrderedDict) in those three cases. I'd like to handwave on the ordering of all other dicts. Yes, in CPython 3.6 and in PyPy they are all ordered, but it's an implementation detail. I don't want to *force* all other implementations to follow suit. I also don't want too many people start depending on this, since their code will break in 3.5. (Code that needs to depend on the ordering of keyword args or class attributes should be relatively uncommon; but people will start to depend on the ordering of all dicts all too easily. I want to remind them that they are taking a risk, and their code won't be backwards compatible.) --Guido On Fri, Sep 9, 2016 at 9:52 AM, Brett Cannon wrote: > > > On Fri, 9 Sep 2016 at 01:58 Antoine Pitrou wrote: >> >> On Thu, 8 Sep 2016 14:20:53 -0700 >> Victor Stinner wrote: >> > 2016-09-08 13:36 GMT-07:00 Guido van Rossum : >> > > IIUC there's one small thing we might still want to change somewhere >> > > after 3.6b1 but before 3.6rc1: the order is not preserved when you >> > > delete some keys and then add some other keys. Apparently PyPy has >> > > come up with a clever solution for this, and we should probably adopt >> > > it, but it's probably best not to hurry that for 3.6b1. >> > >> > Very good news: I was wrong, Raymond Hettinger confirmed that the >> > Python 3.6 dict *already* preserves the items order in all cases. In >> > short, Python 3.6 dict = Python 3.5 OrderedDict (in fact, OrderedDict >> > has a few more methods). >> >> Is it an official feature of the language or an implementation detail? > > > It depends on the context. **kwargs is now defined to be an ordered mapping > and PEP 520 has been updated to drop __definition_order__ and to say that > cls.__dict__ is an ordered mapping. Otherwise we have not made dict itself > ordered everywhere. > > And there has been discussion to rip out the C code for OrderedDict and > change the Python code to subclass dict so it only has to provide its > additions to the dict API. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
2016-09-09 10:17 GMT-07:00 Guido van Rossum : > - keyword args are ordered > - the namespace passed to a metaclass is ordered by definition order > - ditto for the class __dict__ Maybe we should define exactly "ordered" somewhere the language reference: https://docs.python.org/dev/reference/index.html I expect: * a mapping: mapping ABC, https://docs.python.org/dev/library/collections.abc.html#collections-abstract-base-classes * ordered by definition order * no more I mean: OrderedDict has extra methods, __reversed__() and move_to_end(). Users should not rely on them. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Fri, 9 Sep 2016 at 10:28 Victor Stinner wrote: > 2016-09-09 10:17 GMT-07:00 Guido van Rossum : > > - keyword args are ordered > > - the namespace passed to a metaclass is ordered by definition order > > - ditto for the class __dict__ > > Maybe we should define exactly "ordered" somewhere the language reference: > https://docs.python.org/dev/reference/index.html > > I expect: > > * a mapping: mapping ABC, > > https://docs.python.org/dev/library/collections.abc.html#collections-abstract-base-classes > * ordered by definition order > * no more > > I mean: OrderedDict has extra methods, __reversed__() and > move_to_end(). Users should not rely on them. > Adding "ordered mapping" to the glossary and linking to the term from the language spec should cover that. Maybe Eric can add it since he made the spec updates earlier? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote: >Are there any downsides to explicitly specifying that all dicts are ordered? >People will inevitably start relying on this behaviour, and this will >essentially become the *de-facto* spec, so alternative Python implementations >will have to follow suit anyway. It *might* make sense to revisit this once 3.5 is no longer maintained at all, but I think Guido's exactly right in his analysis. If people start relying on all dicts being ordered now, their code won't be compatible with both 3.5 and 3.6, and I think it's important to emphasize this to developers. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
It seems unlikely, but not inconceivable, that someday in the future someone will implement a dictionary that is faster than current versions but at the cost of losing inherent ordering. It feels best to me only to promise order in specific cases like kwargs, but say nothing (even in 3.6 or 3.7) about the requirement for how dict itself is implemented. On Sep 9, 2016 11:39 AM, "Barry Warsaw" wrote: > On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote: > > >Are there any downsides to explicitly specifying that all dicts are > ordered? > >People will inevitably start relying on this behaviour, and this will > >essentially become the *de-facto* spec, so alternative Python > implementations > >will have to follow suit anyway. > > It *might* make sense to revisit this once 3.5 is no longer maintained at > all, > but I think Guido's exactly right in his analysis. If people start > relying on > all dicts being ordered now, their code won't be compatible with both 3.5 > and > 3.6, and I think it's important to emphasize this to developers. > > Cheers, > -Barry > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > mertz%40gnosis.cx > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Friday, September 9, 2016 2:01:08 PM EDT David Mertz wrote: > It feels best to me only to promise order in specific cases like kwargs, > but say nothing (even in 3.6 or 3.7) about the requirement for how dict > itself is implemented. On Saturday, September 10, 2016 6:39:27 AM EDT Barry Warsaw wrote: > If people start relying on all dicts being ordered now, their code won't > be compatible with both 3.5 and 3.6, and I think it's important to > emphasize this to developers. OK, that makes sense. Putting an explicit note in the documentation that one should not rely on the key order will probably be enough to reduce the concern. Elvis ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Porting buildbot to Python 3
Hi, It's not essential, but I thought it would be nice to port buildbot to Python 3. I've managed to submit multiple simple patches to buildbot, which were quickly accepted: https://github.com/buildbot/buildbot/pulls/rodrigc?q=is%3Apr+is%3Aclosed Now things are more slow going as the easy stuff is out of the way and I am submitting more complicated things: https://github.com/buildbot/buildbot/pulls/rodrigc Is there anyone on python-dev who has the interest and free cycles to push Python 3 fixes to the buildbot team? Thanks. -- Craig ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changes to PEP 498 (f-strings)
I found some time before beta 1 to modify the f-string code to implement
the desired behavior: no backslashes inside the curly braces, but
they're allowed in the literal string portions. I just checked it in.
I still need to update PEP 498, and the documentation needs updating.
I'll create an issue for the docs once I've updated the PEP.
This is a fairly large change, because now I need to parse the f-strings
in UTF-8, and do the decoding myself in pieces, instead of the previous
behavior of decoding the string first and then parsing it.
I think I have tests for all of the backslash scenarios, but I'll watch
the buildbots.
Eric.
On 8/30/2016 1:55 PM, Eric V. Smith wrote:
After a long discussion on python-ideas (starting at
https://mail.python.org/pipermail/python-ideas/2016-August/041727.html)
I'm proposing the following change to PEP 498: backslashes inside
brackets will be disallowed. The point of this is to disallow convoluted
code like:
d = {'a': 4}
f'{d[\'a\']}'
'4'
In addition, I'll disallow escapes to be used for brackets, as in:
f'\x7bd["a"]}'
'4'
(where chr(0x7b) == "{").
Because we're so close to 3.6 beta 1, my plan is to:
1. Modify the PEP to reflect these restrictions.
2. Modify the code to prevent _any_ backslashes inside f-strings.
This is a more restrictive change than the PEP will describe, but it's
much easier to implement. After beta 1, and hopefully before beta 2, I
will implement the restrictions as I've outlined above (and as they will
be documented in the PEP). The net effects are:
a. Some code that works in the alphas won't work in beta 1. I'll
document this.
b. All code that's valid in beta 1 will work in beta 2, and some
f-strings that are syntax errors in beta 1 will work in beta 2.
I've discussed this issue with Ned and Guido, who are okay with these
changes.
The python-ideas thread I referenced above has some discussion about
further changes to f-strings. Those proposals are outside the scope of
3.6, but the changes I'm putting forth here will allow for those
additional changes, should we decide to make them. That's a discussion
for 3.7, however.
I'm sending this email out just to notify people of this upcoming
change. I hope this won't generate much discussion. If you feel the need
to discuss this issue further, please use the python-ideas thread (where
some people are already ignoring it!).
Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: make invalid_comma_and_underscore a real prototype
Oops, thanks Benjamin. That was a copy and paste error.
Eric.
On 9/9/2016 11:15 PM, benjamin.peterson wrote:
https://hg.python.org/cpython/rev/1e7b636b6009
changeset: 103539:1e7b636b6009
user:Benjamin Peterson
date:Fri Sep 09 20:14:05 2016 -0700
summary:
make invalid_comma_and_underscore a real prototype
files:
Python/formatter_unicode.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python/formatter_unicode.c b/Python/formatter_unicode.c
--- a/Python/formatter_unicode.c
+++ b/Python/formatter_unicode.c
@@ -41,7 +41,7 @@
}
static void
-invalid_comma_and_underscore()
+invalid_comma_and_underscore(void)
{
PyErr_Format(PyExc_ValueError, "Cannot specify both ',' and '_'.");
}
___
Python-checkins mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changes to PEP 498 (f-strings)
Very happy to hear it. It's almost like you were present at the sprint!
On Fri, Sep 9, 2016 at 7:04 PM, Eric V. Smith wrote:
> I found some time before beta 1 to modify the f-string code to implement the
> desired behavior: no backslashes inside the curly braces, but they're
> allowed in the literal string portions. I just checked it in.
>
> I still need to update PEP 498, and the documentation needs updating. I'll
> create an issue for the docs once I've updated the PEP.
>
> This is a fairly large change, because now I need to parse the f-strings in
> UTF-8, and do the decoding myself in pieces, instead of the previous
> behavior of decoding the string first and then parsing it.
>
> I think I have tests for all of the backslash scenarios, but I'll watch the
> buildbots.
>
> Eric.
>
>
> On 8/30/2016 1:55 PM, Eric V. Smith wrote:
>>
>> After a long discussion on python-ideas (starting at
>> https://mail.python.org/pipermail/python-ideas/2016-August/041727.html)
>> I'm proposing the following change to PEP 498: backslashes inside
>> brackets will be disallowed. The point of this is to disallow convoluted
>> code like:
>>
> d = {'a': 4}
> f'{d[\'a\']}'
>>
>> '4'
>>
>> In addition, I'll disallow escapes to be used for brackets, as in:
>>
> f'\x7bd["a"]}'
>>
>> '4'
>>
>> (where chr(0x7b) == "{").
>>
>> Because we're so close to 3.6 beta 1, my plan is to:
>>
>> 1. Modify the PEP to reflect these restrictions.
>> 2. Modify the code to prevent _any_ backslashes inside f-strings.
>>
>> This is a more restrictive change than the PEP will describe, but it's
>> much easier to implement. After beta 1, and hopefully before beta 2, I
>> will implement the restrictions as I've outlined above (and as they will
>> be documented in the PEP). The net effects are:
>>
>> a. Some code that works in the alphas won't work in beta 1. I'll
>> document this.
>> b. All code that's valid in beta 1 will work in beta 2, and some
>> f-strings that are syntax errors in beta 1 will work in beta 2.
>>
>> I've discussed this issue with Ned and Guido, who are okay with these
>> changes.
>>
>> The python-ideas thread I referenced above has some discussion about
>> further changes to f-strings. Those proposals are outside the scope of
>> 3.6, but the changes I'm putting forth here will allow for those
>> additional changes, should we decide to make them. That's a discussion
>> for 3.7, however.
>>
>> I'm sending this email out just to notify people of this upcoming
>> change. I hope this won't generate much discussion. If you feel the need
>> to discuss this issue further, please use the python-ideas thread (where
>> some people are already ignoring it!).
>>
>> Eric.
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
>>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
