Joe Smith wrote:
> LISP was a disaster to use, so I doubt your language would have been any
> worse.
At least Lisp would let you say
(* 4 a c)
and not force you to write
(* (* 4 a) c)
My language would not have been so forgiving,
unless you were willing to define a bunch of
different *
On 3/11/06, Joe Smith <[EMAIL PROTECTED]> wrote:
> Well the original was almost certainly a tongue-in-cheek reference to LISP.
> LISP was a disaster to use, so I doubt your language would have been any
> worse.
> The way one identifies a lisp programmer is to find the person whose paren
> keys have
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jeremy Hylton wrote:
>> Perhaps the solution
>> is to require parens around all expressions, a simple consistent rule.
>
> I actually designed a language with that feature once.
> It was an exercise in minimality, with har
With parentheses, we can use "if cond then val1 else val2" form
without the burden of hacking the parser, although the cost of the
keyword "then" is still there.
so, some possible forms that prompts in my mind are
level = (if "absolute_import" in self.future then 0 else -1)
level = (if "ab
Morel Xavier wrote:
> Steve Holden wrote:
>
>>Contrast with the bleeding obvious:
>>
>> level = 0
>> if "absolute_import" in self.futures:
>> level = -1
>>
>>regards
>> Steve
>
> >
> The issue that spawned the necessity of a ternary operator in the first
> place was that this s
Steve Holden wrote:
> Contrast with the bleeding obvious:
>
> level = 0
> if "absolute_import" in self.futures:
> level = -1
>
> regards
> Steve
>
The issue that spawned the necessity of a ternary operator in the first
place was that this syntax is not usable at all in quit
Greg Ewing wrote:
> Jeremy Hylton wrote:
> > Perhaps the solution
> > is to require parens around all expressions, a simple
> consistent rule.
>
> I actually designed a language with that feature once.
> It was an exercise in minimality, with hardly anything
> built-in -- all the arithmetic opera
Paul Moore wrote:
> +0 for mentioning parens around conditional expressions in PEP 8. But
> it's aready covered by the general "code should be readable" in my
> view.
Indeed. Writing readable code is ultimately the
responsibility of the person doing the writing.
It's enough that you *can* put par
Jeremy Hylton wrote:
> Perhaps the solution
> is to require parens around all expressions, a simple consistent rule.
I actually designed a language with that feature once.
It was an exercise in minimality, with hardly anything
built-in -- all the arithmetic operators, etc. were
defined in the lang
On Mar 7, 2006, at 7:29 AM, Steve Holden wrote:
...
>> In fact, I think the below examples are reasonable uses
>> that do a better job of expressing intent than the if
>> statement would. I just don't like the mental backtrack
>> they require, and would like some sort of advance
>> warning.
Jim Jewett wrote:
> On 3/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>
>
>>The parentheses around genexps were (AFAICT)
>>different - without them, the grammar was ambiguous,
>>so some way of disambiguating was needed.
>
>
> The out-of-order evaluation is a very large change,
> because now we h
On 3/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> The parentheses around genexps were (AFAICT)
> different - without them, the grammar was ambiguous,
> so some way of disambiguating was needed.
The out-of-order evaluation is a very large change,
because now we have a situation where normal
parsi
Paul Moore wrote:
> On 3/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>> On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
>>> ...
I think that adding parentheses would help, by at least signalling
that the logic is longer than jus
On 3/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> >
> > On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> > ...
> > > I think that adding parentheses would help, by at least signalling
> > > that the logic is longer than just the next (sin
On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> ...
> > I think that adding parentheses would help, by at least signalling
> > that the logic is longer than just the next (single) expression.
> >
> > level = (0 if "absolute_import" in
Joe Smith wrote:
> "Steve Holden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Jim Jewett wrote:
>>
>>>I think that adding parentheses would help, by at least signalling that
>>>the logic is longer than just the next (single) expression.
>>>
>>>level = (0 if "absolute_imp
Alex Martelli wrote:
> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> ...
> > I think that adding parentheses would help, by at least signalling
> > that the logic is longer than just the next (single) expression.
> >
> > level = (0 if "absolute_import" in self.futures else -1)
>
> +1 (ju
[Jim Jewett]
>>> I think that adding parentheses would help, by at least signalling that
>>> the logic is longer than just the next (single) expression.
>>>
>>> level = (0 if "absolute_import" in self.futures else -1)
[Steve Holden]
>> Contrast with the bleeding obvious:
>>
>> level = 0
>>
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jim Jewett wrote:
>> I think that adding parentheses would help, by at least signalling that
>> the logic is longer than just the next (single) expression.
>>
>> level = (0 if "absolute_import" in self.futures else -
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
...
> I think that adding parentheses would help, by at least signalling
> that the logic is longer than just the next (single) expression.
>
> level = (0 if "absolute_import" in self.futures else -1)
+1 (just because I can't give it +3.1415
Morel Xavier wrote:
> Steve Holden wrote:
>
>> Contrast with the bleeding obvious:
>>
>> level = 0
>> if "absolute_import" in self.futures:
>> level = -1
>>
>> regards
>> Steve
>
> >
> The issue that spawned the necessity of a ternary operator in the first
> place was that
Jim Jewett wrote:
> Now that we have started to see conditional expressions ... I would
> like to see them parenthesized. The parens aren't as important as they
> are with generator expressions, but ... they matter.
>
> From a recent checkin --
>
> level = 0 if "absolute_import" in self
On 3/6/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > level = 0 if "absolute_import" in self.futures else -1
> > Mentally, I can't help parsing that as "level = 0" plus
> > comments that turn out to be code that triggers
> > backtracking.
On 3/6/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
From a recent checkin --
level = 0 if "absolute_import" in self.futures else -1Mentally, I can't help parsing that as "level = 0" plus comments that turn out to be code that triggers backracking.When the expressions (particularly the true case) a
Now that we have started to see conditional expressions ... I would like to see them parenthesized. The parens aren't as important as they are with generator expressions, but ... they matter.From a recent checkin --
level = 0 if "absolute_import" in self.futures else -1Mentally, I can't hel
25 matches
Mail list logo
