[issue31904] Python should support VxWorks RTOS

[Peixing Xin]

Change by Peixing Xin :


--
pull_requests: +22676
pull_request: https://github.com/python/cpython/pull/23815

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[STINNER Victor]

STINNER Victor  added the comment:

Oh, test_epoll failed on 3.9. So I backported my change to 3.8 and 3.9, to see 
if it helps or not.

s390x RHEL8 Refleaks 3.9:
https://buildbot.python.org/all/#builders/326/builds/159

Traceback (most recent call last):
  File 
"/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z.refleak/build/Lib/test/test_epoll.py",
 line 199, in test_control_and_wait
self.assertEqual(events, expected)
AssertionError: Lists differ: [(5, 5)] != [(4, 5), (5, 5)]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[miss-islington]

Change by miss-islington :


--
pull_requests: +22675
pull_request: https://github.com/python/cpython/pull/23814

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22674
pull_request: https://github.com/python/cpython/pull/23813

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42651] Recursive traceback crashes Python Interpreter

[Xinmeng Xia]

Change by Xinmeng Xia :


--
title: Title: Recursive traceback crashes  Python Interpreter -> Recursive 
traceback crashes  Python Interpreter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41960] Add globalns and localns to the inspect.signature and inspect.Signature.from_callable

[Guido van Rossum]

Guido van Rossum  added the comment:

It's been a while, I've lost context for this idea. What problem are you trying 
to solve here? Are there issues where people have reported problems that this 
would allow them to solve?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Function returns old value

[dn via Python-list]

On 17/12/2020 16:06, Bischoop wrote:

On 2020-12-17, dn  wrote:


Remember that posts to the list are archived, and thus may be searched.
People experiencing similar problems in-future will be able to 'mine'
the archives for help and advice.

Using a/any pastebin is great for immediate sharing. Remember that in
this case their links expire/the bin 'disappears'.

After expiry, any posts 'here' with links to 'there', will be useless.


I do mind that however I thoght it better if paste a whole code to see
and pasting from my IDE to vim/slrn was messing syntax, I'll do better
next time.



Yes, it can be difficult to know how much code to include and how much 
can be left-out. Don't worry about that - replies can always trim any 
excess.


Also, don't be concerned about such comments. Rather than complaints, 
please regard them as advice from folk who have been 'here' and/or using 
Python for some time.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Review, suggestion etc?

[Bischoop]

On 2020-12-17, Bischoop  wrote:


Accidently removed the paste, https://bpa.st/E3FQ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Function returns old value

[Bischoop]

On 2020-12-17, dn  wrote:

> Remember that posts to the list are archived, and thus may be searched. 
> People experiencing similar problems in-future will be able to 'mine' 
> the archives for help and advice.
>
> Using a/any pastebin is great for immediate sharing. Remember that in 
> this case their links expire/the bin 'disappears'.
>
> After expiry, any posts 'here' with links to 'there', will be useless.

I do mind that however I thoght it better if paste a whole code to see
and pasting from my IDE to vim/slrn was messing syntax, I'll do better
next time.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Function returns old value

[dn via Python-list]

On 17/12/2020 15:40, Bischoop wrote:

On 2020-12-12, Terry Reedy  wrote:


Don't post links to unknown sites.  Reduce it to the minimum needed to
exhibit the questionable behavior and include inline with the question.



BTW bpa.st/+python is well known for code sharing among Python
communities it's alternative to pastebin.com.



Remember that posts to the list are archived, and thus may be searched. 
People experiencing similar problems in-future will be able to 'mine' 
the archives for help and advice.


Using a/any pastebin is great for immediate sharing. Remember that in 
this case their links expire/the bin 'disappears'.


After expiry, any posts 'here' with links to 'there', will be useless.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Function returns old value

[Bischoop]

On 2020-12-12, Terry Reedy  wrote:
>
> Don't post links to unknown sites.  Reduce it to the minimum needed to 
> exhibit the questionable behavior and include inline with the question.
>
>> How this functions should look properly?
>
>

I've solved the problem.
BTW bpa.st/+python is well known for code sharing among Python
communities it's alternative to pastebin.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Review, suggestion etc?

[Bischoop]

I've done my biggest project that allowed me to learn a lot.
It's basically simply Database with basic options >> https://bpa.st/FU4A
.
What sucks here is basically the find_people() I'll have to work on it
yet to make it more useful.
.
If anyone was bored and wished to point me some wrong way or suggest a
better one I'd appreciate.

--
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue17140] Document multiprocessing.pool.ThreadPool

[Matt Wozniski]

Change by Matt Wozniski :


--
keywords: +patch
nosy: +godlygeek
nosy_count: 7.0 -> 8.0
pull_requests: +22673
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23812

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Jason R. Coombs]

Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +22672
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23010

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[Eric V. Smith]

Change by Eric V. Smith :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[Eric V. Smith]

Eric V. Smith  added the comment:

You have the parameters to strptime backward.

>>> datetime.datetime.strptime(datetime.datetime.now().strftime("%c"), "%c")
datetime.datetime(2020, 12, 16, 20, 51, 38)

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

[Jason R. Coombs]

Change by Jason R. Coombs :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41478] Empty representation of AssertionError

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[sds]

New submission from sds :

>>> import datetime, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> datetime.datetime.strptime("%c",datetime.datetime.now().strftime("%c"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data '%c' does not match format 'Wed Dec 16 18:44:27 2020'

--
components: Library (Lib)
messages: 383217
nosy: sam-s
priority: normal
severity: normal
status: open
title: strptime(%c) fails to parse the output of strftime(%c)
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22671
pull_request: https://github.com/python/cpython/pull/23811

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Daniel Hahler  added the comment:

Brett, thanks for the reference.

I've found 
https://discuss.python.org/t/coverage-report-in-github-ci-for-standard-library/2836/11,
 and https://bugs.python.org/issue40993 through it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Change by Daniel Hahler :


--
nosy: +blueyed -blueyed2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Cameron Simpson]

On 16Dec2020 21:59, Chris Green  wrote:
>Cameron Simpson  wrote:
>> On 16Dec2020 18:51, Chris Green  wrote:
>> >The specific problem that finally prevented me from managing to get it
>> >to work was a (Linux) .so file that had been built for Python 2 and,
>> >as I don't have the source, I can't build for Python 3.
>>
>> ChrisA I think suggested keeping a Python 2.7 install around for this.
>>
>Not possible really as there are other python conflicts that start
>appearing if one tries to retain the libraries needed.

Runtime python issues like you missing symbol error, or package conflict 
issues?

i.e. can you keep the OKI stuff sitting around along with Python 2 
install without having trouble with the PPA?

>> >I need to have another go at fixing this as otherwise the code that 
>> >I need to manage my printer will stop working as I update my Ubuntu
>> >systems.

I'm leaning towards ChrisA's JSON suggestion at this point (absent newer 
driver software). Keep a small Python 2 programme around which uses the 
printer driver in whatever _basic_ ways you need, and _invoke that_ from 
your modern Python 3 code as an external command, passing/receiving the 
necessary information in JSON form as input.output, or on its command 
line if that is more convenient.

>> Have you considered keeping a legacy VM around as well? I have a few VMs
>> sitting here I use for some legacy software.
>>
>That's not a lot of use.  The programs that I want to run (by
>converting to Python 3) are utility programs for my printer, they
>install with a handy 'app' in my toolbar.  Having them in a VM
>wouldn't really do much good! :-)

Fair enough. It seemed cumbersome to me too, but it is a viable way to 
keep something legacy around, particularly if that legacy thing requires 
a legacy OS.

>I still have python 2.  The issue is that the programs need modules
>which come from a PPA to support Python GTK, these conflict with
>ongoing updates to Python.  The PPA works OK in Ubuntu 20.04 but
>prevents some updates in 20.10.  I expect it will get worse as time
>goes on.
[...]
>> Guessing from the library name, have you looked on the OKI.com site 
>> for current software? Maybe here? What's your printer model?
>> https://www.oki.com/au/printing/support/drivers-and-utilities/index.html
>>
>>
>It comes from OKI with the Linux utilities for the printer, it's an
>MC342N.

