[issue43240] IDLE Classic Unix keyboard shortcuts broken

[Terry J. Reedy]

Terry J. Reedy  added the comment:

IDLE just tells tcl/tk via tkinter what function to call when particular UI 
events happen.  Recognizing UI events is handled between the OS window manager 
and tcl/tk. So I am sure this is not an IDLE issue.

For another application to affect the Linux-tcl interaction is new to me.  
Serhiy, have you ever heard of such a thing, or seen it happen?

--
nosy: +serhiy.storchaka
resolution:  -> third party
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

[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist

[Eryk Sun]

Eryk Sun  added the comment:

I left this open in case someone wants to modify shutil.copy() and 
shutil.copy2() to raise a less misleading exception when `dst` names a 
non-existing directory such as 'not_a_dir/'. Failing with IsADirectoryError 
(errno EISDIR) is confusing since shutil.copy() and shutil.copy2() do support a 
destination directory.

Note that in Windows this case fails with EINVAL, which is at least less 
misleading than EISDIR. The EINVAL error is based on WinAPI ERROR_INVALID_NAME 
(123). CreateFileW() can create a directory if passed particular parameters, in 
which case a trailing slash is allowed. Otherwise it fails with 
ERROR_INVALID_NAME (123), unless it's an open-existing disposition, in which 
case it fails with ERROR_FILE_NOT_FOUND (2). This is specified in [MS-FSA] 
2.1.5.1 [1]:

Phase 6 -- Location of file (final path component):

Search ParentFile.DirectoryList for a Link where Link.Name or
Link.ShortName matches FileNameToOpen. If such a link is found:

Set File = Link.File.
Set Open.File to File.
Set Open.Link to Link.

Else:

If (CreateDisposition == FILE_OPEN || CreateDisposition ==
FILE_OVERWRITE), the operation MUST be failed with
STATUS_OBJECT_NAME_NOT_FOUND.

Phase 7 -- Type of stream to open:

If PathName contains a trailing backslash:

If StreamTypeToOpen is DataStream or
CreateOptions.FILE_NON_DIRECTORY_FILE is TRUE, the operation
MUST be failed with STATUS_OBJECT_NAME_INVALID.

NTAPI STATUS_OBJECT_NAME_NOT_FOUND and STATUS_OBJECT_NAME_INVALID map to WinAPI 
ERROR_FILE_NOT_FOUND and ERROR_INVALID_NAME.

---
[1] 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/8ada5fbe-db4e-49fd-aef6-20d54b748e40

--
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.10, Python 3.8, 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

[issue43155] PyCMethod_New not defined in python3.lib

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +23336
pull_request: https://github.com/python/cpython/pull/24554

___
Python tracker 

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

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

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Thanks, Victor.

For PySequence_ITEM, I guess adding a private C version (for example 
_PySequence_Item) and redirecting the macro to the C version would be 
acceptable.

Ditto for PyHeapType_GET_MEMBERS and PyType_SUPPORTS_WEAKREFS.

--

___
Python tracker 

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

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

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
pull_requests: +23335
pull_request: https://github.com/python/cpython/pull/24553

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

[STINNER Victor]

STINNER Victor  added the comment:

> builds a 31/32 bit Python 3.10 on an s390x system.

What is the use case or benefit of building Python for 32-bit rather than 
64-bit?

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> For PyExceptionClass_Name: Is it ok to just remove the macro version (like 
> with GH-24548)?

Yes, I think so.

--

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's 
> multilib support in a similar manner that I've mentioned about RHEL7?

I work at SUSE. I looked at the internal build system. Debian also still build 
s390 multilib libraries, i.e. on zelenka.debian.org, I can still install 
"libc6-s390".

And I still don't understand why you are so keen at keeping people from 
building Python 3.10 on a certain architecture. You don't gain anything by 
removing these few lines of codes. But you risk at making someone unhappy who - 
for whatever reason - builds a 31/32 bit Python 3.10 on an s390x system.

--

___
Python tracker 

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

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

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

For PyExceptionClass_Name: Is it ok to just remove the macro version (like with 
GH-24548)?

--

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

[STINNER Victor]

Change by STINNER Victor :


--
title: Remove 32-bit s390 Linux support (s390-linux-gnu triplet) -> Remove 
31/32-bit s390 Linux support (s390-linux-gnu triplet)

___
Python tracker 

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

[issue43233] test_os: test_copy_file_range_offset fails on FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:

AMD64 FreeBSD Shared 3.x is also affected:
https://buildbot.python.org/all/#/builders/483/builds/813

FAIL: test_copy_file_range_offset (test.test_os.FileTests)

--
title: test_copy_file_range_offset fails on AMD64 FreeBSD Shared 3.9 -> 
test_os: test_copy_file_range_offset fails on FreeBSD CURRENT
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

[issue43240] IDLE Classic Unix keyboard shortcuts broken

[Alan Moore]

Alan Moore  added the comment:

OK, it seems that closing all my firefox windows restored correct behavior to 
IDLE.  I can only guess that somehow firefox was eating the Ctrl-x.

Not sure if this is a firefox issue, a window manager issue, or an IDLE issue.  
If you think it's not the latter, feel free to close.

--

___
Python tracker 

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

[issue43236] Windows IDLE taskbar icon jump list fails to open recent files

[Ned Deily]

Ned Deily  added the comment:

> Ned, do you have any comments, pro or con, about doing so.

I don't think there is a conflict here and I don't really have an opinion as I 
don't use Windows regularly. From a bit of web research, it looks like the 
closest thing to Windows jump lists on macOS are control-clicking on an app 
icon (like IDLE.app) in the dock which then may show some recent files used 
with the app. As you note, IDLE's recent file list is also available, a good 
cross-platform choice.

--

___
Python tracker 

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

[issue39093] tkinter objects garbage collected from non-tkinter thread cause crash

[John Rouillard]

John Rouillard  added the comment:

Sorry for the spam, but there is no silent post setup for this tracker.

On https://github.com/python/psf-infra-meta/issues/74 in July E-paine reports 
that he can't post to this issue. I just created an account linked to github to 
see if I am able to post.

--
nosy: +rouilj

___
Python tracker 

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

[issue43240] IDLE Classic Unix keyboard shortcuts broken

[Alan Moore]

New submission from Alan Moore :

Using IDLE 3.9.1 on Arch Linux.

In IDLE I've selected the "classic unix" key set.  It worked for a while, then 
stopped registering key combinations for more than one key (e.g. Ctrl-x Ctrl-s).

Have tried creating a custom key set and manually setting the shortcuts, but it 
still fails the same way.  Caps lock is not on (disabled on my system).

Have also tried moving configs and starting fresh, does not help.

It had been working, then suddenly stopped in the middle of a work day and I 
can't get it working again.

--
assignee: terry.reedy
components: IDLE
messages: 387124
nosy: Alan Moore, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE Classic Unix keyboard shortcuts broken
type: behavior
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

[issue43236] Windows IDLE taskbar icon jump list fails to open recent files

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Eryk, thank you for the research.   Our macOS installer already adds an 
'idlex.y' executable.  Ned, do you have any comments, pro or con, about doing 
so.

(I worry a bit about reinforcing the beginner delusion that IDLE is Python or 
that IDLE executes Python code.  But this appears to already be as common for 
Windows beginners as for Mac beginners.)

--
nosy: +ned.deily

___
Python tracker 

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

[issue43239] PyCFunction_New is not exported with PyAPI_FUNC

[Petr Viktorin]

Petr Viktorin  added the comment:

> By the way, I would suggest to move "#define PyCFunction_New(ML, SELF) 
> PyCFunction_NewEx((ML), (SELF), NULL)" to Include/cpython/methodobject.h 

Wait no, I wrote too soon.
PyCFunction_NewEx is part of the limited API as well, even though it's 
undocumented. People can call it.

--

___
Python tracker 

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

[issue43239] PyCFunction_New is not exported with PyAPI_FUNC

[Petr Viktorin]

Petr Viktorin  added the comment:

> By the way, I would suggest to move "#define PyCFunction_New(ML, SELF) 
> PyCFunction_NewEx((ML), (SELF), NULL)" to Include/cpython/methodobject.h 

OK, I'll add that move to the PR.

> Oh, it's not listed by Doc/data/stable_abi.dat and so not checked by 
> Tools/scripts/stable_abi.py.

I'm planning to rework this for PEP 652 (which is how I found the issue in the 
first place), so I'll not add it there now.

--

___
Python tracker 

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

[issue43239] PyCFunction_New is not exported with PyAPI_FUNC

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

[issue43239] PyCFunction_New is not exported with PyAPI_FUNC

[STINNER Victor]

STINNER Victor  added the comment:

Oh, it's not listed by Doc/data/stable_abi.dat and so not checked by 
Tools/scripts/stable_abi.py.

It's implemented explicitly as a function only for the stable ABI:

PyObject *
PyCFunction_New(PyMethodDef *ml, PyObject *self)
{
return PyCFunction_NewEx(ml, self, NULL);
}

So yeah, it should be exported.

By the way, I would suggest to move "#define PyCFunction_New(ML, SELF) 
PyCFunction_NewEx((ML), (SELF), NULL)" to Include/cpython/methodobject.h to 
clarify that the limited C API should call "PyCFunction_New()" and not call 
"PyCFunction_NewEx()".

--
nosy: +vstinner

___
Python tracker 

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

[issue43239] PyCFunction_New is not exported with PyAPI_FUNC

[Petr Viktorin]

New submission from Petr Viktorin :

PyCFunction_New is part of the Stable ABI (see bpo-21354), but it is not 
declared as PyAPI_FUNC, and thus not exported with GCC's -fvisibility=hidden.
To match Windows, it should be declared.

