Re: Puzzling behaviour of Py_IncRef

[Tony Flury via Python-list]

On 26/01/2022 22:41, Barry wrote:



Run python and your code under a debugger and check the ref count of 
the object as you step through the code.


Don’t just step through your code but also step through the C python code.
That will allow you to see how this works at a low level.
Setting a watch point on the ref count will allow you run the code and 
just break as the ref count changes.


That is what I do when a see odd c api behaviour.

Barry



Thanks - I have tried a few times on a few projects to run a debugger in 
mixed language mode and never had any success.


I will have to try again.


As posted in the original message - immediately before the call to 
the C function/method sys.getrefcount reports the count to be 2 
(meaning it is actually a 1).


Inside the C function the ref count is incremented and the Py_REFCNT 
macro reports the count as 3 inside the C function as expected (1 for 
the name in the Python code, 1 for the argument as passed to the C 
function, and 1 for the increment), so outside the function one would 
expect the ref count to now be 2 (since the reference caused by 
calling the function is then reversed).


However - Immediately outside the C function and back in the Python 
code sys.getrefcount reports the count to be 2 again - meaning it is 
now really 1. So that means that the refcount has been decremented 
twice in-between the return of the C function and the execution of 
the immediate next python statement. I understand one of those 
decrements - the parameter's ref count is incremented on the way in 
so the same object is decremented on the way out (so that calls don't 
leak references) but I don't understand where the second decrement is 
coming from.


Again there is nothing in the Python code that would cause that 
decrement - the decrement behavior is in the Python runtime.



--
Anthony Flury
email :anthony.fl...@btinternet.com

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


--
Anthony Flury
email :anthony.fl...@btinternet.com


--
Anthony Flury
email : anthony.fl...@btinternet.com

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

[issue46285] protocol_version in http.server.test can be ignored

[Hugo Almeida]

Hugo Almeida  added the comment:

Hi Éric, thank you so much.

I know only a little usage of closure and functools.partial but not the 
historical/relative knowledge of their design/feature, I mean this issue have 2 
visual, the partical object not working as it expected or we are not calling 
the partical as it expected:

1) partial is not working as its feature or design said, assume I guessed 
right, thus partial object behaviors should be totally equal to its 
wrapper/inside class called with properties applied in a standalone/outside way 
which we usually used, the use of partical at http.server.test should be okey.

"""
import functools

class Obj:
pass

obj = Obj(); obj.foo = bar  # usually used
jbo = functools.partial(Obj, foo=bar)

# if jbo totally equal to obj in anywhere
# (the so called Duck Type or
# maybe the LSP rule, Liskov
# Substitution Principle)
# the use of partical in http.server
# should also be ok
#
# I used the partical times the same
# as http.server's author did
# and I told myself I know its usage
# but now I do not think so
"""

2) solve this issue itself, to pass handler class directly to ignore partial 
object caused problem, this is a coding logic shelter/fixing because the way we 
used functools.partical is not as it expected. This is what cpython@github 
PR30701 already done. (so the use of partical in http.server is not ok, not 
welcome at least, so based what I said above, the feature/design of partical 
now confused me, unless its a bug of partical itself which I am not sure.)

--

___
Python tracker 

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

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If this is not fixed, perhaps it should be documented along with other IDLE 
differences in Running User code.

--

___
Python tracker 

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

[issue45975] Simplify some while-loops with walrus operator

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To me, the five idlelib changes make the code easier to understand.  Nick, 
please either move them into a separate PR or allow me to do so, and subject to 
manual testing, I will merge and backport.  (I requested this on the PR by 
maybe you missed it.)

If there are other plausible changes in idlelib that you would like considered, 
make a spinoff issue where we can discuss them first.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue45162] Remove old deprecated unittest features

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee: gregory.p.smith -> 

___
Python tracker 

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

[issue45162] Remove old deprecated unittest features

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset b50322d20337ca468f2070eedb051a16ee1eba94 by Gregory P. Smith in 
branch 'main':
bpo-45162: Revert "Remove many old deprecated unittest features" (GH-30935)
https://github.com/python/cpython/commit/b50322d20337ca468f2070eedb051a16ee1eba94


--

___
Python tracker 

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

[issue46543] Add sys._getfunc

[Jelle Zijlstra]

Change by Jelle Zijlstra :


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

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 287ceca2d62d11a8b45f6264226d984dd044e082 by Terry Jan Reedy in 
branch '3.9':
bpo-46496: news39 for bpo45296 (#30949)
https://github.com/python/cpython/commit/287ceca2d62d11a8b45f6264226d984dd044e082


--

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset b3cf525bd1c57a1d3f28fcb90bce364f0bcb2b7d by Miss Islington (bot) 
in branch '3.10':
bpo-46496: news11-10 for bpo45296 (GH-30937)
https://github.com/python/cpython/commit/b3cf525bd1c57a1d3f28fcb90bce364f0bcb2b7d


--

___
Python tracker 

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

[issue46282] return value of builtins is not clearly indicated

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Steven, I am also inclined to close this.  What do you think after the 
discussion?  It is sometimes easier to clarify when we have a confused person 
present in the discussion.

--

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue45296] IDLE: Better document close and exit.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 5acaad0b3033fde6f21de6ac73681cd6cf64b1f7 by Miss Islington (bot) 
in branch '3.10':
bpo-45296: Clarify close, quit, and exit in IDLE (GH-30936) (GH-30944)
https://github.com/python/cpython/commit/5acaad0b3033fde6f21de6ac73681cd6cf64b1f7


--

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +29128
pull_request: https://github.com/python/cpython/pull/30949

___
Python tracker 

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

[issue46543] Add sys._getfunc

[Jelle Zijlstra]

New submission from Jelle Zijlstra :

sys._getframe() has to create frame objects, which is relatively expensive. 
Usually the calling function object should be enough.

See https://github.com/faster-cpython/ideas/discussions/238

--
assignee: Jelle Zijlstra
components: Interpreter Core
messages: 411833
nosy: Jelle Zijlstra, Mark.Shannon
priority: normal
severity: normal
status: open
title: Add sys._getfunc
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[miss-islington]

miss-islington  added the comment:


New changeset bc7d96ee332c8a575a453ec81367f2ad499f57d3 by Miss Islington (bot) 
in branch '3.9':
bpo-45296: Clarify close, quit, and exit in IDLE (GH-30936)
https://github.com/python/cpython/commit/bc7d96ee332c8a575a453ec81367f2ad499f57d3


--

___
Python tracker 

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

[issue45476] [C API] PEP 674: Disallow using macros as l-value

[STINNER Victor]

STINNER Victor  added the comment:

> recordclass-0.16.3: lib/recordclass/_dataobject.c + code generated by Cython


I created: 
https://bitbucket.org/intellimath/recordclass/pull-requests/1/python-311-support-use-py_set_size

--

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 9f0881476e0113d3a35e0ffa96649b9276dd75c5 by Terry Jan Reedy in 
branch 'main':
bpo-46496: news11-10 for bpo45296 (GH-30937)
https://github.com/python/cpython/commit/9f0881476e0113d3a35e0ffa96649b9276dd75c5


--

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[miss-islington]

Change by miss-islington :


