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

[Daniel Moisset]

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
existing stdlib pieces depend on this deprecated modules. For example,
email.mime.audio is part of a non-deprecated module but it depends on
sndhdr which is being planned for deprecation. Should that part of the
functionality be deprecated too? rewritten to not depend on the deprecated
module (but keep the pieces of relevant code? depend on optional 3rd party
modules and degrade if those are not available?

The sndhdr case is just an example but I can imagine there are others
(optparse is no longer schedule for removal in your PEP, but would have
been another case, being used by the profile module).

Best,
Daniel

On Tue, 21 May 2019 at 15:15, Christian Heimes  wrote:

> Hi,
>
> I have updated the PEP with feedback from discussions. The highlights are:
>
> * Deprecate parser module
> * Keep fileinput module
> * Elaborate why crypt and spwd are dangerous and bad
> * Improve sections for cgitb, colorsys, nntplib, and smtpd modules
> * The colorsys, crypt, imghdr, sndhdr, and spwd sections now list suitable
> substitutions.
> * Mention that socketserver is going to stay for http.server and
> xmlrpc.server
> * The future maintenance section now states that the deprecated modules
> may be adopted by Python community members.
>
> https://github.com/python/peps/compare/7799178a...2d536899?diff=unified#diff-ae358c21fa7968ee3b6c64479e051574
>
>
> I'll be traveling the next couple of days and will only have limited
> opportunities to respond on feedback.
>
> Christian
>
> ---
> PEP: 594
> Title: Removing dead batteries from the standard library
> Author: Christian Heimes 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 20-May-2019
> Post-History: 21-May-2019
>
>
> Abstract
> 
>
> This PEP proposed a list of standard library modules to be removed from the
> standard library. The modules are mostly historic data formats and APIs
> that
> have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
>
>
> Rationale
> =
>
> Back in the early days of Python, the interpreter came with a large set of
> useful modules. This was often refrained to as "batteries included"
> philosophy and was one of the corner stones to Python's success story.
> Users didn't have to figure out how to download and install separate
> packages in order to write a simple web server or parse email.
>
> Times have changed. The introduction of the cheese shop (PyPI), setuptools,
> and later pip, it became simple and straight forward to download and
> install
> packages. Nowadays Python has a rich and vibrant ecosystem of third party
> packages. It's pretty much standard to either install packages from PyPI or
> use one of the many Python or Linux distributions.
>
> On the other hand, Python's standard library is piling up cruft,
> unnecessary
> duplication of functionality, and dispensable features. This is undesirable
> for several reasons.
>
> * Any additional module increases the maintenance cost for the Python core
>   development team. The team has limited resources, reduced maintenance
> cost
>   frees development time for other improvements.
> * Modules in the standard library are generally favored and seen as the
>   de-facto solution for a problem. A majority of users only pick 3rd party
>   modules to replace a stdlib module, when they have a compelling reason,
> e.g.
>   lxml instead of `xml`. The removal of an unmaintained stdlib module
>   increases the chances of a community contributed module to become widely
>   used.
> * A lean and mean standard library benefits platforms with limited
> resources
>   like devices with just a few hundred kilobyte of storage (e.g. BBC
>   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
>   (e.g. pyodide) also benefit from reduced download size.
>
> The modules in the PEP have been selected for deprecation because their
> removal is either least controversial or most beneficial. For example
> least controversial are 30 years old multimedia formats like ``sunau``
> audio format, which was used on SPARC and NeXT workstations in the late
> 1980ties. The ``crypt`` module has fundamental flaws that are better solved
> outside the standard library.
>
> This PEP also designates some modules as not scheduled for removal. Some
> modules have been deprecated for several releases or seem unnecessary at
> first glance. However it is beneficial to keep the modules in the standard
> library, mostly for environments where installing a package from PyPI is
> not
> an option. This can be cooperate environments or class rooms where external
> code is not permitted without legal approval.
>
> * The usage of FTP is declining, but some files are still provide

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

[Chris Angelico]

On Sun, May 26, 2019 at 8:38 AM Richard Damon  wrote:
>
> On 5/25/19 5:09 PM, Nathaniel Smith wrote:
> > a = locals()
> > b = locals()
> > # now our first "snapshot" has changed
> > assert "a" in a
> >
> To me that is a static snapshot of a dynamic environment, not a dynamic
> snapshot. The snapshot you get at THAT moment in time won't change, as
> time progresses, so that snapshot itself isn't dynamic.

Except that it does. After calling locals() a second time, the result
of the *first* call will be updated to reflect changes. It's not a
frozen snapshot; you can't diff the two dictionaries to see what's
changed (unless you use "a = dict(locals())" or something, which IS a
snapshot).

>From my reading of the description, you could also "assert a is b" -
is that correct?

ChrisA
___
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] [SPAM?] Re: PEP 558: Defined semantics for locals()

[Richard Damon]

On 5/25/19 5:09 PM, Nathaniel Smith wrote:
> On Sat, May 25, 2019, 07:38 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?
>
>
> It's dynamic in that it can spontaneously change when certain other
> events happen. For example, imagine this code runs at function scope:
>
> # take a snapshot
> a = locals()
>
> # it's a snapshot, so it doesn't include the new variable
> assert "a" not in a
>
> # take another snapshot
> b = locals()
>
> # now our first "snapshot" has changed
> assert "a" in a
>
> Overall I'm happy with the PEP, but I'm still a bit uneasy about
> whether we've gotten the details of this "dynamicity" exactly right,
> esp. since the PEP promotes them from implementation detail to
> language features. There are a lot of complicated tradeoffs so I'm
> working on a longer response that tries to lay out all the options and
> hopefully convince myself (and everyone else).
>
> -n
To me that is a static snapshot of a dynamic environment, not a dynamic
snapshot. The snapshot you get at THAT moment in time won't change, as
time progresses, so that snapshot itself isn't dynamic. Calling
something a 'dynamic snapshot' could be take to imply that the snapshot
itself is dynamic, and thus changes at that environment changes (and you
could pass that snapshot to some other place, and they could get a view
of things just like you would see it there,

-- 
Richard Damon

___
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 558: Defined semantics for locals()

[Guido van Rossum]

That's a good fine point that the PEP could call out, but just adding
"dynamic" in front of "snapshot" everywhere doesn't tell me any of that.

Given that the code calling locals() must of necessity live in the same
function body (except for the special case of trace functions), I don't
think that what you describe here is too worrisome a scenario.

On Sat, May 25, 2019 at 2:09 PM Nathaniel Smith  wrote:

> On Sat, May 25, 2019, 07:38 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?
>>
>
> It's dynamic in that it can spontaneously change when certain other events
> happen. For example, imagine this code runs at function scope:
>
> # take a snapshot
> a = locals()
>
> # it's a snapshot, so it doesn't include the new variable
> assert "a" not in a
>
> # take another snapshot
> b = locals()
>
> # now our first "snapshot" has changed
> assert "a" in a
>
> Overall I'm happy with the PEP, but I'm still a bit uneasy about whether
> we've gotten the details of this "dynamicity" exactly right, esp. since the
> PEP promotes them from implementation detail to language features. There
> are a lot of complicated tradeoffs so I'm working on a longer response that
> tries to lay out all the options and hopefully convince myself (and
> everyone else).
>
> -n
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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 558: Defined semantics for locals()

[Nathaniel Smith]

On Sat, May 25, 2019, 07:38 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?
>

It's dynamic in that it can spontaneously change when certain other events
happen. For example, imagine this code runs at function scope:

# take a snapshot
a = locals()

# it's a snapshot, so it doesn't include the new variable
assert "a" not in a

# take another snapshot
b = locals()

# now our first "snapshot" has changed
assert "a" in a

Overall I'm happy with the PEP, but I'm still a bit uneasy about whether
we've gotten the details of this "dynamicity" exactly right, esp. since the
PEP promotes them from implementation detail to language features. There
are a lot of complicated tradeoffs so I'm working on a longer response that
tries to lay out all the options and hopefully convince myself (and
everyone else).

-n
___
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 594: update 1

[Brett Cannon]

Please start a new thread if you want to continue discussing what will come
after Python 3.9.

On Fri., May 24, 2019, 22:45 Glenn Linderman,  wrote:

> On 5/24/2019 9:09 PM, Random832 wrote:
>
> On Thu, May 23, 2019, at 15:27, Steve Holden wrote:
>
> Besides which, it would be lovely to have a major release that didn't
> involve any pain at all for the majority of users!
>
> Our erstwhile BDFL always eschewed two-digit version identifiers- due
> to the possibility for confusion about collating sequence, I beleive..
> We should honour his preferences by going from 3.9 to 4.0.
>
>
> Is 4.0 still gonna install as "python3", pip3, etc, executable as "py -3" on 
> windows? I can see that being a pain point even if nothing else is.
>
>
> Maybe by then it can go back to just being python, as 2.x will be past
> end-of-life.
> ___
> 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/brett%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 558: Defined semantics for locals()

[Terry Reedy]

On 5/25/2019 10:36 AM, Guido van Rossum wrote:

This looks great.


I agree.  I understand and have tried to explain normal operation 
multiple times.  The proposed new doc looks better than anything I ever 
wrote.  (I never even thought about locals() with tracing on.)  The 
improved clarity well justifies the increased space.



I only have two nits with the text.

First, why is the snapshot called a "dynamic snapshot"? What exactly is 
dynamic about it?


Good catch.  'snapshot' is from "At function scope (including for 
generators and coroutines), [locals()] returns a dynamic snapshot of the 
function's local variables and any nonlocal cell references."
'Dynamic' could be misunderstood to mean the function locals() snapshot 
always tracks the underlying function namespace.  The point of using the 
'snapshot' metaphor is that it does not.


The snapshot is 'dynamic' in that it can be changed, but the same is 
true of real photos.  But just as with real photos, changing the 
snapshot does not change the reality it represents (as explained in the 
next proposed sentence).  The 'snapshot' metaphor does not need 
'dynamic' and I think it works better without it.


Second, you use the word "mapping" a lot. Would you mind changing that 
to "mapping object" in most places? Especially in the phrase "each call 
to ``locals()`` returns the *same* mapping". To me, without the word 
"object" added, this *could* be interpreted as "a dict with the same 
key/value pairs" (since "mapping" is also an abstract mathematical 
concept describing anything that maps keys to values).


