[issue46594] Windows "Edit with IDLE >" only has one selection

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The registry settings should be correctly set by the installer.  The bug is 
that they are not.  I don't touch the registry, and the last 3 versions are 
less than 2 weeks old.

--

___
Python tracker 

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

[issue41266] IDLE call hints and completions confused by ints and floats

[Terry J. Reedy]

Terry J. Reedy  added the comment:

There are 1000s of open python issues and perhaps 200 for IDLE. I consider this 
one to be lower priority that enough others to fill my IDLE time.

--
stage:  -> test needed
versions: +Python 3.11 -Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue45325] Allow "p" in Py_BuildValue

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

I stumbled upon the PR and tend to agree with Serhiy that this could be a 
source of nasty bugs. Passing the wrong type to a va_arg() argument is 
undefined behavior (e.g. 
https://wiki.sei.cmu.edu/confluence/display/c/EXP47-C.+Do+not+call+va_arg+with+an+argument+of+the+incorrect+type),
 and it does seem easy to do that by accident for an int-like type. For 
printf() compilers implement custom checks that make sure the types are right, 
but we don't get that luxury with Py_BuildValue(). It's also easy to make a 
bool yourself with the O code and Py_True/Py_False, so I don't think the 
additional code is worth the risk.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue41266] IDLE call hints and completions confused by ints and floats

[wyz23x2]

wyz23x2  added the comment:

Ping, this issue is 571 days old.

--

___
Python tracker 

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

[issue26276] Inconsistent behaviour of PEP 3101 formatting between versions

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm going to close this issue. The behavior might be inconsistent with 2.7, but 
I don't think that matters any more.

--
resolution:  -> wont fix
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

[issue45885] Specialize COMPARE_OP

[Dennis Sweeney]

Change by Dennis Sweeney :


--
pull_requests: +29223
pull_request: https://github.com/python/cpython/pull/31040

___
Python tracker 

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

[issue43540] importlib: Document how to replace load_module() in What's New in Python 3.10

[STINNER Victor]

STINNER Victor  added the comment:

Python 3.10 is released. It's too late, I close the issue.

--
resolution:  -> out of date
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

[issue46595] [doc] Undocumented behavior of importlib.metadata.version

[cowlinator]

Change by cowlinator :


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

[issue46595] [doc] Undocumented behavior of importlib.metadata.version

[cowlinator]

cowlinator  added the comment:

nevermind, i was just being stupid. the git describe wound up in a local egg or 
build metadata which i guess is where importlib.metadata.version pulls from

--

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

If necessary, we can keep _Py_IDENTIFIER() (and the functions).  Regardless, we 
can stop using it internally.

--

___
Python tracker 

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

[issue46595] [doc] Undocumented behavior of importlib.metadata.version

[cowlinator]

cowlinator  added the comment:

I'd also like to know which `git describe` args it's using

--

___
Python tracker 

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

[issue46595] [doc] Undocumented behavior of importlib.metadata.version

[cowlinator]

New submission from cowlinator :

If `importlib.metadata.version` can't find the distribution version, it seems 
to return the result of a local `git describe`.  I don't know if this is 
git-specific, or which other SCMs this might try to interact with.

The result of `importlib.metadata.version` varies depending on whether the 
local directory happens to be a git repo.

This is unexpected and undocumented. Based on the documentation, I expected 
that when it couldn't find the distribution version, it would ALWAYS raise and 
exception or return nothing.

In order to properly document this, you'll have to figure out all of the SCMs 
that it might interact with.

--
assignee: docs@python
components: Documentation
messages: 412227
nosy: cowlinator, docs@python
priority: normal
severity: normal
status: open
title: [doc] Undocumented behavior of importlib.metadata.version
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

___
Python tracker 

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

[issue46555] Unicode-mangled names refer inconsistently to constants

[James Gerity]

James Gerity  added the comment:

> Why was it decided to not raise a syntax error...

I'm not sure if such a decision was even ever made, the error happens before 
normalization is applied. I.e. the parser is doing two things here: (1) 
validating the syntax against the grammar and (2) building the AST. 
Normalization happens after (1), and `𝕋𝕣𝕦𝕖 = 0` is valid syntax because the 
grammar is NOT defined in terms of normalized identifiers, it's describing the 
valid (but confusing!) assignment that Carl described.