>From here?


https://www.oki.com/uk/printing/support/drivers-and-utilities/colour-multifunction/01331401/?os=ab33=ac2

This driver?


https://www.oki.com/uk/printing/support/drivers-and-utilities/?id=46252701FZ01=drivers-and-utilities=colour-multifunction=01331401=ab33=ac2

I've just installed the .deb above on my Ubuntu 20.04.1 LTS system.  
Aside from whinging about systemd it installed ok. How do I reproduce 
your problems? (I've got no printer of course, but...)

>I have tried asking them for a Python 3 version, maybe I should try
>again.

Can't hurt, but may not be necessary if you are prepared to split your 
Python 3 code form the Python 2 stuff that ships with the .deb.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[CrocoDuck]

CrocoDuck  added the comment:

Hi, I somehow missed the other issue while searching for something 
similar to this, sorry about that.

The main issue is that files pickled with python 3.9.0 cannot be read 
back by using python 3.9.0 if they contain a `uname_result` object.

As for expecting pickle to work across different versions: I did not 
actually think about that. In the original message I mentioned python 
3.8.5 as I noticed this issue did not happen in python 3.8.5, so I 
though it was useful information. To my (hopefully correct) 
understanding if a python version supports the same protocol that was 
used to create the pickle file then it is expected to work. For example 
I have observed that files containing `uname_result` objects pickled 
with python 3.7.6 are still readable with python 3.8.5. As far as I 
understand this is the expected behavior.

On 16/12/2020 22:08, Jason R. Coombs wrote:
> Jason R. Coombs  added the comment:
>
> The PR for the related issue does address pickling. Do you expect pickles to 
> work across Python versions?
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Chris Angelico]

On Thu, Dec 17, 2020 at 9:06 AM Chris Green  wrote:
> > Also, make note of the specific Python 2 version where your software
> > works - the CPython API does change somewhat sometimes.
> >
> I still have python 2.  The issue is that the programs need modules
> which come from a PPA to support Python GTK, these conflict with
> ongoing updates to Python.  The PPA works OK in Ubuntu 20.04 but
> prevents some updates in 20.10.  I expect it will get worse as time
> goes on.
>

Try getting JUST the printer info in Python 2, and then outputting
that to stdout in JSON format. Then your Python 3 script can run your
Python 2 script, read what it sends on stdout, and do whatever it
needs to.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The PR for the related issue does address pickling. Do you expect pickles to 
work across Python versions?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Chris Green]

Cameron Simpson  wrote:
> On 16Dec2020 18:51, Chris Green  wrote:
> >The specific problem that finally prevented me from managing to get it
> >to work was a (Linux) .so file that had been built for Python 2 and,
> >as I don't have the source, I can't build for Python 3.
> 
> ChrisA I think suggested keeping a Python 2.7 install around for this.
> 
Not possible really as there are other python conflicts that start
appearing if one tries to retain the libraries needed.


> >I need to have another go at fixing this as otherwise the code that I
> >need to manage my printer will stop working as I update my Ubuntu
> >systems.
> 
> Have you considered keeping a legacy VM around as well? I have a few VMs 
> sitting here I use for some legacy software.
> 
That's not a lot of use.  The programs that I want to run (by
converting to Python 3) are utility programs for my printer, they
install with a handy 'app' in my toolbar.  Having them in a VM
wouldn't really do much good! :-)


> Have you checked an upgraded Ubuntu to failure to run your software 
> using Python 2? Python 2 won't be installed by default, but I'm pretty 
> sure you can add it in. It is just the "system Python" which is moving 
> to Python 3.
> 
> Also, make note of the specific Python 2 version where your software 
> works - the CPython API does change somewhat sometimes.
> 
I still have python 2.  The issue is that the programs need modules
which come from a PPA to support Python GTK, these conflict with
ongoing updates to Python.  The PPA works OK in Ubuntu 20.04 but
prevents some updates in 20.10.  I expect it will get worse as time
goes on.


> >The specific error I'm getting is as follows:-
> >File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  import 
> > pyscand
> >ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
> > _Py_ZeroStruct
> 
> 
> Guessing from the library name, have you looked on the OKI.com site for 
> current software? Maybe here? What's your printer model?
> 
> https://www.oki.com/au/printing/support/drivers-and-utilities/index.html
> 
> Not that I've found anything helpful...
> 
> What Ubuntu package supplies that .so file?
> 
It comes from OKI with the Linux utilities for the printer, it's an
MC342N.

I have tried asking them for a Python 3 version, maybe I should try
again.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37961] Tracemalloc traces do not include original stack trace length

[miss-islington]

miss-islington  added the comment:


New changeset 78062e07bc7c3b47ffdcdec786b259dda376370c by Miss Islington (bot) 
in branch '3.9':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/78062e07bc7c3b47ffdcdec786b259dda376370c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Brett Cannon]

Brett Cannon  added the comment:

Your question is best directed at https://discuss.python.org/c/core-workflow/8, 
Daniel.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42125] linecache cannot get source for the __main__ module with a custom loader

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

STINNER Victor  added the comment:

Thanks David Hewitt for the bug report, and Zackery Spytz for your fix!

3.9 fix:

commit 166286849048eccadecf02b242dbc4042b780944
Author: Victor Stinner 
Date:   Wed Dec 16 22:41:47 2020 +0100

Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)

Add the following symbols to python3dll.c:

* PyFrame_GetCode (bpo-40421)
* PyFrame_GetLineNumber (bpo-40421)
* PyObject_CallNoArgs (bpo-37194)
* PyThreadState_GetFrame (bpo-39947)
* PyThreadState_GetID (bpo-39947)
* PyThreadState_GetInterpreter (bpo-39947)

(cherry picked from commit fcc6935384b933fbe1a1ef659ed455a3b74c849a)

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39947] [C API] Make the PyThreadState structure opaque (move it to the internal C API)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37194] Move new vector private declarations to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22670
pull_request: https://github.com/python/cpython/pull/23809

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 051b9818671625d125dee8198e0d2af5ad4c85b8 by Daniel Hahler in 
branch 'master':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/051b9818671625d125dee8198e0d2af5ad4c85b8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42663] zoneinfo does not support full range of allowed transition hours in fallback string

[Paul Ganssle]

New submission from Paul Ganssle :

TZif files consist of a list of transitions followed by a POSIX TZ var-style 
string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to 
"AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies 
starting at 02:15:45 local time on the 1st Sunday in November and ending at 
1:30:00 local time on the 2nd Sunday in March". After the last listed 
transition, the rule specified by the TZ variable applies.

POSIX says that the "hours" part of the transition rule must be in the range 
±24, but as mentioned in a TODO comment in _zoneinfo.c, RFC 8536 §3.3.1 
specifies that the hours part of transition times may range from -167 to 167 
(see: 
https://github.com/python/cpython/blob/master/Modules/_zoneinfo.c#L1844-L1847 ).

Currently, zoneinfo does not support the full range of possible transitions, 
and a TZif file with a 3-digit transition hour would likely fail to parse. This 
isn't a terribly high priority at the moment, but if the tz project ever 
releases a TZif file with one of these TZ strings on it, it will all of a 
sudden become very critical to fix it, so we should probably try to get it 
fixed before Python 3.9 is EOL, so that all versions of Python with `zoneinfo` 
can handle this properly.

--
components: Library (Lib)
messages: 383206
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: zoneinfo does not support full range of allowed transition hours in 
fallback string
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Chris Angelico]

