[Python-Dev] Re: [python-committers] [RELEASED] Python 3.5.10rc1 is released

[Victor Stinner]

Hi,

I checked the vulnerabilities that I'm tracking at
https://python-security.readthedocs.io/vulnerabilities.html

I noticed that https://bugs.python.org/issue39603 "http.client: HTTP
Header Injection in the HTTP method" lacks a fix in the 3.5 branch.

I backported the fix to 3.5: https://github.com/python/cpython/pull/21946

Victor


Le sam. 22 août 2020 à 05:23, Larry Hastings  a écrit :
>
>
> On behalf of the Python development community, I'm pleased to finally 
> announce the availability of Python 3.5.10rc1.
>
> Python 3.5 is in "security fixes only" mode.  This new version only contains 
> security fixes, not conventional bug fixes, and it is a source-only release.
>
> Important Notice: The latest releases of Linux (Ubuntu 20.04, Fedora 32) ship 
> with a new version of OpenSSL.  New versions of OpenSSL often include 
> upgraded configuration requirements to maintain network security; this new 
> version no longer finds Python 3.5's OpenSSL configuration acceptable.  As a 
> result, most or all secure-transport networking libraries are broken in this 
> release on systems where this new version of OpenSSL is deployed.  This 
> means, for example, that seven (7) of the regression tests in the test suite 
> now regularly fail.  Older versions of Linux, with older versions of OpenSSL 
> installed, are unaffected.  We're aware of the problem.  Unfortunately, as 
> 3.5 is nearly completely out of support, it has become very low priority, and 
> we've been unable to find the resources to get the problem fixed.  It's 
> possible that these problems simply won't be fixed in 3.5 before it reaches 
> its end-of-life.  As always we recommend upgrading to the latest Python 
> release wherever possible.
>
>
> You can find Python 3.5.10rc1 here:
>
> https://www.python.org/downloads/release/python-3510rc1/
>
>
>
> Cheers,
>
>
> /arry
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committ...@python.org/message/3Z6X4LPSNRHHW4QPLLAVSNYY6CS6DDNR/
> Code of Conduct: https://www.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/KARM2WRI5HVDP4WGOMWH3INW2QKI7Z3C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: **= does not follow the data model

[Brett Cannon]

On Sun, Aug 23, 2020 at 1:57 PM Guido van Rossum  wrote:

> On Sun, Aug 23, 2020 at 1:09 PM Brett Cannon  wrote:
>
>> If you read the language reference for augmented arithmetic assignment,
>> you will note that it essentially says, "call __i__, and if that
>> doesn't work call as if you were doing a  b". Unfortunately it appears
>> **= does not follow the rule of falling back on the binary arithmetic
>> expression semantics. I have a GitHub gist with demonstration code that
>> shows this happening in both 3.8 and master (
>> https://gist.github.com/brettcannon/fec4152857e0ed551b4da515dc63e580).
>> This was reported in https://bugs.python.org/issue38302, although
>> initially it didn't cover __pow__, only __rpow__ being skipped.
>>
>
> Wow, very subtle bug. (Note that the issue was initially raised on
> StackOverflow.)
>

Yeah, I independently ran into it while writing a future blog post and it
took me a bit to realize that it wasn't me. 😄


>
>
>> This appears to happen because the opcode  for **= calls
>> PyNumber_InPlacePower() (
>> https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Objects/abstract.c#L1159)
>> which calls ternary_op for __ipow__ or __pow__ depending on which is
>> defined, but will never try both (
>> https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Objects/abstract.c#L849).
>> All of the other augmented arithmetic assignment operators have a special
>> binary_iop() function to call which takes care of the fallback logic, so no
>> other augmented arithmetic assignments appear to have this problem (I
>> tested them all regardless).
>>
>
> Ugh, for some reason the public C API PyNumber_InPlacePower() takes three
> arguments, like pow(x, y, z) (which computes x**y %  z), even though there
> is no way to invoke it like that from Python. I'm sure this was set in
> stone when augmented assignments were first introduced -- long before we
> even had type slots. But because of this someone (me?) probably was being
> lazy and thought that implementing the full fallback strategy for **= was
> more effort than it was worth. (I don't think I have ever in my life used
> `**=`. :-)
>

I suspect very few have, hence how this has managed to exist as a bug for
as long as it has.


>
>
>> I think there are two options to fixing this:
>>
>> 1. Add a note to the data model that **= is special and does not fall
>> back (obviously the most backwards-compatible)
>>
>
> I think we ought to do this for 3.8 and 3.9 -- it's too late to change in
> 3.9.0.
>

Yes, I agree. Sorry for forgetting to mention I was assuming these options
were targeting for 3.10.


>
>
>> 2. Fix **= (which makes sense from a language consistency perspective)
>>
>
> We should do this in 3.10.
>

👍

BTW I don't have the bandwidth to review the PR that is attached to the
issue (although it looks like Serhiy has reviewed it; are you up for
meringing it, Serhiy?).


>
>
>> Personally, my vote is for #2 as I don't want to have to remember that
>> **= is somehow special compared to all other augmented assignments. I also
>> don't think the backwards-compatibility risk is at all large since the
>> semantics of turning `a **= b` into `a = a ** b` shouldn't really be
>> different.
>>
>
> But it is enough to give me pause about doing this in bugfix releases.
>

Yeah, I agree that I don't think we can do this as a bugfix because it is
such a shift in semantics.

-Brett


>
>
>> P.S. Why are some of the PyNumber_InPlace*() functions handwritten while
>> others are defined using a macro which mirrors the handwritten ones? Just
>> something I noticed while investigating this.
>>
>
> Is this about some using INPLACE_BINOP and others not using it? I can't
> tell the difference for InPlaceFloorDivide and -TrueDivide, possibly
> because these were added at a later time? git blame show that the
> INPLACE_BINOP macro was introduced by Neil Schemenauer in 2001 for PEP 208
> (Reworking the Coercion Model, by Neil and MAL). We didn't have truediv and
> floordiv then, and I guess when they were added later the same year, for
> PEP 238 (Changing the Division Operator, by Moshe Zadka and myself) we did
> it differently. FWIW the in-place power glitch also originated in the PEP
> 208 commit.
>
> --
> --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/OFGBECRP56PUU5GON5MIGSQ5I2VSTIRC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 515: Non-empty return statement

[Paul Bryan]

Per PEP 515:

> It is a SyntaxError to have a non-empty return statement in an
> asynchronous generator.

Synchronus generators can return values that include it in the
StopIteration exception. Why would a return value in an asynchronous
generator not do the same in the StopAsyncIteration?

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

[Python-Dev] Re: PEP 515: Non-empty return statement

[Nathaniel Smith]

It was decided to leave out 'yield from' support for async generators,
at least for now, due to the implementation complexity. And non-empty
returns in generators are only intended for use with 'yield from', so
they got left out as well.

On Mon, Aug 24, 2020 at 4:48 PM Paul Bryan  wrote:
>
> Per PEP 515:
>
> It is a SyntaxError to have a non-empty return statement in an asynchronous 
> generator.
>
>
> Synchronus generators can return values that include it in the StopIteration 
> exception. Why would a return value in an asynchronous generator not do the 
> same in the StopAsyncIteration?
>
> ___
> 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/IYF6QKMNSTZEVEXBDIJH7NO2VNDJNUZJ/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Nathaniel J. Smith -- https://vorpus.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/ZGYKS2MS2LRGKHU7KD2ZO4SMH3GB3HR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 515: Non-empty return statement

[Larry Hastings]

I bet you meant PEP 525.  PEP 515 is underscores in numeric literals.

And... I thought an empty "return" was equivalent to "return None"?


//arry/

On 8/24/20 4:20 PM, Paul Bryan wrote:

Per PEP 515:

It is aSyntaxErrorto have a non-emptyreturnstatement in an 
asynchronous generator.


Synchronus generators can return values that include it in the 
StopIteration exception. Why would a return value in an asynchronous 
generator not do the same in the StopAsyncIteration?



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