[Python-Dev] __pycode__ extension

[Phillip J. Eby]

At 04:52 PM 11/18/04 +0100, Samuele Pedroni wrote:
>Phillip J. Eby wrote:
>>And I'd vote differently on both these matters.  Please state what your 
>>use cases are, so that solutions can be evaluated on the basis of what 
>>use cases they satisfy, not merely votes without any context.
>
>I don't get why your are particularly opposed to attaching source for 
>exec-ed/eval-ed code,

I'm not against it per se.  I'm against adding a feature that crudely 
satisfies certain use cases, but has to be worked around by people who have 
other use cases.

In some cases, a feature can become an "attractive nuisance" that people 
will use because it's there most of the time, but it then becomes 
problematic when it's not available.  This is especially problematic when 
the presence or absence of the feature is on a global basis, potentially 
breaking the composability of Python modules.  (I.e., module A relies on 
the feature's presence, but module B requires its absence.)


>I think that expanding the cases where inspect.getsource just work 
>directly is valuable.

Agreed.


>  And doing that seem a natural way to achieve this.

Also agreed - but my concerns are with the larger consequences of having 
'getsource' *seem* to work everywhere.


>OTOH I personally fully appreciate why you may want to have it work
>even if just pycs are around.

For me, a half-working __source__ feature is almost worse than none at all, 
since the former could lead to the illusion of making progress towards code 
reflection.  This is why I'd like it made clearer what problems this is and 
is not meant to solve, so that programmers who are tempted to use the 
feature will be clearer as to what is and isn't a good idea to do with it.