[issue35954] Incoherent type conversion in configparser

[Tal Einat]

Tal Einat  added the comment:

This is indeed inconsistent, but it's a minor issue that has been this way for 
a long time and is easily worked around. IMO changing it would create more 
problems than leaving it as-is.

IMO we should at most clarify in the docs.

--
nosy: +taleinat
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue37189] PyRun_String not exported in python38.dll

[Christoph Gohlke]

New submission from Christoph Gohlke :

While testing third party packages on Python 3.8.0b1 for Windows, I noticed 
that the `PyRun_String` function is no longer exported from `python38.dll`.

Is this intentional? I can't see this mentioned at 
 or 


This change breaks existing code. But then `PyRun_String` is easy to replace 
with `PyRun_StringFlags`.

--
components: Windows
messages: 344905
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PyRun_String not exported in python38.dll
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

[issue37176] super() docs don't say what super() does

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> What more do you want?

Mainly: it says "a parent or sibling class of *type*" but it doesn't explain 
which class it actually uses.

And the sentence "The __mro__ attribute of the type lists the method resolution 
search order used by both getattr() and super()" is even wrong or at least 
confusing: what matters is not the MRO of the type (the first argument to 
super()) but the MRO of the object (the second argument to super()).

The zero-argument form super() is not explained at all.

> Perhaps there ought to be a "gentle guide to super" somewhere, and the docs 
> could link to that?

There are plenty of guides like that and in fact that docs already link to 
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

--

___
Python tracker 

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

[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"

[Stefan Krah]

Stefan Krah  added the comment:


New changeset 0690c79c419b8d2bdfe7c5b6dca57b018f5a5a54 by Stefan Krah (Eric 
Wieser) in branch 'master':
bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (#13881)
https://github.com/python/cpython/commit/0690c79c419b8d2bdfe7c5b6dca57b018f5a5a54


--
nosy: +skrah

___
Python tracker 

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

[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"

[miss-islington]

Change by miss-islington :


--
pull_requests: +13760
pull_request: https://github.com/python/cpython/pull/13882

___
Python tracker 

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

[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"

[Stefan Krah]

Stefan Krah  added the comment:


New changeset 8f0bbbdcae73f275faff90cc4559f616f001 by Stefan Krah (Miss 
Islington (bot)) in branch '3.7':
bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (GH-13881) (#13882)
https://github.com/python/cpython/commit/8f0bbbdcae73f275faff90cc4559f616f001


--

___
Python tracker 

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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 06/06/2019 19:08, Steve Dower wrote:
> Steve Dower  added the comment:
>
> Changing our policy here (from "no policy" to "here's a recommendation") 
> probably deserves a python-dev discussion first.
I can rejoin the list - to follow the discussion, should one start.
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue37190] asyncio.iscoroutinefunction(.asend) returns False

[Radu Matei Lăcraru]

New submission from Radu Matei Lăcraru :

asyncio.iscoroutinefunction(.__anext__)
asyncio.iscoroutinefunction(.asend)
asyncio.iscoroutinefunction(.athrow)
asyncio.iscoroutinefunction(.aclose)

All of these return False, is this the intended behavior? Aren't all of these 
in fact coroutine functions?

--
components: asyncio
messages: 344910
nosy: Radu Matei Lăcraru, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.iscoroutinefunction(.asend) returns False
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Michael Felt]

Change by Michael Felt :


--
nosy: +Michael.Felt

___
Python tracker 

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

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Robert Collins]

Robert Collins  added the comment:

Thank you @Eryk

--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Petr Viktorin]

New submission from Petr Viktorin :

When compiled with GCC's -Werror=declaration-after-statement ("intermingled 
declarations" in PEP7), cpython/abstract.h (included from ) errors on 
vectorcall helper functions added in 3.8.0 Beta 1.

It's well within our rights to ignore this: since 3.6 we require intermingled 
declarations.
But, when re-compiling Fedora we've seen several projects fail with this 
warning (so far: pygobject3, python-dbus, xen; more will likely come).

Dear Release Manager, should we patch 3.8 to avoid this? The patch is simple, 
and it would give projects that we(re) dutifully tested with the Alphas one 
more release to adapt.

I don't think it's worth changing for 3.9 (but if we do we should test it).

--
messages: 344912
nosy: lukasz.langa, petr.viktorin
priority: normal
severity: normal
status: open
title: Python.h contains intermingled declarations
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

[issue24039] Idle: some modal dialogs maximize, don't minimize

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions:  -Python 2.7

___
Python tracker 

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

[issue37177] IDLE: Search dialogs can be hidden behind the main window

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Irv's steps did not work for me either, on Windows, and I do not know how else 
to reproduce.  So I cannot test that this fixes any hiding issue.  However, the 
patch fixes #24039.  On Windows, it removes the inoperative minimize button and 
the unwanted maximize buttom, making the search dialog work like all the other 
IDLE dialogs I checked.

--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Petr Viktorin]

Petr Viktorin  added the comment:

> pygobject3, python-dbus, xen

Correction:
- The Fedora packages failed to build; this might or might not be due to the 
projects themseves
- pygobject3 actually only warns on this

Anyway, we can usually take care of open-source stuff. Only take it as a litmus 
test for codebases we don't know about.

--
stage: patch review -> 

___
Python tracker 

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

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Michael Felt]

Michael Felt  added the comment:

I started a reply on the python-mentoring maillist - and promised to come back 
here.

a) imho - the discussion about an "attacker" is only misleading for the general 
case. For active attacks - where an attacker has active acces to the system is 
not something that is the responsibility of "stdlib". On POSIX, one of the 
first things I would consider is adding the "STX" bit so that only root and the 
file owner can remove an existing "link" to an inode (a symbolic link is a 
"special" file whose contents is the PATH to yet another filesystem "name" 
regardless of it's type.) For reference, a hard-link "merely" increases the 
number of links to an inode - and so only works for non-directory objects 
within the same filesystem). Puf!

b) the "real", again imho, security issue is one of system integrity. Compare 
this "race" condition with a multi-user database (think of directories as the 
"index" to a data-record. A user that trusts the file-system index to refer to 
the correct file-system object (file, directory, other special file) - 
especially when there is no way for the user to verify the accuracy of the 
symbolic link. Any application, especially if it runs as "root" needs to be 
extremely cautious with "overwriting" existing "records". It is asif as 
database admin just changes where one database record references - as is, I 
cannot change the data it references - so I just change what it goes to - where 
I can change the data. -- As I think about it - an application that is 
dependent on symbolic links has an inherent weakness.

In short - I would be against this - if security is the primary argument for 
developing it. I would rather be notified that there is an existing symbolic 
link - where there should not be - and consider later action.

a) an application, running as root, can override any security measure I can 
come up with. The is the core "weakness" of UNIX/POSIX access control. When not 
running as root - there are mechanisms that can block the removal of any 
directory entry (the unlink() call).

b) so, if you want to consider adding a "user-friendly" force option, just as 
POSIX ln does (whether for hard or soft links) - then that is, imho - a 
different discussion. I would tend to be "against" making it too easy, because 
an application coded with "Force=true" would never get the feedback that 
something already exists. If the currect implementation returns the a "fatal" 
error - that needs to be fixed.

In short, I do not think it is the task of Python to rewrite the behavior of 
the system calls being used - and/because I fear lazy programmers (being there, 
done that!).

"ls -sf xxx yyy" and/or "ln -f xxx yyy" is a convenience. Using it as a default 
is "bad-practice" (imho) - and I fear programmers would use this new "feature" 
and move to "bad practice"

Michael

--

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Jun 07, 2019 at 08:00:34AM +, Jeroen Demeyer wrote:
> 
> Jeroen Demeyer  added the comment:
> 
> > What more do you want?
> 
> Mainly: it says "a parent or sibling class of *type*" but it doesn't 
> explain which class it actually uses.

Only one of the two arguments is called "type". The other is called 
"object-or-type".

> And the sentence "The __mro__ attribute of the type lists the method 
> resolution search order used by both getattr() and super()" is even 
> wrong or at least confusing: what matters is not the MRO of the type 
> (the first argument to super()) but the MRO of the object (the second 
> argument to super()).

The sentence doesn't talk about the MRO of *type* (the first argument), 
it talks about the __mro__ attribute. It is correct. The __mro__ 
attribute is on the type, not the instance:

py> int.__mro__
(, )

py> int().__mro__
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'int' object has no attribute '__mro__'

super() look-ups never start at the instance, they delegate to the 
superclass (or superclasses), not back to the current class, or the 
instance itself.

> The zero-argument form super() is not explained at all.

Yes it is. Look at the example given:

super().method(arg)# This does the same thing as:
   # super(C, self).method(arg)

--

___
Python tracker 

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

[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"

[Stefan Krah]

Stefan Krah  added the comment:

Thanks for the fix!

3.7/3.8 are done, 2.7 still needs a manual backport.

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

[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"

[Stefan Krah]

Change by Stefan Krah :


--
stage: patch review -> backport needed

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Only one of the two arguments is called "type". The other is called 
"object-or-type".

I'm having problems with the first word of "a parent or sibling class of type". 
The most important part of super() is to *which* class that attribute lookups 
are delegated to and this is not explained.

> The __mro__ attribute is on the type, not the instance:

Sorry for that. I meant to say:

And the sentence "The __mro__ attribute of the type lists the method resolution 
search order used by both getattr() and super()" is even wrong or at least 
confusing: what matters is not the MRO of the type (the first argument to 
super()) but the MRO of ***the type of*** the object (the second argument to 
super()).

> Yes it is. Look at the example given:

An example is not an explanation. But it's true, this is the least of my 
problems with this doc.

--

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> The sentence doesn't talk about the MRO of *type* (the first argument), 
it talks about the __mro__ attribute.

If you have to explain in a bpo issue how the doc should be read, that proves 
exactly my point that it's confusing. The fact that it's technically correct if 
you read it the right way is irrelevant.

--

___
Python tracker 

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

[issue37151] Calling code cleanup after PEP 590

[Petr Viktorin]

Petr Viktorin  added the comment:


New changeset 3f345c39255dc3823dd989d4e3c93b12d18c44e0 by Petr Viktorin (Jeroen 
Demeyer) in branch 'master':
bpo-37151: simplify classmethoddescr_call (GH-13340)
https://github.com/python/cpython/commit/3f345c39255dc3823dd989d4e3c93b12d18c44e0


--

___
Python tracker 

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

[issue37169] test_pyobject_is_freed_free fails with 3.8.0beta1

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue36402] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue37187] CField.size from the ctypes module does not behave as documented on bitfields

[Michele Angrisano]

Michele Angrisano  added the comment:

Hi Eric,

Thank you for the report.
Would you interested to propose a Pull Request for this issue?
You can read the devguide for more info: https://devguide.python.org/

--
nosy: +amaury.forgeotdarc, belopolsky, mangrisano, meador.inge

___
Python tracker 

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

[issue36402] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I wrote PR 13889: with this change, I can easily reproduce the crash on Linux:

$ ./python -m test test_threading -m test_threads_join_2 -F
Run tests sequentially
0:00:00 load avg: 0.51 [  1] test_threading
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x7f84ad74d740 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/test/support/__init__.py", line 
2794 in run_in_subinterp
  File "/home/vstinner/prog/python/master/Lib/test/test_threading.py", line 923 
in test_threads_join_2
...

Py_EndInterpreter() calls wait_for_thread_shutdown() to wait until 
threading._shutdown() completes.

When the assertion fails, threading.enumerate() only contains the main thread: 
the spawned thread is already gone. But the assertion fails, which means that 
the Python thread state of the thread (which looks to be completed) is still 
around.

This unit test comes from bpo-18808:

commit 7b4769937fb612d576b6829c3b834f3dd31752f1
Author: Antoine Pitrou 
Date:   Sat Sep 7 23:38:37 2013 +0200

Issue #18808: Thread.join() now waits for the underlying thread state to be 
destroyed before returning.
This prevents unpredictable aborts in Py_EndInterpreter() when some 
non-daemon threads are still running.

--

___
Python tracker 

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

[issue36402] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow, pitrou

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Jun 07, 2019 at 09:57:11AM +, Jeroen Demeyer wrote:

> I'm having problems with the first word of "a parent or sibling class of 
> type". 

The first word is "a". Did you mean something else or did you mean it 
literally?

If the second case, we have to talk about *a* parent class rather than 
*the* parent class, since Python supports multiple inheritance and a 
class can have more than one parent class.

> The most important part of super() is to *which* class that attribute 
> lookups are delegated to and this is not explained.

Lookups are delegated to a parent or sibling class, exactly as the 
documentation says. Which class that is (whether a parent or sibling) 
can only be determined at runtime.

> And the sentence "The __mro__ attribute of the type lists the method 
> resolution search order used by both getattr() and super()" is even 
> wrong or at least confusing: what matters is not the MRO of the type 
> (the first argument to super()) but the MRO of ***the type of*** the 
> object (the second argument to super()).

I believe that is still wrong.

What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

The MRO of the second argument is not relevant, except to the degree 
that it overlaps with the __mro__ attribute of the first. And it will 
always overlaps, because the second argument must be an instance or 
subclass of the first. But not necessarily *directly* of the first:

object > Parent > A > B > C > D > E > F > instance = F()

If the method is defined in class C, then the super call in C should be 
written:

class C(B):
def method(self, arg):
super().method(arg)  # like super(C, self).method(arg)

and the lookup will start at C.__mro__[1], namely B, precisely as 
expected. If it started back at the type of the instance (self), namely 
class F, the C.method would recursively call itself over and over and 
over again.

If you don't believe me, you can simulate super() working the way you 
suggest by doing this:

# -%<-

class A(object):
def method(self):
print("from class A")

class B(A):
def method(self):
print("bad method")
# This is bad, don't do it!
super(type(self), self).method()

class C(B): pass

C().method()

# -%<-

For multiple inheritance:

class C(B, X, Y, Z): ...

we can't generally tell in advance which will be looked at next, since 
that depends on the precise details of the inheritance diagram. But 
whatever the class is, at this point, it is still the __mro__ of C that 
is used, not the MRO of the instance.

The bottom line: what matters is .__mro__, exactly as 
documented.

--

___
Python tracker 

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

[issue37192] pip instal math3d - EROR

[Alen Kolman]

New submission from Alen Kolman :

I am geting constant eror while trying to isntal math3d or urx libary for 
Python using pip install. I am using Windows 10 and Python 3.7.3

I tried to: - unistall/instal python and also try older version 3.4.4.. nothing 
work - upgrade setuptools - upgrade pip (then I get even more errors)

Here is my error:
C:\Python34\Scripts>pip install math3d
Collecting math3d
  Using cached 
https://files.pythonhosted.org/packages/9a/33/72ac95bb4ac11a2b13e033d90f84430dc23fc815124d9303dffca8789a75/math3d-3.3.4.tar.gz
Installing collected packages: math3d
  Running setup.py install for math3d ... error
Complete output from command c:\python34\python.exe -u -c "import 
setuptools, 
tokenize;__file__='C:\\Users\\ALEN~1.KOL\\AppData\\Local\\Temp\\pip-install-duiwypg9\\math3d\\setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
C:\Users\ALEN~1.KOL\AppData\Local\Temp\pip-record-cmd8m8g6\install-record.txt 
--single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib
creating build\lib\math3d
copying math3d\orientation.py -> build\lib\math3d
copying math3d\orientation_computer.py -> build\lib\math3d
copying math3d\quaternion.py -> build\lib\math3d
copying math3d\transform.py -> build\lib\math3d
copying math3d\utils.py -> build\lib\math3d
copying math3d\vector.py -> build\lib\math3d
copying math3d\__init__.py -> build\lib\math3d
creating build\lib\math3d\interpolation
copying math3d\interpolation\r3interpolation.py -> 
build\lib\math3d\interpolation
copying math3d\interpolation\se3interpolation.py -> 
build\lib\math3d\interpolation
copying math3d\interpolation\so3interpolation.py -> 
build\lib\math3d\interpolation
copying math3d\interpolation\__init__.py -> build\lib\math3d\interpolation
creating build\lib\math3d\reference_system
copying math3d\reference_system\frame.py -> 
build\lib\math3d\reference_system
copying math3d\reference_system\free_vector.py -> 
build\lib\math3d\reference_system
copying math3d\reference_system\point.py -> 
build\lib\math3d\reference_system
copying math3d\reference_system\reference_system.py -> 
build\lib\math3d\reference_system
copying math3d\reference_system\__init__.py -> 
build\lib\math3d\reference_system
creating build\lib\math3d\dynamics
copying math3d\dynamics\twist.py -> build\lib\math3d\dynamics
copying math3d\dynamics\wrench.py -> build\lib\math3d\dynamics
copying math3d\dynamics\__init__.py -> build\lib\math3d\dynamics
creating build\lib\math3d\geometry
copying math3d\geometry\line.py -> build\lib\math3d\geometry
copying math3d\geometry\plane.py -> build\lib\math3d\geometry
copying math3d\geometry\__init__.py -> build\lib\math3d\geometry
running install_lib
running install_data
Traceback (most recent call last):
  File "", line 1, in 
  File 
"C:\Users\ALEN~1.KOL\AppData\Local\Temp\pip-install-duiwypg9\math3d\setup.py", 
line 23, in 
data_files=[('share/doc/pymath3d/', ['README.md', 'COPYING'])]
  File "c:\python34\lib\distutils\core.py", line 148, in setup
dist.run_commands()
  File "c:\python34\lib\distutils\dist.py", line 966, in run_commands
self.run_command(cmd)
  File "c:\python34\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
  File "c:\python34\lib\site-packages\setuptools\command\install.py", line 
61, in run
return orig.install.run(self)
  File "c:\python34\lib\distutils\command\install.py", line 557, in run
self.run_command(cmd_name)
  File "c:\python34\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
  File "c:\python34\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
  File "c:\python34\lib\distutils\command\install_data.py", line 56, in run
dir = convert_path(f[0])
  File "c:\python34\lib\distutils\util.py", line 112, in convert_path
raise ValueError("path '%s' cannot end with '/'" % pathname)
ValueError: path 'share/doc/pymath3d/' cannot end with '/'


