Ned Deily added the comment:
Using Serhiy's suggestion, here are patches for 2.7/3.3 and default that
condition the hook function signatures. With these patches, all three branches
compile without warnings and pass test_readline using OS X libedit, readline
6.3-rc2, and an older rea
Changes by Ned Deily :
Added file: http://bugs.python.org/file33937/issue20374_no_cast_3x.patch
___
Python tracker
<http://bugs.python.org/issue20374>
___
___
Python-bug
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:
The change has broken the builds, for example,
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1197.
[ 29/389] test_codecs
Assertion failed: (maxchar >= 0x100), function _PyUnicode_CheckConsistency,
file Objects/unicodeobject.c, line
Ned Deily added the comment:
Duplicate of Issue20520
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue20542>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue20558>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily:
Seen with default (3.4.0) framework builds on OS X 10.9 with ActiveTcl 8.5.15.0:
./configure --enable-universalsdk=/ --with-universal-archs=intel
--enable-framework=/tmp/t/Library/Frameworks
make && make install
cd /tmp/t
/tmp/t/bin/python3.4 -m test
Ned Deily added the comment:
$ /usr/local/bin/python3.3 -m test -w -uall test_idle test_ttk_guionly
[1/2] test_idle
[2/2] test_ttk_guionly
can't invoke "event" command: application has been destroyed
while executing
"event generate $w <>"
(proce
Changes by Ned Deily :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue20567>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue20567>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The combination of just test_idle followed by test_ttk_guionly also produces
the "application has been destroyed" messages on Debian Linux and when run from
a build directory (e.g. not installed) and with 2.7, 3.3, and default.
--
title: test_t
Changes by Ned Deily :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue20573>
___
_
New submission from Ned Deily:
On OS X, most of the IDLE command keyboard accelerators that use the OS X
modifier key do not work correctly with Cocoa Tk, the current native
version of Tk 8.5 and 8.6 used on OS X 10.6 and later releases (and with the
64-/32-bit OS X binary installers from
New submission from Ned Deily:
There is a need for IDLE to provide different default settings depending on
which platform it is running, e.g. Windows, OS X, or other UNIX. That need
need has been most acute for OS X where, for various reasons, tailoring of
default key bindings for IDLE
Ned Deily added the comment:
Here's a patch that refactors many of the OS X customizations in IDLE based on
more granular criteria, e.g. those that should apply to all Tk implementations
vs those that depend on specific ones (Cocoa Tk, Carbon Tk, or X11 Tk) rather
than the bogus cu
Ned Deily added the comment:
(Just to be clear, the Tk situation on OS X has changed substantially since the
original customizations were added by Ronald. So the checks weren't bogus
initially. And I've modified some of them subsequently before understanding
some of the "
Changes by Ned Deily :
--
nosy: +orsenthil
priority: normal -> high
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
It looks like the culprit is _scproxy, an internal C extension, that urllib2
(py2) and urllib.request (py3) use on OS X to access the system configuration
for network proxies. If you aren't using any proxies, a workaround is to
define an environment var
Ned Deily added the comment:
Miki, what is the output of the following on the failing system?
id -G && sw_vers
--
___
Python tracker
<http://bugs.python.org
Ned Deily added the comment:
Perhaps the external pysqlite distribution from PyPI was installed on 2.5.
Kathryn, can you supply the output from the two versions?
import sqlite3
print(sqlite3.version)
print(sqlite3.sqlite_version)
--
nosy: +ned.deily
Ned Deily added the comment:
The test works for me on OS X 10.6 and OS X 10.9. My guess is that the problem
you are seeing is due to a failing lookup of "localhost". What does your
Python report for:
socket.gethostbyname("localhost")
The getaddrinfo(3) man page descrip
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue20607>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
OK, OK, it's not just your machine :=) I was finally able to reproduce the
same failure on a different 10.6 system. I'm still not sure what the
difference between them is but it really doesn't matter. I have a patch
forthcoming to make the test
Ned Deily added the comment:
The committed changes should prevent spurious test failures. Thanks for the
report.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Ned Deily added the comment:
issue19744_ensurepip_install_ok_without_ssl.diff looks good to me. Note,
though, that with it and with ssl support missing, test_ensurepip fails
somewhat obscurely:
==
FAIL
Ned Deily added the comment:
On OS X 10.9 with Cocoa Tk 8.15.0+, Cocoa Tk 8.6, and X11 Tk 8.6:
==
FAIL: test_place_forget
(tkinter.test.test_tkinter.test_geometry_managers.PlaceTest
New submission from Ned Deily:
eef7899ea7ab introduces changes to the documentation build process which
inadvertently breaks OS X installer builds. See, for example:
http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513
Mac/BuildInstaller/build-installer.py should be modified to
Ned Deily added the comment:
Elevating to release blocker pending evaluation by Martin et al.
--
nosy: +larry, loewis, ncoghlan, ned.deily
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
According to the Open Group Base Specification (Issue 7 2013 Issue):
"The setenv() function shall fail if:
[EINVAL]
The envname argument points to an empty string or points to a string containing
an '=' character."
So it seems to me that th
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue20660>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
OTOH, the specification for putenv, which is what is actually used by
posixmodule.c, does not contain that requirement.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setenv.html
Ned Deily added the comment:
Georg, why do you want to cherry-pick this for 3.4.0? As noted in Issue20644,
it definitely breaks OS installer builds and it may break Windows installer
builds as well. We would need to address those problems as wee before rc2,
which seems to me to make this
Ned Deily added the comment:
The installer script wasn't broken, neither was the dmg buildbot. I'm still
not seeing how this change qualifies as one that should be allowed in after
rc1. Perhaps if there were a bug tracker issue that justified it. Still I'll
see what I can
Ned Deily added the comment:
Also Martin should give his blessing wrt the Windows installer builds.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue20
Ned Deily added the comment:
It does affect the distributed content in that the installer scripts for OS X
and Windows are part of the source release and both Martin and I try very hard
to build installers from unmodified source. And the OS X installers are built
from a known vanilla
Ned Deily added the comment:
Thanks, Georg.
--
___
Python tracker
<http://bugs.python.org/issue20661>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
With test_geometry_managers_2.patch, test_tk now passes with all of the
previously tested OS X Tk versions.
--
___
Python tracker
<http://bugs.python.org/issue20
Ned Deily added the comment:
It looks like the new python.org web server configuration was just changed to
no longer gzip robots.txt so the test is no longer failing for me.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue20
Ned Deily added the comment:
... or, more likely, that a robots.txt file is now in place.
--
___
Python tracker
<http://bugs.python.org/issue20719>
___
___
Pytho
Ned Deily added the comment:
Here's another example of an odd test failure apparently caused by test_pydoc
side effects, this using current default tip (same results with the current
cherry pick for 3.4.0rc2):
./bin/python3.4 -m test -w -uall,-largefile test_pydoc test_unicode
Ned Deily added the comment:
Eric, can you take a look at this? It is playing minor havoc with regression
testing for 3.4.0.
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue20
Ned Deily added the comment:
I believe these failures have been corrected for all active branches in the
changes for Issue20695.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_urllibnet.urlretrieve
Ned Deily added the comment:
Interesting. As of last night, I'm no longer seeing 'gzip' encoding and the
test passes for me. But I see some of the buildbots intermittently failing.
Looking at the headers for www.python.org/robots.txt, it appears that the file
is being served
Changes by Ned Deily :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue20727>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
I concur: let's disable the tests for now. If we can do a quick patch and
request a cherry pick from Larry, we can still get this into 3.4.0. To answer
your question, Eric, I normally run tests from a clean, installed location as
part of OS X installer te
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue20732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for looking into it, Eric. Can you open a 3.4 cherry-pick issue for
this so it gets into 3.4.0?
--
___
Python tracker
<http://bugs.python.org/issue20
Changes by Ned Deily :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python, georg.brandl
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
I don't know anything about these programs but it appears libpyuno.so is linked
with a specific version of Python 3. Was it rebuilt linked against Python 3.4,
instead of Python 3.3?
http://packages.ubuntu.com/en/trusty/python3-uno
--
nosy: +ned.
Ned Deily added the comment:
The point is that you may be inadvertently mixing a shared library
(libpyuno.so) linked to a Python 3.3 interpreter with a base Python 3.4
interpreter. Unless python3-uno is very careful to use the stable ABI there is
no guarantee of binary level compatibility
Changes by Ned Deily :
--
nosy: +loewis, ncoghlan
___
Python tracker
<http://bugs.python.org/issue20757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +tim.golden
type: crash ->
versions: -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue20758>
___
___
Py
Ned Deily added the comment:
LGTM
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue20757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +r.david.murray
type: crash ->
___
Python tracker
<http://bugs.python.org/issue20760>
___
___
Python-bugs-list mailing list
Un
Ned Deily added the comment:
This problem is a duplicate of Issue16484.
The URL is generated by pydoc's getdocloc() when you use pydoc explicitly or
through the interactive interpreter's help command. But the doc web server is
not set up to handle links for modules with mixed-
Ned Deily added the comment:
I think you are misunderstanding how del and mutable sequences work. In your
code snippet, the del unbinds the name "root_dir" but it does not alter the
dirnames list object returned by os.path. Try replacing "del root_dir" with
Changes by Ned Deily :
--
assignee: -> georg.brandl
___
Python tracker
<http://bugs.python.org/issue20741>
___
___
Python-bugs-list mailing list
Unsubscrib
Ned Deily added the comment:
Yes, I did indeed mean "dir_list", not "root_dir". Sorry for the confusion.
One point: there is no "copied list". "del dir_list" merely deletes the
binding between the name "dir_list" and the list object
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue20775>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg212255
___
Python tracker
<http://bugs.python.org/issue7511>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
[Note, due to a bug tracker error now fixed, s couple of comments made to this
issue earlier today were dropped. I'm manually adding them here on behalf of
the original submitters.]
At Wed Feb 26 17:05:01 CET 2014, Paul Tunison added the comment:
I can co
Ned Deily added the comment:
At Wed Feb 26 17:09:49 CET 2014, Dhanannjay Deo added the comment:
Confirmed for python 2.7.3 on ubuntu 12.04 lts. Why this issue is still open
after 4 years ?
--
nosy: +Dhanannjay.Deo
versions: -Python 2.6
___
Python
Ned Deily added the comment:
Thanks for the reminder, David. Here are patches for 3.x and 2.7 that include
updated versions of the proposed pyexpat.c and test_pyexpat.py patches along
with a doc update along the lines suggested by David.
--
stage: -> patch review
versions: -Pyt
Changes by Ned Deily :
Added file: http://bugs.python.org/file34241/issue6676_27.patch
___
Python tracker
<http://bugs.python.org/issue6676>
___
___
Python-bugs-list m
Ned Deily added the comment:
Thanks for the report. There was a lengthy discussion of this behavior a few
years ago in Issue3067. At that time it was decided not to change this
behavior for 2.7. I'm not sure if the __future__ "unicode_literals" was
considered then, howev
Ned Deily added the comment:
As Peter notes, .pyc and .pyo files are in general not compatible across Python
versions. PEP 3147 was implemented in Python 3.2 to help avoid the problem you
are seeing by storing .pyc/.pyo files with version-specific filenames. For
Python 2, you need to be
Ned Deily added the comment:
All of the failures I reported are now fixed so I think this issue can be
closed.
--
___
Python tracker
<http://bugs.python.org/issue19
Ned Deily added the comment:
The "Warning -- os.environ was modified by test_ttk_guionly" looks suspicious.
Does the patch for Issue20035 help?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.o
Ned Deily added the comment:
What happens if you add -v (verbose) "... -m test -v -ugui ..." to find the
failing tests?
--
___
Python tracker
<http://bugs.python.o
Ned Deily added the comment:
Sorry, you are going to have supply more information. From the traceback
supplied, it appears the call to subprocess is coming from envoy, which is not
part of the Python standard library. Please re-open if you can supply a test
case demonstrating a problem in
Ned Deily added the comment:
The traceback shows an issue when using envoy, which is not part of the Python
standard library. Assuming you are using the envoy listed in PyPI, I suggest
you ask on the project's issue tracker:
https://github.com/kennethreitz/envoy/issues
--
Ned Deily added the comment:
Crys, as Ronald noted above: "Now that I look at that code again: we can't
extract that code and use it to patch upstream OpenSSL, the
TrustEvaluationAgent framework is a private framework and hence off limits."
It doesn't seem like a good
Ned Deily added the comment:
The particular error you see is caused by code in the setup.py file of the
project you are installing. I suggest you figure out what's going on there:
File "setup.py", line 116, in run
target_data = '/' + os.path.relpath(sel
Ned Deily added the comment:
I think you are misunderstanding the meaning of the width component (e.g. the
10 in your example) of a format specification. As described in the
documentation, width is a decimal integer defining the *minimum* field width,
not the *maximum* field width. As
Ned Deily added the comment:
OK, so the issue is that Python float literals in the range 0.0 < x < 1.0 can
be spelled without a "0" before the decimal point but the built-in format
method for floats appears to always output the leading "0" even in cases where
do
New submission from Ned Deily:
Update the OS X installer build to use SQLite 3.8.3.1 instead of 3.8.3 (see
Issue20465).
--
assignee: larry
components: Build
messages: 212524
nosy: larry, ned.deily
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4
Ned Deily added the comment:
"Fix a bug (ticket 4c86b126f2) that causes rows to go missing on some queries
with OR clauses and IS NOT NULL operators in the WHERE clause, when the
SQLITE_ENABLE_STAT3 or SQLITE_ENABLE_STAT4 compile-time options are used."
http://www.sqlite.org/
Ned Deily added the comment:
Sorry, you were pointed to the wrong tracer. For problems with the new
website, the tracker is:
https://github.com/python/pythondotorg/issues
But, as noted in a reply, the pages you cite should now render properly.
Thanks for reporting it!
https
Ned Deily added the comment:
Thanks for noticing the duplicate. I suggest adding yourself to the nosy list
of Issue4508 and commenting there if you'd like to help things along.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> committed/rejected
status: ope
Ned Deily added the comment:
See also "Modifier Keys" on the Tk Wiki:
http://wiki.tcl.tk/28331
There are both deliberate and accidental platform-specific behavior differences
among Tk implementations.
--
nosy: +ned.deily
___
Pyth
Ned Deily added the comment:
It's not a bug and has nothing to do with pip per se. The PyPI entry of this
package makes no claims that it is supported on Python 3 nor does its README.
PEP 453 does not make any claims to add new capabilities to pip to
automatically try to transform pac
Ned Deily added the comment:
This is existing behavior. The error messages are coming from Distutils doing
a byte compile (producing .pyc) on .py files it is installing. AFAIK, that has
always been treated as a warning in all versions of Distutils; changing that
behavior now could break the
Ned Deily added the comment:
Alas, I don't think there is a bug in the import machinery, either. Note that
puttsx's __init__.py uses a pre-PEP 328 ambiguous relative import:
from engine import ...
Even if there were no syntax errors, in Python 3 that would have to be spelled:
fr
Ned Deily added the comment:
This is most likely a duplicate of Issue20621. A fix for the problem is the
primary motivation for a new maintenance release for which a release candidate
is now available. It would be great if you could test with 3.3.5rc2 and
confirm that the problem no longer
Ned Deily added the comment:
Great, thanks!
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20852>
___
___
Python-bugs-list mai
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue20854>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
>>(I thought the change to not-automatically-getting-sphinx was deferred?)
(The not-automatically-getting-sphinx change is in the default branch but it
has not been cherry-picked for 3.4.0 - and should not be, as agreed upon in
Issue20661.)
-
Changes by Ned Deily :
--
nosy: +belopolsky, lemburg, tim.peters
stage: -> patch review
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Changes by Ned Deily :
--
nosy: +belopolsky, lemburg, tim.peters
___
Python tracker
<http://bugs.python.org/issue20861>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Sorry, the Python bug tracker is not the place to ask about third-party
products. One suggestion though: make sure you entered the full (absolute)
path to the Python 3.3 executable: probably something like
/usr/local/bin/python3.3 or
/Library/Frameworks
Ned Deily added the comment:
Try launching IDLE from a Terminal shell window by typing:
/usr/local/bin/idle3.3
and see if it fails there and, if so, any messages shown. One possibility is
the problem reported in http://bugs.python.org/issue18270 which was fixed in
the IDLE shipped with
Ned Deily added the comment:
Thanks for the update. That is indeed the symptom of the problem documented in
Issue18270. The best solution is to download and install Python 3.3.4 which
has a fix for it.
--
resolution: -> duplicate
stage: -> committed/rejected
superseder: -
Changes by Ned Deily :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20863>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Ned Deily :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue20867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Unfortunately, how getservbyname() and other similar network interface
functions get their data is platform-dependent. /etc/services is a traditional
file location but many modern systems use a database or shared database (e.g.
NIS) and even allow the system
Ned Deily added the comment:
More specifically, the bug that causes the problem was first released in the
2.7.6 release candidate 1 (pre-release, 2013-10-26) and fixed in the official
2.7.6 final release (2013-11-10). So it is somewhat surprising that you would
continually re-encounter it
Ned Deily added the comment:
The fact that "ls" shows a UID of 501 instead of your user name "Charlotte"
strongly suggests you have an inconstantly defined user account. Suggest you
try cresting a new "Administrator" user via "System Preferences" ->
Ned Deily added the comment:
The fact that "ls" shows a UID of 501 instead of your user name "Charlotte"
strongly suggests you have an inconstantly defined user account. Suggest you
try cresting a new "Administrator" user via "System Preferences" ->
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg212953
___
Python tracker
<http://bugs.python.org/issue20873>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
er, "inconstantly" -> "inconsistently"
--
___
Python tracker
<http://bugs.python.org/issue20873>
___
___
5401 - 5500 of 6927 matches
Mail list logo
