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 t
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 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
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 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
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
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
>>
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))
gt; Subject: [Python-Dev] PEP 30XZ: Simplified Parsing
>
>
> 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
>
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
[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"
>>
; 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: S
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
[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
Ron Adam wrote:
> The following inconsistency still bothers me, but I suppose it's an edge
> case that doesn't cause problems.
>
> >>> print r"hello world\"
>File "", line 1
> print r"hello world\"
> ^
> SyntaxError: EOL while scanning single-quoted string
> In
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 r"hello world\"
>>File "", line 1
>> print r"hello world\"
>> ^
>> SyntaxError: EOL while scanning
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 r"hello world\"
>>>File "", line 1
>>> print r"hello world\"
>>> ^
>>> Sy
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 t
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
[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>
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"
>>
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
Mike Klaas <[EMAIL PROTECTED]> wrote:
> 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
>
>> 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
_
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
28 matches
Mail list logo