(I don't think this has any real impact, I just want to fix it before enabling 
automatic tests on such issues.)

--
assignee: petr.viktorin
components: C API
messages: 387119
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: PyCFunction_New is not exported with PyAPI_FUNC
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

[issue23903] Generate PC/python3.def by scraping headers

[Petr Viktorin]

Petr Viktorin  added the comment:

I plan to do this slightly differently, see PEP 652.

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Eryk Sun]

Eryk Sun  added the comment:

Can't there be a library named "libc" with the shared module "liblibc.so"? It 
seems to me that the _is_elf() function added in issue 41976 is breaking the 
contract that "[i]f no library can be found, returns None". It's not supposed 
to leak arbitrary exceptions from the implementation if the library isn't found.

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[STINNER Victor]

STINNER Victor  added the comment:

The documentation is explicit: you must not include the "lib" prefix.
https://docs.python.org/dev/library/ctypes.html#ctypes.util.find_library

See also examples:
https://docs.python.org/dev/library/ctypes.html#finding-shared-libraries

If it worked with "lib" prefix in Python 3.8, it wasn't on purpose.

You should fix your code, but Python works as expected. I close the issue.

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

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset cc54001c2eb3b14320c1667b22602d69c90d5865 by Erlend Egeberg 
> Aasland in branch 'master':
> bpo-40170: Always define PyIter_Check() as a function (GH-24548)

For macOS which doesn't use LTO compiler optimization, we added private static 
inline functions of some "Check" functions. But I don't think that it's worth 
it here (I don't think that the function is commonly called in "hot code").

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:


New changeset cc54001c2eb3b14320c1667b22602d69c90d5865 by Erlend Egeberg 
Aasland in branch 'master':
bpo-40170: Always define PyIter_Check() as a function (GH-24548)
https://github.com/python/cpython/commit/cc54001c2eb3b14320c1667b22602d69c90d5865


--

___
Python tracker 

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

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

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

> s390 is being built for SLE-12, for example, on the internal SUSE build 
> system and SLE-12 is still supported. So if a customer wants to use Python 
> 3.10 in a SLE-12 s390 environment, why keep them from doing so?

Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's 
multilib support in a similar manner that I've mentioned about RHEL7?

--

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[Nicholas Sim]

Change by Nicholas Sim :


--
pull_requests: +2
pull_request: https://github.com/python/cpython/pull/24550

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Vadym Stupakov]

