Ned Deily added the comment:
Sorry, I can't reproduce the problem. By default and by design,
Library/Python/2.7/site-packages comes last in sys.path for the python.org
installed Pythons. Are you sure you aren't overriding sys.path with a
PYTHONPATH environment variable or some
Changes by Ned Deily :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue14188>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Ned Deily :
--
assignee: -> ned.deily
nosy: +ned.deily
stage: -> needs patch
title: test_recursion_limit -> test_recursion_limit fails on OS X when compiled
with clang
___
Python tracker
<http://bugs.python.or
Changes by Ned Deily :
--
status: open -> pending
title: Sharing site-packages between Apply and python.org builds breaks
extensions -> Sharing site-packages between Apple and python.org builds breaks
extensions
___
Python tracker
Changes by Ned Deily :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14188>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
Sorry, can you explain better what problem you are seeing including specific
error messages?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue14
Ned Deily added the comment:
Thank you for the additional information. It appears the problem is that, for
OS X framework builds, the ABI suffix (added in PEP 3149) is not used to create
the shared library dylib name in the framework lib directory. For example,
$ cd Library/Frameworks
New submission from Ned Deily :
./Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'
/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c: In function
'PyCurses_ConvertToCchar_t':
./Modules/_cursesmodule.c:289: error: 'obj' undeclared (firs
Ned Deily added the comment:
3.2 also fails when compiled on 10.7 with clang. Issue9670 had increased the
secondary stack size for OS X and FreeBSD by an empirically-determined amount
to reduce the chance of crashes for recursive function calls. Continuing that
somewhat kludgey strategy
Changes by Ned Deily :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue14104>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
It looks like the increase isn't quite big enough for the clang in Xcode 4.2.
Revised patch uses a slightly bigger size.
--
Added file: http://bugs.python.org/file24810/issue14184_rev1.patch
___
Python tracker
Ned Deily added the comment:
Thanks for the report. Fix applied for 3.2.x (for release in 3.2.4) and
default (for 3.3.0).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: -> crash
___
Py
Changes by Ned Deily :
--
assignee: ronaldoussoren -> ned.deily
___
Python tracker
<http://bugs.python.org/issue14299>
___
___
Python-bugs-list mailing list
Un
Changes by Ned Deily :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue14299>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
(Oops, wrong assignment!)
--
assignee: astrand -> asvetlov
nosy: +asvetlov
___
Python tracker
<http://bugs.python.org/issu
Changes by Ned Deily :
--
nosy: -astrand
___
Python tracker
<http://bugs.python.org/issue13153>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Reassigning to Andrew to investigate solution similar to the one used in
Issue14200.
--
assignee: ned.deily -> astrand
nosy: +astrand
title: IDLE crash with unicode bigger than 0x -> IDLE crashes when pasting
non-BMP unicode char on UCS-16
Ned Deily added the comment:
Thanks for the suggestions!
--
assignee: -> ned.deily
components: +Documentation
nosy: +ned.deily
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3
__
Ned Deily added the comment:
Thanks for the suggestion!
--
nosy: +ned.deily
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
title: Misc/README -> Update Misc/README
___
Python tracker
<http://bugs.python
Ned Deily added the comment:
An update: test_ctypes continues to fail on 2.7.3rc2 with exactly the same
failures as originally reported when compiled non-debug 64-bit (x86_64) with
either the latest clang *or* llvm-gcc from Xcode 4.3.1. It does not fail when
compiled with gcc-4.2 from Xcode
Ned Deily added the comment:
This is likely related to Issue13370 which documents test_ctypes failures when
using either of the llvm-based compilers (clang or llvm-gcc) supplied with
recent versions of Xcode 4. test_ctypes and your test both do not fail when
Python is compiled with the
Changes by Ned Deily :
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.org/issue14078>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.org/issue14377>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Since most people can't reproduce this problem now, let's assume it was a
problem in the particular version of Tk used. If someone can reproduce it with
a current IDLE and Tk, please reopen with details.
--
nosy: +ned.deily
stage: t
Ned Deily added the comment:
To add to the other comments, problems with input methods using Python 3 and
Tkinter or IDLE are usually platform-specific issues with the implementation of
Tk. In particular, the issue Jean-Christophe reported with Python 3.1.1 was
very likely due to its use of
New submission from Ned Deily :
When run from an installed location, rather than from the build directory,
test_unittest now crashes:
$ ./root/bin/python3.3 -m test -w -uall,-largefile test_unittest
[1/1] test_unittest
test test_unittest crashed -- Traceback (most recent call last):
File
Ned Deily added the comment:
Yes, whatever the initial problem, it doesn't seem to be an issue anymore.
--
nosy: +ned.deily
resolution: -> out of date
stage: test needed -> committed/rejected
status: open -> closed
___
Python
Changes by Ned Deily :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
For examples of tests that build extension modules, see
Lib/packaging/tests/test_command_build_ext.py or the Distutils equivalent,
Lib/distutils/tests/test_build_ext.py. These tests are also runnable from
installed versions of Python, assuming the user has the
Ned Deily added the comment:
Roger, I notice that the line your patch modifies in configHandler.py has been
unchanged for years and is the same in older Python versions. My impression
from Ankit's description is that this is a new problem. What's different or am
I misund
Ned Deily added the comment:
(Thanks for the expanded analysis, Roger. I missed the implication of the title
update you made.)
--
___
Python tracker
<http://bugs.python.org/issue14
Ned Deily added the comment:
Niklas, the Python 2 and 3 binaries for Mac OS X provided by the python.org
installers are not built with support for gdbm, nor are the Apple-supplied
system Pythons; Apple does not ship gdbm with OS X. So you can't open a shelve
file created in another P
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue14455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +brian.curtin, loewis
___
Python tracker
<http://bugs.python.org/issue14457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
David, right you are. I verified that the current 3.2.3rc2 without gdbm does
correctly recognize a shelve from another Python backed with gdbm 1.10:
dbm.error: db type is dbm.gnu, but the module is not available
Niklas, yes, to build a Python from source on OS X
Ned Deily added the comment:
Thanks for the patch. Applied to default for 3.3.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Ned Deily :
It may also fail in other builds where the build directory is not the same as
the source directory. The problem is in setup.py function _decimal_ext which
fails to create an absolute path for the libmpdec include source directory.
Patch follows
Changes by Ned Deily :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
No one uses it? I'm surprised. I do and it seems to me by far the easiest and
safest way to maintain patches in progress when there is constant churn.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.py
Changes by Ned Deily :
--
nosy: +brian.curtin
title: Remove using of w9xopen in subporcess module -> Remove using of w9xopen
in subprocess module
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
I am unable to reproduce this behavior with current versions of Python 2.7 or
3.2 on OS X 10.5.8 using either the most recent Apple-supplied Carbon Tcl/Tk
8.4 or with the latest ActiveState Tcl/Tk 8.4 nor with on OS X 10.7 with Tcl/Tk
8.4 or 8.5. There have been
Ned Deily added the comment:
It certainly is still possible to patch current Pythons to build with the X11
Tk 8.5 on OS X. For example, the current MacPorts Python ports use an X11 Tk
8.5. Considering all the issues that have arisen with the other Tcl/Tk
implementations on OS X (i.e. Cocoa
Ned Deily added the comment:
For OS X builds, the value returned in get_platform() is not intended to
indicate what OS version the Python instance is running on. Rather, it
indicates which ABI version was used to build the Python in use so that
Distutils can use the same ABI for building C
New submission from Ned Deily :
With the release of Xcode 4.3 for OS X 10.7, Apple has moved the location of
the OS X SDKs from their long-time path of /Developer to within the new
Xcode.app bundle itself. This breaks the building of extension modules with
any of Distutils or packaging
Ned Deily added the comment:
BTW, Issue14499 is now open to track the Xcode 4.3 SDK problem.
--
___
Python tracker
<http://bugs.python.org/issue14498>
___
___
Ned Deily added the comment:
There was some related work on this in the earlier Demo clean up issue
(Issue7962) and the still open "make altnstall" shebang line cleanup
(Issue10318).
But I'm confused. From the list of files you show in invalid.txt appear to be
from a
Ned Deily added the comment:
Nicholas, please open a new issue documenting which Python 3.3 you are using,
from which python.org installer or the ./configure parameters if you built it
yourself (and whether you supplied a version of GNU readline or used the Apple
default of BSD libedit) and
Ned Deily added the comment:
The use of Xlib is not limited to Linux; most Unix-y platforms supported by
Python have Xlib-based Tk versions available. But it is correct that there are
Tk implementations that do not use X11 as their window server, for example, the
native Tk implementations
Ned Deily added the comment:
That does seem like silly behavior. On the other hand, the only ill effect is
likely the time required to execute the series of open calls which, in the
interactive case, would not even be noticed on most systems. Would you be
interested in writing a patch
Ned Deily added the comment:
This is almost certainly due to using the Apple-supplied Tcl/Tk 8.5 in Mac OS X
10.6. The Apple-suppied version of Tcl/Tk is buggy to the point of being
unusable with Tkinter applications, in particular IDLE. There are many
duplicate issues on similar problems
Ned Deily added the comment:
The problem of not honoring alternate input methods should no longer be a
problem when using a current ActiveState Tcl/Tk 8.5.x on Mac OS X and a Python
that is built to link with it, such as the current Python 2.7.x and 3.2.x
installers from python.org. At the
Ned Deily added the comment:
Peter: I'm sorry that I didn't make it clearer in my reply that you need to use
the 64-bit/32-bit python.org installers (available for OS X 10.6 and above),
not the 32-bit-only installers. The 32-bit-only-installers are linked with
Tcl/Tk 8.4 since t
Ned Deily added the comment:
The problem you are seeing is due to two separate issues. (1) The first time
you build Python 3 in a particular build directory, the Abstract Syntax
Definition Language (asdl) parser build step may be unnecessarily run by "make"
if the time stamps of
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: -Devguide
stage: -> committed/rejected
title: OSX Build Target -> Python build fails on OS X with
"$MACOSX_DEPLOYMENT_TARGET mismatch"
versions: -Python 2.7
___
Ned Deily added the comment:
I don't understand the need for this. AFAICT, the purpose of python-config is
to provide configuration info for embedding Python (Issue1161914 and
https://docs.python.org/3/extending/embedding.html#compiling-and-linking-under-unix-like-systems).
At some
Change by Ned Deily :
--
pull_requests: -13383
___
Python tracker
<https://bugs.python.org/issue25234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
New changeset eca18aac7b5952d23854d27dc8e502dfb0bb0505 by Ned Deily (Yury
Selivanov) in branch 'master':
bpo-34616: Fix code style and unbreak buildbots (GH-13473)
https://github.com/python/cpython/commit/eca18aac7b5952d23854d27dc8e502dfb0bb0505
-
Change by Ned Deily :
--
pull_requests: -13382
___
Python tracker
<https://bugs.python.org/issue33725>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
For macOS, if I understand correctly what you want to do, the way to avoid
using "install_name_tool" to modify the id name of the libpython* dynamic
shared library is to pass the desired name to the link step when building the
shared library
Ned Deily added the comment:
Correction:
DYLD_PRINT_LIBRARIES= /path/to/installed/location/python3
should be
DYLD_PRINT_LIBRARIES= /path/to/installed/location/bin/python3
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg343439
___
Python tracker
<https://bugs.python.org/issue37037>
___
___
Python-bugs-list m
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg343442
___
Python tracker
<https://bugs.python.org/issue37037>
___
___
Python-bugs-list m
Ned Deily added the comment:
(Sorry, my original answer was great except it didn't actually work.
Revisiting.)
--
___
Python tracker
<https://bugs.python.org/is
Ned Deily added the comment:
I don't understand what the issue is here. Can you explain or point to an
explanation of why Homebrew is not linking to SQLite? Is it just not to the
Apple-supplied SQLite?
--
components: +macOS
nosy: +ned.deily, ronaldous
Ned Deily added the comment:
That seems like a reasonable request. We should also check that the Makfile
clean* rules do the right thing. One potential complication: the framework
name is specified by the ./configure --with-framework-name= parameter, so it
may not always be
Ned Deily added the comment:
GPS beat me to it: this definitely should not be backported to either 3.7 or
2.7 since it is a major user behavior change.
--
versions: -Python 2.7, Python 3.7
___
Python tracker
<https://bugs.python.org/issue33
Ned Deily added the comment:
> Can we at least document that the default start method (fork) is now unsafe
> on macOS?
Thanks, I was just going to add that I would accept a doc change for 3.7. But
the wording should be a little clearer that fork has *always* been unsafe on
macO
Ned Deily added the comment:
> To be clear, what is unsafe on macOS (as of 10.13, but even more so on 10.14)
> is calling into the Objective-C runtime between fork and exec.
No, it has *always* been unsafe. What's new as of 10.13/14 is that macOS tries
much harder at runtime to
Ned Deily added the comment:
> To be clear, what is unsafe on macOS (as of 10.13, but even more so on 10.14)
> is calling into the Objective-C runtime between fork and exec.
No, it has *always* been unsafe. What's new as of 10.13/14 is that macOS tries
much harder at runtime to
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg343843
___
Python tracker
<https://bugs.python.org/issue33725>
___
___
Python-bugs-list m
Ned Deily added the comment:
Should we update the Windows and Mac installers to 1.1.1c now?
--
nosy: +ned.deily
___
Python tracker
<https://bugs.python.org/issue37
Ned Deily added the comment:
Thanks for the docstring improvement! It looks like the Library Reference
entry for filter has similar wording in 3.x and 2.7 with regard to "items are
removed". If soneone feels strongly that that is not precise enough, suggest
supplying a separ
Ned Deily added the comment:
New changeset 3dbc43f63c7e056b80d6e28f3812125a09555456 by Ned Deily (Victor
Stinner) in branch '3.6':
bpo-32947: test_ssl fixes for TLS 1.3 and OpenSSL 1.1.1 (GH-11612)
https://github.com/python/cpython/commit/3dbc43f63c7e056b80d6e28f381212
Ned Deily added the comment:
I don't have a strong opinion about backporting to 3.6. With OpenSSL 1.0.2
official support ending at the end of 2019 and 3.6.z retired towards the ned of
2021, there would be a 2-year window where 3.6 is still in security-fix-only
status. But, if we don
Ned Deily added the comment:
New changeset 8ab624b17ba656e9af5a79be6af0cf2911a111ba by Ned Deily (Gregory P.
Smith) in branch '3.6':
[3.6] bpo-35925: Skip SSL tests that fail due to weak external certs or old TLS
(GH-13124) (GH-13252)
https://github.com/python/cpyt
Change by Ned Deily :
--
assignee: ned.deily ->
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python
Ned Deily added the comment:
New changeset 4f06dae5d8d4400ba38d8502da620f07d4a5696e by Ned Deily (Victor
Stinner) in branch '3.6':
bpo-35907, CVE-2019-9948: urllib rejects local_file:// scheme (GH-13513)
https://github.com/python/cpython/commit/4f06dae5d8d4400ba38d8502da620f
Ned Deily added the comment:
The behavior was changed in Python 3.6 for all platforms to catch this error;
see Issue28732.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Ned Deily added the comment:
New changeset 8ea0fd85bc67438f679491fae29dfe0a3961900a by Ned Deily (Miss
Islington (bot)) in branch '3.7':
bpo-26903: Limit ProcessPoolExecutor to 61 workers on Windows (GH-13132)
(GH-13643)
https://github.com/python/cpyt
Change by Ned Deily :
--
versions: -Python 3.5, Python 3.6, Python 3.9
___
Python tracker
<https://bugs.python.org/issue26903>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
FWIW, my opinion on making this kind of wholesale change has not changed: see
the discussion in PR 7800. I think the changes made there were not an
improvement for all the reasons stated, primarily because this now requires
people reading the code base to learn
Change by Ned Deily :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue15590>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ned Deily :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37024>
___
___
Ned Deily added the comment:
Thanks for the analysis and the PR! It turns out the problem is not new to
10.14; as you discovered, it's simply a matter of how may groups a particular
user is in and, with all the system-generated groups, that number may vary from
release to release and
Change by Ned Deily :
--
pull_requests: +13658
pull_request: https://github.com/python/cpython/pull/13773
___
Python tracker
<https://bugs.python.org/issue36
Ned Deily added the comment:
New changeset 0288dd6a5192074fcd5aa0db5d3513c3880209ca by Ned Deily in branch
'master':
bpo-36231: Support building on macOS without /usr/include (GH-13773)
https://github.com/python/cpython/commit/0288dd6a5192074fcd5aa0db5d3513
Change by Ned Deily :
--
pull_requests: +13660
pull_request: https://github.com/python/cpython/pull/13773
___
Python tracker
<https://bugs.python.org/issue33
Ned Deily added the comment:
> One question I have is, can/does SOABI flag removal affect any third party
> package/extension builds in any way, particularly affecting the names of
> files they produce?
Yep, the default file names of C extension modules differ on most/all? Unix-y
Ned Deily added the comment:
Another user-visible difference:
$ ls /tmp/py37/bin/python*
/tmp/py37/bin/python3/tmp/py37/bin/python3.7-config
/tmp/py37/bin/python3.7m-config
/tmp/py37/bin/python3.7 /tmp/py37/bin/python3.7m
/tmp/py37/bin/python3-config
$ ls /tmp/py38/bin/python
Ned Deily added the comment:
New changeset fd1771dbdd28709716bd531580c40ae5ed814468 by Ned Deily (Miss
Islington (bot)) in branch '3.6':
bpo-36742: Corrects fix to handle decomposition in usernames (GH-13812)
(GH-13814)
https://github.com/python/cpyt
Change by Ned Deily :
--
nosy: +lemburg
___
Python tracker
<https://bugs.python.org/issue37180>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Please don’t close this. It’s still an issue that needs to be addressed and I
intend to do so. Thanks.
--
assignee: -> ned.deily
versions: +Python 3.9 -Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<
Ned Deily added the comment:
FWIW, it doesn't fail for me and I don't recall ever seeing a failure like this
on macOS. What hardware? ./python.exe -m test.pythoninfo please!
--
nosy: +ned.deily
___
Python tracker
<https://bu
Ned Deily added the comment:
Also, what utime* results show up in ./configure output? I see
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
--
___
Python tracker
<https://bugs.python.org/issue37
Ned Deily added the comment:
In many installations, the user running Python would not have write access to
the lib directory tree where the compiled byte files need to be created so we
would not want to change the current default behavior. On the other hand, I
could see some times when
Ned Deily added the comment:
WHat kind of file system is @test_28886_tmp/f1 created on?
--
___
Python tracker
<https://bugs.python.org/issue37195>
___
___
Pytho
Ned Deily added the comment:
As I noted on the PR: "I'm not going to get into whether this PR is appropriate
for 3.8 but, assuming it were, I would be very concerned about making a change
of this size and complexity in 3.7 at this stage in its lifecycle."
--
nosy
Ned Deily added the comment:
New changeset fe5f8b9ce2e504d4510cc82129d595015d239634 by Ned Deily (Makdon) in
branch '3.8':
[3.8] bpo-37216: Fix version and filename in Mac using document (GH-13964)
https://github.com/python/cpython/commit/fe5f8b9ce2e504d4510cc82129d595
Ned Deily added the comment:
New changeset c59b137bbfc7eb7a9386bb51c7fea838fc2a by Ned Deily (Makdon) in
branch '3.7':
[3.7] bpo-37216: Fix version and filename in Mac using document (GH-13963)
https://github.com/python/cpython/commit/c59b137bbfc7eb7a9386bb51c7
Change by Ned Deily :
--
assignee: docs@python -> ned.deily
title: mac installation document wrong for python 3.7.3 -> "Using Python on a
Macintosh" chapter of "Python Setup and Usage" doc is out-of-date
versions: +Python 3.8, Python 3.9
2301 - 2400 of 6927 matches
Mail list logo