--
pull_requests: +29126
pull_request: https://github.com/python/cpython/pull/30947

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +29125
pull_request: https://github.com/python/cpython/pull/30946

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[miss-islington]

Change by miss-islington :


--
pull_requests: +29124
pull_request: https://github.com/python/cpython/pull/30945

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset fcde0bc10ddd836b62d0a8e893d80b8c55e0ba3f by Terry Jan Reedy in 
branch 'main':
bpo-45296: Clarify close, quit, and exit in IDLE (GH-30936)
https://github.com/python/cpython/commit/fcde0bc10ddd836b62d0a8e893d80b8c55e0ba3f


--

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +29123
pull_request: https://github.com/python/cpython/pull/30944

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset ced50051bb752a7c1e616f4b0c001f37f0354f32 by Gregory Beauregard in 
branch 'main':
bpo-46539: Pass status of special typeforms to forward references (GH-30926)
https://github.com/python/cpython/commit/ced50051bb752a7c1e616f4b0c001f37f0354f32


--

___
Python tracker 

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

[issue45476] [C API] PEP 674: Disallow using macros as l-value

[STINNER Victor]

STINNER Victor  added the comment:

> * scipy-1.7.3: scipy/_lib/boost/boost/python/object/make_instance.hpp

This is a vendored the Boost.org python module which has already been fixed in 
boost 1.78.0 (commit: January 2021) by:
https://github.com/boostorg/python/commit/500194edb7833d0627ce7a2595fec49d0aae2484

scipy should just update its scipy/_lib/boost copy.

--

___
Python tracker 

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

[issue45476] [C API] PEP 674: Disallow using macros as l-value

[STINNER Victor]

STINNER Victor  added the comment:

> * guppy3-3.1.2: src/sets/bitset.c and src/sets/nodeset.c

I created: https://github.com/zhuyifei1999/guppy3/pull/40

--

___
Python tracker 

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

[issue45735] Promise the long-time truth that `args=list` works

[Tim Peters]

Tim Peters  added the comment:

Charliz, please do! I have no idea why Raymond just stopped. He even deleted 
his initial message here, saying "I relied on this for many years.  So, yet it 
would be nice to guarantee it :-)".

Best I can tell, nothing has changed: lots of people have relied on this 
behavior for years, and the docs should say it's fine.

--

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29122
pull_request: https://github.com/python/cpython/pull/30943

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6b491b9dc0b0fdfd1f07ea4e2151236186d8e7e6 by Victor Stinner in 
branch 'main':
bpo-40170: Remove _Py_GetAllocatedBlocks() function (GH-30940)
https://github.com/python/cpython/commit/6b491b9dc0b0fdfd1f07ea4e2151236186d8e7e6


--

___
Python tracker 

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

[issue45735] Promise the long-time truth that `args=list` works

[Yu Zhao]

Yu Zhao  added the comment:

I'd like to work on this issue recently if it's still needed.

According to suggestions in PR:https://github.com/python/cpython/pull/29437, I 
will:

* Add doc example for Thread function;
* Add some test cases for checking the validity of list args;
* Repeat the above works on multiprocessing module.

--
nosy: +CharlieZhao

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset af32b3ef1fbad3c2242627a14398320960a0cb45 by Victor Stinner in 
branch 'main':
bpo-40170: PyType_SUPPORTS_WEAKREFS() becomes a regular function (GH-30938)
https://github.com/python/cpython/commit/af32b3ef1fbad3c2242627a14398320960a0cb45


--

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29121
pull_request: https://github.com/python/cpython/pull/30942

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +29120
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30941

___
Python tracker 

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

[issue46542] test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot

[STINNER Victor]

STINNER Victor  added the comment:

These 2 tests seem to check for RecursionError. See my notes:
https://pythondev.readthedocs.io/unstable_tests.html#unlimited-recursion

--

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29119
pull_request: https://github.com/python/cpython/pull/30940

___
Python tracker 

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

[issue46498] Add new triplets for loongarch64

[Zhang Na]

Change by Zhang Na :


--
pull_requests: +29118
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30939

___
Python tracker 

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

[issue46542] test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot

[STINNER Victor]

New submission from STINNER Victor :

s390x Fedora Clang 3.x buildbot:
https://buildbot.python.org/all/#/builders/3/builds/1385

This change may be caused by this buildbot configuration change:
https://github.com/python/buildmaster-config/commit/8fbb7492d4509df074750bc1a8ea69812ff53aae

---
0:05:48 load avg: 7.72 [215/432/1] test_lib2to3 crashed (Exit code -11) -- 
running: (...)
Fatal Python error: Segmentation fault

Current thread 0x03ff94176710 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/lib2to3/pytree.py",
 line 845 in generate_matches
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/lib2to3/pytree.py",
 line 785 in _recursive_matches
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/lib2to3/pytree.py",
 line 786 in _recursive_matches
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/lib2to3/pytree.py",
 line 786 in _recursive_matches
  (...)
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/lib2to3/pytree.py",
 line 786 in _recursive_matches
  ...

Extension modules: _testcapi (total: 1)
---

and

---
0:06:29 load avg: 7.50 [245/432/2] test_json crashed (Exit code -11) -- 
running: (...)
Fatal Python error: Segmentation fault

Current thread 0x03ffbccf6710 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/json/encoder.py",
 line 439 in _iterencode
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/json/encoder.py",
 line 325 in _iterencode_list
  (...)
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/json/encoder.py",
 line 439 in _iterencode
  ...

Extension modules: _testcapi (total: 1)
---

test.pythoninfo difference between successful build 1383 and failing build 1385:

* Py_DEBUG: No => Yes
* pymem.allocator: pymalloc => pymalloc_debug
* sysconfig[CFLAGS]: -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 
-Wall
  => sysconfig[CFLAGS]: -Wsign-compare -g -O0 -Wall

--
components: Tests
messages: 411820
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot
versions: Python 3.11

___
Python tracker 

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

Re: mac app from a python script?

[Dan Stromberg]

On Wed, Jan 26, 2022 at 2:35 PM Barry  wrote:

>
>
> On 26 Jan 2022, at 05:17, Dan Stromberg  wrote:
>
>
> On Tue, Jan 25, 2022 at 6:41 PM Dan Stromberg  wrote:
>
>>
>> On Tue, Jan 25, 2022 at 2:23 PM Barry  wrote:
>>
>>>
>>> On 25 Jan 2022, at 02:56, Dan Stromberg  wrote:
>>>
>>> 
>>>
>>> On Sun, Jan 23, 2022 at 1:37 PM Barry  wrote:
>>>

 I do not have experience with great, but you might try pyinstaller.
 I use it to make a PyQt Mac app successfully.

 It’s command line plus setup script.

>>>
>>> I wound up doing:
>>> 1) pyinstaller, as normal, but this created a broken all-encompassing
>>> binary of my script.  At least it gave me the metadata I needed though.
>>>
>>>
>>> You mean it created a .app bundle?
>>>
>>> That is the way that macOS makes it trivia to install apps
>>> Just by drag and drop in /Applications.
>>>
>>
>> Yes, it created an hcm.app for me.  But the executable it created didn't
>> work.  Hence the hack.
>>
>
> $ file /Applications/hcm.app/Contents/MacOS/hcm
> cmd output started 2022 Tue Jan 25 09:00:54 PM PST
> /Applications/hcm.app/Contents/MacOS/hcm: Mach-O 64-bit executable x86_64
>
>
> It’s intended to be started as an app.
>
> What if you double click the app? Does it work?
>
No, it does not start that way either.


