Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum wrote: >> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan wrote: >> > This version looks fine to me. > > Same to me, mostly. I've updated the PEP per everyone's comments [1], except I still haven't dropped the read-only __definition_order__ constraint. I'll do that when I resolve the open questions, on which I'd like some feedback: * What about __slots__? In addition to including __slots__ in __definition_order__, the options I see are to either ignore the names in __slots__, put them into __definition_order__ right after __slots__, or stick them in at the end (since their descriptors are added afterward). I'm leaning toward the first one, leaving the slot names out of __definition_order__ since the names aren't actually part of the definition (__slots__ itself is). Doing so doesn't lose any information and more closely reflects the class definition body. * Allow setting __definition_order__ in type()? I don't see any reason to disallow "__definition_order__" in the namespace passed in to the 3 argument form of builtins.type(). Then dynamically created types can have a definition order (without needing to set cls.__definition_order__ afterward). * C-API for setting __definition_order__? I'd rather avoid any extra complexity in the PEP due to diving into C-API support for *creating* types with a __definition_order__. However, if it would be convenient enough and not a complex endeavor, I'm willing to accommodate that case in the PEP. At the same time, at the C-API level is it so important to accommodate __definition_order__ at class-creation time? Can't you directly modify cls.__dict__ in C? Perhaps it would be safer to have a simple C-API function to set __definition_order__ for you? * Drop the "read-only attribute" requirement? I really like that read-only implies "complete", which is a valuable message for __definition_order__ to convey. I think that there's a lot to be said for communicating about a value in that way. At the same time, most of the time Python doesn't keep you from fiddling with similar "complete" values (e.g. __name__, __slots__), so I see that point too. And since the interpreter (nor stdlib) doesn't rely on __definition_order__, it isn't much of a footgun (nor would setting __definition_order__ be much of an attractive nuisance). I suppose I'm having a hard time letting go of the attractiveness of "read-only == complete". However, given that you've been pretty clear what you think, I'm more at ease about it. :) Anyway, thoughts on the above would be helpful. I'll try to be responsive so we can wrap this up. -eric [1] https://github.com/python/peps/blob/master/pep-0520.txt ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow wrote: > On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum wrote: >>> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan wrote: >>> > This version looks fine to me. >> >> Same to me, mostly. > > I've updated the PEP per everyone's comments [1], except I still > haven't dropped the read-only __definition_order__ constraint. I'll > do that when I resolve the open questions, on which I'd like some > feedback: > > * What about __slots__? > > In addition to including __slots__ in __definition_order__, the > options I see are to either ignore the names in __slots__, put them > into __definition_order__ right after __slots__, or stick them in at > the end (since their descriptors are added afterward). I'm leaning > toward the first one, leaving the slot names out of > __definition_order__ since the > names aren't actually part of the definition (__slots__ itself is). > Doing so doesn't lose any information and more closely reflects the > class definition body. Sounds fine. I guess this means you don't have to do anything special, right? > * Allow setting __definition_order__ in type()? > > I don't see any reason to disallow "__definition_order__" in the > namespace passed in to the 3 argument form of builtins.type(). Then > dynamically created types can have a definition order (without needing > to set cls.__definition_order__ afterward). Right. > * C-API for setting __definition_order__? > > I'd rather avoid any extra complexity in the PEP due to diving into > C-API support for *creating* types with a __definition_order__. > However, if it would be convenient enough and not a complex endeavor, > I'm willing to accommodate that case in the PEP. At the same time, at > the C-API level is it so important to accommodate > __definition_order__ at class-creation time? Can't you directly > modify cls.__dict__ in C? Perhaps it would be safer to have a simple > C-API function to set __definition_order__ for you? What's the use case even? I think if __definition_order__ is writable then C code can just use PyObject_SetAttrString(, "__definition_order__", ). > * Drop the "read-only attribute" requirement? > > I really like that read-only implies "complete", which is a valuable > message for __definition_order__ to convey. I think that there's a > lot to be said for communicating about a value in that way. But it's still unique behavior, and it's not needed to protect CPython internals. > At the same time, most of the time Python doesn't keep you from > fiddling with similar "complete" values (e.g. __name__, __slots__), so > I see that point too. And since the interpreter (nor stdlib) doesn't > rely on __definition_order__, it isn't much of a footgun (nor would > setting __definition_order__ be much of an attractive nuisance). > > I suppose I'm having a hard time letting go of the attractiveness of > "read-only == complete". However, given that you've been pretty clear > what you think, I'm more at ease about it. :) Yeah, it's time to drop it. ;-) > Anyway, thoughts on the above would be helpful. I'll try to be > responsive so we can wrap this up. > > -eric > > > [1] https://github.com/python/peps/blob/master/pep-0520.txt -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
On Tue, Jun 28, 2016 at 11:43 AM, Guido van Rossum wrote: > On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow > wrote: >> I suppose I'm having a hard time letting go of the attractiveness of >> "read-only == complete". However, given that you've been pretty clear >> what you think, I'm more at ease about it. :) > > Yeah, it's time to drop it. ;-) Thanks for the feedback. I've updated the PEP to resolve the open questions. Most notably, I've dropped the read-only constraint on the __definition_order__ attribute. Please let me know if you have any other outstanding concerns. Otherwise I think this PEP is ready for pronouncement. :) -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
Awesome. That addresses my last concerns. PEP 520 is now accepted. Congratulations! On Tue, Jun 28, 2016 at 1:43 PM, Eric Snow wrote: > On Tue, Jun 28, 2016 at 11:43 AM, Guido van Rossum wrote: >> On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow >> wrote: >>> I suppose I'm having a hard time letting go of the attractiveness of >>> "read-only == complete". However, given that you've been pretty clear >>> what you think, I'm more at ease about it. :) >> >> Yeah, it's time to drop it. ;-) > > Thanks for the feedback. I've updated the PEP to resolve the open > questions. Most notably, I've dropped the read-only constraint on the > __definition_order__ attribute. Please let me know if you have any > other outstanding concerns. Otherwise I think this PEP is ready for > pronouncement. :) > > -eric -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
On 06/28/2016 01:55 PM, Guido van Rossum wrote: Awesome. That addresses my last concerns. PEP 520 is now accepted. Congratulations! And more Congratulations!! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request for CPython 3.5.3 release
Long story short, I've discovered that asyncio is broken in 3.5.2. Specifically, there is a callbacks race in `loop.sock_connect` which can make subsequent `loop.sock_sendall` calls to hang forever. This thing is very tricky and hard to detect and debug; I had to spend a few hours investigating what's going on with a failing unittest in uvloop (asyncio-compatible event loop). I can only imagine how hard it would be to understand what's going on in a larger codebase. For those who is interested, here's a PR for asyncio repo: https://github.com/python/asyncio/pull/366 It explains the bug in detail and there has a proposed patch to fix the problem. Larry and the release team: would it be possible to make an "emergency" 3.5.3 release? Going forward, we need to increase the number of functional tests for asyncio, as most of the current tests use mocks. I'm going to port all functional tests from uvloop to asyncio as a start. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
On Jun 28, 2016 2:56 PM, "Guido van Rossum" wrote: > > Awesome. That addresses my last concerns. PEP 520 is now accepted. > Congratulations! Yay! Thank you and to all those that gave such good feedback. -eric (phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for CPython 3.5.3 release
On 06/28/2016 02:05 PM, Yury Selivanov wrote: Long story short, I've discovered that asyncio is broken in 3.5.2. Specifically, there is a callbacks race in `loop.sock_connect` which can make subsequent `loop.sock_sendall` calls to hang forever. This thing is very tricky and hard to detect and debug; I had to spend a few hours investigating what's going on with a failing unittest in uvloop (asyncio-compatible event loop). I can only imagine how hard it would be to understand what's going on in a larger codebase. For those who is interested, here's a PR for asyncio repo: https://github.com/python/asyncio/pull/366 It explains the bug in detail and there has a proposed patch to fix the problem. Larry and the release team: would it be possible to make an "emergency" 3.5.3 release? I've looped in the rest of the 3.5 release team. By the way, I don't know why you Cc'd Nick and Brett. While they're fine fellows, they aren't on the release team, and they aren't involved in these sorts of decisions. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for CPython 3.5.3 release
On 06/28/2016 02:05 PM, Yury Selivanov wrote: Larry and the release team: would it be possible to make an "emergency" 3.5.3 release? I'd like to hear from the other asyncio reviewers: is this bug bad enough to merit such an "emergency" release? Thanks, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for CPython 3.5.3 release
> On Jun 29, 2016, at 12:42 AM, Larry Hastings wrote: > > By the way, I don't know why you Cc'd Nick and Brett. While they're fine > fellows, they aren't on the release team, and they aren't involved in these > sorts of decisions. We're all involved in those sort of decisions. Raymond ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for CPython 3.5.3 release
On 06/28/2016 04:23 PM, Raymond Hettinger wrote: On Jun 29, 2016, at 12:42 AM, Larry Hastings wrote: By the way, I don't know why you Cc'd Nick and Brett. While they're fine fellows, they aren't on the release team, and they aren't involved in these sorts of decisions. We're all involved in those sort of decisions. Raymond Perhaps, but that would make the Cc: list intractably long. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 495 implementation
Dear All, I have not received any responses since my first post in this thread in September last year. This time I am adding python-dev to BCC in hopes to reach a larger audience. With the date of the first beta (2016-09-07) fast approaching, I would like to commit PEP 495 implementation hopefully before alpha 3 (2016-07-11). I have a patch published as a pull request [1] against the python/cpython repository on github. If anyone still prefers the bug tracker workflow, I can publish it as a patch for issue #24773 [2] as well. Please also see my post from March below. Since that post, I have implemented a -utzdata option to the regression test, so now the long exhaustive test only runs when you do python -mtest -utzdata. Note that this test currently fails on a couple exotic timezones such as Asia/Riyadh87, but it is likely to be an issue with the timezone database rather than python code. I still don't have access to a Windows development box and I know that the current implementation will not work there because I use localtime_r. I need help/advise on this front. I have not started updating the documentation, so the PEP text [3] should serve as the documentation for now. I will try to get the documentation patch ready before the beta, but I don't want to delay checking in the code. On Mon, Mar 21, 2016 at 10:34 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > Dear All, > > I am getting close to completing PEP 495 implementation, but I need someone to help me with a port to Windows. One of the major obstacles is that my implementation relies heavily on the POSIX localtime_r function which apparently is not available on Windows. > > I would also appreciate help from a unittest expert to improve test_datetime. One of the pressing tasks is to make ZoneInfoCompleteTest optional because it takes several minutes to complete. > > I am maintaining the patch as a pull request [1] against the python/cpython repository on github. Code reviews are most welcome. > > [1]: https://github.com/python/cpython/pull/20 [2]: http://bugs.python.org/issue24773 [3]: https://www.python.org/dev/peps/pep-0495 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
