Jim's email seems not to have gotten through to the whole list. There's a lot of that going aruond.
On 8/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
I don't think Jim's issue is a real one (according to the snippet I see in your email) because doc is an object defined in one and only one place in Python. It has a unique id(). If two people use the name "doc" then they will be addressable as module1.doc() and module2.doc(). No problem.
There is something different about annotations than everything else in Python so far. Annotations are the first feature other than docstrings (which are proto-annotations) in core Python where third party tools are supposed to go trolling through your objects FINDING STUFF that they may decide is interesting or not to them. When you attach a metaclass or a decorator, you INVOKE CODE that you have installed on your hard drive and if it crashes then you load up your debugger and see what happend.
When you attach an annotation, you are just adding information that code OUTSIDE OF YOUR CONTROL will poke around and interpret (the metadata processor, like a type checker or documentation generator). What you do when you attach an annotation is make an assertion. You always want to be confident that you and the person writing the processor code have the same understanding of the assertion you are making. You do not want to attach a list because you are asserting that the list is a container for a bunch of other assertions about the contents of the list whereas the person writing the processing code thinks that you are asserting that the variable will be of TYPE list.
Now I'm sure that with all of your framework programming you've run into this many times and have many techniques for making these assertions unambiguous. All we need to do is document them so that people who are not as knowledgable will not get themselves into trouble. It isn't sufficient to say: "Only smart people will use this stuff so we need not worry" which is what the original PEP said. Even if it is true, I don't understand why we would bother taking the risk when the alternative is so low-cost. Define the behaviour for intepreting a few built-in types and define guidelines and best practices for other types.
Pickling works because of the underscores and magic like " __safe_for_unpickling__". Len works because of __length__. etc. There are reasons there are underscores there. You understand them, I understand them, Talin understands them. That doesn't mean that they are self-evident. A lesser inventor might have used a method just called "safe_for_pickling" and some unlucky programmer at Bick's might have accidentally triggered unexpected aspects of the protocol while documenting the properties of cucumbers.
These are not universally understood techniques. Let's just document them in the PEP.
If it wasn't at least a bit complicated then there would be no underscores. The underscores are there to prevent SOMETHING bad from happening, right?
Paul Prescod
>Sure there is. There will probably be several frameworks using the
>magic name "doc".
>
>This isn't a problem for the person writing myfunc, and therefore
>isn't a problem for immediate decorators. It is a problem for
>inspection code that wants to present information about arbitrary
>3rd-party libraries.
By this argument, we shouldn't have metaclasses or function attributes,
because they have the same "problem".
I don't think Jim's issue is a real one (according to the snippet I see in your email) because doc is an object defined in one and only one place in Python. It has a unique id(). If two people use the name "doc" then they will be addressable as module1.doc() and module2.doc(). No problem.
However, it's only a problem if you insist on writing brain-damaged
code. If you want interoperability here, you must write tell-don't-ask
code. This is true for *any* use case where frameworks might share
objects; there is absolutely *nothing* special about annotations in this
regard!
There is something different about annotations than everything else in Python so far. Annotations are the first feature other than docstrings (which are proto-annotations) in core Python where third party tools are supposed to go trolling through your objects FINDING STUFF that they may decide is interesting or not to them. When you attach a metaclass or a decorator, you INVOKE CODE that you have installed on your hard drive and if it crashes then you load up your debugger and see what happend.
When you attach an annotation, you are just adding information that code OUTSIDE OF YOUR CONTROL will poke around and interpret (the metadata processor, like a type checker or documentation generator). What you do when you attach an annotation is make an assertion. You always want to be confident that you and the person writing the processor code have the same understanding of the assertion you are making. You do not want to attach a list because you are asserting that the list is a container for a bunch of other assertions about the contents of the list whereas the person writing the processing code thinks that you are asserting that the variable will be of TYPE list.
Now I'm sure that with all of your framework programming you've run into this many times and have many techniques for making these assertions unambiguous. All we need to do is document them so that people who are not as knowledgable will not get themselves into trouble. It isn't sufficient to say: "Only smart people will use this stuff so we need not worry" which is what the original PEP said. Even if it is true, I don't understand why we would bother taking the risk when the alternative is so low-cost. Define the behaviour for intepreting a few built-in types and define guidelines and best practices for other types.
After you run into the issue a few times, you look for a solution, and end
up with either duck typing, interfaces/adaptation, overloaded functions, or
ad hoc registries. ALL of these solutions are *more* than adequate to
handle a simple thing like argument annotations. That's why I keep
describing this as a trivial thing: even *pickling* is more complicated
than this is. This is no more complex than len() or iter() or filter()!
Pickling works because of the underscores and magic like " __safe_for_unpickling__". Len works because of __length__. etc. There are reasons there are underscores there. You understand them, I understand them, Talin understands them. That doesn't mean that they are self-evident. A lesser inventor might have used a method just called "safe_for_pickling" and some unlucky programmer at Bick's might have accidentally triggered unexpected aspects of the protocol while documenting the properties of cucumbers.
These are not universally understood techniques. Let's just document them in the PEP.
However, it appears that mine is a minority opinion. Unfortunately, I'm at
a bit of a communication disadvantage, because if somebody wants to believe
something is complicated, there is nothing that anybody can do to change
their mind. If you don't consider the possibility that it is way simpler
than you think, you will never be able to see it.
If it wasn't at least a bit complicated then there would be no underscores. The underscores are there to prevent SOMETHING bad from happening, right?
Paul Prescod
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