I agree that this doesn't seem like bug, but it IS my new favorite quirk of 
identifier normalization.

--

___
Python tracker 

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

[issue46594] Windows "Edit with IDLE >" only has one selection

[Eryk Sun]

Eryk Sun  added the comment:

Check your settings in the registry.

In "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts" there 
should be a ".py" key, but not necessarily. It should have an "OpenWithList" 
subkey that contains an "MRUList" value (most recently used list). The value 
should be a sequence of letters, each of which should be a value name in the 
key. If the launcher was last used to open a ".py" file, the first letter in 
the list should be a value with the data "py.exe".

Ideally there should also be a subkey named "UserChoice" that contains a 
"ProgId" (programmatic identifier) value with the data "Python.File". This sets 
the "Python.File" ProgID as the locked-in user choice for ".py" files. In the 
GUI, you can set this in the open-with dialog by selecting "always use this app 
to open .py files". The selected app should be "Python", with an icon that 
contains the Python logo and a rocket (the launcher).

If ".py" isn't the locked-in user choice, the shell API will use the most 
recent user selection in the open-with menu. If there's no user selection, the 
default association is calculated from "HKCR\.py", which is a merged view of 
"[HKCU|HKLM]\Software\Classes\.py". The default value of "HKCR\.py" sets the 
default file association. Ideally it should be "Python.File".

"HKCR\Python.File" is a merged view of 
"[HKCU|HKLM]\Software\Classes\Python.File". For the merged view, if a value 
name is defined in the same subkey of HKCU and HKLM, the view prefers the HKCU 
value. There should be a subkey named "shell\editwithidle\shell". It should 
define one or more subkeys named "edit3*", such as "edit310". Each should 
contain a "MUIVerb" value that sets the command description in the "open-with" 
menu. There should also be a "command" subkey that contains the template 
command as its default value, e.g. ""C:\Program Files\Python310\pythonw.exe" -m 
idlelib "%L" %*".

--
nosy: +eryksun

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

Change by Brandt Bucher :


--
pull_requests: +29222
pull_request: https://github.com/python/cpython/pull/31039

___
Python tracker 

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

[issue46594] Windows "Edit with IDLE >" only has one selection

[Terry J. Reedy]

New submission from Terry J. Reedy :

I have Python and hence IDLE 3.8, 3.9, 3.10, and 3.11 installed.  When I right 
click a .py file, and then on "Edit with IDLE >" the sub-menu only has 
'3.11.0a4' listed.  This negates the purpose of having a submenu.

I did some search of previous issues and see a) that I have had more than one 
version listed before, but b) there have been previous issues with some 
missing.  I don't know if #27603 has any relevance.

I discovered this when investigating the report at
https://stackoverflow.com/questions/70931009/cant-open-py-files-in-idle-on-desktop-with-python-3-10-2
For that, clicking on the submenu worked for 3.9 but not after upgrading to 
3.10. Clicking for me opened the file, but there was only one choice.

--
components: Installation, Windows
messages: 412224
nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows "Edit with IDLE >" only has one selection
type: behavior
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

[issue29688] Add support for Path.absolute()

[Eryk Sun]

Eryk Sun  added the comment:

> I'd imagine that bug is reproducible with `Path('C:\\Temp', 'C:')` 
> already, right? If that's the case, should it logged as a 
> separate issue?

Yes, it's a separate issue that affects the _from_parts() call in absolute().

How about designing absolute() to create a new instance from an absolute path 
that's created by os.path? For example: 

join(abspath(self.drive) if self.drive else getcwd(), self)

Of course use accessor functions.

--

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Barney Gale]

Barney Gale  added the comment:

@eryksun thanks for flagging, a couple thoughts:

I'd imagine that bug is reproducible with `Path('C:\\Temp', 'C:')` already, 
right? If that's the case, should it logged as a separate issue?

I'm planning to /experimentally/ throw away pathlib's internal
path parsing logic and defer to `posixpath` / `ntpath` instead. I suspect this 
bug and others will be fixed by that change, but I need to see what the 
performance impact will be.

--

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Eryk Sun]

Eryk Sun  added the comment:

> I'm not seeing what's wrong with your example.

"C:" or "C:spam\\eggs" are not absolute paths. They depend on the effective 
working directory on the drive. An absolute path should never depend on a 
working directory, which can change at random.