Command "c:\python34\python.exe -u -c "import setuptools, 
tokenize;__file__='C:\\Users\\ALEN~1.KOL\\AppData\\Local\\Temp\\pip-install-duiwypg9\\math3d\\setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
C:\Users\ALEN~1.KOL\AppData\Local\Temp\pip-record-cmd8m8g6\install-record.txt 
--single-version-externally-managed --compile" failed with error code 1 in 
C:\Users\ALEN~1.KOL\AppData\Local\Temp\pip-install-duiwypg9\math3d\

--
components: Installation
messages: 344924
nosy: Alen Kolman
priority: normal
severity: normal
status: 

[issue37192] pip instal math3d - EROR

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This tracker is only for issues related to CPython. math3d is not a part of 
CPython stdlib. I would suggest following up on the respective repo's issue 
tracker.

--
nosy: +xtreak

___
Python tracker 

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

[issue37192] pip instal math3d - EROR

[SilentGhost]

Change by SilentGhost :


--
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

___
Python tracker 

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

[issue37194] Move new vector headers to the internal C API

[STINNER Victor]

New submission from STINNER Victor :

bpo-37191: the new vector APIs declare "static inline" functions which are no 
C89 compatible and so cause compilation issues on pygobject3, python-dbus, xen 
(for example).

I propose to move the new *private* declarations to the internal C API.

I started to work on an application. The blocker issue is _PyObject_CallNoArg() 
which is now commonly used in CPython code base for best performances. It is 
used the _testcapi which must *not* be compiled with the internal C API.

So I suggest to first add a new public PyObject_CallNoArg() function. It would 
be different than _PyObject_CallNoArg() static inline function: 
PyObject_CallNoArg() would be a regular function and so fit better with ABI 
issues.

--
components: Interpreter Core
messages: 344927
nosy: vstinner
priority: normal
severity: normal
status: open
title: Move new vector headers to the internal C API
versions: 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

[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

[Norihiro Maruyama]

New submission from Norihiro Maruyama :

UDP/TCPServer with socketserver.ThreadingMixin class (also ThreadingTCPServer 
and ThreadingUDPServer class) seems to be memory leak while running the server.

https://docs.python.org/3/library/socketserver.html#socketserver.ThreadingMixIn

My code which wrote to check this is the following.

```
class ThreadedTCPRequestHandler(socketserver.BaseRequestHandler):
def handle(self):
data = str(self.request.recv(1024), 'ascii')
cur_thread = threading.current_thread()
response = bytes("{}: {}".format(cur_thread.name, data), 'ascii')
self.request.sendall(response)


if __name__ == "__main__":
HOST, PORT = "localhost", 0

server = socketserver.ThreadingTCPServer((HOST, PORT), 
ThreadedTCPRequestHandler)
server.daemon_threads = False
server.block_on_close = True

with server:
ip, port = server.server_address

server_thread = threading.Thread(target=server.serve_forever)

server_thread.daemon = True
server_thread.start()

for i in range(1000):
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
sock.connect(server.server_address)
sock.sendall(bytes("hello", 'ascii'))
response = str(sock.recv(1024), 'ascii')
print("Received: {}".format(response))
time.sleep(0.01)

server.server_close()
server.shutdown()
```
( I wrote this based on 
https://docs.python.org/3/library/socketserver.html#asynchronous-mixins)

Then I checked memory usage with profiling tool.
(I used memory-profiler module https://pypi.org/project/memory-profiler/)

$ mprof run python mycode.py
$ mprof plot

I attached result plot.

And also I checked this also more long time and I found memory usage was 
increased endlessly.

My environment is

Hardware: MacBook Pro (15-inch, 2018)
OS: MacOS 10.14
Python 3.7.1


I guess it caused by a thread object is not released in spite of the thread 
finished to process request and thread object will be made infinitely until 
server_close() is called.

--
components: Library (Lib)
files: threadingmixin_memory_usage.png
messages: 344926
nosy: maru-n
priority: normal
severity: normal
status: open
title: Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48399/threadingmixin_memory_usage.png

___
Python tracker 

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

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

[STINNER Victor]

Change by STINNER Victor :


--
title: Move new vector headers to the internal C API -> Move new vector private 
declarations to the internal C API

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[STINNER Victor]

STINNER Victor  added the comment:

PR 13887 is fine but I would prefer to still be able to use C99 style for 
variable declarations. More generally, I don't think that variable declaration 
is the only issue: static inline function is a new shiny thing which can cause 
other issues with some C compilers. So I propose a different approach, 
bpo-37194: "Move new vector private declarations to the internal C API".

--
nosy: +vstinner

___
Python tracker 

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

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

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> I propose to move the new *private* declarations to the internal C API.

Some of those functions (in particular _PyObject_Vectorcall) are expected to 
become public in 3.9. They are only private for now since the API is 
provisional.

--
nosy: +jdemeyer

___
Python tracker 

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

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

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> If you have to explain in a bpo issue how the doc should be read, that 
> proves exactly my point that it's confusing. The fact that it's 
> technically correct if you read it the right way is irrelevant.

Do you expect the docs to be technically correct when read wrongly? How 
else should people read the docs, except the right way?

If you have *concrete* suggestions for improvements, of course we will 
consider them. I'll start with two concrete improvements:

1. Explicitly document that the zero-argument version is equivalent
to super(__class__, ), and note that 
__class__ here is a special variable populated by the compiler.

The first part of this is already documented in super.__doc__ and the 
second part used to be documented:

https://docs.python.org/3.1/library/functions.html?#super

and I don't think there's any harm in adding it back in.

2. Link to the essay on how the MRO is calculated.

https://www.python.org/download/releases/2.3/mro/

--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Should we revert these inline functions back to macros?

--
nosy: +jdemeyer

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> It's well within our rights to ignore this: since 3.6 we require intermingled 
> declarations.

It's not clear from PEP 7 if we require intermingled declarations only when 
compiling CPython itself, or also for external packages that include CPython 
headers. It would be prudent to stay C89-compatible for non-internal header 
files.

--

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +13765
pull_request: https://github.com/python/cpython/pull/13891

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

[Norihiro Maruyama]

Change by Norihiro Maruyama :


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

___
Python tracker 

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

[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

./python.exe -m test test_os -R : -v
==
FAIL: test_utime (test.test_os.UtimeTests)
--
Traceback (most recent call last):
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 591, in 
test_utime
self._test_utime(set_time)
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 579, in 
_test_utime
self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6)
AssertionError: 1559912609.2612822 != 1.002003 within 1e-06 delta 
(1559912608.2592793 difference)

==
FAIL: test_utime_by_indexed (test.test_os.UtimeTests)
--
Traceback (most recent call last):
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 609, in 
test_utime_by_indexed
self._test_utime(set_time)
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 579, in 
_test_utime
self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6)
AssertionError: 1559912609.2679918 != 1.002003 within 1e-06 delta 
(1559912608.2659888 difference)

==
FAIL: test_utime_dir_fd (test.test_os.UtimeTests)
--
Traceback (most recent call last):
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 651, in 
test_utime_dir_fd
self._test_utime(set_time)
  File "/Users/pgalindo3/github/cpython/Lib/test/test_os.py", line 579, in 
_test_utime
self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6)
AssertionError: 1559912609.2721212 != 1.002003 within 1e-06 delta 
(1559912608.2701182 difference)

--

--
components: Tests
messages: 344933
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)
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

