mutable default parameter problem [Prothon]
mark at prothon.org
Sat Jun 26 01:13:20 CEST 2004
Dave Brueck wrote:
> You cut out my example that elaborated on the questions I was asking:
> 1) It's just part of the name. So from the language's perspective,
> whether you call it appendINPLACE or append! makes no difference?
It makes no difference to the interpreter, but to the other Prothon
programmers it makes a difference because it's a convention. Also append!()
is a standard library function so you don't get to change it :-)
> 2) (continuing on #1) that being the case, it's really just a naming
> convention, correct? (because the language itself doesn't do anything
> with that information - additional checking to enforce that
> convention, different functionality, etc)
>> From what I gather that's a "yes" to both questions.
>>> Seems like a waste to reserve a
>>> symbol for something so rarely needed.
>> I disagree. In-place modification is significant and happens often.
>> Ignoring this is dangerous.
> Well, now we're down to disagreeing how often it occurs. I just
> haven't seen very many cases in practice where (1) I want to both do
> something to an object AND have it return itself in a single step and
> (2) doing so can be done in a clear way, and (3) I want to do it for
> a good reason rather than just wanting to save a line of code. In the
> few cases I've seen so far, the rationale has apparently been to make
> the code shorter, not necessarily better.
There are many clean readable programming conventions that rely on return
values. This is certainly an acceptable construct, right?
while len(list.append!(x)) < 10:
blah blah blah
Compare that to the less readable and less maintainable Python version:
while len(list) < 10:
list.append(x) # duplicate code
I can come up with many more. I think when you have been without a language
feature for a while you tend to block it out of your mind.
>> How can you argue that the exclamation mark indicating
>> in-place-modification does not make it more readable?
> (1) Because in practice I haven't seen the need for it much,
You don't look for it because in the back of your mind you know you can't
> it encourages
> cramming more onto a line just because you can.
You are being pretty negative here. Not everyone is out to cram more into a
line. Give people a little more credit.
> The "print list.append!(5)" is a fine example of this IMO - you've
> combined two *completely unrelated* operations for no good reason.
> Yes, it's just an example, I know, but it's probably an example of
> how it'll be commonly (mis)used. For every one "good" use of the !
> form you'll probably have a thousand uses where the only benefit was
> that it saved a line of code. <0.5 wink>
I don't think I commited any big sin. It seemed plenty readable to me.
Combining operations on one line is done all the time. I suppose you would
x = a + b
x = x * c
instead of this:
print (a+b) * c
> (2) It's just a naming convention, so you can't rely on it's presence
> or absence as being accurate (probably not a big deal in practice, but
All programming involves trust. Any programmer can obfuscate his code a
> (3) Cases like w = x.y.z!() would confuse me, as would
> ref! = obj.method!
You are confused pretty easily. Maybe because you aren't used to them.
They read easily to me.
> x = ref!(5, 6, 7) # what the heck, x == obj?!
ref! is invalid by convention and obj?! would throw a syntax exception.
More information about the Python-list