Re: Namespaces are one honking great idea

Hi all, although it doesn't fit the bill 100%, I sometimes use this extremely simple function as a decorator: def new(call): return call() For example: @new class MySingleton: x = 2 y = 2 def sum(self, x, y): return x + y @new def my_obj(): x = 2 y = 2

A nestedmodule decorator (Re: Namespaces are one honking great idea)

Steven D'Aprano wrote: There's only so far I can go without support from the compiler. It turns out one can go surprisingly far. Here's something I cooked up that seems to meet almost all the requirements. The only shortcoming I can think of is that a nestedmodule inside another nestedmodule

Re: Namespaces are one honking great idea

On Tuesday 05 July 2016 13:47, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote: >>> If you push your code into a separate .py file, you can reference the >>> original module by importing it. Is that also the normal way to use >>> "outer"

Re: Namespaces are one honking great idea

On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote: >> If you push your code into a separate .py file, you can reference the >> original module by importing it. Is that also the normal way to use >> "outer" functions etc from inside a namespace? > > Good question! > > With

Re: Namespaces are one honking great idea

On Tue, 5 Jul 2016 12:58 pm, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano > wrote: >> *** IF *** you are willing to push the code out into its own separate .py >> file, you can use a module and write your code in a more natural form: >> >> >> #

Re: Namespaces are one honking great idea

On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano wrote: > *** IF *** you are willing to push the code out into its own separate .py > file, you can use a module and write your code in a more natural form: > > > # module example.py > var = 999 > > def spam(arg): > return

Re: Namespaces are one honking great idea

On Mon, 4 Jul 2016 09:23 pm, jmp wrote: > On 07/01/2016 04:13 PM, Steven D'Aprano wrote: >> But classes are not like the others: they must be instantiated before >> they can be used, and they are more than just a mere namespace grouping >> related entities. Classes support inheritance. Classes

Re: Namespaces are one honking great idea

On Tuesday, July 5, 2016 at 10:10:04 AM UTC+12, I wrote: > > On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > > > Functions within the namespace can't call other functions within the > > same namespace using unqualified names. This was a stated requirement. > > Doesn’t my

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > Functions within the namespace can't call other functions within the > same namespace using unqualified names. This was a stated requirement. Doesn’t my @namespace decorator provide that? --

Re: Namespaces are one honking great idea

On 07/04/2016 01:37 PM, Chris Angelico wrote: On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote: On 07/01/2016 04:13 PM, Steven D'Aprano wrote: But classes are not like the others: they must be instantiated before they can be used, and they are more than just a mere namespace

Re: Namespaces are one honking great idea

On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote: > On 07/01/2016 04:13 PM, Steven D'Aprano wrote: >> >> But classes are not like the others: they must be instantiated before they >> can be used, and they are more than just a mere namespace grouping related >> entities. Classes

Re: Namespaces are one honking great idea

On 07/01/2016 04:13 PM, Steven D'Aprano wrote: But classes are not like the others: they must be instantiated before they can be used, and they are more than just a mere namespace grouping related entities. Classes support inheritance. Classes should be used for "is-a" relationships, not "has-a"

Re: Namespaces are one honking great idea

On 07/03/2016 03:02 PM, Kevin Conway wrote: >At some point earlier Ethan Furman declared: It's not a language change. Perhaps. My argument is that anything that introduces a new class-like construct and set of lexical scoping rules is a language change. For example, if this change went into

Re: Namespaces are one honking great idea

On 04/07/2016 00:21, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: If the problem with using classes to satisfy the namespace need is that it's unwieldy to use dot qualified paths then isn't that quite similar to saying namespaces are unwieldy?

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: > If the problem with using classes to satisfy the namespace need is > that it's unwieldy to use dot qualified paths then isn't that quite similar > to saying namespaces are unwieldy? Python has a simple solution to that: a =

Re: Namespaces are one honking great idea

>> Regardless, all use cases you've listed are already satisfied by use of >> the static and class method decorators. Methods decorated with these do >> not require an instance initialization to use. > And are significantly less easy to use, as the functions MUST refer to each > other by their

Re: Namespaces are one honking great idea

On 07/02/2016 08:44 PM, Steven D'Aprano wrote: Try getting this behaviour from within a class: class Food(metaclass=Namespace): # (1) no special decorators required def spam(n): return ' '.join(['spam']*n) # (2) can call functions from inside the namespace

Re: Namespaces are one honking great idea

