[Python-Dev] PEP 616 "String methods to remove prefixes and suffixes" accepted

Hi, The Python Steering Council accepts the PEP 616 "String methods to remove prefixes and suffixes": https://www.python.org/dev/peps/pep-0616/ Congrats Dennis Sweeney! We just have one last request: we expect the documentation to explain well the difference between

[Python-Dev] PEP 554 comments

Hello, First, I would like to say that I have no fondamental problem with this PEP. While I agree with Nathaniel that the rationale given about the CSP concurrency model seems a bit weak, the author is obviously expressing his opinion there and I won't object to that. However, I think the PEP

[Python-Dev] PEP 554 for 3.9 or 3.10?

Hi all, It was nice to speak with many of you at the online language summit this week. It was the next best thing to seeing you all in person! :) With the 3.9 feature freeze coming up I'm considering options for PEP 554. I'm hopeful to have a pronouncement from Antoine in the near future. If

[Python-Dev] PEP: Modify the C API to hide implementation details

Hi, Here is a first draft a PEP which summarize the research work I'm doing on CPython C API since 2017 and the changes that me and others already made since Python 3.7 towards an "opaque" C API. The PEP is also a collaboration with developers of PyPy, HPy, Rust-CPython and many others! Thanks to

[Python-Dev] PEP 617: New PEG parser for CPython

Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros Nikolaou and myself have been working on a new parser for CPython. We are now far enough along that we present a PEP we've written: https://www.python.org/dev/peps/pep-0617/ Hopefully the PEP speaks for itself. We are

[Python-Dev] PEP 585 "Type Hinting Generics In Standard Collections" accepted

Hi, The Python Steering Council accepts PEP 585 "Type Hinting Generics In Standard Collections": https://www.python.org/dev/peps/pep-0585/ Congrats Łukasz Langa for your tenacity! (PEP written one year ago.) Thanks also to everyone who was involved in the discussion to help to get a better PEP

[Python-Dev] PEP 616 -- String methods to remove prefixes and suffixes

Browser Link: https://www.python.org/dev/peps/pep-0616/ PEP: 616 Title: String methods to remove prefixes and suffixes Author: Dennis Sweeney Sponsor: Eric V. Smith Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 19-Mar-2020 Python-Version: 3.9 Post-History: 30-Aug-2002

[Python-Dev] PEP 614 accepted

By unanimous consent, the Python Steering Council unanimously accepts PEP 614 — Relaxing Grammar Restrictions On Decorators. Congratulations to PEP author Brandt and PEP sponsor Guido, and thanks to everyone who’s worked on this PEP and its implementation. Cheers, -Barry signature.asc

[Python-Dev] PEP 615: Support for IANA Time Zones in the Standard Library

Greetings! Last year at the Language Summit, I proposed to add additional concrete time zones to the standard library . After much work and much more procrastination, I now have now put together my first proposal:

[Python-Dev] PEP 585: Type Hinting Generics In Standard Collections

Read in the browser: https://www.python.org/dev/peps/pep-0585/ Read the source: https://raw.githubusercontent.com/python/peps/master/pep-0585.rst The following PEP has been

[Python-Dev] PEP 614: Relaxing Grammar Restrictions On Decorators

PEP 614 has recently completed a round of review on Python-Ideas: https://www.python.org/dev/peps/pep-0614/ It proposes that the current decorator syntax restrictions be relaxed to allow any valid expression. Nobody has raised any objections, but I wanted to gather more feedback here prior to

[Python-Dev] PEP 584: Add Union Operators To dict

Steven D'Aprano and I have pushed a third draft of PEP 584: https://www.python.org/dev/peps/pep-0584/ The accompanying reference implementation is on GitHub: https://github.com/brandtbucher/cpython/tree/addiction For those who have been following the discussions over the past year on

[Python-Dev] PEP 613 Accepted

The Steering Council has considered Guido’s request for pronouncement on PEP 613 - Explicit Type Aliases, written by Shannon Zhu and sponsored by Guido van Rossum. The Council unanimously accepts PEP 613. Congratulations! We’ll leave it to the sponsor and author to update the PEP accordingly.

[Python-Dev] PEP 587

I am really confused on writing python and what app I need to write it in any tips or any ideas for apps?? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] PEP 458: Secure PyPI downloads with package signing

Hi! I'm forwarding this on behalf of Marina Moore https://github.com/mnm678 . - Sumana Harihareswara --- PEP 458 ( https://www.python.org/dev/peps/pep-0458/ ) proposes using The Update Framework (TUF) to allow users of PyPI to verify that the packages they install originate from PyPI.

