[issue1098732] Enhance tracebacks and stack traces with vars
Skip Montanaro added the comment: PyPI: http://pypi.python.org/pypi/tb ___ Python tracker <http://bugs.python.org/issue1098732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5332] csv sniffer
Skip Montanaro added the comment: I verified the bug. I started to work on a patch (see attached), but it quickly seems to get out-of-hand with tracebacks about stuff not supporting the buffer API. I suspect the real solution might involve doing something to convert the bytes to strings read when in binary mode, but I don't have any idea how to finesse the requirement of bytes() for an encoding arg. -- keywords: +patch nosy: +skip.montanaro stage: -> needs patch versions: +Python 3.1 Added file: http://bugs.python.org/file13186/csv.diff ___ Python tracker <http://bugs.python.org/issue5332> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Raymond> Barry or Skip, is this something you want in your module? Sorry, I haven't really looked at this ticket other than to notice its presence. I wrote the DictReader/DictWriter functions way back when, so I'm pretty comfortable using them. I haven't felt the need for any other reader or writer which manipulates file headers. Skip ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Hrm... I replied twice by email. Only one comment appears to have survived the long trip. Here's my second reply: Rob> NamedTupleReader and NamedTupleWriter should be inverses. This Rob> means that NamedTupleWriter needs to write headers. This should Rob> produce identical output as the dict writer example, but it's much Rob> cleaner. You're assuming that one instance of these classes will read or write an entire file. What if you want to append lines to an existing CSV file or pick up reading a file with a new reader which has already be partially processed? ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Let me be more explicit. I don't know how it implements it, but I think you really need to give the user the option of specifying the field names and not reading/writing headers. It can't be implicit as I interpreted Rob's earlier comment: > NamedTupleReader and NamedTupleWriter should be inverses. > This means that NamedTupleWriter needs to write headers. Skip ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Rob> I agree that we should not unconditionally write headers, but I Rob> think that we should write headers by default, much like we read Rob> them by default. I don't think you should write them by default. I've worked with lots of CSV files which have no headers. I can imagine people wanting to write CSV files with multiple headers. It should be optional and explicit. Skip ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment:
More concretely, I don't think this is so onerous:
names = ["col1", "col2", "color"]
writer = csv.DictWriter(open("f.csv", "wb"), fieldnames=names, ...)
writer.writerow(dict(zip(names, names)))
...
or
f = open("f.csv", "rb")
names = csv.reader(f).next()
reader = csv.DictReader(f, fieldnames=names, ...)
...
Skip
___
Python tracker
<http://bugs.python.org/issue1818>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Rob> I still don't like the lack of symmetry of supporting implicit Rob> header reads, but not implicit header writes. A header is nothing more than a row in the CSV file with special interpretation applied by the user. There is nothing implicit about it. If you know the first line is a header, use the recipe I posted. If not, supply your own fieldnames and treat the first row as data. Skip ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4308] repr of httplib.IncompleteRead is stupid
Skip Montanaro added the comment: Can't be applied to 2.5 at this point. I agree it's dumb to report the entire partial read and that reporting just the number of bytes read is a much better solution. Your patch looks fine to me as well, except you call resp.close() twice in test_incomplete_read(). Assigning to Benjamin for application. (He's going to get the merge stuff right. I almost certainly will not.) -- assignee: -> benjamin.peterson nosy: +skip.montanaro versions: +Python 3.0 -Python 2.5 ___ Python tracker <http://bugs.python.org/issue4308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4308] repr of httplib.IncompleteRead is stupid
Changes by Skip Montanaro : -- stage: needs patch -> commit review ___ Python tracker <http://bugs.python.org/issue4308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4308] repr of httplib.IncompleteRead is stupid
Skip Montanaro added the comment: Chris> Why can't it be applied to 2.5? Benjamin can correct me if I'm wrong, but I thought the last 2.5 release was the last full release planned. Certainly if another full 2.5 release is in the cards then the patch should go there as well. Skip ___ Python tracker <http://bugs.python.org/issue4308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4308] repr of httplib.IncompleteRead is stupid
Skip Montanaro added the comment: Martin> The Python 2.5 branch is closed for bug fixes; no further bug Martin> fix releases of Python 2.5 will be made. Only security fixes can Martin> be accepted on the 2.5 branch. So all Chris has to do to get this applied to 2.5 is craft an exploit based on the current behavior, right? ;-) S ___ Python tracker <http://bugs.python.org/issue4308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: Jervis> in csv.rst removed reference to reader.next() as a public method. Because? I've not seen any discussion in this issue or in any other forums (most certainly not on the c...@python.org mailing list) which would suggest that csv.reader's next() method should no longer be a public method. Skip ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: I don't know how NamedTuple objects work, but in many situations you want the content of the CSV file to drive the output. I would think you would use a technique similar to my DictReader example to tell the NamedTupleReader the fieldnames. For that you need a fieldnames argument. -- message_count: 24.0 -> 25.0 ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: I find this aspect of the proposal disturbing: If *fieldnames* is None the values in the first row of the *csvfile* will be used as the fieldnames I don't think this should be implicit. It makes the NamedTupleReader semantically different from the vanilla reader object which treats every row of the file as data. The use of the fieldnames argument should be required for NamedTupleReader objects as it is for DictReader objects. -- message_count: 25.0 -> 26.0 ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Changes by Skip Montanaro : -- message_count: 26.0 -> 25.0 ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: I retract my previous comment. I don't use the DictReader the way it operates (fieldnames==None => first row is a header) and forgot about that behavior. -- message_count: 25.0 -> 26.0 ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5455] csv module no longer works as expected when file opened in binary mode
New submission from Skip Montanaro :
I just discovered that the csv module's reader class in 3.x doesn't work
as expected when used as documented. The requirement has always been
that the CSV file is opened in binary mode so that embedded newlines in
fields are screwed up. Alas, in 3.x files opened in binary mode return
their contents as bytes, not unicode strings which are apparently not
allowed by the next() builtin:
% python3.1
Python 3.1a0 (py3k:70084M, Feb 28 2009, 20:46:48)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> next(csv.reader(open("f.csv", "rb")))
Traceback (most recent call last):
File "", line 1, in
_csv.Error: iterator should return strings, not bytes (did you open the
file in text mode?)
>>> next(csv.reader(open("f.csv", "r")))
['col1', 'col2', 'color']
At the very least the documentation for the csv.reader class is no
longer correct. However, I can't see how you can open a CSV file in
text mode and not screw up embedded newlines. I think binary mode
*has* to stay and some other way of dealing with bytes has to be found.
--
components: Library (Lib)
message_count: 1.0
messages: 83350
nosy: skip.montanaro
nosy_count: 1.0
severity: normal
status: open
title: csv module no longer works as expected when file opened in binary mode
type: behavior
versions: Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5455>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5455] csv module no longer works as expected when file opened in binary mode
Skip Montanaro added the comment: Jervis> So the returned lineobj is a bytes type and then the Jervis> PyUnicode_Check throws the error. Right, but given that fact how do you get a Unicode string out of the bytes without an encoding? You can't open a file in binary mode and give the encoding arg. -- message_count: 4.0 -> 5.0 ___ Python tracker <http://bugs.python.org/issue5455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4847] csv fails when file is opened in binary mode
Skip Montanaro added the comment: me> What should be the default? Scratch that. If the iterator passed to csv.reader is in a mode which will cause it to emit bytes instead of unicode objects the caller must give an encoding. The csv.reader code will then perform the necessary bytes-to-unicode conversion. If bytes are returned by the iterator but no encoding was given it should raise an exception (something standard? something new?). Skip -- message_count: 20.0 -> 21.0 ___ Python tracker <http://bugs.python.org/issue4847> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4847] csv fails when file is opened in binary mode
Skip Montanaro added the comment: This issue seems to have simply been overlooked when 3.0 was released. It should be fixed in the next round of 3.0 and 3.1 updates. Any feeback on the idea that the csv.reader constructor (and probably the DictReader and proposed NamedTupleReader constructors) should take an optional encoding argument? In fact, the writers should as well which would inform the writer how to encode the output when writing. -- message_count: 21.0 -> 22.0 priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue4847> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, addition to os
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue444582> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1157169] csv Sniffer returns bad dialect?
Skip Montanaro added the comment: I'm closing this. It's my own fault that it languished for so long, but the current trunk version of Python doesn't demonstrate the behavior Neil documented four years ago. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue1157169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1431091] CSV Sniffer fails to report mismatch of column counts
Skip Montanaro added the comment: (I did try to clarify the return type of the iterator a bit better.) -- ___ Python tracker <http://bugs.python.org/issue1431091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1431091] CSV Sniffer fails to report mismatch of column counts
Changes by Skip Montanaro : -- ___ Python tracker <http://bugs.python.org/issue1431091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1431091] CSV Sniffer fails to report mismatch of column counts
Skip Montanaro added the comment: Closing as won't fix. There are bound to be limits to how the Sniffer class works. I'm not sure it's worth the effort necessary to fix this corner case. (Andrew, reopen if you want to tackle this.) -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue1431091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1157169] csv Sniffer returns bad dialect?
Skip Montanaro added the comment: (I did try to clarify the return value of the next/__next__ method a bit.) -- ___ Python tracker <http://bugs.python.org/issue1157169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] Figure out what to do with unittest's redundant APIs
Changes by Skip Montanaro : -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] Figure out what to do with unittest's redundant APIs
Skip Montanaro added the comment: Personally, I would prefer it if unittest got rid of all the various ways to spell "assert" and just let test cases use the assert statement. I use nose for most of my stuff which supports/allows use of the assert statement. I think my test cases are better for it. (crap, crap, crap. I was scrolling through the messages and my finger slid off the button on my laptop. I pressed it again without really looking. I didn't realize the mouse was no longer over the scrollbar's thumb and, too late, saw that I had clicked the Remove button of this message "msg84360". I hope I clicked the cancel button soon enough. If not, can it be "unremoved" programmatically? I have the text of the message if need be.) -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] Figure out what to do with unittest's redundant APIs
Skip Montanaro added the comment: Just in case it can't be retrieved, here is Greg's text from msg84360: Oh for reference, i left these out but they may interest people for completeness sake. assert_ 15% assertTrue 9% assertFalse 5% We don't currently have the auto type checking in assertEqual in our internal codebase, direct use of the type specific methods has been encouraged in the past but that doesn't mean it is the right thing for Python. --- Again, my apologies. Skip -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1537721] csv module: add header row to DictWriter
Skip Montanaro added the comment: I don't see a patch. Is there some reason that if you need this you can't simply subclass DictWriter? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue1537721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1653416] print >> f, "Hello" produces no error: normal?
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue1653416> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5632] Bug - threading.currentThread().ident returns None in main thread
New submission from Skip Montanaro : The main thread has an ident, but the threading module doesn't recognize that fact. I shouldn't have to "start" the main thread. Example: % python Python 2.7a0 (trunk:70084, Feb 28 2009, 20:51:51) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> import thread >>> print threading.currentThread(), threading.currentThread().ident, thread.get_ident() <_MainThread(MainThread, started)> None -1602627808 % python3.1 Python 3.1a0 (py3k:70084M, Feb 28 2009, 20:46:48) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> print (threading.current_thread(), threading.current_thread().ident)<_MainThread(MainThread, started)> None -- components: Library (Lib) messages: 84901 nosy: skip.montanaro severity: normal status: open title: Bug - threading.currentThread().ident returns None in main thread type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5632> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5632] Bug - threading.currentThread().ident returns None in main thread
Skip Montanaro added the comment: Here's a test case which reveals the problem as I see it. -- keywords: +patch stage: -> needs patch Added file: http://bugs.python.org/file13525/threading.diff ___ Python tracker <http://bugs.python.org/issue5632> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4847] csv fails when file is opened in binary mode
Skip Montanaro added the comment: David> I've added some unit tests for embedded newlines, and py3k csv David> passes (on linux at least) when newline='' is used. Unless David> someone can provide a test case that fails when newline='' is David> used, I propose we fix the documentation and leave the code David> alone. This thread is getting a bit long. Can someone summarize how the expected usage of the csv module is supposed to change? If I read things correctly, instead of requiring (in the general case) that csv files be opened in binary mode, the requirement will be that they be opened with newline=''. This will thwart any attempts by the io module at newline translation, but since the file is still opened in text mode its contents will implicitly be Unicode (or Unicode translated to bytes with a specific encoding). That encoding will also be specified in the call to open(). Is this about correct? Do any test cases need to be updated or added? I notice that something called BytesIO is imported from io but not used. Were some test cases removed which used to involve that class or is that a 2to3 artifact? Skip -- ___ Python tracker <http://bugs.python.org/issue4847> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4847] csv fails when file is opened in binary mode
Skip Montanaro added the comment: David> I also deleted the unicode discussion (since CSV obviously David> handles unicode now) ... Maybe there should be a simple example showing use of the encoding parameter to open() to encode Unicode on write and decode to Unicode on read? Skip -- ___ Python tracker <http://bugs.python.org/issue4847> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] additional unittest type equality methods
Skip Montanaro added the comment: Am I the only person who wishes all the assert* and fail* methods would simply go away in favor of simply using the assert statement? Skip -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] additional unittest type equality methods
Skip Montanaro added the comment: Michael> Why do you need the assert methods to go away in order to use Michael> assert statements? You don't, but use of assert statements seems a hell of a lot more Pythonic to me than all the assert* or fail* method names which I can never remember. S -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] additional unittest type equality methods
Skip Montanaro added the comment: >> You don't, but use of assert statements seems a hell of a lot more >> Pythonic to me than all the assert* or fail* method names which I can >> never remember. Antoine> 1. they are optimized away in "-Oxxx" mode As far as I can tell for Python itself we never use -O while running unit tests. Antoine> 2. they don't provide good reporting in case of failure I've never had a problem with that. It yields a perfectly useful traceback, and in the case of the nose package at least, it does the right thing with it. In any case, your test machinery will have to catch AssertionError exceptions anyway. -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
New submission from Skip Montanaro :
I configured and built Python 2.6.2c1 on Solaris 10 using gcc 4.2.
All tests pass except cmath:
% LD_LIBRARY_PATH=. ./python Lib/test/regrtest.py -v test_cmath
test_cmath
test_abs (test.test_cmath.CMathTests) ... ok
test_cmath_matches_math (test.test_cmath.CMathTests) ... ok
test_constants (test.test_cmath.CMathTests) ... ok
test_input_type (test.test_cmath.CMathTests) ... ok
test_isinf (test.test_cmath.CMathTests) ... ok
test_isnan (test.test_cmath.CMathTests) ... ok
test_phase (test.test_cmath.CMathTests) ... ok
test_polar (test.test_cmath.CMathTests) ... ok
test_rect (test.test_cmath.CMathTests) ... ok
test_specific_values (test.test_cmath.CMathTests) ... FAIL
test_user_object (test.test_cmath.CMathTests) ... ok
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File "/home/tuba/skipm/src/Python-2.6.2c1/Lib/test/test_cmath.py",
line 338, in test_specific_values
self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052:
exp(complex(710.0, 1.5))
--
Ran 11 tests in 0.048s
FAILED (failures=1)
test test_cmath failed -- Traceback (most recent call last):
File "/home/tuba/skipm/src/Python-2.6.2c1/Lib/test/test_cmath.py",
line 338, in test_specific_values
self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052:
exp(complex(710.0, 1.5))
1 test failed:
test_cmath
Since we are so close to release I'm assigning it to Barry, though
Mark Dickinson is probably the best person to look at this problem. I
think this is a long-standing Solaris/cmath issue. I'm sorry Mark and
I didn't connect long enough at PyCon to dig into this. It may not be
serious enough to hold up a final release, but I wanted to mention the
problem so it's recognized.
--
assignee: barry
components: Tests
messages: 85784
nosy: barry, skip.montanaro
severity: normal
status: open
title: 2.6.2c1 fails to pass test_cmath on Solaris10
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue5724>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
Changes by Skip Montanaro : -- nosy: +marketdickinson ___ Python tracker <http://bugs.python.org/issue5724> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
Skip Montanaro added the comment: Mark> Here's a patch that backports the corresponding changes from Mark> trunk. Mark> Skip, can you confirm that this fixes the issue? Indeed, your patch appears to fix the problem: % LD_LIBRARY_PATH=. ./python Lib/test/regrtest.py -v test_cmath test_cmath test_abs (test.test_cmath.CMathTests) ... ok test_cmath_matches_math (test.test_cmath.CMathTests) ... ok test_constants (test.test_cmath.CMathTests) ... ok test_input_type (test.test_cmath.CMathTests) ... ok test_isinf (test.test_cmath.CMathTests) ... ok test_isnan (test.test_cmath.CMathTests) ... ok test_phase (test.test_cmath.CMathTests) ... ok test_polar (test.test_cmath.CMathTests) ... ok test_rect (test.test_cmath.CMathTests) ... ok test_specific_values (test.test_cmath.CMathTests) ... ok test_user_object (test.test_cmath.CMathTests) ... ok -- Ran 11 tests in 0.063s OK 1 test OK. I'll leave it to you and Barry to consider if the patch is too hefty for backport. Skip -- ___ Python tracker <http://bugs.python.org/issue5724> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
Skip Montanaro added the comment: FWIW, with the patch applied all tests still pass on Mac OS X 10.5.6 (Intel). S -- ___ Python tracker <http://bugs.python.org/issue5724> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5736] Add the iterator protocol to dbm modules
Skip Montanaro added the comment: Akira> Note that dbm and gdbm C API is a little different. gdbm_nextkey Akira> requires key for its argument, dbm_nextkey don't. So I had to Akira> use for gdbm an static variable that points to the current Akira> position. I don't think this is going to fly. A static variable is not thread-safe. What's worse, even in a non-threaded environment you might want to iterate over the gdbm file simultaneously from two different places. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue5736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5736] Add the iterator protocol to dbm modules
Skip Montanaro added the comment: skip> What's worse, even in a non-threaded environment you might want to skip> iterate over the gdbm file simultaneously from two different skip> places. Or iterate over two different gdbm files simultaneously. -- ___ Python tracker <http://bugs.python.org/issue5736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Skip Montanaro added the comment: Sorry, I've been away from this issue. I was sort of hoping the Sun and Apple folks would just work things out amongst themselves and present us with a fait accompli. ;-) I'll try to mess around with this a little. Robert> $ sudo dtrace ... Perhaps not quite on-topic for this tracker item, but it bugs me that the mere compilation of a D script requires root privileges. I guess there's not much we can do about this other than complain to Sun and Apple though. Skip -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Skip Montanaro added the comment: Robert> Is there any interest in my expanding the list of probes? Yes. Jeff Garrett (a guy I work with) added some more DTrace probes to a 2.4 source tree at work. I mentioned them in an earlier message. I'll check with him at work tomorrow and see about making sure they can be released. I think it's important to get Sun and Apple in sync as well. Maybe more important than adding new probes. (Though if the Python community drives the creation of new probes perhaps both will pick them up.) Skip -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue1755841> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks
Skip Montanaro added the comment: Daniel> Daniel Diniz added the comment: Daniel> I get different behavior in py3k compared to trunk: Daniel> ~/trunk-py$ ./python issue1511_py3k.py Daniel> [['foo', 'bar\r\nbaz\r\nbiff', 'boo']] Daniel> 'foo,"bar\r\nbaz\r\nbiff",boo\r\n' Daniel> ~/trunk-py$ ../py3k/python issue1511_py3k.py Daniel> [['foo', 'bar\nbaz\nbiff', 'boo']] Daniel> 'foo,"bar\nbaz\nbiff",boo\n' Try adding newline='' to your open calls. I believe that will preserve the CRLF pairs. Skip -- ___ Python tracker <http://bugs.python.org/issue1511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
