I'll be the first to admit it. The point of writing a fake story by
Associated Press and publishing it on a programming mailing list is
totally beyond me.
Confoundedly yours,
Friðrik Már
--
http://mail.python.org/mailman/listinfo/python-list
Hi Rhodri,
It's only really a pitfall if you try to use the built-in after you've
redefined it. That's the thing to keep an eye open for.
You're right, but in cases where you're editing a codebase which you
didn't author entirely by yourself you may not be aware of that.
That said, if the
Tom Kermode wrote:
Do you know a good way to avoid running into this problem? It
makes sense to suggest not calling variables the same names as
built-in functions, but that's hard for a new python programmer who
doesn't already know what all the built-in functions are.
One way is using a code
Previously, I wrote:
P.S. While this is a fairly obvious problem it's usually a good
idea to post working code and a traceback when requesting help.
Nick wrote:
thanks for spotting the obvious errors, its my 2nd day programming
python in about 3 years.
I'm sorry, my saying it was obvious ma
Look at:
len = len(text)
You're overriding `len` (a built-in method), with an integer
(`len(text)`). You then call:
for i in range(len(fields)):
But `len` is no longer a callable, but merely an integer.
Regards,
Friðrik Már
P.S. While this is a fairly obvious problem it's usually a g
J Kenneth King wrote:
I was wondering when someone would mention filter()
I was happy to see that too.
It's clean, faster than list comprehension and in terms of clarity
it's only to be expected that the developer is familiar with, or at
least willing to look up, the available built-in met
ma wrote:
filter(lambda x: x, your_list)
Good call! Equivalent but more efficient:
filter(None, your_list)
Regards,
Friðrik Már
--
http://mail.python.org/mailman/listinfo/python-list