On Sun, 3 Jul 2016 01:34 am, Kevin Conway wrote: > staticmethod isn't technically required to use a method through the class > (or subclasses), it simply provides the appropriate magic to allow it to > be called through instances. > > For example, the following code covers all described use

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 11:50 am, Kevin Conway wrote: > I believe the namespace object you are referring to is exactly a class. Yes, a namespace is exactly like a class, minus inheritance, instantiation, the implied "is-a" relationship, and the whole Java "utility class" anti-pattern. In other

Re: Namespaces are one honking great idea

On 07/02/2016 08:34 AM, Kevin Conway wrote: For the proponents of namespace, what is deficient in the above example that necessitates a language change? Adding a new widget is not changing the language. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

> staticmethod isn't technically required to use a method through the class (or subclasses), it simply provides the appropriate magic to allow it to be called through instances. For example, the following code covers all described use cases of the proposed namespace. Methods are invoked without

Re: Namespaces are one honking great idea

On Fri, Jul 1, 2016, at 21:50, Kevin Conway wrote: > I believe the namespace object you are referring to is exactly a > class. IIRC, classes came about as a "module in a module". No, because classes have instances. And conceptually they seem like they *should* have instances. Just using the term

Re: Namespaces are one honking great idea

On Saturday, July 2, 2016 at 1:50:56 PM UTC+12, Kevin Conway wrote: > Regardless, all use cases you've listed are already satisfied by use of the > static and class method decorators. Except for the need to decorate every such function inside the class. How about: import types def

Re: Namespaces are one honking great idea

On Friday, July 1, 2016 at 8:19:36 PM UTC+5:30, BartC wrote: > On 01/07/2016 15:13, Steven D'Aprano wrote: > > > Sometimes we have a group of related functions and variables that belong > > together, but are not sufficiently unrelated to the rest of the module that > > we want to split them out

Re: Namespaces are one honking great idea

I believe the namespace object you are referring to is exactly a class. IIRC, classes came about as a "module in a module". Regardless, all use cases you've listed are already satisfied by use of the static and class method decorators. Methods decorated with these do not require an instance

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 05:29 am, Ethan Furman wrote: > On 07/01/2016 10:10 AM, Steven D'Aprano wrote: >> On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: > >>> Did you mean for this to go to -Ideas? >> >> Not yet. I wanted some initial feedback to see if anyone else liked the >> idea before taking

Re: Namespaces are one honking great idea

On 07/01/2016 10:10 AM, Steven D'Aprano wrote: On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: Did you mean for this to go to -Ideas? Not yet. I wanted some initial feedback to see if anyone else liked the idea before taking it to Bikeshedding Central :-) Besides, I expect Python-Ideas

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 12:49 am, BartC wrote: > On 01/07/2016 15:13, Steven D'Aprano wrote: > >> Sometimes we have a group of related functions and variables that belong >> together, but are not sufficiently unrelated to the rest of the module >> that we want to split them out into another file. >

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: > On 07/01/2016 07:13 AM, Steven D'Aprano wrote: > > I like the idea, but I have a couple questions about the design choices. Thanks! > Comments below. [...] >> Despite the "class" statement (a limitation of Python's lack of dedicated >>

Re: Namespaces are one honking great idea

On Sat, Jul 2, 2016 at 12:49 AM, BartC wrote: > Why not just extend the capabilities of a class? I actually thought this > would work until I tried it and it didn't: > > class C(): > def fn(): > print ("Hi!") > > C.fn() > > The error message suggests Python knows

Re: Namespaces are one honking great idea

On 07/01/2016 07:13 AM, Steven D'Aprano wrote: I like the idea, but I have a couple questions about the design choices. Comments below. The Zen of Python says: Namespaces are one honking great idea -- let's do more of those! Proposal = Add a new "namespace&qu

Re: Namespaces are one honking great idea

On 01/07/2016 15:13, Steven D'Aprano wrote: Sometimes we have a group of related functions and variables that belong together, but are not sufficiently unrelated to the rest of the module that we want to split them out into another file. Here's a proof of concept. I use a class with a custom

Re: Namespaces are one honking great idea

On Fri, Jul 1, 2016, at 10:13, Steven D'Aprano wrote: > The biggest limitation is that I have to abuse the class statement to do > this. In an ideal world, there would be syntactic support and a keyword: > > namespace Example: > x = 0 > y = [] > def test(n): ... > >

Namespaces are one honking great idea

The Zen of Python says: Namespaces are one honking great idea -- let's do more of those! Proposal = Add a new "namespace" object to Python. Rationale == Sometimes we have a group of related functions and variables that belong together, but are not sufficiently