[Python-Dev] PEP 558: Defined semantics for locals() (December 2019 edition)

Hi folks, I've finally updated PEP 558 and it's reference implementation based on Nathaniel's feedback back in May. The latest version of the PEP can now be found at https://www.python.org/dev/peps/pep-0558/, and I've created a discussion thread on Discourse:

[Python-Dev] PEP 611 - saturating reference counts

as an aside in the portion of PEP 611 proposing a limit to the number of classes, the proposal also mentioned reducing the size of the reference count field to achieve part of its object size savings. one of the mechanisms proposed was to implement a "saturating" reference count, though it

[Python-Dev] PEP 611 -- why limit coroutines and classes?

I want to question two specific limits. (a) Limiting the number of classes, in order to potentially save space in object headers, sounds like a big C API change, and I think it's better to lift this idea out of PEP 611 and debate the and cons separately. (b) Why limit coroutines? It's just

[Python-Dev] PEP 587

Hii.I want to download Python 3.8.0 at my mobile.Please help me to download. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/

[Python-Dev] PEP 611: The one million limit.

Hi Everyone, Thanks for all your feedback on my proposed PEP. I've editing the PEP in light of all your comments and it is now hopefully more precise and with better justification. https://github.com/python/peps/pull/1249 Cheers, Mark. ___

[Python-Dev] PEP 608 and backwards compatibility [was: Deprecating the "u" string literal prefix]

On 12/04/2019 04:21 AM, Victor Stinner wrote: IMHO we need a metric to measure the risk of an incompatible change: estimate the percentage of broken Python applications. For example, run the test suite of the PyPI top 100 projects with the incompatible change and see how many fails. That's the

[Python-Dev] PEP proposal to limit various aspects of a Python program to one million.

Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. Any thoughts or feedback? The PEP: https://github.com/markshannon/peps/blob/one-million/pep-100.rst Cheers, Mark.

[Python-Dev] PEP 607: Shared background for PEPs 602 and 605

Hi folks, Since we have two competing proposals for the Steering Council to consider when it comes to the target release date for Python 3.9.0, Steve, Łukasz and I put together a short-ish overview of the common set of problems that the two PEPs are both attempting to address, as well as the

[Python-Dev] PEP for libffi + _ctypes

I have been comiling Python 3.8 from source and have had a really difficult time with getting _ctypes to compile. I see that libffi is no longer distributed with the Python source code, in preference for what is on the system. I searched for a PEP that describes the rationale behind this, but

[Python-Dev] PEP 605: A rolling feature release stream for CPython

Hi folks, Steve Dower and I have put together a proposal to try to reduce feature delivery latency by changing our pre-release management process such that beta releases are considered production ready. The preferred discussion thread for that PEP is on Discourse here:

[Python-Dev] PEP 587 (Python Initialization Configuration) updated to be future proof again

Hi, I dislike having to do that, but I had to make a last minute change in my PEP 587 "Python Initialization Configuration" to allow to modify the structure in the future without breaking the backward compatibility. I added a "struct_size" field to PyPreConfig and PyConfig: *

[Python-Dev] PEP 601: discussion-to discuss.python.org

Please use https://discuss.python.org/t/pep-601-forbid-return-break-continue-breaking-out-of-finally/2239 for feedback and discussion. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] PEP 581/588 RFC: Collecting feedback about GitHub Issues

(cross posting to python-committers, python-dev, core-workflow) PEP 581: Using GitHub Issues has been accepted by the steering council, but PEP 588: GitHub Issues Migration plan is still in progress. I'd like to hear from core developers as well as heavy b.p.o users, the following: 1. what

[Python-Dev] PEP 572 TargetScopeError

bpo-37757: https://bugs.python.org/issue37757 This issue describes some corner cases in PEP 572 (assignment expressions) syntax that haven’t been implemented yet. The PEP currently says: "The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same

[Python-Dev] PEP 588 updates

I've updated the text of PEP 588 (https://www.python.org/dev/peps/pep-0588/) with several items under "Migration Plan" section: - Hire a professional project manager to help ensure the success of the project. - Create a playground issue tracker on GitHub to experiment and test the new workflow -

[Python-Dev] PEP 581 has been updated with "Downsides of GitHub" section

Hi, I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section. https://www.python.org/dev/peps/pep-0581/#downsides-of-github Other parts of the PEP has also been updated to reflect recent changes to roundup/bpo that happened after PEP 581's acceptance, for example: - ability to

