New submission from Ronald Oussoren :
The implementation for asyncio.trsock.TransportSocket says that a number of
methods will be prohibited in 3.9
(https://github.com/python/cpython/blob/8f04a84755babe516ebb5304904ea7c15b865c80/Lib/asyncio/trsock.py#L19),
but merely warns in both 3.9
Ronald Oussoren added the comment:
I've filed a report with Apple about this (FB7731971), even though I expect
that this behaviour will not change. That's something we should have done years
ago.
BTW. The link to malloc_print_configure that Victor shared seems to indicate
that the default
Ronald Oussoren added the comment:
I'm not sure if it is worthwhile to tweak CPython to work around this
misfeature of libc on macOS (and likely iOS). Is this something that causes
issues in real code, or just in the test suite? Looking at this particular
test is seems to use a context
Ronald Oussoren added the comment:
Looking at the source code at
<https://github.com/python/cpython/blob/a871f692b4a2e6c7d45579693e787edc0af1a02c/Python/ceval.c#L1024>:
computed gotos are enabled automatically when they are ava
Ronald Oussoren added the comment:
The result of auto detection of computed gotos can be seen using the
HAVE_COMPUTED_GOTOS macro, not the USE_... one.
Computed gotos should work on macOS, and does on my machine.
--
___
Python tracker
<ht
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 used
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 installers
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue15751>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
What version of macOS do you use?
--
___
Python tracker
<https://bugs.python.org/issue40508>
___
___
Python-bugs-list mailin
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:
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:
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
Change by Ronald Oussoren :
--
stage: -> needs patch
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40381>
___
___
Python-bugs-list
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
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:
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
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:
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 functions that I
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 using
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:
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:
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 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
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 pytho
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:
>From the screenshot:
>>> b = ['sss', 'ase', 'klm', 'qwe']
>>> print sorted(b)
['ase', 'klm', 'qwe', 'sss']
This is the correct result, the output list is alphabetically sorted.
--
nosy: +ronaldoussoren
resolution: ->
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:
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:
An additional question: what version of macOS are you using?
--
___
Python tracker
<https://bugs.python.org/issue39
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 on mac
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:
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:
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:
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
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
interpreter
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 socket
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 python.org
Ronald Oussoren added the comment:
The attached code creates a static (global) C++ object that owns a reference to
a Python object, and releases that reference in its destructor. That destructor
runs at program termination, which is after interpreter shutdown (that is after
Py_FinalizeEx
Ronald Oussoren added the comment:
I'm afraid it will be close to impossible to determine what's going on without
a reproducer.
There's not enough context in the issue to understand the report, in particular
what the main thread is doing and how that's releasing the GIL.
BTW. The code
Ronald Oussoren added the comment:
I don't think this is a bug:
- PyGILState_Ensure() acquires the GIL when it is not already acquired (and can
be called without checking).
It cannot acquire the GIL when some other thread has already taken the GIL, but
wait until the GIL is released
Ronald Oussoren added the comment:
What's the value of PyGILState_Check() before the call to PyGILState_Ensure()?
PyGILState_Ensure() and PyGILState_Release() should bracket code where you're
not sure about the current GIL state, but need the GIL. The Release function
only undoes
Ronald Oussoren added the comment:
W.r.t. the deprecated APIs in getpath.c: Issue15498
That issue contains an ancient patch to switch to non-deprecated APIs, but we
haven't had time yet to fully test these. The issue also mentions that Apple's
install of Python already switched away from
Ronald Oussoren added the comment:
Looking at the stack trace this is a similar issue as the "no_proxy" one, but
in some sense worse because it happens when just calling a regular unix API
(not an Apple framework API).
The first few lines of the stack trace are for code in th
Ronald Oussoren added the comment:
I don't think this is a bug.
def func():
print(var)
This captures the globals at the time of definition, that is "global"
references are resolved using the func.__globals__ attribute which is the
globals dictionary at the time the function
Change by Ronald Oussoren :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38053>
___
___
Ronald Oussoren added the comment:
New changeset 24b11b8c95e96cf9c93fb7fc253e6e96506f2d77 by Ronald Oussoren (Jon
Janzen) in branch 'master':
bpo-38053 Update documentation for plistlib (GH-15727)
https://github.com/python/cpython/commit/24b11b8c95e96cf9c93fb7fc253e6e96506f2d77
Ronald Oussoren added the comment:
I think it is unlikely that the timeouts on Azure CI are related to this change.
--
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
New changeset ce81a925ef2d466b0d801deaba9af44a0dfc2aa1 by Ronald Oussoren (Jon
Janzen) in branch 'master':
bpo-36409: Remove old plistlib API deprecated in 3.4 (GH-15615)
https://github.com/python/cpython/commit/ce81a925ef2d466b0d801deaba9af44a0dfc2aa1
Ronald Oussoren added the comment:
Ana,
The error in "piperroroutput.txt" points to the issue Mark mentioned in
msg351131: the current release of Numpy is not compatible with Python 3.8, but
the tip of the tree on GitHub is.
I can install Numpy from the repository:
$ python
Ronald Oussoren added the comment:
Thanks for the update.
What's the error message you get when using pip to install?
--
___
Python tracker
<https://bugs.python.org/issue38
Ronald Oussoren added the comment:
What issues to you see?
What operating system and version are you on?
How did you install Python?
Note that Python 3.8 is still in beta and therefore a lot of 3th party
libraries do no yet have binary wheels available. You therefore likely need
Ronald Oussoren added the comment:
@raymond, as to your question in msg350586: The release installers are
generally build on the oldest release of the OS targeted by the installer.
That's to ensure that the binaries actually work there.
It should be possible to build on newer releases
Ronald Oussoren added the comment:
I'd increase the default stack size for FreeBSD as well. AFAIK FreeBSD uses
clang as the default compiler like macOS, and it is therefore likely that the
two platforms have similar stack usage for similar code.
BTW. I can provide a PR for this but cannot
Ronald Oussoren added the comment:
Does this application use Tkinter?
If so, this is a duplicate of #37833, and a bug in macOS triggered by (amongst
others) anaconda but (AFAIK) not by the Python.org installer.
The "logout" is a crash in the WindowServer proces, which is
Ronald Oussoren added the comment:
The py2app issue I mentioned is not relevant for this issue.
A simple tkinter runs fine with Python 3.7 (64-bit, 3.7.4, Python.org
installer), the same script causes a WindowServer crash (SEGV) when bundled
with py2app.
This is definitely a bug in macOS
Ronald Oussoren added the comment:
Interestingly enough both users in the py2app issue I mentioned use the
python.org installer to install Python.
One of them mentions this only happens when py2app is used, and that the script
works fine outside of an app.
I'll look into this tonight
Ronald Oussoren added the comment:
I'd prefer a solution that uses symbols where the are available (weak linking).
That way users on newer systems can use all functionality available there,
without having multiple binaries.
I've done this in the past for older macOS versions, but don't
Ronald Oussoren added the comment:
A followup question: How can I determine the exact version of Tk?
--
___
Python tracker
<https://bugs.python.org/issue37
Ronald Oussoren added the comment:
I had a similar problem during EuroPython, but that was when I had anaconda on
my machine. I've since removed it because generally don't use it but had it
installed for a training session.
I haven't tried to reproduce, but also don't run 10.14.6 yet
Ronald Oussoren added the comment:
This is almost certainly a bug in macOS. I wonder if it is possible to work
around it in Python.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Ronald Oussoren :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ronald Oussoren added the comment:
New changeset 9670ce76b83bde950020f8d89c4d27168aaaf912 by Ronald Oussoren
(Michael Felt) in branch 'master':
bpo-18049: Define THREAD_STACK_SIZE for AIX to pass default recursion limit
test (GH-15081)
https://github.com/python/cpython/commit
Ronald Oussoren added the comment:
That code is only called if THREAD_STACK_SIZE is defined. The block I mention
defines it for macOS and FreeBSD, but not for other platforms. I therefore
expect that this code is not used on AIX (which would be easy enough to verify
by adding an #error
Ronald Oussoren added the comment:
@Michael: The relevant code is in Python/thread_pthread.h:
https://github.com/python/cpython/blob/bf8162c8c45338470bbe487c8769bba20bde66c2/Python/thread_pthread.h#L34
There are already blocks for macOS and FreeBSD, adding a block for AIX should
be easy
Ronald Oussoren added the comment:
PR 15075 should fix this issue. As mentioned in that PR I do have a question
w.r.t. the exact shape of that patch: I currently reintroduce a "skipUnless"
decorator that only runs this test on macOS, I could also introduce one that
just disable
Change by Ronald Oussoren :
--
pull_requests: +14822
pull_request: https://github.com/python/cpython/pull/15075
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
The patch to fix this should be:
diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py
index 1466d25e94..658bc1c7a0 100644
--- a/Lib/test/test_threading.py
+++ b/Lib/test/test_threading.py
@@ -1057,6 +1057,7 @@ class ThreadingExceptionTests
Ronald Oussoren added the comment:
That is related, my patch removes a guard that should enable this test only on
macOS.
This fragment is the issue:
- @unittest.skipUnless(sys.platform == 'darwin' and
test.support.python_is_optimized(),
-'test macosx problem
Ronald Oussoren added the comment:
New changeset 1a057bab0f18d6ad843ce321d1d77a4819497ae4 by Ronald Oussoren in
branch 'master':
bpo-18049: Sync thread stack size to main thread size on macOS (GH-14748)
https://github.com/python/cpython/commit/1a057bab0f18d6ad843ce321d1d77a4819497ae4
Ronald Oussoren added the comment:
A GCC export should be able to tell more, but the warning should be harmless.
Objects/obmalloc.c says that the thread sanitizer is available from GCC 4.8,
but for some reason it isn't on your system. This seems to be a bug in
obmalloc.c: The GCC 4.8.5
Ronald Oussoren added the comment:
- Which python version do you try to build?
- What platform are you on?
- Which compiler and compiler version do you use?
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue37
Ronald Oussoren added the comment:
A trick w.r.t. comments in command-lines is to use the ":" command, that's a
no-op shell command that ignores its arguments (although you do need to take
care with shell special characters as it is just a command like
Ronald Oussoren added the comment:
You can always strip the file yourself :-)
Ignoring leading whitespace for XML would be fairly invasive due to the way the
code is set up. I'm not set against it, but I'm not in favour of complicating
the implementation for an edge case like
Ronald Oussoren added the comment:
@shaneg, could you elaborate on why you created this issue?
I don't know of tooling that would generate such files, and it is highly
unlikely that Apple's system tooling/libraries would do so.
--
___
Python
Change by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue33450>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
This is IMHO not a bug in Python, the problem can been seen when you rewrite
the code in msg170261 in C, see the code below.
An observation with the C code below: Both moving ``close(slave)`` to above the
sleep or removing that close entirely fixes
Ronald Oussoren added the comment:
I don't agree with calling lstrip() before checking which format is used
because leading whitespace is invalid for binary plist files (and plutil agrees
with me on that).
--
___
Python tracker
<ht
Change by Ronald Oussoren :
--
stage: -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.org/issue34105>
___
___
Python-bugs-
Ronald Oussoren added the comment:
I'm closing this as out of date.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Ronald Oussoren added the comment:
Please also add a reference to py2app (at least of the programming FAQ as
py2app is macOS-only).
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue30
Ronald Oussoren added the comment:
W.r.t. PyOS_CheckStack: I had that idea last year as well, and someone
contributed a pull request, see issue33955.
--
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
I've done some more testing, and the thread stack size could be smaller than
16MB, but definitely not as small as the value that's currently in
thread_pthread.h.
I prefer to have a slightly too large value here because IIRC the relation
between
Ronald Oussoren added the comment:
In response to msg282272: That day has come, the beta for 10.15 contains Python
3.7.3.
--
___
Python tracker
<https://bugs.python.org/issue28
Ronald Oussoren added the comment:
I've converted the patch to a pull request (and closed to other issue because
that has a patch that is less complete).
I'm not sure if it is acceptable to backport this patch to 3.8 at this time.
--
title: Re-enable threading test on OSX ->
Change by Ronald Oussoren :
--
pull_requests: +14543
pull_request: https://github.com/python/cpython/pull/14748
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
This is a duplicate of 18049, which has a more complete patch.
--
resolution: -> duplicate
stage: patch review -> resolved
superseder: -> Re-enable threading test on OSX
___
Python tracke
Change by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34264>
___
___
Python-bugs-list mailing list
Unsubscrib
Ronald Oussoren added the comment:
This is not a bug in Xcode 11. Xcode 11 includes definitions for new flags that
get picked up by Python's build, but only work on a new version of macOS.
I guess this could be seen as a bug in macOS 10.14 (and earlier) because it
ignores an unknown flag
New submission from Ronald Oussoren :
The Xcode 11 beta introduced a definition for POSIX_SPAWN_SETSID, but that flag
is only supported on macOS 10.15 (also beta), not on earlier versions.
Because of this the testsuite will have failures when you build using Xcode 11
on macOS 10.14.
I'm
Ronald Oussoren added the comment:
As promised there is now a pull request.
I'd love a review (and a change to approve the pull request when reviewers are
happy, I'm trying to get back into actively contributing).
---
I now understand why locale.getdefaultlocale() fails even when LC_CTYPE
Change by Ronald Oussoren :
--
pull_requests: +14530
pull_request: https://github.com/python/cpython/pull/14736
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
LC_CTYPE=UTF-8 is a valid configuration on macOS, and is in the default
environment when you install a fresh system. This includes the beta's for macOS
10.15 and is therefore unlikely to change anytime soon.
Interestingly enough I get this error even when
Ronald Oussoren added the comment:
Which exact python version did you test? The current codebase raises this
exception on all platforms, not just macOS (see os_execv_impl in
Modules/posixmodule.c)
The behaviour of raising an exception was introduced in issue 28732 for
Windows, not sure
Ronald Oussoren added the comment:
We generally don't drop support for OS versions in patch releases for Python.
The 3.8 installer will require macOS 10.9, as does the default x86-64 installer
for 3.7.
--
___
Python tracker
<ht
Ronald Oussoren added the comment:
This could be a duplicate of Issue34572
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue36
Ronald Oussoren added the comment:
The program you include in your report will crash because the interpreter is
never initialised.
See the embedding documentation for more information:
https://docs.python.org/3/extending/embedding.html
--
resolution: -> not a bug
status: o
Ronald Oussoren added the comment:
This is a duplicate of issue36010, which contains an explanation of why there
is no installation method with a zipfile.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue36
Ronald Oussoren added the comment:
This might cause a MemoryError when the __length_hint__ of the source returns a
too large value, even when the actual size of the comprehension is smaller,
e.g.:
[x**2 for x in range(LARGE_VALUE) if is_prime(x)]
See also issue28940
--
nosy
Ronald Oussoren added the comment:
Given a python script in a file named foo.py in the current directory:
* python -m foo
Should, and does, work.
* python -m foo.py
Raises an error, because the command tries to run the submodule "py" of
module "foo" as
Ronald Oussoren added the comment:
This is not a bug:
* "python -m NAME" runs module (or package) NAME as a script, NAME should
therefore be a module name and not a filename (and hence not have a .py suffix)
* "python NAME" runs a script in file NAME and should therefore
501 - 600 of 2417 matches
Mail list logo