Vadym Stupakov  added the comment:

I mean, find_library relies on gcc linker, when you pass library name to the 
linker, it automatically ads "lib" prefix to the library
so, when you pass "libc", linker ads "lib" so u have an error with "liblibc" 
name.

just man ld and see "-l" option:

"
-l namespec
   --library=namespec
   Add the archive or object file specified by namespec to the
   list of files to link.  This option may be used any number of
   times.  If namespec is of the form :filename, ld will search
   the library path for a file called filename, otherwise it
   will search the library path for a file called libnamespec.a.
"

as you can see, you pass not a library name, but a "namespec"
which then transforms to "libnamespec"

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Vadym Stupakov]

Vadym Stupakov  added the comment:

> ctypes.util.find_library("libc") used to work in 3.8, not working in 3.9. As 
> I said before, ctypes.util.find_library("c") works in both 3.8 and 3.9.

no, it doesn't work (and it shouldn't) neither in python 3.8 nor 3.7

Python 3.8.5 (default, Sep  4 2020, 07:30:14) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.19.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ctypes.util
In [2]: a = ctypes.util.find_library("libc")
In [3]: print(a)
None

Python 3.7.6 (default, Jan  8 2020, 19:59:22) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.16.1 -- An enhanced Interactive Python. Type '?' for help.
Python 3.7.6 (default, Jan  8 2020, 19:59:22) 

import ctypes.util
a = ctypes.util.find_library("libc")
print(a)
None

as I said, adding prefix "lib" is wrong

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Eryk Sun]

Eryk Sun  added the comment:

Issue 41976 added ctypes.util._is_elf() to filter out linker scripts such as 
"libc.so". The PR was backported to 3.7. _is_elf() assumes the trace result has 
absolute paths that can be opened, but Matthias is getting the relative 
filename "liblibc.a" in the result. Whatever the reason, I think if the file 
can't be opened for reading, then _is_elf() should just return False. For 
example:

def _is_elf(filename):
"Return True if the given file is an ELF file"
elf_header = b'\x7fELF'
try:
with open(filename, 'br') as thefile:
return thefile.read(4) == elf_header
except OSError:
return False

--
nosy: +eryksun

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Matthias Klose]

Matthias Klose  added the comment:

ctypes.util.find_library("libc") used to work in 3.8, not working in 3.9. As I 
said before, ctypes.util.find_library("c") works in both 3.8 and 3.9.

--

___
Python tracker 

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

[issue41282] Deprecate and remove distutils

[Lumír Balhar]

Change by Lumír Balhar :


--
pull_requests: +23332
pull_request: https://github.com/python/cpython/pull/24549

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Vadym Stupakov]

Vadym Stupakov  added the comment:

So, can we close it?

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[STINNER Victor]

STINNER Victor  added the comment:

Oh right, I always use find_library("c"), not find_library("libc").

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Vadym Stupakov]

Vadym Stupakov  added the comment:

Note, that adding "lib" prefix to any library is wrong, that's why it returns 
"None" or raises the exception.

And it works fine when you call find_library("c")

I guess the issue, that was reported here, is about raising and exception 
instead of returning "None", but not about finding library, isn't it?

--

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 17dbd4078b68db8954df6b5cdc40b786bc4ad7af by Nicholas Sim in 
branch 'master':
bpo-35134, Include: Move pytime.h to cpython/pytime.h (GH-23988)
https://github.com/python/cpython/commit/17dbd4078b68db8954df6b5cdc40b786bc4ad7af


--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[STINNER Victor]

STINNER Victor  added the comment:

> _findLib_gcc() uses "gcc -Wl,-t -o tmp -lc" command and search for "lib" in 
> the created "tmp" file.

Oh, it looks for the "lib" in the process stdout (not in the created "tmp" 
file).

--

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[STINNER Victor]

STINNER Victor  added the comment:

This function is quite complicated on Linux:

