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
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 of
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, since
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
the
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 especially important
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. fdrake at acm.org
___
Python-Dev mailing list
[-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 (which has
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 incredibly
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
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, regardless of if
[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' %
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.
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
14 matches
Mail list logo
