Amaury Forgeot d'Arc added the comment:
The _PyGILState_Fini function might cause user code to run as well,
it removes the thread-local variable that contains the PyThreadState
for threads, and that contains some Python objects that might contain
arbitrary values (such as the last
synx added the comment:
I dunno if this is helpful, but in the 2.5 module, it parses mailboxes
into rfc822 messages, but then expects them to be email.Message messages
when unparsing them back to a mailbox. mbox2.add(mbox1.popitem()[1])
fails with rfc822 as the default factory. Since the factory
Christian Heimes added the comment:
Guido van Rossum wrote:
- Please clean up the comment in classobject.c starting with Method
objects are used for one purposes: -- to begin with, one purposes is
ungrammatical. Best to remove the (a) bullet and rephrase the whole
thing more like Method
Christian Heimes added the comment:
I've committed the changes in r59189. The documentation still needs
updates. I had only time to fix some of the docs.
--
resolution: - fixed
status: open - pending
__
Tracker [EMAIL PROTECTED]
New submission from Christian Heimes:
Todo:
im_self - __self__
im_func - __func__
im_class - __self__.__class__
instancemethod(func, self, cls) - instancemethod(func, self)
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
keywords: py3k
messages: 57870
nosy:
New submission from Christian Heimes:
The problem is in _ctypes.c:create_comerror() around line 4620.
--
assignee: theller
components: Extension Modules, Windows
keywords: py3k
messages: 57871
nosy: theller, tiran
priority: high
severity: normal
status: open
title: Changes to
vila added the comment:
Well I was confused.
In fact, I have a working http/1.1 client which indeed works around that
close.
HTTPConnection.close() must be called once the response has been
processed or the next request can't be handled since
HTTPConnection.__state is not _CS_IDLE.
Christian Heimes added the comment:
I've created another patch to add VS 2008 support to distutils. The new
patch requires you to copy the msvccompiler.py first:
$ cd Lib/distutils
$ svn copy msvccompiler.py msvc9compiler.py
$ cd ../..
$ patch -p0 py3k_vs2008_4.patch
Martin, if you are going
Changes by Raymond Hettinger:
--
assignee: - rhettinger
nosy: +rhettinger
versions: +Python 2.6 -Python 2.5
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1746088
_
Changes by Raymond Hettinger:
--
assignee: tim_one - rhettinger
nosy: +rhettinger
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1045
__
___
Python-bugs-list mailing
Guido van Rossum added the comment:
Crys, why don't you give it a try yourself? It's quite easy to write
such a simple substitution.
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1504
__
Amaury Forgeot d'Arc added the comment:
The slowdown is due to the new function _PyObject_LengthHint: on my
Win2K machine,
the command
python -m timeit tuple(1 for _ in xrange(3))
answers:
10 loops, best of 3: 4.14 usec per loop
By adding a line return rv; on the second line of
Raymond Hettinger added the comment:
I'll take a look at it next week -- want to think through the various
cases. The current setup provides nice speedups when the length_hint
is available. Possibly, it may be worthwhile to skip that check when
the input is a generator. For the most part,
Guido van Rossum added the comment:
No, _PyGILState_Fini does not invoke any python code
You're right. It calls PyThread_delete_key(). I thought this would
delete entries from a dictionary (thereby potentially invoking Python
code via Py_DECREF()), but it doesn't -- it just frees some memory.
Raymond Hettinger added the comment:
FWIW, the 2.4 to 2.5 timing difference came from renaming __len__ to
__length_hint__. This was at Guido's request so that the value of bool
(iter(obj)) would always be True. The consequence of the change was
that we lost the fast slot lookup for __len__
Facundo Batista added the comment:
Fixed in the trunk, rev 59195.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1755179
_
___
Python-bugs-list mailing list
Unsubscribe:
Christian Heimes added the comment:
Added fix_methodattrs with an unit test in r59196. Can you check it please.
By the way how do you know my IRC nick? Are you lurking in #python? :)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1504
Thomas Heller added the comment:
Christian Heimes schrieb:
New submission from Christian Heimes:
The problem is in _ctypes.c:create_comerror() around line 4620.
The code tries to populate a dict with methods and finally pass them to
PyErr_NewException(_ctypes.COMError, NULL, dict);
I
Bill Janssen added the comment:
That's because the socket.py code has been adapted (the first word I wrote
there was perverted :--) to deal with this case. That is, the close() has
been rendered meaningless because of the explicit reference counting in
socket.py. But the right solution is to
Guido van Rossum added the comment:
It works, though the __self__.__class__ substitution is technically
wrong -- it creates a single NAME node whose contents is that string,
while in the parse tree it should really be three tokens. But as it
works, I wouldn't worry about it.
I saw you sign a
Christian Heimes added the comment:
You are too fast. I haven't written a fixer for new.instancemethod yet.
Do we need one?
--
status: closed - open
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1504
__
Changes by Maarten Thibaut:
--
components: Library (Lib)
nosy: mthibaut
severity: normal
status: open
title: func alloca inside ctypes lib needs #include alloca.h on solaris
type: compile error
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
How should I issue a warning in the new module? Should and can I check
for the -3 warning option or should I warn w/o checks for the -3 option?
from warnings import warn as _warn
_warn(The 'new' module is not supported in 3.x,
DeprecationWarning, 2)
New submission from Maarten Thibaut:
On Solaris, alloca() is a #define which is inside alloca.h.
Ctypes fails to compile because the #define is missing. Please fix by
adding the following at the front of these 2 files:
#if defined (__SVR4) defined (__sun)
# include alloca.h
#endif
Changes by Maarten Thibaut:
--
components: +Extension Modules -Library (Lib)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1506
__
___
Python-bugs-list mailing list
Tom Culliton added the comment:
Looking at the subprocess.py code it occurred to me that it never checks
if the value of self.pid returned by os.fork is -1, this would mean that
later it runs waitpid with -1 as the first argument, putting it into
promiscuous (wait for any process in the group)
Guido van Rossum added the comment:
There's C code like this:
if (Py_Py3kWarningFlag
PyErr_Warn(PyExc_DeprecationWarning,
apply() not supported in 3.x) 0)
return NULL;
I don't know how to check for that flag in Python though -- we
Changes by Guido van Rossum:
--
assignee: - theller
nosy: +theller
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1506
__
___
Python-bugs-list mailing list
New submission from Mark Dickinson:
In Python2.5 and the current trunk, construction of a complex number from two
floats
loses the negative sign of a negative zero in the imaginary part.
complex(-0., 0.).real # behaves as expected
-0.0
complex(0., -0.).imag # loses sign of zero
0.0
There
Tom Culliton added the comment:
Good question. The documentation I was reading was mute on the subject
so I made a reasonable guess. Does it throw an exception instead?
Guido van Rossum wrote:
Guido van Rossum added the comment:
Looking at the subprocess.py code it occurred to me that
Guido van Rossum added the comment:
Looking at the subprocess.py code it occurred to me that it never
checks if the value of self.pid returned by os.fork is -1
What makes you think os.fork(0 can return -1? It's not C you know...
_
Tracker [EMAIL PROTECTED]
Guido van Rossum added the comment:
Committed revision 59203.
Anthony, is this OK to backport to 2.5.2?
--
assignee: - anthonybaxter
nosy: +anthonybaxter, gvanrossum
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1507
Guido van Rossum added the comment:
Yes, like all system calls in the os module.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1731717
_
___
Python-bugs-list mailing
New submission from Joseph Armbruster:
I found two code blocks that look as if they can be safely removed:
From _csv.c:
/* begin 2.2 compatibility macros */
#ifndef PyDoc_STRVAR
/* Define macros for inline documentation. */
#define PyDoc_VAR(name) static char name[]
#define
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
There's C code like this:
if (Py_Py3kWarningFlag
PyErr_Warn(PyExc_DeprecationWarning,
apply() not supported in 3.x) 0)
return NULL;
I
Maarten Thibaut added the comment:
forgot to mention the files:
Modules/_ctypes/callproc.c
Modules/_ctypes/libffi/src/sparc/ffi.c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1506
__
Georg Brandl added the comment:
Okay, checked in as r59205.
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1496
__
___
Georg Brandl added the comment:
Will it be backported?
--
nosy: +georg.brandl
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1755179
_
___
Python-bugs-list
New submission from Peter Mawhorter:
The current documentation for the sqlite3 module on the web fails to
make any mention of the fetch* functions posessed by the Cursor class
of that module. It in fact gives no indication of how one should
extract results from sql queries. The docstrings in
New submission from cfk:
bltinmodule.c:
PyDoc_STRVAR(open_doc,
open(name[, mode[, buffering]]) - file object\n\
\n\
Open a file using the file() type, returns a file object.);
Help for file() is detailed, which would lead people to use file over
open. given that file() is removed in py3k, I
New submission from Bill Fenner:
When a field has internal line breaks, e.g.,
foo,bar
baz
biff,boo
that is actually 3 lines, but one csv-file row. csv.reader() converts
this to ['foo', 'bar\nbaz\nbiff', 'boo']. This is a reasonable
behavior.
Unfortunately, csv.writer() does not use the
Changes by Bill Fenner:
--
components: +Library (Lib)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1511
__
___
Python-bugs-list mailing list
Unsubscribe:
Bill Fenner added the comment:
I realized that my description was not crystal clear - the file being
read has \r\n line terminators - in the format that I used later, the
input file is
foo,bar\r\n
baz\r\n
biff,boo\r\n
__
Tracker [EMAIL PROTECTED]
Gregory P. Smith added the comment:
release25-maint and trunk (2.6) appear to do the correct thing when
testing on my ubuntu gutsy linux x86 box. test script and file attached.
The problem is reproducable in a release24-maint build compiled 2007-11-05.
--
nosy: +gregory.p.smith
Added
Gregory P. Smith added the comment:
attaching the test input file. use od -x or similar to compare the
new.csv output with issue1511.csv to see if the problem happened.
its 2.4.. that may be old enough to be considered dead
Added file: http://bugs.python.org/file8817/issue1511.csv
45 matches
Mail list logo
