On 02/24/2013 09:29 AM, Michael Torrie wrote:
> On 02/24/2013 09:23 AM, Ethan Furman wrote:
>> On 02/24/2013 07:46 AM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:> Hi guys,
>>> Question. Have this code
>>> intX = 32 # decl + init int var
>>> intX_asString = None # decl + init with NULL string var
>>> intX_asString = intX.__str__ () # convert int to string
>>> What are these ugly underscores for? _________________str___________________
>> This is a good example of why you shouldn't program language X in language Y.
>> For starters, `intX.__str__` should be written as `str(intX)`;
>> For middlers, intX_asString is probably not necessary (is it being printed? then
>> do a `print intX`, or a `print "size left on disk: %d" % intX`, etc.
>> For finishers, why the System Hungarian Notation?
> I think he's maintaining existing code. It's unfortunate that his first
> exposure to python is code written by someone else in such a poor style,
> and in a way that definitely isn't pythonic. No wonder he's struggling
> to like python!
On the bright side, if this is one of his 2000 line scripts, he should be able to get it down
to at least half that once he has a good feel for Python and re-writes it.
> Another way to explain the double underscore methods is that they are
> how things like operator overloading is performed. Want to make a class
> that you can use the [index] notation on instances? Define the
> __get_attr__() method.
Actually, it's the __getitem__ method.
In article <(E-Mail Removed)>,
Ethan Furman <(E-Mail Removed)> wrote:
> On the bright side, if this is one of his 2000 line scripts, he should be
> able to get it down
> to at least half that once he has a good feel for Python and re-writes it.