[Python-ideas] 'const' and 'require' statements

David Townshend aquavitae69 at gmail.com
Fri Jan 18 10:38:25 CET 2013


On Fri, Jan 18, 2013 at 10:08 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Fri, Jan 18, 2013 at 5:22 PM, David Townshend <aquavitae69 at gmail.com>
> wrote:
> > As has already been pointed out, syntax to allow compile-time
> optimisations
> > doesn't really make much sense in python, especially considering the
> > optimisations Pypy already carries out.  Some sort of "finalise" option
> may
> > be somewhat useful (although I can't say I've ever needed it).  To avoid
> > adding a new keyword it could be implementer as a function, e.g.
> > finalise("varname") or finalise(varname="value").  In a class, this would
> > actually be quite easy to implement by simply replacing the class dict
> with
> > a custom dict designed to restrict writing to finalised names.  I haven't
> > ever tried changing the globals dict type, but I imagine it would be
> > possible, or at least possible to to provide a method to change it.  I
> > haven't thought through all the implications of doing it this way, but
> I'd
> > rather see something like this than a new "const" keyword.
>
> While you won't see module level support (beyond the ability to place
> arbitrary classes in sys.modules), this is already completely possible
> through the descriptor protocol (e.g. by creating read-only
> properties).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>

True.  I was going for something which might work in modules too, but
module-level descriptors would probably be a more consistent approach
anyway.  This is actually something I have needed in the past, and got
around it by putting a class in sys.modules.  Maybe finding a neat way to
write module-level descriptors would be more useful, and cover the same use
case as consts?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130118/dbc246d9/attachment.html>


More information about the Python-ideas mailing list