Python Language Features and Tricks
41–50 of 86 posts
Re: Python Language Features and Tricks
#42Re: Python Language Features and Tricks
#43Earlier 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'd extend that one step further unpacking where first-class patterns are increasingly becoming available in some languages which offer pattern matching (in particular, Haskell will have them soon).
Re: Python Language Features and Tricks
#44Earlier quoted context omitted.
For TRE: http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi... For the GIL, there are alternative implementations of Python (Jython, IronPython, etc.)
Hm... Python only supports 1000 recursions? That seems unsafe. It seems like anyone who writes functional-style code will run the risk of a stack overflow.
http://neopythonic.blogspot.co.uk/2009/04/final-words-on-tai...
Is Guido's take on it.
Essentially, as I understand it, his take is that massive recursion is confusing, and 'unpythonic'. And with the whole 'explicit is better than implicit' thing, I guess there is a point.
Some times recursion is the best/most obvious solution, and then it is a bit annoying to not have TCO, but you can usually work around it.
Re: Python Language Features and Tricks
#45One thing that strikes odd for me is how people describe Python/Ruby are way more readable than Java.
I felt that Python, while more readable than Ruby (because Python uses less symbols), still contain more nifty tricks compare to Java.
It's true that the resulting code is less code but behind that less line of code bugs might linger around because there might be plenty "intents" being hidden deep in the implementation of Python.
The Python way that is touted many times is "explicit is better than implicit" seems to correlate better with the much maligned "Java is too verbose".
Anyhow, the other day I was refreshing my Python skill and learned the default implicit methods that I can override ( those eq, gte, gt, lte, lt) and I wonder how overriding those resulted in less lines of code compare to Java overriding equals, hashCode, and implementing one Comparator method than can return -1, 0, 1 to cover the whole spectrum of gte, gt, lte, (and even equality, given the context).
I suppose everything is relative...
Re: Python Language Features and Tricks
#46Earlier quoted context omitted.
I'd extend that one step further unpacking where first-class patterns are increasingly becoming available in some languages which offer pattern matching (in particular, Haskell will have them soon).
I did a little googling, but am finding it difficult to find good clear information - do you have any articles where I can read about first-class patterns?
That's the haskell extension.
To see a very nice use of them, check out this paper (pdf) http://strictlypositive.org/CJ.pdf
Re: Python Language Features and Tricks
#47I've been using Python and Ruby on and off for a couple years (largely because I haven't found the need to use it seriously day job or side projects). One thing that strikes odd for me is how people describe Python/Ruby are way more readable than Java. I felt that Python, while more readable than Ruby (because Python uses less symbols), still contain more nifty tricks compare to Java. It's true that the resulting cod…
I think comparisons about readability aren't very useful (they are subjective, 'enough' counts), but I sure like the relative terseness of Python (to the point that I lament people who come over and write Java in Python (I don't mean to direct that at you, it's just a thing that happens, where people don't take advantage of things that are very idiomatic and thus clear even when terse)).
Re: Python Language Features and Tricks
#48I think this is great, I've been doing Python for a while and I knew many of the features but I also learned a few new ones. I don't understand how this one to flatten lists works: a = [[1, 2], [3, 4], [5, 6]] [x for l in a for x in l] Can somebody explain what the order of operations is here and what the variables refer to in the various stages of evaluation?
The expression is a list comprehension with 2 nested for statements. It is similar to this, which names its result: result = [] for l in a: for x in l: result.append(x)
Re: Python Language Features and Tricks
#49Why are there so many negative comments? Maybe those posters are vastly underestimating how many people that just start out read HN. I think it's a pretty good post to read after something like "X in Y minutes - Python" to get a very quick grasp of what the language is like. I'm also not ashamed to say that despite having written quite a few LOC of Python I wasn't aware of named slices for some reason and I think the…
(I've been using python for many years, but not full time. It's the language I use for one-off scripts, small tools that make use of its handy standard library, or prototypes for things I'm going to write in some other language. That's my excuse for the gaps in my knowledge.)
Re: Python Language Features and Tricks
#50Earlier quoted context omitted.
The expression is a list comprehension with 2 nested for statements. It is similar to this, which names its result: result = [] for l in a: for x in l: result.append(x)
Yes. And the order of the two for's in the list comprehension was deliberately kept the same as the order of the two for loops in your explicit code, on purpose, for ease of remembering how the former (i.e. list comp) works.
I see now that the Python docs explain this very clearly...