Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89912 > unrolled thread

Bitten by my C/Java experience

Back to article view | Back to comp.lang.python

Contents

  Bitten by my C/Java experience Cecil Westerhof <Cecil@decebal.nl> - 2015-05-04 17:20 +0200
    Re: Bitten by my C/Java experience Tobiah <toby@tobiah.org> - 2015-05-04 10:18 -0700
    Re: Bitten by my C/Java experience Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2015-05-04 19:32 +0200
      Re: Bitten by my C/Java experience Chris Angelico <rosuav@gmail.com> - 2015-05-05 03:40 +1000
        Re: Bitten by my C/Java experience albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-08 10:47 +0000
          Re: Bitten by my C/Java experience Chris Angelico <rosuav@gmail.com> - 2015-05-08 21:32 +1000
    Re: Bitten by my C/Java experience Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-04 11:43 -0600
      Re: Bitten by my C/Java experience Andrew Cooper <amc96@cam.ac.uk> - 2015-05-04 21:57 +0100
        Re: Bitten by my C/Java experience random832@fastmail.us - 2015-05-04 17:16 -0400
        Re: Bitten by my C/Java experience Tim Chase <python.list@tim.thechases.com> - 2015-05-04 16:26 -0500
    Re: Bitten by my C/Java experience Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-04 18:59 +0100
    Re: Bitten by my C/Java experience Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-04 13:39 -0600
      Re: Bitten by my C/Java experience Cecil Westerhof <Cecil@decebal.nl> - 2015-05-04 22:28 +0200
        Re: Bitten by my C/Java experience Dave Angel <davea@davea.name> - 2015-05-04 19:17 -0400
    Re: Bitten by my C/Java experience Terry Reedy <tjreedy@udel.edu> - 2015-05-04 16:06 -0400
    Re: Bitten by my C/Java experience BartC <bc@freeuk.com> - 2015-05-04 23:02 +0100
      Re: Bitten by my C/Java experience Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-05 18:19 +1000
        Re: Bitten by my C/Java experience BartC <bc@freeuk.com> - 2015-05-05 14:20 +0100
          Re: Bitten by my C/Java experience Rustom Mody <rustompmody@gmail.com> - 2015-05-05 09:24 -0700
            Re: Bitten by my C/Java experience Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-06 14:38 +0200
              Re: Bitten by my C/Java experience Rustom Mody <rustompmody@gmail.com> - 2015-05-06 06:03 -0700
          Re: Bitten by my C/Java experience Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-06 23:19 +1200
            Re: Bitten by my C/Java experience BartC <bc@freeuk.com> - 2015-05-06 13:40 +0100
              Re: Bitten by my C/Java experience Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-07 02:03 +1000
                Re: Bitten by my C/Java experience Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-06 21:13 +0100
        Re: Bitten by my C/Java experience Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-06 23:15 +1200
      Re: Bitten by my C/Java experience random832@fastmail.us - 2015-05-06 09:11 -0400
      Re: Bitten by my C/Java experience Chris Angelico <rosuav@gmail.com> - 2015-05-06 23:16 +1000

Page 2 of 2 — ← Prev page 1 [2]

#90051

On Wednesday, May 6, 2015 at 6:09:08 PM UTC+5:30, Antoon Pardon wrote:
> Op 05-05-15 om 18:24 schreef Rustom Mody:
> 
> > Yeah I happen to me in that minuscule minority that regards '= denotes 
> > assignment' a bigger mistake than ++
> 
> Nice to know I'm not alone. I Especially think it is a mistake, because
> it is then used as a reason for not allowing something like
> 
>   if a = b - 1:
> 
> arguing it would lead to some difficult bugs.
> 
> Which in my mind is arguing backwards. Either you think an assigment
> in a condition is useful or harmful. In the first case you then look
> for an assignment token or assignment syntax that is not that likely
> to lead to difficult to discover bugs instead of letting a possible
> misleading token or syntax prevent you from implementing something
> useful.
> 
> In the second case you just state why you think an assignment in a
> condition is harmful. No need to hide behind awkward syntax.

Nice to know we agree though I am not sure I agree with your agreement :-)

In APL assignment is ← goto is → [and of course equality and negated equality
are = and ≠ ]
But if you've seen hair-raising APL one-liners with multiple ← and even → stuffed in...

No on second thoughts we probably agree... I am just in the second camp:
assignment in conditions is trouble; no need for syntax to argue that

[toc] | [prev] | [next] | [standalone]

#90046

BartC wrote:

> So why pretend that ++ and -- don't exist?

Probably because Python would gain very little from
having them.

Main uses of ++ in C are things like integer for
loops:

    for (i = 0; i < 10; i++) {...

and stepping through arrays:

    a[i++] = b[j++];

Python code usually operates at a higher level than
that.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#90050

On 06/05/2015 12:19, Gregory Ewing wrote:
> BartC wrote:
>
>> So why pretend that ++ and -- don't exist?
>
> Probably because Python would gain very little from
> having them.
>
> Main uses of ++ in C are things like integer for
> loops:
>
>     for (i = 0; i < 10; i++) {...
>
> and stepping through arrays:
>
>     a[i++] = b[j++];
>
> Python code usually operates at a higher level than
> that.

I think even in Python it is sometimes necessary to increment things (as 
the OP did).

But I had in mind not implementing ++ and --, but detecting them and 
issuing a warning, so forcing someone to type "+ +" or to use 
parentheses, which is unlikely to be much of an imposition as how often 
are two unary pluses going to be used together?


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90062

On Wed, 6 May 2015 10:40 pm, BartC wrote:

> But I had in mind not implementing ++ and --, but detecting them and
> issuing a warning, 

That's a job for a linter, not the compiler. The compiler should be as
flexible as possible in what it accepts:


a   ,    b=12+3     *          4,"hello"          .      upper   ()


is perfectly legal code. The compiler shouldn't force you to write good
looking code, apart from what is prohibited altogether.

Both + and - are unary prefix operators, so you can apply + and - to any
expression -- even an expression that already has a unary prefix operator:

py> -     --- +++ + - - + -- +++ --- 999
-999


Is that ugly, horrible code that nobody in their right mind would use in
production? Absolutely. But the compiler can and should accept it, and
linters (or human reviewers) should warn about it.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90070

On 06/05/2015 17:03, Steven D'Aprano wrote:
> On Wed, 6 May 2015 10:40 pm, BartC wrote:
>
>> But I had in mind not implementing ++ and --, but detecting them and
>> issuing a warning,
>
> That's a job for a linter, not the compiler. The compiler should be as
> flexible as possible in what it accepts:
>
>
> a   ,    b=12+3     *          4,"hello"          .      upper   ()
>
>
> is perfectly legal code. The compiler shouldn't force you to write good
> looking code, apart from what is prohibited altogether.
>
> Both + and - are unary prefix operators, so you can apply + and - to any
> expression -- even an expression that already has a unary prefix operator:
>
> py> -     --- +++ + - - + -- +++ --- 999
> -999
>
>
> Is that ugly, horrible code that nobody in their right mind would use in
> production? Absolutely. But the compiler can and should accept it, and
> linters (or human reviewers) should warn about it.
>

Linters were mentioned a day or two back.  Take a horse to water...

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#90045

Steven D'Aprano wrote:

> The first one just does a name lookup and then throws the result away. The 
> second one looks up names a and b, then adds them together, throwing away 
> the result.

Actually, it's worse than that. :-) It's possible for a to
have an __add__ method with a side effect, although that
would be evil.

It's also possible for merely looking up a name to have
a side effect, if it's done in the right context -- but
that would be even more evil.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#90053

On Mon, May 4, 2015, at 18:02, BartC wrote:
> (I think I would have picked up "++" and "--" as special tokens even if 
> increment/decrement ops weren't supported. Just because they would 
> likely cause errors through misunderstanding.)

There's precedent for not doing this in C itself - even though "=+"
(from very early versions of C, also =-, =*, =&) no longer acts as an
add-in-place operator, it's not recognized as a special token to prevent
errors either.

[toc] | [prev] | [next] | [standalone]

#90055

On Wed, May 6, 2015 at 11:11 PM,  <random832@fastmail.us> wrote:
> On Mon, May 4, 2015, at 18:02, BartC wrote:
>> (I think I would have picked up "++" and "--" as special tokens even if
>> increment/decrement ops weren't supported. Just because they would
>> likely cause errors through misunderstanding.)
>
> There's precedent for not doing this in C itself - even though "=+"
> (from very early versions of C, also =-, =*, =&) no longer acts as an
> add-in-place operator, it's not recognized as a special token to prevent
> errors either.

Given that the in-place operators changed to +=, -=, etc very early
on, I doubt there's anyone who is actually confused by them. And it'd
be extremely annoying to have to stop and think about parsing rules
when taking or dereferencing pointers:

/* This works */
x = &y;

/* Why shouldn't this? */
x=&y;

To the greatest extent possible, spaces around assignment operators
should be the domain of style guides, not syntax.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web