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) man page that it supports
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 deeper into
distutils
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 the trunk as of just
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 added for the search path
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/file11675/runtime.diff
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.python.org/issue4010
Skip Montanaro [EMAIL PROTECTED] added the comment:
Seems to work for framework builds as well.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4010
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, stores
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11517/atexit.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3666
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://bugs.python.org/issue3666
Skip Montanaro [EMAIL PROTECTED] added the comment:
Checked in as revision 66562.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3666
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.python.org/issue3666
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)
function lambda at 0x5c91e0
sys.exit()
Error in atexit._run_exitfuncs:
TypeError
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.python.org/issue3666
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 change
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 first, next, last
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 guarantee that zip(db.keys(), db.values() == db.items
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 (for dicts at least - other mappings
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 just do
Gerhard without the ORDER
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 behavior isn't guaranteed, I think you
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 application programmer
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 it strange to potentially ruin
Antoine
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
--
nosy: +skip.montanaro
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
Amaury value.
Well, 2.5
Skip Montanaro [EMAIL PROTECTED] added the comment:
Extra data point. I tried
f[1] = a
and
f[b1] = a
with dbm.{gnu,ndbm,dumb,sqlite}. All worked with bytes. A except
dbm.dumb worked with strings. (dbm.sqlite is my little proof-of-concept
module currently in the sandbox
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
__setitem__
self._addkey(key
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, best of 3: 5.51 msec per loop
py3k% python3.0 -m timeit -s
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 upload
Antoine full
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 PROTECTED]
http://bugs.python.org
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11386/dbm.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11387/sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11388/test_dbm_sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
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:
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]
http://bugs.python.org/issue3769
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.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11380/sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
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.python.org/issue3783
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.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11383/sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
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.python.org/issue3783
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.python.org/issue3783
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.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11384/test_dbm_sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11385/sqlite.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3783
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 values:
% find /usr/include
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.
If not, could a dbm.sqlite
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: pychecker.diff
keywords
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 [EMAIL PROTECTED]
http
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 there some reason
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 directory
Skip Montanaro [EMAIL PROTECTED] added the comment:
Committed as revision 65605.
--
assignee: - skip.montanaro
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3436
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
example. I freely
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/file11021/csv.diff
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10978/csv.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3436
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 [EMAIL PROTECTED
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 tried the straightforward
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 column
headers. Given that case, my argument
Skip Montanaro [EMAIL PROTECTED] added the comment:
Done...
--
resolution: - wont fix
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3436
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 snagged
Skip Montanaro [EMAIL PROTECTED] added the comment:
committed as r 65255.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3437
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())
So it is fairly trivial to set
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.python.org/issue3437
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 module
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 PROTECTED]
http://bugs.python.org
Changes by Skip Montanaro [EMAIL PROTECTED]:
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3437
___
___
Python-bugs-list mailing list
Unsubscribe:
http
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.montanaro
Added file
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://bugs.python.org/issue3359
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 text file from, say, Windows to Mac, and
open
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 with them. Using 'b' and
'U' together makes no sense
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.1
libc.so.1
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-i86pc-2.6/math.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 overflow.
--
nosy
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 since then.
If you think
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
___
Python tracker [EMAIL PROTECTED
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 out
from the machine
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.CMathTests
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 xmlrpclib is
just
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://bugs.python.org/issue3173
Skip Montanaro [EMAIL PROTECTED] added the comment:
Jesse Per skip's email:
Jesse FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does
Jesse define
Jesse _SEM_VALUE_MAX in sys/params.h.
...
Thanks for submitting the bug report. I wonder why the processing
Skip Montanaro [EMAIL PROTECTED] added the comment:
I suppose I'm as good a person to continue maintaining this as any,
though my time is largely spent doing other stuff these days. The patch
doesn't apply cleanly right now and lots of the changes it suggests have
been made already (or done
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file8179/robotparser.py.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1778443
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10617/robotparser.py.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1778443
Skip Montanaro [EMAIL PROTECTED] added the comment:
Georg I agree with Antoine that the standard behavior is what you want in most
Georg simple command-line scripts.
Georg It's easy enough to replace the parser's exit function to just print
the
Georg message, or raise an exception
New submission from Skip Montanaro [EMAIL PROTECTED]:
I'm fully up-to-date on my py3k branch (r64171). After a make clean I
find that I can't build either the time or datetime modules. Here are
errors from gcc:
building 'time' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
Skip Montanaro [EMAIL PROTECTED] added the comment:
Georg Georg Brandl [EMAIL PROTECTED] added the comment:
Georg Where does the strftime.c come from? It is not in the Python
Georg sources -- is this a Mac-specific thing?
Whoops. My bad. Modified sandbox. Please reject.
Skip
Skip Montanaro [EMAIL PROTECTED] added the comment:
My bad. Sorry for the noise. mods in my sandbox...
--
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3091
New submission from Skip Montanaro [EMAIL PROTECTED]:
This seems like a bug in optparse.OptionParser:
def exit(self, status=0, msg=None):
if msg:
sys.stderr.write(msg)
sys.exit(status)
def error(self, msg):
error(msg : string)
Print a usage
Changes by Skip Montanaro [EMAIL PROTECTED]:
--
versions: +Python 2.6, Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3079
___
___
Python
New submission from Skip Montanaro [EMAIL PROTECTED]:
This seems like a bug in optparse.OptionParser:
def exit(self, status=0, msg=None):
if msg:
sys.stderr.write(msg)
sys.exit(status)
def error(self, msg):
error(msg : string)
Print a usage
Changes by Skip Montanaro [EMAIL PROTECTED]:
--
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3084
___
___
Python-bugs-list
Skip Montanaro [EMAIL PROTECTED] added the comment:
I'm not going to pretend I understand the changes. I do notice
that test_docxmlrpc hangs hard on my Mac (doesn't even respond to
Ctl-C). DocXMLRPCServer subclasses from SimpleXMLRPCServer, so I
suspect it needs some attention. I tried
Skip Montanaro [EMAIL PROTECTED] added the comment:
Ah, I remember now. It was a special case for xmlrpclib to allow
its Date objects to operate before 1900.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1777412
Skip Montanaro [EMAIL PROTECTED] added the comment:
The conclusion on python-dev is that NamedTemporaryFile is
an adequate replacement for mktemp, so this isn't needed.
--
resolution: - rejected
status: open - closed
__
Tracker [EMAIL PROTECTED]
http
Skip Montanaro [EMAIL PROTECTED] added the comment:
Thanks. New patch attached.
Added file: http://bugs.python.org/file10137/mkstempf.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2717
Changes by Skip Montanaro [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10136/mkstempf.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2717
__
___
Python-bugs
Skip Montanaro [EMAIL PROTECTED] added the comment:
Nick What does this offer over using NamedTemporaryFile(delete=False)?
Nothing I suppose. I wasn't aware of the similarity of the two (I always
use mkstemp()) or the delete arg to NamedTemporaryFile, and assumed Guido's
complaint about
New submission from Skip Montanaro [EMAIL PROTECTED]:
On python-dev Guido lamented the fact that tempfile.mkstemp()
returns a file descriptor instead of a file object. This
patch adds tempfile.mkstempf to remedy that.
--
components: Library (Lib)
files: mkstempf.diff
keywords: easy
Skip Montanaro [EMAIL PROTECTED] added the comment:
It's not a mistake. In fact, the csv unit tests make use of being able
to iterate over strings. I don't think this feature is going away.
--
nosy: +skip.montanaro
__
Tracker [EMAIL PROTECTED]
http
Skip Montanaro [EMAIL PROTECTED] added the comment:
Leonard,
Can you reformulate your patch in terms of the current xmlrpclib module
code? It no longer applies cleanly. Also, to be considered it will
definitely need new test cases and may well need documentation changes.
Also, note
Skip Montanaro [EMAIL PROTECTED] added the comment:
Donovan, can you recreate this patch using the current Subversion trunk?
The patch program complains:
malformed patch at line 125: Index:
trunk.2/Lib/SimpleXMLRPCServer.py
Thanks,
Skip
--
nosy: +skip.montanaro
601 - 700 of 805 matches
Mail list logo
