• Advertisement
Sign in to follow this  

for each in: Pythonic?

This topic is 992 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was watching a video about beautiful Python where one of the core developers of Python said that for python 3 they should have named the for loop "foreach."

 

Does this make the following code pythonic now:

fruit = ["apple","orange","grape","watermelon","kiwi"]

for each in fruit:
    print each.upper()

I am starting to like using each now. I could even use "each item" to make it sound better? But each sounds okay. Anyone seen code like this before?

 

 

Share this post


Link to post
Share on other sites
Advertisement

I honestly think that looks bad. It doesnt really relate to using foreach as a keyword and "each" looks strange as a variable inside the loop. Variable names should be clear as to what they represent. That is not clear.

Share this post


Link to post
Share on other sites

If

for fruit in fruits  

  is best, that is what I will use. I was wondering if each would be good if the list had various data types. I was just wondering. Thanks for the replies. I can't teach bad habits. 

Edited by Tutorial Doctor

Share this post


Link to post
Share on other sites

I was wondering if each would be good if the list had various data types

If your list contains multiple, non-polymorphic datatypes, then you are doing something evil (or spent too much time in LISP).

 

Edit: just to clarify, a list containing multiple, non-polymorphic datatypes is almost impossible to operate on idiomatically. You are forced to either know the exact type and order of each element ahead of time (in which case a tuple would be more appropriate), or fallback to a chain of if insinstance(a, Foo): else: statements, which is just bad software design.

Share this post


Link to post
Share on other sites

Edit: just to clarify, a list containing multiple, non-polymorphic datatypes is almost impossible to operate on idiomatically. You are forced to either know the exact type and order of each element ahead of time (in which case a tuple would be more appropriate), or fallback to a chain of if insinstance(a, Foo): else: statements, which is just bad software design.


Not exactly. Remember that Python is an aggressive/enthusiastic user of duck typing, so non-polymorphic types that nevertheless expose the same interface can be operated on as a coherent collection.
 
#Python 2.7 is still my system default; i should change that...
L = [(1, 2, 3), "four", [5, 6], {'seven': 8, 'nine': 10, 0: 11}]
for item in L:
    print len(item)  # valid for any sequence type
    print i[0]       # valid for any subscriptable object: implement __getitem__()

I was wondering if each would be good if the list had various data types


Presumably you have aggregated your objects into a list because they are somehow conceptually related. That relationship should inform your naming. Their concrete types are not exactly irrelevant, but by far a secondary concern.

Share this post


Link to post
Share on other sites

non-polymorphic types that nevertheless expose the same interface


... that phrase makes no sense. smile.png

duck-typing is an _application_ of polymorphism, not an alternative to it.

It does if you understood swiftcoder's phrase as taking a C++-centric notion of "polymorphic" as "concrete types sharing the same inherited ancestor, which is the locus of said polymorphism," as opposed to "types fulfilling Liskov Substitution Principle for the given context." Above all I was trying to say that these types need only share the interface(s) exercised in the aggregated dispatch context (loop body), and no others.

If that wasn't his intent, however, then I apologize and you can ignore my comment.

Share this post


Link to post
Share on other sites


If that wasn't his intent, however, then I apologize and you can ignore my comment.

I was counting duck typing as polymorphism in this context, but the clarification is nonetheless warranted, as not everyone treats it that way.

 

The reason I mention LISP, is that in a language with tagged structs and pattern matching on types (i.e. most functional languages), it is quite reasonable to mix-and-match distinct types in the same container.

Share this post


Link to post
Share on other sites

 


I was wondering if each would be good if the list had various data types

If your list contains multiple, non-polymorphic datatypes, then you are doing something evil (or spent too much time in LISP).

 

Edit: just to clarify, a list containing multiple, non-polymorphic datatypes is almost impossible to operate on idiomatically. You are forced to either know the exact type and order of each element ahead of time (in which case a tuple would be more appropriate), or fallback to a chain of if insinstance(a, Foo): else: statements, which is just bad software design.

 

Certainly not. python can work on different types just like some kind of type erasure system. they are not polymorphic but some operations can apply to a whole variety of types. This is the same than working against the highest interface in OOP. In python you can do it too without any contracts.

take a look at that : http://lucumr.pocoo.org/2011/7/9/python-and-pola/

There is not even a mention of classes and inheritance and yet python can accept code that is even more powerful than multiple inheritance, because you can work against "operators" (c.f `len` example in the link). If you keep that in mind as a discipline when writing functions, you open your possible accepted types to a larger variety.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement