Jason Orendorff wrote:
> Hmm. It sounds like what you're saying is, if we're going to do
> string constant folding, then it makes sense to have a special case in
> the grammar to reflect that visually.
I think it's more a matter of wanting to write things
declaratively rather than procedurally.
Phillip J. Eby wrote:
>>> * Eliminate implicit string concatenation: "abc" "def"
>> Sure, I use it, but if it went away, I would type the plus sign. Not
>> a problem. And it would be one less thing for newcomers to learn, and
>> explicit is better, right?
> But there's another Python principle
On 4/11/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Talin schrieb:
> > I'm not sure that I am the first to bring this up, but I might as well
> > get it written down.
> >
> > I've never liked using the backslash operator for line continuation, for
> > two reasons:
> >
> > 1) It requires that it b
On 4/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> But there's another Python principle here, I think... complexity of
> computation should be represented by complexity of syntax. We don't
> generally like to use properties for expensive computation, or methods for
> simple field access, for
At 01:03 PM 4/11/2007 -0400, Jason Orendorff wrote:
>On 4/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > * Eliminate implicit string concatenation: "abc" "def"
> > in favor of an explicit + operation. That simplifies
> > the grammar just a bit and the compiler already is
> > smart enoug
On 4/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> * Eliminate implicit string concatenation: "abc" "def"
> in favor of an explicit + operation. That simplifies
> the grammar just a bit and the compiler already is
> smart enough to do constant fold this operation at
> compile time. [...]
On 10/04/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[snip]
Here's that I think might not need a PEP:
* Eliminate implicit string concatenation: "abc" "def"
in favor of an explicit + operation. That simplifies
the grammar just a bit and the compiler already is
smart enough to do consta
Talin schrieb:
> I'm not sure that I am the first to bring this up, but I might as well
> get it written down.
>
> I've never liked using the backslash operator for line continuation, for
> two reasons:
>
> 1) It requires that it be the last character of a line, meaning that you
> have to insu
At 09:50 PM 4/10/2007 -0700, Guido van Rossum wrote:
>I'm kind of worried about the performance though -- won't you have to
>pay at least for the lookup of __and1__ or __or1__ in the MRO of the
>first argument?
Not if they're tp_* slots. And we could introduce the feature only for
new-style clas
On Wednesday 11 April 2007 11:01, Talin wrote:
> Parsing-wise, an ellipsis operator would have the following meaning:
> Inside a parenthesized or bracketed expression, it would have the same
> meaning it does now. Otherwise, it has the meaning "consume all
> whitespace, including newlines".
Re
I'm not sure that I am the first to bring this up, but I might as well
get it written down.
I've never liked using the backslash operator for line continuation, for
two reasons:
1) It requires that it be the last character of a line, meaning that you
have to insure that there's no trailing whi
On 4/11/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Would it make sense to make the state of the decoder public, e.g. by
> adding setstate() and getstate() methods? This would give a cleaner API.
I've been thinking of the same thing!
I wonder if it would be possible to return the state as a p
guido.van.rossum wrote:
> Author: guido.van.rossum
> Date: Wed Apr 11 03:09:03 2007
> New Revision: 54742
>
> Modified:
>python/branches/p3yk/Lib/io.py
>python/branches/p3yk/Lib/test/test_io.py
> Log:
> Checkpoint so I can continue to work on this at a different box.
> There is somewhat w
13 matches
Mail list logo