Agreed also.


--
Terry Jan Reedy

___
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 558: Defined semantics for locals()

[Guido van Rossum]

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?

Second, you use the word "mapping" a lot. Would you mind changing that to
"mapping object" in most places? Especially in the phrase "each call to
``locals()`` returns the *same* mapping". To me, without the word "object"
added, this *could* be interpreted as "a dict with the same key/value
pairs" (since "mapping" is also an abstract mathematical concept describing
anything that maps keys to values).

Other than that, go for it! (Assuming Nathaniel agrees, of course.)

--Guido

On Tue, May 21, 2019 at 7:54 AM Nick Coghlan  wrote:

> Hi folks,
>
> After a couple of years hiatus, I finally got back to working on the
> reference implementation for PEP 558, my proposal to resolve some
> weird interactions between closures and trace functions in CPython by
> formally defining the expected semantics of the locals() builtin at
> function scope, and then ensuring that CPython adheres to those
> clarified semantics.
>
> The full text of the PEP is included below, and the rendered version
> is available at https://www.python.org/dev/peps/pep-0558/
>
> The gist of the PEP is that:
>
> 1. The behaviour when no trace functions are installed and no frame
> introspection APIs are invoked is fine, so nothing should change in
> that regard (except that we elevate that behaviour from "the way
> CPython happens to work" to "the way the language and library
> reference says that Python implementations are supposed to work", and
> make sure CPython continues to behave that way even when a trace hook
> *is* installed)
> 2. If you get hold of a frame object in CPython (or another
> implementation that emulates the CPython frame API), whether via a
> trace hook or via a frame introspection API, then writing to the
> returned mapping will update the actual function locals and/or closure
> reference immediately, rather than relying on the
> FastToLocals/LocalsToFast APIs
> 3. The LocalsToFast C API changes to always produce RuntimeError
> (since there's no way for us to make it actually work correctly and
> consistently in the presence of closures, and the trace hook
> implementation won't need it any more given the write-through proxy
> behaviour on frame objects' "f_locals" attribute)
>
> The reference implementation still isn't quite done yet, but it's far
> enough along that I'm happy with the semantics and C API updates
> proposed in the current version of the PEP.
>
> Cheers,
> Nick.
>
> P.S. I'm away this weekend, so I expect the reference implementation
> to be done late next week, and I'd be submitting the PEP to Nathaniel
> for formal pronouncement at that point. However, I'm posting this
> thread now so that there's more time for discussion prior to the 3.8b1
> deadline.
>
> ==
> PEP: 558
> Title: Defined semantics for locals()
> Author: Nick Coghlan 
> BDFL-Delegate: Nathaniel J. Smith
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2017-09-08
> Python-Version: 3.8
> Post-History: 2017-09-08, 2019-05-22
>
>
> Abstract
> 
>
> The semantics of the ``locals()`` builtin have historically been
> underspecified
> and hence implementation dependent.
>
> This PEP proposes formally standardising on the behaviour of the CPython
> 3.6
> reference implementation for most execution scopes, with some adjustments
> to the
> behaviour at function scope to make it more predictable and independent of
> the
> presence or absence of tracing functions.
>
>
> Rationale
> =
>
> While the precise semantics of the ``locals()`` builtin are nominally
> undefined,
> in practice, many Python programs depend on it behaving exactly as it
> behaves in
> CPython (at least when no tracing functions are installed).
>
> Other implementations such as PyPy are currently replicating that
> behaviour,
> up to and including replication of local variable mutation bugs that
> can arise when a trace hook is installed [1]_.
>
> While this PEP considers CPython's current behaviour when no trace hooks
> are
> installed to be acceptable (and largely desirable), it considers the
> current
> behaviour when trace hooks are installed to be problematic, as it causes
> bugs
> like [1]_ *without* even reliably enabling the desired functionality of
> allowing
> debuggers like ``pdb`` to mutate local variables [3]_.
>
>
> Proposal
> 
>
> The expected semantics of the ``locals()`` builtin change based on the
> current
> execution scope. For this purpose, the defined scopes of execution are:
>
> * module scope: top-level module code, as well as any other code executed
> using
>   ``exec()`` or ``eval()`` with a single namespace
> * class scope: code in the body of a ``class`` statement, as well as any
> other
>   code executed using ``exec()`` or ``eval()`` with separate local and
> global
>   namespaces
> * function scope: code in the body of a ``def`` or ``async def``

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

[Armin Rigo]

Hi,

On Thu, 23 May 2019 at 17:28, Steve Dower  wrote:
> On 23May2019 0636, Nick Coghlan wrote:
> > However, I think the PR does show that the proposed technique can be
> > implemented without too much additional code complexity, and will
> > hopefully be adaptable for all implementations that emulate the frame
> > API at all.
>
> Much excitement!
>
> One of the things I like best about this change is that it actually
> makes it *easier* for alternative implementations to use a simpler frame
> object without having to emulate CPython semantics (I'd love to get to a
> place where bug-for-bug compatibility wasn't required, but this is where
> we are right now so *shrug*).

Thanks Nick for getting this through!

A bientôt,
Armin
___
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