Ronald Oussoren added the comment:
Should we add documentation about this?
The truly annoying bit about that discussion is that its probably easier to
just install gdb and use that to debug extensions.
--
___
Python tracker
<ht
New submission from Ronald Oussoren :
Py_GenericAlias seems to be a public API given its name and is mention in the
stable ABI list for 3.10
(https://docs.python.org/3.10/c-api/stable.html?highlight=py_genericalias), but
the API is not documented.
Likewise for Py_GenericAliasType
Ronald Oussoren added the comment:
I'm not working on this. Feel free to work on a PR.
--
___
Python tracker
<https://bugs.python.org/issue44392>
___
___
Ronald Oussoren added the comment:
Why should this be deprecated at all?
The API is a convenient way to add ``__class_getitem__`` in a way that is
consistent with the implementation for builtin types and the stdlib.
I noticed the lack of documentation when I worked on implementing this for
Ronald Oussoren added the comment:
I guess Ned and I are the only core devs that would be vaguely interested in
working on this. I have no active plans to work on this.
Having a relocatable framework would be nice, but doing this in a way that
maintains all functionality, esp. w.r.t. the
Ronald Oussoren added the comment:
As mentioned on the PR:
Support for OSF1 was removed in Python 3.3 (see
https://www.python.org/dev/peps/pep-0011/#unsupporting-platforms).
I expect that there will be little interest amongst the core developers for
reintroducing support because OSF1 is an
Ronald Oussoren added the comment:
IMHO the most important question to answer first is: Why is adding OSF1 support
a good idea?
The PR, which IMHO in its current state is not mergeable, adds some complexity
to the build and ongoing maintenance of CPython itself. This tends to be
Ronald Oussoren added the comment:
Without having looked at this issue in detail...
This looks like an issue with macOS and not Python. In general API's providing
access to system calls are just thin wrappers around those system calls. If
this is a bug in macOS there's nothing
Ronald Oussoren added the comment:
The problem with moving from Catalina to Big Sur is a known issue, AFAIK
there's an open issue for this.
The problem is that Big Sur moved system libraries into a big blob (which Apple
calls the shared library cache). Ctypes uses an API that's ne
Ronald Oussoren added the comment:
Anyways, the solution for "build on older macOS version, deploy to Big Sur" is
to dynamically look for the relevant API (``_dyld_shared_cache_contains_path``)
and use it when available. But only in that scenario, the current code path
using exp
Ronald Oussoren added the comment:
The disadvantage of using dlopen is that this function has side effects, and
those can affect program behaviour. Because of this I'm against switching to
using dlopen to probe for libraries.
--
___
P
Ronald Oussoren added the comment:
The problem is related to recursion, the code basically ends up with an
unlimited number of iterations of select.select and test_select_mutated on the
call stack and this doesn't trigger the stack depth checker.
The following definition of class F tri
Ronald Oussoren added the comment:
The output from the print statement in the finally block is before the
traceback, you need to scroll back in the output buffer in VS Code.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.
Ronald Oussoren added the comment:
This is no longer relevant now that distutils is deprecated.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Ronald Oussoren added the comment:
Note that importlib.import_module, and the import statement itself, can raise
an arbitrary exception when that exception is raised while executing the module
body.
This is easily observed by creating a module that just raises an error in its
body:
# t.py
Ronald Oussoren added the comment:
I'm afraid we cannot do a lot with the information you provided. I've just ran
a full test run for a copy of 3.10rc1 installed using the universal2 installer
and that doesn't have problem.
One way to find more information about what'
Ronald Oussoren added the comment:
Good question. Hopefully one of the documentation or importlib experts can
chime in about that. I may also have uncovered a new issue in importlib ;-)
Personally I'd say that documenting raising ImportError is still useful because
that's
Ronald Oussoren added the comment:
There is a 3th possibility: This could be a bug in the OS, Monterey is still in
beta at this point and beta's tend to contain more bugs than release versions.
--
___
Python tracker
<https://bugs.py
Ronald Oussoren added the comment:
I'm not sure what your question is. But to enable the hardened runtime you need
to sign the binaries using ``--options runtime`` as one of the options.
--
___
Python tracker
<https://bugs.python.org/is
Ronald Oussoren added the comment:
I don't know what creates "python3.9-intel64", but this is not created by the
regular Python build process. It might be created by one of the build scripts
you use.
--
___
Python
Ronald Oussoren added the comment:
According to https://man7.org/linux/man-pages/man2/getrlimit.2.html there is no
RLIMIT_VMEM on linux, RLIMIT_AS is the closest equivalent.
--
nosy: +ronaldoussoren
resolution: -> not a bug
stage: -> resolved
status: open -&g
New submission from Ronald Oussoren :
The requirements on a freezing tool to work with the freeze support in the
multiprocessing library are unclear.
In particular, I'm trying to support multiprocessing in py2app and cannot rely
on the documentation to implement that support.
The parti
Ronald Oussoren added the comment:
Note that sqlite3_enable_load_extension was unavailable way before macOS
11.5.1, the symbol is not present on 10.15 (I used 'nm
/usr/lib/libsqlite3.dylib' to check for symbol availability).
Just checking for MACOS and a system include directory
Ronald Oussoren added the comment:
@ned: the "reliable way to run under rosetta" is using "arch -x86_64 python3".
I don't particularly like having another executable to accomplish the same goal.
--
___
Python tracker
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue45020>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
You stripped too much output from the build, in particular you removed the part
where _curses failed to build. The output you show only says that _cursus_panel
failed verification because _cursus could not be imported.
Could you add the build failure for
Ronald Oussoren added the comment:
I agree that this would be nice to have, but wonder how help() could access
that information. The two @overload definitions will be overwritten by the
non-overload one at runtime, and hence will ever been seen by help().
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
According to https://invisible-island.net/ncurses/NEWS.html#index-t20170401 the
function extended_color_content was introduced in 2017, maybe the detection of
support for this function doesn't work properly for some reason (although the
preprocessor
New submission from Ronald Oussoren :
The symbol _Py_DecodeUTF8_surrogateescape is not exported from Python.framework
on macOS in Python 3.10. The symbol was exported in earlier versions of 3.x.
I'm not sure if this was intentional, so far I haven't been able to find when
this w
Ronald Oussoren added the comment:
I've switched py2app to Py_DecodeLocale, which is a public API introduced in
3.5 to accomplish the same task.
I'm leaving the issue open in case hiding the symbol is unintentional.
--
___
Python track
Ronald Oussoren added the comment:
@Steven: the difference between indexing and the repr of list() is also
explained by Eryk's explanation.
s = ... # (value from msg401078)
for x in repr(list(s)):
print(x)
The output shows characters in the expected order.
--
New submission from Ronald Oussoren :
The attached file demonstrates the problem:
If importlib.invalidate_caches() is called while the zipfile used by the zip
importer is not available the import system breaks entirely. I found this in a
testsuite that accedently did this (it should have
Change by Ronald Oussoren :
--
nosy: +pablogsal, twouters
___
Python tracker
<https://bugs.python.org/issue45183>
___
___
Python-bugs-list mailing list
Unsub
Change by Ronald Oussoren :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue45183>
___
___
Python-bugs-list mailing list
Unsubscrib
Ronald Oussoren added the comment:
I just noticed that I'm unnecessarily obtuse in my description of a possible
fix, the diff (without test update):
% git diff Lib/zipimport.py
(main)cpython
diff --
Ronald Oussoren added the comment:
I'd expect that there'd be at least one instance of X alive due to
sys.last_value and in particular sys.last_traceback (which has a reference to
the stack frame which contains references to local variables).
Btw. I cannot reproduce this with Py
Ronald Oussoren added the comment:
I'm not sure what the issue is here. ZipInfo does not have a filemode
attribute, that's why it is not in ZipInfo.__slots__.
That said, it might be interesting to add a property to ZipInfo that extracts
the file mode from ZipInfo.ext
Ronald Oussoren added the comment:
The documentation for the SIG* constants also mentions:
SIG*
All the signal numbers are defined symbolically. For example, the hangup signal
is defined as signal.SIGHUP; the variable names are identical to the names used
in C programs, as found in
Ronald Oussoren added the comment:
The error in the attached file says that one of the dependencies could not be
found, in particular the "packaging" library.
This doesn't look like a bug in CPython or pip, but more a general support
question. I kindly ask you to visit on
Ronald Oussoren added the comment:
The repr() output of a ZipInfo contains filemode, but it is not an attribute of
those objects, see
<https://docs.python.org/3/library/zipfile.html#zipinfo-objects> for a list of
attributes and methods.
Adding an @property for mode that extracts th
Ronald Oussoren added the comment:
Marc, thanks for the update.
Will there be a Tcl/Tk release soonish that includes this fix?
Alternatively, is there patch that we can apply to the latest release when
building the copy of Tk included with the installers
Ronald Oussoren added the comment:
The most straightforward change for macOS is to add “pyi” to the list of
extensions in “Mac/IDLE/IDLE.app/Contents/Info.plist”. That way IDLE will be
seen as a valid editor for .pyi files.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
Are you using macOS 12 (Monterey)?
I get an error as well using that version of the OS (see open-error). The error
happens within a second or two after opening the open dialog, without
interacting with the dialog in any way. This is on an M1 laptop running
Ronald Oussoren added the comment:
> Heads up! A strange Apple quirk has been identified which could affect the
> file dialog behavior if the Tk library is compiled on macOS 10.XX and used on
> macOS 11 or 12. (I am not sure if this applies here.)
I'm pretty sure that&
Ronald Oussoren added the comment:
> Where do you think that "feature" is documented?
I'd have to check, but I didn't learn this from Twitter, although it wouldn't
surprise me if I learned this from a WWDC talk.
The beta for Big Sur never identified itself as 1
Ronald Oussoren added the comment:
1) __APPLE_USE_RFC_3542 should have been in socketmodule.c from the start, not
sure why it was added in setup.py.
2) as you and Ned noticed -search_paths_first has been the default for a long
while, we can just drop it and anyone building on ancient
Ronald Oussoren added the comment:
dbm_open is in libc on macOS. likely due to being in SUSv2.
The implementation in libc appears to be suboptimal (for example: issue33074),
although I wouldn't teach configure.ac to ignore the system version of the
library.
--
nosy: +ronaldous
Ronald Oussoren added the comment:
Please include reproducer code in the issue itself, not on some external side.
That said, the error you're getting is related to the start method used by
multiprocessing. On Linux the start method is fork, on macOS (and Windows) the
start method is
Ronald Oussoren added the comment:
I'm assuming you run on a M1* system.
What's the architecture for the python binary (run "file $(which python3)" in a
shell to get this information, excluding the quotes)?
If the binary supports only x86_64 you might run into
Ronald Oussoren added the comment:
The problem will go away when you install and use an arm64 or universal2
variant of Python.
This is behaviour of macOS and cannot be changed in CPython.
--
resolution: -> third party
stage: -> resolved
status: open -&g
Ronald Oussoren added the comment:
IMHO your code is buggy, as Hai Shi also indicates.
After Py_Finalize all objects in all (sub-)interpreters are deallocated unless
there are bugs in the interpreter. Because of this "..., item should still be
alive" in your sample code is inco
Ronald Oussoren added the comment:
Could you check with "curl -k https://pypi.org/ >/dev/null" what certificate is
used by PyPI?
On my system I get (amongst other output):
...
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Serve
Ronald Oussoren added the comment:
This would definitely be a new feature and not something that can be back
ported.
That said, I don't understand why it is desirable to use a Path as the match
argument. That argument is a glob pattern (such as "*.py") and not a file name .
Ronald Oussoren added the comment:
Match doesn't match paths, but basically does a regular expression match on the
textual representation (using glob syntax instead of normal regular expression
syntax).
Because of this I don't agree with your idea that anything that can match a
Ronald Oussoren added the comment:
I'm not sure what your code tries to accomplish, does it check that
``f.parent`` refers to the same location as ``ref_file``? A clearer solution
for that would be ``f.parent.resolve() == ref_file.resolve()``.
The argument to match, glob and
Ronald Oussoren added the comment:
I don't think our opinions about this will converge, I'm therefore leaving this
discussion.
>> would ``Path("dir/some.py").match(Path("*.py"))`` return?
>
> str(Path("*.py")) == "*.py"
>
>
Ronald Oussoren added the comment:
The default behaviour of functions is to not steal references, in general only
exceptions to this are documented. Likewise with return values: by default the
result is a strong reference, and borrowed references are documented as such.
--
nosy
Ronald Oussoren added the comment:
The reproducer script and .c file I added earlier do not fail with "Cannot
allocate memory" on macOS 12.0.1.
I haven't checked yet if this is enough to avoid test failures in the (now
skipped)
Ronald Oussoren added the comment:
Is arch corei7-avx compatible with your CPU? One way to test is to leave out
-mtune=... and -march=... when building python.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue45
New submission from Ronald Oussoren :
The documentation for PyType_Spec and the related functions is not clear about
the required lifetime of fields of PyType_Spec.
In particular, PyType_Spec.name must remain valid for the entire lifetime of
types created with PyType_FromSpec*. The
Ronald Oussoren added the comment:
I just noticed this duplicates #45315, sorry about the noise.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> `PyType_FromSpec` does not copy the name
___
Py
New submission from Ronald Oussoren :
There are two ways to develop against a Python.framework on MacOS:
1. Use the regular Unix pattern with "#include "Python.h", using compiler flags
to select the right headers and libraries.
2. Using the native framework pattern with
Ronald Oussoren added the comment:
I don't think this is a bug. The value's in the plutil output are correct, and
marked up with the correct type in both cases.
The difference between 0.1 and 0.10001 is the usual problem with
floating point representation (see the
Ronald Oussoren added the comment:
As you noted /dev/log doesn't exist on macOS (the correct path is
/var/run/syslog).
I guess the change that would be most in spirit of the comment is to set
self.socket to None when the socket cannot be opened and test for that before
closing the s
Ronald Oussoren added the comment:
You only have to check, using a public API, if you have no control over when
C++ objects are destructed. I'd personally try to structure code to make sure
that C++ objects owning references to Python objects get destructed before the
interpret
Ronald Oussoren added the comment:
The relevant API on macOS is [f]copyfile(3) which is at the POSIX layer. The
copyFile API linked to in msg357395 is a higher-level ObjC/Swift API.
Using the copyfile(3) API has another advantage beyond this issue: This API can
perform a clone action on
Ronald Oussoren added the comment:
In what way does it not work when using a framework build? Is this when you add
the python framework to an (Xcode) project and include the main python header
using "#include "?
--
___
Python track
Ronald Oussoren added the comment:
Looks like expected behaviour, the attached file is an incomplete compressed
file that does not seem to contain data (according to gzcat)
gzcat: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4:
unexpected end of file
gzcat: crash
Ronald Oussoren added the comment:
The stdlib documentation does in general not contain exhaustive documentation
on exceptions that might be raised.
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python trac
Ronald Oussoren added the comment:
You don't even need a C program to reproduce:
$ cd /private/tmp
$ touch ../../foo.txt
touch: ../../tmp/foo.txt: No such file or directory
And the "cd" is optional, I get the same error from my home directory
(/Users/ronald).
All of this o
Ronald Oussoren added the comment:
An additional question: what version of macOS are you using?
--
___
Python tracker
<https://bugs.python.org/issue39
Ronald Oussoren added the comment:
The other locale related settings are off as well, the default system locale
ends with ".UTF-8".
--
___
Python tracker
<https://bugs.python.o
Ronald Oussoren added the comment:
I agree with deprecating binhex.
--
___
Python tracker
<https://bugs.python.org/issue39353>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
>From the screenshot:
>>> b = ['sss', 'ase', 'klm', 'qwe']
>>> print sorted(b)
['ase', 'klm', 'qwe', 'sss']
This is the correct result, the output li
Ronald Oussoren added the comment:
issue39684 has a PR for this.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue39690>
___
___
Pytho
Ronald Oussoren added the comment:
I'm fairly sure support for .pyw, or rather a separate python executable, was
introduced in the MacOSX port. In particular, we started out with two different
executables "python" and "pythonw" where the first was the regular pyth
Ronald Oussoren added the comment:
Note that IDLE.app sets the current working directory to ~/Documents to have a
sane working directory (and hence sane behavior in file dialogs), by default
app bundles on macOS are launched with the root directory as the current
working directory.
For
Ronald Oussoren added the comment:
What version of macOS are you on? And which compiler do you use?
--
___
Python tracker
<https://bugs.python.org/issue39
Ronald Oussoren added the comment:
Note that the implementation of np_bool in _struct.c [1] is incorrect because
this is supposed to access a boolean of a standard size, but uses _Bool. The
size of _Bool is not prescribed, and IIRC sizeof(_Bool) was 4 with the
compilers used for macOS/PPC
Ronald Oussoren added the comment:
Sigh... never mind, I misread the code. Please ignore msg364472
--
___
Python tracker
<https://bugs.python.org/issue39
Ronald Oussoren added the comment:
AFAIK the macOS builds are still build on the oldest macOS release supported by
the installer (that is, a macOS 10.9 system). This means the build won't use
macOS APIs introduced in macOS 10.10 or later.
It would be nice to build the installer
Ronald Oussoren added the comment:
I don't like that workaround. I'm also not sure if the value of these constants
is the same on macOS and iOS (I do know that some constants higher up in the
stack are not the same).
This issue is a duplicate of an earlier bug about missing functi
Ronald Oussoren added the comment:
This is expected behavior, the call to "C.sm()" happens before "C" is created.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type: -> behavior
__
Ronald Oussoren added the comment:
The incompatibility mentioned in msg366473 is probably fixable by treating the
PyObject header the same as the GC head structure. With some care this could
mostly maintain binary compatibility by inserting some unused fields in
PyObject_HEAD instead of the
Ronald Oussoren added the comment:
Something else that probably needs attention with the TypeSpec API is
subclassing type in an extension when that subclass adds fields to the type
object.
I use this in PyObjC to (dynamically) create types that have some additional
data. I could probably
Ronald Oussoren added the comment:
IMHO this is a bug and plistlib should behave the same as Apple’s libraries
here.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Ronald Oussoren :
--
stage: -> needs patch
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40381>
___
___
Python-bugs-list
Ronald Oussoren added the comment:
AFAIK Windows 10 in Bootcamp is just the regular Windows 10. Bootcamp (or
technically "Bootcamp Assistent") creates a partition for the installation of
W10 and adds some drivers for Apple hardware.
See als: https://support.apple.com/en-u
Ronald Oussoren added the comment:
How did you install Python?
Does "python" work as a command (should give you an interactive shell)?
Does "python -m test" work? This runs the testsuite.
--
___
Python tracker
<
Ronald Oussoren added the comment:
Do you get an error message when you start a command shell and type "python"?
--
___
Python tracker
<https://bugs.python.o
Ronald Oussoren added the comment:
What version of macOS do you use?
--
___
Python tracker
<https://bugs.python.org/issue40508>
___
___
Python-bugs-list mailin
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue15751>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
The macOS test checks if the binary targets macOS 10.4 or earlier. Those
versions of macOS have been out of support for a very long time, and we haven't
had installers targeting those versions of macOS for a long time as well. 2.7
and 3.5 had insta
Ronald Oussoren added the comment:
Technically this would be a functional change, I'd drop this code in 3.9 and
trunk (although it is awfully close to the expected date for 3.9b1).
Older versions would keep this code and the bug, that way the older python
versions can still be us
Ronald Oussoren added the comment:
I've attached a C program that demonstrates the problem, and have filed an
issue with Apple about this: FB8919203
It is not clear to me what we can do about this, other than not building the
ndbm binding on macOS. The manpages for the ndbm APIs d
Ronald Oussoren added the comment:
This is incompatibility between upstream clang and Apple's headers. The same
warning is not present when using Xcode's compiler.
As a workaround this warning can be disabled when including pthread.h,
something like:
```
#ifdef __clang__
#pr
Ronald Oussoren added the comment:
Is this still reproducible?
A question to those that can reproduce this: does this happen with the built-in
screen (assuming a laptop or iMac) or an external interface? If the latter, is
that a retina display? And does this happen more when moving IDLE
Change by Ronald Oussoren :
--
title: Problems building with --enable-profiling on macOS -> Problems building
with --enable-profiling on macOS using homebrew GCC
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
This is a duplicate of #24464
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> "sqlite3_enable_shared_cache" deprecation warning when
compiling wit
Change by Ronald Oussoren :
--
title: Support lldb enhancement in MacOS -> [feature request] Add lldb
equivalent to Tools/gdb
versions: +Python 3.10 -Python 3.9
___
Python tracker
<https://bugs.python.org/issu
601 - 700 of 2445 matches
Mail list logo
