[Python-Dev] Exception pickling patch
Can somebody please review this patch: https://sourceforge.net/support/tracker.php?aid=1692335 It aims to fix the pickling of exceptions whose __init__ methods don't call Exception.__init__ at all, or with a different number of arguments. This should be fixed before 2.5.2. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Universal newlines support in Python 3.0
On Aug 10, 2007, at 11:23 AM, Guido van Rossum wrote:
> Python 3.0 currently has limited universal newlines support: by
> default, \r\n is translated into \n for text files, but this can be
> controlled by the newline= keyword parameter. For details on how, see
> PEP 3116. The PEP prescribes that a lone \r must also be translated,
> though this hasn't been implemented yet (any volunteers?).
>
I'm working on this, but now I'm not sure how the file is supposed to
be read when
the newline parameter is \r or \r\n. Here's the PEP language:
buffer is a reference to the BufferedIOBase object to be wrapped
with the TextIOWrapper.
encoding refers to an encoding to be used for translating between
the byte-representation
and character-representation. If it is None, then the system's
locale setting will be used
as the default. newline can be None, '\n', '\r', or '\r\n' (all
other values are illegal);
it indicates the translation for '\n' characters written. If None,
a system-specific default
is chosen, i.e., '\r\n' on Windows and '\n' on Unix/Linux. Setting
newline='\n' on input
means that no CRLF translation is done; lines ending in '\r\n'
will be returned as '\r\n'.
('\r' support is still needed for some OSX applications that
produce files using '\r' line
endings; Excel (when exporting to text) and Adobe Illustrator EPS
files are the most common examples.
Is this ok: when newline='\r\n' or newline='\r' is passed, only that
string is used to determine
the end of lines. No translation to '\n' is done.
> However, the old universal newlines feature also set an attibute named
> 'newlines' on the file object to a tuple of up to three elements
> giving the actual line endings that were observed on the file so far
> (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not
> implemented. I'm tempted to kill it. Does anyone have a use case for
> this? Has anyone even ever used this?
>
This strikes me as a pragmatic feature, making it easy to read a file
and write back the same line ending. I can include in patch.
http://www.google.com/codesearch?hl=en&q=+lang:python+%22.newlines%22
+show:cz2Fhijwr3s:yutdXigOmYY:YDns9IyEkLQ&sa=N&cd=12&ct=rc&cs_p=http://f
tp.gnome.org/pub/gnome/sources/meld/1.0/
meld-1.0.0.tar.bz2&cs_f=meld-1.0.0/filediff.py#a0
http://www.google.com/codesearch?hl=en&q=+lang:python+%22.newlines%22
+show:SLyZnjuFadw:kOTmKU8aU2I:VX_dFr3mrWw&sa=N&cd=37&ct=rc&cs_p=http://s
vn.python.org/projects/ctypes/trunk&cs_f=ctypeslib/ctypeslib/
dynamic_module.py#a0
Thanks
-Tony
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Universal newlines support in Python 3.0
On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On Aug 10, 2007, at 11:23 AM, Guido van Rossum wrote:
>
> > Python 3.0 currently has limited universal newlines support: by
> > default, \r\n is translated into \n for text files, but this can be
> > controlled by the newline= keyword parameter. For details on how, see
> > PEP 3116. The PEP prescribes that a lone \r must also be translated,
> > though this hasn't been implemented yet (any volunteers?).
> >
>
> I'm working on this, but now I'm not sure how the file is supposed to
> be read when
> the newline parameter is \r or \r\n. Here's the PEP language:
>
>buffer is a reference to the BufferedIOBase object to be wrapped
> with the TextIOWrapper.
>encoding refers to an encoding to be used for translating between
> the byte-representation
>and character-representation. If it is None, then the system's
> locale setting will be used
>as the default. newline can be None, '\n', '\r', or '\r\n' (all
> other values are illegal);
>it indicates the translation for '\n' characters written. If None,
> a system-specific default
>is chosen, i.e., '\r\n' on Windows and '\n' on Unix/Linux. Setting
> newline='\n' on input
>means that no CRLF translation is done; lines ending in '\r\n'
> will be returned as '\r\n'.
>('\r' support is still needed for some OSX applications that
> produce files using '\r' line
>endings; Excel (when exporting to text) and Adobe Illustrator EPS
> files are the most common examples.
>
> Is this ok: when newline='\r\n' or newline='\r' is passed, only that
> string is used to determine
> the end of lines. No translation to '\n' is done.
I *think* it would be more useful if it always returned lines ending
in \n (not \r\n or \r). Wouldn't it? Although this is not how it
currently behaves; when you set newline='\r\n', it returns the \r\n
unchanged, so it would make sense to do this too when newline='\r'.
Caveat user I guess.
> > However, the old universal newlines feature also set an attibute named
> > 'newlines' on the file object to a tuple of up to three elements
> > giving the actual line endings that were observed on the file so far
> > (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not
> > implemented. I'm tempted to kill it. Does anyone have a use case for
> > this? Has anyone even ever used this?
> >
>
> This strikes me as a pragmatic feature, making it easy to read a file
> and write back the same line ending. I can include in patch.
OK, if you think you can, that's good. It's not always sufficient (not
if there was a mix of line endings) but it's a start.
> http://www.google.com/codesearch?hl=en&q=+lang:python+%22.newlines%22
> +show:cz2Fhijwr3s:yutdXigOmYY:YDns9IyEkLQ&sa=N&cd=12&ct=rc&cs_p=http://f
> tp.gnome.org/pub/gnome/sources/meld/1.0/
> meld-1.0.0.tar.bz2&cs_f=meld-1.0.0/filediff.py#a0
>
> http://www.google.com/codesearch?hl=en&q=+lang:python+%22.newlines%22
> +show:SLyZnjuFadw:kOTmKU8aU2I:VX_dFr3mrWw&sa=N&cd=37&ct=rc&cs_p=http://s
> vn.python.org/projects/ctypes/trunk&cs_f=ctypeslib/ctypeslib/
> dynamic_module.py#a0
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Universal newlines support in Python 3.0
On Aug 11, 2007, at 10:29 AM, Guido van Rossum wrote: >> Is this ok: when newline='\r\n' or newline='\r' is passed, only that >> string is used to determine >> the end of lines. No translation to '\n' is done. > > I *think* it would be more useful if it always returned lines ending > in \n (not \r\n or \r). Wouldn't it? Although this is not how it > currently behaves; when you set newline='\r\n', it returns the \r\n > unchanged, so it would make sense to do this too when newline='\r'. > Caveat user I guess. Because there's an easy way to translate, having the option to not translate apply to all valid newline values is probably more useful. I do think it's easier to define the behavior this way. > OK, if you think you can, that's good. It's not always sufficient (not > if there was a mix of line endings) but it's a start. Right -Tony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (08/05/07 - 08/12/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1295 open ( +8) / 11130 closed ( +2) / 12425 total (+10) Average duration of open issues: 690 days. Median duration of open issues: 553 days. Open Issues Breakdown open 1295 ( +8) pending 0 ( +0) Issues Created Or Reopened (10) ___ x08/08/07 http://bugs.python.org/issue1000created gbrandl MSVC++8 x86 tkinter build patch for trunk08/05/07 http://bugs.python.org/issue1767787 created brotch test_asyncore fix08/05/07 http://bugs.python.org/issue1767834 created hdiwan650 Badly formed XML using etree and utf-16 08/05/07 http://bugs.python.org/issue1767933 created bugok Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong 08/06/07 http://bugs.python.org/issue1768121 created lpd tutorial 08/06/07 CLOSED http://bugs.python.org/issue1768767 created mrbax Python - Operation time out problem 08/06/07 http://bugs.python.org/issue1768858 created mohammedsk Fix for failing test_scriptpackages in py3k-struni 08/07/07 CLOSED http://bugs.python.org/issue1768976 created arsatiki A paragraph about packages should be updated.08/07/07 http://bugs.python.org/issue1769002 created noamr Fix for failing test_plistlib in py3k-struni 08/07/07 http://bugs.python.org/issue1769016 created brotch Issues Now Closed (7) _ fix 1668596: copy datafiles properly when package_dir is ' ' 83 days http://bugs.python.org/issue1720897 loewis unicode(None,charset) raise TypeError 15 days http://bugs.python.org/issue1758804 sf-robot socket close fixed 6 days http://bugs.python.org/issue1763387 jyasskin urllib2-howto - correction 4 days http://bugs.python.org/issue1765839 gbrandl test_csv struni fixes + unicode support in _csv3 days http://bugs.python.org/issue1767398 gvanrossum tutorial 0 days http://bugs.python.org/issue1768767 mrbax Fix for failing test_scriptpackages in py3k-struni 0 days http://bugs.python.org/issue1768976 nnorwitz ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
