Re: [Python-Dev] What's the status of PEP 515?
On 07.09.16 07:21, Eric V. Smith wrote: The implementation of '_' in numeric literals is here: http://bugs.python.org/issue26331 And to add '_' in int.__format__ is here: http://bugs.python.org/issue27080 But I don't want to add support in int.__format__ unless numeric literal support is added. So, Georg and Serhiy: is issue 26331 going to get committed? If so, I'll commit 27080 (or you can). I just don't want the second part of PEP 515 to not make the deadline if the first part makes it in at the last minute. I had not much time last weeks to make a review of such large patches. I'm going to make a review today. In any case I think the patch is good in general, and if there are any bugs we can fix them in the beta stage. ___ 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] Make "global after use" a SyntaxError
Hi all, The documentation at https://docs.python.org/3/reference/simple_stmts.html says that: "Names listed in a global statement must not be used in the same code block textually preceding that global statement" But then later: "CPython implementation detail: The current implementation does not enforce the two restrictions, but programs should not abuse this freedom, as future implementations may enforce them..." Code like this def f(): x = 1 global x gives SyntaxWarning for several releases, maybe it is time to make it a SyntaxError? (I have opened an issue for this http://bugs.python.org/issue27999 I will submit a patch soon). -- Ivan ___ 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] A Pseudo-Post-Mortem (not dead yet) on my Multi-Core Python Project.
On 7 September 2016 at 09:56, Eric Snow wrote: > I'm not anticipating much discussion on this, but wanted to present a > summary of my notes from the project I proposed last year and have > since tabled. > > http://ericsnowcurrently.blogspot.com/2016/09/solving-mutli-core-python.html Thanks for that update. For the PEP 432 start-up changes, the draft implementation reached a point earlier this year where it aligns with the current PEP draft and works as intended, except for the fact that most config settings aren't actually using the new structs yet: https://bitbucket.org/ncoghlan/cpython_sandbox/branch/pep432_modular_bootstrap However, there were other things that seemed higher priority to work on or help coordinate, so I deferred actually wrangling the process of proposing it for inclusion as a private API and then incrementally migrating settings over to it (particular as I think there's a high chance of that migration process stalling out if I can't be sure I'll have time to work on it myself). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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 525, fourth update
Thank you, Guido! I've updated the PEP to make shutdown_asyncgens a coroutine, as we discussed. Yury On 2016-09-06 7:10 PM, Guido van Rossum wrote: Thanks Yury! I am hereby accepting PEP 525 provisionally. The acceptance is so that you can go ahead and merge this into 3.6 before the feature freeze this weekend. The provisional status is because this is a big project and it's likely that we'll need to tweak some small aspect of the API once the code is in, even after 3.6.0 is out. (Similar to the way PEP 492, async/await, was accepted provisionally.) But I am cautiously optimistic and I am grateful to Yury for the care and effort he has put into it. --Guido On Tue, Sep 6, 2016 at 5:10 PM, Yury Selivanov wrote: Hi, I've updated PEP 525 with a new section about asyncio changes. Essentially, asyncio event loop will get a new "shutdown_asyncgens" method that allows to close the loop and all associated AGs with it reliably. Only the updated section is pasted below: asyncio --- The asyncio event loop will use ``sys.set_asyncgen_hooks()`` API to maintain a weak set of all scheduled asynchronous generators, and to schedule their ``aclose()`` coroutine methods when it is time for generators to be GCed. To make sure that asyncio programs can finalize all scheduled asynchronous generators reliably, we propose to add a new event loop method ``loop.shutdown_asyncgens(*, timeout=30)``. The method will schedule all currently open asynchronous generators to close with an ``aclose()`` call. After calling the ``loop.shutdown_asyncgens()`` method, the event loop will issue a warning whenever a new asynchronous generator is iterated for the first time. The idea is that after requesting all asynchronous generators to be shutdown, the program should not execute code that iterates over new asynchronous generators. An example of how ``shutdown_asyncgens`` should be used:: try: loop.run_forever() # or loop.run_until_complete(...) finally: loop.shutdown_asyncgens() loop.close() - 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/guido%40python.org ___ 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 525, fourth update
Thanks Yury! (Everyone else following along, the PEP is accepted provisionally, and we may make small tweaks from time to time during Python 3.6's lifetime.) ___ 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] Make "global after use" a SyntaxError
+1 On Wed, Sep 7, 2016 at 7:10 AM, Ivan Levkivskyi wrote: > Hi all, > > The documentation at https://docs.python.org/3/reference/simple_stmts.html > says that: > > "Names listed in a global statement must not be used in the same code block > textually preceding that global statement" > > But then later: > > "CPython implementation detail: The current implementation does not enforce > the two restrictions, > but programs should not abuse this freedom, as future implementations may > enforce them..." > > Code like this > > def f(): > x = 1 > global x > > gives SyntaxWarning for several releases, maybe it is time to make it a > SyntaxError? > > (I have opened an issue for this http://bugs.python.org/issue27999 I will > submit a patch soon). > > -- > Ivan > > ___ > 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/guido%40python.org > -- --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 529: Change Windows filesystem encoding to UTF-8
I'm hijacking this thread to provisionally accept PEP 529. (I'll also
do this for PEP 528, in its own thread.)
I've talked things over with Steve and Victor and we're going to do an
experiment (as now written up in the PEP:
https://www.python.org/dev/peps/pep-0529/#beta-experiment) to tease
out any issues with this change during the beta. If serious problems
crop up we may have to roll back the changes and reject the PEP -- we
won't get another chance at getting this right. (That would also mean
that using the binary filesystem APIs will remain deprecated and will
eventually be disallowed; as long as the PEP remains accepted they are
undeprecated.)
Congrats Steve! Thanks for the massive amount of work on the
implementation and the thinking that went into the design. Thanks
everyone else for their feedback.
--Guido
PS. I have one small inline response to Nick below.
On Sun, Sep 4, 2016 at 11:58 PM, Nick Coghlan wrote:
> On 5 September 2016 at 15:59, Steve Dower wrote:
>> +continue to default to ``locale.getpreferredencoding()`` (for text files) or
>> +plain bytes (for binary files). This only affects the encoding used when
>> users
>> +pass a bytes object to Python where it is then passed to the operating
>> system as
>> +a path name.
>
> For the three non-filesystem cases:
>
> I checked the situation for os.environb, and that's already
> unavailable on Windows (since os.supports_bytes_environ is False
> there), while sys.argv is apparently already handled correctly (i.e.
> always using the *W APIs).
>
> That means my only open question would be the handling of subprocess
> module calls (both with and without shell=True), since that currently
> works with binary arguments on *nix:
>
subprocess.call([b"python", b"-c", "print('ℙƴ☂ℌøἤ')".encode("utf-8")])
> ℙƴ☂ℌøἤ
> 0
subprocess.call(b"python -c '%s'" % 'print("ℙƴ☂ℌøἤ")'.encode("utf-8"),
shell=True)
> ℙƴ☂ℌøἤ
> 0
>
> While calling system native apps that way will still have many
> portability challenges, there are also plenty of cases where folks use
> sys.executable to launch new Python processes in a separate instance
> of the currently running interpreter, and it would be good if these
> changes brought cross-platform consistency to the handling of binary
> arguments here as well.
I checked with Steve and this is not supported anyway -- bytes
arguments (regardless of the value of shell) fail early with a
TypeError. That may be a bug but there's no backwards compatibility to
preserve here. (And apart from Python, few shell commands that work on
Unix make much sense on Windows, so Im also not particularly worried
about that particular example being non-portable -- it doesn't
represent a realistic concern.)
--
--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 528: Change Windows console encoding to UTF-8
Congrats Steve! I'm provisionally accepting PEP 528. You can mark it as provisionally accepted in the PEP, preferably with a link to the mail.python.org archival copy of this message. Good luck with the implementation. -- --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
[Python-Dev] (some) C99 added to PEP 7
To conclude our discussion about using C99 features, I've updated PEP 7 to allow the following features: - Standard integer types in and - ``static inline`` functions - designated initializers - intermingled declarations - booleans I've been adding examples of these to 3.6 over the last few days to make sure the buildbots will like it. https://github.com/python/peps/commit/b6efe6e06fa70e8933440da26474a804fb3edb6e Enjoy. ___ 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] (some) C99 added to PEP 7
2016-09-07 10:56 GMT-07:00 Benjamin Peterson : > To conclude our discussion about using C99 features, I've updated PEP 7 > to allow the following features: > - Standard integer types in and > - ``static inline`` functions > - designated initializers > - intermingled declarations > - booleans Welcome to the future! Victor ___ 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 529: Change Windows filesystem encoding to UTF-8
On 07Sep2016 1037, Guido van Rossum wrote: I'm hijacking this thread to provisionally accept PEP 529. (I'll also do this for PEP 528, in its own thread.) I've talked things over with Steve and Victor and we're going to do an experiment (as now written up in the PEP: https://www.python.org/dev/peps/pep-0529/#beta-experiment) to tease out any issues with this change during the beta. If serious problems crop up we may have to roll back the changes and reject the PEP -- we won't get another chance at getting this right. (That would also mean that using the binary filesystem APIs will remain deprecated and will eventually be disallowed; as long as the PEP remains accepted they are undeprecated.) Congrats Steve! Thanks for the massive amount of work on the implementation and the thinking that went into the design. Thanks everyone else for their feedback. --Guido Thanks! I've updated the status. Now the process of bartering for code reviews begins :) Patches are at: PEP 528: http://bugs.python.org/issue1602 PEP 529: http://bugs.python.org/issue27781 Cheers, Steve ___ 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] PEP 526 (variable annotations) accepted provisionally
I'm accepting PEP 526 provisionally. I am personally confident that this PEP is adding a useful new feature to the language: annotations that can be used by a wide variety of tools, whether off-line type checkers or frameworks that add runtime checking (e.g. traits or traitlets). The provisional status reflects the understanding that minor details of the proposed syntax and its runtime effects may still have to change based on experience during the 3.6 life cycle. (For example, maybe we end up not liking ClassVar, or maybe we'll decide we'll want to support `x, y, z: T` after all.) There's been some quite contentious discussion about the PEP, on and off python-dev, regarding how the mere presence of annotation syntax in the language will change the way people will see the language. My own experience using mypy and PyCharm has been quite different: annotations are a valuable addition for large code bases, and it's worth the effort to add them to large legacy code bases (think millions of lines of Python 2.7 code that needs to move to Python 3 by 2020). The effect of this has been that engineers using Python are happier and more confident that their code works than before, have an easier time spelunking code they don't know, and are less afraid of big refactorings (where conversion to Python 3 can be seen as the ultimate refactoring). I should blog about our experience at Dropbox; I hope the Zulip open source folks (not at Dropbox) will also blog about their experience. In the meantime you can read Daniel F. Moisset's three-part blog about adding annotations to pycodestyle (formerly pep8) here: http://www.machinalis.com/blog/a-day-with-mypy-part-1/ If you want to see a large open source code base that's annotated for mypy (with 97% coverage), I recommend looking at Zulip: https://github.com/zulip/zulip Finally, some of us are starting a new (informational) PEP to set expectations for how type checkers should make use of the annotation syntax standardized by PEP 484 and PEP 526. This is going to take more time, and new collaborators are welcome here: https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, I really hope you'll accept the invitation to participate. Your experience would be most welcome.) -- --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
[Python-Dev] Making PEP 3156 (asyncio) non-provisional
PEP 3156 and the asyncio module it defines have been provisional for the lifetime of Python 3.4 and 3.5. The module is now quite mature. I propose that we end the provisional period and make asyncio subject to the usual backwards compatibility rules: new features only appear in "minor" releases (e.g. 3.6, 3.7) and all changes must be backward compatible. There's some wiggle room though: in some cases we may decide that a given "feature" was really "undefined/undocumented behavior" and then we can treat it as a bug and fix it (== change the behavior) in a bugfix release (or during the 3.6 beta period). There are some worries that Twisted might request some incompatible changes in order to obtain better interoperability. I've sent an email to Amber Brown asking for a clarification. There's also the issue of starttls, a feature that we know we'd like to add but don't have ready for 3.6b1. I think the right approach there is to provide an add-on package on PyPI that implements a starttls-capable Transport class, and when that code is sufficiently battle-tested we can add it to the stdlib (hopefully by 3.7). Such a package might end up having to copy portions of the asyncio implementation and/or use internal/undocumented APIs; that's fine because it is only meant as a temporary measure, and we can make it clear that just because the starttls package uses a certain internal API that doesn't mean that API is now public. A big advantage of having the initial starttls implementation outside the stdlib is that its release schedule can be much more frequent than that of the stdlib (== every 6 months), and a security issue in the starttls package won't require all the heavy guns of doing a security release of all of CPython. -- --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] (some) C99 added to PEP 7
W00t! I will have to rewrite my brain. :-) On Wed, Sep 7, 2016 at 11:07 AM, Victor Stinner wrote: > 2016-09-07 10:56 GMT-07:00 Benjamin Peterson : >> To conclude our discussion about using C99 features, I've updated PEP 7 >> to allow the following features: >> - Standard integer types in and >> - ``static inline`` functions >> - designated initializers >> - intermingled declarations >> - booleans > > Welcome to the future! > > Victor > ___ > 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/guido%40python.org -- --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] (some) C99 added to PEP 7
On Wed, 7 Sep 2016 11:53:14 -0700 Guido van Rossum wrote: > W00t! I will have to rewrite my brain. :-) ... Is your brain coded in C89? > > On Wed, Sep 7, 2016 at 11:07 AM, Victor Stinner > wrote: > > 2016-09-07 10:56 GMT-07:00 Benjamin Peterson : > >> To conclude our discussion about using C99 features, I've updated PEP 7 > >> to allow the following features: > >> - Standard integer types in and > >> - ``static inline`` functions > >> - designated initializers > >> - intermingled declarations > >> - booleans > > > > Welcome to the future! > > > > Victor > > ___ > > 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/guido%40python.org > > > ___ 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] (some) C99 added to PEP 7
Wonder if it's ever segfaulted... ...hey, I just figured out why we got Python 3! ;) -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Sep 7, 2016 2:02 PM, "Antoine Pitrou" wrote: > On Wed, 7 Sep 2016 11:53:14 -0700 > Guido van Rossum wrote: > > W00t! I will have to rewrite my brain. :-) > > ... Is your brain coded in C89? > > > > > > On Wed, Sep 7, 2016 at 11:07 AM, Victor Stinner > > wrote: > > > 2016-09-07 10:56 GMT-07:00 Benjamin Peterson : > > >> To conclude our discussion about using C99 features, I've updated PEP > 7 > > >> to allow the following features: > > >> - Standard integer types in and > > >> - ``static inline`` functions > > >> - designated initializers > > >> - intermingled declarations > > >> - booleans > > > > > > Welcome to the future! > > > > > > Victor > > > ___ > > > 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/ > guido%40python.org > > > > > > > > > > ___ > 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/ > rymg19%40gmail.com > ___ 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] A Pseudo-Post-Mortem (not dead yet) on my Multi-Core Python Project.
Thanks for the post. :) There's some typo in the title and url. :/ :D On 07.09.2016 01:56, Eric Snow wrote: I'm not anticipating much discussion on this, but wanted to present a summary of my notes from the project I proposed last year and have since tabled. http://ericsnowcurrently.blogspot.com/2016/09/solving-mutli-core-python.html -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/srkunze%40mail.de ___ 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 526 (variable annotations) accepted provisionally
Thank you Guido! :-) -- Ivan On 7 September 2016 at 20:18, Guido van Rossum wrote: > I'm accepting PEP 526 provisionally. > > I am personally confident that this PEP is adding a useful new feature > to the language: annotations that can be used by a wide variety of > tools, whether off-line type checkers or frameworks that add runtime > checking (e.g. traits or traitlets). > > The provisional status reflects the understanding that minor details > of the proposed syntax and its runtime effects may still have to > change based on experience during the 3.6 life cycle. (For example, > maybe we end up not liking ClassVar, or maybe we'll decide we'll want > to support `x, y, z: T` after all.) > > There's been some quite contentious discussion about the PEP, on and > off python-dev, regarding how the mere presence of annotation syntax > in the language will change the way people will see the language. My > own experience using mypy and PyCharm has been quite different: > annotations are a valuable addition for large code bases, and it's > worth the effort to add them to large legacy code bases (think > millions of lines of Python 2.7 code that needs to move to Python 3 by > 2020). The effect of this has been that engineers using Python are > happier and more confident that their code works than before, have an > easier time spelunking code they don't know, and are less afraid of > big refactorings (where conversion to Python 3 can be seen as the > ultimate refactoring). > > I should blog about our experience at Dropbox; I hope the Zulip open > source folks (not at Dropbox) will also blog about their experience. > In the meantime you can read Daniel F. Moisset's three-part blog about > adding annotations to pycodestyle (formerly pep8) here: > > http://www.machinalis.com/blog/a-day-with-mypy-part-1/ > > If you want to see a large open source code base that's annotated for > mypy (with 97% coverage), I recommend looking at Zulip: > https://github.com/zulip/zulip > > Finally, some of us are starting a new (informational) PEP to set > expectations for how type checkers should make use of the annotation > syntax standardized by PEP 484 and PEP 526. This is going to take more > time, and new collaborators are welcome here: > https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, > I really hope you'll accept the invitation to participate. Your > experience would be most welcome.) > > -- > --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 526 (variable annotations) accepted provisionally
:D -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Sep 7, 2016 1:20 PM, "Guido van Rossum" wrote: > I'm accepting PEP 526 provisionally. > > I am personally confident that this PEP is adding a useful new feature > to the language: annotations that can be used by a wide variety of > tools, whether off-line type checkers or frameworks that add runtime > checking (e.g. traits or traitlets). > > The provisional status reflects the understanding that minor details > of the proposed syntax and its runtime effects may still have to > change based on experience during the 3.6 life cycle. (For example, > maybe we end up not liking ClassVar, or maybe we'll decide we'll want > to support `x, y, z: T` after all.) > > There's been some quite contentious discussion about the PEP, on and > off python-dev, regarding how the mere presence of annotation syntax > in the language will change the way people will see the language. My > own experience using mypy and PyCharm has been quite different: > annotations are a valuable addition for large code bases, and it's > worth the effort to add them to large legacy code bases (think > millions of lines of Python 2.7 code that needs to move to Python 3 by > 2020). The effect of this has been that engineers using Python are > happier and more confident that their code works than before, have an > easier time spelunking code they don't know, and are less afraid of > big refactorings (where conversion to Python 3 can be seen as the > ultimate refactoring). > > I should blog about our experience at Dropbox; I hope the Zulip open > source folks (not at Dropbox) will also blog about their experience. > In the meantime you can read Daniel F. Moisset's three-part blog about > adding annotations to pycodestyle (formerly pep8) here: > > http://www.machinalis.com/blog/a-day-with-mypy-part-1/ > > If you want to see a large open source code base that's annotated for > mypy (with 97% coverage), I recommend looking at Zulip: > https://github.com/zulip/zulip > > Finally, some of us are starting a new (informational) PEP to set > expectations for how type checkers should make use of the annotation > syntax standardized by PEP 484 and PEP 526. This is going to take more > time, and new collaborators are welcome here: > https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, > I really hope you'll accept the invitation to participate. Your > experience would be most welcome.) > > -- > --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/ > rymg19%40gmail.com > ___ 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] Commits to migrated repos no longer sent to Python-checkins
The repos which used to send to Python-checkins no longer do so since their respective migrations (devguide, peps). I don't know who's responsible for that, so I figured I'd post here. -Emanuel ___ 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] Commits to migrated repos no longer sent to Python-checkins
On Wed, 7 Sep 2016 at 14:24 Emanuel Barry wrote: > The repos which used to send to Python-checkins no longer do so since their > respective migrations (devguide, peps). I don't know who's responsible for > that, so I figured I'd post here. > If people want those back on then that could be arranged. I'm not sure, though, if it still makes sense having emails for every commit from three separate repositories going to the same mailing list. You can follow the commits through an atom feed, e.g https://github.com/python/peps/commits.atom. That means you could use something like IFTTT on your own to send you an email for each commit so you can track only the repositories you care about. That makes me think that it's worth even less for peps since those all have to be posted here anyway and the devguide doesn't affect people's future production deployments. ___ 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] Commits to migrated repos no longer sent to Python-checkins
Fair enough. I never really bothered to set up any complicated design to get commits, and my emails all get automatically sorted into folders so it doesn’t matter which list it goes to. Although now that you mention it, I could simply subscribe to the GitHub repos and get the notifications for free :) -Emanuel From: Brett Cannon [mailto:br...@python.org] Sent: Wednesday, September 07, 2016 5:40 PM To: Emanuel Barry; python-dev@python.org Subject: Re: [Python-Dev] Commits to migrated repos no longer sent to Python-checkins On Wed, 7 Sep 2016 at 14:24 Emanuel Barry mailto:vgr...@live.ca>> wrote: The repos which used to send to Python-checkins no longer do so since their respective migrations (devguide, peps). I don't know who's responsible for that, so I figured I'd post here. If people want those back on then that could be arranged. I'm not sure, though, if it still makes sense having emails for every commit from three separate repositories going to the same mailing list. You can follow the commits through an atom feed, e.g https://github.com/python/peps/commits.atom. That means you could use something like IFTTT on your own to send you an email for each commit so you can track only the repositories you care about. That makes me think that it's worth even less for peps since those all have to be posted here anyway and the devguide doesn't affect people's future production deployments. ___ 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] (some) C99 added to PEP 7
One more thing I forgot: C++-style line comments are kosher, too. On Wed, Sep 7, 2016, at 10:56, Benjamin Peterson wrote: > To conclude our discussion about using C99 features, I've updated PEP 7 > to allow the following features: > - Standard integer types in and > - ``static inline`` functions > - designated initializers > - intermingled declarations > - booleans > > I've been adding examples of these to 3.6 over the last few days to make > sure the buildbots will like it. > > https://github.com/python/peps/commit/b6efe6e06fa70e8933440da26474a804fb3edb6e > > Enjoy. ___ 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] Commits to migrated repos no longer sent to Python-checkins
On Wed, 7 Sep 2016 at 14:46 Emanuel Barry wrote: > Fair enough. I never really bothered to set up any complicated design to > get commits, and my emails all get automatically sorted into folders so it > doesn’t matter which list it goes to. Although now that you mention it, I > could simply subscribe to the GitHub repos and get the notifications for > free :) > Yep, you can always watch the projects as well. I just didn't suggest it as people have so far told me they viewed it as overkill when they just wanted commits. -Brett > > > -Emanuel > > > > *From:* Brett Cannon [mailto:br...@python.org] > *Sent:* Wednesday, September 07, 2016 5:40 PM > *To:* Emanuel Barry; python-dev@python.org > *Subject:* Re: [Python-Dev] Commits to migrated repos no longer sent to > Python-checkins > > > > > > On Wed, 7 Sep 2016 at 14:24 Emanuel Barry wrote: > > The repos which used to send to Python-checkins no longer do so since their > respective migrations (devguide, peps). I don't know who's responsible for > that, so I figured I'd post here. > > > > If people want those back on then that could be arranged. I'm not sure, > though, if it still makes sense having emails for every commit from three > separate repositories going to the same mailing list. > > > > You can follow the commits through an atom feed, e.g > https://github.com/python/peps/commits.atom. That means you could use > something like IFTTT on your own to send you an email for each commit so > you can track only the repositories you care about. That makes me think > that it's worth even less for peps since those all have to be posted here > anyway and the devguide doesn't affect people's future production > deployments. > ___ 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] (some) C99 added to PEP 7
Thank you very much Benjamin. On 7 September 2016 at 17:56, Benjamin Peterson wrote: > To conclude our discussion about using C99 features, I've updated PEP 7 > to allow the following features: > - Standard integer types in and Perhaps PEP 7 should clarify if the optional types like uint32_t are allowed, or only C99 mandatory types like uint_fast32_t etc. I think more people will be familiar with the fixed-width uint32_t etc. I know they are mandatory in Posix, and presumably also Windows, so they may be okay. > - ``static inline`` functions > - designated initializers > - intermingled declarations > - booleans > > I've been adding examples of these to 3.6 over the last few days to make > sure the buildbots will like it. > > https://github.com/python/peps/commit/b6efe6e06fa70e8933440da26474a804fb3edb6e > > Enjoy. ___ 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] (some) C99 added to PEP 7
On Wed, Sep 7, 2016, at 15:58, Martin Panter wrote: > Thank you very much Benjamin. > > On 7 September 2016 at 17:56, Benjamin Peterson > wrote: > > To conclude our discussion about using C99 features, I've updated PEP 7 > > to allow the following features: > > - Standard integer types in and > > Perhaps PEP 7 should clarify if the optional types like uint32_t are > allowed, or only C99 mandatory types like uint_fast32_t etc. I think > more people will be familiar with the fixed-width uint32_t etc. I know > they are mandatory in Posix, and presumably also Windows, so they may > be okay. Yes, I will clarify we require the fixed-width types. ___ 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] Commits to migrated repos no longer sent to Python-checkins
Let's see if watching the git repo (and filtering if necessary) covers this use case before we build more custom infrastructure. On Wed, Sep 7, 2016 at 2:46 PM, Emanuel Barry wrote: > Fair enough. I never really bothered to set up any complicated design to get > commits, and my emails all get automatically sorted into folders so it > doesn’t matter which list it goes to. Although now that you mention it, I > could simply subscribe to the GitHub repos and get the notifications for > free :) > > > > -Emanuel > > > > From: Brett Cannon [mailto:br...@python.org] > Sent: Wednesday, September 07, 2016 5:40 PM > To: Emanuel Barry; python-dev@python.org > Subject: Re: [Python-Dev] Commits to migrated repos no longer sent to > Python-checkins > > > > > > On Wed, 7 Sep 2016 at 14:24 Emanuel Barry wrote: > > The repos which used to send to Python-checkins no longer do so since their > respective migrations (devguide, peps). I don't know who's responsible for > that, so I figured I'd post here. > > > > If people want those back on then that could be arranged. I'm not sure, > though, if it still makes sense having emails for every commit from three > separate repositories going to the same mailing list. > > > > You can follow the commits through an atom feed, e.g > https://github.com/python/peps/commits.atom. That means you could use > something like IFTTT on your own to send you an email for each commit so you > can track only the repositories you care about. That makes me think that > it's worth even less for peps since those all have to be posted here anyway > and the devguide doesn't affect people's future production deployments. > > > ___ > 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/guido%40python.org > -- --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] RFC: PEP 509: Add a private version to dict
Folks, At the sprint both Victor and Yury have petitioned me to accept this PEP. I now agree. Let's do it! PEP 509 is hereby officially accepted. (Some implementation details have to be sorted out, but I need to unblock Victor before the sprint is over.) -- --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] Make "global after use" a SyntaxError
I don't know if feedback from a single, humble Python programmer is of any value, but: +1 I do sometimes have global statements at the start of the bit of code to which they apply (rather than having all global statements agglomerated at the start of the function they are in). This seems to me consistent with good practice, whether for clarity or to make code cut-and-pasting easier. I cannot imagine ever wanting a global statement to be AFTER the first reference to one of the global variables it mentions. Best wishes. Rob Cliffe On 07/09/2016 17:59, Guido van Rossum wrote: +1 On Wed, Sep 7, 2016 at 7:10 AM, Ivan Levkivskyi wrote: Hi all, The documentation at https://docs.python.org/3/reference/simple_stmts.html says that: "Names listed in a global statement must not be used in the same code block textually preceding that global statement" But then later: "CPython implementation detail: The current implementation does not enforce the two restrictions, but programs should not abuse this freedom, as future implementations may enforce them..." Code like this def f(): x = 1 global x gives SyntaxWarning for several releases, maybe it is time to make it a SyntaxError? (I have opened an issue for this http://bugs.python.org/issue27999 I will submit a patch soon). -- Ivan ___ 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/guido%40python.org ___ 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 526 (variable annotations) accepted provisionally
On 8 September 2016 at 04:18, Guido van Rossum wrote: > There's been some quite contentious discussion about the PEP, on and > off python-dev, regarding how the mere presence of annotation syntax > in the language will change the way people will see the language. My > own experience using mypy and PyCharm has been quite different: > annotations are a valuable addition for large code bases, and it's > worth the effort to add them to large legacy code bases (think > millions of lines of Python 2.7 code that needs to move to Python 3 by > 2020). The effect of this has been that engineers using Python are > happier and more confident that their code works than before, have an > easier time spelunking code they don't know, and are less afraid of > big refactorings (where conversion to Python 3 can be seen as the > ultimate refactoring). I also don't think it hurts to make the language migration easier for folks coming from a C/C++/C#/Java background, and even if they initially use explicit hints more heavily than they need to given the inferencing engines in typecheckers, those same hints have the potential to enable more automated refactorings that simplify their code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Making PEP 3156 (asyncio) non-provisional
On 8 September 2016 at 04:31, Guido van Rossum wrote: > There's also the issue of starttls, a feature that we know we'd like > to add but don't have ready for 3.6b1. I think the right approach > there is to provide an add-on package on PyPI that implements a > starttls-capable Transport class, and when that code is sufficiently > battle-tested we can add it to the stdlib (hopefully by 3.7). Such a > package might end up having to copy portions of the asyncio > implementation and/or use internal/undocumented APIs; that's fine > because it is only meant as a temporary measure, and we can make it > clear that just because the starttls package uses a certain internal > API that doesn't mean that API is now public. A big advantage of > having the initial starttls implementation outside the stdlib is that > its release schedule can be much more frequent than that of the stdlib > (== every 6 months), and a security issue in the starttls package > won't require all the heavy guns of doing a security release of all of > CPython. This could also be useful in general in terms of defining more clearly what kinds of access to asyncio internals are currently needed to implement 3rd party Transport classes, and perhaps lead to related future additions to the public API. Pending Amber's response, a definite thumbs up from me for removing the provisional caveat, and congratulations on a provisional experiment proving successful :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Making PEP 3156 (asyncio) non-provisional
On Wed, Sep 7, 2016 at 8:43 PM, Nick Coghlan wrote: > On 8 September 2016 at 04:31, Guido van Rossum wrote: >> There's also the issue of starttls, a feature that we know we'd like >> to add but don't have ready for 3.6b1. I think the right approach >> there is to provide an add-on package on PyPI that implements a >> starttls-capable Transport class, and when that code is sufficiently >> battle-tested we can add it to the stdlib (hopefully by 3.7). Such a >> package might end up having to copy portions of the asyncio >> implementation and/or use internal/undocumented APIs; that's fine >> because it is only meant as a temporary measure, and we can make it >> clear that just because the starttls package uses a certain internal >> API that doesn't mean that API is now public. A big advantage of >> having the initial starttls implementation outside the stdlib is that >> its release schedule can be much more frequent than that of the stdlib >> (== every 6 months), and a security issue in the starttls package >> won't require all the heavy guns of doing a security release of all of >> CPython. > > This could also be useful in general in terms of defining more clearly > what kinds of access to asyncio internals are currently needed to > implement 3rd party Transport classes, and perhaps lead to related > future additions to the public API. Well, the thing is, I don't ever want third party code to subclass any of the implementation classes in asyncio. Even with the best intentions, the implementation details just move around too much and having to worry about subclasses using a "protected" API would stifle improvements completely. A 3rd party Transport class will have to reimplement a bunch of Transport logic that already exists in the asyncio library, but with one exception (in _SelectorTransport.__repr__(), self._loop._selector is used to render the polling state) it doesn't use any internals from the event loop. I expect it would be a major design exercise to create a set of helper APIs or a standard base class that we feel comfortable with providing to transports; especially since creating a new transport often involves exploring new territory in some other domain as well (e.g. I remember that designing the subprocess transports was a complex task). For the add-on starttls package I propose to cheat, because it is on its way to become a stdlib API -- it just needs time to mature and I don't trust that the 3.6 beta period is enough for that. I want at least two independent developers (not Yury or myself) to build a protocol implementation based on the 3rd party starttls package before I'll feel comfortable that the API is right. For example -- do streams need starttls capability? It's somewhat scary because of the buffering, but maybe streams are the right abstraction for protocol implementations. Or maybe now. Nobody knows! > Pending Amber's response, a definite thumbs up from me for removing > the provisional caveat, and congratulations on a provisional > experiment proving successful :) Yup. And many new experiments are currently starting! -- --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 529: Change Windows filesystem encoding to UTF-8
On 8 September 2016 at 03:37, Guido van Rossum wrote: > On Sun, Sep 4, 2016 at 11:58 PM, Nick Coghlan wrote: >> While calling system native apps that way will still have many >> portability challenges, there are also plenty of cases where folks use >> sys.executable to launch new Python processes in a separate instance >> of the currently running interpreter, and it would be good if these >> changes brought cross-platform consistency to the handling of binary >> arguments here as well. > > I checked with Steve and this is not supported anyway -- bytes > arguments (regardless of the value of shell) fail early with a > TypeError. That may be a bug but there's no backwards compatibility to > preserve here. (And apart from Python, few shell commands that work on > Unix make much sense on Windows, so Im also not particularly worried > about that particular example being non-portable -- it doesn't > represent a realistic concern.) Cool, I suspected "That already doesn't work, so you just have to use strings for cross-platform compatibility in those cases" would be the answer, and I think that's a sensible way to go. Even on *nix passing bytes arguments to subprocess is unusual, since anyone with Python 2 based habits will omit the "b" prefix from literals, and anything coming from the command line, environment, or other user input is supplied as text by default. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
