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

[Serhiy Storchaka]

17.02.20 23:02, Guido van Rossum пише:
Now that the last bits of discussion about PEP 584 have been settled (we 
will *not* be calling the `copy` or `update` methods) I am accepting 
this PEP. Congratulations Steven and Brandt!


Thanks to everyone else who gave their opinion.

Formally, I will just send my recommendation to accept the PEP to the 
Steering Council -- they will then let us know whether they agree, and 
once that's done we can update the PEP with the "Accepted" status and 
land the implementation (https://github.com/python/cpython/pull/12088). 
(Hm, the PEP should probably also link to that PR rather than to 
Brandt's private branch.)


Comments to the PEP.

In the disadvantages of existing syntax `{**d1, **d2}` 
(https://www.python.org/dev/peps/pep-0584/#d1-d2) it claims:



{**d1, **d2} ignores the types of the mappings and always returns a dict. 
type(d1)({**d1, **d2}) fails for dict subclasses such as defaultdict that have 
an incompatible __init__ method.


But it was decided that `d1 | d2` also should ignore the types of the 
operands and always return a dict. And it accepts only dicts, not 
general mappings, in difference to `{**d1, **d2}`.


So the only disadvantage of `{**d1, **d2}` is that it is not well known 
and "looks ugly". But it supports general mappings.


There is a similar note about ChainMap 
(https://www.python.org/dev/peps/pep-0584/#collections-chainmap)



Like dict unpacking, it is tricky to get it to honor the desired subclass. For 
the same reason, type(d1)(ChainMap(d2, d1)) fails for some subclasses of dict.


which is not relevant to the final implementation of PEP 584.


The pure-Python implementation of the non-inplace operator can be 
simpler if use dict unpacking:


def __or__(self, other):
if not isinstance(other, dict):
return NotImplemented
return {**self, **other}

def __ror__(self, other):
if not isinstance(other, dict):
return NotImplemented
return {**other, **self}


I suggest to include to objections that non-inplace merging of two dicts 
is much less common operation than concatenating of two strings or other 
sequences, and that the existing syntax `{**d1, **d2}` completely 
satisfies the need. The in-place operator is completely equivalent to 
dict.update(). So the possible benefit of adding support of two 
operators for dict is much less than common bar for changes in the 
builtin types.


This is why I still -0 for this feature. In the initial form it 
contradicted the behavior of other builtin types and operators, but 
after fixing contradictions it became pretty useless.

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

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

[Nick Coghlan]

On Tue., 18 Feb. 2020, 12:14 am Mark Shannon,  wrote:

>
> Any function returning a borrowed reference is already broken, IMO.
> Sadly there are quite a few of them :(
> Might as well fix `PyEval_GetLocals()` as we are changing its semantics
> anyway.
>
> A quick search of GitHub shows that most uses erroneously fail to
> increment the reference. So changing `PyEval_GetLocals()` to return a
> real reference would convert a possible crash into a memory leak.
> Maybe that's an improvement, maybe not, but it is a reasonable change IMO.
>

If the idea I had yesterday works out, then `PyEval_GetLocals()` will end
up having exactly the same behavior as it does in 3.8, but we'll have a
potential path towards some day deprecating and removing it (since there
will be better behaved APIs offering equivalent functionality).


> >
> > The proposed APIs instead aim to make it possible to access the Python
> > locals without needing to acquire a frame object reference at all.
>
> Why would you need to do that? An addition to the C API needs a much
> stronger justification than "it might be handy for someone".
>

The latest iteration of the PEP goes into more detail, but the key point is
that the Python semantics are difficult to handle from the point of view of
extension module code, because you can't tell just from looking at the code
whether the locals() equivalent is going to return a copy or not.

So the proposed C API instead lets the consuming code choose between:

* get a read-only view
* get a shallow copy
* use the Python level semantics (with a query function to find out what
those semantics are in the running frame)

That way, it will be easier to write extension module code that behaves the
same way in all scopes, or at least fails loudly if it doesn't work
properly in the running frame.

Cheers,
Nick.



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

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

[Guido van Rossum]

Now that the last bits of discussion about PEP 584 have been settled (we
will *not* be calling the `copy` or `update` methods) I am accepting this
PEP. Congratulations Steven and Brandt!

Thanks to everyone else who gave their opinion.

Formally, I will just send my recommendation to accept the PEP to the
Steering Council -- they will then let us know whether they agree, and once
that's done we can update the PEP with the "Accepted" status and land the
implementation (https://github.com/python/cpython/pull/12088). (Hm, the PEP
should probably also link to that PR rather than to Brandt's private
branch.)

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

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

[Mark Shannon]

On 16/02/2020 1:35 pm, Nick Coghlan wrote:
On Mon., 10 Feb. 2020, 8:31 pm Mark Shannon, > wrote:



On 08/02/2020 11:49 am, Nick Coghlan wrote:
 > Unfortunately, the simplifications you propose would be backwards
 > incompatible - it's existing behaviour that there's a real shared
dict
 > (even on optimised frames) where arbitrary extra attributes can be
 > stored (even though they don't become accessible as Python
variables).
 > I don't want to make frame objects any bigger than they already are,
 > so the natural solution is to store the mapping proxy as `f_locals`,
 > and then bypass the proxy in order to make `PyEval_GetLocals` still
 > "work" (at least as well as it ever did).

The proposed changes in PEP 558 are also backwards incompatible.
I thought that was the point. The current implementation is broken in
weird ways and we want to fix that. Since we need to break backward
compatibility anyway, why not do it in a way the makes the behaviour as
well defined and maintainable as possible.


The changes at the Python level are *technically* incompatible, but 
Nathaniel's review made a compelling case that the real world 
compatibility problems were likely to be minimal, and in some cases 
would actually be fixing latent defects in existing code.


I think that PEP 558, as it stands, is still a bit fragile because of
the handling of cycles between the locals proxy and the frame.


Unfortunately, I'm not entirely sure there's any way to get rid of that 
without getting rid of PyEval_GetLocals() completely, and that 
*wouldn't* be a subtle break in the slightest (it's even part of the 
stable ABI).


Since that API returns a borrowed reference, the real reference has to 
live somewhere, and the most natural place is the frame f_locals 
attribute (as that's where it lives today).


Any function returning a borrowed reference is already broken, IMO.
Sadly there are quite a few of them :(
Might as well fix `PyEval_GetLocals()` as we are changing its semantics 
anyway.


A quick search of GitHub shows that most uses erroneously fail to 
increment the reference. So changing `PyEval_GetLocals()` to return a 
real reference would convert a possible crash into a memory leak.

Maybe that's an improvement, maybe not, but it is a reasonable change IMO.



And even if we *did* manage to resolve that dilemna, we then run into 
the problem that we also need the frame object to hold the proxy because 
the C level equivalent of accessing the attribute is just 
"frame->f_locals": it's not an opaque struct, so that pointer is part of 
the public API.
I don't think the internal structure of Python objects is part of the 
API. Otherwise we couldn't change anything, ever.




I agree I should explain this aspect clearly in the PEP though (and 
likely in some block comments in the implementation), as you're quite 
right that the associated reference borrowing and cycle breaking code is 
thoroughly nasty now that the namespace object isn't going to be a 
simple dictionary.


(Thinking out loud, though: something that might work is for each locals 
proxy to use a common snapshot namespace, and store *that* on the frame, 
exactly as we do today. That would replace the cycle in the current 
implementation with multiple references to the common snapshot)



 >
 > PyObject_GetAttr(string) also doesn't do that same thing as the
 > proposed C functions, since it invokes the Python descriptor
 > machinery. (Note that the discussion at
 >
https://discuss.python.org/t/pep-558-defined-semantics-for-locals/2936/
 > is more up to date than the PEP text where the C API is concerned)

`PyObject_GetAttr("attr")` has the same semantics as the Python
operator
`x.attr` which is under the control of `type(x)`, in this case the
frame
object class. The descriptor protocol is irrelevant.


The now proposed C APIs don't include one to get access to the 
write-through proxy, so you do indeed have to use PyObject_GetAttr for that.


The proposed APIs instead aim to make it possible to access the Python 
locals without needing to acquire a frame object reference at all.


Why would you need to do that? An addition to the C API needs a much 
stronger justification than "it might be handy for someone".





 >
 > The reference to tracing mode dependent semantics puzzles me, as that
 > was removed in December:
 >

https://github.com/python/peps/commit/54888058ce8ad5257114652d9b41e8d1237b8ef9#diff-5abd04ea7e619670b52d61883873e784
 >

That was my misreading. The behaviour of `f_locals` in the PEP is not
very clear, as it is buried in the discussion of CPython changes.
Could you add it to the proposal section?


Aye, I'll do that when clarifying the complications arising from wanting 
to keep PyEval_GetLocals() and direct "frame->f_locals" access working 
pretty closely to the 

[Python-Dev] Re: Azure Pipelines PR: Unresponsive agent

[Victor Stinner]

Le sam. 1 févr. 2020 à 12:34, Steve Dower  a écrit :
> I think we're at the point where it's probably okay to disable Azure
> Pipelines as a required check and replace it with the GitHub Actions checks.

More and more often, I'm waiting for Azure Pipelines to complete: it's
currently the slowest "CI" (made of multiple jobs) on pull requests.
But it seems like Azure Pipelines basically re-do the same tests which
are already done on GitHub Actions: Windows (32 and 64-bit), macOS,
Ubuntu, Docs.

GitHub Actions seem better integrated with GitHub.

Would it make sense to simply remove Azure Pipelines integration, to
only keep GitHub Actions? It would allow to merge PRs faster.

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

[Python-Dev] Re: Regarding SSL installation in python

[Kyle Stanley]

Hey Chaitanya,

The "python-dev" mailing list is specifically for the development *of*
Python itself, not for general help with Python. "comp.lang.python" or
"python-help" is more likely the list you're looking for.

Also, for general information on the purpose of each of the primary mailing
lists, see https://www.python.org/community/lists/.

On Mon, Feb 17, 2020 at 1:04 AM Naga Chaitanya L <
nagachaitany...@vasudhaika.net> wrote:

> Hi,
> I want to know how to install ssl certificate in python. please give me
> referral link.
> thnk u
> Regards!
> chaitanya
> ___
> 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/LS6OFKHCJILJIYRHRDCTHEMUHSAU47CE/
> 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/D4OPKMFXQDIZSZBQKCYONRURTWCDYT5L/
Code of Conduct: http://python.org/psf/codeofconduct/