Mark Hammond wrote:
Please add my -1 to the chorus here, for the same reasons already expressed.
Another -1 here - while I agree there are benefits to removing backslash
continuations and string literal concatenation, I don't think they're
significant enough to justify the hassle of making it
Surely
from textwrap import dedent as d
is close enough?
Nick Apart from it happening at run time rather than compile time.
And as someone else pointed out, what if you don't want each chunk of text
terminated by a newline?
Skip
Michael Foord wrote:
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
[EMAIL PROTECTED] wrote:
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' %
Steven Bethard a écrit :
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 5/4/07, Baptiste Carvello [EMAIL PROTECTED] wrote:
maybe we could have a dedent literal that would remove the first newline and
all indentation so that you can just write:
call_something( d'''
first part
second line
third line
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 with
[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 an
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning single-quoted string
In the first
Benji York wrote:
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning single-quoted
Ron Adam schrieb:
Benji York wrote:
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning
On 5/3/07, Georg Brandl [EMAIL PROTECTED] wrote:
These are raw strings if you didn't notice.
It's all in the implementation. The tokenizer takes it as an escape sequence
-- it doesn't specialcase raw strings -- the AST builder (parsestr() in ast.c)
doesn't.
FWIW, it wasn't designed this way
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
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
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
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 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))
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
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: Simplified Parsing
PEP: 30xz
Title: Simplified Parsing
Version: $Revision$
Last-Modified: $Date
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 its parsing from C. While
27 matches
Mail list logo
