41–50 of 59 posts
In case there are Pythonistas here who will indulge a question: one thing I've never figured out how to do elegantly ("idiomatically", I suppose) is create a list of predetermined size initialized with a constant(usually zeros). I always end up with something kludgey like: x = [0 for i in xrange(0..100)] which seems so roundabout it can't possibly be the right solution.
x = [0] * 100
def __init__(self, first, second, third,
fourth, fifth, sixth):
Am I missing something here? The two just seem mutually exclusive in most cases (where the alignment position's required spaces % 4 != 0. Is the indentation done with just spaces then?
This might be completely trivial, but can someone explain to me how one Python idiom is not to mix tabs and spaces, and another is to align arguments over several lines when needed like this: def __init__(self, first, second, third, fourth, fifth, sixth): I see similar examples elsewhere, and I don't see how you can achieve the alignment without mixing in spaces - at least in some cases. I, too, prefer to align argum…
This might be completely trivial, but can someone explain to me how one Python idiom is not to mix tabs and spaces, and another is to align arguments over several lines when needed like this: def __init__(self, first, second, third, fourth, fifth, sixth): I see similar examples elsewhere, and I don't see how you can achieve the alignment without mixing in spaces - at least in some cases. I, too, prefer to align argum…
Yes, indentation is done just with spaces. Tabs are not used. Typically you set your text editor to have the tab key print 4 spaces.
Earlier quoted context omitted.
Actually [x for x in xrange(..)] will produce only one list. In Python 2.X, range() returns a list while xrange() an iterable. If you just need an iterable, itertools.repeat(0, 100) will do the trick.
I suppose I didn't say it correctly, you're still maintaining two objects though (xrange the iterable, and the new list being built by the comprehension). The "optimization" I suppose is a moot point because Python's handling of lists is pretty solid and this isn't the 90's anymore, but at least with the while loop you've only got one list object and an integer (which is faster, I would think, to increment than it is…
If either xrange or list comprehensions are implemented in C instead of Python, do you still think your version will run quicker? What do you think the likelihood of either or both of these being the case is on your Python implementation? How many name lookups and function calls do you think each version does? Do you think you should find out before writing longer and more complicated code to attempt to out-perform it?
On my machine, your implementation performed ~3 times slower than the naive idiomatic "[0 for _ in xrange(100)]" and closer to 4 times slower when I bumped the list size up to 20000. And your version was ~32 times slower than "[0] * 100" and around 60 times slower when I bumped the list size up to 20000.
So please, don't optimize without measuring and instead just write idiomatic code the first time.
The code, for reference:
def mk_list_1(size):
ls = []
cnt = 0
while cnt Executing 1000000 runs:
mk_list_1 took 32 s
mk_list_2 took 10 s
mk_list_3 took 1 sEarlier quoted context omitted.
Yes, indentation is done just with spaces. Tabs are not used. Typically you set your text editor to have the tab key print 4 spaces.
Ah, there lies the rub. Thanks a bunch.
I don't know which one is the "right" way, but I certainly prefer Emacs's default behaviour. Maybe I just didn't configure my Vim properly :-)
Example:
In Emacs:
def _five(one,two,
....,,,,..three,four):
In Vim, with 4 space Tabs:
def _five(one,two,
....,,,,|hree,four):
| => cursor position when you press ENTER.One thing that has always bugged me about PEP8 is the advice about trying to keep line length to I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN. I personally find it incredibly irritating when I see pe…
It's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page. This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen. If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human…
It seems there is a compromise to make between the readability of single statements versus the readability of the code as a whole.
One thing that has always bugged me about PEP8 is the advice about trying to keep line length to I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN. I personally find it incredibly irritating when I see pe…
People seem disregard this rule as "dated" without actually providing much argument! The reason is that with a larger screen you can get more than one file on the screen at once, and the usability of that massively trumps any minor linebreaking issues.
I also print out complex code fragments or read them on a tablet. In this format 80 characters or less is also quite excellent.
Finally, to I try limit to 76 characters. It permits you to do "> > " in e-mail conversations about the code without having it auto-wrap in mutt.
Here are my arguments against it:
- "Explicit is better than implicit."
- If there's need for a table as reference for what is intrinsically true and what is intrinsically false, then it's clearly not "elegant" enough for people to just understand from looking at the code.
- Conventions vary across languages. You're basically forcing anyone who looks at your code who's not used tons of Python (and who would otherwise completely understand the code) to look up that table.
I know about this construct but whenever I have a problem that requires it, I always forget and use old:
if counter -1 == len(obj):
...