[Python-Dev] Re: macOS issues with 3.8.7rc1

[Ronald Oussoren via Python-Dev]

> On 10 Dec 2020, at 06:38, Greg Ewing  wrote:
> 
> On 10/12/20 10:28 am, Guido van Rossum wrote:
>> In my experience Apple hardware is very reliable and way outlives the OS 
>> updates. Even if an OS updates is still available, the newer OS often needs 
>> more memory, which can be a problem
> 
> Another problem, for me at least, is that OS updates often seem
> to remove functionality that I like and rely on. I stuck with
> 10.6 for a very long time, because it did everything I wanted,
> and there were some third party extensions I used that stopped
> working in 10.7 and there were no good replacements available.

Luckily there are no plans to remove support for macOS versions :-)

For master and 3.9 we can build on macOS 11 and deploy to macOS 10.9 and that  
won’t change. For 3.8 that doesn’t work yet, but backporting is just boring 
work. For 3.7 and earlier this will never work, those branches are closed for 
development.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> 
> -- 
> Greg
> ___
> 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/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/57DWVZDDJNXBNT6UKGSFH5STJHYREAHO/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MQWRHCXJ57GBT3FV53MGWWWO7XPMNCTO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Can lib2to3 and 2to3 be deprecated yet?

[Victor Stinner]

Hi,

I vaguely recall that PEP 617 "New PEG parser for CPython" was
supposed to deprecate the lib2to3 module and the 2to3 program.

I see that lib2to3/__init__.py contains a PendingDeprecationWarning in
Python 3.9. Can it be converted into a regular DeprecationWarning and
document the deprecation in Doc/library/2to3.rst?

--

Do we still want to maintain lib2to3? People who didn't migrate to
Python 3 can use 2to3 of Python 3.9 or Python 3.10. There are also
other tools like 2to6, modernize, etc. (or my "sixer" project which I
no longer maintains.)

I'm not sure sure if the lib2to3 module is used by 3rd party projects
like modernize or black?

I understood that lib2to3 is a LL(1) parser and so cannot be used with
latest Python grammar.

Well, also, Python 2.7 is not longer supported.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6PL5LMSLYVHJNLTCGUDYWVAU2VTS3CYW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Can lib2to3 and 2to3 be deprecated yet?

[Matthias Klose]

On 12/10/20 10:58 AM, Victor Stinner wrote:
> Hi,
> 
> I vaguely recall that PEP 617 "New PEG parser for CPython" was
> supposed to deprecate the lib2to3 module and the 2to3 program.
> 
> I see that lib2to3/__init__.py contains a PendingDeprecationWarning in
> Python 3.9. Can it be converted into a regular DeprecationWarning and
> document the deprecation in Doc/library/2to3.rst?
> 
> --
> 
> Do we still want to maintain lib2to3? People who didn't migrate to
> Python 3 can use 2to3 of Python 3.9 or Python 3.10. There are also
> other tools like 2to6, modernize, etc. (or my "sixer" project which I
> no longer maintains.)
> 
> I'm not sure sure if the lib2to3 module is used by 3rd party projects
> like modernize or black?

lib2to3 is used by distutils/util, so why deprecate it before distutils?
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KZ37BBHWE7UG65J6APC6ONW2LGWFXNTT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Can lib2to3 and 2to3 be deprecated yet?

[Victor Stinner]

Le jeu. 10 déc. 2020 à 11:51, Matthias Klose  a écrit :
> lib2to3 is used by distutils/util, so why deprecate it before distutils?

I don't think that it's exclusive. We can deprecate the 2to3 feature
in distutils as well. But please don't put a requirement on
deprecating distutils to be able to deprecate 2to3: there is the PEP
632 for that.

Now I recall that docutils, which is used by Sphinx uses, the 2to3
feature of distutils. I was surprised to see that. This project can
run 2to3 once and drop Python 2 support (or use any other tool to keep
Python 2 support if they prefer).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JMZR5SNOE2TMVH4AQYRUSO6JXCZET5MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Can lib2to3 and 2to3 be deprecated yet?

[Guido van Rossum]

See https://bugs.python.org/issue40360

