Ronald Oussoren added the comment:
Eddie,
I have read the thread and still don't see why breaking existing code is a good
thing to do.
As I wrote earlier there are two issues you're trying to address with one patch:
1) Not all types in the CPython tree are initialised using PyType_Ready
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
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:
(added "object model" reviewers to the nosy list)
--
nosy: +benjamin.peterson, twouters
___
Python tracker
<https://bugs.python.o
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 custom metatype (e.g
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
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:
I have a patch for making the stack sizes the same in Issue34264.
--
___
Python tracker
<https://bugs.python.org/issue18
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:
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 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 sh
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 or s
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
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:
Could you explain why this would be useful?
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue34
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:
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.pyth
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 the &qu
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
___
Python
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:
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 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:
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
Change by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue34105>
___
___
Python-bugs-list mailing list
Un
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
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 servname pro
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.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/pullrequ
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:
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-party
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 after
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 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 correctly
Ronald Oussoren added the comment:
PS. A pull request will follow shortly.
--
___
Python tracker
<https://bugs.python.org/issue34264>
___
___
Python-bugs-list m
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
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +8046
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
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 providing a reliable
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
Change by Ronald Oussoren :
--
pull_requests: +8038
___
Python tracker
<https://bugs.python.org/issue34170>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +8037
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34247>
___
___
Py
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).
Those are read
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.python.org/issue34
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: ronaldoussoren
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/issue34
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
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
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
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:
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:
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:
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
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
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 files
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 without
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:
Sure. I'm not working on this at the moment.
--
___
Python tracker
<https://bugs.python.org/issue33955>
___
___
Python-bug
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:
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 yet.
On the other hand
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 yet
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
hig
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't
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, ronaldoussoren
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:
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())&q
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
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, wouldn't
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:
@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:
>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:
@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:
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:
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:
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 won't
Ronald Oussoren <ronaldousso...@mac.com> 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 o
Ronald Oussoren <ronaldousso...@mac.com> 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 th
Ronald Oussoren <ronaldousso...@mac.com> 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 dif
Ronald Oussoren <ronaldousso...@mac.com> 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 Pytho
Ronald Oussoren <ronaldousso...@mac.com> 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
Ronald Oussoren <ronaldousso...@mac.com> 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.
Ronald Oussoren <ronaldousso...@mac.com> 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 pro
Ronald Oussoren <ronaldousso...@mac.com> 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 particula
Ronald Oussoren <ronaldousso...@mac.com> 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 men
Ronald Oussoren <ronaldousso...@mac.com> 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 h
Ronald Oussoren <ronaldousso...@mac.com> 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
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
I'm still not too happy about supporting UIDs in plistlib, especially because
I'm not sure it that's all that's needed. AFAIK I removed more types that the
underlying encoder supported from plistlib because those are neve
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
The "reverse_pointers" attribute is implicitly documented by this phrase in the
introduction of network objects:
--
All attributes implemented by address objects are implemented by network
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
@bigfootjon: Cocoa keyed archives are not plist files.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
Note that I'm still -1 on merging this patch because it is unclear how to
create such plist files using public Apple APIs.
P.S. The low-level code for creating and reading binary plist files appears to
be used for more than
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
The ApplePersistenceIgnoreState setting (either in user defaults or an
info.plist file) is IMHO not the right solution, as this is a setting intended
to be used for testing (see
<https://developer.apple.com/librar
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
The 3.7b1 64-bit installer includes a local copy of Tcl/Tk (see
Mac/BuildScript/build-installer.py), which could be changed as needed. That
said, I'm not advocating changing default Tcl/Tk configuration options because
I don'
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
<https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Address.reverse_pointer>
documents that this attribute contains the name of the DNS name that could be
used to query for PTR record.
That functionality
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
I different question w.r.t. detection of the clang/llvm version on Apple's
system compiler: Is it worthwhile to do so?
If the compiler included in the Xcode 9.3 beta (and hence likely the one in
Xcode 9.3 final)
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
Is there anything we (the CPython developers) can do about this?
If I read the issue correctly clang 5.x generates faster binaries than clang
3.x and 4.x. If that is indeed the issue there's probably not much we can do
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
I agree, as long as there are other buildbots for macOS (and there appear to be
buildbots for macOS 10.12 and 10.13).
It would be nice to have buildbots running the OS releases for which installers
are build (10.6 an
Ronald Oussoren <ronaldousso...@mac.com> added the comment:
@larry: plists are Apple's equivalent to Windows INI files ;-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ronald Oussoren <ronaldousso...@mac.com> 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
Ronald Oussoren <ronaldousso...@mac.com> 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
Ronald Oussoren <ronaldousso...@mac.com> 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 th
Ronald Oussoren <ronaldousso...@mac.com> 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 T
701 - 800 of 2417 matches
Mail list logo
