[issue9574] allow whitespace around central '+' in complex constructor
Jervis Whitley added the comment: Here is a patch to document string argument requirements. -- keywords: +patch Added file: http://bugs.python.org/file18686/complex_doc.diff ___ Python tracker <http://bugs.python.org/issue9574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9574] allow whitespace around central '+' in complex constructor
Jervis Whitley added the comment: I can write a documentation patch for this: http://docs.python.org/library/functions.html?highlight=complex#complex to highlight the expected format of the string argument. As others have pointed out here, there are a number of other options available to correctly parse the complex string argument: * using eval where appropriate; and * preprocessing to remove whitespace. I think that the current options are sufficient that a patch to apply new behaviour isn't required. -- ___ Python tracker <http://bugs.python.org/issue9574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9574] complex does not parse strings containing decimals
Jervis Whitley added the comment: It hadn't occurred to me to try this without spaces. Thank you for pointing this out. Agreed that the enhancement is not essential. -- ___ Python tracker <http://bugs.python.org/issue9574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9574] complex does not parse strings containing decimals
New submission from Jervis Whitley :
complex() raises ValueError when parsing a string argument containing both real
and imaginary where one of the real or imaginary is a decimal.
To reproduce:
>>> complex("1.1 + 2.1j")
ValueError: complex() arg is a malformed string
>>> complex("2.1j")
2.1j
>>> complex("1.1 + 2j")
ValueError: complex() arg is a malformed string
>>> complex("1 + 2.1j")
ValueError: complex() arg is a malformed string
Expected results:
>>> complex("1.1 + 2.1j")
(1.1 + 2.1j)
>>> complex("2.1j")
2.1j
>>> complex("1.1 + 2j")
(1.1 + 2j)
>>> complex("1 + 2.1j")
(1 + 2.1j)
This affects all versions up to Python 3.1.2. I haven't tested any of the
development builds.
Tests were conducted on a Windows XP 32 bit machine.
--
components: Interpreter Core
messages: 113661
nosy: jdwhitley
priority: normal
severity: normal
status: open
title: complex does not parse strings containing decimals
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue9574>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714448] if something as x:
Jervis Whitley added the comment: > Matthew suggested ~= instead of -> or "as". Try the patch, you can make changes (for those that aren't aware) by changing the token in Grammar/Grammar to whatever you wish. It is easy to do and you need only recompile after this step. example: assexp: xor_expr ['->' xor_expr] could become assexp: xor_expr ['magic' xor_expr] >>> 'hello' magic words 'hello' >>> words 'hello' Note that Mr Barnett may need to look at other fixes to get his '~=' idea off the ground (tokenizer.c and specifically adding a new token) I've recommended that we close this issue. Cheers, Jervis -- ___ Python tracker <http://bugs.python.org/issue1714448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714448] if something as x:
Jervis Whitley added the comment:
> Regarding the proposed syntax:
> if (f() == 'spam') -> name:
> newname = name.replace('p', 'h')
> Surely that should assign the *bool* result of comparing f()
> with 'spam' to name? Doing anything else is opening the door to a
> world of pain.
You are correct. It does assign the result of the bool. I have
made an error in creating the example. This is what happens when
I copy and paste and don't check the result.
should read
if f -> name:
# use name, (pointless example but in line with the OP's suggestion)
Thanks for picking this up.
--
___
Python tracker
<http://bugs.python.org/issue1714448>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714448] if something as x:
Jervis Whitley added the comment: > If we allow this, how many of the following will be allowed? > if expr as name: > while expr as name: > expr as name # alternative to "name = expr" This patch implements your final point: expr as name (albeit with a nominal '->' RARROW rather than 'as') the patch creates a new expression, assexp (assignment expression) there is no need to implement this for countless other if/while/for because they accept expressions and this assignment is an expression. (Note it is a patch for a different behaviour than the OP suggested.) > As for using "->", please no, there are plenty of languages that use > line noise, but Python doesn't need to be one of them. I have begun a discussion about this on python-ideas to give it some air as suggested by Raymond. We can always close the issue as 'wont fix' if it doesn't get off the ground. This issue (although addressing an old concern dating back to the beginning of python) has been sitting unloved for 9 or so months and I felt that we should at least resolve it. Cheers, Jervis -- ___ Python tracker <http://bugs.python.org/issue1714448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714448] if something as x:
Jervis Whitley added the comment:
Hi,
I like this idea.
I've put together a short patch that will implement inline
assignment.
if f() -> name:
use(name)
or more powerfully:
if f() -> name == 'spam':
usespam(name)
the old syntax if something as x: is still available if that
is what is desired.
if (f() == 'spam') -> name:
newname = name.replace('p', 'h')
Patched against Py3k please kick the tires, I've added some tests and
developed a PEP.
--
keywords: +patch
nosy: +jdwhitley
versions: +Python 3.1 -Python 2.6
Added file: http://bugs.python.org/file13329/assexp.diff
___
Python tracker
<http://bugs.python.org/issue1714448>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4540] typo in a module describes utf-8 as uft-8
Jervis Whitley added the comment:
I can still reproduce on py3
>>> help("modules anything")
Traceback (most recent call last):
...
This patch works (on Py3.1a1).
Amaury, are you still o.k with catching Exception rather
than just (SyntaxError, UnicodeDecodeError, ImportError)?
The code-refactoring does clean the structure up well.
Cheers,
Jervis
--
message_count: 9.0 -> 10.0
nosy: +jdwhitley
nosy_count: 3.0 -> 4.0
___
Python tracker
<http://bugs.python.org/issue4540>
___
___
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
Jervis Whitley added the comment: Hi all, This patch takes the approach of assuming utf-8 format encoding for files opened with 'rb' directive. That is: 1. Check if each line is Unicode Or Bytes Type. 2. If Bytes, get char array reference to internal buffer. 3. use PyUnicode_FromString to create a new unicode object from the char* - This step assumes UTF-8. 4. get a Py_UNICODE reference to internal unicode object buffer and continue as before. Is this in the right direction at all? Cheers, Jervis -- message_count: 9.0 -> 10.0 nosy: +jdwhitley nosy_count: 5.0 -> 6.0 Added file: http://bugs.python.org/file13279/csv.diff ___ 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
[issue5455] csv module no longer works as expected when file opened in binary mode
Jervis Whitley added the comment: Hi Skip, Currently, once we are sure the lineobj is a unicode obj we then get it's internal buffer using: line = PyUnicode_AsUnicode(lineobj); for the purpose of iterating through the line. is there an opportunity to use: line = PyBytes_AsString(lineobj); (or similar approach if I have quoted an incorrect function) for the case that we have a bytes object (not Unicode)? -- message_count: 2.0 -> 3.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
[issue5455] csv module no longer works as expected when file opened in binary mode
Jervis Whitley added the comment:
in _csv.c, the check is done here:
lineobj = PyIter_Next(self->input_iter);
if (lineobj == NULL) {
/* End of input OR exception */
if (!PyErr_Occurred() && self->field_len != 0)
PyErr_Format(error_obj,
"newline inside string");
return NULL;
}
if (!PyUnicode_Check(lineobj)) {
PyErr_Format(error_obj,
"iterator should return strings, "
"not %.200s "
"(did you open the file in text mode?)",
lineobj->ob_type->tp_name
);
Py_DECREF(lineobj);
return NULL;
}
So the returned lineobj is a bytes type and then the PyUnicode_Check
throws the error.
--
message_count: 1.0 -> 2.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
[issue5455] csv module no longer works as expected when file opened in binary mode
Changes by Jervis Whitley : -- nosy: +jdwhitley nosy_count: 1.0 -> 2.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
[issue1818] Add named tuple reader to CSV module
Jervis Whitley added the comment: Updated version of docs for 2.7 and 3k. -- message_count: 29.0 -> 30.0 Added file: http://bugs.python.org/file13274/ntreader6_py3.diff ___ 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 Jervis Whitley : Added file: http://bugs.python.org/file13275/ntreader6_py27.diff ___ 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 Jervis Whitley : Removed file: http://bugs.python.org/file13268/ntreader5_py3_1.diff ___ 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
Jervis Whitley added the comment: Antoine> I don't understand why NamedTupleReader requires the Antoine> fieldnames array Antoine> rather than the namedtuple class itself. If you could pass it Antoine> the namedtuple class, users could choose whatever namedtuple Antoine> subclass with whatever additional methods or behaviour suits Antoine> them. It would make NamedTupleReader more flexible and more Antoine> useful. The NamedTupleReader does take the namedtuple class as the fieldnames argument. It can be a namedtuple, a 'fieldnames' array or None. If a namedtuple is used as the fieldnames argument, returned rows are created using ._make from the this namedtuple. Unless I have read your requirements incorrectly, this is the behaviour you describe. Given the confusion, I accept that the documentation needs to be improved. The NamedTupleReader and Writer were created to follow as closely as possible the behaviour (and signature) of the DictReader and DictWriter, with the exception of using namedtuples instead of dicts. -- message_count: 27.0 -> 28.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
Jervis Whitley added the comment: Jervis> in csv.rst removed reference to reader.next() as a public method. Skip> Because? I've not seen any discussion in this issue or in any Skip> other forums Skip> (most certainly not on the c...@python.org mailing list) which would Skip> suggest Skip> that csv.reader's next() method should no longer be a public method. I agree, this should be applied separately. -- message_count: 26.0 -> 27.0 Added file: http://bugs.python.org/file13268/ntreader5_py3_1.diff ___ 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
Jervis Whitley added the comment: Added a patch against py3k branch. in csv.rst removed reference to reader.next() as a public method. Added file: http://bugs.python.org/file13263/ntreader4_py3_1.diff ___ 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
Jervis Whitley added the comment: Skip> Let me be more explicit. I don't know how it implements it, but I think Skip> you really need to give the user the option of specifying the field Skip> names and not reading/writing headers. It can't be implicit as I Skip> interpreted Rob's earlier comment: rrenaud> NamedTupleReader and NamedTupleWriter should be inverses. rrenaud> This means that NamedTupleWriter needs to write headers. I agree with Skip, we mustn't have a 'wroteheader' flag internal to the NamedTupleWriter. Currently to write a 'header' row with a csv.writer you could (for example) pass a tuple of header names to writerow. NamedTupleWriter is no different, you would have a namedtuple of header names instead of a tuple of header names. I would not like to see another flag added to the initialisation process to enable the writing of a header row as the 'first' (or any) row written to a file. We could add a function 'writeheader' that would write the contents of 'fieldnames' as a row, but I don't like the idea. Cheers, ___ 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
Jervis Whitley added the comment: Updated NamedTupleReader to give a rename=False keyword argument. rename is passed directly to the namedtuple factory function to enable automatic handling of invalid fieldnames. Two new tests for the rename keyword. Cheers, Added file: http://bugs.python.org/file13009/ntreader4.diff ___ 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
Jervis Whitley added the comment:
An implementation of a namedtuple reader and writer.
Created a writer for the case where user would like to specify
desired field names and default values on missing field names.
e.g.
mywriter = NamedTupleWriter(f, fieldnames=['f1', 'f2', 'f3'],
restval='missing')
Nt = namedtuple('LessFields', 'f1 f3')
nt = Nt(f1='one', f2=2)
mywriter.writerow(nt) # writes one,missing,2
any thoughts on case where defined fieldname has a leading
underscore? Should there be a flag to silently ignore?
e.g.
if self._ignore_underscores:
fieldname = fieldname.lstrip('_')
Leading underscores may be present in an unsighted csv file,
additionally, spaces and other non alpha numeric characters pose
a problem that does not affect the DictReader class.
Cheers,
--
keywords: +patch
nosy: +jdwhitley
Added file: http://bugs.python.org/file12990/ntreader3.diff
___
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