> Also you can use the open command to run use the app name you give it.
>
 Thanks for the tip.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29117
pull_request: https://github.com/python/cpython/pull/30938

___
Python tracker 

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

[issue46496] idlelib/NEWS.txt for 3.11.0 and backports

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +29116
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30937

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:

In the top 5000 PyPI projects, the _PyObject_SIZE() and _PyObject_VAR_SIZE() 
functions are used by 7 projects:

* Cython-0.29.26
* frozendict-2.2.0: implement "sizeof" function, found in copies of 
Objects/dictobject.c file
* JPype1-1.3.0
* numpy-1.22.1: gentype_alloc() in numpy/core/src/multiarray/scalartypes.c.src, 
used as type tp_alloc functions
* pickle5-0.0.12
* pyobjc-core-8.2
* recordclass-0.17.1

--

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:

I searched for "_PyObject_DebugMallocStats" in top 5000 PyPI projects. There is 
a single project using it: guppy3.

Extract of guppy3 src/heapy/xmemstats.c:

...
dlptr__PyObject_DebugMallocStats = 
addr_of_symbol("_PyObject_DebugMallocStats");
...
static PyObject *
hp_xmemstats(PyObject *self, PyObject *args)
{
if (dlptr__PyObject_DebugMallocStats) {
fprintf(stderr, 
"==\n");
fprintf(stderr, "Output from _PyObject_DebugMallocStats()\n\n");
dlptr__PyObject_DebugMallocStats(stderr);
}
...
}

addr_of_symbol() is implemented with dlsym() or 
GetModuleHandle(NULL)+GetProcAddress(): it searchs for the symbol in the 
current process.

--

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:

I searched for "_PyGC_FINALIZED" in top 5000 PyPI projects. It seems like only 
Cython is impacted.

ddtrace and guppy3 use directly the internal C API.

== Cython 0.29.26 ==

* Cython/Compiler/ModuleNode.py: finalised_check = '!_PyGC_FINALIZED(o)'
* Cython/Compiler/ModuleNode.py: '(!PyType_IS_GC(Py_TYPE(o)) || 
!_PyGC_FINALIZED(o))')

== ddtrace 0.57.3 ==

In ddtrace/profiling/collector/stack.pyx:

IF PY_MINOR_VERSION >= 9:
# Needed for accessing _PyGC_FINALIZED when we build with 
-DPy_BUILD_CORE
cdef extern from "":
pass

== guppy3-3.1.2 ==

In src/heapy/hv.c:

#if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 9
# define Py_BUILD_CORE
/* PyGC_Head */
#  undef _PyGC_FINALIZED
#  include 
# undef Py_BUILD_CORE
#endif

--

___
Python tracker 

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

[issue45296] IDLE: Better document close and exit.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +29115
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30936

___
Python tracker 

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

[issue40170] [C API] Make PyTypeObject structure an opaque structure in the public C API

[STINNER Victor]

STINNER Victor  added the comment:

TODO:

* Macros still accessing directly PyTypeObject members:

  * PyHeapType_GET_MEMBERS()
  * PySequence_ITEM()
  * _PyObject_SIZE()
  * _PyObject_VAR_SIZE()
  * PyType_SUPPORTS_WEAKREFS()

* Try again to apply "bpo-40170: PyType_HasFeature() now always calls 
PyType_GetFlags() (GH-19378)" which has been reverted?
* Py_TYPE(obj)->tp_name is still commonly used to format error messages: see 
rejected bpo-34595

Other TODO tasks which can be addressed in follow-up issues:

* Add buffer protocol to PyType_FromSpec()
* Stdlib C extensions still define static types: see bpo-40077
* 3rd party C extensions still define static types: PEP 630 and others propose 
heap types

--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset c7af838805ddf52320bce3d5978bfdd37eed1b3a by Pablo Galindo Salgado 
in branch '3.10':
[3.10] bpo-46502: Remove "How do I tell incomplete input" from FAQ (GH-30925) 
(GH-30933)
https://github.com/python/cpython/commit/c7af838805ddf52320bce3d5978bfdd37eed1b3a


--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset dafada393f9a790461430e2493ea1379e938b51a by Pablo Galindo Salgado 
in branch '3.9':
[3.9] bpo-46502: Remove "How do I tell incomplete input" from FAQ (GH-30925) 
(GH-30934)
https://github.com/python/cpython/commit/dafada393f9a790461430e2493ea1379e938b51a


--

___
Python tracker 

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

[issue45162] Remove old deprecated unittest features

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +29114
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30935

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +29113
pull_request: https://github.com/python/cpython/pull/30934

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +29112
pull_request: https://github.com/python/cpython/pull/30933

___
Python tracker 

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

[issue38472] setup.py: GCC detection is broken when cross-compiling with a German locale

[miss-islington]

miss-islington  added the comment:


New changeset ff11effab7ae10b57719c066ee49b52d3991ead3 by Miss Islington (bot) 
in branch '3.9':
bpo-38472: setup.py uses LC_ALL=C to check the C compiler (GH-30929)
https://github.com/python/cpython/commit/ff11effab7ae10b57719c066ee49b52d3991ead3


--

___
Python tracker 

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

[issue38472] setup.py: GCC detection is broken when cross-compiling with a German locale

[miss-islington]

miss-islington  added the comment:


New changeset 171fdf2162130bc8c748173bc8eef184b21f5a08 by Miss Islington (bot) 
in branch '3.10':
bpo-38472: setup.py uses LC_ALL=C to check the C compiler (GH-30929)
https://github.com/python/cpython/commit/171fdf2162130bc8c748173bc8eef184b21f5a08


--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset f0a648152f2d8011f47cc49873438ebaf01d3f82 by Mateusz Łoskot in 
branch 'main':
bpo-46502: Remove "How do I tell incomplete input" from FAQ (GH-30925)
https://github.com/python/cpython/commit/f0a648152f2d8011f47cc49873438ebaf01d3f82


--

___
Python tracker 

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

[issue45162] Remove old deprecated unittest features

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> gregory.p.smith

___
Python tracker 

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

[issue45173] Remove configparser deprecations

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Per 
https://mail.python.org/archives/list/python-...@python.org/thread/GJTREADEXYAETECE5JDTPYWK4WMTKYGR/
 we want to revert 
https://github.com/python/cpython/commit/1fc41ae8709e20d741bd86c2345173688a5e84b0
 for 3.11 to avoid causing pain.

per that thread and 
https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911 it 
sounds like you may be on top of filing upstream issues/PRs to get OSS projects 
to stop using the deprecated APIs.  great!  that should help this stick in 3.12.

as the commit removed several things at once, I suggest a full rollback, and 
smaller PRs for individual things if your upstream python project testing 
reveals things that nobody appears to be depending on.

--
nosy: +gregory.p.smith
priority: normal -> deferred blocker
stage: patch review -> needs patch

___
Python tracker 

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

[issue46282] return value of builtins is not clearly indicated

[Irit Katriel]

Irit Katriel  added the comment:

> "have the :ref:`default return value  of ``None``."


