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/m
> So can we just finish PEP 584 without the .copy() call?
Sounds good. I’ll update the implementation and open a PR to the PEPs repo
later tonight. Thanks everybody!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to py
I don't have anything to add on the side of the technical specifics, but I
do want to point out another benefit of adding these APIs: a significant
improvement in testability, since you will be able to test the reduction
and reconstruction behaviours directly, rather than having to infer what is
go
On Sun, Feb 16, 2020 at 02:12:48PM -0800, Guido van Rossum wrote:
> So can we just finish PEP 584 without the .copy() call?
Fine by me.
Thanks to everyone!
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
So can we just finish PEP 584 without the .copy() call? Surely the more
general solution will not be ready for Python 3.9, while PEP 584 is nearly
done. (I'm also skeptical about a general solution, but I'd rather stay out
of that discussion for a while longer, and maybe you all come up with
someth
Brandt Bucher wrote:
> This leads me to believe that we’re approaching the problem wrong. Rather
> than making a
> copy and working on it, I think the problem would be better served by a
> protocol that runs
> the default implementation, then calls some under hook on the subclass to
> build a
>
After a few days of thinking and experimenting, I’ve been convinced that `copy`
(and also `__copy__`) is not the right protocol for what we want to do here. I
believe that 584 can likely continue without subclass-preserving behavior, but
that better behavior could perhaps could be added to *all*
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