WinAPI SetEnvironmentVariableW() allows applications to set environment 
variables with names that begin with "=". These names are effectively reserved 
for special use by the OS, at least as documented. In particular, names of the 
form "=X:", where "X" is a drive letter, are used to store the working 
directory on a drive. The C runtime _[w]chdir() function sets these per-drive 
environment variables, as does Python's os.chdir(). As environment variables, 
they can be inherited by child processes.

When then Windows API resolves a file path to access a file, or in 
GetFullPathNameW(), a drive-relative path such as "X:" or "X:spam\\eggs" is 
resolved against either the current working directory (if it's on the drive) or 
the value of the "=X:" environment variable for the drive. If the latter isn't 
defined, it defaults to the root directory, e.g. "X:\\". If the current working 
directory is on the drive, the system updates the value of the "=X:" 
environment variable, if it exists.

> on Windows you have to resolve the drive separately from the 
> working directory and then concatenate them?

No, if self.drive is defined, then abspath(self.drive) should be called instead 
of getcwd(). In Windows, ntpath.abspath() calls WinAPI GetFullPathNameW(), 
which resolves the working directory on the drive.

--

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Eryk Sun]

Change by Eryk Sun :


--
Removed message: https://bugs.python.org/msg412220

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Eryk Sun]

Eryk Sun  added the comment:

> I'm not seeing what's wrong with your example.

"C:" or "C:spam\\eggs" are not absolute paths. They depend on the effective 
working directory on the drive. An absolute path should never depend on a 
working directory, which can change at random.

WinAPI SetEnvironmentVariableW() allows applications to set environment 
variables with names that begin with "=". These names are effectively reserved 
for special use by the OS, at least as documented. In particular, names of the 
form "=X:", where "X" is a drive letter, are used to store the working 
directory on a drive. The C runtime _[w]chdir() function sets these per-drive 
environment variables, as does Python's os.chdir(). As environment variables, 
they can be inherited by child processes.

When then Windows API resolves a file path to access a file, or in 
GetFullPathNameW(), a drive-relative path such as "X:" or "X:spam\\eggs" is 
resolved against either the current working directory (if it's on the drive) or 
the value of the "=X:" environment variable for the drive. If the latter isn't 
defined, it defaults to the root directory, e.g. "X:\\". If the current working 
directory is on the drive, the system updates the value of the "=X:" 
environment variable, if it exists.

> on Windows you have to resolve the drive separately from the 
> working directory and then concatenate them?

Yes, if self.drive is defined. This would be handled by 
os.path.abspath(self.drive), which calls WinAPI GetFullPathNameW().

--

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Brett Cannon]

Brett Cannon  added the comment:

@eryksun I'm not seeing what's wrong with your example. Would you mind pointing 
out what you expect the result to be?

And are you saying on Windows you have to resolve the drive separately from the 
working directory and then concatenate them?

--

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

s390x Fedora Clang 3.x buildbot is back to green, I close the issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

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

[miss-islington]

miss-islington  added the comment:


New changeset 34794517d1380e206fbbc9735b8aaaf07a5237ce by Miss Islington (bot) 
in branch '3.10':
bpo-46542: test_lib2to3 uses support.infinite_recursion() (GH-31035)
https://github.com/python/cpython/commit/34794517d1380e206fbbc9735b8aaaf07a5237ce


--

___
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

[miss-islington]

miss-islington  added the comment:


New changeset 30463860796790d3be97b76744290e4c364ad765 by Miss Islington (bot) 
in branch '3.9':
bpo-46542: test_lib2to3 uses support.infinite_recursion() (GH-31035)
https://github.com/python/cpython/commit/30463860796790d3be97b76744290e4c364ad765


--

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +29221
pull_request: https://github.com/python/cpython/pull/31038

___
Python tracker 

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

[issue46372] int/float specializations should mutate the LHS in-place when possible

[Guido van Rossum]

Guido van Rossum  added the comment:

