[Python-Dev] Re: Python standardization

[Victor Stinner]

See "A formal specification for the (C)Python virtual machine - Python
Language Summit 2020" by Mark Shannon:
https://pyfound.blogspot.com/2020/04/a-formal-specification-for-cpython.html

Victor

On Fri, Feb 12, 2021 at 7:40 PM Dan Stromberg  wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it 
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its growth 
> and avoiding featuritis.
>
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
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/2NHEU5AZS3GHJXYAJPFMS27NY737BSPT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

[Victor Stinner]

On Mon, Feb 15, 2021 at 6:31 AM Inada Naoki  wrote:
> * PYTHONWARNENCODING / warn_ecoding

(I love this "ecoding" typo, but it's not my favorite choice ;-))

I dislike "warn_encoding" because it is too generic. An encoding?
Which one? Why does anyone want to emit a warning when an encoding is
used? Ah, only when it's not specified?

> * PYTHONWARNOMITENCODING / warn_omit_encoding
> * PYTHONWARNDEFAULTENCODING / warn_default_encoding

IMO this name describes exactly what the PEP 597 purpose. It can be
read aloud: "emit a warning when the default encoding is used".

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/HJH2FE2KUOXKZ4ZUJTZ4HXMTXHXOQU4E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Emily Bowman]

FWIW, it would really be nice if this was called IsInstance[...]; I feel
like that would neatly encapsulate its meaning to both old and new, that
it's just a yes/no on whether this is an instance of [...]. TypeScript has
the concept of a type guard but doesn't use that name in code, so there's
no reason to be wedded to it.

-Em
___
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/T3XEKYHDOFC6EDVUSC55AQKLW2NY3JWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Merge Request Review Reminder

[Faisal Mahmood]

Hello,

I hope you are all well, I currently have an issue / merge request that has
become stale and as per the guidelines I am sending this e-mail to request
someone to review it for me please.

Issue Number: 42861 (https://bugs.python.org/issue42861)
Pull Request: 24180 (https://github.com/python/cpython/pull/24180)

This is my first contribution to CPython and I am very keen to get this
added as I think it is an almost essential enhancement missing from the
ipaddress module.  I would greatly appreciate if someone can take a look
and give me feedback, I am more than happy to help explain things, as I
appreciate this is not the most straightforward thing to do.

Effectively, this method allows you to get the next closest network of any
prefix size, it works by effectively adding 1 to the host portion of the
network.  There is actually a very nice guide someone made on stackexchange
explaining how to do this calculation manually, I simply followed this
logic and have tested it as much as possible and it seems to work great.
See here:
https://networkengineering.stackexchange.com/questions/7106/how-do-you-calculate-the-prefix-network-subnet-and-host-numbers/53994#53994

Please let me know if there is anything else I can do to help get this
merged.

Kind regards,

Faisal.
___
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/ICVG3PZG2IYMMGQKW7Q5GDTM4HIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Security releases of CPython

[Victor Stinner]

Hi Michał,

I created https://python-security.readthedocs.io/ website to track
known Python vulnerabilities to help me checking if fixes are
backported to all supported Python branches. I'm maintaing this list
manually, it's far from being complete, and likely outdated.

I also created https://github.com/vstinner/check_python_vuln project
which implements runtime checks for a few Python vulnerabilities. It
should help users and Linux packagers to check if their Python has
known vulnerabilities or not.

On Thu, Feb 11, 2021 at 9:44 PM Michał Górny  wrote:
> I feel that vulnerability fixes do not make it to end users fast enough.
> For example, according to the current release schedules for 3.9 and 3.8,
> the bugfix releases are planned two months apart. While the release is
> expected to happen in the next few days, both versions are known to be
> vulnerable for almost a month!

We are doing our best to fix all known security vulnerabilities in all
maintained Python versions (3.6, 3.7, 3.8, 3.9 and master: 5
branches). But we have no policy to define the severity of these
vulnerabilities. IMO sometimes we are a little bit too conservative
when marking some issues are "security" issues.

For example, the https://bugs.python.org/issue41944 "CJK codecs tests
call eval() on content received via HTTP" issue only impacts users
running the Python test suite.
https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html
gives the timeline, extract:

2020-10-05 (+0 days): Reported (email sent to the PSRT list)
(...)
2020-10-22 (+17 days): CVE-2020-27619 published
2020-12-07 (+63 days): Python 3.9.1 released
2020-12-21 (+77 days): Python 3.8.7 released

IMO here the delay is reasonable (~2 months for 3.8 and 3.9 versions)
for this kind of vulnerability.

HTTP header and email header injections vulnerabilities are bad, but
they can be prevented by applications. For example, good user inputs
validation should prevent such vulnerability. Example of HTTP header
injection timeline:
https://python-security.readthedocs.io/vuln/http-header-injection-method.html

Do you have a specific kind of vulnerability in mind that would
require a faster release?


> 2. When releases happen, security fixes are often combined with many
> other changes. This causes problems for distribution maintainers who, on
> one hand, would like to deploy the security fixes to production versions
> ASAP, and on the other, would prefer that the new version remained in
> testing for some time due to the other changes.

We attempt to avoid incompatible changes in 3.x.y bug fix releases. If
it happens, we can consider to revert it on a case by case basis.
Usually, it is discussed before merging a change.

Usually, the incompatible changes that we allow are justified... to
fix security issues :-)

Do you have a specific example of problematic incompatible change in
mind? For me, the largest change was a Python 2.7 release which
started to check TLS certificates on HTTP... It was to make Python
more secure to protect users :-)