[Python-Dev] PEP 596 proposes doubling the release cadence

PEP body and discussion link: https://discuss.python.org/t/pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828 - Ł signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To

Re: [Python-Dev] PEP 594: update 1

On 6/4/2019 8:21 PM, Victor Stinner wrote: So what is happening for this PEP since Python 3.8 beta1 has been released? Is it too late for Python 3.8 or not? The only action proposed for 3.8 was soft deprecation in the docs, which I presume can be done later in the beta process. It seems

Re: [Python-Dev] PEP 594: update 1

So what is happening for this PEP since Python 3.8 beta1 has been released? Is it too late for Python 3.8 or not? It seems like most people are confused by the intent of the PEP. IMHO it would be better to rewrite "Remove packages from the stdlib" as "Move some stdlib modules to PyPI". But that

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Wed, May 29, 2019, at 01:25, Nick Coghlan wrote: > Having a single locals() call de-optimize an entire function would be > far from ideal. What if there were a way to explicitly de-optimize a function, rather than guessing the user's intent based on looking for locals and exec calls (both of

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On 2019-06-02 13:51, Steven D'Aprano wrote: On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote: Armin Rigo wrote: >You have the occasional big function that benefits a lot from being >JIT-compiled but which contains ``.format(**locals())``. There should be a lot less need for that now

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote: > Armin Rigo wrote: > >You have the occasional big function that benefits a lot from being > >JIT-compiled but which contains ``.format(**locals())``. > > There should be a lot less need for that now that we have f-strings. I think

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Armin Rigo wrote: You have the occasional big function that benefits a lot from being JIT-compiled but which contains ``.format(**locals())``. There should be a lot less need for that now that we have f-strings. -- Greg ___ Python-Dev mailing list

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Hi, On Wed, 29 May 2019 at 08:07, Greg Ewing wrote: > Nick Coghlan wrote: > > Having a single locals() call de-optimize an entire function would be > > far from ideal. > > I don't see what would be so bad about that. The vast majority > of functions have no need for locals(). You have the

Re: [Python-Dev] PEP 595: Improving bugs.python.org

On Sat, Jun 1, 2019 at 11:50 AM Antoine Pitrou wrote: > > On Fri, 31 May 2019 11:58:22 -0700 > Nathaniel Smith wrote: > > On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > > > > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > > > > > I second this. > > > > > > > > There are

Re: [Python-Dev] PEP 595: Improving bugs.python.org

On Fri, 31 May 2019 11:58:22 -0700 Nathaniel Smith wrote: > On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > > > I second this. > > > > > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > > > makes a good

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 29May2019 1311, Petr Viktorin wrote: On 5/29/19 3:36 PM, Jeroen Demeyer wrote: On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall

Re: [Python-Dev] PEP 595: Improving bugs.python.org

Nathaniel Smith wrote: On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: On May 31, 2019, at 01:22, Antoine Pitrou wrote: I second this. There are currently ~7000 bugs open on bugs.python.org.  The Web UI makes a good job of actually being able to navigate through these bugs,

Re: [Python-Dev] PEP 595: Improving bugs.python.org

On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > I second this. > > > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > > makes a good job of actually being able to navigate through these bugs, > > search

Re: [Python-Dev] PEP 595: Improving bugs.python.org

On May 31, 2019, at 01:22, Antoine Pitrou wrote: > I second this. > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > makes a good job of actually being able to navigate through these bugs, > search through them, etc. > > Did the Steering Council conduct a usability study

Re: [Python-Dev] PEP 595: Improving bugs.python.org

or a tool to generate the > > links and updating them will need to be written. > > > > * GitHub doesn't provide a way to set and preserve issue IDs > > if they are migrated automatically with the use of a button. > > (Some projects managed to preserve the IDs by con

Re: [Python-Dev] PEP 595: Improving bugs.python.org

s issues will need to be addressed: > > * GitHub is properietary and there is risk of vendor lock-in. > Their business model might change and they could shut down > altogether. > > * Switching to GitHub Issues will likely increase the number of > invalid reports and increase the

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Thu, May 30, 2019 at 4:28 PM Greg Ewing wrote: > Nick Coghlan wrote: > > So for me, getting rid of write backs via exec and "import *" was a > > matter of "Yay, we finally closed those unfortunate loopholes" rather > > than being any kind of regrettable necessity. > > If that were the

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: So for me, getting rid of write backs via exec and "import *" was a matter of "Yay, we finally closed those unfortunate loopholes" rather than being any kind of regrettable necessity. If that were the reasoning, the principled thing to do would be to raise an exception if

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Fri., 31 May 2019, 5:20 am Xavier de Gaye, wrote: > Currently f_locals is documented as readonly [1]. > Read-only in the sense that you can't rebind it to point to a different object - the dict it points to is mutable. > The PEP says: > > * "Don't change what isn't broken": the current

