It looks to me like dict.__copy__ is not implemented, does anyone know why it's
not basically an alias for dict.copy?
If it's just random happenstance, presumably we could move dict.copy to
__copy__ and then have dict.copy as an alias or thin wrapper. It might be
desirable anyway for copy.copy
I agree that if this is only in 3.9 then this is a cleanup of semantics that
were a bit off and should stay but get a mention in What's New.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
I agree that if we want to go down the road of creating a copy to allow for
subclasses then we should define a dunder method for such a use, even if it's
redundant in the face of dict.copy().
___
Python-Dev mailing list -- python-dev@python.org
To unsub
You can find the rationale for this change in two issues:
* https://bugs.python.org/issue27987
* https://bugs.python.org/issue36618
First, it was a warning in clang ubsan (Undefined Behavior Sanitizer).
Then ctypes started to crash when Python was compiled with clang. It
means that compiling Pyth
On Feb 7, 2020, at 13:33, Antoine Pitrou wrote:
> On Fri, 07 Feb 2020 14:59:19 +0100
> Julien Danjou wrote:
>> I've been hit by a segfault recently in a binary wheel running on Python
>> 3.7.3, but that worked fine on Python 3.7.5.
>
> Can you clarify a bit? Was it with a single specific packag
On Fri, 07 Feb 2020 14:59:19 +0100
Julien Danjou wrote:
> Hi fellows,
>
> I've been hit by a segfault recently in a binary wheel running on Python
> 3.7.3, but that worked fine on Python 3.7.5.
Can you clarify a bit? Was it with a single specific package, or is it
reproducible with several Pyth
ACTIVITY SUMMARY (2020-01-31 - 2020-02-07)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7288 (-12)
closed 44042 (+80)
total 51330 (+68)
Open issues wi
On Fri, Feb 7, 2020 at 1:48 AM Mark Shannon wrote:
> Including the function name in the error message is misleading.
>
> "TypeError: print() argument after * must be an iterable, not int"
> implies that the error is related to `print`. It is not; the error is
> entirely on the caller's side. The
Hi fellows,
I've been hit by a segfault recently in a binary wheel running on Python
3.7.3, but that worked fine on Python 3.7.5.
The code was compiled on Python 3.7.5 using manylinux1 Docker images and
transformed in a manylinux1 wheel. The segmentation fault back trace did
not make any sense, s
On 06/02/2020 9:56 pm, Serhiy Storchaka wrote:
06.02.20 08:28, Brandt Bucher пише:
Commits 13bc139 and 8a4cd70 introduced subtle changes in the
evaluation logic of unpacking operations. Previously, all elements
were evaluated prior to being collected in a container. Now, these
operations are
07.02.20 01:00, Guido van Rossum пише:
How did we move from [*a,...] to print(*a,...)? They are quite different.
They are quite similar. The code for `(*a, *b, *c)` is:
1 0 LOAD_NAME0 (a)
2 LOAD_NAME1 (b)
4 LOAD_NAME
Sorry, ignore that - I see Serhiy used "print(*a)".
Paul
On Fri, 7 Feb 2020 at 08:10, Paul Moore wrote:
>
> On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
> >
> > How did we move from [*a,...] to print(*a,...)? They are quite different.
>
> It was a good way to demonstrate evaluation order
On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
>
> How did we move from [*a,...] to print(*a,...)? They are quite different.
It was a good way to demonstrate evaluation order, as an expression
with a visible side effect. What the expression [print("a"), *None,
print("b")] prints before the
07.02.20 01:00, Paul G пише:
I will note that it doesn't seem to be true that operators never call
standard methods. Looks like date.__add__ calls date.toordinal and
date.fromordinal (at least in the pure Python implementation), and
datetime calls those plus tzinfo.utcoffset. Not sure if the ru
14 matches
Mail list logo