def find_library(name):
# See issue #9998
return _findSoname_ldconfig(name) or \
   _get_soname(_findLib_gcc(name)) or 
_get_soname(_findLib_ld(name))

_findSoname_ldconfig() uses "/sbin/ldconfig -p" and searchs for 'libc6,x86-64' 
in the output (on x86-64).

_findLib_gcc() uses "gcc -Wl,-t -o tmp -lc" command and search for "lib" in the 
created "tmp" file.

_findLib_ld() uses "ld -t -lc" command and searchs for "lib" pattern.

The exact code is more complicated :-) You should debug this issue by running 
these commands manually on Debian.

Note: python3.9 -c 'import ctypes.util; print(ctypes.util.find_library("c"))' 
commands displays libc.so.6 with Python 3.8, 3.9 and 3.10 on Fedora. I cannot 
reproduce the issue on Fedora 33 (x86-64).

--
nosy: +vstinner

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[RedEyed]

RedEyed  added the comment:

can't reproduce

(py39) ➜  ~ ipython 
Python 3.9.1 (default, Dec 11 2020, 14:32:07) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ctypes.util
In [2]: a = ctypes.util.find_library("libc")
In [3]: print(a)
None

--
nosy: +RedEyed

___
Python tracker 

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

[issue43175] filecmp is not working for UTF-8 BOM file.

[Eryk Sun]

Eryk Sun  added the comment:

The two files in "files.zip" have the same contents:

>>> open('source.css', 'rb').read() == open('destination.css', 'rb').read()
True

Maybe there's something peculiar about the stat results. Check that they're 
both reported as regular files with the same size:

import os
for f in ('source.css', 'destination.css'):
print(f, os.path.isfile(f), os.path.getsize(f))

--
nosy: +eryksun

___
Python tracker 

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

[issue43237] datetime.__eq__ returns true when timezones don't match

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

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

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
pull_requests: +23331
pull_request: https://github.com/python/cpython/pull/24548

___
Python tracker 

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

[issue43237] datetime.__eq__ returns true when timezones don't match

[Mark Dickinson]

Mark Dickinson  added the comment:

Hi Richard. Thanks for the report. Python's working as designed (and as 
documented and tested) here. IOW, the behaviour is deliberate - this isn't a 
bug.

Any change in behaviour would have to target 3.10 at the earliest (and it's 
already quite late in the release process for 3.10). A couple of questions: (1) 
what would you want the comparisons `datetime_in_sgt <= datetime_in_utc` and 
`datetime_in_utc <= datetime_in_sgt` to give? (2) How would you propose to 
change the behaviour without breaking existing code that makes use of the 
current behaviour?

> This is confusing and non-intuitive.

That's a rather subjective judgement. I'd personally find the behaviour you 
suggest non-intuitive (and I find the behaviour of Java's order comparisons on 
ZonedDateTime to be highly non-intuitive). We'd need something a bit more 
objective and/or widely supported to justify a behaviour change.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue43238] python picking garbage values randomly incase running palindrome function

[Mark Dickinson]

Mark Dickinson  added the comment:

Hi Raghav.

I think you think you're found a bug in Python, but I'm afraid it's difficult 
to tell from your report what you think that bug is. Please state clearly what 
you did, what you expected to happen (and why), and what actually happened. You 
may find this article useful: 
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

You might also consider asking for help on user forums. It's much more likely 
that any surprising behaviour you're seeing here is due to a bug in your code 
rather than in Python itself.

--
components:  -Windows
nosy: +mark.dickinson -paul.moore, rv.raghav23, steve.dower, tim.golden, 
zach.ware
resolution:  -> not a bug
status: open -> pending

___
Python tracker 

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

[issue43236] Windows IDLE taskbar icon jump list fails to open recent files

[Eryk Sun]

Eryk Sun  added the comment:

The IDLE shortcut that's installed by the development distribution runs 
`"\pythonw.exe" "\Lib\idlelib\idle.pyw"`. 
Thus opening a file that's pinned to the jumplist will execute it as a script 
via "pythonw.exe". 