Re: [Python-Dev] PEP 558: Defined semantics for locals()

Currently f_locals is documented as readonly [1]. The PEP says: * "Don't change what isn't broken": the current tracing mode problems are caused by a requirement that's specific to tracing mode (support for external rebinding of function local variable references), so it made sense to also

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Thu, 30 May 2019 at 09:12, Greg Ewing wrote: > > Nick Coghlan wrote: > > If there was a compelling use case for letting "a = 1; exec(src); > > print(a)" print something other than "1" at function scope, then I'd > > be more amenable to the idea of the associated compatibility break and > >

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: If there was a compelling use case for letting "a = 1; exec(src); print(a)" print something other than "1" at function scope, then I'd be more amenable to the idea of the associated compatibility break and potential performance regression in other implementations. However,

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 3:36 PM, Jeroen Demeyer wrote: On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall is no longer provisional. For static

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On Wed, May 29, 2019 at 7:55 AM Jeroen Demeyer wrote: > On 2019-05-29 16:00, Christian Heimes wrote: > > You could add a check to PyType_Ready() and have it either return an > > error or fix tp_call. > > Yes, but the question is: which of these two alternatives? I would vote > for fixing tp_call

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Wed, 29 May 2019 at 16:08, Greg Ewing wrote: > > Nick Coghlan wrote: > > Having a single locals() call de-optimize an entire function would be > > far from ideal. > > I don't see what would be so bad about that. The vast majority > of functions have no need for locals(). If there was a

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 2019-05-29 16:00, Christian Heimes wrote: You could add a check to PyType_Ready() and have it either return an error or fix tp_call. Yes, but the question is: which of these two alternatives? I would vote for fixing tp_call but Petr voted for an error.

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 29/05/2019 15.29, Petr Viktorin wrote: > On 5/29/19 2:25 PM, Jeroen Demeyer wrote: >> Hello, >> >> I have one implementation question about vectorcall which is not >> specified in PEP 590: what should happen if a type implements >> vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall is no longer provisional. For static types I either wouldn't bother at all, or

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 2:25 PM, Jeroen Demeyer wrote: Hello, I have one implementation question about vectorcall which is not specified in PEP 590: what should happen if a type implements vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e. tp_call == NULL)? I see the

[Python-Dev] PEP 590: vectorcall without tp_call

Hello, I have one implementation question about vectorcall which is not specified in PEP 590: what should happen if a type implements vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e. tp_call == NULL)? I see the following possibilities: 1. Ignore this

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Indeed. On Tue, May 28, 2019 at 11:07 PM Greg Ewing wrote: > Nick Coghlan wrote: > > Having a single locals() call de-optimize an entire function would be > > far from ideal. > > I don't see what would be so bad about that. The vast majority > of functions have no need for locals(). > > -- >

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: Having a single locals() call de-optimize an entire function would be far from ideal. I don't see what would be so bad about that. The vast majority of functions have no need for locals(). -- Greg ___ Python-Dev mailing list

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Wed., 29 May 2019, 2:29 pm Guido van Rossum, wrote: > So why is it “hellish” for JITs if locals() returns a proxy, while > frame.f_locals being a proxy is okay? > As I understand it, they already drop out of compiled mode if they detect that the code is tinkering with frame objects. Having

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

