Live data from Hacker News

Python Language Features and Tricks

sahandsaba.com

71–80 of 86 posts

Re: Python Language Features and Tricks

#71
post #4

patterns / tricks = language deficiencies Wake me up when Python will support tail call elimination and will get rid of GIL. For now this language is no better than PHP.

I suggest you are suffering from the Blub Paradox[0][1][2]. [0] http://paulgraham.com/avg.html [1] http://c2.com/cgi/wiki?BlubParadox [2] http://weblog.raganwald.com/2006/10/are-we-blub-programmers....

P.G. is right about PHP. This language is better than Python in various ways. For ex. it does not scare people away if you want to sell your project, because everyone and their grandma knows PHP. Most successful web pages (eg. FB) started out with PHP, not Lisp, C++, Python, Java, but PHP.

Re: Python Language Features and Tricks

#72
post #4

patterns / tricks = language deficiencies Wake me up when Python will support tail call elimination and will get rid of GIL. For now this language is no better than PHP.

I suggest you are suffering from the Blub Paradox[0][1][2]. [0] http://paulgraham.com/avg.html [1] http://c2.com/cgi/wiki?BlubParadox [2] http://weblog.raganwald.com/2006/10/are-we-blub-programmers....

> I suggest you are suffering from the Blub Paradox[0][1][2].

Writing some C will cure that disease, but the treatment has possible side effects, like carpal tunnel syndrome.

Re: Python Language Features and Tricks

#73
post #30

Nice reference. 1.29 happened to be exactly what I was looking for: for subset in itertools.chain(*(itertools.combinations(a, n) for n in range(len(a) + 1))) I spent way too much time writing a function to come up with these combinations.

You can also do

    itertools.chain.from_iterable(itertools.combinations(a, n) for n in range(len(a) + 1))

Re: Python Language Features and Tricks

#74
post #28

Slice has always been a painful adventure for me. I always forget that [1:3] is not all inclusive. It's actually just range from 1 to 2. I believe in 2.7 zip is still returning a list rather than an iterator ( izip in Python 2, zip in Python 3+). Another unappreciated stdlib is definitely functools . mock is also another awesome stdlib. functools , collections and itertools are definitely useful to make things faster…

Slices make sense when you realize that [n:n] is always empty, and [:n] + [n:] is always the whole list. From these two identities, all else follows.

Re: Python Language Features and Tricks

#75
post #15

Earlier quoted context omitted.

Same here, learned something new today.

A common theme running through named tuples, itertools and collections is Raymond Hettinger. He has also put together lots of tutorials and talks.

Thank you sir, something else to go through on a quiet Sunday :).

Re: Python Language Features and Tricks

#76
post #67

Earlier quoted context omitted.

Unpacking is a limited form of what is called destructuring in other languages like Clojure. I would say that, in terms of feature-richness: unpacking < destructuring < pattern matching.

I don't know Clojure, but I do know Python, and I'd like to say that unpacking is more flexible than you may realize. For example, you can do this: a,(b,c),d = [1,[2,3],4]

I don't mean to belittle Python here, I think its a great language and I find its unpacking useful. I'm only trying to demonstrate that the concept can be (and is in some other languages, like Clojure) taken further to make it more useful still.

I think that Python's unpacking allows most, if not all, of Clojures sequence destructuring for tuples and lists. Clojure takes it a bit further, however, by applying it to all sequences. For example, you could do this:

    a,b,c = "XYZ"
because strings are also sequences. You can also do something like this (excuse the awkward syntax as I try to express it in pseudo-Python):

    a,b : c as d = [1,2,3,4,5]
    # a = 1
    # b = 2
    # c = [3, 4, 5]
    # d = [1, 2, 3, 4, 5]
This might not be so useful in python, since the list already is d and c is simply slicing the end from the list, but Clojure allows you to destructure function arguments: (defn foo [[a, b & c :as d]] ...) when passed the above list (foo [1 2 3 4 5]) would bind the variables as shown in the above comments.

Where destructuring really shines, though, is that you can destructure maps (dictionaries in Python) and vectors can also be treated as maps (their keys are the indices), so you can do stuff like this:

    a, {[b {:keys [c, d]} :foo}, e = [1, {foo: [2, {c: 3, d: 4}, bar: 9}, 5]
    # a = 1
    # b = 2
    # c = 3
    # d = 4
    # e = 5

http://clojure.org/special_forms#binding-forms

Re: Python Language Features and Tricks

#77

Coming from a long history of languages like BASIC and Pascal, I will bookmark this tutorial. It seems to open up a lot of interesting Python features that were, quite frankly, not always easy to understand when described in plain text, but now seem pretty simple when presented as examples. I'll also think about the "collection of simple examples" next time I want to document something.

I used to bookmark tutorials like this, but now ... I just bookmark the HN discussion. Not only does that retain a link to the tutorial, but it also retains a link to a discussion that usually adds value to the tutorial. I'm assuming that HN discussions remain available for many years. Anyone know for sure if that is/isn't true?

Instapaper has become my bookmarking tool. I don't even really sort it out anymore. I know it should be there when I need it and mostly the actual article is saved.

Re: Python Language Features and Tricks

#78
post #14

zip to unzip a dict is a very slow approach to do it Instead of mi = dict(zip(m.values(), m.keys())) Do mi = {v: k for (k, v) in m.iteritems()}

When did support for dictionary comprehensions make it into 2.x? I could've sworn it didn't used to work, but I just tried it in the shell and sure enough, it does in 2.7.3.

Wow I didn't know that! I was always doing something like this

    mi = dict((v,k) for k,v in m.iteritems())

Re: Python Language Features and Tricks

#79
post #70

Earlier quoted context omitted.

I'm aware of generator expressions, but the fact that list comprehensions are not lazy can trip people if they are used to other languages with this feature, since they are usually lazy.

Reading through http://en.wikipedia.org/wiki/List_comprehension , it seems that there are roughly equal numbers of languages where "list comprehension" produces strict list as languages where it produces lazy lists. I think it's a lack of naming convention - the word "list" on its own means "strict list" in some languages and "lazy list" in others.

Fair enough, I retract my statement :) Maybe people are not surprised after all.

Re: Python Language Features and Tricks

#80
post #61

Earlier quoted context omitted.

I'm aware of generator expressions, but the fact that list comprehensions are not lazy can trip people if they are used to other languages with this feature, since they are usually lazy.

I don't agree, people are more likely to come from python that to python from a language that has lazy list comprehensions. But regardless, using a language requires that you learn it and I doubt many people think list comp is lazy. Pythonic programming obeys explicit over implicit, which which if you want a lazy version you explicitly use a lazy version.

> Pythonic programming obeys explicit over implicit, which which if you want a lazy version you explicitly use a lazy version.

What does this have to do with anything? If the construct was defined as lazy, then it would be just as explicit. There is nothing about generator expressions that says "here, here, this is lazy".

Post reply on HN