autoincrementing 
Author Message
 autoincrementing

Hello,

I've read somehwere the that newer versions of
python support autoincrementing. I've just upgraded
from 1.5.2 to 2.2.2, and

i=1
i++

still gives me a syntax error. I can do

i+=1

however. Why doesn't i++ work?

Thanks,
Hilbert



Sat, 13 Aug 2005 16:41:23 GMT  
 autoincrementing

Quote:

> I've read somehwere the that newer versions of
> python support autoincrementing. I've just upgraded
> from 1.5.2 to 2.2.2, and

> i=1
> i++

> still gives me a syntax error. I can do

> i+=1

> however. Why doesn't i++ work?



operator (and MOST other sequences of special symbols
and punctuation are also not operators, thanks be).

Writing one more character to code +=1 instead of ++
is no great hardship, and it would be absurd for
Python to introduce a special operator just for the
purpose of saving that one character.

Alex



Sat, 13 Aug 2005 17:00:34 GMT  
 autoincrementing

Quote:

> I've read somehwere the that newer versions of
> python support autoincrementing.

That information is incorrect.  Python does not have ++ or -- operators.

It _does_ have the augmented assignment operators, such as +=, -=, etc.,
support in Python 2.0 and above.

--

 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ We'll have to make our own luck from now on.
\__/ Louis Wu
    The laws list / http://www.alcyone.com/max/physics/laws/
 Laws, rules, principles, effects, paradoxes, etc. in physics.



Sat, 13 Aug 2005 17:14:56 GMT  
 autoincrementing

Quote:



>operator (and MOST other sequences of special symbols
>and punctuation are also not operators, thanks be).

>Writing one more character to code +=1 instead of ++
>is no great hardship, and it would be absurd for
>Python to introduce a special operator just for the
>purpose of saving that one character.

>Alex

That is not the point of auto-increment (and I'm sure you must know
this)

   intPrev = intNew++

is equivalent to:

   intPrev = intNew
   intNew += 1

Rather more than one character saved. And there are times when it can
save you a lot more than that, too.
--
Dale Strickland-Clark
Riverhall Systems Ltd



Sat, 13 Aug 2005 20:35:29 GMT  
 autoincrementing
   ...

Quote:
> That is not the point of auto-increment (and I'm sure you must know
> this)

>    intPrev = intNew++

> is equivalent to:

>    intPrev = intNew
>    intNew += 1

> Rather more than one character saved. And there are times when it can
> save you a lot more than that, too.

In Python, all binding and rebinding of names is in statements, never in
expressions; and numbers are immutable -- so if x refers for example to
the number 3, there is no way to make x refer to the number 4 except by
rebinding name x to a different object (you cannot ALTER a number).

I had not imagined the original poster was asking for Python to be
entirely and drastically revolutionized -- making numbers mutable, or
letting name binding or rebinding happen in expressions and not just
in statements -- in order to let him save A FEW characters' worth of
typing; I had rather made more charitable assumptions about what he
was asking about/for.

If the question being asked is "why are numbers immutable" or "why
does Python distinguish between expressions and statements and never
lets operators bind or rebind the names they're applied to", then
the only sensible answer is "because it's Python -- if you want C,
you know where to find it".

If the question is "why doesn't Python make an exception to its
otherwise simple and universal rules in order to treat an extremely
specific case 'ad hoc' in a way that would be convenient to me",
then my suggestion would be to switch to Perl: in that language you
will find an endless, dazzling variety of such "convenient" design
choices -- bon appetit!

Since I keep assuming human being are fundamentally good, even though
sometimes misguided, I still prefer to keep also assuming that the
poster, as indicated by using the non-C terminology "autoincrement"
rather than the C terminology "preincrement" or "postincrement", was
NOT wondering about inflicting such horrors upon Python, but simply
about a "++" synonym for the construct "+=1" -- a statement rebinding
a reference, but NOT returning a result.

Alex



Sat, 13 Aug 2005 21:09:14 GMT  
 autoincrementing
Dale Strickland-Clark wrote

Quote:




> >operator (and MOST other sequences of special symbols
> >and punctuation are also not operators, thanks be).

> >Writing one more character to code +=1 instead of ++
> >is no great hardship, and it would be absurd for
> >Python to introduce a special operator just for the
> >purpose of saving that one character.

> >Alex

> That is not the point of auto-increment (and I'm sure you must know
> this)

>    intPrev = intNew++

> is equivalent to:

>    intPrev = intNew
>    intNew += 1

> Rather more than one character saved. And there are times when it can
> save you a lot more than that, too.
> --
> Dale Strickland-Clark
> Riverhall Systems Ltd
> --

Surely, the main point is that

i += 1

is an assignment statement

and

i++

is an expression. Python makes a clear distinction between expressions and functions. Implementing i++ would give in-line assignment which the BDFL is apparently set against (so am I in the form if a = b..., but wouldn't mind if a := b...).

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.



Sat, 13 Aug 2005 21:00:03 GMT  
 autoincrementing

|In Python, all binding and rebinding of names is in statements, never in
|expressions; and numbers are immutable -- so if x refers for example to
|the number 3, there is no way to make x refer to the number 4 except by
|rebinding name x to a different object (you cannot ALTER a number).

Not ALL rebinding of names is in statements, e.g.

    >>> x = 3
    >>> somevar = globals().__setitem__('x',4)
    >>> x
    4

Of course, I don't recommend trying this sort of abomination at home.
:-)