[issue37192] pip instal math3d - EROR

[Steven D'Aprano]

Steven D'Aprano  added the comment:

In addition to being a third-party library, according to the output you posted, 
you're actually running Python 3.4 not 3.7.

--
nosy: +steven.daprano

___
Python tracker 

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

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

[STINNER Victor]

Change by STINNER Victor :


Added file: https://bugs.python.org/file48400/stack_overflow-4.py

___
Python tracker 

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

[issue37030] Lib/cmd.py: Hide undocumented commands in help and completenames

[Aldwin Pollefeyt]

Aldwin Pollefeyt  added the comment:

Can there be a review of the PR to let me know if all changes are correct?

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

I used testcapi_call_no_args.patch and stack_overflow-4.py to measure the stack 
consumption of PyObject_CallNoArgs() and PyObject_CallFunctionObjArgs() for PR 
13890.

--
Added file: https://bugs.python.org/file48401/testcapi_call_no_args.patch

___
Python tracker 

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

[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +p-ganssle

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

I'm sorry to say that you're wrong here. super() looks at the MRO of the type 
of the object (the second argument) (*). It has to do that in order to support 
diamonds. Consider a diamond like

  D
 / \
B   C
 \ /
  A

(with A as common base class). Now super(B, D()).attr will look in the MRO of D 
(which is D, B, C, A) and therefore delegate to C.attr. In this case, C does 
not even appear in the MRO of B.

(*) To be pedantic: in the special case that the second argument is a type 
itself, it looks at the MRO of the second argument.

--

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

And this last comment is precisely the kind of information which should be 
explained in the super() docs.

--

___
Python tracker 

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

[issue37196] Allowing arbitrary expressions in the @expression syntax

[Géry]

New submission from Géry :

Could we allow arbitrary expressions in the @expression syntax for applying 
decorators to functions/classes? The current grammar restriction to:

decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE

is very surprising and I don't understand the real motivation.

I find it weird that you are not able to do that:

def f():
def g():
def h(x):
pass
return h
return g

@f()()
def i():
pass

since you get:

@f()()
^
SyntaxError: invalid syntax

but the following is perfectly valid:

def f():
def g():
def h(x):
pass
return h
return g

def g(x):
def h(x):
pass
return g

@g(f()())
def h():
pass

See this post for more details: https://stackoverflow.com/questions/56490579

--
components: Interpreter Core
messages: 344939
nosy: bob.ippolito, exarkun, gvanrossum, j1m, maggyero, mwh, rhettinger
priority: normal
severity: normal
status: open
title: Allowing arbitrary expressions in the @expression syntax
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue37196] Allowing arbitrary expressions in the @expression syntax

[Christian Heimes]

Christian Heimes  added the comment:

The syntax is deliberately limited. The reasons are explained at:

https://www.python.org/dev/peps/pep-0318/#current-syntax
https://mail.python.org/pipermail/python-dev/2004-August/046711.html

--
nosy: +christian.heimes

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Géry]

Géry  added the comment:

@Jeroen Demeyer

> I'm sorry to say that you're wrong here. super() looks at the MRO of the type 
> of the object (the second argument) (*).

Exactly! It is funny because I was about to open the same issue this weekend. 
The documentation of super() is wrong here.

--
nosy: +maggyero

___
Python tracker 

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

[issue37169] test_pyobject_is_freed_free fails with 3.8.0beta1

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3bf0f3ad2046ac674d8e8a2c074a5a8b3327797d by Victor Stinner in 
branch 'master':
bpo-37169: Rewrite _PyObject_IsFreed() unit tests (GH-13888)
https://github.com/python/cpython/commit/3bf0f3ad2046ac674d8e8a2c074a5a8b3327797d


--

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[STINNER Victor]

STINNER Victor  added the comment:


New changeset dd492d9c352eb0fa2bc48ea9acc47e47a7fab8a0 by Victor Stinner 
(Zackery Spytz) in branch '3.8':
[3.8] bpo-37170: Fix the cast on error in PyLong_AsUnsignedLongLongMask() 
(GH-13860) (GH-13891)
https://github.com/python/cpython/commit/dd492d9c352eb0fa2bc48ea9acc47e47a7fab8a0


--

___
Python tracker 

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

[issue37169] test_pyobject_is_freed_free fails with 3.8.0beta1

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13769
pull_request: https://github.com/python/cpython/pull/13895

___
Python tracker 

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

[issue37177] IDLE: Search dialogs can be hidden behind the main window

[Thomas Viehmann]

Change by Thomas Viehmann :


--
pull_requests: +13768
pull_request: https://github.com/python/cpython/pull/13894

___
Python tracker 

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

[issue37196] Allowing arbitrary expressions in the @expression syntax

[Géry]

Géry  added the comment:

@Christian Heimes

> The reasons are explained at:

