which is "better" (or more Pythonic)?

[Skaperen]

this is an actual line from the file i am currently working on ...

elif all(isinstance(x,(int,float))for x in items) and all(x<0x110000 for x in items):

where i am wondering if doing it this way ...

elif all(isinstance(x,(int,float)) and x<0x110000 for x in items)

would be better. it is certainly shorter. can that be of value to make code be more Pythonic?

(i like to prefer "x" as the iteration variable name in comprehensions)

[Gribouillis]

I'm currently reading Martin Fowler's "Refactoring" book on my spare time and he advises to split loops that do several things at a time, so I think he would favor the first version. His examples are in Javascript, but his purpose is code readability and maintainability and that goes far beyond the choice of the language. The point is rather that someone who doesn't know your code may find the first version easier to understand because each of the loops focuses on a single thing. It also allows potentially to extract functions if you want to write someday

if all_int_or_float(items) and all_below(0x110000, items): ...

From a pythonic perspective, one usually tries to avoid type checking if possible, so the if all(isinstance... is not very pythonic per se.

[Skaperen]

without type checking this code (generator) would blow up, big time. i write a lot of functions (and some classes and generators) that could be used by others. they can get bytes/bytearray instead of str (or variations such as a list of them). IMHO, supporting that is a good thing. sometimes i use bytes, too. but working with bytes vs str requires some things to be done differently. for example, converting from numeric code (like chr() for str).

programs that i (or others who are using my functions) are often writing apps for end users who can make mistakes that they (the end user) can fix. we want to output error messages that are meaningful to those end users, rather than expecting them to understand Python trace backs and figure out what mistake led to that. more likely the user wants us to interpret that for them.