[EMAIL PROTECTED] wrote:
> when I hit LF in an open
> multiline string a newline is inserted and the cursor is lined up under the
> "r" of "rows", not under the opening quote of the multiline string, and not
> where you chose to indent your example.
Seems to me that Python actually benefits from a
>Raymond> I find that style hard to maintain. What is the advantage over
>Raymond> multi-line strings?
>
>Raymond> rows = self.executesql('''
>Raymond> select cities.city, state, country
>Raymond> from cities, venues, events, addresses
>Raymond> where cities.
Georg Brandl wrote:
> 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
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end
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
>
>> -Or
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"
>>
[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"
>
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; that
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] PE
> 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 (becau
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))
-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
>>
-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 "
>>
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
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 i
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_
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
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
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
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"
>>
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 i
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 straight
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 ini
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
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/
> -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 cha
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 calli
26 matches
Mail list logo
