11–20 of 54 posts
Thanks for posting. As a Ruby programmer I have been wanting to learn Python since 2 weeks and hopefully this will get me started for good.
Not bad, but the big weakness is that the author seems to be very familiar with more expert-level aspects of Ruby, but not so much with Python. And turns that into "Python doesn't have these". For example, he mentions Python doesn't have an equivalent of method_missing -- it's technically true that there's nothing you define on a Python class to specifically intercept a nonexistent method, but that's because Python's…
There are also a few non-idiomatic practices he seems to favor. For example, he seems to advocate use of `filter`, `map`, `reduce` in a few places, which, in Python, are better expressed with list comprehensions, combined with builtins like `sorted`, `all`, `any`, `sum`, etc. Adding the `operator` module opens up even more functional constructs without ever touching `map`, `reduce`, or `filter`.
Also, if I say "Python doesn't have these," I'm often saying it in support of Python! :)
Weird that author never mentioned PEP8 guide. I think it's the main thing that difference Python from Ruby developers. If you follow the PEP8 rules, you can interact with other Python programmers without much problems, and enforce you to be a better and organized programmer.
> It's harder to write code that pisses off other developers in Python
The presentation incorrectly identified Python dictionaries as “lists”. It also identified actual Python lists as lists. The presentation states that tuples are “immutable lists“ and that they ”should be homogeneous, but [this is] not enforced“. I disagree: tuples are meant to act as “records“ (as in a database or other set of data), which are neither lists nor homogeneous. The presentation brought up multiple times…
Indeed, hence `namedtuple` (named tuples extend tuples). The author got it exactly backwards: tuples are generally heterogenous, the (rare) cases of homogenous tuples are reflexive short lists and hope of a slightly cheaper creation cost.
Earlier quoted context omitted.
There are also a few non-idiomatic practices he seems to favor. For example, he seems to advocate use of `filter`, `map`, `reduce` in a few places, which, in Python, are better expressed with list comprehensions, combined with builtins like `sorted`, `all`, `any`, `sum`, etc. Adding the `operator` module opens up even more functional constructs without ever touching `map`, `reduce`, or `filter`.
Using list comprehensions as a replacement for filter and map I can see. I don't really see where you're getting at as far as substitutes for 'reduce' are concerned. For me, the 'operator' module is a justification for using 'reduce', not a replacement for it.
Reduce simply isn't used much in Python code, as a product of both culture and rather lacking lambdas. It's used so little (pretty much the only "usual use case" is covered by `sum`) it's been moved out of the builtins and to the functools module in Python 3 (whereas `map` and `filter` have remained)
One of the things that bothers me about python is the way you have to specify 'self' for instance methods. Instance methods should be the norm not the exception.
class Foo:
def bar(self):
return "bar"
foo = Foo()
foo.bar() # returns "bar"
Foo.bar(foo) # returns "bar"
After realizing this, I was enlightened.
The presentation incorrectly identified Python dictionaries as “lists”. It also identified actual Python lists as lists. The presentation states that tuples are “immutable lists“ and that they ”should be homogeneous, but [this is] not enforced“. I disagree: tuples are meant to act as “records“ (as in a database or other set of data), which are neither lists nor homogeneous. The presentation brought up multiple times…
From the context (I was there), that was obviously just a typo, probably carried over accidentally from a previous slide.
I know very little of Ruby, but difference 13 states that Ruby has stronger metaprogramming features in that "Python doesn't have define_method, class_eval, and method_missing". Are these really things that can't be implemented with metaclasses and overloading __getattr__?
* define_method simply isn't needed, just set a function as attribute on a class tadaa you've defined a method:
>>> class A: pass
...
>>> a = A()
>>> a.foo()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'A' object has no attribute 'foo'
>>> A.foo = lambda self: 3
>>> a.foo
of >
>>> a.foo()
3
>>> A.bar = classmethod(lambda cls: 4)
>>> A.bar()
4
>>> a.bar()
4
One of the things that bothers me about python is the way you have to specify 'self' for instance methods. Instance methods should be the norm not the exception.
Interestingly you can do this: class Foo: def bar(self): return "bar" foo = Foo() foo.bar() # returns "bar" Foo.bar(foo) # returns "bar" So it's not actually specifying `self` for instance methods; it's just a special thing about class instances that calling a method will call its class's method passing the instance as the first argument. After realizing this, I was enlightened.
I think you meant `Foo.bar(foo)` here.