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

[Paul G]

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 to have a "fast path".

On February 7, 2020 11:21:55 PM UTC, Brett Cannon  wrote:
>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 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/ON3E55CDBUDDHY4BEBYH25ZOKZH7HUDQ/
>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/2QG4IE5GAQPPGCEY7JCE2VHZHGFYZIWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification of unpacking semantics.

[Brett Cannon]

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
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NRVXPXZSD54F6JHRKCQEEQTITFPNUPUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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

[Python-Dev] Re: ABI breakage in >= 3.7.4 ?

[Victor Stinner]

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 Python 3.7 with clang also had the issue.

The quick fix was to compile Python with -fmax-type-align=8 when clang
was detected.

But it was a signal that something was wrong in Python on x86-64:
Python didn't respect the x86-64 ABI.

> 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.

Do you know which wheel package caused the issue? Which part of Python
caused the problem? Well, open a issue and try to provide as much
information as possible ;-)

Victor

Le ven. 7 févr. 2020 à 15:01, Julien Danjou  a écrit :
>
> 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, so I guessed it was an ABI change.
>
> After running git bisect for a few hours, it turns out that the culprit
> is the following commit:
>
>   
> https://github.com/python/cpython/commit/8766cb74e186d3820db0a855ccd780d6d84461f7
>
> From my understanding, that commit indeed changes the ABI by modifying
> the header file and the size of the PyGC_Head and breaks code compiled
> on Python >= 3.7.4 running on earlier Python 3.7 version.
>
> I don't know if anything can be done about this now that it's done and
> released. It might be something we want to double check in the future.
> Having some kind of warning when doing backports could be worth it.
>
> Cheers,
> --
> Julien Danjou
> // Free Software Hacker
> // https://julien.danjou.info
> ___
> 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/J2FGZPS5PS7473TONJTPAVSNXRGV3TFL/
> 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/L4LUY7EY3E2KOI5DOBGAN5E5OAONMIYV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: ABI breakage in >= 3.7.4 ?

[Ned Deily]

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 package, or is it
> reproducible with several Python packages?  It would be good to know
> what's required exactly to hit this issue.

And, if you want action on this, please open a new issue about it on 
bugs.python.org.

Thanks!

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

[Python-Dev] Re: ABI breakage in >= 3.7.4 ?

[Antoine Pitrou]

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 Python packages?  It would be good to know
what's required exactly to hit this issue.

Regards

Antoine.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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 with patches: 2864 


Issues opened (43)
==

#39512: expat parser not xml 1.1 (breaks xmlrpclib) - still
https://bugs.python.org/issue39512  opened by mforkel

#39513: NameError: name 'open' is not defined
https://bugs.python.org/issue39513  opened by Sandeep

#39517: runpy calls open_code with Path object
https://bugs.python.org/issue39517  opened by Tomas Ravinskas

#39520: AST Unparser can't unparse ext slices correctly
https://bugs.python.org/issue39520  opened by BTaskaya

#39521: reversed(mylist) much slower on Python 3.8 32-bit for Windows
https://bugs.python.org/issue39521  opened by Stefan Pochmann

#39522: AST Unparser with unicode kinded constants
https://bugs.python.org/issue39522  opened by BTaskaya

#39523: Unnecessary variable assignment and initial loop check in pysq
https://bugs.python.org/issue39523  opened by alex.henrie

#39524: Escape sequences in doc string of ast._pad_whitespace
https://bugs.python.org/issue39524  opened by mpheath

#39529: Deprecate get_event_loop()
https://bugs.python.org/issue39529  opened by asvetlov

#39530: Documentation about comparisons between numeric types is misle
https://bugs.python.org/issue39530  opened by mark.dickinson

#39531: Memory Leak in multiprocessing.Pool()
https://bugs.python.org/issue39531  opened by EMO

#39532: Pathlib: handling of `.` in paths and patterns creates unmatch
https://bugs.python.org/issue39532  opened by Isaac Muse

#39533: Use `statx(2)` system call on Linux for extended `os.stat` inf
https://bugs.python.org/issue39533  opened by ntninja

#39534: Clarify tutorial on return statement in finally clause.
https://bugs.python.org/issue39534  opened by mdk

#39535: multiprocessing.Process file descriptor resource leak
https://bugs.python.org/issue39535  opened by Robert Pierce

#39537: Change line number table format
https://bugs.python.org/issue39537  opened by Mark.Shannon

#39538: SystemError when set Element.attrib to non-dict
https://bugs.python.org/issue39538  opened by serhiy.storchaka

#39539: Improve Keccak support in hashlib including KangarooTwelve
https://bugs.python.org/issue39539  opened by gvanas

#39540: Logging docs don't address the creation of multiple loggers wh
https://bugs.python.org/issue39540  opened by flipdazed