On Thu, Dec 17, 2020 at 8:26 AM Cameron Simpson  wrote:
>
> On 16Dec2020 18:51, Chris Green  wrote:
> >The specific problem that finally prevented me from managing to get it
> >to work was a (Linux) .so file that had been built for Python 2 and,
> >as I don't have the source, I can't build for Python 3.
>
> ChrisA I think suggested keeping a Python 2.7 install around for this.

(MRAB did, but I agree with it.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 2 to Python 3 .so library incompatibility - need help

[Cameron Simpson]

On 16Dec2020 18:51, Chris Green  wrote:
>The specific problem that finally prevented me from managing to get it
>to work was a (Linux) .so file that had been built for Python 2 and,
>as I don't have the source, I can't build for Python 3.

ChrisA I think suggested keeping a Python 2.7 install around for this.

>I need to have another go at fixing this as otherwise the code that I
>need to manage my printer will stop working as I update my Ubuntu
>systems.

Have you considered keeping a legacy VM around as well? I have a few VMs 
sitting here I use for some legacy software.

Have you checked an upgraded Ubuntu to failure to run your software 
using Python 2? Python 2 won't be installed by default, but I'm pretty 
sure you can add it in. It is just the "system Python" which is moving 
to Python 3.

Also, make note of the specific Python 2 version where your software 
works - the CPython API does change somewhat sometimes.

>The specific error I'm getting is as follows:-
>File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  import 
> pyscand
>ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
> _Py_ZeroStruct


Guessing from the library name, have you looked on the OKI.com site for 
current software? Maybe here? What's your printer model?

https://www.oki.com/au/printing/support/drivers-and-utilities/index.html

Not that I've found anything helpful...

What Ubuntu package supplies that .so file?

>Is there *any* other way around this, like a 'compatibility module' to
>use Python 2 .so files in Python 3 or anything like it?  I have all
>the Python code and have (up to hitting this problem) converted it to
>Python 3.

Almost certainly not. I think ChrisA's Python 2 suggestion is the go 
here.

You may need to manually copy the requisite .so files if the package is 
about to vanish.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

Paul Bryan  added the comment:

Retracting.

--
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

Change by Paul Bryan :


--
keywords: +patch
pull_requests: +22668
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23808

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

New submission from Paul Bryan :

Currently the data model documentation does not specify the order of keys in 
__annotations__ dictionary. It is currently in the order that arguments or 
attributes are declared. I propose to make this explicit.

Rationale: Having order explicitly specified in the documentation makes it a 
documented feature that code can depend on. Current code cannot safely rely on 
this behavior.

--
assignee: docs@python
components: Documentation
messages: 383204
nosy: docs@python, pbryan
priority: normal
severity: normal
status: open
title: Propose: Data model explict about __annotations__ key ordering.
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Chris Angelico]

