[Python-Dev] Python 3.0a documentation
I'd like to help out cleaning up the Python3.0 documentation. There are a lot of little leftovers from 2.x that are no longer true. (mentions of long, callable() etc.) Ideally (especially in the tutorial), we should only refer to 3.0 features and syntax, and keep the special cases and "other ways to do it" to a minimum. Before I dive in and start submitting patches, what does everyone else think? How much reference to previous python versions should be left in? Does it make sense to keep notes of the nature of "since version 2.3 ..." when there is an intentional discontinuity at 3.0? Peter Harris ___ 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 3.0a documentation
I fully support removing all historic references from the 3.0 language
manual. Please do help out! You can just start putting patches ("svn
diff") into bugs.python.org; typically Georg gets to these very
quickly. Do use subversion, not the distributed tarbal (which was out
of date by the time it was uploaded to python.org. :-).
--Guido
On 9/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd like to help out cleaning up the Python3.0 documentation. There are a
> lot of little leftovers from 2.x that are no longer true. (mentions of
> long, callable() etc.)
>
> Ideally (especially in the tutorial), we should only refer to 3.0 features
> and syntax, and keep the special cases and "other ways to do it" to a
> minimum.
>
> Before I dive in and start submitting patches, what does everyone else
> think? How much reference to previous python versions should be left in?
> Does it make sense to keep notes of the nature of "since version 2.3 ..."
> when there is an intentional discontinuity at 3.0?
>
> Peter Harris
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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
[Python-Dev] Iterating over objects of unknown length
Hello!
(This seems like a "developing with Python" question and partially it is
but please read on.)
I have a class that represents SQL queries. Instances of the class can
be iterated over. As an SQL query doesn't know in advance if it will
produce any row the class doesn't implement __len__(). Moreover, users of
the class sometimes write
if sqlQuery:
for row in sqlQuery: ...
else:
# no rows
which is a bug (the query doesn't know if it's True or False; to find it
out the user have to execute the query by trying to iterate over it). To
prevent users from writing such code the class implements __nonzero__()
that always raises an exception.
Unfortunately, I found some libraries test the object in boolean context
before iterating over it and that, of course, triggers the exception from
__nonzero__().
Even worse, some libraries test the object in boolean context regardless
of iterating over it. For example, logging module (this is where my
question becomes "developing for Python") triggers the exception in such
simple case:
logginig.debug("Query: %s", sqlQuery)
Funny, the code
logginig.debug("Query: %s, another: %s", sqlQuery, another_value)
doesn't trigger the exception. This is due to the code in
logginig/__init__.py:
if args and (len(args) == 1) and args[0] and (type(args[0]) ==
types.DictType):
args = args[0]
(class LogRecord, method __init__). "and args[0]" triggers the exception.
My questions are:
1. Should I consider this a bug in the logging module (and other libraries)
and submit patches?
2. Or should I stop raising exceptions in __nonzero__()?
In this particular case with logging the fix is simple - do "and args[0]"
after type check.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
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] Iterating over objects of unknown length
The logging code looks archaic: IMO it should be:
if args and len(args) == 1 and isinstance(args[0], dict) and args[0]:
But I also fail to see why you would be so draconian as to disallow
truth testing of a query altogether. Your query looks like an
iterator. There are tons of other iterators in the language, library
and 3rd party code, and it would be madness to try to fix all of them
in the way you suggest just because some users don't get the concept
of iterators.
So I'm for #1 *and* #2.
--Guido
On 9/26/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> Hello!
>
>(This seems like a "developing with Python" question and partially it is
> but please read on.)
>
>I have a class that represents SQL queries. Instances of the class can
> be iterated over. As an SQL query doesn't know in advance if it will
> produce any row the class doesn't implement __len__(). Moreover, users of
> the class sometimes write
>
> if sqlQuery:
>for row in sqlQuery: ...
> else:
># no rows
>
> which is a bug (the query doesn't know if it's True or False; to find it
> out the user have to execute the query by trying to iterate over it). To
> prevent users from writing such code the class implements __nonzero__()
> that always raises an exception.
>Unfortunately, I found some libraries test the object in boolean context
> before iterating over it and that, of course, triggers the exception from
> __nonzero__().
>Even worse, some libraries test the object in boolean context regardless
> of iterating over it. For example, logging module (this is where my
> question becomes "developing for Python") triggers the exception in such
> simple case:
>
> logginig.debug("Query: %s", sqlQuery)
>
>Funny, the code
>
> logginig.debug("Query: %s, another: %s", sqlQuery, another_value)
>
>doesn't trigger the exception. This is due to the code in
> logginig/__init__.py:
>
> if args and (len(args) == 1) and args[0] and (type(args[0]) ==
> types.DictType):
> args = args[0]
>
> (class LogRecord, method __init__). "and args[0]" triggers the exception.
>
>My questions are:
>
> 1. Should I consider this a bug in the logging module (and other libraries)
>and submit patches?
> 2. Or should I stop raising exceptions in __nonzero__()?
>
>In this particular case with logging the fix is simple - do "and args[0]"
> after type check.
>
> Oleg.
> --
> Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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] Iterating over objects of unknown length
At 07:24 PM 9/26/2007 +0400, Oleg Broytmann wrote: >Hello! > >(This seems like a "developing with Python" question and partially it is >but please read on.) > >I have a class that represents SQL queries. Instances of the class can >be iterated over. As an SQL query doesn't know in advance if it will >produce any row the class doesn't implement __len__(). Moreover, users of >the class sometimes write > >if sqlQuery: >for row in sqlQuery: ... >else: ># no rows This isn't consistent with iterators; e.g.: >>> x=iter([]) >>> if x: print "yes" ... yes ISTM that you should be returning "True" from __nonzero__, since you don't implement len(). >1. Should I consider this a bug in the logging module (and other libraries) >and submit patches? >2. Or should I stop raising exceptions in __nonzero__()? #2 - Python objects should always be __nonzero__, unless they are empty containers, zeros, or otherwise specifically False. It's reasonable for libraries to expect that truth-testing an object is always safe. ___ 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 3.0a documentation
Guido> I fully support removing all historic references from the 3.0 Guido> language manual. By historic I assume you mean references to 2.x modules, classes, functions, etc which are no longer present. One thing I would suggest is that the more recent versionadded strings be kept. At the very least, if something is going to be new in 2.6, keep that. Maybe also keep the 2.5 versionadded references. Older references can probably be deleted. Skip ___ 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 3.0a documentation
On 9/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Guido> I fully support removing all historic references from the 3.0 > Guido> language manual. > > By historic I assume you mean references to 2.x modules, classes, functions, > etc which are no longer present. One thing I would suggest is that the more > recent versionadded strings be kept. At the very least, if something is > going to be new in 2.6, keep that. Maybe also keep the 2.5 versionadded > references. Older references can probably be deleted. In the 2.x docs, all versionadded strings should stay. But IMO in the 3.0 docs we should get rid of them all. If you want compatibility information, look at the 2.6 docs (those should also mention things that are changing in 3.0). -- --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] Iterating over objects of unknown length
On Wed, Sep 26, 2007 at 09:29:10AM -0700, Guido van Rossum wrote: > But I also fail to see why you would be so draconian as to disallow > truth testing of a query altogether. Your query looks like an > iterator. There are tons of other iterators in the language, library > and 3rd party code, and it would be madness to try to fix all of them > in the way you suggest just because some users don't get the concept > of iterators. Seems me myself didn't get it: On Wed, Sep 26, 2007 at 12:33:33PM -0400, Phillip J. Eby wrote: > This isn't consistent with iterators; e.g.: > > >>> x=iter([]) > >>> if x: print "yes" > ... > yes On Wed, Sep 26, 2007 at 09:29:10AM -0700, Guido van Rossum wrote: > So I'm for #1 *and* #2. I see now. Thank you! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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 3.0a documentation
> In the 2.x docs, all versionadded strings should stay. But IMO in the > 3.0 docs we should get rid of them all. If you want compatibility > information, look at the 2.6 docs (those should also mention things > that are changing in 3.0). I agree. People who target 3.x need to test anyway if they also want to support some 2.x version (if that is possible at all), so it does not help them to know what Python version introduced a certain feature they use. Regards, Martin ___ 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 3.0a documentation
Martin v. Löwis schrieb: >> In the 2.x docs, all versionadded strings should stay. But IMO in the >> 3.0 docs we should get rid of them all. If you want compatibility >> information, look at the 2.6 docs (those should also mention things >> that are changing in 3.0). > > I agree. People who target 3.x need to test anyway if they also want > to support some 2.x version (if that is possible at all), so it does > not help them to know what Python version introduced a certain feature > they use. Also, it has already been done, and would be painful to undo :) 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
[Python-Dev] New lines, carriage returns, and Windows
We ran into an interesting user-reported issue w/ IronPython and the way Python writes to files and I thought I'd get python-dev's opinion. When writing a string in text mode that contains \r\n we both write \r\r\n because the default write mode is to replace \n with \r\n. This works great as long as you stay within an entirely Python world. Because Python uses \n for everything internally you'll never end up writing out a \r\n that gets transformed into a \r\r\n. But when interoperating with other native code (or .NET code in our case) it's fairly easy to be exposed to a string which contains \r\n. Ultimately we see odd behavior when round tripping the contents of a multi-line text box through a file. So today users have to be aware of the fact that Python internally always uses \n. They also need to be aware of any APIs that they call that might return a string with an embedded \r\n inside of them and transform the string back into the Python version. It could be argued that there's little value in doing the simple transformation from \r\n -> \r\r\n. Ultimately that creates a file that has line endings which aren't good on any platform. On the other hand it could also be argued that Python defines new-lines as \n and there should be no deviation from that. And doing so could be considered a slippery slope, first file deals with it, and next the standard libraries, etc... Finally this might break some apps and if we changed IronPython to behave differently we could introduce incompatibilities which we don't want. So I'm curious: Is there a reason this behavior is useful that I'm missing? Would there be a possibility (or objections to) making \r\n be untransformed in the Py3k timeframe? Or should we just tell our users to open files in binary mode? :) ___ 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] New lines, carriage returns, and Windows
Dino Viehland wrote: > We ran into an interesting user-reported issue w/ IronPython and the way > Python writes to files and I thought I'd get python-dev's opinion. > > When writing a string in text mode that contains \r\n we both write \r\r\n > because the default write mode is to replace \n with \r\n. This works great > as long as you stay within an entirely Python world. Because Python uses \n > for everything internally you'll never end up writing out a \r\n that gets > transformed into a \r\r\n. But when interoperating with other native code > (or .NET code in our case) it's fairly easy to be exposed to a string which > contains \r\n. Ultimately we see odd behavior when round tripping the > contents of a multi-line text box through a file. > > So today users have to be aware of the fact that Python internally always > uses \n. They also need to be aware of any APIs that they call that might > return a string with an embedded \r\n inside of them and transform the string > back into the Python version. > > It could be argued that there's little value in doing the simple > transformation from \r\n -> \r\r\n. Ultimately that creates a file that has > line endings which aren't good on any platform. On the other hand it could > also be argued that Python defines new-lines as \n and there should be no > deviation from that. And doing so could be considered a slippery slope, > first file deals with it, and next the standard libraries, etc... Finally > this might break some apps and if we changed IronPython to behave differently > we could introduce incompatibilities which we don't want. > > So I'm curious: Is there a reason this behavior is useful that I'm missing? > Would there be a possibility (or objections to) making \r\n be untransformed > in the Py3k timeframe? Or should we just tell our users to open files in > binary mode? :) > It is normal when working with Windows interaction in the Python world to be aware that you might receive strings with '\r\n' in and do the conversion yourself. We come across this a great deal with Resolver (when working with multi line text boxes for example) and quite happily replace '\r\n' with '\n' and vice versa as needed. As a developer who uses both Python and IronPython I say that this isn't a problem. I may be wrong or outvoted of course... Michael http://www.manning.com/foord > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ 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] New lines, carriage returns, and Windows
> This works great as long as you stay within an entirely Python world. > Because Python uses \n for everything internally I think you misunderstand fairly significantly how this all works together. Python does not use \n "for everything internally". Python is well capable of representing \r separately, and does so if you ask it to. > So I'm curious: Is there a reason this behavior is useful that I'm > missing? I think you are missing how it works in the first place (or else you failed to communicate to me what precise behavior you find puzzling). Regards, Martin ___ 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] New lines, carriage returns, and Windows
On 9/26/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> We ran into an interesting user-reported issue w/ IronPython and the way
> Python writes to files and I thought I'd get python-dev's opinion.
>
> When writing a string in text mode that contains \r\n we both write \r\r\n
> because the default write mode is to replace \n with \r\n. This works great
> as long as you stay within an entirely Python world. Because Python uses \n
> for everything internally you'll never end up writing out a \r\n that gets
> transformed into a \r\r\n. But when interoperating with other native code
> (or .NET code in our case) it's fairly easy to be exposed to a string which
> contains \r\n. Ultimately we see odd behavior when round tripping the
> contents of a multi-line text box through a file.
>
> So today users have to be aware of the fact that Python internally always
> uses \n. They also need to be aware of any APIs that they call that might
> return a string with an embedded \r\n inside of them and transform the string
> back into the Python version.
>
> It could be argued that there's little value in doing the simple
> transformation from \r\n -> \r\r\n. Ultimately that creates a file that has
> line endings which aren't good on any platform. On the other hand it could
> also be argued that Python defines new-lines as \n and there should be no
> deviation from that. And doing so could be considered a slippery slope,
> first file deals with it, and next the standard libraries, etc... Finally
> this might break some apps and if we changed IronPython to behave differently
> we could introduce incompatibilities which we don't want.
>
> So I'm curious: Is there a reason this behavior is useful that I'm missing?
No, it is simply the way Microsoft's C stdio library works. :-(
A simple workaround would be to apply s.replace('\r', '') before
writing anything of course.
> Would there be a possibility (or objections to) making \r\n be untransformed
> in the Py3k timeframe? Or should we just tell our users to open files in
> binary mode? :)
Py3k supports a number of different ways of working with newlines for
text files, but not (yet) one that leaves \r\n alone while translating
a lone \n into \r\n. It may not be too late to change that though.
--
--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] New lines, carriage returns, and Windows
My understanding is that users can write code that uses only \n and Python will
write the end-of-line character(s) that are appropriate for the platform when
writing to a file. That's what I meant by uses \n for everything internally.
But if you write \r\n to a file Python completely ignores the presence of the
\r and transforms the \n into a \r\n anyway, hence the \r\r in the resulting
stream. My last question is simply does anyone find writing \r\r\n when the
original string contained \r\n a useful behavior - personally I don't see how
it is.
But Guido's response makes this sound like it's a problem w/ VC++ stdio
implementation and not something that Python is explicitly doing. Anyway, it'd
might be useful to have a text-mode file that you can write \r\n to and only
get \r\n in the resulting file. But if the general sentiment is
s.replace('\r', '') is the way to go we can advice our users of the behavior
when interoperating w/ APIs that return \r\n in strings.
-Original Message-
From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 3:01 PM
To: Dino Viehland
Cc: [email protected]
Subject: Re: [Python-Dev] New lines, carriage returns, and Windows
> This works great as long as you stay within an entirely Python world.
> Because Python uses \n for everything internally
I think you misunderstand fairly significantly how this all works
together. Python does not use \n "for everything internally". Python
is well capable of representing \r separately, and does so if you
ask it to.
> So I'm curious: Is there a reason this behavior is useful that I'm
> missing?
I think you are missing how it works in the first place (or else
you failed to communicate to me what precise behavior you find
puzzling).
Regards,
Martin
___
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] Re: New lines, carriage returns, and Windows
Dino Viehland wrote:
> My understanding is that users can write code that uses only \n and Python
> will write the end-of-line character(s) that are appropriate for the platform
> when writing to a file. That's what I meant by uses \n for everything
> internally.
>
> But if you write \r\n to a file Python completely ignores the presence of the
> \r and transforms the \n into a \r\n anyway, hence the \r\r in the resulting
> stream. My last question is simply does anyone find writing \r\r\n when the
> original string contained \r\n a useful behavior - personally I don't see how
> it is.
>
> But Guido's response makes this sound like it's a problem w/ VC++ stdio
> implementation and not something that Python is explicitly doing. Anyway,
> it'd might be useful to have a text-mode file that you can write \r\n to and
> only get \r\n in the resulting file. But if the general sentiment is
> s.replace('\r', '') is the way to go we can advice our users of the behavior
> when interoperating w/ APIs that return \r\n in strings.
>
We always do replace('\r\n','\n') but same difference...
Michael
>
> -Original Message-
> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 26, 2007 3:01 PM
> To: Dino Viehland
> Cc: [email protected]
> Subject: Re: [Python-Dev] New lines, carriage returns, and Windows
>
>
>> This works great as long as you stay within an entirely Python world.
>> Because Python uses \n for everything internally
>>
>
> I think you misunderstand fairly significantly how this all works
> together. Python does not use \n "for everything internally". Python
> is well capable of representing \r separately, and does so if you
> ask it to.
>
>
>> So I'm curious: Is there a reason this behavior is useful that I'm
>> missing?
>>
>
> I think you are missing how it works in the first place (or else
> you failed to communicate to me what precise behavior you find
> puzzling).
>
> Regards,
> Martin
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>
___
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] Re: New lines, carriage returns, and Windows
And if this is fine for you, given that you may have the largest WinForms / IronPython code base, I tend to think the replace may be reasonable. But we have had someone get surprised by this behavior. -Original Message- From: Michael Foord [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 3:15 PM To: Dino Viehland Cc: [email protected] Subject: Re: [python] Re: [Python-Dev] New lines, carriage returns, and Windows Dino Viehland wrote: > My understanding is that users can write code that uses only \n and Python > will write the end-of-line character(s) that are appropriate for the platform > when writing to a file. That's what I meant by uses \n for everything > internally. > > But if you write \r\n to a file Python completely ignores the presence of the > \r and transforms the \n into a \r\n anyway, hence the \r\r in the resulting > stream. My last question is simply does anyone find writing \r\r\n when the > original string contained \r\n a useful behavior - personally I don't see how > it is. > > But Guido's response makes this sound like it's a problem w/ VC++ stdio > implementation and not something that Python is explicitly doing. Anyway, > it'd might be useful to have a text-mode file that you can write \r\n to and > only get \r\n in the resulting file. But if the general sentiment is > s.replace('\r', '') is the way to go we can advice our users of the behavior > when interoperating w/ APIs that return \r\n in strings. > We always do replace('\r\n','\n') but same difference... Michael > > -Original Message- > From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 26, 2007 3:01 PM > To: Dino Viehland > Cc: [email protected] > Subject: Re: [Python-Dev] New lines, carriage returns, and Windows > > >> This works great as long as you stay within an entirely Python world. >> Because Python uses \n for everything internally >> > > I think you misunderstand fairly significantly how this all works > together. Python does not use \n "for everything internally". Python > is well capable of representing \r separately, and does so if you > ask it to. > > >> So I'm curious: Is there a reason this behavior is useful that I'm >> missing? >> > > I think you are missing how it works in the first place (or else > you failed to communicate to me what precise behavior you find > puzzling). > > Regards, > Martin > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ 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] Re: New lines, carriage returns, and Windows
Dino Viehland wrote: > And if this is fine for you, given that you may have the largest WinForms / > IronPython code base, I tend to think the replace may be reasonable. But we > have had someone get surprised by this behavior. > It is a slight impedance mismatch between Python and Windows - but isn't restricted to IronPython, so changing Python semantics doesn't seem like the right answer. Alternatively a more intelligent text mode (that writes '\n' as '\r\n' and '\r\n' as '\r\n' on Windows) doesn't sound like *such* a bad idea - but you will still get caught out by this. A string read in text mode will read '\r\n' as '\n'. Setting this on a winforms component will still do the wrong thing. Better to be aware of the difference and use binary mode. Michael > -Original Message- > From: Michael Foord [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 26, 2007 3:15 PM > To: Dino Viehland > Cc: [email protected] > Subject: Re: [python] Re: [Python-Dev] New lines, carriage returns, and > Windows > > Dino Viehland wrote: > >> My understanding is that users can write code that uses only \n and Python >> will write the end-of-line character(s) that are appropriate for the >> platform when writing to a file. That's what I meant by uses \n for >> everything internally. >> >> But if you write \r\n to a file Python completely ignores the presence of >> the \r and transforms the \n into a \r\n anyway, hence the \r\r in the >> resulting stream. My last question is simply does anyone find writing >> \r\r\n when the original string contained \r\n a useful behavior - >> personally I don't see how it is. >> >> But Guido's response makes this sound like it's a problem w/ VC++ stdio >> implementation and not something that Python is explicitly doing. Anyway, >> it'd might be useful to have a text-mode file that you can write \r\n to and >> only get \r\n in the resulting file. But if the general sentiment is >> s.replace('\r', '') is the way to go we can advice our users of the behavior >> when interoperating w/ APIs that return \r\n in strings. >> >> > > We always do replace('\r\n','\n') but same difference... > > Michael > > >> -Original Message- >> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 26, 2007 3:01 PM >> To: Dino Viehland >> Cc: [email protected] >> Subject: Re: [Python-Dev] New lines, carriage returns, and Windows >> >> >> >>> This works great as long as you stay within an entirely Python world. >>> Because Python uses \n for everything internally >>> >>> >> I think you misunderstand fairly significantly how this all works >> together. Python does not use \n "for everything internally". Python >> is well capable of representing \r separately, and does so if you >> ask it to. >> >> >> >>> So I'm curious: Is there a reason this behavior is useful that I'm >>> missing? >>> >>> >> I think you are missing how it works in the first place (or else >> you failed to communicate to me what precise behavior you find >> puzzling). >> >> Regards, >> Martin >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> >> >> > > > ___ 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] urllib exception compatibility
urllib goes to goes to some trouble to ensure that it raises IOError,
even when the underlying exception comes from another module.[*] I'm
wondering if it would make sense to just have those modules'
exceptions inherit from IOError.
In particular, should socket.error, ftp.Error and
httplib.HTTPException (used in Py3K) inherit from IOError?
I'm also wondering whether it would be acceptable to change the
details of the exceptions. For example, could
raise IOError, ('ftp error', msg), sys.exc_info()[2]
be reworded, or is there there too much risk that someone is checking
for an "errno" of 'ftp error'?
[*] This isn't a heavily tested path; some actually fail with a
TypeError since 2.5, because IOError no longer accepts argument tuples
longer than 3. http://bugs.python.org/issue1209 Fortunately, this
makes me less worried about changing the contents of the specific
attributes to something more useful...
-jJ
___
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] Iterating over objects of unknown length
Oleg Broytmann wrote: > Hello! > >(This seems like a "developing with Python" question and partially it is > but please read on.) > >I have a class that represents SQL queries. Instances of the class can > be iterated over. ... users of > the class sometimes write > > if sqlQuery: >for row in sqlQuery: ... > else: ># no rows > > To prevent users from writing such code the class implements __nonzero__() > that always raises an exception. I'm not sure I like that idea. It's common practice to write 'if x:' as a shorthand for 'if x is not None:' when it's known that x is an object that doesn't have a notion of emptiness. A __nonzero__ that always raises an exception just to spite you interferes with that. Another thing is that any code doing "if x" to test for emptiness is clearly expecting x to be a sequence, *not* an iterator, and you've violated the contract by passing it one. This is what you may be running into with the libraries you mention. Generally I think it's a bad idea to try to protect people from themselves when doing so can interfere with legitimate usage. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] urllib exception compatibility
Shouldn't these all inherit from EnvironmentError?
Or should EnvironmentError and IOError be the same thing perhaps?
--Guido
On 9/26/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> urllib goes to goes to some trouble to ensure that it raises IOError,
> even when the underlying exception comes from another module.[*] I'm
> wondering if it would make sense to just have those modules'
> exceptions inherit from IOError.
>
> In particular, should socket.error, ftp.Error and
> httplib.HTTPException (used in Py3K) inherit from IOError?
>
> I'm also wondering whether it would be acceptable to change the
> details of the exceptions. For example, could
>
> raise IOError, ('ftp error', msg), sys.exc_info()[2]
>
> be reworded, or is there there too much risk that someone is checking
> for an "errno" of 'ftp error'?
>
>
> [*] This isn't a heavily tested path; some actually fail with a
> TypeError since 2.5, because IOError no longer accepts argument tuples
> longer than 3. http://bugs.python.org/issue1209 Fortunately, this
> makes me less worried about changing the contents of the specific
> attributes to something more useful...
>
> -jJ
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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] Iterating over objects of unknown length
On Thu, Sep 27, 2007 at 01:33:47PM +1200, Greg Ewing wrote: > Oleg Broytmann wrote: > >if sqlQuery: > > for row in sqlQuery: ... > >else: > > # no rows > > > >To prevent users from writing such code the class implements __nonzero__() > >that always raises an exception. > > I'm not sure I like that idea. It's common practice to write > 'if x:' as a shorthand for 'if x is not None:' when it's known > that x is an object that doesn't have a notion of emptiness. > Another thing is that any code doing "if x" to test for > emptiness is clearly expecting x to be a sequence, *not* > an iterator, and you've violated the contract by passing > it one. This is what you may be running into with the libraries > you mention. In most cases the code in those libraries is, using the word of Mr. van Rossum, "archaic". It was developed for old versions of Python (long before Python has got the iterator protocol). I will file bug reports and patches (I have filed one about logginig/__init__.py) to allow developers to either fix the code or document the fact the code really requires a finite sequence. Unfortunately now when my code no longer raises an exception it would be harder to spot the buggy libraries. > Generally I think it's a bad idea to try to protect people > from themselves when doing so can interfere with legitimate > usage. I agree. I admitted in mailing list it was my design mistake. The offending __nonzero__ was removed from SVN today. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] New lines, carriage returns, and Windows
Dino Viehland wrote: > When writing a string in text mode that contains \r\n we both write \r\r\n Maybe there should be a universal newlines mode defined for output as well as input, which translates any of "\r", "\n" or "\r\n" into the platform line ending. Although I suspect that a string containing "\r\n" is going to cause more problems for Python applications than this. E.g. consider what happens when you try to split a string on newlines. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] New lines, carriage returns, and Windows
Greg> Maybe there should be a universal newlines mode defined for output
Greg> as well as input, which translates any of "\r", "\n" or "\r\n"
Greg> into the platform line ending.
I thought that's the way it was supposed to work, but it clearly doesn't:
>>> f = open("test.txt", "wt")
>>> f.write("a\rb\rnc\n")
7
>>> f.close()
>>> open("test.txt", "rb").read()
b'a\rb\rnc\n'
I'd be open to such a change. Principle of least surprise?
Skip
___
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] urllib exception compatibility
Jim Jewett wrote: > In particular, should socket.error, ftp.Error and > httplib.HTTPException (used in Py3K) inherit from IOError? I'd say that if they incorporate a C library result code they should inherit from IOError, or if they incorporate a system call result code they should inherit from OSError. Otherwise they should inherit from EnvironmentError. I don't think there's any point in simply catching one of these and re-wrapping it in the library's own exeption class, but if such wrapping is done, it should inherit from EnvironmentError as well. It's convenient to be able to catch EnvironmentError and get anything that is caused by circumstances outside the program's control. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] New lines, carriage returns, and Windows
> My understanding is that users can write code that uses only \n and > Python will write the end-of-line character(s) that are appropriate > for the platform when writing to a file. That's what I meant by uses > \n for everything internally. Here you misunderstand - that's only the case when the file is opened in text mode. If the file is opened in binary mode, and you write \n, then it writes just a single byte (0xA). > But if you write \r\n to a file Python completely ignores the > presence of the \r and transforms the \n into a \r\n anyway, hence > the \r\r in the resulting stream. My last question is simply does > anyone find writing \r\r\n when the original string contained \r\n a > useful behavior - personally I don't see how it is. That's just for consistency. > But Guido's response makes this sound like it's a problem w/ VC++ > stdio implementation and not something that Python is explicitly > doing. That's correct - it's the notion of "text mode" for file IO. > Anyway, it'd might be useful to have a text-mode file that > you can write \r\n to and only get \r\n in the resulting file. This I don't understand. Why don't you just use binary mode then? At least for Python 2.x, the *only* difference between text and binary mode is the treatment of line endings. For Python 3, things will be different as the distinction goes further; the precise API for line endings is still being considered there. Regards, Martin ___ 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
