Changes by Skip Montanaro <[EMAIL PROTECTED]>:
--
nosy: -skip.montanaro
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3799>
___
_
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Unassigning. Haven't heard from Tim in quite awhile and he's made no
input on this issue. Also bump to 2.7.
--
assignee: tim_one ->
versions: +Python 2.7 -Python 2.6
___
Pyt
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Perhaps final comment here. The email package was authored by Barry
Warsaw. That's the way he prefers to break his code into sections.
Definitely neither parasitic nor accidental.
Skip
--
nosy: +ski
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
*argh* segfault running tests w/ Sun Studio 12 compiled version
of ctypes 1.0.2:
% python ctypes/test/runtests.py -v
sh: objdump: not found
find_library('c') -> sh: objdump: not found
None
find_library(
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Though I should note that ctypes 1.0.2 won't build with Sun Studio 12
on Python 2.4 without some patches for the __i386 macro in
ffitarget.h. I added this check near the top of ffitarget.h:
#ifdef __i386
/* Su
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
FWIW, ctypes builds on trunk and all its tests
pass with Sun Studio 12. I suspect this issue
can be closed but will leave that for Thomas to
decide.
--
nosy: +skip.montanaro
___
Python t
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I've been thinking about it, and I think even though it would be a slight
change to the API, I agree with Winfried that the default value for
bufsize should be -1, not 0. In my own use of os.popen and friends,
almost all the
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
>> Using a nonzero bufsize parameter makes all the difference in the
>> world:
...
In fact, looking at posix_popen in posixmodule.c it appears the default
value for bufsize there is -1, implying that I/O is fully
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Using a nonzero bufsize parameter makes all the difference in the world:
Using the default (bufsize=0 ==> unbuffered):
% python popentest.py
time with os.popen : 0.035032
time with subprocess.Popen : 1.496455
Cre
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I don't expect Python3 to be all that great io performance-wise yet.
Still, for me on the Mac os.popen beats subprocess.Popen pretty handily:
% python3.0 popentest.py
time with os.popen : 0.874988
time with subpr
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Good suggestion Sameer. I tried it out with Python 2.5 on a Linux host
here and saw essentially identical results for the two alternatives (~
0.08s).
S
___
Python tracker <[EMAIL PROTECTE
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Good question. I don't think it's MacOSX-specific. The original problem
raised its ugly head on Solaris 10. I don't have quite as many versions
of Python available there, but the relative performance is still b
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
I noticed a colleague at work today checked in a change to his code to
switch back from subprocess.Popen to os.popen. I asked him about it and he
reported that subprocess.Popen was about 10x slower than os.popen. I asked
him for a
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
Please apply the attached one-line patch to setup.py. This is a
backport from trunk/2.6. I would check it in myself but I don't have
access to a read/write checkout at the moment.
Thanks,
Skip
--
files: setup.py.di
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Final comment before I see some feedback from the experts.
I have this code in the worker function's loop:
# quick pause to allow other stuff to happen a bit randomly
t = 0.1 * random.random()
time.sleep(t)
If I el
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Got another one just now, but with just the note about the exception
in the queue feeder thread. The traceback was swallowed.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Oh, the range command used in the shell for loop is analogous to Python's
range() builtin function.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
I worked up a simple example of using the external processing module
(0.52) for a friend at work today. I noticed some cases where it raised
exceptions during exit. Not all the time, but not infrequently either.
This evening I t
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
While responding to a c.l.py question just now I discovered that
numeric timezone offsets don't appear to be supported by either the
time.strftime function or the _strptime module. I noticed on my
Mac's strftime(3)
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I checked in r66823 to add the -R flag extraction like Brett's -L
extraction. I'll leave the issue open while folks discuss Roumen's
proposal. I have no particular desire to delve d
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Seems to work for framework builds as well.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Confirmed that nothing seems broken on my OS X 10.5 laptop (doing a
unix-style build, not a framework build).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Here's a patch. Works for me on Solaris 10. I'll try to check
it out on OS X 10.5. Would appreciate it if someone on Linux can
kick the tires too.
--
keywords: +easy, patch
Added file: http://bugs.python.org/file11
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Brett> Well, all of my modules are in a non-standard location and I have
Brett> no build issues on OS X 10.5. If you look at
Brett> PyBuildExt.detect_modules() you will see that the paths are at
Brett> least ad
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
If you are fortunate enough to have all your third-party libraries in
a single quasi-standard location, say, /usr/local/lib, you will
probably have never encountered this problem, but setting environment
variables like LDFLAGS don
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
The "clean" target in the makefile fails to delete the libpython.a file
and the libpython.so.X.Y file (should you have configured using
--enable-shared). The attached trivial patch solves that problem.
The patch is against
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Looks reasonable, though I'm no ctypes maven. Trivial little nit:
In the comment just before the start of CField_FromDesc it says,
in part:
* Expects the size, index and offset for the current field in *psize and
* *poffset,
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Checked in as revision 66562.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I've taken this ticket. Can someone please review and give
it a thumbs up or thumbs down?
--
assignee: -> skip.montanaro
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11517/atexit.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
New patch. This also makes the various atexit_*
functions static.
Added file: http://bugs.python.org/file11519/atexit.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
The attached patch causes an exception to print
at exit on my Mac:
>>> import sys, atexit
>>> atexit.register(lambda: 1, 0, 0, (x for x in (1,2)), 0, 0)
at 0x5c91e0>
>>> sys.exit()
Error in atexit._run_e
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Why not just have atexit_callfuncs call atexit_cleanup at the end of its
execution?
--
nosy: +skip.montanaro
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
What would you suggest? The docs already say:
Though list objects support similar operations, they are optimized
for fast fixed-length operations and incur O(n) memory movement costs
for pop(0) and insert(0, v) operations which
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Josiah> I know that no one hear likes my particular implementation
Josiah> (though it offers more or less the full interface)...
I think implementing as much of the bsddb interface as you can is fine. I
agree people used
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
>> Well, sure, but heaven only knows what an application programmer will
>> do...
Antoine> If the docs clearly explain that there is no guarantee, we
Antoine> don't need heaven. I would find i
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Antoine> I might add that calling keys() then values() is suboptimal,
Antoine> because it will issue two SQL queries while calling items()
Antoine> will issue just one.
Well, sure, but heaven only knows what an applica
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
>> As long as SQLite guarantees that the ordering is identical, then
>> sure, dump the ORDER BY clause.
Gerhard> It doesn't guarantee it, but the implementation behaves like
Gerhard> this.
If the
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Gerhard> FWIW that will also work without the ORDER BY, because you're
Gerhard> getting the rows back in the same ORDER. Something cheaper
Gerhard> would also be "ORDER BY ROWID". I still propose to ju
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
>> I'd like to guarantee that zip(db.keys(), db.values() == db.items().
Antoine> It doesn't sound very useful, and it may hurt performance on
Antoine> big tables.
Actually, I think Python guarantees
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Gerhard> What's all this ORDER BY in both your implementations about?
Gerhard> The dbm "spec" says nothing about keys being ordered AFAIC. Can
Gerhard> we get rid of these?
I'd like to guar
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Amaury> I suppose you meant PyLong_FromDouble()?
Yes, sorry.
Amaury> I think the messages talk about abstract numbers, not a specific
Amaury> python type: "infinity/NaN cannot be converted to an integral
A
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Just a quick nit, but it seems to me that since 2.6 still actually
distinguishes between longs and ints that the two error messages in
PyLong_FromFloat should mention "long" instead of "integer".
Skip
--
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I'm not sure. I've never done anything with the io module. Simply
eliminating the bytes checks and letting it try to write the string
yields:
File "/Users/skip/local/lib/python3.0/dbm/dumb.py", line 170, in
__
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Extra data point. I tried
f["1"] = "a"
and
f[b"1"] = "a"
with dbm.{gnu,ndbm,dumb,sqlite}. All worked with bytes. A except
dbm.dumb worked with strings. (dbm.sqlite is my little pr
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
Consider these two timeit commands:
py3k% python3.0 -m timeit -s 'import dbm.ndbm as db' -s 'f =
db.open("/tmp/trash.db", "c")' 'for i in range(1000): f[str(i)] = str(i)'
100 loops,
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11388/test_dbm_sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11387/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11386/dbm.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
OK, I made a sandbox project out of it:
svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/dbm_sqlite
Hack away!
--
assignee: -> skip.montanaro
___
Python tracker <[EMAIL PROTE
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Antoine> It would be more efficient to base keys() on iterkeys() than the
Antoine> reverse, IMO.
True. I was just modifying the dumbdbm implementation.
Antoine> Other than that, why not open a branch or at least upl
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11385/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11384/test_dbm_sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Updated test cases
Added file: http://bugs.python.org/file11388/test_dbm_sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Another tweak - add values()
Added file: http://bugs.python.org/file11387/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Trivial doc diffs against 3.0b3 doc.
Added file: http://bugs.python.org/file11386/dbm.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11383/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Another slight revision to the module.
Added file: http://bugs.python.org/file11385/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Attaching test cases based on dumbdbm tests.
Added file: http://bugs.python.org/file11384/test_dbm_sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11380/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Attaching corrected module.
Added file: http://bugs.python.org/file11383/sqlite.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
me> If not, could a dbm.sqlite module be written for 2.7 and 3.1 which
me> can fill that role?
http://bugs.python.org/issue3783
S
___
Python tracker <[EMAIL PROTECTED]>
<h
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
Based on recent discussions about ridding Python of bsddb I decided to
see how hard it would be to implement a barebones dbm.sqlite module.
Turns out, not very hard.
No docs. No test cases. Caveat emptor. But I think it can serve
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Is there going to be a dbm.* module which is supported across all the core
platforms: Windows, Mac & Unix? I don't count dumbdbm as really all that
useful, especially given the caveats listed in the module docstring.
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Remind me why we want to get rid of bsddb?
Skip
--
nosy: +skip.montanaro
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I can confirm that Jesse's patch allows multiprocessing to compile on
Solaris 10. Note, however, that there are other symbolic constants
defined which contain "SEM_VALUE_MAX", all with widely differing
underlying val
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I can see where that might be a problem. If that's the case I suspect
those property attributes should be changed. OTOH, do properties work on
classic classes?
___
Python tracker <[E
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
Attached is a patch to fix some pychecker complaints Neal Norwitz
uncovered. All involved tests pass. Submitting patch simply because
we're past beta3.
--
assignee: nnorwitz
components: Library (Lib)
files: pyc
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Most of it looks okay except for the rewrite of
the lineno command. That was written in gdb's command language so
that you could get a python stack from a core dump, not just from a
running process. Is
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
I usually build Python directly in my source repository (the directory
containing the configure script). Accordingly, I have .o files scattered
throughout my sandbox.
Today I decided to build --with-pydebug, so I created a debug dir
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Committed as revision 65605.
--
assignee: -> skip.montanaro
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Andrii, If my view of the Python 3.0 development process is correct and
this change makes it into the 2.6 code, one of the 3.0 developers will
merge to the py3k branch.
___
Python tracker &
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10978/csv.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I added a comment to Andrii's patch and added simple test cases
which check to make sure the way Nick and I currently use the
DictReader class (or at least envision using it) still works.
Added file: http://bugs.python.org/file110
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Nick,
Working with Andrii's patch I'm trying to add a couple test cases to
make sure the methods you and I both demonstrated still work. Mine is
no problem, but I must be doing something wrong trying to use/adapt your
ex
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Guido> I know this has been closed, but perhaps the fieldnames attribute
Guido> could be made into a property that reads the first line of the
Guido> file if it hasn't been read yet?
It's a nice thought. I
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Done...
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
The consensus seems to be that __init__ shouldn't "magically" read the
header row, even though by not specifying a fieldnames arg that's
exactly what you're telling the DictReader where to find the colum
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I should also point out that I've generally used this technique to
populate the fieldnames attribute from the file:
f = open("somefile.csv", "rb")
rdr = csv.DictReader(f, fieldnames=csv.reader(f).next
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
committed as r 65255.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Attached is a patch against 2.6 which adds the missing line (state = 2), a
comment describing the three states the parser can be in and expands the
test cases to cover this change (fail without it, pass with it). In the
process I s
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
That would be a fairly easy change to the DictReader class (see
the attached patch) but probably can't be applied at this point
in the 2.6 release cycle even though all csv module tests pass
with it.
--
nosy: +skip.mont
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3437>
___
___
Python-bugs-list mailing list
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
*sigh* there are no test cases in the current code with Allow: lines in
test_robotparser.py.
--
priority: -> normal
versions: +Python 2.6
___
Python tracker <[EMAIL PROTE
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
*sigh* there are no test cases with Allow: lines in test_robotparser.py.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Perhaps more important than a test case, can you explain what states 0, 1
and 2 are (maybe give them some symbolic names I can at least put in a
comment)? This is not my code. Though I wrote the first version of the
robotparser
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Do you have a concrete robots.txt file I can use in a test case?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
As I indicated in msg69679 if you want to see the line endings just open
the file in binary mode ('rb').
___
Python tracker <[EMAIL PROTECTED]>
<http://
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
anatoly> If you open file with 'r' - all line endings will be mapped
anatoly> precisely to '\n' anyways, so it has nothing to do with 'U'
anatoly> mode.
Before 3.0 at least, if you copy a
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
The whole idea of universal newline mode is that the various possible
line endings ('\r', '\n' and '\r\n') are all mapped to '\n' precisely
so the user doesn't have to detect and fiddle wi
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Regarding -lieee, I don't see an ieee library on my system.
Regarding -ffast-math, while it changes the log function which is linked
to, it doesn't appear to modify the result of math.log:
% ldd build/lib.solaris-2.10-i
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Here's a gdb session using r64812. gcc 4.2.2. ldd on math.so shows:
% ldd build/lib.solaris-2.10-i86pc-2.6/math.so
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /opt/app/nonc++/lib/libgcc_s.so.
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
George> To handle overflows, I figured it should wrap around a 24-hour
George> limit.
That's precisely the reason that time objects don't support arithmetic.
There is no obviously best way to handle over
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Good question. I don't claim that the strftime.c I found is complete
for our needs, only that we can avoid the "rewrite strftime from
scratch" problem Guido indicated.
S
___
P
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
(Sorry for the delay responding. Gmail thought Facundo's response was
spam. :-/) In defense of my bug report, note that I submitted it in
January 2003! It's quite possible that the docs have improved in this
regard sin
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I tried to configure with '-Xlinker -xlibmieee' added to LDFLAGS. Failed
miserably. In fact, configure complained that my compiler couldn't create
executables, told me to look at config.log for details then logged me
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Dunno about Sun's compiler, but I get test errors on Solaris 10 using
gcc 4.2:
==
FAIL: test_specific_values (test.test_cmath
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Ummm... I think I only modified timemodule.c. datetimemodule.c
probably needs a tweak as well. I need to get this off my desk though.
___
Python tracker <[EMAIL PROTECTED]>
<http://
New submission from Skip Montanaro <[EMAIL PROTECTED]>:
Back in April we had a thread on xmlrpclib's problematic handling of dates
before 1900:
http://thread.gmane.org/gmane.comp.python.devel/93273/focus=93309
I'm still of the opinion that strftime() is the culprit and xmlr
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10617/robotparser.py.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
601 - 700 of 838 matches
Mail list logo