On Thu, Dec 10, 2020 at 3:01 AM Victor Stinner  wrote:

> Le jeu. 10 déc. 2020 à 11:51, Matthias Klose  a écrit :
> > lib2to3 is used by distutils/util, so why deprecate it before distutils?
>
> I don't think that it's exclusive. We can deprecate the 2to3 feature
> in distutils as well. But please don't put a requirement on
> deprecating distutils to be able to deprecate 2to3: there is the PEP
> 632 for that.
>
> Now I recall that docutils, which is used by Sphinx uses, the 2to3
> feature of distutils. I was surprised to see that. This project can
> run 2to3 once and drop Python 2 support (or use any other tool to keep
> Python 2 support if they prefer).
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JMZR5SNOE2TMVH4AQYRUSO6JXCZET5MD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZABVN24TFHAGNINIOFBWXIXI7D4HHCNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

[Brett Cannon]

On Wed, Dec 9, 2020 at 7:38 PM Larry Hastings  wrote:

> On 12/9/20 5:21 PM, Ethan Furman wrote:
>
> On 12/9/20 5:01 PM, Larry Hastings wrote:
>
> > "Misc/NEWS" is no longer checked in, it's generated on demand using
> "blurb merge".
>
> So if I understand correctly, blurb makes NEWS, but `whatsnew` is still
> done by hand.
>
>
> Correct.  You'll notice that each "whatsnew" lists its "editor"; for
> example, Lukasz edited the whatsnew document for 3.9.  If you want to
> ensure there is "whatsnew" coverage for your change you should contact the
> relevant editor for that version.
>

I will also say that I have floated the idea of trying to be more
diligent/thoughtful of managing What's New entries (at least for the
initial population of that doc) as I know various editors in the past have
said it's a huge time sink (so it's more editorial and less gathering). But
they have also said they didn't care about a tool to help compile the
initial entries, so 🤷‍♂️.


>
> */arry*
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DYLP6YAW23JSQNCQ5WZL4B5KKIWN6MXW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PMROEXCWZKA6I2ANHDWBUTBK6IMVXK3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Runtime vs. Static Typing

[Paul Bryan]

Per PEP 563:

> Most importantly, Guido van Rossum explicitly stated interest in
> gradually restricting the use of annotations to static typing (with
> an optional runtime component).

As I'm working on runtime type encoding and validation using type
annotations, this passage raises a bit of a concern, as I don't know
what is meant by optional runtime component.

Looking for any discussion on this. I checked:

https://bugs.python.org/issue38605
https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed

Can't find any references to runtime. Can someone point me to (or
briefly explain) the thinking on this?

Thanks,

Paul

___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Runtime vs. Static Typing

[Guido van Rossum]

Hi Paul,

The runtime component is the API provided by the `typing` module such as
`get_type_hints()`, plus the `__annotations__` attribute on various objects
(classes and functions, mostly).

I am not aware of any plans or proposals to remove `__annotations__` or
`typing.get_type_hints()`, and obviously use cases like yours abound.

That said, the needs of static checking (e.g. mypy) and runtime checking
(e.g. JSON schema checkers) sometimes diverge, and in those cases I tend to
favor the needs of static checkers.

PEP 563 is an example: we found that developers were having a hard time
with the original requirement that all annotations are evaluated as
expressions at the time the function definition is executed, since it makes
forward references difficult (requiring the hack of enclosing the
annotation in string quotes).

At the same time we found that static type checks are much more used than
runtime type checks -- presumably for performance reasons. So PEP 563 was
born -- annotations containing forward references no longer need to be
quoted, making the use of static checkers simpler, while still catering to
the needs of runtime checkers via typing.get_type_hints(). (Note that the
latter was already needed to deal with explicitly quoted forward references
pre-PEP-563.)

It is not inconceivable that eventually type system features will be
introduced that are hard to check at runtime, and in such cases we will not
let that stop us from defining the new type system feature. (I already
doubt that there are runtime checkers that check the consistent use of type
variables at runtime.)

