Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11439>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11445>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11419>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11421>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10954>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10444>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue10401>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9650>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9788>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue9755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro :
--
nosy: -skip.montanaro
___
Python tracker
<http://bugs.python.org/issue8387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
John> Skip, The changes that I suggested have NOT been made. Please
John> re-read the doc page you pointed to. The "writer" paragraph does
John> NOT mention that newline='' is required when writing. The "writer"
New submission from Skip Montanaro :
At Antoine's behest, I tried running
./python.exe -m test -j2
in my cpython sandbox and saw several test case failures which
didn't appear when I executed a simple
make test
He suggested I add the -W flag and try again. I did, but I don
Skip Montanaro added the comment:
Thanks. That worked better. Here is the tail end of the output
showing the verbose test output.
--
Added file: http://bugs.python.org/file21362/output
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
Antoine> Skip, can you please try "make distclean" and then rebuild from
Antoine> scratch?
I did. The last output was after
make distclean
./configure ... my usual suspects ...
make
./python.exe -j2 -w
I will try one more
Skip Montanaro added the comment:
Antoine> New changeset 9aa6097131ef by Antoine Pitrou in branch '3.2':
Antoine> Issue #11653: fix -W with -j in regrtest
Antoine> http://hg.python.org/cpython/rev/9aa6097131ef
Antoine> New changeset c381b35e4f31 by Antoine Pit
Skip Montanaro added the comment:
Brett> The import failures are because you didn't rebuild (I added a new
Brett> function to imp). Re-build and the import issues will go away.
An easy mistake to make. I'm used to running "make test" which would have
guaranteed
Skip Montanaro added the comment:
Ned> Skip, what parameters are you using with ./configure ?
Pretty vanilla. Install in my directory tree, get libraries from MacPorts:
--prefix=/Users/skip/local --enable-shared LDFLAGS=-L/opt/local/lib
CPPFLAGS=-I/opt/local/include
I thought you
Skip Montanaro added the comment:
+1. That was the first thing I looked for when I checked
my email today.
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
>From the comment in the test_csv.py:
+# XXX: I don't know what the correct behavior should be for these.
+# Currently the first one raises an error that the delimiter can't
+# be determined while the second one retur
Skip Montanaro added the comment:
> FWIW, (simple)json module serializes subclasses of builtin types
> just as expected.
Does that round trip properly? For instance, if you serialize an
instance of a list subclass does it unserialize as a list instance
or as the subclass?
Perhaps JS
Skip Montanaro added the comment:
I get two failures with David's latest patch. Abstracting from
a lightly modified patch:
sample was: 'a,b,"c,d"\r\ne,f,g', got: '', expected: ','
sample was: '"a,b,c,d"\r\ne', got:
Skip Montanaro added the comment:
Also, this comment in test_csv.py puzzles me:
# given that all three lines in sample3 are equal,
# I think that any character could have been 'guessed' as the
# delimiter, depending on dictionary order
As a human looking
Skip Montanaro added the comment:
Here's my candidate patch. Instead of returning an empty string
as the delimiter it returns a comma.
--
Added file: http://bugs.python.org/file20111/csv_delimiter_tests.patch
___
Python tracker
Skip Montanaro added the comment:
John,
The API for the open() builtin function has changed. You should open
the output file with newline="" instead of using the default. Take a
look at the documentation for open() and csv.reader:
http://docs.python.org/py3k/library/func
Skip Montanaro added the comment:
On my Mac it displays "12345". I don't see that as a big problem.
It raises ValueError for a year of -1. This is with build py3k:87566.
If someone wants to feed a year > to time.strftime I don't see that
as a big problem. I l
Skip Montanaro added the comment:
Skip> On my Mac it displays "12345". I don't see that as a big problem.
haypo> Why do you say "problem"? It is the correct result :-)
I agree. I interpreted your ticket as complaining that it should raise
a ValueError if
Skip Montanaro added the comment:
If you intend this to be "safe" in the security sense of the word, I
suggest you release it in PyPI and post a note on comp.lang.python
(a.k.a. python-l...@python.org) asking people to try and break it.
--
nosy: +skip
Skip Montanaro added the comment:
Looking at the csv.rst file I see this statement early in the py3k
docs:
If *csvfile* is a file object, it should be opened with ``newline=''``.
There is also a footnote about the consequences of leaving it out:
.. [#] If ``newline=''
Skip Montanaro added the comment:
My suggestion attached.
--
keywords: +patch
Added file: http://bugs.python.org/file20497/csv.rst.diff
___
Python tracker
<http://bugs.python.org/issue10
Skip Montanaro added the comment:
I disagree. Both os.popen and os.system work fine in the proper context
and are easier to use (and remember how to use) than the subprocess
module. You don't give any examples of breakage, or whether said
breakage is platform-dependent.
--
Skip Montanaro added the comment:
Given this code:
#!/usr/bin/env python
class C:
def bomb(self):
1/0
c = C()
c.bomb()
when run it produces
Traceback (most recent call last):
File "", line 8, in
File "", line 5, in bomb
ZeroDivisionError: integer divisi
Skip Montanaro added the comment:
I'm not sure you can get there from here, certainly not in a
straightforward way. The traceback formatter gets a reference to
the code object (traceback -> frame -> code). That object has a name
attribute (which is what's displayed) but i
Skip Montanaro added the comment:
I agree with Antoine, however, if you can come up with a
reasonable patch which implements the desired behavior, I
think it would be reasonable to add it to Python 3.3. The
definition of "reasonable" is subject to interpretation.
As I indicated in
Skip Montanaro added the comment:
Eric> Note that os.popen is implemented with subprocess.
That seems somewhat wrong to me. There is a stdio popen function which
os.popen used to expose. I thought that was the goal (thin wrapper around
many library functions, then build higher level stuff
Changes by Skip Montanaro :
--
nosy: +skip.montanaro
___
Python tracker
<http://bugs.python.org/issue11089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro added the comment:
Here's a patch.
--
keywords: +patch
nosy: +skip.montanaro
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20753/compile.diff
___
Python tracker
<http://bugs.py
Skip Montanaro added the comment:
Working on a test case too.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list mailin
Changes by Skip Montanaro :
Removed file: http://bugs.python.org/file20753/compile.diff
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list m
Skip Montanaro added the comment:
It's not so easy as first appeared.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list m
Skip Montanaro added the comment:
Okay, this looks better. I was confusing myself with leftover .pyc
files I think. Test included.
--
Added file: http://bugs.python.org/file20754/compile.diff
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
Georg, I think this might need to sneak into 3.2.
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue11
Skip Montanaro added the comment:
3.2 and earlier versions are all frozen, but for 3.3 it might make sense to
bump the version number of the bytecode and change STORE_MAP to take the key
and value in the opposite order, thus allowing to remove the ROT_TWO I had to
add to make this work
Skip Montanaro added the comment:
As Georg suggested, it is correct in 2.4, wrong in 2.5.
--
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Pytho
Skip Montanaro added the comment:
> To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD
> opcodes need minor modifications (just switch the u and w variable
> assignments).
Either of which would not be possible in anything other that 3.3 or
lat
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 attenti
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 : str
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 : str
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
I originally sent this by email but never saw it pop up. I eventually
submitted via the web.
--
superseder: -> sys.exit() called from optparse - bad, bad, bad
___
Python tracke
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3084>
___
__
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 -DN
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.
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
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
Ge
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.
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
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file8179/robotparser.py.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Skip Montanaro <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10617/robotparser.py.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
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
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://
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:
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:
(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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
*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:
*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
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:
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
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:
committed as r 65255.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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:
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:
Done...
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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:
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:
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
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:
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 &
Skip Montanaro <[EMAIL PROTECTED]> added the comment:
Committed as revision 65605.
--
assignee: -> skip.montanaro
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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:
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]>:
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:
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
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:
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:
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.
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]>
<h
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
101 - 200 of 838 matches
Mail list logo
