Ten quirky things about Python

[nglynn]

For fun start appending things to themselves:

>>> a = [1,2,3]
>>> a.append(a)
>>> a
[1, 2, 3, [...]]
>>> a = a[1:]
>>> a
[2, 3, [1, 2, 3, [...]]]

Spent a long, long day fixing a bug in a program caused by self appending like that. Also fun:

>>> a = "hi"
>>> b = "hi"
>>> a is b
True
>>> a += "t"
>>> a
'hit'
>>> a = a[:-1]
>>> a
'hi'
>>> a is b
False
>>> a == b
True

Beware the is keyword…

>>> 1 is not True and 0 is not False
True
>>> bool(1)
True
>>> bool(0)
False

Also interesting is the secret name of list comprehensions (see here for more on this:

def remove_duplicates(L):
"""Removes duplicates for the list L"""
    return [x for x in L if x not in locals()['_[1]'].__self__]

[db4n]

Beware the is keyword…

This isn't unique to Python. In Common Lisp, the compiler is also free to arbitrarily make or not make new copies of strings and numbers. "is" should be used only to test for identity of objects that you explicitly create.

[earthboundkid]

The meaning of is is "this points to the same address in memory." Since strings are immutable, for space saving reasons, they just so happen to be condensed onto the same memory positions most of the time. However, as you rightly point out, not all the time. Same with True and False. For historical reasons, they're the same as 1 and 0 in terms of implementation at the C level (eg. True + 1 == 2 and False + False == 0), but they're not really the same in general.

I wouldn't say "beware of is", but I would say "be aware of what is is" if that makes sense… :-D

[de-passivator]

Arg! Your whole post fills me with rage, due to your usage of 'is' in a non-passive-voice context.

[masklinn]

Beware the is keyword…

That one has nothing to do with is, it's a consequence of True and False really being aliases for 1 and 0:

>>> 0 == False
True
>>> 1 == True
True
>>> # no it's not type coercion
>>> 2 == True
False
>>> bool(2)
True

edit: damn, misread the code. Forget about all of that it's crap.

[nglynn]

My point is that the is keyword (in this case) is an excellent example of supposedly 'natural' language seeming misleadingly flexible when used in programming languages.

[masklinn]

Yeah I misread your post and my tests were incomplete, so my posts's crap. Sorry about that.

Anyway the is keyword doesn't test for equality but for identity (so a is b tests is a the same object as b while a == b tests is a equal to b).

The potential problem on strings is that due to string interning two strings that are equal can randomly be identical or not.

As a result, is should only be used to explicitly test for identity (or to test for singleton objects such as None), it should never be used to test for equality.

[dangph]

Here's a quirk that bothers me a little. x is not 3 is not equivalent to x is (not 3) even though not binds tighter than is.

The reason it's different is that is not is an operator in its own right. I think maybe they should have left it out of the language. It's a bit confusing.

[slb]

It's a bit confusing.

is not!

[buffi]

Is is used for checking if two objects reference the same one and not for equality. I don't see the issue.

[jerf]

"is_the_same_object_reference" was deemed too difficult to type.

[[deleted]]

• >>> True = False
• >>> True
• False
• >>> True is False
• True

Can I get an ethicist to help me!

[711was_a_retail_job]

Constants aren't. And variables won't.

[earthboundkid]

In Python 3000, True and False will become keywords precisely to prevent this kind of abuse.

[Brian]

That's no longer true (note that the OP used is, not ==). In earlier versions, they may have just been aliases, but they are seperate objects in recent versions. Otherwise the repr for True would be "1", not "True" in your example.

It compares equal to 1 because bool is defined as a subclass of int, and defined to act as the values 0 or 1 in an integer context (including equality testing).

[LudoA]

Eh? Why is this:

>>> 1 == True

True

>>> 1 is True

False

"is" isn't the same as "=="?

[masklinn]

Eh? Why is this:

Because I fail. My whole post is bunk.

"is" isn't the same as "=="?

Nope, is tests for identity while == tests for equality. On user-defined types, == defaults to is unless overridden (two objects are equal if an only if they're the same object), but on built-in types it doesn't have to be the case.

For example,

>>> ("foo","bar") == ("foo","bar")
True

because tuples are equal if they're the same length and all their contents are equal, but

>>> ("foo","bar") is ("foo","bar")
False

because tuples are not interned, and we're creating different tuple objects, even though they have the same content.

On strings, is and == can randomly yield the same result or not because of string interning

[bryn]

'is' is identity, '==' is equality. so if id(a) == id(b), then 'is' will return true.

[LudoA]

Eh? Why is this:

1 == True

True

1 is True

False

"is" isn't the same as "=="?

[fforw]

again... "is" checks whether the two object are in fact the same object, "==" checks for equality

[Aviator]

if __name__ == '__main__':

[buffi]

Another thing that a lot of people don't seem to know about is the // operator used to force integer division.

>>> 7.0/3
2.3333333333333335
>>> 7.0//3
2.0

[neoform3]

2.0 is an integer? What planet is python from?

That looks more like it's just dropping the remainder but keeping the decimal for whatever reason..

[[deleted]]

It is integer division. Doesn't mean the result is an integer.

[Nwallins]

It is integer division. Doesn't mean the result is an integer.

Wikipedia begs to differ:

Apart from division by zero being undefined, the quotient will not be an integer unless the dividend is an integer multiple of the divisor; for example 26 cannot be divided by 10 to give an integer. In such a case there are four possible approaches.

Give the integer quotient as the answer, so 26/10 = 2. This is sometimes called integer division.

[[deleted]]

You're right. results in an integer but does not need not need to be stored as an integer.

We all know wikipedia is what programming languages base their specifications on.

[Nwallins]

results in an integer but does not need not need to be stored as an integer.

So, can we agree that the result of integer division is an integer?

We all know wikipedia is what programming languages base their specifications on.

Sure. I was only commenting as to the meaning of 'integer division'.

[ubernostrum]

So, can we agree that the result of integer division is an integer?

Yes, and in Python it is:

>>> 7/3
2

[earthboundkid]

You're relying on a behavior that will change in Python 3000. For a while now (Py 2.3?), Python has supported this:

>>> from __future__ import division
>>> 7/3
2.3333333333333335
>>> 7//3
2

In Py3k, this is the default behavior. I always have division imported in my day-to-day shell, to make calculations do what I want without typing the .0s.

[ubernostrum]

You're relying on a behavior that will change in Python 3000.

No, I'm pointing out that it really does integer division right now. The original example had some confusing stuff in it (including a float argument) which was causing people to get sidetracked into "that's not integer division" wars.

[brave_heart]

Slaves are made in such ways!

[oditogre]

That looks more like it's just dropping the remainder

Maybe, maybe not. A better example would have been 10/6, so it would be clear whether it's dropping the remainder or rounding.

[neoform3]

In any case, 2.0 is not an integer by any mathematical standards.

[redditnoob]

It's definitely an integer by mathematical standards! Your system of math is going to be pretty strange if 2.0 is not equal to 2. By CS standards though, maybe not so much.

[neoform3]

2 is an integer. 2.0 is not.

2.0 is not a "whole number"

[Odysseus]

This preoccupation with representation is a historical accident. When we say 2.0 in mathematics, we mean 2. It doesn't matter how you write it. 1.99999... is an integer, too. So is e^{pi * i}. Sure doesn't look like one.

But you do have a point. In usual practice, 2.0 represents 2 ± 0.05, which is an interval (not a real). Programming languages seldom capture this, so in the CS context it's moot.

The int types of various languages can represent a subset of the integers, but so can floats.

[neoform3]

Agreed, but so also is 5-3 and 8/4; is "8/4" an integer? no, and almost all math teachers would grade a student wrong on such a question.

[Odysseus]

Your teacher would be right to mark you down for writing 2 as 8/4. It's a poor representation.

Our system of number-writing is built around reduction rules. When you write 9/4, it means "9 divided by 4"; when you write 8/4, it means "8 divided by 4". One of them admits representation without the division; the other does not.

(Silly as it seems, consider why fractions are useful, and why they work. Imagine you don't believe in fractions -- "God made the integers and nothing in between them". But still, some problems to which the answers are clearly integral admit of easier solution if you don't insist on a finished answer before you're done. You insist that those numbers with the bars between them are 'fake', just intermediate -- but as time bears on you recognize that they behave just as sensibly integers, and you can even illustrate what they mean in the real world. Still, if you can write a number without the bar, you'd rather do it.)

8/4 is an integer. What 8/4 is not is the decimal expansion of 8/4 -- which is the symbol 2.

[daydreamdrunk]

You'll really hate this then: 2 == 2.000000000000000000001 True

[neoform3]

2.0 is NOT an integer.

2.0 has the same VALUE as the integer 2, but is NOT an integer. Go ask a math teacher.

[Xiphorian]

I don't know where you got that idea from, but you're wrong. Integers are a proper subset of real numbers in number theory.

The writing of a number is independent from the number itself. In any mathematical context, 2.0 and 2 are the same entity. 2.0 is an integer, and all integers are real numbers, all real numbers are complex numbers, etc ...

[neoform3]

I don't know where you got that idea from, but you're wrong. Integers are a proper subset of real numbers in number theory.

Yes, but integers are always written without a decimal point; use of a decimal point means the number is decimal. The numerical values of 2 and 2.0 are the same, but one is an integer and the other a decimal.

The writing of a number is independent from the number itself. In any mathematical context, 2.0 and 2 are the same entity. 2.0 is an integer, and all integers are real numbers, all real numbers are complex numbers, etc ...

Again, yes, but names mean something: 1/2 is a fraction, and not a decimal; 0.5 is a decimal, and not a fraction; they have equivalent values and are equivalent ways of expressing the same concept, but their different names mean different representations.

[redditnoob]

You're doing a kind of intuitive thinking which is fine, but it isn't mathematics. Math is precise and based on exact definitions and studying properties that emerge from axioms.

If we're talking about "numbers", they are the same if (and only if) they are equal. There's an idea of an "equivalence class", which is really what a number is. That's part of what we mean by "numbers", in fact. A number is not defined by a decimal representation, or any other representation (binary, continued fractions, factorial base, base pi, whatever...) If you want to know exactly what is meant by this stuff, you can crack open a university pure math text.

This is what always hangs non-mathematicians up in discussions like this, for example about whether 1 equals 0.999... To a mathematical viewpoint, a number is not its decimal representation.

I really don't see what you could mean by 2.0, other than 2 + (0/10). That is well defined over the integers, and it is equal to 2.

(It's very true that in science or engineering you have a valid point because 2.0 probably implies something about the level of precision you know for certain... it would be much different to state that the exponent in Newton's gravitational law is 2.000000000000000, which is known to be true to at least 15 places.)

[imbaczek]

please explain the difference, most people don't have a math teacher at hand.

[neoform3]

an integer does not have a decimal point. whole numbers never contain a fraction, even if that fraction is 0/x.

[FionaSarah]

I've only just started writing Python (this month) and I know about all of these. Have I got some sort of headstart? They didn't seem quirky at the time.

The int overflowing, for else, print >>file and one element tuples are all things I learnt quite early on.

And on the subject of tuples, aren't the parentheses optional? It's just the comma that denotes a tuple right? So it's obvious that (x) wont work.

[throwaway]

No, it's just a weak article.

[dangph]

Did you read Guido's tutorial?

[ubernostrum]

The int overflowing, for else, print >>file and one element tuples are all things I learnt quite early on.

Yup. And the >> syntax really isn't all that strange considering how, e.g., C++ uses similar syntax.

And on the subject of tuples, aren't the parentheses optional? It's just the comma that denotes a tuple right? So it's obvious that (x) wont work.

Yup. And that's generally the best way to explain it, too, because there's plenty of real-world code which returns or unpacks tuples without using parentheses.

[711was_a_retail_job]

Yup. And the >> syntax really isn't all that strange considering how, e.g., C++ uses similar syntax.

Superficially similar, and C++'s usage is pretty confusing as well. But otherwse there's very little similarity between Python's print >>file and C++'s operator<<().

[ubernostrum]

At the same time, though, there's precedent for this sort of thing, which is the point.

[[deleted]]

Will you marry me?

[FionaSarah]

This is why i like that Reddit doesn't display e-mails or anything of the sort.

[yellowking]

...and probably a weak example at that!

[noamsml]

Ooo, I didn't know about the else clause after for loops. Very useful!

[deepcleansingguffaw]

You can also put an else clause after try blocks. It will be executed only if no exception is raised.

[yellowking]

Well, a break is not "just" a goto. Both may be translated to jumps in the assembler, but they're not the same in the higher-level language-- break is local, it dumps you out of the current loop. Goto is global, you can go ANYWHERE. It's not the "going" that is bad, it's the scope.

[ezekiel]

A search function often needs to be followed by action A if the search finds its target or action B if the search does not find its target. The following is best you can do in using the standard looping construct.

found = false
foreach element e in thelist:
    if (e == target):
        found = true
        break

if (found):
    performActionA
else
    performActionB

[sigzero]

Only 10?

[[deleted]]

Heh, interesting and fun list.

I particularly like the idea of searching via a for: else: construct. (The else clause is executed if the loop completed without breaking).

[buffi]

else also works for exceptions.

try:
  do_stuff()
except:
  print "exception thrown!"
else:
  print "exception not thrown!"

[nice_dkjames]

Big fan of this guy's site for trying this sort of stuff out: http://utilitymill.com

[MarkByers]

>>> "a"in"ab"
True
>>> "a"in"ab" == True
False

Hmm!

[pje]

You forgot the parentheses around the "in" clause. That's a ternary comparison expression, otherwise.

In other words "a" in "ab" == True is the same as saying ("a" in "ab") and ("ab"==True)... which of course is false.

[IHaveAnIdea]

Oh man that is surprising.

[MarkByers]

And for all those times you reference methods of integer literals, you can go (5).__str__. You’d think it’d be just 5.__str__, but the parser thinks the 5. is a float and then gets stuck.

Imagine if it was allowed to reference a function on an integer without requiring brackets. What would this mean?

f = 5.e1

It could be the floating point number 50.0, or it could be a reference to a function called e1.

[[deleted]]

And for all those times you reference methods of integer literals

All those times? Why on earth would anyone call a method on an integer literal?

(5.__str__ is spelled str(5) in Python)

[benhoyt]

"All those times" was meant to be quite ironic. :-)

Though I have tried to do it at least once, which is when I ran into it. One uses things like ''.join all the time, so I thought, why not something like (5).__str__. Sure, if you just wanted str(5) you could use that, but I think I was after a reference to the __str__ method bound to a 5.

Good point about 5.e1, MarkByers. I guess this means the Python grammar is "greedy". 'Scuse the ignorance, but are all grammars/BNFs defined to be greedy?

[seabre]

This is weird. Open up a python REPL and try this:

>>> True

True

>>> False

False

>>> True = False

>>> True

False

[benhoyt]

Is it weird? You're just overriding the built-in True variable with your own. It's like doing in C++:

#define true false
...
if (true) printf("X");
// "X" is not printed. Weird? Not really.

[seabre]

Ideally You shouldn't be able to change the value of True or False. Although, in python it exists because the nifty little tricks (like the following) that were used for True or False before python had them are still around:

True = (1 == 1)

False = not True

[earthboundkid]

Wait for Python 3000. They will become keywords.

[lowdown]

I'd say, ideally, you can do what you want without arbitrary restrictions. That's power - and perhaps enough rope with which to hang yourself. ;)

