[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-27 22:36
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
>Assigned to: Andrew McNamara (andrewmcnamara)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 05:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1744752 ] Newline skipped in "for line in file"
Bugs item #1744752, was opened at 2007-06-28 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744752&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rune Devik (runedevik) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: Creating new ticket for the bug described here since it was closed (and I was not able to reopen it): http://sourceforge.net/tracker/index.php?func=detail&aid=1636950&group_id=5470&atid=105470 The problem is that when you open a hughe file on windows with the "r" mode it will sometimes merge two lines. As I said in the ticket above (but probably ignored since I updated a closed ticket): Hi I have the same problem with a huge file (8GB) containing long lines. Sometimes two lines are merged into one and rerunning the test script that reads the file it's always the same lines that are merged. Also the merging happens more frequently towards the end of the file it seems. I tried to reproduce with a smaller data set (10 lines before the two lines that get merged, the two lines that gets merged and the 10 lines after that) but I was not able to reproduce on this smaller data set. However if you open this huge file in "rb" mode instead of "r" mode everything works as it should and no lines are merged at all! If I copy the file over to linux and rerun the test script no lines are merged (regardless if mode is "r" or "rb") so this is windows specific and might have something todo with the adding of \r\n if only \n is found when you open the file in "r" mode maybe? Also I have reproduced it on both python 2.3.5 and 2.5c1 on both windows XP and windows 2003. More stats on the input file in both "r" mode and "rb" mode below: Input file size: 8 695 828 KB fp = open(file, "r"): - total number of lines read: 668909 - length of the longest line: 13179792 - length of the shortest line: 89 - 56 lines contains the content of two lines - Always just two lines that are merged into one! - Always the same lines that are merged rerunning the test on the same file. open(file, "rb"): - total number of lines read: 668965 - length of the longest line: 13179793 - length of the shortest line: 90 - no lines merged Regards, Rune Devik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744752&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-28 13:36
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 21:35
Message:
Logged In: YES
user_id=698599
Originator: NO
Dialects were made immutable, because they can potentially represent the
configuration of a running state machine (the reader), and the dialects are
potentially shared.
If you want to change a registered dialect, I suggest you do something
like:
csv.register_dialect('excel', csv.get_dialect('excel'),
delimiter='\t')
This changes the dialect for new users, but doesn't disrupt the state of
already running readers.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 20:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-28 13:36
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 21:41
Message:
Logged In: YES
user_id=698599
Originator: NO
I should also mention that if you simply wanted a reader of a variant of
the "excel" dialect, the simplest way to achieve that is:
r=csv.reader(f, dialect='excel', delimiter='\t')
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 21:35
Message:
Logged In: YES
user_id=698599
Originator: NO
Dialects were made immutable, because they can potentially represent the
configuration of a running state machine (the reader), and the dialects are
potentially shared.
If you want to change a registered dialect, I suggest you do something
like:
csv.register_dialect('excel', csv.get_dialect('excel'),
delimiter='\t')
This changes the dialect for new users, but doesn't disrupt the state of
already running readers.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 20:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Santiago Gala (sgala)
Date: 2007-06-28 14:59
Message:
Logged In: YES
user_id=178886
Originator: YES
Still:
$ python -c "import codecs,sys; sys.stdout =
codecs.getwriter('utf-8')(sys.stdout); print sys.stdout.encoding"
UTF-8
$ python -c "import codecs,sys; sys.stdout =
codecs.getwriter('utf-8')(sys.stdout); print sys.stdout.encoding" | cat
None
but now, at least
$ python -c "import codecs,sys; sys.stdout =
codecs.getwriter('utf-8')(sys.stdout); print unicode('á %s' %
'éí','utf8') "
á éí
$ python -c "import codecs,sys; sys.stdout =
codecs.getwriter('utf-8')(sys.stdout); print unicode('á %s' %
'éí','utf8') " | cat
á éí
can be piped.
It still looks amazing to me that people is happy with this behavior.
Waiting anxiously to see how this is dealt with in the str/unicode
unification coming for python 3000...
Santiago :)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-06-27 14:04
Message:
Logged In: YES
user_id=849994
Originator: NO
Yes, I'm sorry my fix is bad, you should rather use
sys.stdout = codecs.getwriter('utf-8')(sys.stdout)
--
Comment By: Omari Norman (massysett)
Date: 2007-06-27 13:29
Message:
Logged In: YES
user_id=1764292
Originator: NO
The fix given by gbrandl, which is to use
sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8')
does not work. EncodedFile expects to receive encoded strings, so if you
try to use it with Unicode strings, you get errors. I could of course
I tried
sys.stdout = codecs.open(sys.stdout, 'w', 'utf-8')
but that gives me "Type Error: coercing to Unicode: need string or buffer,
file found."
Since this was (absurdly) closed as invalid, are there any good fixes that
actually work?
--
Comment By: Santiago Gala (sgala)
Date: 2007-03-03 14:22
Message:
Logged In: YES
user_id=178886
Originator: YES
>This is not magic. "print" looks for an "encoding" attribute on the file
>it is printing to. This is the terminal encoding for sys.stdout and None
>for other files.
I'll correct you:
"print" looks for an "encoding" attribute on the file it is printing to.
This is the terminal encoding for sys.stdout *if sys.stdout is a terminal*
and None when sys.stdout is not a terminal.
After all, the bug reported is that *the same program* behaved different
when used standalone than when piped to less:
$ python -c "import sys; print sys.stdout.encoding"
UTF-8
$ python -c "import sys; print sys.stdout.encoding" | cat
None
If you say that this is intended, not a bug, that an external process is
altering the behavior of a python program, I'd just leave it written to
warn other naive people like myself, that thinks that an external program
should not influence python behavior (with *the same environment*):
$ locale
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=es_ES.UTF-8
But I take it as a design flaw, and against all pythonic principles,
probably coming from the fact that a lot of python developers/users are
windows people that don't care about stdout at all.
IMO, the behavior should be either:
- use always None for sys.stdout
- use always LC_CTYPE or LANG for sys.stdout
I prefer the second one, as when I pipe stdout, after all, I expect it to
be honoring my locale settings. Don't forg
[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-27 22:36
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 09:38
Message:
Logged In: YES
user_id=44345
Originator: NO
Would it have made sense to save the class when registering then
return a new instance from get_dialect()? I believe the current
scheme instantiates the dialect being registered, then returns that
object anytime get_dialect is called. That would have allowed the
user to modify the returned dialect to their heart's content without
messing up the registered dialect.
At the very least I think this change needs to be documented.
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 06:41
Message:
Logged In: YES
user_id=698599
Originator: NO
I should also mention that if you simply wanted a reader of a variant of
the "excel" dialect, the simplest way to achieve that is:
r=csv.reader(f, dialect='excel', delimiter='\t')
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 06:35
Message:
Logged In: YES
user_id=698599
Originator: NO
Dialects were made immutable, because they can potentially represent the
configuration of a running state machine (the reader), and the dialects are
potentially shared.
If you want to change a registered dialect, I suggest you do something
like:
csv.register_dialect('excel', csv.get_dialect('excel'),
delimiter='\t')
This changes the dialect for new users, but doesn't disrupt the state of
already running readers.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 05:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745035 ] DoS smtpd vulnerability
Bugs item #1745035, was opened at 2007-06-28 21:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745035 ] DoS smtpd vulnerability
Bugs item #1745035, was opened at 2007-06-28 21:44
Message generated for change (Comment added) made by billiejoex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: DoS smtpd vulnerability
Initial Comment:
Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if
received lines are too long (possible Denial-of-Service attacks).
Without truncating such buffer a simple malicious script sending extremely long
lines without "\r\n" terminator could easily saturate system resources.
--
>Comment By: billiejoex (billiejoex)
Date: 2007-06-28 21:45
Message:
Logged In: YES
user_id=1357589
Originator: YES
--- malicious script
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 8025))
while 1:
s.sendall('x' * 1024)
--- proposed smtpd.py patch
124a125
> self.__in_buffer_len = 0
135a137,139
> self.__in_buffer_len += len(data)
> if self.__in_buffer_len > 4096:
> self.__line = []
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745035 ] DoS smtpd vulnerability
Bugs item #1745035, was opened at 2007-06-28 21:44
Message generated for change (Settings changed) made by billiejoex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: DoS smtpd vulnerability
Initial Comment:
Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if
received lines are too long (possible Denial-of-Service attacks).
Without truncating such buffer a simple malicious script sending extremely long
lines without "\r\n" terminator could easily saturate system resources.
--
Comment By: billiejoex (billiejoex)
Date: 2007-06-28 21:45
Message:
Logged In: YES
user_id=1357589
Originator: YES
--- malicious script
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 8025))
while 1:
s.sendall('x' * 1024)
--- proposed smtpd.py patch
124a125
> self.__in_buffer_len = 0
135a137,139
> self.__in_buffer_len += len(data)
> if self.__in_buffer_len > 4096:
> self.__line = []
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-28 13:36
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-29 09:32
Message:
Logged In: YES
user_id=698599
Originator: NO
The user already has a number of entirely satisfactory ways to "modify"
the dialect - the module is implemented as it is to keep the code simple
and obvious (from a maintenance point of view).
As far as I'm concerned the old behaviour was undocumented and accidental.
I don't mind if you want to document the new behaviour, but I'm afraid I
don't have time to do it at the moment.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-29 00:38
Message:
Logged In: YES
user_id=44345
Originator: NO
Would it have made sense to save the class when registering then
return a new instance from get_dialect()? I believe the current
scheme instantiates the dialect being registered, then returns that
object anytime get_dialect is called. That would have allowed the
user to modify the returned dialect to their heart's content without
messing up the registered dialect.
At the very least I think this change needs to be documented.
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 21:41
Message:
Logged In: YES
user_id=698599
Originator: NO
I should also mention that if you simply wanted a reader of a variant of
the "excel" dialect, the simplest way to achieve that is:
r=csv.reader(f, dialect='excel', delimiter='\t')
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 21:35
Message:
Logged In: YES
user_id=698599
Originator: NO
Dialects were made immutable, because they can potentially represent the
configuration of a running state machine (the reader), and the dialects are
potentially shared.
If you want to change a registered dialect, I suggest you do something
like:
csv.register_dialect('excel', csv.get_dialect('excel'),
delimiter='\t')
This changes the dialect for new users, but doesn't disrupt the state of
already running readers.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 20:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745108 ] 2.5.1 curses panel segfault in new_panel on aix 5.3
Bugs item #1745108, was opened at 2007-06-29 00:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mattias Wadenstein (maswan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 curses panel segfault in new_panel on aix 5.3 Initial Comment: I've compiled python 2.5.1 on AIX 5.3 with ncurses 5.6 and I get segmentation faults as soon as any curses.panel tries to make a new panel. The following test program gives a segmentation fault for me (remove the new_panel line and it works fine): import curses from curses import panel def mkpanel(scr): win = curses.newwin(8,8,1,1) pan = panel.new_panel(win) curses.wrapper(mkpanel) Also the test_curses program triggers this segfault. A traceback puts the problem in: root_panel(), line 57 in "p_new.c" new_panel(win = 0x000110246dc0), line 90 in "p_new.c" PyCurses_new_panel(self = (nil), args = 0x000110246dc0), line 396 in "_curses_panel.c" PyCFunction_Call(func = 0x00011024a368, arg = 0x000110246dc0, kw = (nil)), line 73 in "methodobject.c" Note that the ncurses I've compiled works fine with the shipped test programs, so it seems to be an issue with the python interaction. Please let me know if there is anything else that I can provide to help track this bug down. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1744580 ] cvs.get_dialect() return a class object
Bugs item #1744580, was opened at 2007-06-27 22:36
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Kristukat (ckkart)
>Assigned to: Skip Montanaro (montanaro)
Summary: cvs.get_dialect() return a class object
Initial Comment:
With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class
object in contrast to python 2.4 where an instance of csv.excel is returned,
the former having only read only attributes.
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 21:46
Message:
Logged In: YES
user_id=44345
Originator: NO
Grabbing this. I'll try to come up with some wording about the change.
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 18:32
Message:
Logged In: YES
user_id=698599
Originator: NO
The user already has a number of entirely satisfactory ways to "modify"
the dialect - the module is implemented as it is to keep the code simple
and obvious (from a maintenance point of view).
As far as I'm concerned the old behaviour was undocumented and accidental.
I don't mind if you want to document the new behaviour, but I'm afraid I
don't have time to do it at the moment.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 09:38
Message:
Logged In: YES
user_id=44345
Originator: NO
Would it have made sense to save the class when registering then
return a new instance from get_dialect()? I believe the current
scheme instantiates the dialect being registered, then returns that
object anytime get_dialect is called. That would have allowed the
user to modify the returned dialect to their heart's content without
messing up the registered dialect.
At the very least I think this change needs to be documented.
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 06:41
Message:
Logged In: YES
user_id=698599
Originator: NO
I should also mention that if you simply wanted a reader of a variant of
the "excel" dialect, the simplest way to achieve that is:
r=csv.reader(f, dialect='excel', delimiter='\t')
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2007-06-28 06:35
Message:
Logged In: YES
user_id=698599
Originator: NO
Dialects were made immutable, because they can potentially represent the
configuration of a running state machine (the reader), and the dialects are
potentially shared.
If you want to change a registered dialect, I suggest you do something
like:
csv.register_dialect('excel', csv.get_dialect('excel'),
delimiter='\t')
This changes the dialect for new users, but doesn't disrupt the state of
already running readers.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-28 05:56
Message:
Logged In: YES
user_id=44345
Originator: NO
I took a brief look at the code. get_dialect is imported from the
underlying _csv.c extension module and didn't change between 2.4 and 2.5.
There is a new static function, _call_dialect, though. It is called from
several places, most notably from csv_register_dialect. The code in 2.4
that it replaces seems much different to me than the code in the body of
_call_dialect. I suspect there was some sort of regression there.
Assigning to Andrew since he's the primary author of the code as well as
the author of this particular change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