On Thu, Dec 17, 2020 at 7:27 AM MRAB  wrote:
>
> On 2020-12-16 19:16, Chris Angelico wrote:
> > On Thu, Dec 17, 2020 at 6:06 AM Chris Green  wrote:
> >>
> >> Some time ago (in July) I asked some questions here
> >> about problems migrating some code from Python 2 to Python 3.
> >>
> >> The specific problem that finally prevented me from managing to get it
> >> to work was a (Linux) .so file that had been built for Python 2 and,
> >> as I don't have the source, I can't build for Python 3.
> >>
> >> I need to have another go at fixing this as otherwise the code that I
> >> need to manage my printer will stop working as I update my Ubuntu
> >> systems.
> >>
> >> The specific error I'm getting is as follows:-
> >>
> >> File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  
> >> import pyscand
> >> ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
> >> _Py_ZeroStruct
> >>
> >> I know this is because the extension module is compiled for Python 2
> >> and _Py_ZeroStruct is only available in Python 2.  I don't have the C
> >> code for the module.
> >>
> >> Is there *any* other way around this, like a 'compatibility module' to
> >> use Python 2 .so files in Python 3 or anything like it?  I have all
> >> the Python code and have (up to hitting this problem) converted it to
> >> Python 3.
> >>
> >
> > Basically no. The error you're seeing is a nice noisy one, but even if
> > you got past that, there'll be a LOT of incompatibilities.
> > Unfortunately, a quick google search for 'pyscand' showed up
> > places where you've asked this question, suggesting that nobody else
> > uses this library. It looks like you're going to have to take a big
> > step back and figure out what the library is doing for you, and
> > reimplement that somehow. :(
> >
> > Good luck.
> >
> Alternatively, run something in Python 2.7 that can import it and talk
> to the main Python 3 code, at least until you have a long-term solution.

Yes, that's a possibility. A hack, but a definite hack. But this is
one of the places where the universality of stdin/stdout is extremely
handy.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 2 to Python 3 .so library incompatibility - need help

[MRAB]

On 2020-12-16 19:16, Chris Angelico wrote:

On Thu, Dec 17, 2020 at 6:06 AM Chris Green  wrote:


Some time ago (in July) I asked some questions here
about problems migrating some code from Python 2 to Python 3.

The specific problem that finally prevented me from managing to get it
to work was a (Linux) .so file that had been built for Python 2 and,
as I don't have the source, I can't build for Python 3.

I need to have another go at fixing this as otherwise the code that I
need to manage my printer will stop working as I update my Ubuntu
systems.

The specific error I'm getting is as follows:-

File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  import 
pyscand
ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
_Py_ZeroStruct

I know this is because the extension module is compiled for Python 2
and _Py_ZeroStruct is only available in Python 2.  I don't have the C
code for the module.

Is there *any* other way around this, like a 'compatibility module' to
use Python 2 .so files in Python 3 or anything like it?  I have all
the Python code and have (up to hitting this problem) converted it to
Python 3.



Basically no. The error you're seeing is a nice noisy one, but even if
you got past that, there'll be a LOT of incompatibilities.
Unfortunately, a quick google search for 'pyscand' showed up
places where you've asked this question, suggesting that nobody else
uses this library. It looks like you're going to have to take a big
step back and figure out what the library is doing for you, and
reimplement that somehow. :(

Good luck.

Alternatively, run something in Python 2.7 that can import it and talk 
to the main Python 3 code, at least until you have a long-term solution.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: bug in download

[Terry Reedy]

On 12/16/2020 12:15 PM, Erick Willum wrote:




Begin forwarded message:


From: Erick Willum 
Date: 16 December 2020 at 15:53:40 GMT
To: python-list@python.org
Subject: bug in download

Hallo and good afternoon,

Having installed python (big thank you) and sublime text, i get the next 
message when trying to download numpy or matplotlib in sublime text:

fails to pass a sanity check due to a bug in the windows runtime. See this 
issue for more information:
https://tinyurl.com/y3dm3h86I


The answer on stackoverflow.com, easily accessed by their local search 
or Google web search: use 1.9.3 on Windows 2004, 1.9.4 on *nix.  1.9.3 
did not work on *nix, and the 1.9.4 hotfix does not work on on some 
Windows.  I have not seen anything either way about the 2009 Windows update


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get(key, default) evaluates default even if key exists

[Grant Edwards]

On 2020-12-16, Dennis Lee Bieber  wrote:
> On Tue, 15 Dec 2020 20:08:53 + (UTC), Mark Polesky via Python-list
> declaimed the following:
>
>>behavior, and I can't remember any programming language in which it's
>>different.
>
> https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_name 

Most of us only run across call-by-name when using macro processors
(cpp, m4, TeX, various assemblers). I vaguely recall some other old
language I ran across in a survey course when in college that used it.
IIRC it was Algol. Somebody else already mentioned Haskel.

--
Grant







-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

> Adding a static assertion about the signedness of uint8_t looks meaningless 
> to me.

My proposal is to add a static assertion that `day` is an unsigned type. In the 
code it would look something like it does in the backports.zoneinfo code 
(https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L1247-L1255):


```
// The actual bounds of day are (day >= 0 && day <= 6), but since day is an
// unsigned variable, day >= 0 is always true. To ensure that a bug is not
// introduced in the event that someone changes day to a signed type, we
// will assert that it is an unsigned type.
Py_ASSERT_VAR_UNSIGNED(day);
if (day > 6) {
PyErr_Format(PyExc_ValueError, "Day must be in [0, 6]");
return -1;
}
```

> I propose to change types of function parameters and local variables. In any 
> case the constructor checks the range of parameters, so there is no problem 
> with packing them into compact structure.

> This will help to avoid errors of implicit conversion between different 
> integer types. Also it can help to avoid code duplication in parsing integers 
> of different size and signedness.

This is not entirely unreasonable in my opinion, though in this case everything 
is determined by the POSIX standard and an RFC, so it is unlikely that we'll 
ever see anything outside of 8 bit integers for these things. If you'd like to 
refactor the parsing code to use signed integers unconditionally and have them 
converted as part of the constructor that seems reasonable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python 2 to Python 3 .so library incompatibility - need help

[Chris Angelico]

On Thu, Dec 17, 2020 at 6:06 AM Chris Green  wrote:
>
> Some time ago (in July) I asked some questions here
> about problems migrating some code from Python 2 to Python 3.
>
> The specific problem that finally prevented me from managing to get it
> to work was a (Linux) .so file that had been built for Python 2 and,
> as I don't have the source, I can't build for Python 3.
>
> I need to have another go at fixing this as otherwise the code that I
> need to manage my printer will stop working as I update my Ubuntu
> systems.
>
> The specific error I'm getting is as follows:-
>
> File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  import 
> pyscand
> ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
> _Py_ZeroStruct
>
> I know this is because the extension module is compiled for Python 2
> and _Py_ZeroStruct is only available in Python 2.  I don't have the C
> code for the module.
>
> Is there *any* other way around this, like a 'compatibility module' to
> use Python 2 .so files in Python 3 or anything like it?  I have all
> the Python code and have (up to hitting this problem) converted it to
> Python 3.
>

Basically no. The error you're seeing is a nice noisy one, but even if
you got past that, there'll be a LOT of incompatibilities.
Unfortunately, a quick google search for 'pyscand' showed up
places where you've asked this question, suggesting that nobody else
uses this library. It looks like you're going to have to take a big
step back and figure out what the library is doing for you, and
reimplement that somehow. :(

Good luck.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose to change types of function parameters and local variables. In any 
case the constructor checks the range of parameters, so there is no problem 
with packing them into compact structure.

This will help to avoid errors of implicit conversion between different integer 
types. Also it can help to avoid code duplication in parsing integers of 
different size and signedness.

Adding a static assertion about the signedness of uint8_t looks meaningless to 
me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Python 2 to Python 3 .so library incompatibility - need help

[Chris Green]

Some time ago (in July) I asked some questions here
about problems migrating some code from Python 2 to Python 3.  

The specific problem that finally prevented me from managing to get it
to work was a (Linux) .so file that had been built for Python 2 and,
as I don't have the source, I can't build for Python 3.

I need to have another go at fixing this as otherwise the code that I
need to manage my printer will stop working as I update my Ubuntu
systems.

The specific error I'm getting is as follows:-

File "/usr/libexec/okimfputl.new/guicom.py", line 66, in  import 
pyscand
ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: 
_Py_ZeroStruct

I know this is because the extension module is compiled for Python 2
and _Py_ZeroStruct is only available in Python 2.  I don't have the C
code for the module. 

Is there *any* other way around this, like a 'compatibility module' to
use Python 2 .so files in Python 3 or anything like it?  I have all
the Python code and have (up to hitting this problem) converted it to
Python 3.


-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42661] Hashlib Bug

[Zachary Ware]

Zachary Ware  added the comment:

`hashlib` is part of the standard library and thus does not need to be (and 
should not be :)) installed via pip.

--
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

There are at least two issues with this:

1. This is a constructor for a struct, and the struct would really 
unnecessarily balloon in size if we switched everything over to be 32-bit 
integers (which I think is your suggestion?). This is not a major concern 
because in typical operation there are not likely to be more than 500 of these 
structs in existence at any one time (due to the cache), but it's still a minor 
annoyance.

I would guess that accepting `int` in the constructor function and converting 
it to uint8_t as part of building the struct would be maybe neutral to 
negative, since it involves casting a large signed type to a small unsigned 
one. This could cause more problems with overflow, not less.

2. In the current implementation `day` is unsigned by its nature — it 
represents a value indexed at 0 for which negative indices have no meaning. If 
we leave `day` as a uint8_t, then that tells the compiler at least something 
about the valid range of the value. By turning `day` (and presumably the other 
elements of this struct) into a less-suitable type, we're depriving ourselves 
of possibly *useful* compiler warnings.

Barring a solution where we have a simple and robust way to suppress warnings, 
I think the next-best solution is to add a static assertion about the 
signedness of the type for this particular case. I'd be happy to write it in a 
relatively general way so that it can be re-used elsewhere in CPython for the 
same purpose.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Fwd: bug in download

[Erick Willum]

Begin forwarded message:

> From: Erick Willum 
> Date: 16 December 2020 at 15:53:40 GMT
> To: python-list@python.org
> Subject: bug in download
> 
> Hallo and good afternoon,
> 
> Having installed python (big thank you) and sublime text, i get the next 
> message when trying to download numpy or matplotlib in sublime text:
> 
> fails to pass a sanity check due to a bug in the windows runtime. See this 
> issue for more information: 
> https://tinyurl.com/y3dm3h86I
> 
> I got the next message from tiny.url, the long url is:
> 
> https://developercommunity.visualstudio.com/content/problem/
> 1207405/fmod-after-an-update-to-windows-2004-is-causing-a.html
> 
> These next lines appear in the sublime window as well:
> 
>   File 
> "C:\Users\Bill\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
>  line 305, in 
> _win_os_check()
>   File 
> "C:\Users\Bill\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py",
>  line 302, in _win_os_check
> raise RuntimeError(msg.format(__file__)) from None
> 
> I would appreciate your help.
> Thanks again.
> Bill.
> 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

miss-islington  added the comment:


New changeset dd262ef46d2e2fff4c413cfa5faa9e72cd36220e by Miss Islington (bot) 
in branch '3.8':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/dd262ef46d2e2fff4c413cfa5faa9e72cd36220e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42661] Hashlib Bug

[Samit Mohnot]

New submission from Samit Mohnot :

Complete output (6 lines):
Traceback (most recent call last):
  File "", line 1, in 
  File 
"C:\Users\Username\AppData\Local\Temp\pip-install-uyjqlzx9\hashlib_973e0ee3f102447498d1d4dca94b7942\setup.py",
 line 68
print "unknown OS, please update setup.py"
  ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print("unknown OS, please update setup.py")?

ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.

--
components: Library (Lib)
messages: 383198
nosy: samit.mohnot.018
priority: normal
severity: normal
status: open
title: Hashlib Bug
type: compile error
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

miss-islington  added the comment:


New changeset bf0eed3e60acc7e4969a4fae940bc615fa924c30 by Miss Islington (bot) 
in branch '3.9':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/bf0eed3e60acc7e4969a4fae940bc615fa924c30


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

[miss-islington]

miss-islington  added the comment:


New changeset 9d409d6b474c188feca6213b9601e06f97715b72 by Miss Islington (bot) 
in branch '3.9':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/9d409d6b474c188feca6213b9601e06f97715b72


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python concurrent.futures.ProcessPoolExecutor

[MRAB]

On 2020-12-16 16:04, Rob Rosengard wrote:

Warning:  I am new to this group
Warning:  I am not an expert at Python, I've written a few small programs, and 
spend 20 hours of online classes, and maybe a book or two.
Warning:  I am new to trying to use concurrent.futures.ProcessPoolExecutor
- Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.  
And confirmed the problem still exists.
- Running on Windows 10 Professional
- I've been trying to run a simple piece of code to exactly match what I have 
seen done in various training videos.  By I am getting a different and
unexpected set of results.  I.e. the instructor got different results than I 
did on my computer.  My code is very simple:

import concurrent.futures
import time


start = time.perf_counter()


def task(myarg):
 print(f'Sleeping one second...{myarg}')
 time.sleep(1)
 return 'Done sleeping...'


if __name__ == '__main__':
 with concurrent.futures.ProcessPoolExecutor() as executor:
 future1 = executor.submit(task, 1)
 future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')

And the output is:
Finished in 0.0 seconds
Finished in 0.0 seconds
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds

Process finished with exit code 0

---
QUESTIONS and CONCERNS that I have...
It seems that both calls to task not only runs that function, but then keeps executing 
the rest of the main line code.  I only expected it to run the function and then 
immediately quit/disappear.   That is, I expect the output to look like (i.e. not having 
the three lines of "Finished in x.x seconds", rather, just one line like that):
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds

Goal:  I need the executor tasks to only run that one function, and then 
completely go away and stop.  Not keep executing more code that doesn't belong 
to the task function.

I've tried many iterations of this issue, and placed PRINT statements all over 
to try to track what is going on.  And I used if/else statements in the main 
code, which caused even more problems.  I.e. both the IF and the ELSE was 
executed each time through the code. Which completely blows my mind.

Any thoughts on this?  Thanks for your time and help!

It imports the module to run the function, so any top-level code _will_ 
be run.


Here's a modified version:

--8<8<--

import concurrent.futures
import time

print('Main code, __name__ is {!a}'.format(__name__))

start = time.perf_counter()


def task(myarg):
print('In task, __name__ is {!a}'.format(__name__))
print(f'Sleeping one second...{myarg}')
time.sleep(1)
return 'Done sleeping...'


if __name__ == '__main__':
with concurrent.futures.ProcessPoolExecutor() as executor:
future1 = executor.submit(task, 1)
future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')

--8<8<--

It prints:

--8<8<--

Main code, __name__ is '__main__'
Main code, __name__ is '__mp_main__'
Finished in 0.0 seconds
Main code, __name__ is '__mp_main__'
Finished in 0.0 seconds
In task, __name__ is '__mp_main__'
Sleeping one second...1
In task, __name__ is '__mp_main__'
Sleeping one second...2
Finished in 1.8 seconds

--8<8<--

Any top-level code that you don't want it to run when it re-imports the 
module should be protected by the __name__ test.

--
https://mail.python.org/mailman/listinfo/python-list

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

[miss-islington]

miss-islington  added the comment:


New changeset d549d0b5575b390431b7b26999151f79f74d4516 by Miss Islington (bot) 
in branch '3.8':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/d549d0b5575b390431b7b26999151f79f74d4516


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +22666
pull_request: https://github.com/python/cpython/pull/23806

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34 by Chris Jerdonek in 
branch 'master':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (#22756)
https://github.com/python/cpython/commit/66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python concurrent.futures.ProcessPoolExecutor

[Dan Stromberg]

On Wed, Dec 16, 2020 at 9:23 AM Israel Brewster 
wrote:

> > On Dec 16, 2020, at 7:04 AM, Rob Rosengard 
> wrote:
> >
> > Warning:  I am new to this group
> > Warning:  I am not an expert at Python, I've written a few small
> programs, and spend 20 hours of online classes, and maybe a book or two.
> > Warning:  I am new to trying to use
> concurrent.futures.ProcessPoolExecutor
> > - Prior to writing this question I updated to Python 3.9 and PyCharm
> 2020.3.  And confirmed the problem still exists.
> > - Running on Windows 10 Professional
> > - I've been trying to run a simple piece of code to exactly match what I
> have seen done in various training videos.  By I am getting a different and
> > unexpected set of results.  I.e. the instructor got different results
> than I did on my computer.  My code is very simple:
> >
> > import concurrent.futures
> > import time
> >
> >
> > start = time.perf_counter()
> >
> >
> > def task(myarg):
> >print(f'Sleeping one second...{myarg}')
> >time.sleep(1)
> >return 'Done sleeping...'
> >
> >
> > if __name__ == '__main__':
> >with concurrent.futures.ProcessPoolExecutor() as executor:
> >future1 = executor.submit(task, 1)
> >future2 = executor.submit(task, 2)
> > finish = time.perf_counter()
> > print(f'Finished in {round(finish-start,2)} seconds')
> >
> > And the output is:
> > Finished in 0.0 seconds
> > Finished in 0.0 seconds
> > Sleeping one second...1
> > Sleeping one second...2
> > Finished in 1.14 seconds
> >
> > Process finished with exit code 0
>


> Assuming the code above is indented exactly as you run it, you have an
> indentation error. That is, the finish and print() are not indented to be
> part of the if __name__… call. As such, they run on import. When you launch
> a new process, it imports the module, which then runs those lines, since
> they are not guarded by the if statement.
>
> Indent those last two lines to be under the if (they don’t need to be
> indented to be under the with, just the if), and it should work as intended.
>

Windows has a problem forking, so the indentation is more persnickety
there. On Linux and I believe on Mac, you don't have to be so careful with
multiprocessing and concurrent.futures.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

Change by miss-islington :


--
pull_requests: +22667
pull_request: https://github.com/python/cpython/pull/23807

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Daniel Hahler  added the comment:

Is it planned to enable coverage uploads for PRs?
This would really help with seeing if code (to be merged) is covered etc.

--
nosy: +blueyed2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose to change the type of day to int. It will remove any objections 
againsy the range check and make the code less error-prone for integer overflow 
and sign loss.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41354] filecmp.cmp documentation does not match actual code

[Scott]

Scott  added the comment:

I suggest changing the documentation rather than the code.  The mix up is in 
the wording.

Documentation below
"If shallow is true, files with identical os.stat() signatures are taken to be 
equal. Otherwise, the contents of the files are compared."

The "Otherwise" appears to be referencing the "If shallow is true" cause, when 
it should be referring to the equality of the _sig()s.

Proposed Change 
"If shallow is true, files with identical os.stat() signatures are taken to be 
equal. If they are not equal, the contents of the files are compared."

--
nosy: +FreeSandwiches

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1571878] Improvements to socket module exceptions

[Irit Katriel]

Irit Katriel  added the comment:

This was indeed done by now - all these exception types now extend OSErrors, 
the hierarchy is very close to the one suggested here (with the exception of 
the AddressError superclass, which I don't think is that useful to have), and 
they have an errno field (derived from OSError).

--
nosy: +iritkatriel
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python concurrent.futures.ProcessPoolExecutor

[Israel Brewster]

> On Dec 16, 2020, at 7:04 AM, Rob Rosengard  wrote:
> 
> Warning:  I am new to this group
> Warning:  I am not an expert at Python, I've written a few small programs, 
> and spend 20 hours of online classes, and maybe a book or two. 
> Warning:  I am new to trying to use concurrent.futures.ProcessPoolExecutor
> - Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.  
> And confirmed the problem still exists. 
> - Running on Windows 10 Professional
> - I've been trying to run a simple piece of code to exactly match what I have 
> seen done in various training videos.  By I am getting a different and 
> unexpected set of results.  I.e. the instructor got different results than I 
> did on my computer.  My code is very simple:
> 
> import concurrent.futures
> import time
> 
> 
> start = time.perf_counter()
> 
> 
> def task(myarg):
>print(f'Sleeping one second...{myarg}')
>time.sleep(1)
>return 'Done sleeping...'
> 
> 
> if __name__ == '__main__':
>with concurrent.futures.ProcessPoolExecutor() as executor:
>future1 = executor.submit(task, 1)
>future2 = executor.submit(task, 2)
> finish = time.perf_counter()
> print(f'Finished in {round(finish-start,2)} seconds')
> 
> And the output is: 
> Finished in 0.0 seconds
> Finished in 0.0 seconds
> Sleeping one second...1
> Sleeping one second...2
> Finished in 1.14 seconds
> 
> Process finished with exit code 0
> 
> --- 
> QUESTIONS and CONCERNS that I have...
> It seems that both calls to task not only runs that function, but then keeps 
> executing the rest of the main line code.  I only expected it to run the 
> function and then immediately quit/disappear.   That is, I expect the output 
> to look like (i.e. not having the three lines of "Finished in x.x seconds", 
> rather, just one line like that):
> Sleeping one second...1
> Sleeping one second...2
> Finished in 1.14 seconds
> 
> Goal:  I need the executor tasks to only run that one function, and then 
> completely go away and stop.  Not keep executing more code that doesn't 
> belong to the task function. 
> 
> I've tried many iterations of this issue, and placed PRINT statements all 
> over to try to track what is going on.  And I used if/else statements in the 
> main code, which caused even more problems.  I.e. both the IF and the ELSE 
> was executed each time through the code. Which completely blows my mind. 
> 
> Any thoughts on this?  Thanks for your time and help!  

Assuming the code above is indented exactly as you run it, you have an 
indentation error. That is, the finish and print() are not indented to be part 
of the if __name__… call. As such, they run on import. When you launch a new 
process, it imports the module, which then runs those lines, since they are not 
guarded by the if statement.

Indent those last two lines to be under the if (they don’t need to be indented 
to be under the with, just the if), and it should work as intended.

---
Israel Brewster
Software Engineer
Alaska Volcano Observatory 
Geophysical Institute - UAF 
2156 Koyukuk Drive 
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145

> 
> R
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42556] unittest.mock.patch() cannot properly mock methods