#39541: distutils: Remove bdist_wininst (Windows .exe installers) in f
https://bugs.python.org/issue39541  opened by vstinner

#39544: Pathlib PureWindowsPath sorting incorrect (is not natural sort
https://bugs.python.org/issue39544  opened by tegavu

#39545: await is not supported in f-string in 3.6
https://bugs.python.org/issue39545  opened by serhiy.storchaka

#39546: argparse: allow_abbrev=False is ignored for alternative prefix
https://bugs.python.org/issue39546  opened by kyleam

#39547: hmac.new() default parameter change not mentioned in changelog
https://bugs.python.org/issue39547  opened by wbond

#39548: Request fails when 'WWW-Authenticate' header for Digest Authen
https://bugs.python.org/issue39548  opened by Stephen Balousek

#39549: The reprlib.Repr type should permit the “fillvalue” to be 
https://bugs.python.org/issue39549  opened by fish2000

#39550: isinstance accepts subtypes of tuples as second argument
https://bugs.python.org/issue39550  opened by ewjoachim

#39551: mock patch should match behavior of import from when module is
https://bugs.python.org/issue39551  opened by dino.viehland

#39557: ThreadPoolExecutor is busy-waiting when idle.
https://bugs.python.org/issue39557  opened by Avraham Mahfuda

#39560: PyUnicode_FromKindAndData kind transformation is not documente
https://bugs.python.org/issue39560  opened by smola

#39562: Asynchronous comprehensions don't work in asyncio REPL
https://bugs.python.org/issue39562  opened by jack1142

#39565: Modules/signalmodule.c creates handlers for signals bounded by
https://bugs.python.org/issue39565  opened by ngie

#39567: Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglo
https://bugs.python.org/issue39567  opened by serhiy.storchaka

#39569: Is the return value of pathlib.Path.glob() sorted?
https://bugs.python.org/issue39569  opened by Björn.Lindqvist

#39570: Python 3.7.3 Crash on msilib actions
https://bugs.python.org/issue39570  opened by UltraLutra

#39572: [typing] TypedDict's 'total' argument is undocumented
https://bugs.python.org/issue39572  opened by brett.cannon

#39573: Make PyObject an opaque structure in the limited C API
https://bugs.python.org/issue39573  opened by vstinner

#39574: str.__doc__ is misleading
https://bugs.python.org/issue39574  opened by kcirtsew

#39575: `coverage` build target should use --coverage instead of -lgco
https://bugs.python.org/issue39575  opened by MaskRay

[Python-Dev] Re: Clarification of unpacking semantics.

[Guido van Rossum]

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 object being called is irrelevant.
>

That's true, but the function name may help the user find the right call in
the code if there are multiple calls on the line.

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

[Python-Dev] ABI breakage in >= 3.7.4 ?

[Julien Danjou]

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, so I guessed it was an ABI change.

After running git bisect for a few hours, it turns out that the culprit
is the following commit:

  
https://github.com/python/cpython/commit/8766cb74e186d3820db0a855ccd780d6d84461f7

>From my understanding, that commit indeed changes the ABI by modifying
the header file and the size of the PyGC_Head and breaks code compiled
on Python >= 3.7.4 running on earlier Python 3.7 version.

I don't know if anything can be done about this now that it's done and
released. It might be something we want to double check in the future.
Having some kind of warning when doing backports could be worth it.

Cheers,
-- 
Julien Danjou
// Free Software Hacker
// https://julien.danjou.info
___
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/J2FGZPS5PS7473TONJTPAVSNXRGV3TFL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification of unpacking semantics.

[Mark Shannon]

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 interleaved. For example, the code `[*a, *b]` used to 
evaluate in the order `a` -> `b` -> `a.__iter__()` -> `b.__iter__()`. 
Now, it evaluates as `a` -> `a.__iter__()` -> `b` -> `b.__iter__()`.


