Anti-Patterns in Python Programming

Post by syllogism » Wed, Jul 09, 2014, 9:08 PM UTC

dalke wrote: post #69

jcampbell1 wrote: post #48

Earlier quoted context omitted.

Can you clarify? def foo(default_arg = []): Why can't that just be shorthand for: def foo(default_arg = ParamNone): if default_arg == ParamNone: default_arg = [] How would that break first class functions?

As a minor point, use "default_arg is ParamNone", since "==" probably won't do the right thing. What breaks is something like: def foo(default_arg = slow_f()): pass Under the shorthand gets turned into: ParamNone = object() def foo(default_arg = ParamNone): if default_arg is ParamNone: default_arg = slow_f() pass This is fine, since everyone would know that the shorthand means to not put slow code there. Instead, peo…

Post by lilsunnybee » Wed, Jul 09, 2014, 10:01 PM UTC

jmount wrote: post #100

SEJeff wrote: post #34

Earlier quoted context omitted.

Couldn't agree more! One of my all time new python interview questions gets a surprisingly large number of developers. Given a function like: def append_one(l=[]): l.append(1) return l What does this return each time? >>> append_one() >>> append_one() >>> append_one()

Wow, that is really ugly semantics. Here are some notes of mine on how hard R works to avoid exposing this sort of aliasing/mutability issue to the user: http://www.win-vector.com/blog/2014/04/you-dont-need-to-unde...

Post by alextgordon » Wed, Jul 09, 2014, 10:25 PM UTC

jl6 wrote: post #92

dozzie wrote: post #66

Earlier quoted context omitted.

Tuples by pythonists are used as they were mere lists, just immutable. This is clearly displayed by Python's own interface. For the rest of the world, tuples are not immutable lists. They are tuples, i.e. collections of "objects" that could share nothing about their type. Tuples often are not even iterable! (Erlang, Haskell) The fact that tuples in Python can have as much structure as one wants is derived from dynami…

I'm sorry, I don't see clearly what a tuple should be. What would be different about Python tuples if they were true tuples?

Post by nilved » Wed, Jul 09, 2014, 10:37 PM UTC

LyndsySimon wrote: post #123

blossoms wrote: post #37

Earlier quoted context omitted.

alist = [foo(word) for word in words if word.startswith('a')] alist = map(foo, filter(lambda word: word.startswith('a'), words)) Which reads better?

I don't use FP practices in Python much, but if I did I'd define the filter outside the map, like so: begins_with_a = lambda x: x.startswith('a') alist = map(foo, filter(begins_with_a, words))

    ;; clojure
    (let [begins-with-a #(.startsWith % "a")
          foo #(do-some-stuff-with %)]
      (-> words (filter begins-with-a) (map foo))))

    # ruby
    words.filter { |e| e.start_with?(?a) }.map { |e| foo(e) }

Post by SEJeff » Wed, Jul 09, 2014, 10:48 PM UTC

bkeroack wrote: post #111

SEJeff wrote: post #82

Earlier quoted context omitted.

Map is not allegedly slower, it is demonstrably slower. $ python -mtimeit -s'nums=range(10)' 'map(lambda i: i + 3, nums)' 1000000 loops, best of 3: 1.61 usec per loop $ python -mtimeit -s'nums=range(10)' '[i + 3 for i in nums]' 1000000 loops, best of 3: 0.722 usec per loop Function calls have overhead in python, list comprehensions are implemented knowing this fact and avoiding it so the heavy lifting ultimately happ…

Fair enough. I said "allegedly" because I had never personally measured the performance difference. Even though you could construe map as "half as fast" (or twice as slow) as the equivalent comprehension, I don't see a difference of ~1 usec making any difference in my code thus far. Good to know, though.