This sounds to me like "by default they return None but you can override this 
default".

I don't think any change to the doc makes sense here. When you state the 
obvious people wonder what they're missing.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue45162] Remove old deprecated unittest features

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Per 
https://mail.python.org/archives/list/python-...@python.org/thread/GJTREADEXYAETECE5JDTPYWK4WMTKYGR/
 we want to revert this change for 3.11 as it causes adoption pain for little 
benefit.

To determine if we should proceed with this in 3.12 or future versions, run a 
stable Python with this change applied on the test suites of external projects 
to find regressions.  (many will have been addressed by then thanks to the work 
by RedHat)

and remember that those are only open source projects. Peoples internal 
codebases are full of use of these names and this will prevent upgrading until 
they take the time to address those.

There are targeted pieces of this change that may make sense to go forward with 
individually.  But it is easier to reason about after a rollback and consider 
new PRs to move those forward.

--
nosy: +gregory.p.smith
priority: normal -> deferred blocker
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
type: enhancement -> behavior

___
Python tracker 

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

[issue38472] setup.py: GCC detection is broken when cross-compiling with a German locale

[STINNER Victor]

Change by STINNER Victor :


--
title: GCC detection in setup.py is broken -> setup.py: GCC detection is broken 
when cross-compiling with a German locale

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

STINNER Victor  added the comment:

The workaround for this bug is to build Python using the command:

LC_ALL=C make

rather than running:

make

--

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[miss-islington]

Change by miss-islington :


--
pull_requests: +29111
pull_request: https://github.com/python/cpython/pull/30932

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +29110
pull_request: https://github.com/python/cpython/pull/30931

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

STINNER Victor  added the comment:


New changeset a9503ac39474a9cb1b1935ddf159c0d9672b04b6 by Victor Stinner in 
branch 'main':
bpo-38472: setup.py uses LC_ALL=C to check the C compiler (GH-30929)
https://github.com/python/cpython/commit/a9503ac39474a9cb1b1935ddf159c0d9672b04b6


--

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

STINNER Victor  added the comment:

FYI distutils.unixccompiler has a private _is_gcc() function:

def _is_gcc(self, compiler_name):
# clang uses same syntax for rpath as gcc
return any(name in compiler_name for name in ("gcc", "g++", "clang"))

It's called with:

compiler = os.path.basename(sysconfig.get_config_var("CC"))

For example, on my Fedora 35, compiler is the string: 'gcc -pthread'. So 
_is_gcc() returns True.

--

___
Python tracker 

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

Re: Pandas or Numpy

[Marco Sulla]

On Mon, 24 Jan 2022 at 05:37, Dennis Lee Bieber  wrote:
> Note that the comparison warns that /indexing/ in pandas can be slow.
> If your manipulation is always "apply operationX to columnY" it should be
> okay -- but "apply operationX to the nth row of columnY", and repeat for
> other rows, is going to be slow.

In my small way, I can confirm. In one of my previous works, we used
numpy and Pandas. Writing the code in Pandas is quick, but they just
realised that was really slow, and they tried to transform as much
Panda code to numpy code as possible.

Furthermore, I saw that they were so accustomed with Pandas that they
used it for all, even for a simple csv creation, when the csv builtin
module is enough.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46506] [Windows] wrap CreateFile to support follow_symlinks

[Eryk Sun]

Eryk Sun  added the comment:

Here's an implementation of _Py_CreateFile2() and win32_xstat_impl():


typedef struct {
DWORD type;
DWORD attributes;
DWORD reparseTag;
} _PY_CREATE_FILE_INFO;


static HANDLE
_Py_CreateFile2(LPCWSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
DWORD dwCreationDisposition,
LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams,
BOOL traverse,
_PY_CREATE_FILE_INFO *pCreateInfo)
{
HANDLE hFile;
DWORD error;
FILE_BASIC_INFO fbi;
FILE_ATTRIBUTE_TAG_INFO fati;
BOOL openReparsePoint = FALSE;
BOOL traverseFailed = FALSE;
_PY_CREATE_FILE_INFO cfi = {0};

CREATEFILE2_EXTENDED_PARAMETERS createExParams = {
sizeof(CREATEFILE2_EXTENDED_PARAMETERS)};
if (!pCreateExParams) {
pCreateExParams = 
}

pCreateExParams->dwFileFlags |= FILE_FLAG_BACKUP_SEMANTICS;

if (pCreateExParams->dwFileFlags & FILE_FLAG_OPEN_REPARSE_POINT) {
openReparsePoint = TRUE;
} else if (!traverse) {
pCreateExParams->dwFileFlags |= FILE_FLAG_OPEN_REPARSE_POINT;
}

// Share read access if write access isn't requested because
// CreateFile2 uses the NT I/O flag FILE_DISALLOW_EXCLUSIVE.
if (!(dwDesiredAccess & (GENERIC_ALL | GENERIC_WRITE |
FILE_WRITE_DATA | FILE_APPEND_DATA))) {
dwShareMode |= FILE_SHARE_READ;
}

call_createfile:
hFile = CreateFile2(lpFileName, dwDesiredAccess, dwShareMode,
dwCreationDisposition, pCreateExParams);
error = GetLastError(); // success: 0 or ERROR_ALREADY_EXISTS
if (hFile == INVALID_HANDLE_VALUE) {
// bpo-37834: open an unhandled reparse point if traverse fails.
traverseFailed = (error == ERROR_CANT_ACCESS_FILE);
if (openReparsePoint || !(traverse && traverseFailed)) {
return INVALID_HANDLE_VALUE;
}
pCreateExParams->dwFileFlags |= FILE_FLAG_OPEN_REPARSE_POINT;
hFile = CreateFile2(lpFileName, dwDesiredAccess, dwShareMode,
dwCreationDisposition, pCreateExParams);
if (hFile == INVALID_HANDLE_VALUE) {
SetLastError(error);
return INVALID_HANDLE_VALUE;
}
error = GetLastError(); // 0 or ERROR_ALREADY_EXISTS
}

if (!pCreateInfo && (openReparsePoint || (traverse && !traverseFailed)))
{
return hFile;
}

cfi.type = GetFileType(hFile);
if (cfi.type == FILE_TYPE_UNKNOWN && GetLastError() != 0) {
error = GetLastError();
goto cleanup;
}

if (GetFileInformationByHandleEx(
hFile, FileAttributeTagInfo, , sizeof(fati))) {
cfi.attributes = fati.FileAttributes;
cfi.reparseTag = fati.ReparseTag;
} else if (GetFileInformationByHandleEx(
hFile, FileBasicInfo, , sizeof(fbi))) {
cfi.attributes = fbi.FileAttributes;
} else {
switch (GetLastError()) {
case ERROR_INVALID_PARAMETER:
case ERROR_INVALID_FUNCTION:
case ERROR_NOT_SUPPORTED:
// The file is not in a filesystem.
break;
default:
error = GetLastError();
}
goto cleanup;
}

if (cfi.attributes & FILE_ATTRIBUTE_REPARSE_POINT) {
if (IsReparseTagNameSurrogate(cfi.reparseTag)) {
if (traverseFailed) {
error = ERROR_CANT_ACCESS_FILE;
goto cleanup;
}
} else if (!openReparsePoint && !traverseFailed) {
// Always try to reparse if it's not a name surrogate.
CloseHandle(hFile);
traverse = TRUE;
pCreateExParams->dwFileFlags &= ~FILE_FLAG_OPEN_REPARSE_POINT;
goto call_createfile;
}
}

cleanup:
if (error && error != ERROR_ALREADY_EXISTS) {
CloseHandle(hFile);
hFile = INVALID_HANDLE_VALUE;
} else if (pCreateInfo) {
*pCreateInfo = cfi;
}
SetLastError(error);
return hFile;
}