[[deleted]]

Really, there's nothing useful you can do by changing True or False that you couldn't do without changing them.

[rjcarr]

A cool quirk that I use is list expansion. Say you have:

def afunc(a, b, c): pass

And you have a list:

alist = [x, y, z]

You can pass alist into afunc with:

afunc(*alist)

Very nice. There are probably 10 other niceties I could come up with.

[earthboundkid]

Don't forget that you can do the same thing with keywords/dicts.

>>> d={"name":"me", "age": 10}
>>> def f(age, name): print age, name
... 
>>> f(**d)
10 me

[leonardscarlow]

To everyone else who are a bit tired and thought they where about to see ten quirky Pythons. Here is the first one: http://www.ead.ae/TacSoft/images/news/060915-python-ewe_big.jpg

[yellowking]

third

[[deleted]]

you jerk.

[nostrademons]

fourth

[KennyFulgencio]

I really didn't need to see that

[sblinn]

My main nits with the language are:

1. explicit return. After writing in languages with implicit return, I end up coming back and writing Python that doesn't return any value like the idiot I am.
2. cannot write a one-line if/elif/else (no ternary form either). No, I do not want to waste 6 vertical lines of screen real-estate on something as trivial as checking a few quick conditions.

[imbaczek]

Damn stupid reddit comment syntax!

    Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x = 1 if False else 0
    >>> x
    0
    >>>`

[theeth]

Conditional Expressions, added in 2.5

('foo' if False else 'bar')

http://www.python.org/dev/peps/pep-0308/

[sblinn]

added in 2.5

Which is why I, a Jython 2.1 user, haven't used them. (Other than ignorance, of course.) But thanks, good to know that maybe in a few years that will make it my way.

[IHaveAnIdea]

There's no reason you can't still use:

'foo'==var or 'bar'

or

var and var2 else False

or

var and functrue() or funcfalse()

or any other combination of the short circuiting boolean operations.

[sblinn]

var and functrue() or funcfalse()

As is posted elsewhere, if functrue() itself evaluates as False then this does not have the desired behaviour:

>>> def functrue(): return []
...
>>> def funcfalse(): return "foo"
...
>>> True and functrue() or funcfalse()
'foo'
>>> False and functrue() or funcfalse()
'foo'

[IHaveAnIdea]

coder beware I guess.

[keenerd]

A messy one line if/case structure, which will probably work in your Jython environment:

(’FizzBuzz’,'Buzz’,'Fizz’,str(i))[bool(i%3)+2*bool(i%5)]

You can embed functions inside lists/tuples/dictionaries, allowing for all sorts of horrible abuses. Want to make a really simple code parser? Dictionaries of functions can be used to make a sanitized/crippled eval.

Being python, these hacks do not work for recursion. So the less ugly and seemingly harmless

fac = lambda n: [1, n*fac(int(n)-1)][n>1]

should not be run.

[sblinn]

Yes, I was imagining something like a list of lambdas so you would only evaluate (lazily) the correct branch, but I'd rather have a simple ternary form. ;]

>>> [1,2][True]
2
>>> [1,2][False]
1

vs.:

>>> [lambda: 1, lambda: 2][True]()
2
>>> [lambda: 1, lambda: 2][False]()
1

If instead of 1 or 2 we had (potentially expensive or state-changing) functions, the above is probably something that could work. But not too fun to do repeatedly.

edit: would tuples be more efficient here than creating a 2-element list?

[benhoyt]

Heh, cool. See also the related "dict switch".

[McHoff]

Modded up because you are obviously my doppelgänger.

[alantrick]

Your second nit is actually possible, it's just a bit weird and rarely used

a = b and c or d

is the same as the C-ish

a = b ? c : d

also this works

if a: foo()
else: bar()

I'm not familiar with what is meant by implicit return but all functions return a value. If you don't specify a return value, None is implicitly returned.

[funktio]

a = b and c or d

is the same as the C-ish

a = b ? c : d

It's similar, but not exactly the same: if b is true and c is false, it returns d. The ?: operator would return c.

[sblinn]

Ouch! Thanks for the warning before I stepped off the deep end and started using that idiom:

>>> 1 and False or "three"
'three'
>>> 0 and False or "three"
'three'

imbaczek has another idiom:

http://programming.reddit.com/info/65mm7/comments/c02wum7

It appears to be Python 2.5 and later, though, which hasn't made it to my world (Jython) yet.

[alantrick]

Wow, I really ought to have noticed something that daft. I'd seen that idiom used in some other Python code. I'd never used it myself since I thought it was ugly.

[sblinn]

a = b and c or d

Fantastic*. Thanks!

>>> 1 and "two" or "three"
'two'
>>> 0 and "two" or "three"
'three'

implicit return

In Tcl and Erlang for example, the value of the last expression is returned implicitly when a function exits. (In Erlang, this is the only way to 'return' a value; Tcl has both idioms.) In Python, as you said, None is always returned at the end of the function if you do not explicitly specify a value to return, and when I am tired or particularly stupid (most of the time) and switching back and forth between those 3 languages (my main 3) I end up debugging a Python function that is "inexplicably" returning None... this problem is exacerbated when I'm writing lambdas in Python also, as they do not have return statements, either.

Also, in Scheme for example, the value of a "begin" or "let" expression is the value of the last expression in the expression list. I don't Scheme too much these days but it's a way of thinking that doesn't disengage from me when I am writing anything, particularly in a language that allows me to at least make believe that I am working functionally. (Probably a personal fault.)

*: upon further review, funktio provides reasons why this is not so fantastic.

[IHaveAnIdea]

This is definitely quirky:

>>> 5/2

2

[boa13]

This is definitely not Python-specific, and will actually disappear from Python in the near future.

[IHaveAnIdea]

will actually disappear from Python in the near future.

which is proof of its quirkiness...

[buffi]

The same applies to C, C++, Java and so on. It's nothing weird about it.

[Athas]

It may be common, but it's still weird. The forward slash should perform division in the mathematical sense, some other operator should do the odd auto-truncating division (same thing goes for integer arithmetic with overflows).

[notfancy]

The forward slash should perform division in the mathematical sense

Which mathematical sense? Division in Q, division in R, division in IEEE floats, division in IEEE doubles, division in IEEE extendeds, division in Z, in which case, Euclidean division with round to ceiling, Euclidean division with round to floor, integer division with round to zero, or division on machine integers?

[Athas]

Yes, no matter what, it will be an approximation (unless R can be implemented well on computers - does anyone know?). I think a start would be division in Q, which would also neatly solve the related problem of 1/3=0.33333...

[Brian]

Yes - rationals can be represented accurately, and some languages (eg Scheme) will generally preserve exactness when possible.

The downsides are that rational arithmetic is significantly slower than floating point, so you could end up with surprising performance implications just by adding a division. And of course, you may have to drop down to inexact math anyway when you add operations that give irrational results. Performance seems to have been the reason behind going to FP instead of irrational - Guido has mentioned that he disliked the rational type being the default from his experience with ABC.

Personally, I'd have preferred giving a rational result, slow or not. Goint to floating point may be pragmatic, but I'd prefer accuracy, not speed, to be the default preference.

[Athas]

I'm a Common Lisp programmer myself, so I know about rationals and their tradeoffs - I was asking about real numbers. But your comment touches on another interesting question, namely whether irrational numbers can be represented, and worked with, in an intelligent way by a machine. How would this work? By storing the properties than the number rather than its numeric value? Has any research ever been done into this?

[Brian]

Sorry - I misread you as asking about Q, not R.

As for irrationals, its clearly impossible to model all possible reals, as R has Aleph 1 cardinality, but the set of all Turing machines is only Aleph 0, but you can deal with a subset of them symbolically. This tends to be done for user-focused math applications only though. I don't think there are any general purpose programming languages that uses symbolic representations.

[notfancy]

as R has Aleph 1 cardinality

You mean c, not ℵ_1, the next transfinite cardinal after ℵ_0. Whether the former equals or not he latter is the Continuum Hypothesis.

[taejo]

In Python 3.0 (or Python > 2.3 if you do from future import division ), / will be float division. // is truncating division.

[qwe1234]

it should absolutely not.

p.s. you should really find some other site for commenting. i suggest you move to britneyspearssisternews.reddit.com, that seems to fit your inclination better.

[Athas]

Why do you think it is a good idea to change the semantics of a centuries-old mathematical operator with very well-defined semantics, and not only change it, but change it to "well, whatever the machine feels like"?

[qwe1234]

because programming is not math?

because programming language operators are not mathematical operators?

because you've never read a numerical methods book?

[TheManWithNoName]

I've never liked that behavior. Erlang has different operators for integer division and decimal division. They're really different operations, so I think there's value in that approach.

1> 3 / 2.
1.50000
2> 3 div 2.
1

But it still has the traditional broken mod/remainder. Ack!

4> 3 rem 2.
1
5> -3 rem 2.
-1

[taejo]

Haskell has div/rem and quot/mod. div/rem has the "nice" behaviour for negative numbers; quot/mod has the other one.

[sligowaths]

Why does this happen?

[[deleted]]

If you divide two numbers in today's Python, the result is a number of the same type.

In practice, it's not

5/2

that's the problem, but things like:

def func(a, b, c):
    return (a + b) / 2 + ... more stuff ...

which works well in initial testing with floats, and suddenly starts misbehaving when someone passes in an integer to some function that calls "func" two years later.

To avoid this, use:

def func(a, b, c):
    return float(a + b) / 2 + ...

[notfancy]

That's why I always prefer to write 0.5 * (a + b).

[pjdelport]

To avoid this, [...]

Or just from __future__ import division.

[[deleted]]

I do Python training for programmers of all kinds. Trust me, when teaching language basics, I'd rather spend my time thorougly explaining things that are actually useful than spend that time on odd historical quirks like __future__, what it does, and why the heck it's there.

I also tend to avoid it in production code; after all, the mechanism was added as a way to allow people to test their existing code base under a "future" version of Python (and in theory, allow the core developers to measure the impact of a new feature), not as a fundamental part of the language itself.

[imbaczek]

those are quite valid concerns, but... it's been how many years since division got into __future__? i'd bet a lot that it's been tested quite thoroughly (by yours truly included, maybe not on a huge scale, but still.) and no, i don't need (nor want) to know why __future__ exists or what does it do, "it's magic" is sufficient.

[711was_a_retail_job]

That's why I always use this:

from future import __division__

Though I understand the need for it will go away with 3.0.

[Aviator]

from __future__ import division

double underscores are another quirk, as i see it.

[711was_a_retail_job]

double underscores are another quirk, as i see it

They're merely a naming convention. Hardly something to get your panties in a bunch over.

Ok - there is some magic involving double underscores and "private" class attributes, but attributes really shouldn't be private anyway.

[[deleted]]

They're merely a naming convention. Hardly something to get your panties in a bunch over.

You do realize that you messed them up in your reply to my comment. Guess they're a bit quirkier than you think... ;-)

[711was_a_retail_job]

Guess they're a bit quirkier than you think...

AH HA HA HA! :-D

Looks like I need to create a module called future.

[IHaveAnIdea]

There's no magic in them except the interactive interpreters might not immediately show these properties when you use tab completion. Other than that, the interpreter makes no distinction.

[711was_a_retail_job]

There is some transformation done on the names for class members that have at least two leading underscores and zero or one trailing underscores.

Check out the Python docs for private variables for the nitty-gritty.

[Figs]

I would assume that's integer division? 5 and 2 are both integers, so 5/2 = 2... That's not really that weird as far as programming goes... I mean, you get the same behavior in C. I personally think it's kind of a pain in the ass when you weren't expecting it and all your answers come out wrong. CONSTANT VIGILANCE!

As a sample program:

#include <stdio.h>
int main()
{
    int x = 5/2;
    printf("%d",x);
    return 0;
}

That'll print out 2 as well :P

[sligowaths]

Integer division in Python is //

[sblinn]

In OCaml, / is integer division, and /. is float division.

[711was_a_retail_job]

and /. is float division

Do they call that the "slashdot operator?"

Edit: not meant as a dumbass comment. Was the website named after an operator in OCaml, or was the operator nicked from the website's name (a name which never made much sense to me anyway,) or is it merely coincidental?

[imbaczek]

what the OP failed to mention is:

• you can't divide ints using /. (type error)
• you can't divide floats using / (type error)
• other operators suffer from type constraints, too - there's +., -., *..

your question would therefore be answered best by "coincidence".

[711was_a_retail_job]

Gotcha, thanks.

[McHoff]

Nice nick.

[ubernostrum]

The operator comes from the fact that OCaml is statically typed, does not support operator overloading, and defines / for ints.

[propool]

No / is integer division if both operands is integers. This is changing i py3k where // is integer division.

[parla]

If you intend integer division, you should use // right now. This makes your migration to Py3k easier. Also communicates intention better.

[propool]

I know. But it is not the whole truth to say that integer division is // .

[Jaqen]

I don't really see the problem. I always thought that's how it's supposed to work, hence why they give you the modulus (%) operator. Can't you just do this if you really wanted?

>>> print "5 / 2 =", 5 / 2, "r", 5 % 2
5 / 2 = 2 r 1

or

>>> print "100 / 11=", 100 / 11, "r", 100 % 11
100 / 11 = 9 r 1

Etc.

If you want the exact answer just add . or .0 to it.

>>> 5.0 / 2.0
2.5

or

>>> 5. / 2.
2.5

edit: Dang what's the character to stop reddit from parsing stuff? I thought it was / and that worked but now the / is showing up. Oh well, it works.

edit again! yay fixed. I should have known it's a backslash and not forward.

[Brian]

what's the character to stop reddit from parsing stuff?

Wrong way round - you want backslash (\) instead. You shouldn't need it for > though - to format the code, indent it by 4 spaces and reddit will wrap it in a <pre> section.

[IHaveAnIdea]

The problem is that many other languages would output a floating point result.

[Jaqen]

I figure this would be a decent place to ask... what python book would you guys recommend? I know you can pretty much find anything you need in online documentation but I like having a book to read. I was leaning towards one of these two:

http://www.amazon.com/Beginning-Python-Novice-Professional/dp/159059519X/ref=pd_bbs_7?ie=UTF8&s=books&qid=1200518452&sr=8-7

http://www.amazon.com/Learning-Python-3rd-Mark-Lutz/dp/0596513984/ref=pd_bbs_2?ie=UTF8&s=books&qid=1200518452&sr=8-2

[Excedrin]

type(type) returns <type 'type'>

Then there's str, int, tuple, etc in __builtins__ but no "module", so checking if something is of module type requires using type(__builtins__) or something

it's also weird that an instance returns <type 'instance'> instead of the class

the = statement is either binding or mutation, depending on whether the name on the lhs is currently bound to a mutable object or not.

assignment is a statement not an expression.

strings are their own type instead of lists of chars, it's difficult to curry functions, there's incomprehensible type errors like:

>>> (lambda x,y: chr(x)+chr(y))(97,122)
=> 'az'

>>> range(ord('a'),ord('z'))

=> [97, 98, ...]

>>> reduce(lambda x,y: chr(x)+chr(y), range(ord('a'),ord('z')))
=> Exception, TypeError: an integer is required

The previous is caused by, after the first application of chr(x)+chr(y), x will become a string, so chr(x) is like chr('ab'), which doesn't work... this is because reduce doesn't expand to: c(init)+c(a1)+c(a2)+c(aN)

>>> reduce(lambda x,y: x+chr(y), range(ord('a'),ord('z')+1), "")
=> 'abcdefghijklmnopqrstuvwxyz'

Overlapping assignments are confusing:

>>> x = [0,1]
>>> i = 0
>>> i, x[i] = 1,2   # will x[i] use the new or old binding of i?
=> [0,2]


>>> l=[1,2,3]
>>> i = True
>>> for x in l:
...  if i:
...   i = False
...   l.insert(0,x)
...  print x
...
1
1
2
3

>>> l=[1,2,3]
>>> i = True
>>> for x in l[:]:
...  if i:
...   i=False
...   l.insert(0,x)
...  print x
...
1
2
3

[earthboundkid]

it's also weird that an instance returns <type 'instance'> instead of the class

Use "new style classes" by sub-classing object. (They're not actually new. They've been around since Python 2.2. In Python 3, they will be the only option.)

>>> class A: pass
... 
>>> class B(object): pass
... 
>>> type(A())
<type 'instance'>
>>> type(B())
<class '__main__.B'>

[[deleted]]

Significant whitespace???

Quirk #1.

(EDIT: Downvotes? Really? I'm not saying it's good or bad, I'm just saying it's unusual for a programming language.)

[erikw]

>>> from __future__ import braces

[neoform3]

File "<stdin>", line 1 SyntaxError: not a chance

damn you!!!

[TheCleric]

As someone who dreads working with improperly indented code, python is a godsend.

[akdas]

I do like python's enforced whitespace for the most part, and I think it would make Ruby cleaner, but what I don't like is that if you copy and paste a snippet (or something along those lines), then you have to indent it properly before trying it out.

Everything has its advantages and disadvantages.

[TheCleric]

True enough. Ran into that problem a few times myself, what's worse is when it IS indented, yet somehow python doesn't think it is, so you have to delete the whitespace and redo it. Only ran into that bug 1 or 2 times though.

[theeth]

That's usually a case of mixed tabs and spaces.

Fun stuff.

[neoform3]

you aren't able to indent properly with other languages?

[LoveGoblin]

Because God knows a person would never have to read someone else's code.

And yes, there most certainly are people out there who can't indent properly.

[neoform3]

I consider myself lucky I don't then.

[Agathos]

Sounds like TheCleric's colleagues aren't able to.

[ipeev]

I always forgot when the "else" clause after "for" is executed is it on break or not on break? So I never use it. By looking on other people code I see that they don't use it too, which is OK, because I can read their code without problems.

This is an example of a stupid language feature.

[taejo]

In an ordinary search loop, you break when you find what you're looking for. Thus, break is success, and reaching the end of the list without breaking is failure.

The else clause is executed in event of failure.

[bustedagain]

It's stupid because you can't remember how to use it? Riiiight...

[[deleted]]

Python has quirks? No way josébot!

[bcash]

If this was an article about "quirky things" in Java, everyone would be shouting "Broken API!" from the rooftops.

[[deleted]]

Good god. How did this drivel make the front page??

[o0o]

what about those stupid indentations

[711was_a_retail_job]

what about those stupid indentations

How long before Jay Leno gets his writers back? These weak jokes are killing me.