Ronald Oussoren added the comment:
I'm fairly sure this is expected behavior on macOS: _tkinter loads the Tk
library, which loads Apple GUI frameworks. Those frameworks are not save w.r.t.
fork(2) and that can lead to all kinds of unwanted behavior (although I would
have expected a
Ronald Oussoren added the comment:
I cannot reproduce the problem on macOS 10.13.3 with python 3.6 (but haven't
spent much time on this).
The combination of GUI code with multiprocessing is a known source of problems
on macOS, the system libraries are hostile to that.
Changing the
Ronald Oussoren added the comment:
@ezwelty: The import of multiprocessing and the call to set_start_method should
be at the very start of the code, before other imports, to avoid the annoying
Apple behavior I mentioned.
--
___
Python tracker
Ronald Oussoren added the comment:
As far as I know macOS does not support different salt types at all. The
manpage does mention an "extended crypt", but according to the documentation
that just controls the number of DES rounds used.
In particular:
The salt is a 9-chara
Ronald Oussoren added the comment:
What's the specific exception you are getting?
BTW. This involves third-party code and this may be a bug in that code. An
important difference between linux and windows is how multiprocessing launches
additional processes.
--
nosy: +ronaldous
Ronald Oussoren added the comment:
Multiprocessing by default uses the fork system call to start new processes on
Linux. This system call is not available on Windows, and there multiprocessing
starts a fresh interpreter (see
<https://docs.python.org/3.6/library/multiprocessing.h
Ronald Oussoren added the comment:
The second link contains an explanation of what's going on, and that this is
unexpected behaviour of the macOS kernel.
I'm not sure what we could do about this, the blog post explains that this
error can happen when send(2) is called while the
Ronald Oussoren added the comment:
This is true for other symbols as well, when deploying to older releases of
macOS.
I have added runtime checking for a number of symbols in the past, that could
be extended to newer APIs.
--
On the road, hence brief.
Op 30 sep. 2017 om 09:17 heeft
Ronald Oussoren added the comment:
Calling get_proxies() in a subprocess would also work, although I'd then prefer
to use a small daemon proces to avoid the startup cost of a new process for
every call to _scproxy functions.
There is a conflict between two goals w.r.t. the macOS por
Ronald Oussoren added the comment:
CLOCK_THREAD_CPUTIME_ID should be available on macOS 10.12 and later (which is
also when clock_gettime was introduced).
I'm not sure if it is worthwhile to implement this fairly specialised function
for older macOS releases due to the maintenance
Ronald Oussoren added the comment:
This appears to be an issue with a 3th-party library
(https://pypi.python.org/pypi/ObjectListView), not CPython itself.
The repository (and issue tracker) for that library is at
<https://bitbucket.org/wbruhin/objectlistview>.
@Balakrishnan: cou
Ronald Oussoren added the comment:
Another option is to skip this test unconditionally on macOS when using APFS,
the test is already skipped on win32 and tests a generic codepath where only
testing on Linux should be fine.
BTW. It is fairly easy to detect if a path is on APFS:
```
import
Ronald Oussoren added the comment:
This is the expected behavior, the upgrade from 3.5 to 3.6 is a feature update
that is (in general) not expected to be binary compatible with the previous
release.
--
nosy: +ronaldoussoren
___
Python tracker
Ronald Oussoren added the comment:
The virtualenv (both using venv and using the third party library virtualenv)
still relies on most of the python installation outside of the virtualenv, in
particular the stdlib extensions. Those are not guartanteed to be binary
compatible between feature
Change by Ronald Oussoren :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ronald Oussoren added the comment:
I don't have time to perform a review right now, I'm trying to get PEP 447
through review and that takes most of my available time at the moment.
I'm not convinced that the speedup of plistlib is relevant for real-world code,
plist files
Ronald Oussoren added the comment:
I don't know if the issue has been fixed on macOS, and I'd be surprised if Ned
would know this without testing.
Anyways, I think it is worthwhile to perform the testing that Antoine mentioned
on a recent version of macOS (I'd start on 1
Ronald Oussoren added the comment:
If the nested loop is the issue the Python 3 version behaves as expected.
A difference between python2 and python3 is that the zip() builtin returns a
list on python2 and an iterator on python3. This explains the difference in
results in running the code on
Ronald Oussoren added the comment:
As I mentioned on the pull request it is not clear to me what the actual issue
is.
What are the settings for building that cause problems? In particular, what
are the compiler/linker related variables in Python's Makefile (and
_sysconfigdata.py)?
Ronald Oussoren added the comment:
Did you install ActiveState's distribution of Tk as described here:
https://www.python.org/download/mac/tcltk/ ?
Sadly enough the version of Tcl/Tk shipped by Apple contains a number of bugs
that cause problems for Tkinter applications like
Ronald Oussoren added the comment:
There appears to be a permission issue with the home directory.
What's the output of the following commands in a terminal window:
$ ls -led ~
$ id
The home directory should be owned by the "uid" shown by the second command,
and should be
Ronald Oussoren added the comment:
This is an issue with the czipfile package on PyPI
(<https://pypi.python.org/pypi/czipfile>) and not a bug in CPython.
Note that czipfile appears to support Python 2 only, which would explain the
error message you are getting.
-
Ronald Oussoren added the comment:
The darwin version change is likely due to an upgrade from macOS 10.13.1 to
10.13.2.
The user change can be due to the introduction of a new system user, but I
don't know when user _timed was introduced and don't have 10.3 VMs other than
o
Ronald Oussoren added the comment:
Another note: we also prefer relatively small samples, the code in search.zip
is quite large.
The reason to want a small example for this issue is that this would make it
easier to check if the problem is on the Python side or on the Tk side (e.g.,
this
Ronald Oussoren added the comment:
I don't think there's a bug here: sched.enter schedules an event some time
after the current time. The two calls to sched.enter are not at the same time,
hence the priority is not used because the events are scheduled at different
times.
-
Ronald Oussoren added the comment:
I did look at the code :-)
The enter() method just calls enterabs() with an absolute time calculated from
the current time (using the timefunc for the scheduler) and the passed relative
time. Two calls of enter() with the same relative time will therefore
Ronald Oussoren added the comment:
This is fairly odd behaviour of macOS, the same error can be seen from a bash
session:
$ stat /dev/fd/3
stat: /dev/fd/3: stat: Bad file descriptor
The reason os.walk() works while the Path().is_file doesn't is that os.walk()
explicitly guards ag
Ronald Oussoren added the comment:
I'm not a Windows expert, but looking that the API description [1] the patch is
not entirely correct.
The API takes an integer with 3 valid values, the patch effectively passes the
value 1 (which means the application claims to be DPI aware, but
Ronald Oussoren added the comment:
A better solution is to avoid using fork mode for multiprocessing. The spawn
and fork server modes should work fine.
The underlying problem is that macOS system frameworks (basically anything
higher level than libc) are not save wrt fork(2) and fixing
Ronald Oussoren added the comment:
Antoine, the issue is not necessarily related to POSIX compliance, AFAIK
strictly POSIX compliant code should work just fine. The problem is in
higher-level APIs (CoreFoundation, Foundation, AppKit, ...), and appears to be
related to using multi-threading
Ronald Oussoren added the comment:
@Ned: In the long run the macOS installers should be build using the latest
SDK, primarily to get full API coverage and access to all system APIs.
AFAIK building using the macOS 10.9 SDK still excludes a number of libSystem
APIs that would be made
Ronald Oussoren added the comment:
>From the zip file, the "bug" is:
#
def parent_function2( argument1 ):
def child_function():
print( argument1 )
if False:
argument1 = None # Same function but with fak
Ronald Oussoren added the comment:
@stephen: Lib/encoding/aliases.py contains aliases for a (largish) number of
encoding names, including both "cp" and "" for most windows code pages.
For code page 874 only the name "cp874" can be used and not "874&
Ronald Oussoren added the comment:
Could you also add a documentation update and a news entry?
The section on standard encodings mentions aliases for standard encodings, and
IMHO the new aliases should be added to that page.
Creating a new entry is described here:
https
Ronald Oussoren added the comment:
I'm not convinced that adding code to search_function is the right solution for
this.
BTW. I'm also not sure yet why this error happens, does windows return a
codepage number as the preferred encoding when the io module looks for one? If
so, w
Ronald Oussoren added the comment:
Confirmation that the patch actually fixes the problem would be nice, but I'd
still like to understand why Python tries to use an encoding with the name
"874" as this might lead to a nicer solution to the problem.
BTW. There is some dis
Ronald Oussoren added the comment:
In particular, we're interested in the following information:
* What OS is installed on your machine?
* What locale (country/language) is configured?
* What does "import locale; print(locale._getdefaultlocale
Ronald Oussoren added the comment:
@Serhiy: The screenshot suggests that this is regular python install.
--
___
Python tracker
<https://bugs.python.org/issue33
Ronald Oussoren added the comment:
Patch looks good to me, and back porting to 3.6/3.7 should be safe enough.
I haven't merged yet because I need to study the devguid a bit before I do so
(especially w.r.t. back porting)
--
components: +macOS
nosy: +ned.deily, ronaldous
Ronald Oussoren added the comment:
The crash is likely caused by recursion during the clean-up of the
object().__dir__.__dir__ chain.
The trashcan API (see Py_TRASHCAN_SAFE_BEGIN/Py_TRASHCAN_SAFE_END in
Include/object.h) can help here.
Those do some real work and have a cost, I can&#
New submission from Ronald Oussoren :
The (non-portable) pthread APIs "pthread_get_stacksize_np()" and
"pthread_get_stackaddr_np()" can be used to implement PyOS_CheckStack on macOS,
which would give nicer behavior than crashing when the recursion limit is too
high for t
Ronald Oussoren added the comment:
@victor: thanks for confirming my analysis.
The trashcan API does fix this issue, although I did have to change
"_PyObject_GC_UNTRACK(m);" to "PyObject_GC_UnTrack(m);" as well. I haven't
checked
Ronald Oussoren added the comment:
Eric,
Thanks.
See the pull request for why this might qualify for a back port: other parts of
distutils recognise '.mm' as a valid extension, but '.mm' doesn't work yet
because UnixCCompiler doesn't support this ye
Ronald Oussoren added the comment:
Do the tests work properly from an installed python framework?
That doesn't immediately help with the normal way of running tests, but might
point to a way forward. The major difference with normal installs is that the
python interpreter is started
Ronald Oussoren added the comment:
Sure. I'm not working on this at the moment.
--
___
Python tracker
<https://bugs.python.org/issue33955>
___
___
Pytho
Ronald Oussoren added the comment:
Have you looked at benchmark results for this patch?
In particular, PyOS_CheckStack is called quite often and I wonder how those
calls affect performance. If there is a clear performance impact it would be
useful to store some information in the python
Ronald Oussoren added the comment:
W.r.t. benchmarks: The full benchmark suite that's often used to assess the
performance impact on real world code is: http://pyperformance.readthedocs.io
Running this takes some time, and the interesting bit is comparing the
performance with and wi
Ronald Oussoren added the comment:
I agree with Ned that we shouldn't add code to deal with non-standard compiler
setups, correctly supporting macOS is hard enough as it is.
That said, the attached patch (but not PR8056) looks fine to me, it includes
all possibly relevant headers file
Ronald Oussoren added the comment:
Sorry about the slow response.
The patch looks OK, although I'm entirely happy yet about the workaround for
the stack size on the main thread. Primarily because framework builds use a
non-standard stack size as the default one is too small fo
Ronald Oussoren added the comment:
As I mentioned in msg314304 this is almost certainly expected behavior on macOS
because Apple’s GUI frameworks are not fork()-safe. There is nothing we can do
about this other than changing the default spawn mechanism for multiprocessing
on macOS.
--
On
Ronald Oussoren added the comment:
I can provide a patch, but that will likely be during EuroPython as I’m
currently taking a roundabout route towards Edinburgh.
Btw. I’m not sure yet how impactful changing the default spawning mechanism
would be for 3.8. How likely is that to break user
Ronald Oussoren added the comment:
I’m not sure if I understand correctly. Is your report about the difference in
the values of EAGAIN between Linux and macOS?
If so, that is not a bug: the relevant standards only document the name and
type of these constants and not their values. The value
Ronald Oussoren added the comment:
This is not a bug and the issue can be closed. I’ll do so when I get back to
my computer in a couple of days.
--
On the road, hence brief.
Op 19 jul. 2018 om 08:52 heeft Karthikeyan Singaravelan
het volgende geschreven:
>
> Karthikeyan Singar
Ronald Oussoren added the comment:
Os.stat is defined in C code, in particular in Modules/posixmodule.c.
Op 20 jul. 2018 om 10:44 heeft Windson Yang het
volgende geschreven:
>
> Windson Yang added the comment:
>
> I tried to fix this issue and I found this should be relate
New submission from Ronald Oussoren :
Attached is a very basic launcher for python scripts. This script works as
expected in Python 3.6, but not in 3.7.0.
In particular, the launcher sets the environment variable PYTHONOPTIMIZE before
calling Py_Initialize and that setting is ignored.
I
Change by Ronald Oussoren :
Added file: https://bugs.python.org/file47717/foo.py
___
Python tracker
<https://bugs.python.org/issue34247>
___
___
Python-bugs-list mailin
Change by Ronald Oussoren :
Added file: https://bugs.python.org/file47716/t.c
___
Python tracker
<https://bugs.python.org/issue34247>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
I'm at the EuroPython sprints and currently working on a testcase for this.
Should be a nice way to get back into actively contributing to CPython :-)
--
___
Python tracker
<https://bugs.python.org/is
New submission from Ronald Oussoren :
The testsuite skips test_embed when srcdir != builddir, that's because
test.test_embed assumes that _testembed is in the source directory.
I noticed this while working on issue34247.
--
components: Tests
messages: 322531
nosy: ronaldous
Ronald Oussoren added the comment:
FYI: I've filed issue34255 while working on this, test_embed assumes that
you're building in the source directory (which I usually don't do).
--
___
Python tracker
<https://bugs.pyt
Ronald Oussoren added the comment:
Interesting... pylifecycle.c uses code in main.c, I hadn't expected that.
If I've read the code correctly Py_Initialize won't look at PYTHONOPTIMZE at
all (and other environment variables that have a command-line equivalent).
Th
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +8037
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34247>
___
___
Py
Change by Ronald Oussoren :
--
pull_requests: +8038
___
Python tracker
<https://bugs.python.org/issue34170>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I've created a pull request that seems to work properly, although I am not
entirely sure that this is the right way to fix this.
As I mentioned in the pull request I created it against the 3.7 branch because
of bpo-34170, but would happily rebase i
Ronald Oussoren added the comment:
That's annoying, I cannot reproduce the issue on macOS 10.13. I don't have
access to my test VM running 10.11 at the moment, I'll work on documenting this
when I get back home (and do have access to 10.11 again).
BTW. I don't know if
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +8046
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Ronald Oussoren :
configure.ac sets the stack size for the main thread on macOS to 100 (hex),
while Python/threading_pthread.h sets the default stack size for other threads
to 0x50. The latter is half of the former.
IMHO both should be the same, as both claim to
Ronald Oussoren added the comment:
PS. A pull request will follow shortly.
--
___
Python tracker
<https://bugs.python.org/issue34264>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
I get the same error on High Sierra, but not on the Mojave beta. I also
regularly get a FileNotFound error instead (which is why I ended up at this
issue in the first place).
I'm not sure yet what causes this, a small reproducer in C works correctl
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +8051
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
I'm slightly closer to understanding the problem. The value of errno is that of
the last error *before* getgrouplist(3) was called, that is, getgrouplist
return -1 but does not update errno.
And looking at Apple source code this is a bug in CPython
Ronald Oussoren added the comment:
https://core.tcl.tk/tk/tktview/769367b4c9b8e4fc05afaf67dc0aa6e3c1dba682 is an
Tcl/Tk issue about issue34275, which is also about Tooltips.
I've added a comment to the Tk issue to note that IDLE also has problems (the
other ticket is about a 3th-
Ronald Oussoren added the comment:
@terry.reed: Kevin Walzer is a maintainer for Tk on macOS.
I know too little of IDLE to answer his questions.
--
___
Python tracker
<https://bugs.python.org/issue34
Ronald Oussoren added the comment:
I'm not sure what your proposal is. Do you have a patch that increases the
performance of collections.deque in some cases? If so please share that patch,
preferably as a pull request on GitHub (see
<https://devguide.python.org/pullrequest/
Ronald Oussoren added the comment:
That's ok, I hadn't expected that you'd sign the CLA before being asked to do
so :-)
Good luck.
--
___
Python tracker
<https://bugs.pyt
Ronald Oussoren added the comment:
This is not expected, but I don't know where the problem is.
On my machine I get:
>>> socket.gethostbyname('0.1.1.~1')
Traceback (most recent call last):
File "", line 1, in
socket.gaierror: [Errno 8] nodename nor servna
Ronald Oussoren added the comment:
Note that the test itself has the following comment:
def test_host_resolution_bad_address(self):
# These are all malformed IP addresses and expected not to resolve to
# any result. But some ISPs, e.g. AWS, may successfully resolve these
Change by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue34105>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
For some reason your system resolves invalid names, likely due to some upstream
nameserver misbehaving.
Is your Internet provider T-Online in Germany? The address 62.138.239.45 is
registered to that company, the IP address also appears to host some kind of
Ronald Oussoren added the comment:
This message is generated by setuptools (in module setuptools.msvc).
The GitHub repository for setuptools is at
<https://github.com/pypa/setuptools>, please contact the developers there.
--
nosy: +ronaldoussoren
resolution: -> third pa
Ronald Oussoren added the comment:
The PR works for me as well, and looks ok to me.
--
___
Python tracker
<https://bugs.python.org/issue34247>
___
___
Python-bug
Ronald Oussoren added the comment:
This might be a useful feature but I think it would be better to develop this
outside the stdlib, especially when the mechanism needs application specific
code (such as preloading modules used by a specific script).
If/when such a tool has enough traction
Ronald Oussoren added the comment:
This is expected behaviour, the FAQ entry on floating point gives a good
explanation about what's going on here:
https://docs.python.org/3.7/tutorial/floatingpoint.html
--
nosy: +ronaldoussoren
___
P
Ronald Oussoren added the comment:
This is IMHO not a bug in CPython (or even macOS). On Python 2.7 file I/O is
implemented using C's stdio library and that prescribes this behaviour (the "at
EOF" state of a file stream is sticky.
fd.seek(0, 2) should unset th
Ronald Oussoren added the comment:
For completeness sake I've attached a C program demonstrating the same problem.
--
status: pending -> open
Added file: https://bugs.python.org/file47740/readwrite.c
___
Python tracker
<https://bugs
Change by Ronald Oussoren :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue34371>
___
___
Python-bugs-list mailing list
Unsubscrib
Ronald Oussoren added the comment:
Could you explain why this would be useful?
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue34
Ronald Oussoren added the comment:
Another reason for not wanting write access to the sys.intern dictionary is
that this dictionary does not own references to its keys and values.
--
___
Python tracker
<https://bugs.python.org/issue34
Ronald Oussoren added the comment:
IMHO we shouldn't expose the intern dictionary without there being a clear, and
good enough, use case for doing so.
Exposing the dictionary decreases implementation flexibility, and increases
requirements on other implementations. One example o
Ronald Oussoren added the comment:
I don't understand this clarification:
> Clarification: while Mac/OS falls under "posix" in python terms - maybe
> "breakage" will need to be accepted,
> or, for "back-ports" Mac/OS will be "as if root
Ronald Oussoren added the comment:
This is expected behaviour: When your run a script the directory containing the
script is added to the start of sys.path. Running "python3.6 a/foo.py"
therefore adds "a" to the start of sys.path, and "math.py" then shadows th
Ronald Oussoren added the comment:
This has nothing to do with absolute imports at all.
You have two toplevel modules in an entry on sys.path that is before the stdlib
(see the earlier message by Eric V. Smit for documentation on how the path is
initialised). The name of one of those
Ronald Oussoren added the comment:
This behaviour is not a bug, even if it can be confusing at times.
Please read <https://docs.python.org/3/tutorial/modules.html>.
--
resolution: -> not a bug
status: open -> closed
___
Python tra
Ronald Oussoren added the comment:
I have a patch for making the stack sizes the same in Issue34264.
--
___
Python tracker
<https://bugs.python.org/issue18
Change by Ronald Oussoren :
--
nosy: +eli.bendersky, scoder
___
Python tracker
<https://bugs.python.org/issue34461>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
FWIW I can reproduce the problem with IDLE and tk_scroll.py:
1) Add a spanish keyboard layout in System Preferences (my normal layout is US
International, matching the text on the keyboard)
2) Select this keyboard using the keyboard menu item
3) Type CMD
Ronald Oussoren added the comment:
I don't agree with "This means that a PyTypeObject's ob_type should always be
set by PyType_Ready.", and therefore don't agree with the change to
PyVarObject_HEAD_INIT.
In particular this is not correct when the type has a custo
Ronald Oussoren added the comment:
(added "object model" reviewers to the nosy list)
--
nosy: +benjamin.peterson, twouters
___
Python tracker
<https://bugs.python.o
Ronald Oussoren added the comment:
I was also talking about static C types, it is possible to write types with
custom meta types in C code (even if that is even less common than using meta
types in the first place). I have extensions where I use PyVarObject_HEAD_INIT
without the first
Ronald Oussoren added the comment:
BTW. And that -1 was even before considering that PyVarObject_HEAD_INIT is not
a type-object specific macro, but a macro to staticky initialize values of
PyVarObject.
--
___
Python tracker
<ht
1201 - 1300 of 2445 matches
Mail list logo