static int
win32_xstat_impl(const wchar_t *path, struct _Py_stat_struct *result,
 BOOL traverse)
{
DWORD error;
BY_HANDLE_FILE_INFORMATION fileInfo;
_PY_CREATE_FILE_INFO cfi;
int retval = 0;

HANDLE hFile = _Py_CreateFile2(path, FILE_READ_ATTRIBUTES, 0,
OPEN_EXISTING, NULL, traverse, );

if (hFile == INVALID_HANDLE_VALUE) {
// Either the path doesn't exist, or the caller lacks access.
error = GetLastError();
switch (error) {
case ERROR_INVALID_PARAMETER:
// The "con" DOS device requires read or write access.
hFile = _Py_CreateFile2(path, GENERIC_READ, FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE, OPEN_EXISTING,
NULL, traverse, );
if (hFile == INVALID_HANDLE_VALUE) {
SetLastError(error);

[issue45476] [C API] PEP 674: Disallow using macros as l-value

[STINNER Victor]

STINNER Victor  added the comment:

> pickle5-0.0.12: pickle5/_pickle.c

This project is a backport targeting Python 3.7 and older. I'm not sure if it 
makes sense to update to it to Python 3.11.

It's the same for pysha3 which targets Python <= 3.5.

--

___
Python tracker 

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

[issue45476] [C API] PEP 674: Disallow using macros as l-value

[STINNER Victor]

STINNER Victor  added the comment:

> datatable-1.0.0.tar.gz

I created https://github.com/h2oai/datatable/pull/3231

--

___
Python tracker 

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

Re: Puzzling behaviour of Py_IncRef

[Barry]

> On 25 Jan 2022, at 23:50, Tony Flury  wrote:
> 
> 
> 
> 
>> On 25/01/2022 22:28, Barry wrote:
>> 
 On 25 Jan 2022, at 14:50, Tony Flury via Python-list 
  wrote:
 
 
> On 20/01/2022 23:12, Chris Angelico wrote:
>>> On Fri, 21 Jan 2022 at 10:10, Greg Ewing  
>>> wrote:
>>> On 20/01/22 12:09 am, Chris Angelico wrote:
>>> At this point, the refcount has indeed been increased.
>>> 
   return self;
  }
>>> And then you say "my return value is this object".
>>> 
>>> So you're incrementing the refcount, then returning it without
>>> incrementing the refcount. Your code is actually equivalent to "return
>>> self".
>> Chris, you're not making any sense. This is C code, so there's no
>> way that "return x" can change the reference count of x.
> Yeah, I wasn't clear there. It was equivalent to *the Python code*
> "return self". My apologies.
> 
>  > The normal thing to do is to add a reference to whatever you're
>  > returning. For instance, Py_RETURN_NONE will incref None and then
>  > return it.
>  >
> 
> The OP understands that this is not a normal thing to do. He's
> trying to deliberately leak a reference for the purpose of diagnosing
> a problem.
> 
> It would be interesting to see what the actual refcount is after
> calling this function.
>>> After calling this without a double increment in the function the ref count 
>>> is still only 1 - which means that the 'return self' effectively does a 
>>> double decrement. My original message includes the Python code which calls 
>>> this 'leaky' function and you can see that despite the 'leaky POC' doing an 
>>> increment ref count drops back to one after the return.
>>> 
>>> You are right this is not a normal thing to do, I am trying to understand 
>>> the behaviour so my library does the correct thing in all cases - for 
>>> example - imagine you have two nodes in a tree :
>>> 
>>> A --- > B
>>> 
>>> And your Python code has a named reference to A, and B also maintains a 
>>> reference to A as it's parent.
>>> 
>>> In this case I would expect A to have a reference count of 2 (counted as 3 
>>> through sys.getrefcount() - one for the named reference in the Python code 
>>> - and one for the link from B back to A; I would also expect B to have a 
>>> reference count here of 1 (just the reference from A - assuming nothing 
>>> else referenced B).
>>> 
>>> My original code was incrementing the ref counts of A and B and then 
>>> returning A. within the Python test code A had a refcount of 1 (and not the 
>>> expected 2), but the refcount from B was correct as far as I could tell.
>>> 
>>> 
 Yes, and that's why I was saying it would need a *second* incref.
 
 ChrisA
>>> Thank you to all of you for trying to help - I accept that the only way to 
>>> make the code work is to do a 2nd increment.
>>> 
>>> I don't understand why doing a 'return self' would result in a double 
>>> decrement - that seems utterly bizzare behaviour - it obviously works, but 
>>> why.
>> The return self in C will not change the ref count.
>> 
>> I would suggest setting a break point in your code and stepping out of the 
>> function and seeing that python’s code does to the ref count.
>> 
>> Barry
> Barry,
> 
> something odd is going on because the Python code isn't doing anything that 
> would cause the reference count to go from 3 inside the C function to 1 once 
> the method call is complete.
> 
> As far as I know the only things that impact the reference counts are : 
> 
> Increments due to assigning a new name or adding it to a container.
> Increment due to passing the object to a function (since that binds a new 
> name) 
> Decrements due to deletion of a name
> Decrement due to going out of scope
> Decrement due to being removed from a container.
> None of those things are happening in the python code.
> 

Run python and your code under a debugger and check the ref count of the object 
as you step through the code.

Don’t just step through your code but also step through the C python code.
That will allow you to see how this works at a low level. 
Setting a watch point on the ref count will allow you run the code and just 
break as the ref count changes.

That is what I do when a see odd c api behaviour.

Barry
> As posted in the original message - immediately before the call to the C 
> function/method sys.getrefcount reports the count to be 2 (meaning it is 
> actually a 1).
> 
> Inside the C function the ref count is incremented and the Py_REFCNT macro 
> reports the count as 3 inside the C function as expected (1 for the name in 
> the Python code, 1 for the argument as passed to the C function, and 1 for 
> the increment), so outside the function one would expect the ref count to now 
> be 2 (since the reference caused by calling the function is then reversed).
> 
> However - Immediately outside the C function and 

Re: mac app from a python script?

[Barry]

> On 26 Jan 2022, at 05:17, Dan Stromberg  wrote:
> 
> 
> 
>> On Tue, Jan 25, 2022 at 6:41 PM Dan Stromberg  wrote:
>> 
>>> On Tue, Jan 25, 2022 at 2:23 PM Barry  wrote:
>>> 
> On 25 Jan 2022, at 02:56, Dan Stromberg  wrote:
> 
 
 
> On Sun, Jan 23, 2022 at 1:37 PM Barry  wrote:
> 
> I do not have experience with great, but you might try pyinstaller.
> I use it to make a PyQt Mac app successfully.
> 
> It’s command line plus setup script.
 
 I wound up doing:
 1) pyinstaller, as normal, but this created a broken all-encompassing 
 binary of my script.  At least it gave me the metadata I needed though.
>>> 
>>> You mean it created a .app bundle?
>>> 
>>> That is the way that macOS makes it trivia to install apps
>>> Just by drag and drop in /Applications.
>> 
>> Yes, it created an hcm.app for me.  But the executable it created didn't 
>> work.  Hence the hack.
> 
> More specifically:
> $ /Applications/hcm.app/Contents/MacOS/hcm --gui
> cmd output started 2022 Tue Jan 25 09:00:33 PM PST
> Traceback (most recent call last):
>   File "/Applications/hcm.app/Contents/Resources/__boot__.py", line 146, in 
> 
> _run()
>   File "/Applications/hcm.app/Contents/Resources/__boot__.py", line 129, in 
> _run
> exec(compile(source, path, "exec"), globals(), globals())
>   File "/Applications/hcm.app/Contents/Resources/hcm.py", line 1950, in 
> 
> import gi
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 664, in _load_unlocked
>   File "", line 627, in _load_backward_compatible
>   File "", line 259, in load_module
>   File "gi/__init__.pyc", line 40, in 
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 664, in _load_unlocked
>   File "", line 627, in _load_backward_compatible
>   File "", line 259, in load_module
>   File "gi/_gi.pyc", line 14, in 
>   File "gi/_gi.pyc", line 10, in __load
>   File "imp.pyc", line 342, in load_dynamic
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 664, in _load_unlocked
>   File "", line 627, in _load_backward_compatible
>   File "/Applications/hcm.app/Contents/Resources/__boot__.py", line 36, in 
> load_module
> return imp.load_module(
>   File "imp.pyc", line 244, in load_module
>   File "imp.pyc", line 216, in load_package
>   File "", line 710, in _load
> AttributeError: 'NoneType' object has no attribute 'name'
> 2022-01-25 21:00:34.576 hcm[62695:1322031] hcm Error
> ^C^\Quit: 3
> above cmd output done2022 Tue Jan 25 09:00:42 PM PST
> dstromberg@Daniels-Mini:~/src/home-svn/hcm/trunk x86_64-apple-darwin20.6.0 
> 61933
> 
> $ file /Applications/hcm.app/Contents/MacOS/hcm
> cmd output started 2022 Tue Jan 25 09:00:54 PM PST
> /Applications/hcm.app/Contents/MacOS/hcm: Mach-O 64-bit executable x86_64

It’s intended to be started as an app.

What if you double click the app? Does it work?
Also you can use the open command to run use the app name you give it.

> 
> But if I replace /Applications/hcm.app/Contents/MacOS/hcm with a symlink to a 
> wrapper shell script, hcm runs fine from the Applications menu.
> 
> It seems that gi.repository.Gtk applications are not packaged correctly by 
> pyinstaller and py2app.  Some Python modules require a little assistance to 
> be packaged up into a Mach-O executable neatly by such tools.  But it's just 
> not that important to me to have a Mach-O of my app.

Understood, was just curious.

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

[issue40280] Consider supporting emscripten/webassembly as a build target

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +29109
pull_request: https://github.com/python/cpython/pull/30930

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

STINNER Victor  added the comment:

Ok, I reproduced the issue. I wrote PR 30929 to fix it.

The issue only occurs when cross-compiling Python with GCC and a German locale. 
I can reproduce the issue on Fedora 35:

$ LC_ALL=de_DE gcc -E -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Ziel: x86_64-redhat-linux
Konfiguriert mit: ../configure --enable-bootstrap 
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
--enable-initfini-array 
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20211203/obj-x86_64-redhat-linux/isl-install
 --enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-gnu-indirect-function --enable-cet --with-tune=generic 
--with-arch_32=i686 --build=x86_64-redhat-linux 
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread-Modell: posix
Unterst�tzte LTO-Kompressionsalgorithmen: zlib zstd
gcc-Version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC) 

The last line starts with "gcc-Version 11.2.1". Whereas the last line starts 
with "gcc version 11.2.1" with the C locale:

$ LC_ALL=C gcc -E -v
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
--enable-initfini-array 
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20211203/obj-x86_64-redhat-linux/isl-install
 --enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-gnu-indirect-function --enable-cet --with-tune=generic 
--with-arch_32=i686 --build=x86_64-redhat-linux 
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC)

--

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Eric Snow  added the comment:

## Background ##

`_Py_Identifier` (and `_Py_IDENTIFIER()`, etc.) was added in 2011 [1][2] for 
several reasons:

* provide a consistent approach for a common optimization: caching C-string 
based string objects
* facilitate freeing those objects during runtime finalization

The solution involved using a static variable defined, using `_Py_IDENTIFIER()` 
near the code that needed the string.  The variable (a `_Py_Identifier`) would 
hold the desired C string (statically initialized) and the corresponding 
(lazily created) `PyUnicodeObject`.  The code where the `_Py_Identifier` was 
defined would then pass it to specialized versions of various C-API that would 
normally consume a C string or `PyUnicodeObject`.  Then that code would use 
either the C-string or the object (creating and caching it first if not done 
already).  This approach decentralized the caching but also provided a single 
tracking mechanism that made it easier to clean up the objects.

Over the last decade a number of changes were made, including recent changes to 
make the identifiers per-interpreter and to use a centralized cache.


[1] 
https://github.com/python/cpython/commit/afe55bba33a20f87a58f940186359237064b428f
[2] 
https://mail.python.org/archives/list/python-...@python.org/message/FRUTTE47JO2XN3LXV2J4VB5A5VILILLA/

--

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

New submission from Eric Snow :

`_Py_Identifier` has been useful but at this point there is a faster and 
simpler approach we could take as a replacement: statically initialize the 
objects as fields on `_PyRuntimeState` and reference them directly through a 
macro.

This would involve the following:

* add a `PyUnicodeObject field (not a pointer) to `_PyRuntimeState` for each 
string that currently uses `_Py_IDENTIFIER()`
* initialize each object as part of the static initializer for `_PyRuntimeState`
* make each "immortal" (e.g. start with a really high refcount)
* add a macro to look up a given string
* update each location that currently uses `_Py_IDENTIFIER()` to use the new 
macro instead

As part of this, we would also do the following:

* get rid of all C-API functions with `_Py_Identifer` parameters
* get rid of the old runtime state related to identifiers
* get rid of `_Py_Identifier`, `_Py_IDENTIFIER()`, etc.

(Note that there are several hundred uses of `_Py_IDENTIFIER()`, including a 
number of duplicates.)


Pros:

* reduces indirection (and extra calls) for C-API using the strings (making the 
code easier to understand and speeding it up)
* the objects are referenced from a fixed address in the static data section 
(speeding things up and allowing the C compiler to optimize better)
* there is no lazy allocation (or lookup, etc.) so there are fewer possible 
failures when the objects get used (thus less error return checking)
* simplifies the runtime state
* saves memory (at little, at least)
* the approach for per-interpreter is simpler (if needed)
* reduces the number of static variables in any given C module
* reduces the number of functions in the ("private") C-API
* "deep frozen" modules can use these strings
* other commonly-used strings could be pre-allocated by adding 
`_PyRuntimeState` fields for them

Cons:

* churn
* adding a string to the list requires modifying a separate file from the one 
where you actually want to use the string
* strings can get "orphaned" (we could prevent this with a check in `make 
check`)
* some PyPI packages may rely on `_Py_IDENTIFIER()` (even though it is 
"private" C-API)
* some strings may never get used for any given ./python invocation


Note that with a basic partial implementation (GH-30928) I'm seeing a 1% 
improvement in performance (see 
https://github.com/faster-cpython/ideas/issues/230).

--
assignee: eric.snow
components: Interpreter Core
messages: 411799
nosy: eric.snow, serhiy.storchaka, vstinner
priority: normal
pull_requests: 29107
severity: normal
stage: needs patch
status: open
title: Replace _Py_IDENTIFIER() with statically initialized objects.
versions: Python 3.11

___
Python tracker 

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

[issue46506] [Windows] wrap CreateFile to support follow_symlinks

[Eryk Sun]

Eryk Sun  added the comment:

> switch to the newer CreateFile2() function

Apparently we need to allow FILE_SHARE_READ if CreateFile2() is used to 
implement os.stat(). It's not a big deal, but this is a design flaw.

CreateFile2() always uses the kernel I/O flag FILE_DISALLOW_EXCLUSIVE [1] when 
it calls NtCreateFile(). The intent of this flag is to avoid exclusive read 
access on the first open of a file when a user lacks write permission. Thus 
unprivileged users aren't allowed to prevent read access to critical system 
files. 

However, the implementation is flawed because it denies access even if the open 
doesn't request data access. It's also flawed because it allows exclusive read 
access when there are previous opens even if the previous opens have no data 
access.

Classically, IoCheckShareAccess() only checks for a sharing violation when an 
open requests read, write, or delete data access (i.e. FILE_READ_DATA, 
FILE_EXECUTE, FILE_WRITE_DATA, FILE_APPEND_DATA, DELETE). This is clearly 
explained in [MS-FSA] [2]. An open that only requests metadata access can never 
cause a sharing violation and poses no problem with regard to blocking access 
to a file.

---
[1] 
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-iocreatefileex
[2] 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/8c0e3f4f-0729-49f4-a14d-7f7add593819

--

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Guido van Rossum]

Guido van Rossum  added the comment:

Agree it's not the same issue, but there's similarity -- both are due to 
putting a stringized annotation (presumably a forward ref) somewhere inside 
another construct. whether it's list["N"] or Annotated["ClassVar[int]"].

--

___
Python tracker 

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

[issue38487] expat infinite loop

[sping]

sping  added the comment:

Hi StyXman,

I had a closer look at the files you shared, thanks for those, very helpful!

What I found is that expat_test.py uses a single scalar variable
(_DictSAXHandler.parser) to keep track of the related parser, while it would
need a stack to allow recursion.  In a way, the current approach is equivalent
to walking up the stack as expected but never going back down.
Once I make the code use a stack, the loop goes away.  I'm pasting the patch
inline (with two spaces indented globally) below.

During debugging, these are commands I used to compare internal libexpat 
behavior,
that may be of interest:

  EXPAT_ACCOUNTING_DEBUG=2 python expat_test.py |& sed 's,0x[0-9a-f]\+,XXX,' | 
tee pyexpat.txt

  EXPAT_ACCOUNTING_DEBUG=2 xmlwf -x test1.xml |& sed 's,0x[0-9a-f]\+,XXX,' | 
tee xmlwf.txt

  diff -u xmlwf.txt pyexpat.txt

Here's how I quick-fixed expat_test.py to make things work:

  # diff -u expat_test.py_ORIG expat_test.py
  --- expat_test.py_ORIG  2022-01-26 21:15:27.506458671 +0100
  +++ expat_test.py   2022-01-26 22:15:08.741384932 +0100
  @@ -7,11 +7,21 @@
   
   parser.ExternalEntityRefHandler = handler.externalEntityRef
   
  -# store the parser in the handler so we can recurse
  -handler.parser = parser
  -
   
   class _DictSAXHandler(object):
  +def __init__(self):
  +self._parsers = []
  +
  +def push_parser(self, parser):
  +self._parsers.append(parser)
  +
  +def pop_parser(self):
  +self._parsers.pop()
  +
  +@property
  +def parser(self):
  +return self._parsers[-1]
  +
   def externalEntityRef(self, context, base, sysId, pubId):
   print(context, base, sysId, pubId)
   external_parser = self.parser.ExternalEntityParserCreate(context)
  @@ -19,7 +29,9 @@
   setup_parser(external_parser, self)
   f = open(sysId, 'rb')
   print(f)
  +self.push_parser(external_parser)
   external_parser.ParseFile(f)
  +self.pop_parser()
   print(f)
   
   # all OK
  @@ -36,12 +48,13 @@
   namespace_separator
   )
   setup_parser(parser, handler)
  +handler.push_parser(parser)
   
   if hasattr(xml_input, 'read'):
   parser.ParseFile(xml_input)
   else:
   parser.Parse(xml_input, True)
  -return handler.item
  +# return handler.item  # there is no .item
   
   
   parse(open('test1.xml', 'rb'))
   
What do you tink?

PS: Please note that processing external entities has security implications
(see https://en.wikipedia.org/wiki/XML_external_entity_attack).

Best, Sebastian

--
nosy: +sping

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Gregory Beauregard]

Gregory Beauregard  added the comment:

I did try the proposed patch in bpo-41370 and verified it didn't resolve the 
issue so I'm not certain they strictly overlap, but I also haven't had time to 
fully digest the underlying issues in bpo-41370 yet.

I think it does have relevance for changes we want to make for dataclasses re: 
Annotated, though: https://bugs.python.org/issue46511

--

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Guido van Rossum]

Guido van Rossum  added the comment:

I wonder if this is at all similar to bpo-41370.

--

___
Python tracker 

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

[issue45173] Remove configparser deprecations

[Hugo van Kemenade]

Change by Hugo van Kemenade :


--
pull_requests: +29106
pull_request: https://github.com/python/cpython/pull/30927

___
Python tracker 

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

[issue46540] dylibs not loading properly from NFS mounts

[embassy_vfx]

New submission from embassy_vfx :

MacOS Catalina 10.15.4 and 10.15.7
tested with XCode Python3.8 install and Python3.7.9 installer from 
https://www.python.org/ftp/python/3.7.9/python-3.7.9-macosx10.9.pkg (and my own 
build of 3.7.12)

When importing libraries that use shared object files to an NFS mounted 
directory, they do not open the dynamic library properly. We can use PySide2 as 
an example here. This workflow works fine in python 2.7 using the same steps.

Repro Steps:
1)pip install PySide2 to an NFS mounted directory: `/usr/local/bin/python3.7 -m 
pip install --target=//nfs_3.7 PySide2`
2)`export PYTHONPATH=//nfs_3.7`
3)run python `/usr/local/bin/python3.7`
4)import PySide2 - you should get an ImportError that looks like 
"dlopen(//nfs_3.7/shiboken2/shiboken2.abi3.so, 2): Library not 
loaded: @rpath/libshiboken2.abi3.5.15.dylib" - otool shows shiboken2.abi3.so 
has it's rpath set as @loader_path and I've confirmed both files exist.