Since we decided to wait on the int operations while longobject.c is being 
refactored (https://github.com/faster-cpython/ideas/issues/245), can you 
clarify whether the speedup reported is from code where it is implemented only 
for floats, or is it from a prototype where it's implemented for floats and 
ints?

--

___
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

[miss-islington]

Change by miss-islington :


--
pull_requests: +29220
pull_request: https://github.com/python/cpython/pull/31037

___
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

[miss-islington]

Change by miss-islington :


--
pull_requests: +29219
pull_request: https://github.com/python/cpython/pull/31036

___
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

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset ee0ac328d38a86f7907598c94cb88a97635b32f8 by Victor Stinner in 
branch 'main':
bpo-46542: test_lib2to3 uses support.infinite_recursion() (GH-31035)
https://github.com/python/cpython/commit/ee0ac328d38a86f7907598c94cb88a97635b32f8


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue46451] Tracing causes module globals to be mutated when calling functions from C

[Sebastian Berg]

Change by Sebastian Berg :


--
title: Possibly bad interaction with tracing and cython? -> Tracing causes 
module globals to be mutated when calling functions from C

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Eric Snow  added the comment:

> Any chance we could revert the recent renaming of tstate.exc_state and 
> tstate.root_cframe

Yeah, I'll sort this out.  Sorry for that.

--

___
Python tracker 

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

[issue42784] issues with object.h includes

[STINNER Victor]

STINNER Victor  added the comment:

There is an on-going work to move more and more header files into 
Include/cpython/ subdirectory, or even to the Include/internal/ directory. 
Examples:

* bpo-35134: Move cellobject.h, classobject.h, context.h, funcobject.h, 
genobject.h and longintrepr.h to Include/cpython/
* bpo-45434: Move pystrhex.h to Include/internal/

C extensions must only use #include "Python.h":
https://docs.python.org/dev/c-api/intro.html#api-includes

Sadly, many project include directly "inner" header files like "longobject.h" 
and so this ong-going work break a few projects at each Python 3.x release.

In the meanwhile, you can reorder your include paths to put your project first, 
or rename object.h to different filename.

---

Yeah, if it wouldn't break any C extension, I would prefer to "hide" all 
"inner" files under a sub-directory, or by renaming them. But right now, it's 
possible.

--
nosy: +vstinner

___
Python tracker 

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

[issue42784] issues with object.h includes

[Irit Katriel]

Irit Katriel  added the comment:

Another workaround is for you to rename object.h in your project.

--
nosy: +iritkatriel
resolution:  -> rejected
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

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to have a PyFrame_GetVariable(frame, "self") function: get the 
value of the "frame" variable of the specified frame object.

--

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

The regression was introduced by GH-30855: "bpo-46329: Split calls into precall 
and call instructions" (commit 89fd7c34520aac493a8784a221366ed04452612b).

--

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

Change by STINNER Victor :


--
pull_requests: +29218
pull_request: https://github.com/python/cpython/pull/31035

___
Python tracker 

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

[issue42844] Turtle Module -- "onclick" arguments enchancement

[sc1341]

Change by sc1341 :


Removed file: https://bugs.python.org/file49723/on_click_arguments_example.py

___
Python tracker 

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

[issue42844] Turtle Module -- "onclick" arguments enchancement

[sc1341]

Change by sc1341 :


--
pull_requests:  -22972

___
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

[Nikita Sobolev]

Change by Nikita Sobolev :


--
nosy:  -sobolevn

___
Python tracker 

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

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

[Aaron Gokaslan]

Aaron Gokaslan  added the comment:

`PyCodeObject_GetVariableName()` and `PyCodeObject_GetVariableKind()` work?

- Some public-gettters such as these functions would be ideal.

OOI, how do you cope with non-local self? 

- We only care about checking self to prevent an infinite recursion in our 
method dispatch code so I am not sure a non-local self would be applicable in 
this case? Correct me if I am wrong.

--

___
Python tracker 

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

[issue45220] Windows builds sometimes fail on Azure and GitHub Action: fatal error RC1116: RC terminating after preprocessor errors

[Steve Dower]

Steve Dower  added the comment:

It was not backported to 3.8 because that's in security fix only mode.

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

[issue46593] memoryview lacks support for half floats

