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 was
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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)
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
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
24 matches
Mail list logo
