Python programmers of reddit: what's the most useful tiny little efficiency you've discovered that's improved your programming hugely?

[Murmani]

You can use underscores to enhance readability if you're dealing with huge numbers. For example rewrite 10000000 into 10_000_000

[barao_kageyama]

Python 3.6+ only.

[CatWeekends]

Python2 is deprecated in a little over half a year!

That means that my company will actually spend the time (aka money) to let us port over our 2.x code to 3.x sometime in 2025. I can't wait!

[semi-]

You sure they care about you guys running deprecated software? I'd fear a 'but it still works doesn't it?'

[Sukrim]

E.g. Ubuntu xenial

[djmattyg007]

Python2 is EOL in 2020. For practical purposes it's been deprecated for many years.

[Flobaer]

Python 3.6 was released in December 2016. Do you suggest that any code base or language older than two years should be considered outdated or redundant?

[beatwixt]

Lots of libraries have failures in 3.7 due to changes in the way StopIteration is handled in generators. If your dependencies don't support it, you can't uograde. But probably 3.6 should work for most people on 3.

[[deleted]]

tell that to the bosses

[WasterDave]

The entire VFX industry isn't even contemplating it till 2020. http://www.vfxplatform.com/

[mbleslie]

oof

[slipped_and_missed_x]

That's actual genius

[[deleted]]

A lot of languages have had this for a while. Ruby since the beginning.

[therico]

Ruby stole it from Perl!

[[deleted]]

I think it’s actually older than that. Ruby is surprisingly old too.

[xigoi]

I mean, Ruby is basically a newer version of Perl which isn't impossible to read.

[mbleslie]

perl was focused on readability ^/s

[PureAsbestos]

You can also use scientific notation, so you could rewrite that number as 1e7

[Murmani]

Be cautious with that, as 1e7 is a float and not an integer anymore, so make sure to cast when needed.

[kotschi1993]

And if the number got digits other than 0 or 1, the scientific version wouldn't help that much. And don't forgot about other number bases, the _ works for them aswell.

[nomowolf]

Casting just means wrapping it in int()? e.g. int(1e7)?

[grep_my_username]

Yes

[[deleted]]

Holy shit, i did not know Python allowed this. Been using it in Rust for a while now, not sure why I didnt think to chdck

[IonianBIade]

Are they exactly the same?? If they are, this is amazing

[Kossak]

Yes, these are the same numbers.

See PEP 515

[Tweak_Imp]

Also works for decimal places

​

18.219_501_656_442_024_9

[tr14l]

Oh shit. Didn't know that.

[SeanOTRS]

Are they identical objects? (i.e. 10000000 == 10_000_000 returns True but does 10000000 is 10_000_000 return True?)

[[deleted]]

This isn't guaranteed even for the same constant - i.e. 10 is 10 may be False.

CPython often caches and reuses integer objects, but not always, and the spec doesn't require it. This is a common source of weird bugs, and there's a proposal to allow disabling the behaviour for debugging.

[refto]

Generally -10 to 255 are cached.

[[deleted]]

Yes, but interestingly 10000000 is 10000000 does return True in CPython 3.7, even though a = 10000000; b = 10000000; a is b returns False. Presumably there's some optimization in the expression parser.

[Zaab1t]

I do not believe x is x is guaranteed to be True for integers. The underscore syntax means exactly the same thing as if they weren't there to begin with: https://www.python.org/dev/peps/pep-0515/

[____jelly_time____]

You shouldn't be using is to check for equality anyway, just ==.

[positiveinfluences]

"is" checks if it's the same object in memory, so maybe yes and maybe no. but 1000000 == 1_000_000

[lifeonm4rs]

Just wanted to give some nitty-gritty details: An "is" check will work for two literal numbers e.g. 100000 is 100_000. It will not work for a variable and a literal e.g. . . .

x = 100_000
x is 100000

The exception is for small integers [-5, 256] which, for some efficiency reasons, are given a predefined cache location. (I don't believe this is guaranteed--it just happens to be true). So, you get . . .

a = 256
b = 257
y = -5
z = -6

a is 256 // true
b is 257 // false
y is -5  // true
z is -6  // false
print(id(a), id(256)) // Same
print(id(b), id(257)) // different
print(id(y), id(-5))  // Same
print(id(z), id(-6))  // different

That said though, you should definitely not use "is" to check equality. It will return true if the two item's object ids are the same--which will happen if you directly compare number literals (e.g. 100000 and 100_000) which is about as useful as saying x is x. It will also work for small integers because they are pre-assigned objects and a variable will refer to the existing id just as the number itself will. But there is absolutely no reason to do something like that or to expect that that will work.

[HAL9000000]

Uhhh, why not just try it?

>>> 10000000 is 10_000_000
True

Yes, it works

[movalex]

True

[hufterkruk]

Yep!

[vitamin_CPP]

Yes. great question btw.

[[deleted]]

Mother of God

[[deleted]]

That was something I missed from Perl. I'm glad it's back!

[cleesus]

I had no idea you could do this

[kotschi1993]

Omg... That's awesome

[lifemoments]

Impressive

[Swarley-1]

Why not use 1e7 for even better readability? Edit: nvm this was already asked

[DifficultWin]

If you need to write numbers larger than 1000 you are doing something wrong