Yours, Lulu...

--

gnosis  | powers of IP- and crypto-tyranny have entered into an unholy
.cx     | alliance...ideas have nothing to lose but their chains.  Unite
        | against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------



Sun, 14 Aug 2005 01:27:03 GMT  
 autoincrementing

Quote:

>In Python, all binding and rebinding of names is in statements, never in
>expressions; and numbers are immutable -- so if x refers for example to
>the number 3, there is no way to make x refer to the number 4 except by
>rebinding name x to a different object (you cannot ALTER a number).

>I had not imagined the original poster was asking for Python to be
>entirely and drastically revolutionized -- making numbers mutable, or
>letting name binding or rebinding happen in expressions and not just
>in statements -- in order to let him save A FEW characters' worth of
>typing; I had rather made more charitable assumptions about what he
>was asking about/for.

>If the question being asked is "why are numbers immutable" or "why
>does Python distinguish between expressions and statements and never
>lets operators bind or rebind the names they're applied to", then
>the only sensible answer is "because it's Python -- if you want C,
>you know where to find it".

>If the question is "why doesn't Python make an exception to its
>otherwise simple and universal rules in order to treat an extremely
>specific case 'ad hoc' in a way that would be convenient to me",
>then my suggestion would be to switch to Perl: in that language you
>will find an endless, dazzling variety of such "convenient" design
>choices -- bon appetit!

>Since I keep assuming human being are fundamentally good, even though
>sometimes misguided, I still prefer to keep also assuming that the
>poster, as indicated by using the non-C terminology "autoincrement"
>rather than the C terminology "preincrement" or "postincrement", was
>NOT wondering about inflicting such horrors upon Python, but simply
>about a "++" synonym for the construct "+=1" -- a statement rebinding
>a reference, but NOT returning a result.

  >phew!< You're hard going sometimes. :)
--
Dale Strickland-Clark
Riverhall Systems Ltd


Sun, 14 Aug 2005 02:46:31 GMT  
 autoincrementing

   ...

Quote:
> Not ALL rebinding of names is in statements, e.g.

>     >>> x = 3
>     >>> somevar = globals().__setitem__('x',4)
>     >>> x
>     4

Qualified names can of course be re-bound within an expression
(by setattr on the object containing the name, or sometimes by
more devious means).  And since simple global names map to
attributes of sys.modules[__name__], then rebinding such
attributes (by any of various expressions) does have the side
effect of rebinding "global" simple names [pop quiz: in what
case does the same apply to *local* simple names that are not
global names?].  So a more careful way of putting things may
be: no expression-level (non-statement) operation on a name
ever specifically causes that name to be re-bound (although it
MAY cause side effects that HAPPEN to rebind it: e.g, in your
example, start with x='x' and use x rather than 'x' as the
first argument to __setitem__).

Quote:
> Of course, I don't recommend trying this sort of abomination at home.

When you consider that any call to a function or method may
have almost arbitrary effects, depending only on how that method
or function is coded; and that the call itself is an expression
level (non-statement) operation; then there is no abomination
needed for weird re-bindings to occur.  One could say that this
is because the implementation of the function or method being
called does execute statements, but this need not be the case --
at least, not necessarily for _Python_ statements, as said
implementation might be in C or other language, and it might
call functions in the Python/C API.

Trying to find a way to express this that is safe from quibbles
of this nature is pretty hard.  The concept is that there is no
operator, such that applying that operator to _ANY_ name
causes that _ONE_ name to be re-bound -- to concoct rebindings
one goes through strings (such as 'x' above) -- but such
strings might be the values of the names (the x='x' quibble)
whence the need to specify that there is no _general_ case of
the kind, even though a special combination of a name and its
value may be envisaged that might, by happenstance, cause the
rebinding in question.

Consider an analogy: if I say

  "Paul" has four letters, but Paul does not have four letters

I _might_ be asserting a falsehood in a specific case, as there
MIGHT be an individual named Paul who DOES happen to have four
letters (having just received them in the mail, perhaps).  This
does not mean that the distinction between the individual Paul
and the name "Paul" is worthless -- it just forces one to
express such a distinction verbosely, painstakingly, and
boringly, rather than pithily, concisely and memorably, if and
when one moves in highly quibble-prone cicles...;-)

Alex



Sun, 14 Aug 2005 02:55:07 GMT  
 autoincrementing

Quote:

>   "Paul" has four letters, but Paul does not have four letters

> I _might_ be asserting a falsehood in a specific case, as there
> MIGHT be an individual named Paul who DOES happen to have four
> letters (having just received them in the mail, perhaps).

Then you would be equivocating, unless "Paul" also received four letters
in the mail.

--
I certainly seem to be enjoying myself in the same way, smacking my
lips, sighing and moaning, dripping [REDACTED] on my shirt and
smearing it into my moustache ... But ... If I snuck a{*filter*} of your
cone, I wouldn't smack my lips. -- Ted Cohen



Sun, 14 Aug 2005 05:24:52 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. getting autoincrementing key to update child field in code

2. ABC AutoIncrementing outside the templates

3. C4 - Autoincrementing default values for multi-valued template symbols

4. Autoincrementing a Decimal

5. Help with trouble autoincrementing non-ABC

6. How to define autoincrementing of a key with two fields?

 

 
Powered by phpBB® Forum Software