[Mario Corchero]

Mario Corchero  added the comment:

Right, I believe this is indeed broken.

This code:
```
class A:
def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m", autospec=True):
A.m.side_effect = print
A().m(1)
```

prints: <__main__.A object at 0x7f69cc7dc6a0> 1

Whilst the same code without autospec:
```
class A:
def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m"):
A.m.side_effect = print
A().m(1)
```

prints: 1

This is a rather tricky issue though, as changing the behaviour to pass self 
would break too many people (even if it would probably the be "right" fix).

You can indeed use autospec or just write a descriptor that does the proper 
bound method logic:

```
class A:
def m(self, a=None): pass

def descriptor(self, obj, objtype=None):
self._self = obj
def _(*args):
return self(obj, *args)
return _

from unittest import mock
with mock.patch.object(A, "m"):
A.m.side_effect = print
A.m.__get__ = descriptor
A().m(1)
```

When patching a method at the class level, today Mock is basically hiding 
"self" when used without a spec. We should decide whether:
- that is OK and we want to "fix" autospec to do the same (remove self)
- Leave things as they are, even if not perfect
- Pass self, breaking most assertions across the world (sounds like a bad idea 
initially)
- Create some opt-in parameter or a custom thing like PropertyMock to pass self 
(MethodMock?).

TBH, I don't have a good answer :/. I'm subscribing other more insightful 
people to the issue, maybe this is the way it is intended to work :).

--
nosy: +cjw296, mariocj89, michael.foord, xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: dict.get(key, default) evaluates default even if key exists

[Ethan Furman]

On 12/16/20 3:08 AM, Peter J. Holzer wrote:

On 2020-12-15 13:07:25 -0800, Ethan Furman wrote:

On 12/15/20 9:07 AM, Mark Polesky via Python-list wrote:


D = {'a':1}

def get_default():
  print('Nobody expects this')
  return 0

print(D.get('a', get_default()))


Python has short-circuiting logical operations, so one way to get the behavior 
you're looking for is:

 D.get('a') or get_default()


That will call get_default for any falsey value (0, "", an empty list ...),
not just for missing values.

Which may or may not be what the OP wants.


Good point, thanks for clarifying.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

> Just my two cents, this isn't just "some compilers". Everything from gcc, 
> msvc, C# to the rust compiler complain about this sort of code. As they 
> should, this is effectively dead code.

They complain because most of the time it's a sign that people were intending 
to use a signed integer, and it's an indicator that they may be susceptible to 
integer overflow.

In this case, it was a deliberate choice to include the extra check knowing 
it's dead code, because it is essentially a machine-checked documentation of 
the bounds of that particular variable.


> I think the more pragmatic way to enforce and document this assumption would 
> be to have a unit test that actually checks that the constructor fails with 
> "negative" days. It'll continue to fail right now as its interpretation as an 
> unsigned int will be large and it will start failing if someone changes this 
> to a signed type.

This would be helpful, but it's not an either-or situation. This particular 
thing would be tricky to write a targeted unit test for, because it's a very 
deep implementation detail. Such a unit test would also be quite physically 
separated from the code in question, whereas if we left the code as-is, we'd 
never see this type of bug, and if we added a static assertion we'd be told at 
compile time exactly what is wrong.

The biggest problem here is the fact that we cannot disable compiler warnings 
when complying with them makes the code less readable and/or less robust. This 
makes compiler warnings less useful, since it changes the calculus around 
whether or not it's worth it to introduce a new compiler warning.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: dict.get(key, default) evaluates default even if key exists

[Ethan Furman]

On 12/16/20 1:44 AM, Chris Angelico wrote:

On Wed, Dec 16, 2020 at 8:43 PM Loris Bennett
 wrote:


Paul Bryan  writes:


On Wed, 2020-12-16 at 10:01 +0100, Loris Bennett wrote:


OK, I get the point about when the default value is generated and
that
potentially being surprising, but in the example originally given,
the
key 'a' exists and has a value of '1', so the default value is not
needed.


But the function is still called. The get method just doesn't use (or
return) the value it generates because the key exists. Nevertheless,
you're passing the return value of the get_default function as an
argument.


Thus, I am still unsurprised when dict.get returns the value of an
existing key.


As am I.


What am I missing?


You'll need to tell me at this point.


I was just slow and confused, but you helped me get there in the end.  I
now realise that issue is not about the result of the dict.get(), but
rather about the fact that the method which generates the default value
is called, whether or not it is needed.

I shall remember that next time I think it might be a good idea to
define a computationally massively expensive value as a rarely needed
default :-)



Yep! That's what defaultdict can do - or if you need more flexibility,
subclass dict and add a __missing__ method.


Or, if the computationally massively expensive call uses potentially
different arguments for each invocation:

some_var = d.get('a') or cme(arg1, arg2, ...)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Ammar Askar]

Ammar Askar  added the comment:

> Some compilers complain about checking `day < 0`, because `day` is an 
> unsigned type

Just my two cents, this isn't just "some compilers". Everything from gcc, msvc, 
C# to the rust compiler complain about this sort of code. As they should, this 
is effectively dead code.

I think the more pragmatic way to enforce and document this assumption would be 
to have a unit test that actually checks that the constructor fails with 
"negative" days. It'll continue to fail right now as its interpretation as an 
unsigned int will be large and it will start failing if someone changes this to 
a signed type.

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

As I mentioned, it's a style issue. Yes this did not introduce any 
user-observable bugs, nor should it have changed the machine code emitted by 
the assembly on any competent compiler.

The issue is that I had deliberately chosen to do a "redundant" check to 
improve the readability and to be robust against someone saying, "Why is this a 
unit8_t instead of an int? I don't think it makes anything faster..." or some 
other justification for changing all the uint8_t fields to ints.

Previous to this, we had something where the compiler would fix any bugs caused 
by that by itself by emitting an additional bounds check. In my proposed fix to 
the compiler warnings, there was a static assertion where the machine would 
alert us if the situation changed. The problem is that we now have a 
non-machine-checked comment for something that would be difficult to issue 
tests for.

Frankly, I think that even the worst case scenario here isn't that bad — TZif 
files malformed in a very specific way would be accepted as valid. As it's 
coded now, this would probably just lead to a crash later, or possibly some 
weird results in time zone math. Still, I think we need a solution to this 
problem because our blind adherence to an invalid compiler warning is leading 
us to write more fragile code, whic h is especially problematic in C, which is 
notoriously dangerous and problematic to write.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

