Steve Jobless wrote:
> Bruno Desthuilliers wrote:
>> Steve Jobless wrote:
>>> Sybren Stuvel wrote:
>>>
>>>> Steve Jobless enlightened us with:
>>>>
>>>>> The first case can be just a typo, like:
>>>>>
>>>>> x.valeu = 5
>>>>>
>>>>> I make typos all the time. Without a spell checker, this message
>>>>> would be unreadable :).
>>>> Then learn to read what you type, as you type it. Typing without
>>>> errors can be trained.
>>>
>>> I'd rather let a machine to do that. Wasn't computer created for tasks
>>> like this? (No, not really. But...)
>> There's obviously a trade-off between 'security' and flexibility. As I
>> said, I do make lots of typo too, but OTOH the edit/test cycle in Python
>> is usually so short that such errors are not a problem for me - they're
>> caught almost immediatly.
>
> I hope you are right. But I have yet to see the proof. Just empirical
> arguments.
Well, I'm only talking about my own experience here - I do not pretend
to prove anything.
>>>>> The second case can be like:
>>>>>
>>>>> x.next = y
>>>>> y.next = None
>>>>>
>>>>> to create a linked list by piggybacking "next" to the class. It will
>>>>> overwrite the iterater for the class if defined.
>>>> You shouldn't simply pick a name and assign something to it without
>>>> checking the current use of that name. It's pretty much true for
>>>> everything in life.
>>>
>>> Well, the choice of "next" was not a good example. Sure, no one with
>>> decent Python knowledge would do that.
>>> But what about adding a method to the class? Am I supposed to ask "Is
>>> anyone using name xxx?"
>> assert 'xxx' not in dir(SomeClassOrObject)
>>
>>> The class may be used by developers I don't
>>> even know and some of them may be on the other side of the planet...
>> How could this be a problem ? What's added/changed at runtime in a given
>> app doesn't impact the source code.
>
> Say you are a 3rd party library developer. You can tell your customers
> to check dir(MyClass), but you can't enforce it.
No, you can't.
> Even if they do, just
> updating your library could break THEIR code. It's not your fault, but
> you have to patiently diagnose their problem and nicely tell them it's
> their fault.
If they monkeypatch my code, they are of course responsible for what may
happen then. And FWIW, I don't have to "diagnose their problem". Let's
put it the other way : I'm the one monkeypatching some 3rd part lib, and
following an update, it happens that my monkeypatch now breaks the lib.
I *know* I monkeypatched it, so my first take will be to inspect this
part.
> It's not a good idea to call them "idiots."
No 'idiocy' here, just willingness to assume one's own responsabilities.
> This may be an
> extreme case, but it could happen within a single organization. You may
> be in the framework group supporting several application groups.
>
>>>>> If I was working on a large project with many engineers, I'd assume
>>>>> someone will do things like this sooner or later. I've seen many
>>>>> horrendous code in my life and I have no control over who I work
>>>>> with.
>>>> Long live a versioning system. With that, you can find the person
>>>> writing the horrible code, and slap them on the back of the head.
>>>> People, like all animals, can be trained into doing the right thing.
>>>
>>> I'd like to. But often those people are long gone for one reason or
>>> another. Sometimes, it happens to be my boss...
>> If your boss is a bad programmer and doesn't know it, then you're in for
>> trouble whatever the language.
>>
>>> Maybe I should ask the question in a different way:
>>>
>>> What are the benefits from this? There must be something really good
>>> (and hopefully safe) you can do with it only from the outside. I don't
>>> have much problem over-riding functions from the inside of the class.
>>> But from the outside, I fail to see why anyone needs to add attributes
>>> or over-ride functions.
>> Just one example : suppose you're working with a framework. Suppose
>> you'd need to customize some objects (including classes - Python classes
>> are objects too) of the framework, but the framework has no hook for
>> this and you definitively don't wan't to bother patching the code and
>> maintaining your own branch.
>>
>
> <IMHO>
>
> Maybe it's cultural. But one aspect of OO is that you only need to know
> what the object does (interface), but you don't have to (and better not)
> know how it does (implementation).
Depends on what you're doing, but globally agreed.
> This is important because the class
> implementor can enhance and/or optimize the class without breaking
> users' code as long as the interface is compatible.
Yes.
> (This is why most,
> if not all, instance variables should be private.
No. Well, not exactly !-)
Attributes (instance or class, callable or not) that are implementation
should be marked as such, attributes (idem) that makes the API should be
marked as such. Any name starting with an underscore is implementation,
any name starting with a letter is API.
> You can use
> __getattr__/__setattr__, but they don't always work.) If you need to
> customize a class, you should sub-class it using the public interface of
> the base class.
Yes, of course. When it's possible. Sometimes it's not.
> You better not mess with it from the outside because
> updating the class can break your code.
Indeed. But what's better : being able to have a working app at the risk
of breaking something, or not being able to have a working app at all ?
> Unfortunately, I don't see a way
> to separate interface from implementation in Python.
Really ?
> So, it may not make
> much difference whether you subclass it or hack it from the outside.
Yes it makes a difference - and of course the preferred way to extend a
class is either to subclass it or to use composition/delegation. But
having the possibility to monkeypatch a module/class/object can really
be a life-saver. Also, the designer of a class / module / package /
framework/etc.. can not reasonnably hope to foresee any possible
*legitimate* use case, and so can choose to not expose features that
could (and perhaps should) be part of the API. Of course the right thing
to do in this case is to get in touch with the designer and ask him if
it could be possible to make this part public somehow - but this can
take some time, and here again, having the possibility to access
implementation can be a life-saver. And finally, there's the obvious
case of a bug in the 3rd part code - which can be solved by
monkeypatching too, until the patch has been submitted and accepted and
the patched version released...
> Python has some good features. The memory management using reference
> counting with garbage collection is very attractive. It can even do
> delegation! Unfortunately, it seems to be taking unnecessary risk. I was
> hoping someone shows me a compelling reason to sacrifice the safety,
As you said, this may be cultural !-). When I first learned Python,
coming from Java, I really felt the freedom and flexibility of Python as
pure madness and certainly not how it should be done. About 7 years
later, my experience is that nothing of what I was afraid of happened.
You're talking about "unnecessary risk" and "sacrifice the safety", but
IMHO it's mostly "irrational fear". Don't take it bad - it's pretty
normal to be afraid of what breaks our *feeling* of safety. But truth is
that there's no objective evidence of all the bondage part of Java and
friends leading to less buggy software. OTHO, there is a clear evidence
that Python's model just works.
> but
> I don't hear much. It looks pretty good as long as it is used by a small
> group, especially for a small project. (Or Python is meant just for such
> projects?)
Ask peoples at google. Ask all people using Zope (which is certainly not
a 'small project used by a small group'). I think there are enough
counter-examples around. OTOH, it also happens that what would be a
large project with most mainstream languages frequently turns into a
medium project in Python.
FWIW, C is famous for its lack of security, and the consequences can be
very very very much worst than a simple runtime error... This doesn't
prevent C from being the base building block of most if not all systems
in the world.
> But I don't feel comfortable enough for a large project that
> involves multiple groups including 3rd parties in a long duration. I
> just wish those "features" would be removed or at least made optional.
You can obviously add your own safety-belts to the language. MHO is that
it's completely counter-productive and a definitive waste of time, but
YMMV.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