Yes I read that. But I am wondering if after 15 years Guido still has this "gut 
feeling". Because my gut feeling as a Python *user* who has discovered 
decorators and stumbled on this restriction was: "what?!".

--

___
Python tracker 

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

[issue33826] enable discovery of class source code in IPython interactively defined classes

[Thomas Viehmann]

Change by Thomas Viehmann :


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

___
Python tracker 

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

[issue37177] IDLE: Search dialogs can be hidden behind the main window

[Tal Einat]

Change by Tal Einat :


--
pull_requests:  -13768

___
Python tracker 

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

[issue33826] enable discovery of class source code in IPython interactively defined classes

[Tal Einat]

Tal Einat  added the comment:

Given that classes already have a '__module__' attribute, using which it is 
rather easy to find the filename, I don't see a good reason to add such an 
attribute to classes.

IMO it would be more appropriate to directly create enhancement proposal for 
IPython/Jupyter to enhance the capabilities of their source code retrieval.

I suggest rejecting this enhancement.

--
nosy: +taleinat

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +13771
pull_request: https://github.com/python/cpython/pull/13896

___
Python tracker 

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

[issue37196] Allowing arbitrary expressions in the @expression syntax

[Guido van Rossum]

Guido van Rossum  added the comment:

What you want to write is as unreadable as it ever was.

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

[issue33826] enable discovery of class source code in IPython interactively defined classes

[Thomas Viehmann]

Thomas Viehmann  added the comment:

Note that the module is less granular than the filename in IPython - i.e. it's 
useless for within notebooks.

--
nosy: +t-vi

___
Python tracker 

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

[issue33826] enable discovery of class source code in IPython interactively defined classes

[Thomas Viehmann]

Change by Thomas Viehmann :


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

[issue36300] eval of comprehension cannot access local variables

[Pekka Klärck]

Pekka Klärck  added the comment:

More ways to be bitten by this strange behavior:

>>> d = {'a': 1, 'b': 2}
>>> eval('[x[k] for k in x]', {}, {'x': d})
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
  File "", line 1, in 
NameError: name 'x' is not defined
>>> 
>>> def f():
... x = {'a': 1, 'b': 2}
... return eval('[x[k] for k in x]')
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in f
  File "", line 1, in 
  File "", line 1, in 
NameError: name 'x' is not defined



In both of the above cases changing

eval('[x[k] for k in x]')

to

eval('[v for v in x.values()]')

avoids the problem. There are no problems when using

[x[k] for k in x]

without `eval()` either. I'd prefer this to be changed, but there should at 
least be a note in the documentation of `eval()` about this.

--
nosy: +pekka.klarck

___
Python tracker 

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

[issue33826] enable discovery of class source code in IPython interactively defined classes

[Thomas Viehmann]

Change by Thomas Viehmann :


--
nosy:  -t-vi
resolution:  -> rejected

___
Python tracker 

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

[issue36300] eval of comprehension cannot access local variables

[Pekka Klärck]

Pekka Klärck  added the comment:

I encountered this issue because Robot Framework -- a generic Python based test 
automation framework -- supports evaluating Python expressions and this issue 
was reported for us:
https://github.com/robotframework/robotframework/issues/3207

--

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Géry]

Géry  added the comment:

@Steven D'Aprano

> What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

By the way, if it was true (it is not), then what did you think was the purpose 
of the second parameter of super(type, obj-or-type)?

--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[Christoph Reiter]

Christoph Reiter  added the comment:

I've removed -Wdeclaration-after-statement in upstream pygobject: 
https://gitlab.gnome.org/GNOME/pygobject/merge_requests/119

--
nosy: +lazka

___
Python tracker 

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

[issue37196] Allowing arbitrary expressions in the @expression syntax

[Géry]

Géry  added the comment:

@Guido van Rossum

> What you want to write is as unreadable as it ever was.

How is @g(f()()) more readable than @f()()? Yet the former is allowed.

--
resolution: wont fix -> 
status: closed -> open

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e36ed475ea429f7cc80a4d65f80b44686a74b246 by Victor Stinner 
(Zackery Spytz) in branch '3.7':
[3.7] bpo-37170: Fix the cast on error in PyLong_AsUnsignedLongLongMask() 
(GH-13860) (GH-13896)
https://github.com/python/cpython/commit/e36ed475ea429f7cc80a4d65f80b44686a74b246


--

___
Python tracker 

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

[issue37169] test_pyobject_is_freed_free fails with 3.8.0beta1

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 357626676035d2bb12ea92e0edf3c7b383d627ec by Victor Stinner in 
branch '3.8':
bpo-37169: Rewrite _PyObject_IsFreed() unit tests (GH-13888) (GH-13895)
https://github.com/python/cpython/commit/357626676035d2bb12ea92e0edf3c7b383d627ec


--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 740a84de73ad8d02655de0a084036f4b7e49a01b by Victor Stinner in 
branch 'master':
bpo-37191: Move TestPEP590 from test_capi to test_call (GH-13892)
https://github.com/python/cpython/commit/740a84de73ad8d02655de0a084036f4b7e49a01b


--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[miss-islington]

Change by miss-islington :


--
pull_requests: +13772
pull_request: https://github.com/python/cpython/pull/13897

___
Python tracker 

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

[issue37169] test_pyobject_is_freed_free fails with 3.8.0beta1

[STINNER Victor]

STINNER Victor  added the comment:

Matej Cepl: thanks for the bug report, it should now be fixed.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[STINNER Victor]

STINNER Victor  added the comment:

> I've removed -Wdeclaration-after-statement in upstream pygobject: 
> https://gitlab.gnome.org/GNOME/pygobject/merge_requests/119

Thanks! Enjoy C99! :-) IMHO C99 with variables in the middle of a function 
helps to write more reliable code: we better control the scope of a variable. 
It reduces the risk of using an uninitialized variable.

--

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +13773
pull_request: https://github.com/python/cpython/pull/13898

___
Python tracker 

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

[issue37180] Fix Persian KAF in mac_farsi.py

[STINNER Victor]

STINNER Victor  added the comment:

> Regarding the file named: "Lib/encodings/mac_farsi.py", the numbers are 
> inserted in the wrong way, they are inserted Arabic numbers instead of 
> Persian, they are edited in the comment.

