Ned Deily n...@acm.org added the comment:
For what it's worth, the python.org installers for Mac OS X do include a
libpython shared library. As of Python 2.7 (and 3.2), the installer includes a
symlink to make it easier to find:
$ cd /Library/Frameworks/Python.framework/Versions/2.7/lib
$ ls
Changes by Ned Deily n...@acm.org:
Removed file: http://bugs.python.org/file19480/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10243
___
___
Hagen Fürstenau ha...@zhuliguan.net added the comment:
The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem
to be broken.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10300
Ask Solem a...@opera.com added the comment:
ah, this is something I've seen as well, its part of a bug that I haven't
created an issue for yet.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10305
Georg Brandl ge...@python.org added the comment:
Fixed in r86157.
--
nosy: +georg.brandl
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10286
___
Changes by Georg Brandl ge...@python.org:
--
assignee: - pitrou
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10293
___
___
Georg Brandl ge...@python.org added the comment:
I'm sorry, the actual revision is r85970. Why should it be irrelevant for
other branches?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10198
Martin Spacek pyt...@mspacek.mm.st added the comment:
It turns out this isn't just a problem with array.array. It's a problem with
Python's file.write() as well. Here's my test code:
# file.write() test:
FOURGBMINUS = 2**32 - 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in
Martin Spacek pyt...@mspacek.mm.st added the comment:
I suppose someone should confirm this problem on Py 2.6?
--
components: +Extension Modules, Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9015
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
It's still an issue with 2.7, and even with 3.2a2, see issue9611.
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9015
Martin Spacek pyt...@mspacek.mm.st added the comment:
We've got a near duplicate Issue9015. This thread seems more considered though
:) Note that writing more than 2**32-1 bytes at once results in a hung process
with 100% CPU in 64-bit Windows, which has to be killed with Task Manager. So I
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Fortunately, the lower-level write() has no such bug, at least when used in
binary mode as FileIO does: it's almost a direct call to WriteFile().
This issue is more considered because it's not a bug in the Microsoft CRT, but
in the
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
Patches for getpath.c in Python 2.7 and 3.2a3:
2.7 chunk#2: copy_absolute() would use uninitialized data if getcwd()
failed. The fix is equivalent to what 3.2a3 does.
3.2a3 chunk#2: search_for_exec_prefix() did 'unsigned value
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
dlmalloc uses mremap() which is undeclared on Linux, needs _GNU_SOURCE.
This can break at least on hosts where void* = 64 bits and int (default
return type) 32 bits, since some bits in the return type are lost.
A minimal patch
Changes by Baiju M baiju.m.m...@gmail.com:
--
nosy: +baijum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10297
___
___
Python-bugs-list mailing
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
In Python 2.7 and 3.2a3, Modules/_io/textio.c uses signed:1 bitfields.
They have value -1 or 0 in two's complement, but are not used thus here:
gcc complains of bitfield = 1 overflow. If the point was that they
are assigned
Ezio Melotti ezio.melo...@gmail.com added the comment:
It should be noted that, if we re-use assertSameElements, the default behavior
should be preserved for compatibility with 3.1, and that is different (and
possibly less useful) than the one of assertItemsEqual. Ambiguities could be
solved
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10310
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10308
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10309
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10133
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10086
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2921
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10070
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10231
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue960325
___
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9611
___
___
Changes by Michael Foord mich...@voidspace.org.uk:
Removed file: http://bugs.python.org/file19483/static.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9732
___
Changes by Michael Foord mich...@voidspace.org.uk:
Removed file: http://bugs.python.org/file19484/test_static.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9732
___
Antoine Pitrou pit...@free.fr added the comment:
About the issue, I'd suggest to just clamp the length to 2**32-1, and
don't bother retrying; leave this to the buffered layer.
Yes, I think it's reasonable.
(or perhaps clamp to something page-aligned, such as 2**32-4096).
Also, the signal
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
Signal handlers that can change errno, must restore it.
I enclose a patch for 2.7, 3.2a3/Modules/signalmodule.c
which also rearranges the code to make this a bit easier.
The patch does if (errno != save_errno) errno =
Michael Foord mich...@voidspace.org.uk added the comment:
Further updated implementation. Now handles data descriptors correctly but
removes the code that resolves the builtin descriptors (calling __get__ on slot
and attribute descriptors).
As it was resolving some descriptors but not all,
Changes by Michael Foord mich...@voidspace.org.uk:
Added file: http://bugs.python.org/file19490/test_static.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9732
___
Antoine Pitrou pit...@free.fr added the comment:
This is a good idea IMO. It would be better if you minimized style changes, so
that the patch is easier to review.
Also, is the while loop around write() necessary here?
--
nosy: +exarkun, loewis, pitrou
stage: - patch review
versions:
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment:
Thank for pointing this out. I've looked at bytearray and
bytes implementations, they actually return unsigned value.
I fixed this in r86159(py3k) and r86160(release31-maint).
--
___
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
Parser/intrcheck.c:intcatcher() can do FILE* operations, which can
deadlock if the interrupt happens while a FILE* operation on the same
FILE holds a mutex for the FILE. I've seen this happen elsewhere.
It'd rather be a pity to
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10312
___
___
Python-bugs-list
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
Parser/intrcheck.c:intcatcher() should do the same. Covered in Issue
10312.
Antoine Pitrou writes:
This is a good idea IMO. It would be better if you minimized style
changes, so that the patch is easier to review.
I'm afraid
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: - theller
nosy: +theller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10309
___
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +amaury.forgeotdarc
stage: - patch review
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10310
___
Antoine Pitrou pit...@free.fr added the comment:
The behaviour of weakrefs here mirrors what is already done for __del__
exceptions. Using warnings would mean that exceptions can get silenced
implicitly (for example, if an exception happens twice at the same location)
which is not very
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no:
--
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10231
___
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no:
--
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10133
___
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no:
--
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10308
___
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no:
--
versions: +Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10309
___
___
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no:
--
versions: +Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10312
___
Julian python_...@somethinkodd.com added the comment:
Thank you, Antoine, you make a good point.
In my example, I am suppressing the warning, which, I agree isn't a good idea.
In my real life usage, I was getting an unexpected exception in a callback in
code written by another person. I
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
This issue is not really relevant on Windows:
- signals are actually run in a new thread specially created.
- errno is a thread-local variable; its value is thus local to the signal
handler, same for WSAGetLastError().
--
nosy:
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment:
I've created the patch to fix this. (This patch comes from
#9055)
--
keywords: +patch
Added file:
http://bugs.python.org/file19492/py3k_check_if_gui_is_really_available.patch
___
Python
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp:
--
dependencies: -test_issue_8959_b fails when run from a service
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9931
___
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
Amaury Forgeot d'Arc writes:
This issue is not really relevant on Windows:
- signals are actually run in a new thread specially created.
- errno is a thread-local variable; its value is thus local to the
signal handler, same
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Nice. Then I suggest a config macro for whether this is needed.
Either a test for windows, or an autoconf thing in case some Unixes
are equally sensible. (Linux isn't, I checked.)
I'm quite sure that all Unixes invoke signal
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
A test giving a strange warning can make a poor user nervous. Here's
a minimal patch to calm his nerves. It would be better to only give
the message if python -b (not -bb) is active, but I do not know how.
diff -prU2
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
Once upon a time, Terry J. Reedy wrote:
Hallvard, do you still consider this a live issue?
If this general behavior remains, yes.
It's been a while since I had a computer without these libraries to
test it on. (Which is why I
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
Amaury Forgeot d'Arc writes:
OTOH this is really a micro optimization.
[this = only saving/restoring errno when needed]
True, but practically nothing is officially safe to do in signal
handlers, so it's good to avoid code which
R. David Murray rdmur...@bitdance.com added the comment:
I don't see any bytes warnings when I run test_os with -b or -bb on linux on
py3k trunk. (If there were such a warning and it was expected, the fix would
be to capture the warning and ignore it.)
Under what circumstances do you see
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
R. David Murray writes:
I don't see any bytes warnings when I run test_os with -b or -bb on
linux on py3k trunk. (If there were such a warning and it was expected,
the fix would be to capture the warning and ignore it.)
Under
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +flox, gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
___
Antoine Pitrou pit...@free.fr added the comment:
[this = only saving/restoring errno when needed]
True, but practically nothing is officially safe to do in signal
handlers, so it's good to avoid code which can be avoided there.
If one can be bothered to, that is.
I think it is extremely
Antoine Pitrou pit...@free.fr added the comment:
By the way, I'd like to clear out a potential misunderstanding: the function
you are patching doesn't call Python signal handlers in itself (those
registered using signal.signal()). It only schedules them for later execution.
If you want to
STINNER Victor victor.stin...@haypocalc.com added the comment:
I wrote a small function to call WriteConsoleOutputA() and
WriteConsoleOutputW() in Python to do some tests. It works correclty, except if
I change the code page using chcp command. It looks like the problem is that
the chcp
STINNER Victor victor.stin...@haypocalc.com added the comment:
sys_write_stdtout.patch: Create sys.write_stdout() test function to call
WriteConsoleOutputA() or WriteConsoleOutputW() depending on the input types
(bytes or str).
--
keywords: +patch
Added file:
Χρήστος Γεωργίου (Christos Georgiou) t...@users.sourceforge.net added the
comment:
http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx
If you want any kind of Unicode output in the console, the font must be an
“official” MS console TTF (“official” as defined by the Windows
Shashank shashank.sunny.si...@gmail.com added the comment:
I had uploaded an incorrect patch. New corrected patch against trunk (on Mac OS
uploaded).
--
Added file: http://bugs.python.org/file19494/zipdecrypt.patch
___
Python tracker
Changes by Shashank shashank.sunny.si...@gmail.com:
Removed file: http://bugs.python.org/file19494/zipdecrypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
___
Changes by Shashank shashank.sunny.si...@gmail.com:
Added file: http://bugs.python.org/file19495/zipdecrypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
___
New submission from Antoine Pitrou pit...@free.fr:
This patch makes sorting of keys when encoding a dict into JSON faster by not
calling pure Python code.
--
components: Library (Lib)
files: jsonsort.patch
keywords: patch
messages: 120418
nosy: pitrou
priority: normal
severity: normal
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
+1
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10314
___
Antoine Pitrou pit...@free.fr added the comment:
Ok, committed in r86169.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10314
___
Éric Araujo mer...@netwok.org added the comment:
I asked that because I didn’t see the fix backported :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10198
___
Changes by Eric Smith e...@trueblade.com:
--
title: str.format_from_mapping() - str.format_map()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6081
___
Eric Smith e...@trueblade.com added the comment:
Committed to 3.2 in r86170.
--
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6081
R. David Murray rdmur...@bitdance.com added the comment:
Can you give the exact command line you are using to run it, and the OS and
version, and perhaps a printenv? I can't reproduce it in 3.1 or 3.2a3.
--
___
Python tracker rep...@bugs.python.org
R. David Murray rdmur...@bitdance.com added the comment:
Running it with -E and seeing if that changes the behavior would also be useful.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10313
Georg Brandl ge...@python.org added the comment:
I always to the backports batched for these minor and docs fixes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10198
___
Changes by Éric Araujo mer...@netwok.org:
--
keywords: +needs review
nosy: +alanmcintyre
stage: - patch review
versions: +Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10298
Éric Araujo mer...@netwok.org added the comment:
Perfect, sorry for doubting you ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10198
___
___
Sandro Tosi sandro.t...@gmail.com added the comment:
The attached patch implements the same tests of byte for string objects.
--
assignee: - sandro.tosi
stage: - patch review
Added file: http://bugs.python.org/file19497/issue3699-py3k-v2.patch
___
Julien ÉLIE jul...@trigofacile.com added the comment:
Hi Steven,
I also don't understand why START_TLS and AUTHINFO need to change
how the module is interfaced to (separating log in/authentication, etc)
Because once you have used AUTHINFO, STARTTLS is no longer a valid command in a
session.
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10243
___
Terry J. Reedy tjre...@udel.edu added the comment:
I am closing this as some combination of wrong, inapplicable, out-of-date, and
postponed.
1. In 3.1, ssl *is* documented as optional in the sense of dependent on an
external library. This module uses the OpenSSL library. It is available on
Martin v. Löwis mar...@v.loewis.de added the comment:
I propose a different solution: On Windows, instead of calling write(), we call
WriteFile directly. We try to faithfully follow the CRT implementation as much
as possible, knowing that what we write to actually is a binary file (in
Antoine Pitrou pit...@free.fr added the comment:
I propose a different solution: On Windows, instead of calling
write(), we call WriteFile directly.
If I'm not mistaken, WriteFile takes the length as a DWORD, which is
still 32 bits under Win64.
--
New submission from Henning Hraban Ramm hra...@fiee.net:
The docs tell us that smtplib.SMTP_SSL was only changed in 2.6, but it is new
(i.e. it didn't exist in 2.5.x).
--
assignee: d...@python
components: Documentation
messages: 120432
nosy: d...@python, hraban
priority: normal
Max Skaller max.skal...@gmail.com added the comment:
On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily rep...@bugs.python.org wrote:
Ned Deily n...@acm.org added the comment:
For what it's worth, the python.org installers for Mac OS X do include a
libpython shared library. As of Python 2.7 (and
Martin v. Löwis mar...@v.loewis.de added the comment:
If I'm not mistaken, WriteFile takes the length as a DWORD, which is
still 32 bits under Win64.
Oops, ignore me, then... I agree that clamping is fine, assuming the
buffering layer takes that into account.
--
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file19498/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10243
___
Antoine Pitrou pit...@free.fr added the comment:
Well, there's this strange-looking thing in PyMemoryView_GetContiguous:
if (buffertype == PyBUF_SHADOW) {
/* return a shadowed memory-view object */
view-buf = dest;
mem-base = PyTuple_Pack(2, obj, bytes);
... but I
Antoine Pitrou pit...@free.fr added the comment:
Done in r86174.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10293
___
Antoine Pitrou pit...@free.fr added the comment:
I've made cosmetic changes and applied in r86175 (3.2) and r86176 (3.1). Thank
you!
--
priority: high - normal
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
New submission from Peter Hall peter.f.h...@nasa.gov:
I am running the following :
Linux Centos version 2.6.18
Python version 2.5
tk version 8.5
tcl version 8.5
I have a Python GUI program (importing Tkinter and tkFileDialog)
which prompts the user to select a (one to many) list of file
Changes by Peter Hall peter.f.h...@nasa.gov:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10316
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
I guess you're not seeing them because Victor silenced them a couple of days
ago in r85902.
Hallvard, if you update your py3k working copy, do these warnings disappear?
--
nosy: +pitrou
___
Python
Ned Deily n...@acm.org added the comment:
It's called Python because that's the way frameworks on OS X are generally
structured: the shared library file has the same name as the framework. The
Apple developer docs have lots of information on frameworks.
Prior to 2.7 and the upcoming 3.2
Antoine Pitrou pit...@free.fr added the comment:
This sounds dangerously like a micro-optimization to me, and I'm not sure an
additional API is ok for that.
--
nosy: +gregory.p.smith, pitrou
___
Python tracker rep...@bugs.python.org
R. David Murray rdmur...@bitdance.com added the comment:
Ah, then this report is probably out of date. I just realized that I ran my
3.2a3 test incorrectly, so my report that I didn't see them there is invalid.
--
___
Python tracker
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
On a second thought... is there another example where a *blocking* stream does
not write all the data without raising an exception?
--
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
On a second thought... is there another example where a *blocking* stream
does not write all the data without raising an exception?
Why do you think this would be somehow an example for a blocking stream
that does not write all data
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Why do you think this would be somehow an example for a blocking stream
that does not write all data without raising an exception?
Well, that's what clamping means, isn't it?
--
___
Python
Antoine Pitrou pit...@free.fr added the comment:
On a second thought... is there another example where a *blocking*
stream does not write all the data without raising an exception?
It can happen with pipes or sockets, if some buffer can only store part
of the data. Or any regular stream if a
1 - 100 of 126 matches
Mail list logo
