Live data from Hacker News

90% of Python in 90 Minutes (2013)

slideshare.net

21–30 of 61 posts

Re: 90% of Python in 90 Minutes (2013)

#21

From slide 32: > (In Python 3 // is integer division) I find it clearer to describe this behavior as "floor" division. You might think "integer division" would have the same results as python 3's `int(a / b)` when `a` and `b` are ints, but, no, this is not the case. I never could quite understand why all the hub-bub about "integer division" and why it should change from python 2 to python 3 because the behavior seeme…

The term "integer division" comes from the fact that Python 2 a/b is the same as Python 3 a//b if a and b are integers.

It's not the same as int(a/b), because like most languages int() rounds toward zero, and unlike most languages Python division rounds down.

100% agreed that "floor division" is a better description (e.g. it covers floats too).

Re: 90% of Python in 90 Minutes (2013)

#22

I guess if learning 90% of something takes 90 minutes, the remaining 10% will take 10 years.

And that is where problems start with keen and eager junior developers who think by knowing the 90% they really know the 100%.

Absolutely. Not using mutable variables as default arguments = 91%

Re: 90% of Python in 90 Minutes (2013)

#23

I guess if learning 90% of something takes 90 minutes, the remaining 10% will take 10 years.

And that is where problems start with keen and eager junior developers who think by knowing the 90% they really know the 100%.

Unfortunately here in HN we constantly upvote those junior developer's Medium posts.

Re: 90% of Python in 90 Minutes (2013)

#26
post #12

Earlier quoted context omitted.

It is also worth noting that in most languages -2 / 3 yields 0 and not -1, i.e. integer devision rounds towards zero, not towards negative infinity.

Yes, in fact that's the point I'm trying to focus on but never made explicit. Thanks.

Integer division rounding toward negative infinity makes it so that for integers a, b, with b > 0, then if a%b is defined as a - b * (a/b), you will always have 0 Integer division rounding toward zero makes that not so. a%b for negative a, positive b, will be On the other hand, rounding toward negative infinity means that (-a)/b != -(a/b), when b does not divide a. Rounding toward zero makes (-a)/b = -(a/b).

I think most mathematicians would rather have 0 <= a%b < b than (-a)/b = -(a/b) if they can't have both.

Re: 90% of Python in 90 Minutes (2013)

#28

Why are these books always focused on a fast learning principle? I really don't think anything useful can be made from 90 minutes of quick reading. It's a great refresher for people that didn't work with the language for a while. Now I remember python's annoying indents.

> Why are these books always focused on a fast learning principle? I really don't think anything useful can be made from 90 minutes of quick reading.

So TRUE !!!!

Re: 90% of Python in 90 Minutes (2013)

#29

From slide 32: > (In Python 3 // is integer division) I find it clearer to describe this behavior as "floor" division. You might think "integer division" would have the same results as python 3's `int(a / b)` when `a` and `b` are ints, but, no, this is not the case. I never could quite understand why all the hub-bub about "integer division" and why it should change from python 2 to python 3 because the behavior seeme…

Also, if you need simple (though not necessarily immediately obvious) ceil division, you can do this:

    -(-a // b)
As in:

    >>> 1 // 2
    0
    >>> -(-1 // 2)
    1
This works because the floor division is truly a floor (and not a truncate), so floor division of a negative number is "rounded" towards negative infinity, and not towards zero.

Re: 90% of Python in 90 Minutes (2013)

#30
post #22

Earlier quoted context omitted.

And that is where problems start with keen and eager junior developers who think by knowing the 90% they really know the 100%.

Absolutely. Not using mutable variables as default arguments = 91%

Python doesn't have 'mutable variables'. I think you mean 'not binding mutable values as default arguments', but that's totally fine. What's wrong is not understanding when default arguments are bound. There's nothing inherently wrong with this:

    class Wrapper:
        def __init__(self, wrapped):
            self.wrapped = wrapped

    def counter():
        def inner(w=Wrapper()):
            w.wrapped += 1
            return w
        return inner
Post reply on HN