That said, I don't see a reason to start deprecating the runtime
introspection features of the existing annotation syntax, and if you look
at PEP 585 (`list[int]` etc.) or PEP 604 (`int | str` union notation)
you'll see that they are completely runtime introspectable. (Believe me, it
would have been much simpler to erase type parameters completely at
runtime, but I personally wrote most of the implementation to make them
available via attributes on the `types.GenericAlias` type.)

Hope this helps,

--Guido

On Thu, Dec 10, 2020 at 7:17 PM Paul Bryan  wrote:

> Per PEP 563:
>
> Most importantly, Guido van Rossum explicitly stated interest in gradually
> restricting the use of annotations to static typing (with an optional
> runtime component).
>
>
> As I'm working on runtime type encoding and validation using type
> annotations, this passage raises a bit of a concern, as I don't know what
> is meant by optional runtime component.
>
> Looking for any discussion on this. I checked:
>
> https://bugs.python.org/issue38605
> https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed
>
> Can't find any references to runtime. Can someone point me to (or briefly
> explain) the thinking on this?
>
> Thanks,
>
> Paul
>
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OSA7VKZSAHQTTVEJDU2MZXESQKTDNKTB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Runtime vs. Static Typing

[Paul Bryan]

Thanks. Concern allayed. 🙂

On Thu, 2020-12-10 at 21:55 -0800, Guido van Rossum wrote:
> Hi Paul,
> 
> The runtime component is the API provided by the `typing` module such
> as `get_type_hints()`, plus the `__annotations__` attribute on
> various objects (classes and functions, mostly).
> 
> I am not aware of any plans or proposals to remove `__annotations__`
> or `typing.get_type_hints()`, and obviously use cases like yours
> abound.
> 
> That said, the needs of static checking (e.g. mypy) and runtime
> checking (e.g. JSON schema checkers) sometimes diverge, and in those
> cases I tend to favor the needs of static checkers.
> 
> PEP 563 is an example: we found that developers were having a hard
> time with the original requirement that all annotations are evaluated
> as expressions at the time the function definition is executed, since
> it makes forward references difficult (requiring the hack of
> enclosing the annotation in string quotes).
> 
> At the same time we found that static type checks are much more used
> than runtime type checks -- presumably for performance reasons. So
> PEP 563 was born -- annotations containing forward references no
> longer need to be quoted, making the use of static checkers simpler,
> while still catering to the needs of runtime checkers via
> typing.get_type_hints(). (Note that the latter was already needed to
> deal with explicitly quoted forward references pre-PEP-563.)
> 
> It is not inconceivable that eventually type system features will be
> introduced that are hard to check at runtime, and in such cases we
> will not let that stop us from defining the new type system feature.
> (I already doubt that there are runtime checkers that check the
> consistent use of type variables at runtime.)
> 
> That said, I don't see a reason to start deprecating the runtime
> introspection features of the existing annotation syntax, and if you
> look at PEP 585 (`list[int]` etc.) or PEP 604 (`int | str` union
> notation) you'll see that they are completely runtime introspectable.
> (Believe me, it would have been much simpler to erase type parameters
> completely at runtime, but I personally wrote most of the
> implementation to make them available via attributes on the
> `types.GenericAlias` type.)
> 
> Hope this helps,
> 
> --Guido
> 
> On Thu, Dec 10, 2020 at 7:17 PM Paul Bryan  wrote:
> > Per PEP 563:
> > 
> > > Most importantly, Guido van Rossum explicitly stated interest in
> > > gradually restricting the use of annotations to static typing
> > > (with an optional runtime component).
> > 
> > 
> > As I'm working on runtime type encoding and validation using type
> > annotations, this passage raises a bit of a concern, as I don't
> > know what is meant by optional runtime component.
> > 
> > Looking for any discussion on this. I checked:
> > 
> > https://bugs.python.org/issue38605
> >
> https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed
> > 
> > Can't find any references to runtime. Can someone point me to (or
> > briefly explain) the thinking on this?
> > 
> > Thanks,
> > 
> > Paul
> > 
> > ___
> > 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/
> > Message archived at
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 

___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NJUTIIV4XHGOJCMKDWW4NGDHKVZ7DQGZ/
Code of Conduct: http://python.org/psf/codeofconduct/