A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/050006.html below:

[Python-Dev] __pycode__ extension

[Python-Dev] __pycode__ extensionSamuele Pedroni pedronis at bluewin.ch
Thu Nov 18 16:52:35 CET 2004
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 think that expanding the cases where inspect.getsource just work 
directly is valuable. And doing that seem a natural way to achieve this.

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

Stelios Xanthakis wrote:
 > Having used this system,
 > 'import' is a good barrier to say "I'm not interested for
 > the __pycode__ of these".

but for example having access to co_filename and or equilavent
(something would have to be for done for classes about this)
is probably also good enough to make that distinction:

 >>> def f(): pass
...
 >>> f.func_code.co_filename
'<stdin>'
 >>>

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4