[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

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

[Aaron Gokaslan]

Aaron Gokaslan  added the comment:

We didn't want to read colocalsplus directly because we were worried about the 
stability of that approach and the code complexity / readability. Also, I 
wasn't aware that colocalsplus would work or if that was lazily populated as 
well. 

The functions used in CPython to extract the args from colocalsplus do not seem 
to be public and would need to be reimplemented by PyBind11, right? That seems 
very brittle as try to support future Python versions and may break in the 
future.

Having a somewhat stable C-API to query this information seems like it would be 
the best solution, but I am open to suggestions on how to best proceed. How 
would you all recommend PyBind11 proceed with supporting 3.11 if not a C-API 
addition? The PyBind11 authors want to resolve this before the API becomes too 
locked down for 3.11.

--

___
Python tracker 

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

[issue46593] memoryview lacks support for half floats

[Antoine Pitrou]

New submission from Antoine Pitrou :

The struct module has support for half-floats (the "e" format code) but support 
is not fully enabled in the memoryview object.

Let's contrast float32 (the "f" format code), which you can cast to, and read 
as Python objects:

>>> a = np.array([0.0, -1.5], np.float32())
>>> list(memoryview(a))
[0.0, -1.5]
>>> memoryview(a.tobytes()).cast('f').tolist()
[0.0, -1.5]

and float16, where support is minimal (casting forbidden, reading as Python 
objects unimplemented):

>>> a = np.array([0.0, -1.5], np.float16())
>>> list(memoryview(a))
Traceback (most recent call last):
  File "", line 1, in 
list(memoryview(a))
NotImplementedError: memoryview: format e not supported

>>> memoryview(a.tobytes()).cast('e').tolist()
Traceback (most recent call last):
  File "", line 1, in 
memoryview(a.tobytes()).cast('e').tolist()
ValueError: memoryview: destination format must be a native single character 
format prefixed with an optional '@'

--
components: Interpreter Core
messages: 412205
nosy: mark.dickinson, meador.inge, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview lacks support for half floats
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

[issue46554] Add append keyword argument to Path.write_text() and Path.write_bytes()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Serhiy.

--
nosy: +pitrou, rhettinger

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

test_lib2to3 crash if Python is built with clang when running 
test_all_project_files() of lib2to3.tests.test_all_fixers.Test_all. This test 
crash on processing the file: "Lib/lib2to3/tests/data/infinite_recursion.py".

The GH-30855 change increased the usage of the stack memory when Python is 
built with clang:
https://github.com/python/cpython/pull/30855#issuecomment-1024884758

* GCC allocates between 544 bytes (-O3) and 608 bytes (-Og) on the stack
* clang allocates between 656 bytes (-O3) and 9200 bytes (Og) on the stack

--

___
Python tracker 

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

[issue45413] Add install scheme for virtual environments

[Miro Hrončok]

Miro Hrončok  added the comment:

I've created a draft PR in https://github.com/python/cpython/pull/31034

It is still missing tests and I have not checked it on Windows, hence still a 
draft.

--

___
Python tracker 

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

[issue45413] Add install scheme for virtual environments

[Miro Hrončok]

Change by Miro Hrončok :


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

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +29216
pull_request: https://github.com/python/cpython/pull/31033

___
Python tracker 

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

[issue45413] Add install scheme for virtual environments

[Miro Hrončok]

Miro Hrončok  added the comment:

I'll try to draft this change for Python 3.11.

--

___
Python tracker 

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

[issue46592] Undocumented behavior in strptime for ISO week dates

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

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

[issue46592] Undocumented behavior in strptime for ISO week dates

[Jonatan Skogsfors]

New submission from Jonatan Skogsfors :

Consider the following code :
Python 3.10.2 (main, Jan 31 2022, 12:03:48) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.strptime("2021-53-1", "%Y-%W-%w").strftime("%c")
'Mon Jan  3 00:00:00 2022'

And also:
>>> datetime.strptime("2021-53-1", "%G-%V-%u").strftime("%c")
'Mon Jan  3 00:00:00 2022'

2021 is a "short year" with 52 weeks (e.g. since December 31 is on a Friday). 
The 53rd week of 2021 is interpreted by Python as week 1 of 2022. This can be 
convenient but as I understand it, it is not a part of ISO 8601 and it is not 
documented as a deviation in the documentation for datetime.

As a comparison, the special behavior of week 0 (also not part of ISO 8601) is 
documented. In the documentation for format directive "%W" it is stated that 
"All days in a new year preceding the first Monday are considered to be in week 
0."

If the behavior for week 53 is intended (as opposed to raising an error) I 
think it should be documented.

--
components: Library (Lib)
messages: 412200
nosy: Jonatan Skogsfors
priority: normal
severity: normal
status: open
title: Undocumented behavior in strptime for ISO week dates
type: behavior
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

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[Petr Viktorin]

Petr Viktorin  added the comment:

> I would hope that competent C programmers would know not to read or write to 
> undocumented fields. But if they come from a Python background, that might 
> not be obvious.

Tread carefully when changing decades-old API, documented or not. The docs 
weren't always as useful and complete as they are now.

> If the advice for something is "use Python", we should probably add an API 
> function.

Not really. If PyObject_GetAttrString doesn't add too much overhead, IMO it's 
fine to use it.

--

___
Python tracker 

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

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[Petr Viktorin]

Change by Petr Viktorin :


--
nosy: +petr.viktorin
nosy_count: 2.0 -> 3.0
pull_requests: +29215
pull_request: https://github.com/python/cpython/pull/31032

___
Python tracker 

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

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Florian Weimer]

