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
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"
>>
Major rewrite.
The inside-a-string continuation is separated from the general continuation.
The alternatives section is expaned to als list Andrew Koenig's
improved inside-expressions variant, since that is a real contender.
If anyone feels I haven't acknowledged their concerns, please tell me.
[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>
Tim Delaney wrote:
> From: "Calvin Spealman" <[EMAIL PROTECTED]>
>
>> I believe the direction my PEP took with all this is a good bit
>> primitive compared to this approach, although I still find value in it
>> because at least a prototype came out of it that can be used to test
>> the waters, reg
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
Tristan Seligmann wrote:
> * Guido van Rossum <[EMAIL PROTECTED]> [2007-04-29 18:19:20 -0700]:
>
>>> In my mind, 'if' and 'or' are "syntax", whereas things like 'None' or
>>> 'True' are "values"; even if None becomes an actual keyword, rather than
>>> a builtin.
>> I'm sorry, but that is such an i
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 04 May 2007, M.-A. Lemburg wrote:
> > I also suggest making all bytes literals immutable to avoid running
> > into any issues like the above.
>
> +1 from me.
Rather than adding immutability to bytes objects (whic
On Friday 04 May 2007, M.-A. Lemburg wrote:
> I also suggest making all bytes literals immutable to avoid running
> into any issues like the above.
+1 from me.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http:
On 2007-05-04 18:53, Georg Brandl wrote:
> M.-A. Lemburg schrieb:
>> Hi Walter,
>>
>> if the bytes type does turn out to be a mutable type as suggested
>> in PEP 358, then please make sure that no code (C code in
>> particular), relies on the constantness of these byte objects.
>>
>> This is especi
M.-A. Lemburg schrieb:
> Hi Walter,
>
> if the bytes type does turn out to be a mutable type as suggested
> in PEP 358, then please make sure that no code (C code in
> particular), relies on the constantness of these byte objects.
>
> This is especially important when it comes to codecs, since
>
M.-A. Lemburg wrote:
> Hi Walter,
>
> if the bytes type does turn out to be a mutable type as suggested
> in PEP 358,
it is.
> then please make sure that no code (C code in
> particular), relies on the constantness of these byte objects.
>
> This is especially important when it comes to codecs
On 2007-05-01 02:29, Phillip J. Eby wrote:
> I wanted to get this in before the Py3K PEP deadline, since this is a
> Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
Could you add a section that explains the side effects of
importing pkg_resources ?
The documentation o
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important when it comes to codecs, since
the error callback logic would allow th
14 matches
Mail list logo
