(original) (raw)

So it sounds like the \_source is a pre-requisite for the current exec-based implementation, but the proposal is to replace with a non-exec-based implementation, meaning \_source would no longer be needed for the module to work and might be eliminated. But \_source could continue to be generated lazily (and cached if thought helpful) using an @property, so even the (apparently rare) uses of \_source would continue to work.

This would in some sense be a DRY violation, but of a very pragmatic Pythonic sort, where we have two implementations, one for documentation and one for efficiency. How different would this be from all those modules that have both Python and C implementations?

On 17 July 2017 at 09:31, Antoine Pitrou <antoine@python.org> wrote:

Le 17/07/2017 à 15:26, Isaac Morland a écrit :
\>
\> I think I understand well enough to say something intelligent…
\>
\> While actual references to \_source are likely rare (certainly I’ve never
\> used it), my understanding is that the way namedtuple works is to
\> construct \_source, and then exec it to create the class. Once that is
\> done, there is no significant saving to be had by throwing away the
\> constructed \_source value.

The proposed resolution on https://bugs.python.org/issue28638 is to
avoid exec() on most parts of the namedtuple class, hence speeding up
the class creation.

\> I come from
\> a non-Pythonic background so use of exec still feels a bit weird to me
\> but I absolutely love namedtuple and use it constantly.

I think for most Python programmers, it still feels a bit un-Pythonic.
While exec() is part of Python, it's generally only used in fringe cases
where nothing else works.

Regards

Antoine.
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/isaac.morland%40gmail.com