Florian Weimer  added the comment:

The report/justification for the removal is simply incorrect. Linux still 
supports s390-*-linux-gnu in user mode. The GNU toolchain is maintained, and 
the glibc testsuite is in good shape. Some distributions still support s390 
(31-bit) applications. Others (Fedora 24 or later, for example) no longer do so.

I expect that 31-bit s390 Linux Python is really unusual these days, so 
removing it could still be fine, but lack of support from the GNU toolchain or 
the Linux kernel is not the correct justification for its removal.

If you have questions about the maintenance status of various parts of the GNU 
toolchain, please feel free to reach out to any of the GNU lists.

https://gcc.gnu.org/mailman/listinfo/gcc
https://sourceware.org/mailman/listinfo/binutils
https://sourceware.org/mailman/listinfo/libc-alpha

--
nosy: +fweimer

___
Python tracker 

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

[issue20923] [doc] Explain ConfigParser 'valid section name' and .SECTCRE

[Irit Katriel]

Irit Katriel  added the comment:

The comment Terry suggests to add (see 
https://bugs.python.org/issue20923#msg255304) could be placed in this paragraph:


https://docs.python.org/3/library/configparser.html#supported-ini-file-structure

--
keywords: +easy
nosy: +iritkatriel
title: Explain ConfigParser 'valid section name' and .SECTCRE -> [doc] Explain 
ConfigParser 'valid section name' and .SECTCRE
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, Python 
3.5, Python 3.6

___
Python tracker 

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

[issue27954] makesetup does not take into account subdirectories

[Irit Katriel]

Irit Katriel  added the comment:

Please create a new issue if this is still a problem on versions >= 3.9.

--
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 768569325abc0a9cd5aae65c531889ec390847aa by Ken Jin in branch 
'main':
bpo-46407: Fix long_mod refleak (GH-31025)
https://github.com/python/cpython/commit/768569325abc0a9cd5aae65c531889ec390847aa


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue46578] cant DEBUG os.spawnv()

[michaellongge]

michaellongge  added the comment:

I can't use subprocess. Because the original problem is not that I want to use 
os.spawnv(). The original problem is that I go to install python3d, use 
setup.py install, the returned information shows that the compilation is 
completed, the link is also completed, and the installation is also completed. 
Done, but the pytorch3d folder is in the 
D:\Python38\Lib\site-packages\pytorch3d-0.6.1-py3.8-win-amd64.egg folder, which 
seems to be wrong because I moved it manually It can be used normally outside 
pytorch3d-0.6.1-py3.8-win-amd64.egg. (I wrote the detailed issue here 
[https://github.com/facebookresearch/pytorch3d/issues/1052]) So I I tried to 
use pycharm to debug the process. I wanted to see where the installation error 
was, so I encountered the problem of os.spawnv(). If you want to find the 
installation problem, you must first compile and link. This LIB: fatal error 
LNK1181: just Occurs in the link stage spawn.py (69). The strange thing is that 
the operation will not report an error,
  but DEBUG will report an error.
So my salmpe code is all separated from D:\Python38\Lib\distutils\spawn.py 
(69), when the breakpoint stops here, rc = os.spawnv(os.P_WAIT, executable, 
cmd) The corresponding parameters are written in samlpe, here is another sample 
of mine, which can also be installed on my PC, but cannot use DEBUG for Pycharm

https://github.com/michaellongge163/hellopythonextension

--
Added file: https://bugs.python.org/file50598/20220131165155.png

___
Python tracker 

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