Ned Deily added the comment:
See Issue21323 for details of a problem introduced by the original fixes for
this problem and now fixed (except for 3.1 which is now end-of-life).
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
IMO, what third-party libraries are included with the Windows and OS X binary
installers, what versions of them, and when to update them are questions
without firm established policy answers, say in a PEP. In many ways, for the
installers we are performing the
Changes by Ned Deily :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue21990>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The problem you see is being caused by trying to override "prefix" on the
"altinstall" or "install" targets. While Makefiles for many products will let
you do that successfully, you really can't do that with Python's.
Un
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue17101>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
Tal, I'm working on something to make that easier.
--
___
Python tracker
<http://bugs.python.org/issue3068>
___
___
Python-bugs-l
Ned Deily added the comment:
"Also, how many variables would you want to protect from being changed? People
may come up with ideas of changing arbitrary other Makefile variables, and
guarding all of them is just not feasible."
I certainly wasn't contemplating guarding *all
Changes by Ned Deily :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue17131>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
cosmicduck, the recommended and supported way to do this is by specifying the
installation prefix at the configure step, not at the "make install" step:
./configure --prefix=${HOME}/scripts/tools/python/python-3.3.2
make
make install
If done thi
Ned Deily added the comment:
There have been a number of EINTR-releated issues reported in the past, some
unique to BSD-based systems and/or OS X; see for example, Issue9867 and
Issue12268. I don't know that any of them specifically addressed problems with
writes to Python 2 file ob
Ned Deily added the comment:
Yes, an issue not likely to be addressed in Python 2.7. I'm still curious as
to why I'm not able to reproduce the problem, though. I suppose it could just
come down to differences in the system it is running on, like workload, amount
of memory, and/or
Ned Deily added the comment:
Doing a quick look, the results vary. Using current python.org 2.7.8 and 3.4.1
installers, the results are correct. These interpreters are built with Apple
gcc-4.2 (non-LLVM) from Xcode 3.2.6. Other 2.7 and 3.4.x builds I have
available at the moment, including
Changes by Ned Deily :
--
components: +Build -Macintosh
___
Python tracker
<http://bugs.python.org/issue22012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
FTR, the problem also shows up with the current clang-3.4 (3.4.2) and clang3.5
(svn213451-1) packages in Debian testing (on i386), building --with-pydebug and
without, so the issue is not confined to OS X.
--
assignee: ronaldoussoren
Changes by Ned Deily :
--
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX ->
struct.unpack('?', '\x02') returns (False,) when Python is built with clang
___
Python
Ned Deily added the comment:
The problem here is that you are trying to use sys.stdin for two different
purposes: 1. as a data input source for your program using stdin redirected to
a disk file; and 2. for pdb's source of debugging commands, expected to be a
terminal file. By specifyin
Ned Deily added the comment:
(In the future, please just show the test failures and their tracebacks rather
than uploading a tar file.)
The logs show three test failures in test_os:
==
ERROR: test_fds
Changes by Ned Deily :
--
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX ->
struct.unpack('?', '\x02') returns (False,) when Python is built with clang
___
Python
Ned Deily added the comment:
I also can reproduce this on Linux with Python 2.7 but not with 3.4 which uses
a different io system. So the question is: is anyone interested in addressing
this for Python 2 file objects?
--
nosy: +gregory.p.smith
stage: -> needs patch
ti
Ned Deily added the comment:
My reading of the man page is that in the xattr case it can refer to conditions
other than just file system full, e.g.
https://bugzilla.kernel.org/show_bug.cgi?id=12793. Also, Yannick reported that
the volume was apparently not full
Ned Deily added the comment:
Lita, I tried the patch. From the perspective of an OS X user, while I might
expect that using the zoom gesture on a mousepad or using a mousewheel (the
equivalent) to increase or decrease the font size, I would even more expect
scrolling to work especially if
Changes by Ned Deily :
--
nosy: +steve.dower, zach.ware
___
Python tracker
<http://bugs.python.org/issue22028>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
On OS X, the actions associated with trackpad gestures are controlled by the
Trackpad panel of System Preferences. The default settings map the "pinch with
two fingers" gesture to "Zoom in or out" which Tk apps see as Mousewheel
events: n
Ned Deily added the comment:
"However, I figure I still need to create separate bindings for Linux,
"Windows and Mac, right? Or does Tkinter unify all the mousewheel events?
I'm not sure I understand: I think that Tk only provides one MouseWheel event
binding. Keyboard or m
Ned Deily added the comment:
The changes are also causing segfaults when readline is linked with BSD libedit
(the default on OS X) rather than GNU readline:
==
FAIL: test_init (test.test_readline.TestReadline
Ned Deily added the comment:
Currently, readline.c uses #ifdef __APPLE__ to guard libedit-specific code
(there is another open issue to generalize libedit support to other platforms).
--
___
Python tracker
<http://bugs.python.org/issue19
Ned Deily added the comment:
> Is there any reason when turtledemo.__init__ and turtledemo.__main__ should >
> not get docstrings in earlier versions? And the turtledemo.__main__ get the >
> same changes in 3.4?
I think my reasoning was that it was not a bug fix so it
Ned Deily added the comment:
Fixed, thanks!
--
nosy: +ned.deily
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Nice insight, Serhly! The patch addresses the menu concern I brought up in
msg223631 of Issue21933. I evaluated the patch with all three OS X Tk variants
(Cocoa, Carbon, and X11) and it looked good to me. The only review comment I
have is that ideally, with
Ned Deily added the comment:
It may be hard to see what's going on with the code written as a list
comprehension. We could expand it out to something roughly equivalent and
print the first n iterations:
def main():
lista =[1, 4, 5 , 5, 6 , 3 ,1]
def ins(x):
r
Ned Deily added the comment:
Here are some review comments on turtle_demo_v2.patch.
First, the subprocess call to start turtledemo may work ok in your build
directory but it will not work in general. Using the standard idiom for
invoking a new process running the current instance of python
Changes by Ned Deily :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15398>
___
___
Ned Deily added the comment:
Is there any reason to not drop support for Tk 8.3? It appears that the last
release of it, 8.3.5, was in 2002. Is anyone aware of any use of it on
currently supported platforms? The final planned release of 8.4 (8.4.20) was
just a year ago and 8.4 is still
Ned Deily added the comment:
Some results from a quick build/test on OS X 10.9.4 with Xcode 5.1.1 clang and
openssl 1.0.1h from MacPorts (similar results when built with Apple-supplied
openssl 0.9.8y and on OS X 10.5.8 ppc with Apple-supplied openssl 0.9.7l):
- Modules/_ssl.c:2861:52: warning
Ned Deily added the comment:
> did you apply the patch from http://bugs.python.org/issue22023 first?
Sorry, missed that. Let's try again with that applied as well:
OS X 10.9.4 with Xcode 5.1.1 clang and openssl 1.0.1h from MacPorts
- Modules/_ssl.c:2861:52: warning: invalid co
Ned Deily added the comment:
Several review comments on tdemo-font-34-t2.diff:
- Terry's question:
>Ned, with this binding, (ignored on Mac?)
>widget.bind_all('', self._updateFont)
>plain wheel moves scroll as desired while Control-wheel changes font sizes.
>
Ned Deily added the comment:
That warning has been around for some time. The question is: is it something
to be concerned about? I don't know of any ctypes test failures on OS X.
There have been various discussions of the warning in other (non-Python)
contexts, for example,
Ned Deily added the comment:
turtle_demo_v3.patch looks good to me. I have satisfied myself that the
AppleScript works OK with a non-English system. And, while it is a bit of a
kludge for OS X and assuming the rest of the change works OK on Windows and
Linux, I would recommend to Terry that
Ned Deily added the comment:
Ronald:
> I'd slightly prefer to add a hack to the turtledemo main function to force
> itself to the foreground on startup. That way the hack also works when the
> user starts the script in a Terminal window.
That's exactly what the propos
Changes by Ned Deily :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22041>
___
___
Python-bugs-list
Ned Deily added the comment:
This is due to a bug in earlier versions of Cocoa Tk 8.5.x, originally
documented in Issue11055. Unfortunately, Apple is still shipping such a
version in current versions of OS X. One solution is to install a newer
version of Tk 8.5, such as ActiveTcl 8.5.15 and
Ned Deily added the comment:
>If the activate code is moved to macosxSupport.activate(), does the
>following work in EditorWindow.open_turtle_demo?
>cmd = [sys.executable, '-c',
'from idlelib.macosxSupport import activate as A; A()\n'
'from turtledemo.__main
Ned Deily added the comment:
See also Issue1382562 "--install-base not honored on win32".
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.o
Changes by Ned Deily :
--
nosy: +doko
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/issue22100>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
The checkin seems to have broken test_idle and test_ttk_guionly. Typical
failure:
==
ERROR: test_horizontal_range
(tkinter.test.test_ttk.test_extensions.LabeledScaleTest
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg224391
___
Python tracker
<http://bugs.python.org/issue12312>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
As the cited Mageia bug has been closed, there seems to be no reason to keep
this issue open.
--
nosy: +ned.deily
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python track
Ned Deily added the comment:
FWIW, on OS X when IDLE is launched from the Finder, for example by
double-clicking on an IDLE icon, IDLE defaults to using the user's Documents
folder as its working directory. When IDLE is launched from a command line
shell, it uses the current wo
Ned Deily added the comment:
What you are seeing is due to the limitations of binary floating-point
arithmetic. The issue is described in more detail in the Python tutorial:
https://docs.python.org/2/tutorial/floatingpoint.html#tut-fp-issues
--
nosy: +ned.deily
resolution: -> no
Ned Deily added the comment:
When you built 3.4.1, did the _ctypes module build correctly? What happens
when you try to import ctypes?
python3.4 -c 'import ctypes'
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.o
Ned Deily added the comment:
This wouldn't apply to 3.3 since we don't do binary installers for branches in
security-fix mode (as discussed recently in Issue21671). Adding Larry as 3.4
release manager.
--
nosy: +larry, ned.deily
priority: normal -> high
versions:
Ned Deily added the comment:
OK. Does test_ctypes run successfully?
cd /home/ubuntu/python/Python-3.4.1
./python -E -S -m test -v test_ctypes
and then does test_venv run successfully in isolation?
cd /home/ubuntu/python/Python-3.4.1
./python -E -S -m test -v test_venv
Also, what
Ned Deily added the comment:
It looks like the changes associated with Issue11571, released in 3.4.1, cause
this problem when the program supplies its own Canvas object rather than
relying on the turtle module to create a default one.
--
assignee: -> ned.deily
nosy: +ned.deily
st
Ned Deily added the comment:
As a temporary workaround, you could edit turtle.py to revert that change, in
other words, just search for and delete the whole "if sys.platform == 'darwin'"
test:
diff -r d85fcf23549e Lib/turtle.py
--- a/Lib/turtle.py Tue Aug 05 14:02:11
Ned Deily added the comment:
This appears to be a duplicate of open Issue12276.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> 3.x ignores sys.tracebacklimit=0
___
Python tr
Ned Deily added the comment:
Thanks. So apparently the _ctypes module failed to build. You should rerun
"make" in your build directory and find out why _ctypes.so fails to build. If
necessary, show the results here.
--
___
Python trac
Ned Deily added the comment:
This problem has reappeared on some of the freebsd buildbots, for example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%202.7/builds/507
Thanks to a lot of good work by koobs in investigating and documenting the
problems in irc, we have figured
Changes by Ned Deily :
Added file: http://bugs.python.org/file36354/issue21166_3x.patch
___
Python tracker
<http://bugs.python.org/issue21166>
___
___
Python-bugs-list m
Ned Deily added the comment:
This appears to be another variation on the problem recently identified in
Issue21166, namely that the pybuildir.txt Makefile rule can incorrectly import
a shared library module from a previously installed Python instance and, if the
ABIs of the installed and
Ned Deily added the comment:
Thanks for the report. After reviewing the situation, I think this is actually
a code bug rather than a documentation issue; in other words, things should
work like the embedding documentation states.
sysconfig has a complicated history; there are currently 6
Ned Deily added the comment:
As Terry requested, here are a few comments on running
linenumber-text-widget-v1.diff on OS X. Overall, this looks to me to be a
useful option.
1. Having line numbering enabled by default was a bit of a surprise,
particularly in light of 2.
2. The "T
Changes by Ned Deily :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue22208>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for addressing the comments. With linenumber-text-widget-v2.diff:
1. With Tk 8.4, the extension gets a bit further but still fails:
File "/Users/nad/Projects/PyDev/active/dev/3x/t/idlelib/__main__.py", line 9,
in
idlelib.PyShell.mai
Ned Deily added the comment:
>> 1. With Tk 8.4, the extension gets a bit further but still fails:
>I fixed this now. Please let me know how it works now.
Yep, 8.4 now seems to work just fine.
>> 2. I just noticed that the (now) "Line Number" menu item has no visual
&
Changes by Ned Deily :
--
nosy: +doko, meador.inge -ned.deily
___
Python tracker
<http://bugs.python.org/issue22157>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Without more information, it is hard to know exactly what problem you are
seeing but it appears you are trying to run pdb from within the tornado web
server. That may be difficult to do; I'm guessing that the pdb debugger main
loop does not play well wi
Ned Deily added the comment:
Closing, since this problem apparently no longer occurs
--
resolution: -> out of date
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Ned Deily :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue22242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue22248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Committed for release in 2.7.9, 3.4.2, and 3.5.0
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Committed for release in 2.7.9
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
The attached patch should prevent the AttributeError exception when not using a
default Canvas. I now think the overall approach introduced in Issue11571 is
not the best. I plan to commit this fix for now but encourage more robust
solutions in the long term
Ned Deily added the comment:
As identified in Issue22168, the changes introduced here do not work when the
user supplies a Canvas rather than relying on the turtle default. There is a
patch there that should solve that issue. But I now think that the original
approach was not an ideal
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue9205>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
nosy: +gregory.p.smith
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue22274>
___
___
Python-bugs-list mai
Ned Deily added the comment:
Can we close this issue then?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue22272>
___
___
Python-bugs-list m
Changes by Ned Deily :
--
nosy: +orsenthil, pitrou
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue22278>
___
___
Python-bugs-list mai
Changes by Ned Deily :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<http://bugs.python.org/issue22273>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
As far as I can tell, a Posix-compliant system is required to implement fork().
Which platform doesn't?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
Hideaki, thanks for the report.
Josh, yes
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue22320>
___
___
Pytho
Ned Deily added the comment:
Good point, Berker. The general FAQ predates the Developer's Guide. Josh, your
patch looked good; would you care to update it? In any case, if you plan to
contribute further patches (and we hope you do), please be sure to fill out a
contributor form (
Ned Deily added the comment:
Thanks again for the patch! (I did change the wording slightly.)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ned Deily :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue22311>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Perhaps David B can update Tcl and Tk on the buildbot? Note, Tcl/Tk 8.6.2 (and
8.5.16) were just released a few days ago.
--
nosy: +db3l, ned.deily
___
Python tracker
<http://bugs.python.org/issue22
Changes by Ned Deily :
--
assignee: docs@python -> benjamin.peterson
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue22345>
___
___
Py
Changes by Ned Deily :
--
nosy: +michael.foord
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue22344>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
nosy: +ncoghlan, vinay.sajip
___
Python tracker
<http://bugs.python.org/issue22343>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Clearly this breaks running from the build directory for various modules when
their optional C extension module build fails. I'll either change the Setup
shared builds to use a build directory or revert the path changes prior to the
upcoming
Ned Deily added the comment:
Closing as a duplicate of the re-opened Issue17095 (since the changes there
haven't been released yet)
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Modules/Setup *shared* support broken
vers
Ned Deily added the comment:
This problem has been introduced by the initial changes for Issue17095. That
issue has been re-opened and the resolution will be covered there.
--
nosy: +ned.deily
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
s
Ned Deily added the comment:
Should this be a release blocker for 3.4.2?
--
___
Python tracker
<http://bugs.python.org/issue19884>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Should this be fixed for 3.4.2?
--
___
Python tracker
<http://bugs.python.org/issue21112>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Ping. Also this will be presumably be an issue for the approved 2.7.x backport
of ensurepip.
--
versions: +Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issue19
Ned Deily added the comment:
Closing since there have been no further reports of this problem and this
buildbot is no longer connected
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python track
Ned Deily added the comment:
The changes for Issue21383 added calls to "make touch" to build_installer.py so
the initial problem reported here should no longer occur on any OS X installer
build. As to the more general problem of needing to use "make touch" because
Changes by Ned Deily :
--
nosy: +dstufft, ncoghlan, ned.deily
versions: +Python 2.7, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue20
Changes by Ned Deily :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue20417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +bquinlan
___
Python tracker
<http://bugs.python.org/issue22361>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
OS X builds are posix builds so, by default, they dynamically link with the
system-supplied zlib. The particular version varies by release: the most
recent (10.9) supplies zlib 1.2.5. So updating the zlib in Modules should have
no effect on OS X. Does that
Ned Deily added the comment:
If you are reporting an issue with how apsw behaves, be aware that it is a
third-party project, not in the Python standard library. As such, you should
report the issue to its bug tracker (https://github.com/rogerbinns/apsw/issues)
as listed in its PyPI entry
5201 - 5300 of 6927 matches
Mail list logo