[Python-ideas] Idea: Named code blocks / inline module declarations

Andrew Barnert abarnert at yahoo.com
Wed Sep 17 10:51:29 CEST 2014


On Sep 16, 2014, at 23:21, David Mertz <mertz at gnosis.cx> wrote:

> Why is this a misuse?

Well, for one thing, you're relying on the fact that unbound methods are just plain functions, which was not true in 2.x and is still not described that way in the documentation. You're also ignoring the fact that the first parameter of a method should be self and the convention (enforced by the interpreter 2.x, although no longer in 3.x, and by various lint tools, and likely relied on by IDEs, etc.) that when calling an unbound method you pass an instance of the class (or a subclass) as the first argument.

In short, you're going to confuse both human and automated readers. Anyone who gets how methods and descriptors work is going to be able to figure it out, but is that really sufficient for readability?

Of course you could solve all of that by declaring each method @staticmethod--or by writing a metaclass or class decorator that does that for you automatically, or (if you don't care about 2.x, or about consenting adults accidentally creating an instance and discovering that the methods don't work) just writing one that does nothing except indicate to the human reader that this is a non-instantiatable class whose methods are all static.


> Classes are largely just namespaces to start
> with, and if you want to use them solely for that purpose, it's all
> there for you.  If you wanted to make you intention even more
> obviously, you could do something like:
> 
>>>> class NoInstance(object):
> ...     def __new__(cls):
> ...         raise NotImplementedError
> ...
>>>> class signin(NoInstance):
> ...     def handle(*args):
> ...         print("Hello", args)
> ...
>>>> signin()
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 3, in __new__
> NotImplementedError
>>>> signin.handle('some','args','here')
> Hello ('some', 'args', 'here')
> 
> Maybe some other name than NoInstance would be better: NamespaceOnly?
> In any case, one helper class lets you use existing syntax exactly as
> you desire.
> 
> On Tue, Sep 16, 2014 at 10:43 PM, Tennessee Leeuwenburg
> <tleeuwenburg at gmail.com> wrote:
>> Hi Ali,
>> 
>> Thanks for the suggestion. I would prefer to avoid that just because it's a
>> potential misuse of classes, and I suspect may lead to confusion for other
>> developers. Otherwise that's exactly what I want to do.
>> 
>> Cheers,
>> -T
>> 
>> On 17 September 2014 15:27, Ali Alkhatib <al2 at stanford.edu> wrote:
>>> 
>>> This may be a misuse of classes, but why can't you make a class and then
>>> not instantiate it?
>>> 
>>>    class signin:
>>>        def handle():
>>>            return "this works"
>>> 
>>>    signin.handle() # returns "this works"
>>> 
>>> On Tue, Sep 16, 2014 at 10:19 PM, Tennessee Leeuwenburg
>>> <tleeuwenburg at gmail.com> wrote:
>>>> 
>>>> I would like to be able to use named sections to organise my code, much
>>>> an inline submodules, bit without using classes or functions to organise
>>>> them. I would use this if I had a group of related functions which were not
>>>> written in an object-oriented-style, possibly due to not needing any shared
>>>> state. Rather than break these out into a new file, I would like to just be
>>>> able to use internal structure to declare the relationship. I've used the
>>>> keyword 'block' to indicate the start of a named block.
>>>> 
>>>> For example,
>>>> 
>>>> block signin:
>>>>     def handle_new_user():
>>>>           do_it()
>>>> 
>>>>     def handle_existing_user():
>>>>           do_it()
>>>> 
>>>> 
>>>> while True:
>>>>    try:
>>>>        signin.handle_existing_user():
>>>>    except:
>>>>        signin.handle_new_user()
>>>> 
>>>>    do_other_stuff()
>>>> 
>>>> At the moment, I would have to either break out into more files, or
>>>> somewhat clumsily co-opt things like functions or staticmethods. I think
>>>> that supporting named blocks or inline module declarations would really help
>>>> me organise some of my code much better. It could also provide a more
>>>> seamless way to decide to break out into a new file. Once a named block got
>>>> big enough, I could easily create a new file and import those functions into
>>>> the same namespace.
>>>> 
>>>> I hope this makes sense and that I'm not overlooking anything obvious.
>>>> 
>>>> Cheers,
>>>> -Tennessee
>>>> 
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas at python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Ali Alkhatib
>>> Department of Computer Science
>>> PhD Student - Stanford University
>> 
>> 
>> 
>> 
>> --
>> --------------------------------------------------
>> Tennessee Leeuwenburg
>> http://myownhat.blogspot.com/
>> "Don't believe everything you think"
>> 
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 
> -- 
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list