Paul created a follow-up issue: bpo-42660.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7492b55ea0ca993c353b6373341b92e40faa9c4d by Miss Islington (bot) 
in branch '3.9':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614) (GH-23804)
https://github.com/python/cpython/commit/7492b55ea0ca993c353b6373341b92e40faa9c4d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See also issue42189.

--
components: +Library (Lib)
nosy: +jaraco, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I do not think there is any problem *now*. The type of day is uint8_t, it 
cannot be negative.

BTW, why is it uint8_t? Would not be easier to use type int by default? I doubt 
that it saves memory or makes the code faster.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Python concurrent.futures.ProcessPoolExecutor

[Rob Rosengard]

Warning:  I am new to this group
Warning:  I am not an expert at Python, I've written a few small programs, and 
spend 20 hours of online classes, and maybe a book or two. 
Warning:  I am new to trying to use concurrent.futures.ProcessPoolExecutor
- Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.  
And confirmed the problem still exists. 
- Running on Windows 10 Professional
- I've been trying to run a simple piece of code to exactly match what I have 
seen done in various training videos.  By I am getting a different and 
unexpected set of results.  I.e. the instructor got different results than I 
did on my computer.  My code is very simple:

import concurrent.futures
import time


start = time.perf_counter()


def task(myarg):
print(f'Sleeping one second...{myarg}')
time.sleep(1)
return 'Done sleeping...'


if __name__ == '__main__':
with concurrent.futures.ProcessPoolExecutor() as executor:
future1 = executor.submit(task, 1)
future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')

And the output is: 
Finished in 0.0 seconds
Finished in 0.0 seconds
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds

Process finished with exit code 0

--- 
QUESTIONS and CONCERNS that I have...
It seems that both calls to task not only runs that function, but then keeps 
executing the rest of the main line code.  I only expected it to run the 
function and then immediately quit/disappear.   That is, I expect the output to 
look like (i.e. not having the three lines of "Finished in x.x seconds", 
rather, just one line like that):
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds

Goal:  I need the executor tasks to only run that one function, and then 
completely go away and stop.  Not keep executing more code that doesn't belong 
to the task function. 

I've tried many iterations of this issue, and placed PRINT statements all over 
to try to track what is going on.  And I used if/else statements in the main 
code, which caused even more problems.  I.e. both the IF and the ELSE was 
executed each time through the code. Which completely blows my mind. 

Any thoughts on this?  Thanks for your time and help!  

R
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue23915] [doc] traceback set with BaseException.with_traceback() pushed back on raise

[Julien Palard]

Change by Julien Palard :


--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23915] [doc] traceback set with BaseException.with_traceback() pushed back on raise

[Julien Palard]

Julien Palard  added the comment:


New changeset c590c2338e5a36cf3ce5b55e6d366a0675ed1db5 by Irit Katriel in 
branch 'master':
bpo-23915: update and elucidate documentation of with_traceback (GH-23680)
https://github.com/python/cpython/commit/c590c2338e5a36cf3ce5b55e6d366a0675ed1db5


--
nosy: +mdk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[daniel hahler]

Change by daniel hahler :


--
nosy: +blueyed
nosy_count: 2.0 -> 3.0
pull_requests: +22665
pull_request: https://github.com/python/cpython/pull/23805

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

New submission from Paul Ganssle :

This is a code style issue — in https://github.com/python/cpython/pull/23614, a 
regression was deliberately introduced to satisfy an overzealous compiler. The 
`day` variable has logical bounds `0 <= day <= 6`. In the original code, both 
sides of this boundary condition were explicitly checked (since this logically 
documents the bounds of the variable).

Some compilers complain about checking `day < 0`, because `day` is an unsigned 
type. It is not an immutable fact that `day` will always be an unsigned type, 
and implicitly relying on this fact makes the code both less readable and more 
fragile. This was changed over my objections and despite the fact that I had a 
less fragile solution available that also satisfied the overzealous compiler.

In the short term, my preferred solution would be to add in a static assertion 
that `day` is an unsigned type — this does not have to work on every platform, 
it simply needs to serve as a notification to make the code less fragile and to 
document our assumptions to both readers and the compiler.

In the long term, I think we need a way to solve the problem that it is 
apparently not possible to disable any compiler warnings even if they don't 
apply to the situation!

--
components: Library (Lib)
messages: 383180
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: _zoneinfo.c incorrectly checks bounds of `day` variable in 
calenderrule_new
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

Fixing these compiler warnings helps PR 18532 "[workflow] Use MSVC problem 
matcher for Windows action build".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

The 3 compiler warnings are now fixed in master, and a 3.9 backport will land 
as soon as the CI tests pass. Thanks everyone who helped to fix these warnings.

I know that the solution is not perfect, but we have to deal with C language 
limitations.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22664
pull_request: https://github.com/python/cpython/pull/23804

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset aefb69b23f056c61e82ad228d950f348de090c70 by Victor Stinner in 
branch 'master':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614)
https://github.com/python/cpython/commit/aefb69b23f056c61e82ad228d950f348de090c70


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Karl Nelson]

Karl Nelson  added the comment:

I am fairly sure this is a Python "bug" in the sense that there was some change 
in undocumented change in requirements and the distutils pattern for building a 
module no longer reflects that requirement.   That said very likely JPype is 
the only module to be affected and thus I will have to manually adjust to 
account for the new requirement.

Unfortunately as far as developers, I am it so fixing it (with your assistance) 
is going to have to fall on me.  So lets do a run down of how this all working 
so you can point me where to look.

1) JPype gets built as an ordinary setup.py CPython module.  So it is possibly 
a bug in the build pattern of the customizers in JPype that was exposed by 
Python 3.9.   I am just going to cut and paste so that it is easy to follow 
along.

jpype/setup.py
```
...
from setuptools import Extension
...
import setupext
...
jpypeLib = Extension(name='_jpype', **setupext.platform.Platform(
include_dirs=[Path('native', 'common', 'include'),
  Path('native', 'python', 'include'),
  Path('native', 'embedded', 'include')],
sources=[Path('native', 'common', '*.cpp'),
 Path('native', 'python', '*.cpp'),
 Path('native', 'embedded', '*.cpp')], platform=platform,
))
```

We have two sets of customization in setup.py.  Both are included from a module 
called jpype/setupext/

The key one is the jpype/setupext/platform.py which defines the compiler flags. 
 There are two sections of interest...

jpype/setupext/platform.py contains these modifications for win32.   
(So there is the Advapi32, not sure why it appears there because this section 
is all before my time as this was started in 2001 and I joined in 2018)
```
static = True
if platform == 'win32':
distutils.log.info("Add windows settings")
platform_specific['libraries'] = ['Advapi32']
platform_specific['define_macros'] = [('WIN32', 1)]
if sys.version > '3':
platform_specific['extra_compile_args'] = [
'/Zi', '/EHsc', '/std:c++14']
else:
platform_specific['extra_compile_args'] = ['/Zi', '/EHsc']
platform_specific['extra_link_args'] = ['/DEBUG']
jni_md_platform = 'win32'
```

The second section is currently commented out.  Though it is relevant because 
JPype is exotic in one way.  It is a module which is loaded in three ways.   
When imported from Python it is an ordinary library (1) which will later pull 
in Java which will then load library a second time (2) to bind Java native 
methods.   It can also be used to launch Python if Java starts the session (3). 
  In that case, it needs libpython.dll to be bound to module so that the Java 
equivalent to LoadLibrary can work.  When it does Java first manually loads 
libpython.dll then loads the module and calls the hook to get Python started. 
```
# This code is used to include python library in the build when starting Python 
from
# within Java.  It will be used in the future, but is not currently required.
#if static and sysconfig.get_config_var('BLDLIBRARY') is not None:
#
platform_specific['extra_link_args'].append(sysconfig.get_config_var('BLDLIBRARY'))
```