Python implements the Unicode standard. In the master branch, it's the Unicode 
standard version 11.0. It gives these character names:

$ python3
>>> import unicodedata
>>> for ch in list(range(0x06f0, 0x06f9+1)) + [0x06A9]:
...  print("U+%04x: %s" % (ch, unicodedata.name(chr(ch
... 

U+06f0: EXTENDED ARABIC-INDIC DIGIT ZERO
U+06f1: EXTENDED ARABIC-INDIC DIGIT ONE
U+06f2: EXTENDED ARABIC-INDIC DIGIT TWO
U+06f3: EXTENDED ARABIC-INDIC DIGIT THREE
U+06f4: EXTENDED ARABIC-INDIC DIGIT FOUR
U+06f5: EXTENDED ARABIC-INDIC DIGIT FIVE
U+06f6: EXTENDED ARABIC-INDIC DIGIT SIX
U+06f7: EXTENDED ARABIC-INDIC DIGIT SEVEN
U+06f8: EXTENDED ARABIC-INDIC DIGIT EIGHT
U+06f9: EXTENDED ARABIC-INDIC DIGIT NINE
U+06a9: ARABIC LETTER KEHEH

>>> unicodedata.unidata_version
'11.0.0'

I still see "ARABIC" in character names.

> The KAF character (ك)

That's the Unicode character: U+0643 called "ARABIC LETTER KAF".

Comments in 
https://github.com/python/cpython/blob/master/Lib/encodings/mac_farsi.py still 
seems to be up to date.

SilentGhost:
> The replacement character that you're proposing is called (according to the 
> same database) 'ARABIC LETTER KEHEH', whereas the old one was 'ARABIC LETTER 
> KAF'. This encoding was originally generated based on data from unicode.org, 
> I'd think a reference would be needed making clear that this is indeed a 
> valid replacement.

mac_farsi.py docstring says:

""" Python Character Mapping Codec mac_farsi generated from 
'MAPPINGS/VENDORS/APPLE/FARSI.TXT' with gencodec.py.

The mapping comes from Unicode. Was it updated since this file was created?

The latest change in this file was made in 2007, a few years ago :-)

--

I don't see anything wrong, I suggest to close the issue.

--

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[miss-islington]

miss-islington  added the comment:


New changeset 5effd10bf14ab0a8a6695100aaf0b687eca68e6d by Miss Islington (bot) 
in branch '3.8':
bpo-37191: Move TestPEP590 from test_capi to test_call (GH-13892)
https://github.com/python/cpython/commit/5effd10bf14ab0a8a6695100aaf0b687eca68e6d


--
nosy: +miss-islington

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I used the wrong bpo number for this change:

New changeset 740a84de73ad8d02655de0a084036f4b7e49a01b by Victor Stinner in 
branch 'master':
bpo-37191: Move TestPEP590 from test_capi to test_call (GH-13892)
https://github.com/python/cpython/commit/740a84de73ad8d02655de0a084036f4b7e49a01b

New changeset 5effd10bf14ab0a8a6695100aaf0b687eca68e6d by Miss Islington (bot) 
in branch '3.8':
bpo-37191: Move TestPEP590 from test_capi to test_call (GH-13892)
https://github.com/python/cpython/commit/5effd10bf14ab0a8a6695100aaf0b687eca68e6d

--

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 2bfc2dc214445550521074f428245b502d215eac by Victor Stinner 
(Zackery Spytz) in branch '2.7':
[2.7] bpo-37170: Fix the cast on error in PyLong_AsUnsignedLongLongMask() 
(GH-13860) (GH-13898)
https://github.com/python/cpython/commit/2bfc2dc214445550521074f428245b502d215eac


--

___
Python tracker 

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

[issue37170] Wrong return value from PyLong_AsUnsignedLongLongMask on PyErr_BadInternalCall

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Antti Haapala for the bug report and thanks Zackery Spytz for the fix!

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

[issue37197] [Idle-dev] Feedback appreciated for two suggested new features

[Irv Kalb]

New submission from Irv Kalb :

[I'm not sure of the proper protocol here, I hope sending a message this way is 
OK.]

Hi,

I am writing about the potential fix to the Search Dialog box problem in IDLE 
that I reported a while back.  I can see that there is a flurry of activity on 
this bug.  I saw that there was a code change, but since I have never looked at 
IDLE source code, I really cannot comment on the fix.

However, I did see comments that it might be difficult to reproduce, so I made 
a short video to clearly demonstrate the bug.  (This is on IDLE/Python 3.6.1 
Mac)  You can see it here:

http://www.youtube.com/watch?v=YWDsOEN8qsE 


I did not get a chance to test this out on Window, but the bug is easily 
reproducible on a Mac.

If the change is to leave the dialog box in front of the editing window, that 
would be be fine.  But long term, if it is possible to incorporate a search bar 
like the one in PyCharm, that would be even better.

Thanks for addressing the issue and I hope this video is helpful.

Irv

> On Jun 6, 2019, at 9:28 AM, Tal Einat  wrote:
> 
> After a great delay, I've created an issue[0] about the search dialogs being 
> hidden behind the main window, and have a PR[1] up with a proposed fix.
> 
> [0] https://bugs.python.org/issue37177 
> [1] https://github.com/python/cpython/pull/13869 
> 
> On Thu, Oct 18, 2018 at 8:13 PM Irv Kalb  > wrote:
> Hi,
> 
> I don't have a strong opinion about the details of the search and replace 
> dialogs.  However, I can tell you that a change replacing the dialog box 
> would be greatly appreciated.
> 
> I teach Python classes using IDLE.  The search dialog is a real a problem for 
> new students and me as the teacher.  My students and I often get into a 
> scenario where the search dialog gets hidden behind a editing window.  When 
> that happens, then you try to make edits in code and nothing happens.  This 
> happens to very often.  I have learned to look for the hidden search dialog 
> window, but my students get very flustered.
> 
> I think that a search bar would be a great improvement.  If you can model it 
> similar to the one in PyCharm, that would be wonderful.
> 
> Thanks for looking into this issue.
> 
> Irv
> 
> 
>> On Oct 13, 2018, at 2:51 PM, Tal Einat > > wrote:
>> 
>> Hi,
>> 
>> I've recently been working on two new features, for which I'd like to 
>> discuss whether it would be wise to include in IDLE. Each has a working 
>> implementation in a PR to make it easy to give it a try.
>> 
>> 1. Replace the search and replace dialogs with a search bar
>> https://bugs.python.org/issue34976 
>> https://github.com/python/cpython/pull/9855 
>> 
>> 
>> 2. Ability to run 3rd party code checkers
>> https://bugs.python.org/issue21880 
>> https://github.com/python/cpython/pull/9802 
>> 
>> 
>> Any thoughts would be greatly appreciated!
>> 
>> - Tal Einat
>> ___
>> IDLE-dev mailing list
>> idle-...@python.org 
>> https://mail.python.org/mailman/listinfo/idle-dev 
>> 
> 
> ___
> IDLE-dev mailing list
> idle-...@python.org 
> https://mail.python.org/mailman/listinfo/idle-dev 
> 

--
messages: 344963
nosy: IrvKalb, taleinat
priority: normal
severity: normal
status: open
title: [Idle-dev] Feedback appreciated for two suggested new features

___
Python tracker 

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

[issue37197] [Idle-dev] Feedback appreciated for two suggested new features

[SilentGhost]

SilentGhost  added the comment:

This seems to have been posted to bpo by mistake. I'm going to close this issue 
as a duplicate of #37177 and I would appreciate if you would send your e-mail 
to the idle-dev mailing list instead.

--
nosy: +SilentGhost
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: Search dialogs can be hidden behind the main window
type:  -> behavior

___
Python tracker 

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

[issue37191] Python.h contains intermingled declarations

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9689f80e61e5863668a562793ebb85031ef9fd3e by Victor Stinner (Petr 
Viktorin) in branch '3.8':
bpo-37191: Avoid declaration-after-statement in header included from Python.h 
(GH-13887)
https://github.com/python/cpython/commit/9689f80e61e5863668a562793ebb85031ef9fd3e


--

___
Python tracker 

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

[issue37198] _parse_localename fail to parse 'US_IL'

[hodai goldman]

New submission from hodai goldman :

_parse_localename fail to parse 'US_IL':

Traceback (most recent call last):
  File "/usr/bin/flowblade", line 78, in 
app.main(modules_path)
  File "/usr/share/flowblade/Flowblade/app.py", line 194, in main
translations.init_languages()
  File "/usr/share/flowblade/Flowblade/translations.py", line 39, in 
init_languages
lc, encoding = locale.getdefaultlocale()
  File "/usr/lib/python2.7/locale.py", line 545, in getdefaultlocale
return _parse_localename(localename)
  File "/usr/lib/python2.7/locale.py", line 477, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_IL


need to add another check for '_' separator, code:

if '.' in code:
return tuple(code.split('.')[:2])

--
messages: 344966
nosy: hodai goldman
priority: normal
severity: normal
status: open
title: _parse_localename fail to parse 'US_IL'
type: crash
versions: Python 2.7

___
Python tracker 

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

[issue37198] _parse_localename fail to parse 'US_IL'

[Michele Angrisano]

Michele Angrisano  added the comment:

Hi Hodai, thank you for the report.
Would you be interested to propose a Pull Request for this issue?

You can read the devguide for more informations.

Thank you. :)

--
nosy: +lemburg, mangrisano

___
Python tracker 

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

[issue37198] _parse_localename fail to parse 'en_IL'

[SilentGhost]

SilentGhost  added the comment:

How come your locale doesn't have encoding associated with it? The bit you're 
looking at is not really relevant, though.

--
components: +Library (Lib)
nosy: +SilentGhost
title: _parse_localename fail to parse 'US_IL' -> _parse_localename fail to 
parse 'en_IL'
type: crash -> behavior

___
Python tracker 

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

[issue15913] Add PyBuffer_SizeFromFormat() C helper for struct.calcsize()

[STINNER Victor]

Change by STINNER Victor :


--
title: PyBuffer_SizeFromFormat is missing -> Add PyBuffer_SizeFromFormat() C 
helper for struct.calcsize()
versions: +Python 3.9 -Python 3.6

___
Python tracker 

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

[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)

[Ned Deily]

Ned Deily  added the comment:

FWIW, it doesn't fail for me and I don't recall ever seeing a failure like this 
on macOS.  What hardware? ./python.exe -m test.pythoninfo please!

--
nosy: +ned.deily

___
Python tracker 

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

[issue37199] Test suite fails when Ipv6 is unavailable

[N.P. Khelili]

New submission from N.P. Khelili :

The test suite does not handle an OS that does not have IPv6.
When Linux kernel is started with argument:

ipv6.disable=1

The test suite fails. ( See attached file )

5 tests failed:
test_asyncio test_imaplib test_importlib test_socket test_zipapp

--
files: test_suite_fail.txt
messages: 344970
nosy: Nophke
priority: normal
severity: normal
status: open
title: Test suite fails when Ipv6 is unavailable
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48402/test_suite_fail.txt

___
Python tracker 

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

[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)

[Ned Deily]

Ned Deily  added the comment:

Also, what utime* results show up in ./configure output?  I see

checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes

--

___
Python tracker 

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

[issue37180] Fix Persian KAF in mac_farsi.py

[SilentGhost]

SilentGhost  added the comment:

Ramin, I agree with Victor, if you have any information contrary to what we 
posted, please feel free to post it here so that we can consider re-opening the 
issue.

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

___
Python tracker 

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

[issue37199] Test suite fails when Ipv6 is unavailable

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@

[STINNER Victor]

Change by STINNER Victor :


--
title: urlsplit doesn't accept a NFKD hostname with a port number -> 
CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@

___
Python tracker 

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

[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@

[STINNER Victor]

STINNER Victor  added the comment:

CVE-2019-10160 has been assigned by Red Hat to this flaw.

--

___
Python tracker 

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

[issue10915] Make the PyGILState API compatible with multiple interpreters

[Eric Snow]

Change by Eric Snow :


--
versions: +Python 3.9

___
Python tracker 

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