If I follow the same procedure above but instead install PySide2 to 
`/tmp/local_3.7` everything works as expected and the binaries are loaded 
properly.

I had this same issue with standard library .so files when I installed my 
custom build of python to an NFS mounted directory (_ssl as an example) but 
only when running through a virtual environment. Possibly @rath/@loader_path 
related? This seems to only be an issue on MacOS as I have no issues on the 
same NFS mount on Linux.

--
components: macOS
messages: 411793
nosy: embassy_vfx, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: dylibs not loading properly from NFS mounts
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Gregory Beauregard]

Gregory Beauregard  added the comment:

typo: the line is `g: Annotated["ClassVar[int]", (2, 5)] = 3` in the code 
sample. Somehow I left it at only `(` for the annotation instead of `(2,5)`

--

___
Python tracker 

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

[issue46528] Simplify the VM's stack manipulations

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset 85483668647e7840c7b9a1877caaf2ef14a4443f by Brandt Bucher in 
branch 'main':
bpo-46528: Simplify the VM's stack manipulations (GH-30902)
https://github.com/python/cpython/commit/85483668647e7840c7b9a1877caaf2ef14a4443f


--

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Gregory Beauregard]

Change by Gregory Beauregard :


--
type:  -> behavior

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +AlexWaygood, sobolevn

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Gregory Beauregard]