So why is it “hellish” for JITs if locals() returns a proxy, while frame.f_locals being a proxy is okay? On Tue, May 28, 2019 at 9:12 PM Nick Coghlan wrote: > (I'll likely write a more detailed reply once I'm back on an actual > computer, but wanted to send an initial response while folks in

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

(I'll likely write a more detailed reply once I'm back on an actual computer, but wanted to send an initial response while folks in the US are still awake, as the detailed reply may not be needed) Thanks for this write-up Nathaniel - I think you've done a good job of capturing the available

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Tue, May 28, 2019 at 6:48 PM Greg Ewing wrote: > > Nathaniel Smith wrote: > > - [proxy]: Simply return the .f_locals object, so in all contexts > > locals() returns a live mutable view of the actual environment: > > > > def locals(): > > return get_caller_frame().f_locals > > Not sure

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nathaniel Smith wrote: - [proxy]: Simply return the .f_locals object, so in all contexts locals() returns a live mutable view of the actual environment: def locals(): return get_caller_frame().f_locals Not sure I quite follow this -- as far as I can see, f_locals currently has the

Re: [Python-Dev] PEP 595: Improving bugs.python.org

y report is also use to generate statistics and graphs that can be used to gain new insights [#]_. * **bpo-related MLs.** There are currently two mailing lists where bpo posts new tracker issues and all messages respectively: `new-bugs-announce` [#]_ and `python-bugs-list` [#]_. A

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, 26 May 2019 at 00:37, Guido van Rossum wrote: > > This looks great. > > I only have two nits with the text. > > First, why is the snapshot called a "dynamic snapshot"? What exactly is > dynamic about it? The dynamic part comes in if you call locals() twice: because it returns the same

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Tue, May 28, 2019 at 08:37:17AM +0100, Paul Moore wrote: > Of course, all of this is only if we have decided to formalise the > semantics and change CPython to conform. I've never personally been > affected by any of the edge cases with locals(), so on a purely > personal basis, I'm equally

Re: [Python-Dev] PEP 558: Defined semantics for locals()

I'm guessing the reason is to remove the overhead of keeping the dictionary up to date during function execution when no Python code needs access to it. On Mon, May 27, 2019 at 8:10 PM Richard Damon wrote: > On 5/27/19 2:05 PM, Terry Reedy wrote: > > On 5/27/2019 9:52 AM, Richard Damon wrote:

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Tue, 28 May 2019 at 06:00, Nathaniel Smith wrote: > - There's the "justified" action-at-a-distance that currently happens > at module scope, where locals().__setitem__ affects variable lookup, > and variable mutation affects locals().__getitem__. This can produce > surprising results if you

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Mon, May 27, 2019 at 9:18 PM Guido van Rossum wrote: > > Note that the weird, Action At A Distance behavior is also visible for > locals() called at module scope (since there, locals() is globals(), which > returns the actual dict that's the module's __dict__, i.e. the Source Of > Truth. So

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Note that the weird, Action At A Distance behavior is also visible for locals() called at module scope (since there, locals() is globals(), which returns the actual dict that's the module's __dict__, i.e. the Source Of Truth. So I think it's unavoidable in general, and we would do wise not to try

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On 5/27/2019 7:28 PM, Steven D'Aprano wrote: On the other hand, locals() currently returns a dict everywhere. It might be surprising for it to start returning a proxy object inside functions instead of a dict. I thought the proxy object sounded more useful... how different is it in use from a

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Mon, May 27, 2019 at 08:15:01AM -0700, Nathaniel Smith wrote: [...] > I'm not as sure about the locals() parts of the proposal. It might be > fine, but there are some complex trade-offs here that I'm still trying > to wrap my head around. The rest of this document is me thinking out > loud to

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

OK, I apologize for not catching on to the changed semantics of f_locals (which in the proposal is always a proxy for the fast locals and the cells). I don't know if I just skimmed that part of the PEP or that it needs calling out more. I'm assuming that there are backwards compatibility

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 5/27/19 2:05 PM, Terry Reedy wrote: > On 5/27/2019 9:52 AM, Richard Damon wrote: >> On 5/27/19 9:12 AM, Terry Reedy wrote: > >>> I believe that the situation is or can be thought of as this: there is >>> exactly 1 function locals dict. > > per function invocation, or more generally, as Guido

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 5/27/2019 9:52 AM, Richard Damon wrote: On 5/27/19 9:12 AM, Terry Reedy wrote: I believe that the situation is or can be thought of as this: there is exactly 1 function locals dict. per function invocation, or more generally, as Guido said, per stack frame. This part is obvious to me,

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Mon, May 27, 2019 at 9:16 AM Guido van Rossum wrote: > > I re-ran your examples and found that some of them fail. > > On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote: [...] >> The interaction between f_locals and and locals() is also subtle: >> >> def f(): >> a = 1 >> loc

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

I re-ran your examples and found that some of them fail. On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote: > First, I want to say: I'm very happy with PEP 558's changes to > f_locals. It solves the weird threading bugs, and exposes the > fundamental operations you need for debugging in a

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Mon, 27 May 2019 at 16:11, Guido van Rossum wrote: > > No, there's only one locals() dict *per stack frame*. So no worries about > concurrency. Again, if the PEP is about formalising the behaviour as language mandated, this is worth documenting explicitly. Paul

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

This whole vexing issue isn't going to be solved with any simple fix. A tool that could identify upcoming trouble spots might or might not be helpful. Or perhaps it could be implemented as a __future__ feature, so that those who choose not to use it during development see no change. The primary

[Python-Dev] [PEP 558] thinking through locals() semantics

First, I want to say: I'm very happy with PEP 558's changes to f_locals. It solves the weird threading bugs, and exposes the fundamental operations you need for debugging in a simple and clean way, while leaving a lot of implementation flexibility for future Python VMs. It's a huge improvement

Re: [Python-Dev] PEP 558: Defined semantics for locals()

No, there's only one locals() dict *per stack frame*. So no worries about concurrency. On Mon, May 27, 2019 at 6:54 AM Richard Damon wrote: > On 5/27/19 9:12 AM, Terry Reedy wrote: > > On 5/27/2019 3:18 AM, Greg Ewing wrote: > >> Chris Angelico wrote: > >>> Except that it does. After calling

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On Mon, 27 May 2019 09:27:33 -0400 David Mertz wrote: > On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano > wrote: > > > > Nobody reads warnings. > > > > If nobody reads warnings, we should just remove the warnings module and > > be done with it. That should probably be a PEP. > > > > We'll

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On 27.05.2019 4:55, Steven D'Aprano wrote: On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote: On 24.05.2019 9:55, Steven D'Aprano wrote: I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it.

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 5/27/19 9:12 AM, Terry Reedy wrote: > On 5/27/2019 3:18 AM, Greg Ewing wrote: >> Chris Angelico wrote: >>> Except that it does. After calling locals() a second time, the result >>> of the *first* call will be updated to reflect changes. >> >> Yeow. That's *really* unintuitive. There had better

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano wrote: > > Nobody reads warnings. > > If nobody reads warnings, we should just remove the warnings module and > be done with it. That should probably be a PEP. > We'll have to start issuing a PendingDeprecationWarning when folk import the

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

Thanks Steve for your comments, I appreciate them. As I said I don't know if this is a good idea or not so please read my responses below as part of a friendly debate aimed at reaching consensus, not an argument. (The argument is in Room 12 with Mr. Barnard.) On Fri, May 24, 2019 at

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote: > On 24.05.2019 9:55, Steven D'Aprano wrote: > >I don't know if this is a good idea or a terrible idea or somewhere in > >between, so I'm throwing it out to see if anyone likes it. [...] > This would greately damage

Re: [Python-Dev] PEP 594: update 1

On Sat, May 25, 2019 at 8:00 PM Daniel Moisset wrote: > Hi, thanks for the work on this proposal, I think this is at least a tip > of the iceberg and a good start for the bigger question of how the stdlib > should evolve.. > > I think that the PEP should include an idea of what should happen if

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On 24.05.2019 9:55, Steven D'Aprano wrote: I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained.

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 09:20:53PM +1000, Chris Angelico wrote: > Sure, but this PEP is all about defining things that weren't > previously defined, so I wanted to clarify intent rather than current > behaviour. As I understand it, the intent is to: - fix some annoyances/bugs involved when you

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, 26 May 2019 at 12:23, Chris Angelico wrote: > > On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote: > > On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote: > > > > > From my reading of the description, you could also "assert a is b" - > > > is that correct? > > > > Yes,

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote: > On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote: > > > From my reading of the description, you could also "assert a is b" - > > is that correct? > > Yes, that's already the behaviour. > > py> def demo(): > ... a =

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 08:04:11PM +1000, Steven D'Aprano wrote: > Richard, your email seems to have introduced a spurious "SPAM" label [...] > edit the subject line to remove the > label? Thanks. I've done so for this response Oops. Done now. -- Steven

Re: [Python-Dev] PEP 558: Defined semantics for locals()

(And this time I will remember to remove the SPAM label...) On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote: > From my reading of the description, you could also "assert a is b" - > is that correct? Yes, that's already the behaviour. py> def demo(): ... a = locals() ...

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On Fri, 24 May 2019 09:54:05 -0700 Steve Dower wrote: > > All in all, this is basically where we are today, with the exception > that we haven't officially said that we no longer support these modules. > PEP 594 is this official statement, and our usual process for things we > don't support

<    1   2   3   4   5   6   7   8   9   10   >