On 29/04/2007 17.04, Guido van Rossum wrote:
This is only a halfway fix to DRY, and it really only fixes the less
important half. The important problem with super is that it
encourages people to write incorrect code by requiring that you
explicitly specify an argument list. Since calling
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 01, 2007 20:46
But then you would substantially change the memory access behavior of
the
program in a debug build, that is, more than it is already changed by
the
fact that you have changed
Giovanni Bajo [EMAIL PROTECTED] wrote:
On 29/04/2007 17.04, Guido van Rossum wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
Really?
http://fuhm.net/super-harmful/
Hmmm.
On 02/05/2007 12.00, Christian Tanzer wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
Really?
http://fuhm.net/super-harmful/
Hmmm.
I've just counted more than 1600 usages of
Jim Jewett wrote:
PEP: 30xz
Title: Simplified Parsing
Version: $Revision$
Last-Modified: $Date$
Author: Jim J. Jewett [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 29-Apr-2007
Post-History: 29-Apr-2007
Abstract
Python initially inherited
There is a considerable amount of warnings present for 64 bit builds on windows.
You can see them using VisualStudio 2005 even if you don't have the x64
compilers installed, by turning on Detect 64 bit portability issues in the
general tab for pythoncore.
Now, some of those just need
On 5/2/07, Michael Foord [EMAIL PROTECTED] wrote:
Implicit string concatenation is massively useful for creating long
strings in a readable way though:
call_something(first part\n
second line\n
third line\n)
I find it an elegant
Steven Bethard wrote:
On 5/2/07, Michael Foord [EMAIL PROTECTED] wrote:
Implicit string concatenation is massively useful for creating long
strings in a readable way though:
call_something(first part\n
second line\n
third line\n)
On Wed, May 02, 2007 at 04:42:09PM +0100, Michael Foord wrote:
Implicit string concatenation is massively useful for creating long
strings in a readable way though:
This PEP doesn't seem very well-argued: It's a common mistake to
leave off a comma, and then scons complains that it can't find
Please stop arguing about an opinionated piece of anti-super PR.
On 5/2/07, Giovanni Bajo [EMAIL PROTECTED] wrote:
On 02/05/2007 12.00, Christian Tanzer wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g.
On Wed, May 02, 2007 at 01:53:01PM -0400, A.M. Kuchling wrote:
On Wed, May 02, 2007 at 04:42:09PM +0100, Michael Foord wrote:
Implicit string concatenation is massively useful for creating long
strings in a readable way though:
This PEP doesn't seem very well-argued: It's a common mistake
At 10:34 AM 5/2/2007 -0700, Trent Mick wrote:
But if you don't want the EOLs? Example from some code of mine:
raise MakeError(extracting '%s' in '%s' did not create the
directory that the Python build will expect:
'%s' % (src_pkg, dst_dir, dst))
On Wednesday 02 May 2007, Trent Mick wrote:
raise MakeError(extracting '%s' in '%s' did not create the
directory that the Python build will expect:
'%s' % (src_pkg, dst_dir, dst))
I use this kind of thing frequently. Don't know if others
On 4/30/07, Jim Jewett [EMAIL PROTECTED] wrote:
Python initially inherited its parsing from C. While this has
been generally useful, there are some remnants which have been
less useful for python, and should be eliminated.
+ Implicit String concatenation
+ Line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 2, 2007, at 2:51 PM, Phillip J. Eby wrote:
At 10:34 AM 5/2/2007 -0700, Trent Mick wrote:
But if you don't want the EOLs? Example from some code of mine:
raise MakeError(extracting '%s' in '%s' did not create the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 2, 2007, at 3:23 PM, Alexey Borzenkov wrote:
On 4/30/07, Jim Jewett [EMAIL PROTECTED] wrote:
Python initially inherited its parsing from C. While this has
been generally useful, there are some remnants which have been
less
Trent But if you don't want the EOLs? Example from some code of mine:
Trent raise MakeError(extracting '%s' in '%s' did not create the
Trent directory that the Python build will expect:
Trent '%s' % (src_pkg, dst_dir, dst))
Any thoughts?
These should be fixed on a case-by-case basis. Please submit patches
to SF, and assign them to me. Changes should only go into 2.6.
As a principle, values that could exceed 2Gi in a hand-crafted Python
program should be Py_ssize_t. Values that can never exceed the int
range
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
]On Behalf
Of Jim Jewett
Sent: Monday, 30 April 2007 1:29 PM
To: Python 3000; Python Dev
Subject: [Python-Dev] PEP 30XZ:
I fully support the removal of implicit string concatenation
(explicit is better than implicit; there's only one way to do it).
I also fully support the removal of backslashes for line continuation
of statements (same reasons). (I mean this as distinct from line
continuation within a string;
[Skip]
I use it all the time. For example, to build up (what I consider to be)
readable SQL queries:
rows = self.executesql(select cities.city, state, country
from cities, venues, events, addresses
where cities.city like %s
Raymond [Skip]
I use it all the time. For example, to build up (what I consider to be)
readable SQL queries:
rows = self.executesql(select cities.city, state, country
from cities, venues, events, addresses
FWIW, I'm -1 on both proposals too. I like implicit string literal concatenation
and I really can't see what we gain from backslash continuation removal.
Georg
Mark Hammond schrieb:
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
-Original
23 matches
Mail list logo
