> 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
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 OS
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", "w
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 conta
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
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 a
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:
>f
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.HTTPEx
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 -
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, Sept
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
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 th
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
> 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 separ
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 wit
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
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
> 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
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
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
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 t
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 i
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 i
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_
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 wa
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
26 matches
Mail list logo