Changes by Gregory P. Smith:
--
title: Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so
we catch this sooner (and more directly) - [py3k] Fix dumbdbm, which fixes
test_shelve (for me); instrument other tests so we catch this sooner (and more
directly
Changes by Gregory P. Smith:
--
assignee: - greg
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1007
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Gregory P. Smith added the comment:
The BerkeleyDB library operates on bytes only. Unicode doesn't make
sense as a key without converting it to a particular encoding first.
Use the unicode object's encode() method if you need to use it as a
database key or create a wrapper object or subclass
Changes by Gregory P. Smith:
--
assignee: - greg
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1725856
_
___
Python-bugs-list mailing list
Unsubscribe:
http
Gregory P. Smith added the comment:
this was marked 'open' and 'fixed' at the same time. that should be an
invalid state. it was indeed fixed eons ago.
--
nosy: +greg
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Gregory P. Smith added the comment:
This code deletes the item that the internal database cursor created by
the db.first() call is pointing at. Then when db.first() is called
again it tries to reuse the same cursor. Now to decide if thats the
expected behavior or a real problem and how to fix
Gregory P. Smith added the comment:
My first description wasn't quite accurate. What was happening is that
the __delitem__(i) call by del was closing the existing cursor and
saving the key it was pointing to and the first() and last() methods
were creating a new cursor and trying to restore
Gregory P. Smith added the comment:
Committed to HEAD as r57378
Committed to release25-maint as r57379
Committed to py3k as r57380
--
resolution: - fixed
status: pending - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1725856
Gregory P. Smith added the comment:
looks like someone already committed the one liner dumbdbm latin-1 fix.
But the meat of this patch is the unit test improvements.
I had to fix test_whichdb to exclude dumbdbm as that has no file for
whichdb to test.
committed to py3k as r57419
Changes by Gregory P. Smith:
--
nosy: -greg
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583946
_
___
Python-bugs-list mailing list
Unsubscribe:
http
Gregory P. Smith added the comment:
Does the existing python SSL implementation allow it to be used over
something other than a socket? If so then yes that makes sense, but
otherwise its best to leave its inheritance from socket.error so that
code that works when handed a regular socket can
New submission from Gregory P. Smith:
I've converted _bsddb.c to use the py3k buffer API for all data and keys
it takes as input. All tests now fail with this error:
BufferError: Cannot make this object read-only.
This presumably results from this call:
PyObject_GetBuffer(obj, view
New submission from Gregory P. Smith:
This is my svn diff of a py3k Modules/_bsddb.c converted to use the
buffer API. I'm submitting it here as so it doesn't get misplaced as it
currently won't work until bytes objects support PyBUF_LOCKDATA (a
separate bug)
--
assignee
Changes by Gregory P. Smith:
--
priority: normal -
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1035
__
___
Python-bugs-list mailing list
Unsubscribe:
http
New submission from Gregory P. Smith:
The Lib/pdb.py debugger fails in the py3k branch.
Traceback (most recent call last):
File /usr/local/gps/python/py3k/Lib/pdb.py, line 1247, in main
pdb._runscript(mainpyfile)
File /usr/local/gps/python/py3k/Lib/pdb.py, line 1173, in _runscript
Gregory P. Smith added the comment:
committed to py3k branch using SIMPLE instead of LOCKDATA: r57610
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1036
Gregory P. Smith added the comment:
I sent an initial patch to the mailing list. Its too late to be ready
for 3.0a1; I'll fix it up next week.
--
assignee: - gregory.p.smith
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1035
Gregory P. Smith added the comment:
i'll take care of this.
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1189216
Gregory P. Smith added the comment:
i'll take care of it. any more info in the interim will be appreciated.
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1060
Gregory P. Smith added the comment:
can you provide a test zip file demonstrating the problem?
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
type: crash - behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1003
Gregory P. Smith added the comment:
that looks good to me.
fixed in:
2.6 trunk r58023
release25-maint r58024
py3k r58025
--
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1112
Gregory P. Smith added the comment:
socket.error now inherits from IOError as of trunk r58067:
Change socket.error to inherit from IOError rather than being a stand
alone class. This addresses the primary concern in
http://bugs.python.org/issue1706815
python-dev discussion here:
http
Gregory P. Smith added the comment:
Attaching the most recent patch (minor update from the second one i sent
to the python-3000 mailing list to initialize ob_readonly_exports = 0 in
the appropriate places).
Current mailing list discussion is pointing out that the name LOCKDATA
means something
Gregory P. Smith g...@krypto.org added the comment:
I've committed this feature just in time for 3.2beta1 (so it can't be said i'm
adding a feature after the beta ;). r87026
It still needs tests and documentation. It doesn't break any existing tests.
I'll take care of that after some sleep
Gregory P. Smith g...@krypto.org added the comment:
r87027 has it for py3k / 3.2. needs backporting to the other branches.
--
nosy: +gregory.p.smith
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10622
Gregory P. Smith g...@krypto.org added the comment:
I have to agree that the name assertCountEqual does not work well for me as
something I can read and really comprehend what it is going to do without
searching for the docs or implementation to double check. (not that
assertItemsEqual did
Gregory P. Smith g...@krypto.org added the comment:
fyi - since I didn't chime in earlier on this: I think you made the right
choice with what was decided in msg122413 and implemented in the renaming done
in r86910 and the work done in issue10242
Gregory P. Smith g...@krypto.org added the comment:
Paul Giovanni: yes I hadn't given the windows side of things any thought when
I made the change for beta1.
Milko: The DISREGARD_FDS approach is basically what I was intending to do.
Also, there really wasn't any objection to going ahead
Gregory P. Smith g...@krypto.org added the comment:
The close_fds default has been fixed in r87206 to remove the DeprecationWarning
and remain False on Windows. It changes to True on POSIX.
--
___
Python tracker rep...@bugs.python.org
http
Gregory P. Smith g...@krypto.org added the comment:
Milko's subprocess-00/01/02 patch set have been committed with minor
modifications in r87207 r87208. Thanks, especially for the test cases!
Is there anything else left that we know about for this bug
Gregory P. Smith g...@krypto.org added the comment:
Bug fix, unittest and documentation added in r87229. Thanks!
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6559
Gregory P. Smith g...@krypto.org added the comment:
I updated the documentation and changed the close_fds default on Windows to be
True when possible per Giovanni's suggestion in r87229. That keeps the API and
defaults as consistent as possible across all platforms.
--
resolution
Gregory P. Smith g...@krypto.org added the comment:
P.S. Yes I will be backporting all of this to subprocess32.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7213
Gregory P. Smith g...@krypto.org added the comment:
r87233 fixes the OSError escaping from wait() issue when SIGCLD is set to be
ignored. (to appear in 3.2beta1; it is a candidate for backporting to 3.1 and
2.7)
--
___
Python tracker rep
Gregory P. Smith g...@krypto.org added the comment:
sorry, i meant 3.2beta2 above.
release27-maint: r87234 targeting 2.7.2
release31-maint: r87235 targeting 3.1.4
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Gregory P. Smith g...@krypto.org added the comment:
rhettinger's fastcount.patch looks good to me. a couple style nits but they're
minor.
no space between if and (? yuck. short variable names like it? yuck.
but the code looks good otherwise. i'm all for it.
--
nosy
Gregory P. Smith g...@krypto.org added the comment:
Ripping HTTP 0.9 support _out_ flys directly in the face of be lenient in
what you accept and strict in what you produce.
I do not mind removing support from http.server. But http.client needs to be
able to communicate with any random
Gregory P. Smith g...@krypto.org added the comment:
Given the 6961 issue I'm happy to change my position and say we nuke the 0.9
client support.
Anyone who _needs_ that can grab this old code or write trivial code for their
poor server's needs
Gregory P. Smith g...@krypto.org added the comment:
In your back traces notice that the size= argument is clearly nonsensical.
Regardless, i can't reproduce this on any of my systems (I don't have a suse
system of any sort). If that is the only place you are seeing this I strongly
suspect
Gregory P. Smith g...@krypto.org added the comment:
unassigning, i don't had time to look at this one.
--
assignee: gregory.p.smith -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3566
Gregory P. Smith g...@krypto.org added the comment:
As belopolsky said... *please* move this development into version control. Put
it up in an Hg repo on code.google.com. or put it on github. *anything* other
than repeatedly posting entire zip file source code drops to a bugtracker
Gregory P. Smith g...@krypto.org added the comment:
FWIW, the example pasted in the bug was the smallest one he could come up
with. in reality we were never calling .__del__() explicitly. We ran into
the problem due to a __del__ method triggering a __getattr__ call and the
__getattr__ ending up
Gregory P. Smith g...@krypto.org added the comment:
it happens on 3.2 (py3k head).
--
Added file: http://bugs.python.org/file20208/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10794
Gregory P. Smith g...@krypto.org added the comment:
The only thing that could cause this error is if the Modules/_posixsubprocess.c
subprocess_cloexec_pipe function fails either in the pipe2() call or if
HAVE_PIPE2 is not defined one of the fcntl() calls.
Can you look to see if HAVE_PIPE2
Gregory P. Smith g...@krypto.org added the comment:
This bug has brought up a broader issue. the pipe2 syscall on Linux is very
new. It is perfectly reasonable to expect a Python binary will be compiled
against a C library that has a pipe2() function but run on a system with an
older (pre
Gregory P. Smith g...@krypto.org added the comment:
This bug has brought up a broader issue. the pipe2 syscall on Linux is very
new. It is perfectly reasonable to expect a Python binary will be compiled
against a C library that has a pipe2() function but run on a system with an
older (pre
Gregory P. Smith g...@krypto.org added the comment:
I've added some code comments on http://bugs.python.org/review/7978/show
overall I think the patch is right, I pointed out one thing to clean up and I
think the unittest can be greatly simplified by using stubbed out mock
select.select
Gregory P. Smith g...@krypto.org added the comment:
fwiw a unified fork-and-exec API implemented in C is what I added in
Modules/_posixsubprocess.c to at least avoid this issue as much as possible
when using subprocess.
--
___
Python tracker rep
Gregory P. Smith g...@krypto.org added the comment:
patch looks good. committed in r87710 for 3.2. needs back porting to 3.1 and
2.7 and optionally 2.6.
--
assignee: rnk - gregory.p.smith
resolution: - accepted
___
Python tracker rep
Gregory P. Smith g...@krypto.org added the comment:
Doing this makes sense, i'm taking to closer look to see where it should be
done.
--
assignee: - gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9535
Changes by Gregory P. Smith g...@krypto.org:
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4188
Changes by Gregory P. Smith g...@krypto.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4188
Gregory P. Smith g...@krypto.org added the comment:
The code surrounding the p2c file descriptors in subprocess has changed a bit
recently since this issue was filed. someone still needs to come up with a way
to reproduce it.
--
assignee: gregory.p.smith
Gregory P. Smith g...@krypto.org added the comment:
r87726 for release31-maint
r87727 for release27-maint - this required a bit more fiddling as _block and
_started and _cond were __ private.
--
versions: -Python 3.1, Python 3.2
___
Python tracker
Gregory P. Smith g...@krypto.org added the comment:
Attached is a patch for Python 2.6 release26_maint for reference incase someone
wants it. That branch is closed - security fixes only.
--
keywords: +patch
status: open - closed
versions: -Python 2.7
Added file:
http
Gregory P. Smith g...@krypto.org added the comment:
that race condition, if thats what this is, is likely not OS X specific. the
child process could complete or close its fds before we reach that code on any
OS. We either need to guard these io.open(p2c*...) lines against EBADF
OSError's
Gregory P. Smith g...@krypto.org added the comment:
its still a problem, even the C path has to call close() a million times in
that case. thats a huge number of wasted syscalls. fixing this is blocking on
a good way to get the list of open fds.
I have seen other subprocess code do it using
Gregory P. Smith g...@krypto.org added the comment:
sorry, i saw the patches committed and thought that had fixed it. oops. still
more to be done.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4188
Gregory P. Smith g...@krypto.org added the comment:
Here's a patch that implements this behavior. It is too late in the 3.2
beta/rc cycle to get this into 3.2. Consider it for 3.3. I'd like a review.
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file20251
Gregory P. Smith g...@krypto.org added the comment:
Yes I'd do it in PyOS_AfterFork. Simpler patch based on gdb's attached.
This could also use a test but as it involves signals and race conditions,
making a deterministic test for this is difficult as it.
If we added testing hooks
Gregory P. Smith g...@krypto.org added the comment:
eek, thanks for noticing that!
r87740 fixes this in py3k. backporting to 3.1 and 2.7 now.
--
nosy: +barry
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http
Gregory P. Smith g...@krypto.org added the comment:
r87741 3.1
r87742 2.7
--
resolution: accepted - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6643
Gregory P. Smith g...@krypto.org added the comment:
Off the top of my head I don't _think_ so.. at least for posix. I'm not sure
about the implications of the if mswindows: code in there though.
--
___
Python tracker rep...@bugs.python.org
http
Gregory P. Smith g...@krypto.org added the comment:
This is likely solved in py3k 3.2 with the C _posixsubprocess.c module. The
pipe creation and cloexec flag setting is all done atomically when possible,
and at least with the GIL held when not. close_fds also now defaults to True
Gregory P. Smith g...@krypto.org added the comment:
IMO, if we give the illusion that the interpreter was actually killed,
we should equate KeyboardInterrupt with SIGINT; any uncaught
KeyboardInterrupt should consequently always lead to raising SIGINT.
Agreed. Plus that is easier
Gregory P. Smith g...@krypto.org added the comment:
btw, I will be backporting all recent subprocess changes to
http://code.google.com/p/python-subprocess32/
there have been a lot of changes recently, i was waiting for that to settle
down before bring it up to current. 3.2rc1 sounds like
Gregory P. Smith g...@krypto.org added the comment:
Generally there is no guarantee that a buffered object works properly when
the raw IO object raises some exception intermittently
I disagree. EINTR is a classic case of this and is something that buffering IO
layers deal with all the time
Gregory P. Smith g...@krypto.org added the comment:
IMNSHO it should but that would violate our release practices to do it this
late in the cycle. I expect the release manager to decline.
It isn't a critical issue, the end result is that people will hard code the
constants into their own
Gregory P. Smith g...@krypto.org added the comment:
Rather than depending on the internal details of ForkingMixIn in your
BaseServer.serve_forever modification I'd prefer to see that simply call
self._cleanup()
Define a do-nothing _periodic_cleanup method in BaseServer. ForkingMixIn
should
Gregory P. Smith g...@krypto.org added the comment:
documentation updated in r88352. thanks!
--
assignee: docs@python - gregory.p.smith
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Gregory P. Smith g...@krypto.org added the comment:
The need to call p1.stdout.close() has now been documented as part of
issue7678. Python 3.2's subprocess also has restore_signals=True as its
default behavior so SIGPIPE is restored by default.
I do not think it is appropriate to to add
Gregory P. Smith g...@krypto.org added the comment:
Your patch makes sense to me. I'll commit it after the 3.2 release for 3.2.1.
The elease manager can feel free to commit it earlier if it is bothering an
important buildbot.
--
assignee: - gregory.p.smith
Gregory P. Smith g...@krypto.org added the comment:
I believe that is good. I'll commit it after the 3.2 release has been cut
(we're in release candidate release blocker only lockdown right now).
Looking at ForkingMixIn.collect_children() there appears to be another buglet:
it loops over
Changes by Gregory P. Smith g...@krypto.org:
--
assignee: - gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11109
___
___
Python
Gregory P. Smith g...@krypto.org added the comment:
fwiw http://bugs.python.org/issue6643 recently fixed on issue where a mutex was
being closed instead of reinitialized after a fork. more are likely needed.
Are you suggesting to use pthread_atfork to call pthread_mutex_init on all
mutexes
Gregory P. Smith g...@krypto.org added the comment:
Yeah, I'm trying to figure out what I was thinking then or if I was just plain
wrong. :)
I was clearly wrong about a release being done in the child being the right
thing to do (issue6643 proved that, the state held by a lock is not usable
Changes by Gregory P. Smith g...@krypto.org:
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11197
Gregory P. Smith g...@krypto.org added the comment:
Agreed, fixing this is going to be too complex for 3.2.0, it'll be done for
3.2.1.
Reading over the http.server Simple and CGI HTTPRequestHandler code I see there
many problems with the way this code does things today.
General:
* I'm
Gregory P. Smith g...@krypto.org added the comment:
fyi - while I still need to update it now that 3.2 final has been released, the
http://code.google.com/p/python-subprocess32/ project has a backport of the
_posixsubprocess stuff from python 3.2 for use on Python 2.x
Gregory P. Smith added the comment:
This bug will be taken care of by PEP 3137
http://python.org/dev/peps/pep-3137/ being implemented.
Anyways, no the _bsddb.c changes that I checked in do not cause a
problem because I checked them in using PyBUF_SIMPLE.
Until PEP 3137 is implemented
New submission from Gregory P. Smith:
This makes all existing bytesobject.c methods use the buffer API rather
than explicitly requiring bytes objects as input. It also fixes input
to append() and remove() that was not strict enough and improves a few
unit tests in that area.
NOTE: this patch
Changes by Gregory P. Smith:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options
Gregory P. Smith added the comment:
Patch updated. It now implements the is*() methods for PyBytes. It
moves common code into a shared bytes_ctype.c and .h file so that
stringobject.c and bytesobject.c can share as much as possible.
Did you move this into the stringlib subdirectory
Changes by Gregory P. Smith:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options
Changes by Gregory P. Smith:
--
nosy: -gps
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Gregory P. Smith added the comment:
heh yep that does look like a bug. Laughing at that one goes well with
this comment currently in test_dbshelve.py:
# TODO: Add test cases for a DBShelf in a RECNO DB.
i'll fix it. :)
__
Tracker [EMAIL PROTECTED]
http
New submission from Gregory P. Smith:
If a bsddb.db.DB object is closed before any DBCursor objects
referencing it are closed, python will crash when the cursors are closed
or deleted.
Workaround: never close a database with open cursors. this is annoying
in unittest code where a tearDown
Gregory P. Smith added the comment:
Fixed in python trunk r58434, release25-maint r58435, py3k r58438
--
resolution: - fixed
status: open - closed
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1233
Changes by Gregory P. Smith:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options
New submission from Gregory P. Smith:
The PyBytes (pep3137 buffer) .extend() method currently only accepts as
input something supporting the pep3118 buffer API. It also needs to
accept an iterable of ints in the 0..255 range.
--
keywords: py3k
messages: 56478
nosy: gregory.p.smith
Changes by Gregory P. Smith:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options
Changes by Gregory P. Smith:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options
Gregory P. Smith added the comment:
Committed revision 58493
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1261
Changes by Gregory P. Smith:
--
nosy: +gregory.p.smith
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1247
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Gregory P. Smith added the comment:
This should be fixed in py3k revision 58761.
--
keywords: +py3k
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1371
New submission from Gregory P. Smith:
I'm attaching the patch to add this method here just as a place to track
it for now. It compiles and it looks right, but it causes a crash
within BerkeleyDB when the test case runs using BerkeleyDB 4.6.21. It
passes as expected when using 4.4.20 or 4.5.20
Gregory P. Smith added the comment:
option 1 sounds best. i'll take care of this. thanks for noticing this
and providing suggestions and a patch.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1385
Changes by Gregory P. Smith:
--
components: +Library (Lib) -None
versions: +Python 2.5, Python 2.6
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1385
__
___
Python
Gregory P. Smith added the comment:
Fixed in trunk (2.6) svn revision 58868 with rfc 4231 unit tests and
tests for the new warnings.
The fix parts of that diff should be backported to 2.5. I'm leaving the
Python 2.5 flag on the bug until that happens.
I'm leaving Python 3.0 and py3k tags
Gregory P. Smith added the comment:
yeah i've seen this at random times as well. I don't believe its
related to py3k or the pep3137 branch at all, i believe seen it on trunk
but its rare.
For reference, what platform (OS) and BerkeleyDB version did you build
python with when this happened
1 - 100 of 3243 matches
Mail list logo