Change by Gregory Beauregard :


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

___
Python tracker 

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

[issue46539] typing: forward references don't understand special type forms

[Gregory Beauregard]

New submission from Gregory Beauregard :

Consider the following code on 3.11 main:

```
from typing import Annotated, ClassVar, get_type_hints

class DC:
a: ClassVar[int] = 3
b: ClassVar["int"] = 3
c: "ClassVar[int]" = 3
d: Annotated[ClassVar[int], (2, 5)] = 3
e: Annotated[ClassVar["int"], (2, 5)] = 3
f: "Annotated[ClassVar[int], (2, 5)]" = 3

class DC_Special_ForwardRef:
g: Annotated["ClassVar[int]", (] = 3

# OK
assert get_type_hints(DC, globals(), locals()) == {
"a": ClassVar[int],
"b": ClassVar[int],
"c": ClassVar[int],
"d": ClassVar[int],
"e": ClassVar[int],
"f": ClassVar[int],
}

# TypeError: typing.ClassVar[int] is not valid as type argument
get_type_hints(DC_Special_ForwardRef, globals(), locals())
```

Currently, the `Annotated["ClassVar[int]", (2, 5)]` annotation raises at 
runtime when `get_type_hints` is called, but all the other forward reference 
annotations are okay.

My understanding is this is because when typing._type_check runs on a type 
where special forms are allowed it's possible for the typing._type_convert it 
calls it itself run a typing._type_check on contained forward references. 
However, if that forward reference was itself a special form then it's possible 
to get an error because typing._type_check doesn't pass on that special forms 
are allowed.