To integrate better with the Windows shell, IDLE would need its own executable. 
Moreover, AFAICT, it isn't enough to use a launcher that executes 
"pythonw.exe", such as a distlib launcher installed by pip for an entrypoint 
script. Using a launcher disassociates the executable that the shell runs to 
open a file from the application that creates the UI. It needs to be a simple C 
application that hard codes executing the idlelib module, similar in spirit to 
what's implemented in PC/python_uwp.cpp for the store app. I created a test app 
that implements this, and I can confirm that pinned and recent files in the 
jumplist open as desired in IDLE.

The development distribution would install the new binary (e.g. "idle3.10.exe") 
in the installation directory beside the DLL. That's the simplest way to link 
with the interpreter DLL and find the standard library. The IDLE shortcut 
target and "Edit with IDLE" command would be updated to use the new executable 
instead of "pythonw.exe".

--
nosy: +eryksun

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> s390 is being built for SLE-12, for example, on the internal SUSE build 
> system and SLE-12 is still supported. So if a customer wants to use Python 
> 3.10 in a SLE-12 s390 environment, why keep them from doing so?

I don't think that SuSE plans to provide Python 3.10 on SLE-12.

cc @mcepl

--
nosy: +mcepl

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> This thread is an excellent example why ignoring platforms comes at a cost. 
> It will only get worse when are going to introduce platform and architecture 
> specific code for optimizations and features.

Which is purely hypothetical at the moment. You are arguing with something that 
might happen in the future but currently doesn't exist to justify the removal 
of 5 lines of preprocessor and autoconf "code".

You can still drop these lines in the future _if_ they happen to cause any 
headache. But that is currently not the case, so there isn't really a burden.

>> You can view test results any time by going to https://buildd.debian.org/ 
>> and searching for "pythonX.Y". So there is actually a CI for release builds.

> The site does not list a s390 builder. There is only a s390x builder.

s390 is being built for SLE-12, for example, on the internal SUSE build system 
and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a 
SLE-12 s390 environment, why keep them from doing so?

In my experience some upstream projects make the mistake that they think they 
always know how users are using their software. But since there is no dedicated 
feedback channel, you have no means in knowing whether someone is building 
Python for a given architecture for their custom project. After all, there are 
source-only distributions like Gentoo, so you don't have to rely on any 
existing binary builds.

--

___
Python tracker 

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

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

[Christian Heimes]

Christian Heimes  added the comment:

> You don't need to support a platform. Just call it unsupported and ignore 
> issues if people report them unless they provide a patch themselves.

This thread is an excellent example why ignoring platforms comes at a cost. It 
will only get worse when are going to introduce platform and architecture 
specific code for optimizations and features.

> You can view test results any time by going to https://buildd.debian.org/ and 
> searching for "pythonX.Y". So there is actually a CI for release builds.

The site does not list a s390 builder. There is only a s390x builder.

--

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> So IMO it's fine to remove the support.

You are not removing "support". You're just disallowing users to use the Python 
interpreter - which works perfectly fine on all architectures we have in 
current and previous releases - on Debian.

A few preprocessor macros plus some lines in a configure.ac aren't something 
that would qualify as platform support. There is no architecture-specific code 
and the Python interpreter is highly portable and just works whereever we build 
it in Debian (and openSUSE).

I would unterstand the reasoning of such a change if there was a swath of users 
filing bug reports about s390 and you just don't want to deal with that any 
longer. But that's not the case as far as I can see.

--

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> The guidelines for platform support are explained in PEP 11 
> (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't 
> support platforms unless we have maintainers and CI (builtbots) in place for 
> the platform.

You don't need to support a platform. Just call it unsupported and ignore 
issues if people report them unless they provide a patch themselves.

FWIW, the Python interpreter has never caused any issues on any platform that 
we support in Debian. We are regularly building the latest upstream versions of 
all available Python interpreters thanks to the packaging work of Matthias 
Klose.

You can view test results any time by going to https://buildd.debian.org/ and 
searching for "pythonX.Y". So there is actually a CI for release builds.

--

___
Python tracker 

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