Re: empty clause of for loops
Peter Otten schreef op 2016-03-16 13:57: If you don't like exceptions implement (or find) something like items = peek(items) if items.has_more(): # at least one item for item in items: ... else: # empty Only if such a function is used a lot or cannot be conceived without severe shortcumings adding to the syntax should be considered. The (hypothetical) question you should answer: which current feature would you throw out to make room for your cool new addition? No need for hypothetical functions or syntax: x = sentinal = object() for x in sequence: # handle x if x is sentinal: # sequence was empty. Disclaimer: not tested because I don't have access to Python from my working location. But it should work according to the language reference, section 8.3 on the 'for' statement: "Names in the target list are not deleted when the loop is finished, but if the sequence is empty, they will not have been assigned to at all by the loop." Regards, Ruud -- https://mail.python.org/mailman/listinfo/python-list
Re: how to convert string to list or tuple
Steven Bethard schreef:
> But unless the person eval-ing your code *only* writes immaculate code I
> can see that you can probably screw them. ;) I wonder why
> __subclasses__ isn't a restricted attribute... Is it ever used for
> something that isn't evil? ;)
>
> STeVe
Completely off topic, but I just cannot resist showing off.
Some time ago I used __subclasses__ in a way that is not evil. I think.
The details are described in the following thread:
http://groups.google.nl/group/comp.lang.python/browse_thread/thread/5c1ccb986c66cdc1/
A summary: I used __subclasses__ to apply the Chain-of-Responsibility
pattern to object creation. The code would appear to instantiate
an object of the root of a class hierarchy, but the actual object
that was created would be an instance of a subclass.
So to get back to your question: yes, there are non-evil
uses for __subclasses__. Weird perhaps, but non-evil.
Non-standard, sure . Too clever for my own good, very likely.
Regards,
Ruud
--
Ruud de Jong
'@'.join('.'.join(s) for s in (['ruud','de','jong'],['tiscali','nl']))
--
http://mail.python.org/mailman/listinfo/python-list
Re: Interpreter problem
Greg Lindstrom schreef:
I am using python 2.3.5 on a Linux system and have an odd problem
dealing with the 'sha-bang' line. I have a file, driver.py which starts
with
#!/usr/bin/python
and works fine (that is, when I type in ./driver.py at the command
prompt the file runs as expected). I have another file, myotherfile.py
which starts with the exact same line (#!/usr/bin/python) but I get
: bad interpreter: No such file or directory
I remember encountering a similar problem once. It turned out that
the python interpreter, when invoked through the #! line, will only work
properly if the line ends in a Unix newline (only a LF: '\n'). When you
create the line on a Windows or Mac platform the line ending will
typically be different: CR/LF (\r\n) for Windows, CR (\r) for Mac. For
the body of the python script this doesn't matter, but it does matter
for the #! line.
Not sure if this applies here, but who knows.
Good luck, Ruud
--
Ruud de Jong
'@'.join('.'.join(s) for s in (['ruud','de','jong'],['tiscali','nl']))
--
http://mail.python.org/mailman/listinfo/python-list