The actual buildext has a few minor patches so that Java libraries can run 
through the normal process.  But nothing seems like a good candidate

We have one section tweeking some of the build options.
```
def initialize_options(self, *args):
"""omit -Wstrict-prototypes from CFLAGS since its only valid for C 
code."""
self.android = False
self.makefile = False
self.jar = False
import distutils.sysconfig
cfg_vars = distutils.sysconfig.get_config_vars()
replacement = {
'-Wstrict-prototypes': '',
'-Wimplicit-function-declaration': '',
}
tracing = self.distribution.enable_tracing

# Arguments to remove so we set debugging and optimization level
remove_args = ['-O0', '-O1', '-O2', '-O3', '-g']

for k, v in cfg_vars.items():
if not isinstance(v, str):
continue
if not k == "OPT" and not "FLAGS" in k:
continue

args = v.split()
for r in remove_args:
args = list(filter((r).__ne__, args))

cfg_vars[k] = " ".join(args)
super().initialize_options()
```

Then later we interrupt the build process for Java.
```
def build_extension(self, ext):
if ext.language == "java":
return self.build_java_ext(ext)
if self.jar:
return
print("Call build ext")
return super().build_extension(ext)
```

2) Next we have the module start.  I am guessing this is not the source of the 
error because adding a printf shows we never got to this point.

jpype/native/pyjp_module.cpp
```
PyMODINIT_FUNC PyInit__jpype()
{
JP_PY_TRY("PyInit__jpype");

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

The problem can be simplified to this x.c file:
---
static int invalid_day(unsigned int day)
{
return (day < 0 || day > 6);
}

int main()
{
invalid_day(3);
return 0;
}
---

GCC emits the warning:

$ gcc x.c -o x -O3 -Wall -Wextra
x.c: In function 'invalid_day':
x.c:3:17: warning: comparison of unsigned expression in '< 0' is always false 
[-Wtype-limits]
3 | return (day < 0 || day > 6);
  | ^

There are different options to avoid the warning:


(A) Remove "day < 0" test

Easiest option, portable, simple: my PR 23614.


(B) Disable compiler warnings on the test

Solution currently implemented with pragma + PR 20619 to fix pragmas.


(C) Cast the 'day' variable to a signed type

I understand that Paul wants the code to be as generic as possible, and not 
depending on the "day" parameter type. For example, casting to "int8_t" may 
introduce a risk of integer overflow if day type is larger than 8 bits. Not my 
favorite option.


(D) Make "day < 0" conditional depending if day type is signed or not
(E) Check that day type is unsigned to ensure indirectly that "day >= 0"

Checking if *a type* is signed or not is easy using the C preprocessor:

#define _Py_IS_TYPE_UNSIGNED(type) (((type)-1) > (type)0) 

The problem is that there is no standard function to get a variable type. GCC 
and clang provide the __typeof__(var) extension, C++ provides decltype(var) 
(but CPython code base cannot be built with a C++ compiler if I recall 
correctly).

Paul's PR 20624 introduces Py_ASSERT_VAR_UNSIGNED(var) macro which fails during 
compilation if the variable is unsigned, or does nothing if the compiler 
doesn't provide a way to get a variable type (ex: MSC on Windows).


--


Most answers about "comparison of unsigned expression always false" question on 
the Internet are (A): remove the check which emits the warning.

My worry is also that outside _zoneinfo.c, they are tons of functions which 
rely on the fact that an unsigned type cannot be negativ. I don't want to start 
adding Py_ASSERT_VAR_UNSIGNED(). For me, it's part of the C language and there 
is no need to be explicit about it. If a developer changes a variable type, 
they have to check the type bounds and check of the variable is used.

I would prefer to be consistent and never check for "< 0" if the type is 
unsigned, nor ensure with an assertion that the type is unsigned.

Paul is in disagreement with that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[CrocoDuck]

New submission from CrocoDuck :

See the code example below.

```python
import platform
import pickle

pack = {
'uname_result': platform.uname()
}

with open('test.pickle', 'wb') as f:
pickle.dump(pack, f, protocol=pickle.HIGHEST_PROTOCOL)

with open('test.pickle', 'rb') as f:
data = pickle.load(f)

```

It works smoothly on Python 3.8.5. However, on Python 3.9.0, the last line 
produces this error:

```
Traceback (most recent call last):
  File "/Users/crocoduck/pickle/3.9.0/make_pickle.py", line 12, in 
data = pickle.load(f)
TypeError: () takes 6 positional arguments but 7 were given
```

The files produced by the code snipped above are attached for reference.

This was observed in macOS Catalina 10.15.7.

--
files: pickles.zip
messages: 383174
nosy: CrocoDuck
priority: normal
severity: normal
status: open
title: Objects of uname_result Class Cannot be Successfully Pickled
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49688/pickles.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +22663
pull_request: https://github.com/python/cpython/pull/23803

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

[Om G]

Change by Om G :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42629] PyObject_Call not behaving as documented

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Pingback from #42033. Proper fix for that issue likely involves moving the work 
for copying kwargs into PyObject_Call, which would fix this bug by side-effect.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42033] Seemingly unnecessary complexification of foo(**kw)

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Even if making a copy is necessary when the underlying function receives the 
dict "raw", preemptively performing the copy (before knowing if the function 
being called is a Vectorcall function) means that when it's a Vectorcall 
function (e.g. all user-defined functions, right?), instead of just copying 
from the original dict to the unpacked stack for vectorcall, it makes an 
intermediate copy, then copies from that copy to the unpacked stack later on; 
the copy is otherwise completely unused.

The extra bytecode isn't even defending against "dict-like" kwargs, because 
CALL_FUNCTION_EX itself already copies to a true dict for anything that's not 
an exact dict (that defense shouldn't even be there if the bytecode compiler is 
already guaranteeing a true dict).

Seems like, if preventing the caller's dict from being passed directly to the 
underlying function is necessary and intended, it should be done in 
PyObject_Call (which can avoid the copy entirely when call a Vectorcall 
function and when the reference count on the dict is 1), not at the bytecode 
interpreter layer. As is, PyObject_Call is already violating the documented 
behavior by *not* matching the behavior of callable(*args, **kwargs) (see 
#42629), so moving it to PyObject_Call would fix that problem and improve 
performance passing a single kwargs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42238] Deprecate suspicious.py?

[Julien Palard]

Julien Palard  added the comment:

I created https://github.com/python/cpython/pull/23802 with a port of the 
"wrong backtick detector" (at least, one aspect from it) from suspicious to 
rstlint.

I dropped the suspicious check three weeks ago, and found a single committed 
issue since then, which was fixable (and is fixed) in rstlint, so I'll continue 
this experience and see where it goes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42238] Deprecate suspicious.py?

[Julien Palard]

Change by Julien Palard :


--
pull_requests: +22662
pull_request: https://github.com/python/cpython/pull/23802

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

STINNER Victor  added the comment:

commit fcc6935384b933fbe1a1ef659ed455a3b74c849a
Author: Victor Stinner 
Date:   Wed Dec 16 15:08:23 2020 +0100

Add symbols of the stable ABI to python3dll.c (GH-23598)

Add the following symbols to python3dll.c:

* PyFrame_GetCode (bpo-40421)
* PyFrame_GetLineNumber (bpo-40421)
* PyModule_AddObjectRef (bpo-1635741)
* PyObject_CallNoArgs (bpo-37194)
* PyThreadState_GetFrame (bpo-39947)
* PyThreadState_GetID (bpo-39947)
* PyThreadState_GetInterpreter (bpo-39947)

I backported the change manually to 3.9: PR 23801.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22659
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner
nosy_count: 7.0 -> 8.0
pull_requests: +22658
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39947] [C API] Make the PyThreadState structure opaque (move it to the internal C API)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22661
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com