I have drafted a patch to pass on this information. This will become important 
in the future as more special forms are allowed to wrap each other, such as 
allowing Final and ClassVar to nest each other in dataclasses, or when Required 
and NotRequired land. In the future we may also want to reconsider runtime 
restrictions on special forms in `typing.py` entirely and instead choose to 
leave this to type checkers.

Is my analysis/patch approach okay? Forward references can be tricky. Should we 
be discussing runtime restrictions in typing.py more generally in the future?

--
components: Library (Lib)
messages: 411790
nosy: GBeauregard, Jelle Zijlstra, gvanrossum, kj
priority: normal
severity: normal
status: open
title: typing: forward references don't understand special type forms
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue42982] Update suggested number of iterations for pbkdf2_hmac()

[Zachary Ware]

Zachary Ware  added the comment:

Rather than suggesting an actual number, perhaps we should link to an external 
resources that covers how to choose the number?

Or we leave it vague and say "The number of iterations should be chosen based 
on the hash algorithm and computing power; there is no universal 
recommendation, but hundreds of thousands of iterations may be reasonable."  
This avoids bikeshedding a specific number, but still gives a general idea of 
the magnitude of number involved.

--
nosy: +zach.ware

___
Python tracker 

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

[issue46487] `_SSLProtocolTransport` doesn't have the `get_write_buffer_limits` implementation.

[Nova]

Nova  added the comment:

Hey Andrew, thanks for the reply! 

> Would you prepare a pull request?

Sure.

> ... and documenting the change.

Apparently `WriteTransport.get_write_buffer_limits` is already documented 
(https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.get_write_buffer_limits)
 

so please can you clarify on what did you mean by that? 

I am sorry this is my first time here.

--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Mateusz Loskot]

Mateusz Loskot  added the comment:

Not quite the answer I'd like to received, but thank you very much for the 
explanation.

I've submitted pull request removing the deprecated FAQ entry
https://github.com/python/cpython/pull/30925

--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +29104
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30925

___
Python tracker 

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

[issue42926] Split compiler into code-gen, optimizer and assembler.

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +iritkatriel

___
Python tracker 

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

[issue42926] Split compiler into code-gen, optimizer and assembler.

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue33205] GROWTH_RATE prevents dict shrinking

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue46534] Implementing PEP 673 (Self type)

[Gobot1234]

Change by Gobot1234 :


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

___
Python tracker 

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

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[STINNER Victor]

STINNER Victor  added the comment:

Can we close this issue? Or is there a remaining task?

--

___
Python tracker 

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

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[STINNER Victor]

STINNER Victor  added the comment:

In Python 3.11, 41 types are declared explicitly with the
Py_TPFLAGS_DISALLOW_INSTANTIATION flag:

* _curses_panel.panel
* _dbm.dbm
* _gdbm.gdbm
* _hashlib.HASH
* _hashlib.HASHXOF
* _hashlib.HMAC
* _md5.md5
* _multibytecodec.MultibyteCodec
* _sha1.sha1
* _sha256.sha224
* _sha256.sha256
* _sha512.sha384
* _sha512.sha512
* _sre.SRE_Scanner
* _ssl.Certificate
* _thread._localdummy
* _thread.lock
* _tkinter.Tcl_Obj
* _tkinter.tkapp
* _tkinter.tktimertoken
* _winapi.Overlapped
* _xxsubinterpreters.ChannelID
* array.arrayiterator
* curses.ncurses_version
* functools.KeyWrapper
* functools._lru_list_elem
* os.DirEntry
* os.ScandirIterator
* pyexpat.xmlparser
* re.Match
* re.Pattern
* select.devpoll
* select.poll
* sqlite3.Statement
* stderrprinter
* sys.flags
* sys.getwindowsversion
* sys.version_info
* unicodedata.UCD
* zlib.Compress
* zlib.Decompress

--

___
Python tracker 

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

[issue42926] Split compiler into code-gen, optimizer and assembler.

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

Re: Puzzling behaviour of Py_IncRef

[Greg Ewing]

The convention for refcounting in CPython is that a function
takes borrowed references as arguments and returns a new
reference.

The 'self' argument passed in is a borrowed reference. If you
want to return it, you need to create a new reference by
increfing it.

So what you have written is just the correct way to write
a do-nothing function that returns its argument, i.e. the
equivalent of the Python function

   def f(self):
  return self

As others have said, if you want to leak a reference, you
need an extra incref besides the one that's a normal part
of the return convention.

--
Greg

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