| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 00:16:09 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,481 |
| Posted today: | 6 |
last_item = my_list[ -1 ]
Way cleaner than my_list[ len( my_list )- 1 ], don't you think?
ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
last_item = my_list[ -1 ]
Way cleaner than my_list[ len( my_list )- 1 ], don't you think?
In "The Mental Game of Python," Raymond Hettinger spills the
beans about our noggins only being able to juggle 7 +/- 2
things in our short-term memory.
So, "last_item = my_list[ -1 ]" might still make the cut,
while "my_list[ len( my_list)- 1 ]" could be biting off
more than we can chew.
|The problem is, the number of brain registers this uses is
|10. This is no longer a decryption effort. This is a puzzle.
|At the moment you put it together, you fully understand it.
|But if this is embedded in bigger code, every time you hit
|this line, you're going to have to pick apart "what does this
|thing do?".
Raymond Hettinger
Then please explain why I have to write:
i += 1
Instead of the shorter:
i ++
My short-term memory is really stressed.
5 is a object that x and y points to. ++x or x++ will redefine 5 to
Truex, y = 5, 4+1
id(x) == id(y)
Truex, y = 10**200, 10**199*10
x == y
Falseid(x) == id(y)
Truex, y = 5, 4+1
id(x) == id(y)
Truex, y = 10**200, 10**199*10
id(x) == id(y)
1600000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000id(x)
Then please explain why I have to write:
i += 1
Instead of the shorter:
i ++
My short-term memory is really stressed.
I heard this behavior is because python's integers are immutable.
For example:
>>> x,y = 5,5
>>> id(x) == id(y)
True
5 is a object that x and y points to. ++x or x++ will redefine 5 to
6, which the interpreter forbids to keep it's state mathematically consistent. Also, by not supporting x++ and ++x, it avoids the pre-
and post-increment (substitute-increment v. increment-substitute) bugs
that plagues C and it's children.
This only works for small integers. I guess
this is because tagged pointers are used
nowadays ?
On 8/11/24 3:04 am, Mild Shock wrote:
This only works for small integers. I guess
this is because tagged pointers are used
nowadays ?
No, it's because integers in a certain small range are cached. Not sure
what the actual range is nowadays, it used to be something like -5 to
256 I think.
BTW you have to be careful testing this, because the compiler sometimes
does constant folding, so you need to be sure it's actually computing
the numbers at run time.
... print( a, b, end=" ", )a = 0; b = 0; c = 0; d = 0
while a is b:
Truex,y = 10**10, 10**9*10
id(x) == id(y)
On 8/11/24 3:04 am, Mild Shock wrote:
This only works for small integers. I guess
this is because tagged pointers are used
nowadays ?
No, it's because integers in a certain small range are cached. Not sure
what the actual range is nowadays, it used to be something like -5 to
256 I think.
BTW you have to be careful testing this, because the compiler sometimes
does constant folding, so you need to be sure it's actually computing
the numbers at run time.
Falsex, y = 257, 257
id(x) == id(y)
Truex, y = 257, 257
id(x) == id(y)
Hi,
In Java its possible to work this way
with the Integer datatype, just call
Integer.valueOf().
I am not sure whether CPython does the
same. Because it shows me the same behaviour
for small integers that are more than
only in the range -128 to 128. You can try yourself:
Python 3.14.0a1 (tags/v3.14.0a1:8cdaca8, Oct 15 2024, 20:08:21)
Truex,y = 10**10, 10**9*10
id(x) == id(y)
Maybe the idea that objects have an address
that can be accessed via id() has been abandoned.
This is already seen in PyPy. So maybe we
are falsly assuming that id() gives na object address.
Greg Ewing schrieb:
On 8/11/24 3:04 am, Mild Shock wrote:
This only works for small integers. I guess
this is because tagged pointers are used
nowadays ?
No, it's because integers in a certain small range are cached. Not
sure what the actual range is nowadays, it used to be something like
-5 to 256 I think.
BTW you have to be careful testing this, because the compiler
sometimes does constant folding, so you need to be sure it's actually
computing the numbers at run time.
For example this article:
https://www.codementor.io/@arpitbhayani/python-caches-integers-16jih595jk
about the integer singletons claims:
Falsex, y = 257, 257
id(x) == id(y)
But on Windows my recent CPython doesn't do that:
Python 3.14.0a1 (tags/v3.14.0a1:8cdaca8, Oct 15 2024, 20:08:21)
Truex, y = 257, 257
id(x) == id(y)
Mild Shock schrieb:
Hi,
In Java its possible to work this way
with the Integer datatype, just call
Integer.valueOf().
I am not sure whether CPython does the
same. Because it shows me the same behaviour
for small integers that are more than
only in the range -128 to 128. You can try yourself:
Python 3.14.0a1 (tags/v3.14.0a1:8cdaca8, Oct 15 2024, 20:08:21)
Truex,y = 10**10, 10**9*10
id(x) == id(y)
Maybe the idea that objects have an address
that can be accessed via id() has been abandoned.
This is already seen in PyPy. So maybe we
are falsly assuming that id() gives na object address.
Greg Ewing schrieb:
On 8/11/24 3:04 am, Mild Shock wrote:
This only works for small integers. I guess
this is because tagged pointers are used
nowadays ?
No, it's because integers in a certain small range are cached. Not
sure what the actual range is nowadays, it used to be something like
-5 to 256 I think.
BTW you have to be careful testing this, because the compiler
sometimes does constant folding, so you need to be sure it's actually
computing the numbers at run time.
I heard this behavior is because python's integers are immutable.
++x or x++ will redefine 5 to 6, which the interpreter forbids ...
x = 55
x ++5
x = 55
++ x6
x = 55
y = (x += 1, x - 1)5
x = 55
y = (x += 1, x)6
On Thu, 07 Nov 2024 12:55:53 +0530, Annada Behera wrote:
I heard this behavior is because python's integers are immutable.
Nothing to do with that.
++x or x++ will redefine 5 to 6, which the interpreter forbids ...
One of those is actually syntactically valid.
It just won’t do what you expect it to do.
Well you can use your Browser, since
JavaScript understand post and pre increment:
So we have x ++ equals in Python:
x + = 1
x - 1
But I don't know how to combine an
assignment and an expression into one
expession. In JavaScript one can use
the comma:
x = 55
y = (x += 1, x - 1)5
x = 55
y = (x += 1, x)6
But in Python the comma would create a tuple.
6x = 5
y = (x := x + 1); x
(6, 6)x, y
(6, 6)x = 5 # define
x += 1 # increment
y = x # alias
x, y
5x = 5
(x := x + 1) - 1
6x
6x = 5
y = (x := x + 1); x
(6, 6)... irrational drivel removed ..x, y
On 8/11/24 14:40, Mild Shock via Python-list wrote:
Well you can use your Browser, since
JavaScript understand post and pre increment:
Question: are we talking Python or JavaScript?
So we have x ++ equals in Python:
Trying to find a word-for-word translation serves as badly in computer- programming languages as it does in human spoken-languages. Learn how to adapt and embrace the differences...
x + = 1
x - 1
The above probably only 'works' (the way you expect) in the REPL.
But I don't know how to combine an
assignment and an expression into one
expession. In JavaScript one can use
Again!
"Everything should be made as simple as possible, but no simpler."
Check out "The Zen of Python" and PEP-0008 for Python idioms.
the comma:
x = 55
y = (x += 1, x - 1)5
x = 55
y = (x += 1, x)6
But in Python the comma would create a tuple.
Exactly, just as driving on the left side of the road will be fine in
some countries but cause a crash in others. Learn the local rules FIRST!
The 'walrus operator' could be applied:
6x = 5
y = (x := x + 1); x
(6, 6)x, y
However, if such were submitted for Code Review, unhappiness would result.
Was the question re-phrased to: how to ... in Python, we'd end-up with something more like this:
(6, 6)x = 5 # define
x += 1 # increment
y = x # alias
x, y
(6, 6)x = 5
y = x = x + 1
x, y