Changes by Ned Deily :
--
nosy: +twouters
___
Python tracker
<http://bugs.python.org/issue24727>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Yes, providing Python on OS X via an app bundle, rather than an installer,
seems like the way to go moving forward. But, yes, there are enough potential
compatibility issues that a PEP for it is in order to make sure the major use
cases are identified and
Ned Deily added the comment:
Berker, the part of the patch for test_rlcompleter.py does not apply cleanly.
Here's an updated version of it. Both the fix and the test seem to work as
advertised on current 3.5 tip. It would be nice to fix this finally.
--
nosy: +ned.deily
Added
Ned Deily added the comment:
With current ActiveTcl 8.5.18 on OS X, "TkFixedFont" translates to Monaco 11
point which looks fine on my laptop. I don't have a Retina display handy to
see how it looks there but it's probably an improvement over Courier so
changing the defau
Changes by Ned Deily :
--
components: +Windows -Documentation
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
> Ned, Mark will be opening several appearance issues (see ttk thread on Idle
> list). Do you want to be routinely added as nosy to comment?
No, that's not necessary or desirable. At the moment, I don't think I have
much bandwidth or expertise
Ned Deily added the comment:
I note that the current wording for both "text" and "tail" are careful to allow
for the most general use of the Element class, that is, that it may be used in
non-XML contexts, for example:
"The text attribute can be used to hold additi
Changes by Ned Deily :
--
nosy: +brett.cannon, eric.snow, ncoghlan
___
Python tracker
<http://bugs.python.org/issue24769>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Unfortunately, we didn't test this change with Tk 8.4: TkFixedFont does not
exist in 8.4. This means that, unless the user has already modified the IDLE
configuration to use an explicit font, IDLE linked with Tk 8.4 crashes in
initialization.
$ mv .i
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg248332
___
Python tracker
<http://bugs.python.org/issue24745>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Unfortunately, we didn't test this change with Tk 8.4: TkFixedFont does not
exist in 8.4. This means that, unless the user has already modified the IDLE
configuration to use an explicit font, IDLE linked with Tk 8.4 crashes in
initialization.
$ mv .i
Ned Deily added the comment:
At Larry's request so that we can get 3.5.0rc1 out the door, I've checked in a
temporary fix for 3.5 (and for 3.6) that should prevent the IDLE crash when
linked with Tk 8.4. I'll leave the issue open for Terry to review and provide
the final fix f
Ned Deily added the comment:
This is a regression from previous releases of Python. It was introduced by
fbe87fb071a6 (for Issue22038) which added the use of C built-in functions for
atomic memory access for additional architectures like x86_64. It seems that
the relatively early version of
Ned Deily added the comment:
This is due to an old Tk bug (http://sourceforge.net/p/tktoolkit/bugs/2722/)
still present in the Apple-supplied versions of Tcl/Tk 8.5 on OS X. See
https://www.python.org/download/mac/tcltk/ and/or Issue22566. If you are using
Python 3.4.x from a python.org
Ned Deily added the comment:
Thanks for all of your contributions on this. I've committed a version along
the lines I suggested along with Martin's example.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> cl
Ned Deily added the comment:
A wild guess: could it be dependent on the screen resolution, in particular if
a Mac Retina display is in use? It also could depend on the version of Tk; from
the screenshot it is clear that Guido was not using a python.org version of 3.4
so the out-of-date Apple
Ned Deily added the comment:
I don't think we should hold 3.5.0 for a patch for this. I recommend lowering
the priority and targeting a patch for 3.5.1.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org
Changes by Ned Deily :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue24912>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
There have been other problems reported with MacPorts Python 3.4 using their
default most recent version of the BSD libedit package. As far as I know,
those problems have not yet been resolved but I can't get to the MacPorts issue
tracker at the moment to
Changes by Ned Deily :
--
nosy: +michael.foord, rbcollins -ned.deily, ronaldoussoren
versions: -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue25
Ned Deily added the comment:
For 3.4 and 2.7, the SciPy and matplotlib projects supply pre-compiled wheels
for their distributions. As of this moment, they haven't yet updated their
PyPI entries with 3.5 wheels (.whl files). Until they do, pip would fall back
to trying to build them
Ned Deily added the comment:
We are pursuing the stale CDN cache issue with #python-infra. It appears that,
as it stands, the cached doc pages will expire within a week.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue25
Ned Deily added the comment:
Thanks for the analysis and the patches, Tim. Now that Xcode 7 is released,
we'll need to ensure we fully support the new stubs. But, as you note, the
workaround as always is to make sure that the current Command Line Tools are
installed, the configuration
Ned Deily added the comment:
Brett, was this on OS X 10.10.x or a 10.11 pre-release? test_eintr does not
fail fail for me on either using the most recent Xcode 7.
--
title: test_einter.test_os_open hangs under Xcode 7 -> test_eintr.test_os_open
hangs under Xcod
Ned Deily added the comment:
Due to our maintenance release compatibility guidelines, I don't think it is
possible to change the Tcl/Tk versions for currently released Python versions
(e.g 3.5.x, 3.4.x, and 2.7.x), or, at least, it is not possible to remove
support for 8.5 in them. To
Ned Deily added the comment:
"the install_name_tool lets you point a shared library at a different dependent
shared library than the one it was originally compiled to link against"
Yes, but I'm not sure how we can take advantage of that. First, keep in mind
that there is only
Ned Deily added the comment:
Without more information or a reproducible test case, it is very difficult to
say what's going on. But, from some of the file paths in the crash report, I'm
guessing you are using a third-party package called OOF2 with a
MacPorts-installed Python 2.
Ned Deily added the comment:
I can reproduce the problem using the MacPorts python2.7 but not the
Apple-supplied Python 2.7 or the python.org one. The difference seems to be
that the MacPorts Python is built with the MacPorts-supplied GNU gettext and
its libintl, whereas the others aren&#
Ned Deily added the comment:
Unfortunately, the version of Tcl/Tk shipped by Apple in OS X is old and buggy.
Please install an updated version of Tcl/Tk 8.5, for example from ActiveState,
as explained here:
https://www.python.org/download/mac/tcltk/
--
resolution: -> third pa
Ned Deily added the comment:
As David notes, this issue does not document any problems with Python 3.5
itself. I see at least two issues here. One, you are using virtualenv, a
third-party package, rather than Python's built-in venv. It appears that the
most recent release of virtuale
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg253937
___
Python tracker
<http://bugs.python.org/issue25531>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
As David notes, this issue does not document any problems with Python 3.5
itself. I see at least two issues here. One, you are using virtualenv, a
third-party package, rather than Python's built-in venv. It appears that the
most recent release of virtuale
Ned Deily added the comment:
Alexey, thanks for the simplified test case. I'll look at it further.
--
resolution: third party ->
stage: resolved ->
status: closed -> open
___
Python tracker
<http://bugs.pyth
Ned Deily added the comment:
I've looked at this some more using variations of Alexy's test case and I now
think there are at least two problems here. And both issues have to do with
confusion about exactly where a distribution's header files should be installed
in venvs (c
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue25531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
assignee: -> ned.deily
title: _ssl doesn't build on OSX 10.11 -> _ssl doesn't build on OS X 10.11
without third-party ssl headers
___
Python tracker
<http://bugs.py
Ned Deily added the comment:
"My understanding is that when we build an osx release, we bundle openssl."
Well, no, we don't exactly do that today. We have recently been doing that for
the 10.5 installer because the 10.5 system version of OpenSSL is so old as to
be unusable for
Ned Deily added the comment:
Chris, how exactly are you running this test that fails and where does the test
come from? I may be overlooking something but I do not see any spelling of a
test_ascii_formatted in the Python 3.5 source including its embedded ctypes.
The ctypes shipped with
Ned Deily added the comment:
Thanks for the updates. Since it's not at all clear what the issue is or that
it is Mac-specific, I'm going to bow out of this and remove the Mac tag for now.
--
components: -Macintosh, Tests
nosy: -rona
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue25589>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily:
https://www.openssl.org/news/secadv/20151203.txt
--
components: Build
messages: 255880
nosy: benjamin.peterson, larry, ned.deily, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Update python.org installers to use
Ned Deily added the comment:
Please read the information at the web page linked to in that message you have
been seeing: https://www.python.org/download/mac/tcltk/. As explained there,
the current Pythons downloaded from python.org for OS X dynamically link with
Tcl/Tk 8.5.x, not 8.6.x
Ned Deily added the comment:
As you may know, GNU gcc and gdb have not been included in the standard
development tools shipped with Apple as part of Xcode and the Command Line
Tools for a number of releases, in favor of llvm/clang and lldb. So test_gdb
is typically automatically skipped on
Changes by Ned Deily :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue26012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue26083>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The point still stands that speaking of "the current machine's IP address" is
misleading at best. I'd say either apply Berker's suggested patch or expand
the description to better reflect the real world of multiple interface
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue15809>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
I can't speak to issues with PyQt5 since that is not part of the Python
standard library but you shouldn't need additional configure options just to
build Python itself. Make sure you have installed the latest version of Xcode
for your release via the
Ned Deily added the comment:
OK, thanks for reporting it. A couple of things. I'm not sure why the PyQt5
build is looking for the MacOSX10.10.sdk as you report. There do seem to be
some issues building a universal Python when using a current default Xcode SDK;
I'm going to leave
Ned Deily added the comment:
LGTM on OS X with both the system libedit and a MacPorts GNU readline. Let's
apply this.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Ned Deily :
--
resolution: fixed ->
stage: resolved -> needs patch
___
Python tracker
<http://bugs.python.org/issue21159>
___
___
Python-bugs-
Ned Deily added the comment:
I can no longer reproduce this either so I agree with Mark that it has most
likely been fixed in later versions of Tk. If the problem can be reproduced
with current Tk releases, please re-open.
--
resolution: -> out of date
stage: -> resolved
Ned Deily added the comment:
There is an open earlier issue about test_gdb failures on OS X with Homebrew.
Closing this issue in favor of that one.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> test_gdb failures on
Ned Deily added the comment:
See also duplicate Issue25992. Unless someone has a better idea, I suggest we
just disable test_gdb on OS X or, somewhat more precisely, when Python has been
compiled with LLVM clang.
--
nosy: +Bryce Miller
stage: -> needs patch
versions: +Python
Changes by Ned Deily :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue21263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
resolution: third party ->
stage: resolved ->
versions: -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/i
Changes by Ned Deily :
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue25195>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue25226>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue25351>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue25459>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
I agree that the approach in "try 2" is fine and the runtime check in "try 3"
is overkill. While it is possible to do so, we've never really supported
building on an OS X release n for release m, where m < n, without using the m
SDK o
Ned Deily added the comment:
Martin, thanks for updating the patch. I've left some review comments on
Rietveld. After reviewing it, I think Garrett's original specification is
correct: there is a need for four options to preserve current expected behavior
although the default i
Ned Deily added the comment:
That said, it *might* be OK to change the default behavior to just remove the
"and on OS X" condition: enable building readline with GNU readline if found
on the search paths, possibly modified by CPPFLAGS and LDFLAGS, and, if not
found, use editline i
Ned Deily added the comment:
My understanding is that the "+" is added to the PY_VERSION in
Include/patchlevel.h by the release management process after any tagged
release, whether pre-release or final. So '+" is supposed to be set whenever
CPython is built from an
Changes by Ned Deily :
--
nosy: +jcea
___
Python tracker
<http://bugs.python.org/issue26308>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
Ronald is correct. Apple added O_CLOEXEC to OS X in 10.7. For compatibility
reasons, the python.org 64-bit installers for OS X currently are built to be
compatible with OS X 10.6 on up and do not do runtime checks for OS features
only available on newer releases
Changes by Ned Deily :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue26180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue26253>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
This is only one example of many cases of calls and options that are exposed by
the os module but are not available on specific platforms or platform releases.
It would be a huge documentation effort to try to identify and keep them all
up-to-date. The fourth
Ned Deily added the comment:
Thanks for the report. Closing this issue as a duplicate of Issue23719.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> PEP 475: port test_eint
Ned Deily added the comment:
Make that Issue23718
--
superseder: PEP 475: port test_eintr to Windows -> strptime() can produce
invalid date with negative year day
___
Python tracker
<http://bugs.python.org/issu
Changes by Ned Deily :
--
nosy: +iaslan
___
Python tracker
<http://bugs.python.org/issue23718>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
stage: patch review -> resolved
___
Python tracker
<http://bugs.python.org/issue25709>
___
___
Python-bugs-list mailing list
Un
Ned Deily added the comment:
Thanks for the report but, since 3.5.1 has subsequently been released, I don't
think there is any reason to keep this open. The distributions vendored with
ensurepip - like pip, setuptools, and their dependencies - will typically
become out-of-date afte
Changes by Ned Deily :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue25726>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +davin, sbt
___
Python tracker
<http://bugs.python.org/issue25796>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue25829>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue25833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
I've committed a revised version of the "try 2" patch for release in 2.7.12,
3.5.2, and 3.6.0. The revisions were to better follow the somewhat arcane
conventions of Apple's availability macros, in particular, to take into a
Ned Deily added the comment:
Upon further investigation, the issues I saw building a universal Python when
using a current default Xcode SDK were due to the introduction in Xcode 7 of
the new textual stub libraries in SDKs, the problem described in Issue25136. So
I'm closing this issue
Ned Deily added the comment:
Thanks for the report, Ryan!
--
nosy: +ned.deily
resolution: -> fixed
stage: -> resolved
status: open -> closed
title: grammatical error in documentation -> grammatical error in asyncio
stream documentation
versions:
Ned Deily added the comment:
Also note that installing ActiveTcl 8.6.x has no effect if the tkinter in use
was linked with an 8.5 version of Tcl/Tk, as the one you are using apparently
was. Make sure you have installed the latest version of ActiveTcl 8.5.x and try
again
Ned Deily added the comment:
I'm not able to test it myself at the moment but you could also try ensuring
your 2.7 build is with the most up-to-date ABI for your system:
./configure MACOSX_DEPLOYMENT_TARGET=10.9
2.7 builds do not set this automatically; 3.x builds do.
--
New submission from Ned Deily:
On OS X framework installs, the Mac-specific sub-makefiles do some important
tailoring of IDLE/s config-extensions.def and config-main.def files, among
other things changing Tk some Tk events for more appropriate keyboard bindings
(e.g. "
<http://bugs.py
Ned Deily added the comment:
For 2.7.12 I've committed changes to the Mac/IDLE Makefile so that it now edits
the defaults files in place on install just like the 3.x Makefiles do.
Framework installs of IDLE 2.7 on OS X no longer output startup warnings and,
since the defaults are now in
Ned Deily added the comment:
See Issue26417 for further discussion about the OS X specific tailoring of IDLE
config files and changes to the 2.7 Makefiles to better match the 3.x Makefiles
to reduce the risk of inadvertent platform differences.
--
versions: -Python 3.4
Ned Deily added the comment:
Thanks for the suggestion. Moving the OS X installers to using Tcl/Tk 8.6 is
the subject of Issue15663.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Investigate providing Tcl/Tk 8.6 with OS
Ned Deily added the comment:
Thanks for the additional patch, Jesse. Since we don't have a NetBSD buildbot
and I don't have any NetBSD or OpenBSD systems at hand to do any testing, I'll
take your word for the version checks. If anyone runs into any problems
because of thes
Changes by Ned Deily :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue26372>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
versions: -Python 3.4
___
Python tracker
<http://bugs.python.org/issue25671>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
I've committed Tim's patches with some additional comments for release in
2.7.12, 3.5,2, and 3.6.0 and have added a note about using 'xcode-select
--install' to the Mac/README files. (The Developer's Guide already documents
Changes by Ned Deily :
--
nosy: +David.Edelsohn
___
Python tracker
<http://bugs.python.org/issue26439>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue26440>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue26443>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
nosy: +ncoghlan, yselivanov
___
Python tracker
<http://bugs.python.org/issue26448>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue26465>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for your suggestion. Unfortunately, at the time support for OS X
universal builds was added, it was not anticipated that there would be a need
for that particular combination of architectures, i.e. just PPC-32 and PPC-64,
and, to the best of my knowledge
Changes by Ned Deily :
--
nosy: +ezio.melotti, michael.foord, rbcollins
___
Python tracker
<http://bugs.python.org/issue26481>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Sorry, I am unable to reproduce the problem. My guess is that somehow there is
a version mismatch between the Python executable and the dynamic libraries.
This *could* be caused by a number of things, like environment variable
settings. Suggest trying to
Ned Deily added the comment:
An even more likely scenario: the Python executable you are using is coming
from an older virtualenv. If so, you need to update the virtualenv to include
an up-to-date python executable.
--
___
Python tracker
<h
6401 - 6500 of 6927 matches
Mail list logo
