[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 5:25 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > > > I would personally love for SimpleNamespace to get a shorter name > > > and become a built-in. > > > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > > builtin, what should its name be? It needs to be short (obviously), > > but not TOO short, > > "It". Too bad about the "not TOO short" requirement, you can't always > get what you want, but if you try sometime :-) As someone who's worked in IT all my life, I should have seen that one coming :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S5XCTSH6PIMG4GGSHEOSJ6ENOLZ6CFW6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
Chris Angelico writes: > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > I would personally love for SimpleNamespace to get a shorter name > > and become a built-in. > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > builtin, what should its name be? It needs to be short (obviously), > but not TOO short, "It". Too bad about the "not TOO short" requirement, you can't always get what you want, but if you try sometime :-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WNUGYEX326RQIRQ6EP3ARS6E5FAZ7KES/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
Abdulla Al Kathiri writes: > How is this not pythonic? > > series.apply(x -> x**2) > Compared to.. > series.apply(lambda x: x**2) The main problem is that the second already exists, and the first doesn't, while the first adds no new power to the language, and isn't enough more readable (and some would argue less readable, expecially in the multiple "lots of irritating parentheses" form) than the "lambda" version. While it's not a good idea to take the Zen too seriously, "There should be one-- and preferably only one --obvious way to do it." is often good advice. "Although that way may not be obvious at first unless you're Dutch." means that often that way must be taught to most developers, with "lambda" being an extreme case since very few of us come from the Lisp, Haskell, or Mathematical Logic worlds any more, so references to lambda are infrequent. A small issue is that with a different value, "f(x -> V)" is also possibly a typo for "f(x) -> V", and likely to occur if you have automagic parenthesis matching in your editor. In general, Python's designers prefer (and try to encourage) a style emphasizing building up complex applications from relatively small *named* functions, rather than large monolithic blocks of code. Random's cavil about warty keywords notwithstanding, I kinda like my idea of using a "def expression" to pass a local function as a keyword argument. I wouldn't be surprised if Guido pops up to say "I thought of that in 1998, but it was too cute by half", though. :-) One could argue that this fits the typical human brain well, with its ability to handle chunked data in groups of 7 +/- 2 items. It's unarguable that Python has become very popular, and that its fans are quite devoted to it. Something about this style is capturing them! I don't speak for Guido or any other authoritative voices, that's just my take. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OQMNNXJZR67SHPCJZ7YJ42ZQY26OVIWB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 1:59 PM Ben Rudiak-Gould wrote: > > On Wed, Feb 17, 2021 at 6:12 PM Chris Angelico wrote: >> >> But if object() could get arbitrary attributes, then __slots__ wouldn't work. > > > It seems to me that all you'd have to do is add a line or two to the add_dict > logic in type_new so that instances of object get a dict. Then instances of > object would get a dict, and nothing else would change. > > In languages like C++ where an instance of a class contains actual in-memory > instances of all of its superclasses, that wouldn't work. In Python, where > instances of different classes have a priori nothing to do with each other, I > think it would work. > Even if it's possible, though, it's a fairly significant breach of Liskov. And I don't know that other Python implementations would be able to do this so cleanly. What's so hard about using a different type? Especially since the vanilla object repr is basically useless, but SimpleNamespace can tell you what it's carrying. Orthogonal point: SimpleNamespace could easily be made JSON-serializable (as a dict), if that would be of value. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MD6ZZW6GYKJXI6VNWRJ6HU4RAT44UANK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Wed, Feb 17, 2021 at 6:12 PM Chris Angelico wrote: > But if object() could get arbitrary attributes, then __slots__ wouldn't > work. > It seems to me that all you'd have to do is add a line or two to the add_dict logic in type_new so that instances of object get a dict. Then instances of object would get a dict, and nothing else would change. In languages like C++ where an instance of a class contains actual in-memory instances of all of its superclasses, that wouldn't work. In Python, where instances of different classes have a priori nothing to do with each other, I think it would work. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2R4FMO5UH6MFTS25BRNJJQB34DKMAZHI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 1:00 PM Christopher Barker wrote:
>
> > On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
>>
>> >> Still think that "object()" should be writable since this seems like an
>> >> arbitrary restriction
>
> ...
>>
>> But I guess there's been discussion around this already.
>
>
> > ... but changing object would be problematic.
>
> Well, yes, due to backward compatibility -- though how much code is counting
> on not being able to add attributes to an instance of object?
>
> I think someone on this thread (sorry can't find it now) said something like:
>
> if you could add attributes to object(), then you'd be able to add attributes
> to subclasses of object. -- but you can already:
>
> Isn't every class a subclass of object?
>
> class C:
> pass
You can add attributes to THIS subclass of object. But you can't add
attributes to EVERY subclass of object. For instance:
x = 1
x.something = 123
If object() could have attributes added, then 1 would have to be able
to have attributes added too. And that would cause all manner of
problems.
> It seems the difference is that both a new class and class instances get a
> __dict__. But given that all classes derive from object, and object is of
> type type, and classes are of type type -- I still have no idea why we can't
> add things to an instance of object.
>
When you create a class as you did above, it gets a __dict__. But if
you set __slots__, the only valid attributes are those listed in the
slots. These are inherited:
>>> class X: __slots__ = 'a', 'b'
...
>>> class Y(X): __slots__ = 'q', 'w'
...
>>> Y.__slots__
('q', 'w')
>>> Y().a = 1
>>> Y().q = 1
>>> Y().z = 1
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Y' object has no attribute 'z'
But if object() could get arbitrary attributes, then __slots__ wouldn't work.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2PQGNNDNE7WDVQWFK7HCFXX26M4ZROAV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote: > >> Still think that "object()" should be writable since this seems like an > >> arbitrary restriction ... > But I guess there's been discussion around this already. > > ... but changing object would be problematic. Well, yes, due to backward compatibility -- though how much code is counting on not being able to add attributes to an instance of object? I think someone on this thread (sorry can't find it now) said something like: if you could add attributes to object(), then you'd be able to add attributes to subclasses of object. -- but you can already: Isn't every class a subclass of object? class C: pass C.this = "something" c = C() c.that = "something else" It seems the difference is that both a new class and class instances get a __dict__. But given that all classes derive from object, and object is of type type, and classes are of type type -- I still have no idea why we can't add things to an instance of object. I suppose adding stuff to the object class itself would be very weird -- as that would mess with ALL classes. But adding to an instance of object? why not? -Chris B -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SZJB5K4ADOM5RXKXCYBFV5RAJI22SG3Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Wed, Feb 17, 2021, 6:20 PM Daniel Moisset wrote: > If we're bike shedding, I'd go for "mutableobject". It's not terribly > short, but it is built on familiar python terminology and does exactly what > it says in the box: like object() but mutable > That is a pretty good suggestion. I'd like it to be shorter though. mobject? > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7I3QDQQZ5OVT7PGSY3Q7TNMDH6ZDXGSY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
Why is this a discussion?! Just start your program with: from types import SimpleNamespace as myfavname On Wed, Feb 17, 2021 at 11:22 PM Daniel Moisset wrote: > If we're bike shedding, I'd go for "mutableobject". It's not terribly > short, but it is built on familiar python terminology and does exactly what > it says in the box: like object() but mutable > > On Wed, 17 Feb 2021, 23:01 Chris Angelico, wrote: > >> On Thu, Feb 18, 2021 at 8:53 AM Brendan Barnwell >> wrote: >> > >> > On 2021-02-17 11:21, Chris Angelico wrote: >> > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a >> > > builtin, what should its name be? It needs to be short (obviously), >> > > but not TOO short, and it needs to be at least somewhat descriptive, >> > > and it needs to not cause confusion with "object". Ideally, it should >> > > get a name that's unlikely to conflict with names already in frequent >> > > use. >> > > >> > > * namespace >> > > * ns >> > > * Thing >> > > * dump >> > > * plunkit >> > >> > Does using SimpleNamespace have any other meaningful >> ramifications >> > besides being able to add attributes? When I see people suggest >> > SimpleNamespace, it's usually just to use it as a dict which is accessed >> > with attribute syntax instead of item syntax. Given that, I think a >> > name like `attrdict` would be appropriate. (There is already a PyPI >> > package called attrdict that uses this name for this purpose: >> > https://pypi.org/project/attrdict/ , And I feel like I've seen other >> > examples of similar names where someone wrote their own >> > mini-implementation of such a thing.) >> >> The main thing it has is a very useful repr, but that doesn't conflict >> with the name attrdict. >> >> ChrisA >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/BNXRZJIVFB23M6X374MP24GI7CPMOFSU/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VZ7ZAX443EXVGIZ75XCVL6B6EB7F7NLY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XCNQ7ZSM6BSHQVFKU4UCI2DAVSKU324K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
If we're bike shedding, I'd go for "mutableobject". It's not terribly short, but it is built on familiar python terminology and does exactly what it says in the box: like object() but mutable On Wed, 17 Feb 2021, 23:01 Chris Angelico, wrote: > On Thu, Feb 18, 2021 at 8:53 AM Brendan Barnwell > wrote: > > > > On 2021-02-17 11:21, Chris Angelico wrote: > > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > > > builtin, what should its name be? It needs to be short (obviously), > > > but not TOO short, and it needs to be at least somewhat descriptive, > > > and it needs to not cause confusion with "object". Ideally, it should > > > get a name that's unlikely to conflict with names already in frequent > > > use. > > > > > > * namespace > > > * ns > > > * Thing > > > * dump > > > * plunkit > > > > Does using SimpleNamespace have any other meaningful > ramifications > > besides being able to add attributes? When I see people suggest > > SimpleNamespace, it's usually just to use it as a dict which is accessed > > with attribute syntax instead of item syntax. Given that, I think a > > name like `attrdict` would be appropriate. (There is already a PyPI > > package called attrdict that uses this name for this purpose: > > https://pypi.org/project/attrdict/ , And I feel like I've seen other > > examples of similar names where someone wrote their own > > mini-implementation of such a thing.) > > The main thing it has is a very useful repr, but that doesn't conflict > with the name attrdict. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BNXRZJIVFB23M6X374MP24GI7CPMOFSU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VZ7ZAX443EXVGIZ75XCVL6B6EB7F7NLY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 8:53 AM Brendan Barnwell wrote: > > On 2021-02-17 11:21, Chris Angelico wrote: > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > > builtin, what should its name be? It needs to be short (obviously), > > but not TOO short, and it needs to be at least somewhat descriptive, > > and it needs to not cause confusion with "object". Ideally, it should > > get a name that's unlikely to conflict with names already in frequent > > use. > > > > * namespace > > * ns > > * Thing > > * dump > > * plunkit > > Does using SimpleNamespace have any other meaningful ramifications > besides being able to add attributes? When I see people suggest > SimpleNamespace, it's usually just to use it as a dict which is accessed > with attribute syntax instead of item syntax. Given that, I think a > name like `attrdict` would be appropriate. (There is already a PyPI > package called attrdict that uses this name for this purpose: > https://pypi.org/project/attrdict/ , And I feel like I've seen other > examples of similar names where someone wrote their own > mini-implementation of such a thing.) The main thing it has is a very useful repr, but that doesn't conflict with the name attrdict. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BNXRZJIVFB23M6X374MP24GI7CPMOFSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
I agree, I don't think it justifies a builtin, because it is so simple to just define your own empty class. That said, it does come in handy, and I do use it for same reasons others have expressed. On Thu, 2021-02-18 at 11:50 +1300, Greg Ewing wrote: > On 18/02/21 3:51 am, Ricky Teachey wrote: > > I would personally love for SimpleNamespace to get a shorter name > > and > > become a built-in. It is a fantastic object to use in all kinds of > > situations > > I find myself disagreeing with that. It's dead simple to define > your own blank-object class, and you get to give it a name that > reflects what you're really doing with it. I don't understand > why there's such a fascination with things like SimpleNamespace. > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EMKHIVA27CVGVDJPJHQ4O2BY6IZXDWRN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On 18/02/21 3:38 am, MRAB wrote: So a "byte" is part of a word (a word contains multiple characters). In the Burroughs B6900 architecture, programs consisted of 48-bit words broken up into 8-bit opcodes called "syllables". -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PCD2BLQSUX2AQY43PFFCEQTOILFLSYX4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On 18/02/21 3:51 am, Ricky Teachey wrote: I would personally love for SimpleNamespace to get a shorter name and become a built-in. It is a fantastic object to use in all kinds of situations I find myself disagreeing with that. It's dead simple to define your own blank-object class, and you get to give it a name that reflects what you're really doing with it. I don't understand why there's such a fascination with things like SimpleNamespace. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RJW5NN24QHCQ5D32HAGUWSVM747Y7ZPT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
Those are not anonymous functions though. > On 18 Feb 2021, at 1:43 AM, Joao S. O. Bueno wrote: > > def f1(x, y): >return x + y > > def f2(): > return 0 > > def f3(x): >return x ** 2 > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S2BT2WJ5GX3MFGCY5YK2D6DWIAA7V3NW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On 2021-02-17 11:21, Chris Angelico wrote: Okay. Let's start bikeshedding. If SimpleNamespace were to become a builtin, what should its name be? It needs to be short (obviously), but not TOO short, and it needs to be at least somewhat descriptive, and it needs to not cause confusion with "object". Ideally, it should get a name that's unlikely to conflict with names already in frequent use. * namespace * ns * Thing * dump * plunkit Does using SimpleNamespace have any other meaningful ramifications besides being able to add attributes? When I see people suggest SimpleNamespace, it's usually just to use it as a dict which is accessed with attribute syntax instead of item syntax. Given that, I think a name like `attrdict` would be appropriate. (There is already a PyPI package called attrdict that uses this name for this purpose: https://pypi.org/project/attrdict/ , And I feel like I've seen other examples of similar names where someone wrote their own mini-implementation of such a thing.) -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7EURJ5E74GL7FEGYKC3DYR77PWMZ7KEZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri < alkathiri.abdu...@gmail.com> wrote: > How is this not pythonic? > > series.apply(x -> x**2) > Compared to.. > series.apply(lambda x: x**2) > > > (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can write it > without parenthesis like the example above) are pythonic enough to my eyes. > Well, for m eyes, the above is definetellly "perlonic" . it could be "j" before being Pyrhon. This is Pythonic: def f1(x, y): return x + y def f2(): return 0 def f3(x): return x ** 2 And it took me a while looking at our example to check it was not really fuction composition with default parameters, or what. I mentioned violation of 6 of the first 7 phrases in the famous "zen of Python" - most important of which can be reasonably agreed is the 7th: "Readability counts". If you don't want readability at all in exchange for typing a few keywords (which more and more automatic tools can auto-complete), I'd suggest going for the "forth" language. Abdulla > > On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno > wrote: > > If someone comes with a "pythonic" way to lift restrictions on > lambda, that could be something for debate, but so far this is > just about uglifying it, and creating a new syntax matching > exactly what exists today. > > > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GL4TPNMIDZTH63WO6E6QNZX57NGYZH2L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
How is this not pythonic? series.apply(x -> x**2) Compared to.. series.apply(lambda x: x**2) (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can write it without parenthesis like the example above) are pythonic enough to my eyes. Abdulla > On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno wrote: > > If someone comes with a "pythonic" way to lift restrictions on > lambda, that could be something for debate, but so far this is > just about uglifying it, and creating a new syntax matching > exactly what exists today. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EK62X73EIH776XGDWUWSN4GWFXDEFD22/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Wed, Feb 17, 2021 at 2:32 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2021-02-18 at 06:21:19 +1100, > Chris Angelico wrote: > > > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > > > > > I would personally love for SimpleNamespace to get a shorter name and > become a built-in. > > > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > > builtin, what should its name be? It needs to be short (obviously), > > but not TOO short, and it needs to be at least somewhat descriptive, > > and it needs to not cause confusion with "object". Ideally, it should > > get a name that's unlikely to conflict with names already in frequent > > use. > > > > * namespace > > * ns > > * Thing > > * dump > > * plunkit > > > > I'm not a fan of any of those, but let's see how inspired other people > are :) > > stuff (thank you, George Carlin!) > bag > > Using a initial lower case letter makes it feel more built in, at the > expense of likely breaking more existing code. Using an initial capital > letter makes it feel more like a class, which may or may not be a good > thing. > a few monty python inspired ideas that aren't likely to conflict with much existing code: * circus * parrot * swallow * nudge * grail * patsy --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O4CEXVY6LIICXH6YTB4GEKJEAU7A57UO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On 2021-02-18 at 06:21:19 +1100, Chris Angelico wrote: > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > > > I would personally love for SimpleNamespace to get a shorter name and > > become a built-in. > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > builtin, what should its name be? It needs to be short (obviously), > but not TOO short, and it needs to be at least somewhat descriptive, > and it needs to not cause confusion with "object". Ideally, it should > get a name that's unlikely to conflict with names already in frequent > use. > > * namespace > * ns > * Thing > * dump > * plunkit > > I'm not a fan of any of those, but let's see how inspired other people are :) stuff (thank you, George Carlin!) bag Using a initial lower case letter makes it feel more built in, at the expense of likely breaking more existing code. Using an initial capital letter makes it feel more like a class, which may or may not be a good thing. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GFEWKTMWR5VJJSH2LP6XC2CLBNMDRJXX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > From other thread: > > On Wed, Feb 17, 2021 at 5:19 AM Chris Angelico wrote: >> >> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote: >> > Still think that "object()" should be writable since this seems like an >> > arbitrary restriction (+SimpleNamespace is no builtin and at least I >> > would use object() for fast PoCs or dirty hackery). But I guess there's >> > been discussion around this already. >> > >> >> It can't, because subclasses of object would then ALSO be writable, >> and that would break a lot of things. Also, a lot of use-cases for >> object() just need sentinels, with no attributes, so this would cost >> them a lot of efficiency. >> >> Using SimpleNamespace is the best way to do this, and maybe there's a >> good argument for making it a builtin (or at least giving it a shorter >> name), but changing object would be problematic. >> >> ChrisA > > > I would personally love for SimpleNamespace to get a shorter name and become > a built-in. > Okay. Let's start bikeshedding. If SimpleNamespace were to become a builtin, what should its name be? It needs to be short (obviously), but not TOO short, and it needs to be at least somewhat descriptive, and it needs to not cause confusion with "object". Ideally, it should get a name that's unlikely to conflict with names already in frequent use. * namespace * ns * Thing * dump * plunkit I'm not a fan of any of those, but let's see how inspired other people are :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VLBT4CSR4K2ZGHSECL5W3HUDO4R37LKK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, 17 Feb 2021 at 18:30, Ethan Furman wrote: > On 2/17/21 8:47 AM, Random832 wrote: > > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > > >> except a couple of characters. So what currently looks like > >> > >> some_list.sort(key=lambda e: e[3].priority) > >> > >> would then be > >> > >> some_list.sort(key=(e)->e[3].priority) > > > > Let's not pretend the key argument being keyword-only isn't a wart. > Surely this would be better if it could be some_list.sort(e->e[3].priority). > > No need to pretend, it isn't a wart. > > -1 on removing the lambda keyword. Just because excessive punctuation > works for other languages does not mean it's a good fit for Python. > Just my 2c, I don't find lambda verbose at all, quite like it. But I wish Python allowed for multi-line lambda functions... somehow. Why? If you need to have a callback function that takes 2 to 5 lines of code, then (1) current lambda doesn't allow it, (2) inline named function, defined earlier, is too verbose IMHO (code style dictates it needs two blank lines, one before, one after, plus need to have a name), and also somewhat breaks the flow of reading code. A multi-line lambda would be able to fill the gap, between too big for single line lambda, but too small to justify its own def xxx(). Sorry, I don't have any concrete proposal, just a vague wish. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PSWFL5AQLWAQSDJA2M2IMZBUPQGCL5NB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, 17 Feb 2021 at 15:31, Ethan Furman wrote: > On 2/17/21 8:47 AM, Random832 wrote: > > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > > >> except a couple of characters. So what currently looks like > >> > >> some_list.sort(key=lambda e: e[3].priority) > >> > >> would then be > >> > >> some_list.sort(key=(e)->e[3].priority) > > > > Let's not pretend the key argument being keyword-only isn't a wart. > Surely this would be better if it could be some_list.sort(e->e[3].priority). > > No need to pretend, it isn't a wart. > > -1 on removing the lambda keyword. Just because excessive punctuation > works for other languages does not mean it's a good fit for Python. > > Indeed - I think typing `import this` is enough to see that this change would directly contradict 6 of the first 7 guidelines in the zen. If someone comes with a "pythonic" way to lift restrictions on lambda, that could be something for debate, but so far this is just about uglifying it, and creating a new syntax matching exactly what exists today. Moreover I'd like to remind people so much worried about expressiveness in less and less characters that Lambda is much less needed in Python than in similar languages due to the existence of the comprehensions and generator expression constructs. The energy spent here could be focused instead on having an equivalent of comprehensions for "reduce", for example. > -- > ~Ethan~ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/IU7DEE5WZFWDKFDPUZAYCV5DPGFGSAJK/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/POJMDVA5WPCOXJUHCQPPK5ZE6ZW6GOXM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On 2/17/21 8:47 AM, Random832 wrote: On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: except a couple of characters. So what currently looks like some_list.sort(key=lambda e: e[3].priority) would then be some_list.sort(key=(e)->e[3].priority) Let's not pretend the key argument being keyword-only isn't a wart. Surely this would be better if it could be some_list.sort(e->e[3].priority). No need to pretend, it isn't a wart. -1 on removing the lambda keyword. Just because excessive punctuation works for other languages does not mean it's a good fit for Python. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IU7DEE5WZFWDKFDPUZAYCV5DPGFGSAJK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > except a couple of characters. So what currently looks like > > some_list.sort(key=lambda e: e[3].priority) > > would then be > > some_list.sort(key=(e)->e[3].priority) Let's not pretend the key argument being keyword-only isn't a wart. Surely this would be better if it could be some_list.sort(e->e[3].priority). > which is shorter but not particularly more readable (and already has a > familiar meaning in C-like languages). this side point is an argument in favor of using => instead. [and if => can be confused with >=, surely so can -> be confused with >-] > 1. In a one-line def of the form "def foo([arglist]): return EXPR", > "return" may be omitted, and the function returns the value of > EXPR (rather than None as currently). (As a multiline def, EXPR > would be presumed to be evaluated for side effects, and I would like something like this - it's worth noting that C# [and as someone helpfully pointed out, Dart] uses => for this case as well, and the argument about the syntax looking bad when a return type annotation is present is, I think, overblown - return type annotations are almost never needed for a function with a single return statement. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BHH7EIXT7KSFMBGTSGG6VKWKD55Y2TE4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
>From other thread:
On Wed, Feb 17, 2021 at 5:19 AM Chris Angelico wrote:
> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
> > Still think that "object()" should be writable since this seems like an
> > arbitrary restriction (+SimpleNamespace is no builtin and at least I
> > would use object() for fast PoCs or dirty hackery). But I guess there's
> > been discussion around this already.
> >
>
> It can't, because subclasses of object would then ALSO be writable,
> and that would break a lot of things. Also, a lot of use-cases for
> object() just need sentinels, with no attributes, so this would cost
> them a lot of efficiency.
>
> Using SimpleNamespace is the best way to do this, and maybe there's a
> good argument for making it a builtin (or at least giving it a shorter
> name), but changing object would be problematic.
>
> ChrisA
I would personally love for SimpleNamespace to get a shorter name and
become a built-in. It is a fantastic object to use in all kinds of
situations and if it were given the same status as dict, tuple, etc etc,
many more people would benefit from it. Right now it is pretty obscure and
you could use python for years and not know about it. I think all but the
most casual of python users at least end up on the built-in webpage at
least once, clicking through to read about the different built-ins and what
they are for.
Rick.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Wed, Feb 17, 2021 at 9:46 AM Sven R. Kunze wrote:
> Starting this as a new thread for the interested reader:
>
> On 17.02.21 11:18, Chris Angelico wrote:
> > On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
> >> Still think that "object()" should be writable since this seems like an
> >> arbitrary restriction (+SimpleNamespace is no builtin and at least I
> >> would use object() for fast PoCs or dirty hackery). But I guess there's
> >> been discussion around this already.
> >>
> [...]
>
> > Using SimpleNamespace is the best way to do this, and maybe there's a
> > good argument for making it a builtin (or at least giving it a shorter
> > name), but changing object would be problematic.
>
> I would be skeptical that either those ideas would help a lot. My
> reasoning is the following:
>
>
> Given the usual terminology in computer science and programming courses,
> we think in "objects". "Namespaces" on the other side are quite static,
> usual representing surroundings or environments which in turn can
> contain "objects". Sadly, the terminology-wise ideal solution is blocked
> by technical reasons.
>
>
> The thinking in the concepting use-case goes like "I need a blank object
> which I can do random things with" (yes, including attaching new
> attributes to it, maybe other stuff as well).
>
> The thinking "hey I need a (simple) namespace which I can attach
> attributes to" requires quite some thoughts especially when being in a
> more "concepting"/"trying out ideas" mood.
>
> In this phase, one does not simply know what one needs ("could be
> sentinel only", "could be data carrying", "could be signalling", "could
> something else") and things move quickly.
>
>
> So, just as an example when renaming/aliasing "types.SimpleNamespace" to
> "builtins.thing", my expectation would be that people could be horribly
> confused seeing "object" and "thing" being a builtin when used in a
> project simultaneously. This always leads to questions like "what to use
> now?"
>
>
> As a conclusion I would say let's leave it like it is since it's a minor
> issue.
>
>
> Best
> Sven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/3IICAAKFYPL7JETS26CHPUVRVQS7KW3Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NMRZB5Q5IBEAUZ42N5Y2PU3ZY6QMEPBY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] SimpleNamespace vs object
Starting this as a new thread for the interested reader:
On 17.02.21 11:18, Chris Angelico wrote:
On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
Still think that "object()" should be writable since this seems like an
arbitrary restriction (+SimpleNamespace is no builtin and at least I
would use object() for fast PoCs or dirty hackery). But I guess there's
been discussion around this already.
[...]
Using SimpleNamespace is the best way to do this, and maybe there's a
good argument for making it a builtin (or at least giving it a shorter
name), but changing object would be problematic.
I would be skeptical that either those ideas would help a lot. My
reasoning is the following:
Given the usual terminology in computer science and programming courses,
we think in "objects". "Namespaces" on the other side are quite static,
usual representing surroundings or environments which in turn can
contain "objects". Sadly, the terminology-wise ideal solution is blocked
by technical reasons.
The thinking in the concepting use-case goes like "I need a blank object
which I can do random things with" (yes, including attaching new
attributes to it, maybe other stuff as well).
The thinking "hey I need a (simple) namespace which I can attach
attributes to" requires quite some thoughts especially when being in a
more "concepting"/"trying out ideas" mood.
In this phase, one does not simply know what one needs ("could be
sentinel only", "could be data carrying", "could be signalling", "could
something else") and things move quickly.
So, just as an example when renaming/aliasing "types.SimpleNamespace" to
"builtins.thing", my expectation would be that people could be horribly
confused seeing "object" and "thing" being a builtin when used in a
project simultaneously. This always leads to questions like "what to use
now?"
As a conclusion I would say let's leave it like it is since it's a minor
issue.
Best
Sven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3IICAAKFYPL7JETS26CHPUVRVQS7KW3Y/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On 2021-02-17 05:57, Steven D'Aprano wrote: On Wed, Feb 17, 2021 at 11:13:08AM +1300, Greg Ewing wrote: On 17/02/21 7:10 am, Steven D'Aprano wrote: >"It's Greek letter, like pi that you may remember from maths >class. In some technical computer science, the Greek L, lambda, is used >as the symbol for functions." The most accurate answer seems to be "Because somebody made a mistake transcribing a mathematics paper many years ago." :-) Not according to Alonzo Church, who at various times has stated that it was either more or less chosen at random, or that it was derived from Whitehead and Russell's x̂ (x-hat) via ∧x to λx to make it easier for the printers. Either way it wasn't a mistake, but a deliberate choice. It is really remarkable how much attention lambda gets. As far as I know, mathematicians don't ask why Hilbert chose epsilon for his epsilon calculus, and nobody ever asks where "byte" comes from. It is, apparently, a deliberate misspelling of bite, to avoid it being accidently changed to bit. But why *bite*? The first published use of "byte" apparently was in a 1956 IBM memo by Werner Buchholz: "[…] Most important, from the point of view of editing, will be the ability to handle any characters or digits, from 1 to 6 bits long. Figure 2 shows the Shift Matrix to be used to convert a 60-bit word, coming from Memory in parallel, into characters, or 'bytes' as we have called them, to be sent to the Adder serially." The memo already shows that Buchholz and IBM were thinking of multiple bits being a "word", so it's not clear why bytes. There's no ordinary sense that a collection of bits (as in "a bit of stuff") is considered "a bite". It's like eating a sausage. You start at one end and take bites off it until you've eaten it all. So a "byte" is part of a word (a word contains multiple characters). Language is fun. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PGRWOZJMKJBMQ7VYY7ATXXKBVRLCISUM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote: > Still think that "object()" should be writable since this seems like an > arbitrary restriction (+SimpleNamespace is no builtin and at least I > would use object() for fast PoCs or dirty hackery). But I guess there's > been discussion around this already. > It can't, because subclasses of object would then ALSO be writable, and that would break a lot of things. Also, a lot of use-cases for object() just need sentinels, with no attributes, so this would cost them a lot of efficiency. Using SimpleNamespace is the best way to do this, and maybe there's a good argument for making it a builtin (or at least giving it a shorter name), but changing object would be problematic. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WORTQLFJZDBQYB4YTUHMNXJL6RVUPZKA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On 16.02.21 17:26, Steven D'Aprano wrote: >>> from types import SimpleNamespace >>> obj = SimpleNamespace() >>> obj.spam = 1 >>> obj namespace(spam=1) Gives you a nice repr so when you are debugging you can actually see what the object is. I see that's Python 3 (vs. Python2.7 - yeah I know, legacy code). But thanks for the remark! :-) Still think that "object()" should be writable since this seems like an arbitrary restriction (+SimpleNamespace is no builtin and at least I would use object() for fast PoCs or dirty hackery). But I guess there's been discussion around this already. Best, Sven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4BOFWAJUQZ7E5UCP7NWRRBG6YN4CSN23/ Code of Conduct: http://python.org/psf/codeofconduct/
