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
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
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_
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
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
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
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
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
> 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
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
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
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
> 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
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
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
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
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:
> 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 -
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
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
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
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
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
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
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
> 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
26 matches
Mail list logo