I believe this breaking semantic change is a bug, and I've opened a PR 
to fix it (https://github.com/python/cpython/pull/18264). My reasoning 
is that "unary *" isn't an operator; it doesn't appear on the operator 
precedence table in the docs, and you can't evaluate `*x`. Like the 
brackets and the comma, it's part of the syntax of the outer display 
expression, not the inner one. It specifies how the list should be 
built, so it should be evaluated last, as part of the list 
construction. And it has always been this way since PEP 448 (as far as 
I can tell).


The docs themselves seem to support this line of reasoning 
(https://docs.python.org/3/reference/expressions.html#evaluation-order):


In the following lines, expressions will be evaluated in the 
arithmetic order of their suffixes:

...
expr1(expr2, expr3, *expr4, **expr5)


Note that the stars are not part of expressions 1-5, but are a part of 
the top-level call expression that operates on them all.


Mark Shannon disagrees with me (I'll let him reply rather than attempt 
to summarize his argument for him), but we figured it might be better 
to get more input here on exactly whether you all think the behavior 
should change or not. You can see the discussion on the PR itself for 
some additional points and context.


I have two problems with this change.

1. It changes error messages.

 >>> print(*1)
Traceback (most recent call last):
   File "", line 1, in 
TypeError: print() argument after * must be an iterable, not int
 >>> print(*1, *2)
Traceback (most recent call last):
   File "", line 1, in 
TypeError: Value after * must be an iterable, not int

In 3.8 you got the same error message.

 >>> print(*1)
Traceback (most recent call last):
   File "", line 1, in 
TypeError: print() argument after * must be an iterable, not int
 >>> print(*1, *2)
Traceback (most recent call last):
   File "", line 1, in 
TypeError: print() argument after * must be an iterable, not int

I am not sure whether the function name is a useful information, but 
some effort was spend to preserve it. In any case, error messages should 
be consistent.


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 object being called is irrelevant.


In 3.8:
>>> 1(*1)
  File "", line 1, in 
TypeError: int object argument after * must be an iterable, not int

"int object argument" is nonsense.




2. It introduces performance regression.

In 3.8 the bytecode for `(*a, *b, *c)` was:

   1   0 LOAD_NAME    0 (a)
   2 LOAD_NAME    1 (b)
   4 LOAD_NAME    2 (c)
   6 BUILD_TUPLE_UNPACK   3

In master it is:

   1   0 BUILD_LIST   0
   2 LOAD_NAME    0 (a)
   4 LIST_EXTEND  1
   6 LOAD_NAME    1 (b)
   8 LIST_EXTEND  1
  10 LOAD_NAME    2 (c)
  12 LIST_EXTEND  1
  14 LIST_TO_TUPLE

The bytecode is larger, therefore slower. It also prevents possible 
optimization of BUILD_TUPLE_UNPACK and similar opcodes for common case 
of tuples and lists which would allow to minimize the number of memory 
allocations.


That's just not true. Larger bytecode is not necessarily slower, in fact 
if the operations are more efficient, it can easily be faster.


Please don't waste your efforts "optimizing" rare bytecodes like 
"BUILD_TUPLE_UNPACK". It just makes the interpreter bigger, and has no 
effect on speed because they are rarely executed.


In the compiled standard library, the most common unpacking bytecode 
`LIST_EXTEND` represents less than 1/1000 of the (static) total

(557 out of 669k).


Cheers,
Mark.


___
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/CZZKWFW22TBJ5VLO7GUIF7A7QBFTBAC2/ 


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

[Python-Dev] Re: Clarification of unpacking semantics.

[Serhiy Storchaka]

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_NAME2 (c)
  6 BUILD_TUPLE_UNPACK   3

The code for `print(*a, *b, *c)` is:

  1   0 LOAD_NAME0 (print)
  2 LOAD_NAME1 (a)
  4 LOAD_NAME2 (b)
  6 LOAD_NAME3 (c)
  8 BUILD_TUPLE_UNPACK_WITH_CALL 3
 10 CALL_FUNCTION_EX 0

It is covered by PEP 448 [1].

* BUILD_TUPLE_UNPACK, BUILD_LIST_UNPACK, BUILD_SET_UNPACK and 
BUILD_MAP_UNPACK were used to unpack iterables or mappings in tuple, 
list, set and dict displays.


* BUILD_TUPLE_UNPACK_WITH_CALL and BUILD_MAP_UNPACK_WITH_CALL were used 
when pass multiple var-positional and var-keyword arguments to a function.


All of them except BUILD_TUPLE_UNPACK_WITH_CALL was added in issue2292 
[2]. BUILD_TUPLE_UNPACK_WITH_CALL was added in issue28257 [3] to unify 
error messages.


[1] https://www.python.org/dev/peps/pep-0448/
[2] https://bugs.python.org/issue2292
[3] https://bugs.python.org/issue28257
___
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/45LN7WN4377W2HGHEW3NJL6ORORJSM3A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification of unpacking semantics.

[Paul Moore]

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, as an expression
> with a visible side effect. What the expression [print("a"), *None,
> print("b")] prints before the "cannot unpack NoneType" exception,
> demonstrates what order the expressions were evaluated in.
>
> Paul
___
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/SETEEWYQNUW3FGGRTW6NPOCWRQQVHMRV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification of unpacking semantics.

[Paul Moore]

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 "cannot unpack NoneType" exception,
demonstrates what order the expressions were evaluated in.

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

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

[Serhiy Storchaka]

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 rule Serhiy 
is citing is only intended to apply to builtins, though.


It is an implementation detail. The C implementation does not call 
date.toordinal and date.fromordinal.

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