Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue8246>
___
___
Python-
Gregory P. Smith added the comment:
wrapping select in an eintr handler that loops like SocketServer_eintr.diff is
fine.
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/iss
New submission from Alf P. Steinbach :
Python 3.1.1 in Windows XP Prof, appears to be a Windows-only problem
Effect: on program exit the interpreter crashes with exception 0xc417
STATUS_INVALID_CRUNTIME_PARAMETER at address 0x78588389, which appears to be in
[msvcr90.dll].
To reproduce
Alf P. Steinbach added the comment:
It now seems almost certain that it's /necessary/ to not have run any Python
programs for a while (say, 10 minutes?) in order for the bug to manifest when
using Ctrl C in the enclosed program.
Also, I forgot to mention, the SEH exception occurs *whil
Alf P. Steinbach added the comment:
Thanks for explaining that.
However, the first bug I ever reported was #7681, "Use floor division in
appropiate places in the wave module.", fixed in 3.1.2.
And the tracker search does not find this bug by id.
Nor does it find it by specifying
Gregory P. Smith added the comment:
i don't see your attachment brett.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue5099>
___
___
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue8513>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
Nice dabeaz.
One potential concern with "dabeaz_gil.patch 2010-04-25 21:13" is that it
appears to always leave the gil_monitor thread running. This is bad on
mobile/embedded platforms where waking up at regular intervals prevents
advanced sl
Gregory P. Smith added the comment:
since the other discussion is ongoing on issue7946 i posted my comment there.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue8
Gregory P. Smith added the comment:
i'm +0.7 on fsencode/fsdecode going into os.path.
My bikeshed 0.7? They're also useful for dealing with environment variables
which are not strictly filesystem (fs) related but also suffer from the same
issue requiring surrogate escape. But
Gregory P. Smith added the comment:
in the unittests there is some use of 'compress' and 'decompress'
mixed with 'zlib.decompress'. which one is right (i'm only looking at
the diff so i can't see if they were imported from zlib or if the
zlib. is requi
Gregory P. Smith added the comment:
I think your partA patch makes sense.
It would benefit from fsencode/fsdecode functions rather than manually doing
the 'surrogateescape' thing everywhere.
Also, could you add a unittest for os._execvpe to test it
Gregory P. Smith added the comment:
+.. function:: fsencode(value)
+
+ Encode *value* to bytes for use in the file system, environment variables or
+ the command line. Use :func:`sys.getfilesystemencoding` and
+ ``'surrogateescape'`` error handler for str, and keep bytes uncha
Gregory P. Smith added the comment:
Build on the os._execvpe unittest I added in py3k r81001. Protected functions
are perfectly fine things to unittest.
--
___
Python tracker
<http://bugs.python.org/issue8
Gregory P. Smith added the comment:
I think your patch looks good Brett.
--
___
Python tracker
<http://bugs.python.org/issue5099>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
Committed to trunk in r81012. though as this missed 2.7beta2 its possible that
will be rejected and this becomes a 3.x only feature.
I'm porting to py3k now.
--
versions: +Python 3.2
___
Python tracker
Gregory P. Smith added the comment:
And reverted in trunk r81013. Multiple buildbot problems from the initial
commit due to the unittest.
This is likely to be py3k only at this point.
I do believe sig.patch.v3 is fine, but its the test_pdb2 unittest that is
difficult to make work well
Gregory P. Smith added the comment:
my bad. hopefully r81019 fixes that.
--
___
Python tracker
<http://bugs.python.org/issue8513>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
bsddb3 isn't in py3k.
--
priority: high -> normal
versions: -Python 2.5, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.or
Gregory P. Smith added the comment:
zliberrors.patch looks good to me.
On Mon, May 10, 2010 at 3:37 PM, Antoine Pitrou wrote:
>
> New submission from Antoine Pitrou :
>
> This is a patch to use our own error descriptions when the zlib doesn't
> provide anything in parti
Gregory P. Smith added the comment:
patch looks good.
--
___
Python tracker
<http://bugs.python.org/issue8672>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
Thanks for the test! I'll take a look and likely commit this later.
--
assignee: -> gregory.p.smith
___
Python tracker
<http://bugs.python.or
New submission from Gregory P. Smith :
C Python has a real wart in that standard types and library functions that are
implemented in C do not always accept keyword arguments:
>>> 'xx'.find('xx', 4)
4
>>> 'xx'.find('xx', start=4
Gregory P. Smith added the comment:
"There is still another possible leak if the PyMem_Realloc
return NULL (i.e., the system is out of memory), but I don't think it
worth fixing."
Do it. It looks easy: a Py_DECREF(it) before the return
Gregory P. Smith added the comment:
reading 5.patch over...
Any particular reason for using buf_size = 32 when the length isn't
known up front? add a comment saying why (or that its just a magic
guess). anyways it sounds like a fine starting value. picking
anything "better"
New submission from Gregory P. Smith:
The resolution to http://bugs.python.org/issue1608 looks like it'll add
a -fwrapv gcc flag when building python. This works around the issue
nicely on one compiler (gcc) but doesn't fix our fundamentally broken code.
We should fix all depen
Gregory P. Smith added the comment:
"""code that has been audited and fixed in the past will again be
vulnerable."""
That code wasn't properly audited or fixed if it depended on integer
overflow behavior.
Anyways, I'm glad we have the flag to disable
Gregory P. Smith added the comment:
heh if thats the only warning gcc -Wstrict-overflow gives then I've
mistitled the bug. Fixed. It'll take some manual code review.
Anyone know if the commercial analysis tools we've run the code base
through in the past can fi
Stephen P. Schaefer added the comment:
I'm not sure of the scope of the "block" to which you're referring. As
patched, the code returns a Tcl_Obj representing 0 length unicode
string, which appears to me to be the correct behavior, and works for
the applications I use (ori
Stephen P. Schaefer added the comment:
It looks good to me (to the extent that means anything). I'm doing an
rpmbuild now with your patch applied to the Fedora 7 .src.rpm, and I'll
start using the result on my workstation ASAP.
__
Tracker <[EM
Stephen P. Schaefer added the comment:
Mr. van Rossum's patch, applied to the Fedora 7 .src.rpm, is working for me.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Gregory P. Smith added the comment:
nice. ping a mac developer for what to do with the darwin stuff that
you commented out.
It'd also be nice to have unit tests for the new behavior. Though i
don't think we have many (any?) of that type of regression test right
now. Such a test wou
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1731717>
_
___
Python-bugs-list
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1336>
__
___
Python-bugs-list mailing list
Unsubs
Gregory P. Smith added the comment:
The uploaded file appears to be derives from Python 2.4.1 (tags/r241).
i've uploaded an actual diff between the two.
regardless, Thomas's point about disabling it -before- the fork() is true.
Added file: http://bugs.python.org/file9186/di
Gregory P. Smith added the comment:
I've just attached a diff against trunk that I believe fixes this (based
off of jba's patch). Unit tests pass but that doesn't say a whole lot
given that this is a hard to reproduce timing/scheduling related bug.
Would someone please
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1736792>
_
___
Python-bugs-list
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1703448>
_
___
Python-bugs-list
Gregory P. Smith added the comment:
threadingbug.py doesn't fail for me on trunk (linux), anyone else?
the output I get is always:
Main thread ID: -134346528
Secondary thread ID: -135349328
Exception KeyError: KeyError(-134346528,) in ignored
--
nosy: +gregory.p.
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1404925>
_
___
Python-bugs-list
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue595601>
___
Python-bugs-list mailing list
New submission from Gregory P. Smith:
This probably applies to 3.0 as well but i have not tested it there.
Here are some sample failures:
=== A ==
Exception in thread Thread-01 (most likely raised during
interpreter shutdown):Exception in thread Thread-03
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1339>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue829951>
___
Python-bugs-list mailing list
Changes by Gregory P. Smith:
--
assignee: -> gregory.p.smith
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue829951>
___
Python-bugs-li
Changes by Gregory P. Smith:
--
assignee: -> gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1339>
__
___
Python-bugs-list mailing li
Gregory P. Smith added the comment:
Yes i believe it is unrelated to any recent change.
I can reproduce both behaviors on my OS X 10.4 dual core mac using
Python 2.5.1.
Python 2.3 on the mac appears to get stuck in a loop when run stand
alone but gets a memory access fault when run under gdb
Gregory P. Smith added the comment:
Fixed in trunk (2.6) r60015.
--
resolution: -> accepted
status: open -> closed
versions: +Python 2.5, Python 2.6
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Gregory P. Smith added the comment:
and in r60017 on release25-maint for inclusion in 2.5.2.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue829951>
___
Gregory P. Smith added the comment:
Accepted and applied, with appropriate documentation updates.
In svn trunk r60020 for 2.6.
--
resolution: -> accepted
status: open -> closed
versions: +Python 2.5, Python 2.6
__
Tracker <[EMAIL PROTECTE
Gregory P. Smith added the comment:
gah, sorry i misread the report. you are correct.
--
versions: +Python 2.4, Python 2.5, Python 2.6
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Gregory P. Smith added the comment:
agreed, during shutdown the other threads should be stopped. anything
to do this complicates acquiring and releasing the GIL by adding another
check to see if we're shutting down.
brainstorm: I haven't looked at the existing BEGIN_ALLOW_T
Changes by Gregory P. Smith:
--
status: pending -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1035>
__
___
Python-bugs-list mailing li
Gregory P. Smith added the comment:
fixed in trunk r60104. i'm backporting it to 2.5 and 2.4.
--
resolution: -> fixed
versions: +Python 2.5, Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Gregory P. Smith added the comment:
r60111 undid part of r60104 that added an unnecessary else and
indentation. svn diff -r60103:60111 of Lib/subprocess.py is a nice
clean patch.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Gregory P. Smith:
--
assignee: -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Gregory P. Smith added the comment:
fixed in trunk r60115 (2.6).
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Gregory P. Smith added the comment:
r60113 in release25-maint, r60114 in release24-maint.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Gregory P. Smith added the comment:
fixed in trunk r60116 (2.6). and release25-maint r60117 (2.5.2).
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Gregory P. Smith added the comment:
The issue here was that reading more data than will fit into an in
memory string fails. While the zipfile module could detect this in some
cases, it is not really worth such a runtime check. This is just a fact
of python and of sane programming, if you&#x
Gregory P. Smith added the comment:
this failure also occurs on simple zip files created using infozip's zip
with -e to "encrypt" the contents. debugging...
__
Tracker <[EMAIL PROTECTED]>
<http://b
Gregory P. Smith added the comment:
Fixed in r60121 (2.6). zip file decryption "check" bytes were more
complicated than the existing code supported. Algorithm updated.
--
resolution: -> fixed
status: open -> closed
versions: +Python
Gregory P. Smith added the comment:
a code snipped using a database d that demonstrates this:
c = d.cursor()
d.close()
print >>sys.stderr, "database closed before cursor"
del c
print >>sys.stderr, "cursor deleted and we didn't crash!&q
Gregory P. Smith added the comment:
why not just do this?
finally:
with _active_limbo_lock:
self.__stop()
try:
self.__delete()
except:
pass
(i believe with works on locks? if not turn that into an acquire, try
Changes by Gregory P. Smith:
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1221598>
_
Gregory P. Smith added the comment:
accepted, committed as svn r60188 for 2.6. I also cleaned up the retr*
and stor* doc strings.
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Gregory P. Smith added the comment:
Looks good. Fixed in r60190 (2.6). And r60191 for release25-maint (2.5.2).
--
assignee: gvanrossum -> gregory.p.smith
keywords: +patch
resolution: -> fixed
status: open -> closed
_
Tracker <[EMA
Gregory P. Smith added the comment:
oh, whoops. not a security issue. should i undo it or let Martin?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1336>
__
__
Gregory P. Smith added the comment:
thanks. applied (well, they will be when svn.python.org comes back)
On 1/22/08, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
>
>
> Giampaolo Rodola' added the comment:
>
> Could I propose the following docstring cor
Gregory P. Smith added the comment:
4.5 support was put in a while back
--
nosy: +gregory.p.smith
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Gregory P. Smith:
--
priority: normal -> low
resolution: -> wont fix
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Gregory P. Smith added the comment:
Works for me in 2.5 and 2.4 isn't getting bug fixes anymore.
>>> import dbhash
>>> d = dbhash.open('x.db', 'w')
>>> d['e'] = 'Eee'
&g
Gregory P. Smith added the comment:
BerkeleyDB 3.3 through 4.5 are supported. 4.6 support has been checked
in and 4.7 (not yet released) support is supposedly on its way from
someone at oracle.
Versions older than 3.3 are too difficult (and too buggy) to support.
You're on your own i
Gregory P. Smith added the comment:
ReST format docs that cover what is actually implemented and wrapped in
python would be good. We need a volunteer willing to go through and do it.
--
assignee: gregory.p.smith ->
nosy: +jcea
title: Python 2.3 bsddb docs need update -> Python
Changes by Gregory P. Smith:
--
assignee: -> gregory.p.smith
keywords: +64bit, easy
nosy: +gregory.p.smith
priority: -> normal
versions: +Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Gregory P. Smith:
--
assignee: -> janssen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1223>
__
___
Python-bugs-list mailing list
Uns
Gregory P. Smith added the comment:
the docs I see in the URL you give are correct as it states 'two and
four byte unsigned integer respectively' for H and L. However the
example is missing the < for little-endian; I'll add that.
Also, I notice that the struct module do
Gregory P. Smith added the comment:
eew, so the struct module does map as documented to the C types listed
in the docs. yuck. regardless, changing the Ls to Is will fix the
tutorial document code. I'll do that.
I believe there are also other instances of wrong uses of L in struct in
the
Gregory P. Smith added the comment:
The documentation for the struct module says:
"short is 2 bytes; int and long are 4 bytes; long long (__int64 on
Windows) is 8 bytes"
and lists 'l' and 'L' as the pack code for a C long.
As it is implemented today, the docu
Gregory P. Smith added the comment:
A significant portion of the python standard library is broken due to
incorrect use of the struct module on LP64 platforms. I'm attaching a
patch that should clean it up.
I need Mac OS X people to confirm that the Mac changes are sane.
Its possible tha
Gregory P. Smith added the comment:
Anders J. Munch on python-dev correctly says:
You overlooked the words "Standard size and alignment are as follows"
that start the quoted paragraph. It's a little confusing because
standard size is not the default. The default is platform
Gregory P. Smith added the comment:
The giant patch was unnecessary, I misread what the struct module was
actually doing. Auditing all uses of struct in the standard library the
only ones that look suspicious to me are:
Lib/posixfile.py
and all of the uses in Lib/plat-mac/
posixfile is
Gregory P. Smith added the comment:
yes i'll take a look at this weekend.
jcea is doing his bsddb development in the pybsddb.sf.net project svn
repository for the time being. I'll be merging his changes back into
the python tree.
We can get him python svn access soon but i wanted to
Gregory P. Smith added the comment:
Fix committed as r60544 in trunk and r60545 in release25-maint.
i assume it'll be merged into py3k in the regular py3k merge sweeps.
--
resolution: -> accepted
status: open -> closed
versions: +Python 2.5,
New submission from Gregory P. Smith:
ftplib does not support ftp over SSL / TLS as described in RFC 4217.
This would be a nice thing for someone wanting to contribute something
to add.
--
components: Library (Lib)
messages: 62217
nosy: gregory.p.smith
severity: normal
status: open
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2016>
__
___
Python-bugs-list mailing list
Unsubs
Gregory P. Smith added the comment:
This appears to have been fixed in 2.5 and trunk. 2.4.x is old and in
security fixes only mode so I wouldn't expect to see this in any
official 2.4.x source tree released in the future unless the bdfl
changes his mind on that. here's the patch to
New submission from Gregory P. Smith:
Some common python utilities had problems on Feb 29 this year when
parsing dates using format strings that did not include a year in them.
>>> time.strptime('Feb 29', '%b %d')
Traceback (most recent call last):
File &quo
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
I updated the subject to better reflect what this is.
My guess is that the test code itself has issues and is asserting
something that isn't quite guaranteed to be true.
--
title: py3k-pep3137: failing unit test
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
working on this now. foo = 'abcdefghijklmnop'
2.x 32-bit long: zlib.crc32(foo) returns -1808088941
2.x 64-bit long: zlib.crc32(foo) returns 2486878355
This is because PyInt_FromLong() happily fits the value into a signed
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
question: should I also make 64-bit 2.x return a signed value as well to
be consistent with 32bit python 2.x?
Consistency in case someone ever pickles the value and sends it to
another python instance of a different word length wo
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
fixed.
3.0 always returns unsigned.
2.6 always returns signed, 2**31...2**31-1 come back as negative integers.
trunk r61449
branches/py3k r61459
--
resolution: -> fixed
status: open
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
i'll take a look at this during the sprint.
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Gregory P. Smith <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 3.0
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1747858>
_
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
i'd say the patch is fine.
on linux ioctl takes an int.
on openbsd it takes an unsigned long.
on something else it might even take its own type like an ioctl_t.
regardless, treating the parameter as either a long or unsigne
Changes by Gregory P. Smith <[EMAIL PROTECTED]>:
--
keywords: +64bit
title: ioctl doesn't work properly on 64-bit OpenBSD -> ioctl request argument
broken on 64-bit OpenBSD or OS X
__
Tracker <[EMAIL PROTECTED]>
<http://bu
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
We really could use an automated pybench runner on a dedicated machine
driven by a buildbot feeding its results into a database so that we had
a record of exactly when/what caused performance changes over time.
This sounds remarkabl
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
fixed in trunk r61540.
I'm leaving this open until i backport it to release25-maint.
--
resolution: -> remind
versions: -Python 2.6
_
Tracker <[EMAIL PROTECTED]>
<
Gregory P. Smith <[EMAIL PROTECTED]> added the comment:
backported to 2.5 in r61542 and r61544.
it'll go into py3k via the regular merges from trunk.
The fix just changed the int -> long and 'ii' -> 'll' and added unit
test coverage.
The patch attached to
Changes by Gregory P. Smith <[EMAIL PROTECTED]>:
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
601 - 700 of 3452 matches
Mail list logo