> Furthermore, I think that at least for branches that are in higher level
> of maintenance than security, it could make sense to actually make
> security releases (e.g. 3.9.1.x) that would include only security fixes
> without other changes.

IMO that's too much work for everybody. developers, testers and packagers.

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/PBZADDEVMQNWAHMR6XZD3BAYVP3OE3HM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Victor Stinner]

On Tue, Feb 9, 2021 at 4:53 AM Kazantcev Andrey  wrote:
> I decided to figure out why it is impossible to change methods of built-in 
> types and found
> ```
> if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
> PyErr_Format(
> PyExc_TypeError,
> "can't set attributes of built-in/extension type '%s'",
> type->tp_name);
> return -1;
> }
> ```
> in function type_setattro.
> If comment this line and try to patch method __eq__ on the list for example 
> the code will work as expected

I removed this "if" and tested:

$ ./python
Python 3.10.0a5+ (heads/master-dirty:ab2d481639, Feb 16 2021, 00:55:58)
>>> "a" == "b"
False
>>> str.__eq__=lambda x,y: True
>>> "a" == "b"
True

It seems technically possible to override attributes/methods of
built-in types, but the question is more if it's desirable?

IMO it goes against the specification of the Python language itself.
For example, in Python, it's not allowed to add methods to built-in
types. Example (with the removed "if")

>>> str.strip_spaces=lambda s: s.strip(" \t")
>>> " a ".strip_spaces()
'a'

The problem is that built-in types are shared by everything, and
adding non-standard methods means that code using it becomes
non-standard (cannot be used on an "unmodified" Python). Do you want
to see projects popping up on PyPI which rely on a special
(non-standard) str methods like strip_spaces()?

I didn't use Ruby on Rails, but the feedback that I heard is that the
ability to extend built-in types is appealing, but it is problematic
in practice.

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/WOEGG2G5PKIXFVB5YOF7MI6OPNTCYQCZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Emily Bowman]

On Mon, Feb 15, 2021 at 4:11 PM Victor Stinner  wrote:

>
> I didn't use Ruby on Rails, but the feedback that I heard is that the
> ability to extend built-in types is appealing, but it is problematic
> in practice.
>

Monkeypatching's such a part of the Ruby (and Javascript) culture that
there isn't much pushback over it. The biggest problem is that it's such a
part of the culture that it's not uncommon to have multiple modules
redefining the same name in incompatible ways, which is as painful to track
down as it sounds. Ruby also has refinements, which only modify within a
specific scope (up to a single file), so forgetting whether it's enabled
can get you even inside the same project.

-Em
___
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/RWDD7ENAIUQKO62ISDMSG53I7AD5DNLD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Guido van Rossum]

On Sun, Feb 14, 2021 at 7:17 PM Inada Naoki  wrote:

> On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez  wrote:
> >
> > > How about having a pseudo-module called __typing__ that is
> > > ignored by the compiler:
> > >
> > > from __typing__ import ...
> > >
> > > would be compiled to a no-op, but recognised by type checkers.
> >
> > If you want to do run-time typing stuff, you would use
> > There is already a way of doing that: `if typing.TYPE_CHECKING: ...`
> https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
> > But yes, the issue with it is that this constant is defined in the
> `typing` module …
> >
> > However, I think this is a part of the solution. Indeed, the language
> could define another builtin constants, let's name it `__static__`, which
> would simply be always false (at runtime), while linters/type checkers
> would use it the same way `typing.TYPE_CHECKING` is used:
> > ```python
> > if __static__:
> > import typing
> > import expensive_module
> > ```
>
>
> Please note that this is a thread about PEP 649.
>
> If PEP 649 accepted and PEP 563 dies, all such idioms breaks
> annotation completely.
>
> Users need to import all heavy modules and circular references used
> only type hints, or user can not get even string form annotation which
> is very useful for REPLs.
>

Hm, that's a rather serious problem with Larry's PEP 649 compared to `from
__future__ import annotations`, actually.

Larry, what do you think?

-- 
--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/6BH5YFZP7YRWCI5P7GH44OX775X46FI3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.7.10 and 3.6.13 security updates now available

[Ned Deily]

Python 3.7.10 and 3.6.13, the lastest security fix rollups for Python 3.7 and 
Python 3.6, are now available. You can find the release files, links to the 
changelogs, and more information here:

https://www.python.org/downloads/release/python-3710/
https://www.python.org/downloads/release/python-3613/

These releases are source code only; Windows and macOS binary installers are 
not provided for security fix releases.

Note that Python 3.9 is now the latest feature release series of Python 3. You 
should consider upgrading to 3.9 as soon as practical. Get the latest release 
of 3.9.x here:

https://www.python.org/downloads/

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf-landing/

--
  Ned Deily
  n...@python.org -- []
___
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/RZPY657ZXBRBKMC3H2GDO7TDG2F7UWB7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Larry Hastings]

I don't work on these sorts of codebases, and I don't use type hints or 
static type checking.  So I'm not really qualified to judge how bad / 
widespread a problem this is.  It's my hope that the greater Python core 
dev / user community can ascertain how serious this is.


My main observation is that, for users facing this problem, they still 
have options.  Off the top of my head, they could:


 * maintain a lightweight "mock" version of expensive_module, or
 * stringize their type hints by hand, or
 * perhaps use with some hypothetical stringizing support library that
   makes it less-painful to maintain stringized annotations.

(I assume that static type checkers could continue to support stringized 
type hints even if PEP 649 was accepted.)


I admit I'd be very surprised if PEP 649 was judged to be unworkable, 
given how similar it is to stock Python semantics for annotations at 
runtime.



Cheers,


//arry/

On 2/15/21 8:14 PM, Guido van Rossum wrote:
On Sun, Feb 14, 2021 at 7:17 PM Inada Naoki > wrote:


On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez mailto:jope...@hotmail.fr>> wrote:
>
> > How about having a pseudo-module called __typing__ that is
> > ignored by the compiler:
> >
> > from __typing__ import ...
> >
> > would be compiled to a no-op, but recognised by type checkers.
>
> If you want to do run-time typing stuff, you would use
> There is already a way of doing that: `if typing.TYPE_CHECKING:
...`
https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING

> But yes, the issue with it is that this constant is defined in
the `typing` module …
>
> However, I think this is a part of the solution. Indeed, the
language could define another builtin constants, let's name it
`__static__`, which would simply be always false (at runtime),
while linters/type checkers would use it the same way
`typing.TYPE_CHECKING` is used:
> ```python
> if __static__:
>     import typing
>     import expensive_module
> ```


Please note that this is a thread about PEP 649.

If PEP 649 accepted and PEP 563 dies, all such idioms breaks
annotation completely.

Users need to import all heavy modules and circular references used
only type hints, or user can not get even string form annotation which
is very useful for REPLs.


Hm, that's a rather serious problem with Larry's PEP 649 compared to 
`from __future__ import annotations`, actually.


Larry, what do you think?

--
--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/FLMZYC2USYBTJABAQLVCNQEZUVVU26WD/
Code of Conduct: http://python.org/psf/codeofconduct/