[Python-ideas] Re: Abstract dataclasses and dataclass fields

[Greg Ewing]

On 23/12/23 9:12 am, DL Neil via Python-ideas wrote:

On 12/23/23 02:09, Eric V. Smith via Python-ideas wrote:


You're better off discussing this on discuss.python.org as this 
mailing list is basically dead.


It can't be dead - you're here!


It's just resting!

--
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/TJQZKCJAAZWQI2BPCMBHYUYIIXBBBZZB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

[Greg Ewing]

On 23/10/23 1:36 am, Juancarlo Añez wrote:
The *re* module is a black swan, because most of stdlib raises 
exceptions on invalid arguments or not being able to deliver.


Most of the time, failure to match an re is not a programming error.
Often it's perfectly normal. Sometimes it's the result of invalid
user input, but that's the fault of the user, not the programmer.

--
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/4JNKSUTZ6ZDVHERYCNO35J2UDS5UO4CD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Greg Ewing]

On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:

result = default if bar is None else bar
or if you prefer
result = bar if bar is not None else default


Would it shut anyone up if we had another logical operator:

x otherwise y

equivalent to

x if x is not None else y

?

--
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/R55FL6U5RFMPLP6NWE4IMMLNR4OLVGTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)

[Greg Ewing]

On 18/07/23 10:30 am, Dom Grigonis wrote:
Although, the argument that python is meant to be read as english is 
very much valid, but I do not see why it has to be an overarching one if 
the opportunity cost of it is too great in other dimensions.


It's not overarching. Many things in Python don't read like English,
and nobody is suggesting changing them to be more English-like.

I think you've got it backwards here. The fact that it reads like
English is just a possible explanation of why many people find it more
readable. The fact that people (well, just Guido at that time) find it
readable is the reason it was chosen, not beause it's English-like.

--
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/ZVVK5APG2MI53UZB5NARI3FQMMLJRKCF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: yield functionality to match that of await

[Greg Ewing]

On 13/06/23 11:38 am, Chris Angelico wrote:

I think they currently use what's basically a copy of the generator
implementation. It makes sense to make resumable functions that way.


In many ways it does, although things get a bit messy
when it comes to async generators. If I were designing
something from scratch to support both, I would probably
do it a bit differently.

> (Fun fact: Pike looked at what Python was doing, and came up with a
> concept of "continue functions"

And I gather that the "async" and "await" keywords came
from C#. Languages are always stealing from each other. :-)

--
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/EG5ALWHCYE64J3UBLHAPP4DGE5PHP7GP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: yield functionality to match that of await

[Greg Ewing]

On 13/06/23 9:29 am, Dom Grigonis wrote:

Also, could anyone point me in the direction, where it is explained why new 
await/async syntax was introduced instead of making use of already existing 
yield coroutine functionality?


To my mind, the fact that coroutines use the same underlying
mechanism as generators is an implementation detail. It's
only like that for historical reasons, and it could change in
the future.

--
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/3WAC6IUUK4P3KYHIR7CNQ3HAYQV4D5CB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Warn when iterating over an already exhausted generator

[Greg Ewing]

On 13/06/23 9:59 am, Rob Cliffe via Python-ideas wrote:

Also the OP's request was for generators, not for any iterator.


IMO it would be a bad idea to make generators behave differently
from other iterators in this regard. And it's far too late to
redefine the iterator protocol in general, because that would
require changing all existing iterators and all existing code
that relies on the current behaviour.

--
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/F3P77JCXI4JYGXVXT6BWTK4BDB2BFM2F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: @lazy decorator an alternative to functools.partial ?

[Greg Ewing]

On 19/05/23 4:16 am, Christopher Barker wrote:
The problem with "batteries included" is that what exactly is a 
battery is hard to define, and everyone has a different opinion about it.


To my mind, "batteries included" means you can do *something*
useful with it out of the box. It doesn't mean you can do
*everything* you might want to do.

--
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/QAJSP3QOSWV7K7O7X6OWZVJU474OOVPQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters

[Greg Ewing]

On 29/04/23 6:59 am, Bruce Leban wrote:
To take this further, suppose you write 'Hello {username} from 
{company}'.format(userdata).format(companydata) where the user has set 
their name to "Dr. {secret} Evil" where {secret} is something in 
companydata that should not be exposed.


More generally, a format string should be treated as code, and
doing anything that could result in untrusted user data being
treated as code is a Bad Idea.

--
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/55PB23XWOLEGM7OWEGPH7ZVAK7MWRIFE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters

[Greg Ewing]

On 22/04/23 10:20 am, Samuel Muldoon wrote:
Can we change str.formatso that it is possible to change only one string 
parameter, but leave the other parameters alone?


That would have the effect that every use of str.format for everyone
would start producing partially-formatted strings if an argument is
accidentally omitted instead of raising an error. Some people might
not like that.

It would be better to write a separate function for doing partial
formatting.

--
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/YPZBVCN2WCRO75LFOMNP3RWFC2B5H2QX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: len(Enum) should raise TypeError

[Greg Ewing]

On 2/04/23 6:36 pm, Benedict Verhegghe wrote:
An Enum is functionally a container with a limited set of constants. Why 
should it not be legitimate to ask for the number of constants in it?


But Enum itself isn't an enum, it's a constructor for enums.
I think len() just happens to work on it as a side effect
of the way enums are implemented.

--
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/6YTC6U27TXS2RA26ZQGLM4AZ3SBHUBR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Better (?) PRNG - follow up

[Greg Ewing]

On 6/12/22 3:58 pm, James Johnson wrote:
I came back to this thread looking for the list of randomness tests, and 
I keep missing them somehow.


If you're interested in testing a PRNG really thoroughly, check
out TestU01:
http://simul.iro.umontreal.ca/testu01/tu01.html

--
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/JNK52FQDWCDRFNWB2PXTGTXVWUDYKLVJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing variable scope control

[Greg Ewing]

On 1/12/22 9:27 am, Anony Mous wrote:
The idea is that YOU write "local:", and the interpreter, without you 
ever seeing it, promotes that into a hidden function with a hidden name 
and a hidden call.


But if that's *all* it does, then this wouldn't happen:

I would expect them to return to, or yield to, the next outer "def" 
function, assuming they were in a "local:" inside another function.


--
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/MXTV25UBEY2CJ6MQRNWHNRZ6GSKYKMAR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing variable scope control

[Greg Ewing]

On 1/12/22 6:58 am, Anony Mous wrote:

local:
     for MyVal in range(0,10)
         pass

provides scoping, making it 
easier for us to code, debug, and document, while significantly 
decreasing the likelihood of variable collisions.


I'm not convinced it would be beneficial in Python. In C
you have declarations that make it clear when you're
introducing a new variable, but in Python there's nothing
saying that MyVal has a restricted scope other than the
rather inconspicuous "local:" above it.

--
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/PCLKTM5FONDXGK3V6JS6EUX3JQ3FLDCP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Void type

[Greg Ewing]

On 27/07/22 5:29 am, Stephen J. Turnbull wrote:

If you're phishing, I guess worms are useful.  *shudder*


I think you need whorms for phishing.

--
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/YGLKEPQPU6XYIVPNXVOUFOJIDRNWITWZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `importlib.resources` access whole directories as resources

[Greg Ewing]

On 17/05/22 4:58 am, Christopher Barker wrote:
if you want to call your collection of files a single resource, then 
sure -- but then it's not the directory that's the resource, it's the 
collection of files that's the resource


Sure, but why am I not allowed to use the name of the directory as
the name of that collection of files?

--
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/CFTAO6NSPLN4JVD6NW2FO6J4267TEIVX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `importlib.resources` access whole directories as resources

[Greg Ewing]

On 16/05/22 5:05 pm, Christopher Barker wrote:
a directory is not a binary artifact -- it can't have actually data in 
it like a file can.


and:

the entire 
point of resources is to provide an abstraction -- the individual 
resources may not be files on disk at all


These two statements are contradictory.

If a resource is an abstraction, why can't it be represented by
a collection of files in a directory rather than a single file?

--
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/BATVPGYYGZJX3IJCMVGAV54J3GVXFUS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New Tool Proposal

[Greg Ewing]

On 10/05/22 8:05 pm, anthony.flury via Python-ideas wrote:
My Idea is a simple tool that uses introspection tools to take a Python 
module and to generate the relevant boiler plate for the module - 
including blank functions for the module classes and for methods.


There's a much better tool in this space already:

https://cython.org/

--
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/SSHXD6IV7OVUBW2UHHLE5TW66MAOU5MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Get the value of an attribute of an object hierarchy with a path expression

[Greg Ewing]

On 5/05/22 3:53 am, gabor.g...@proinbox.com wrote:

I think it is pretty frequent to check that a variable is not None before 
accessing it's attributes or element.


While that's probably true, in my experience I'm usually performing
the test once on a particular object and then accessing a bunch
of attributes. I'm not doing it for individual attribute accesses.

Also I don't find that I'm doing deeply nested sequences of
accesses very often. It gives me the feeling that I'm mixing up
levels of abstraction in my code in a way that's going to cause
problems later.

--
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/XVIL7YLN66CLJKQWBRDB7NYQCRHP7JWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Delete dictionary entry if key exists using -= operator via __isub__()

[Greg Ewing]

On 29/04/22 6:02 am, Zach Victor wrote:

For me, pop() says "give me something."


In English the word "pop" doesn't necessarily imply getting
something wanted, or even getting anything at all. Think
popping a champagne cork, or popping a balloon.

--
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/4MQFQATUZFDRRGVYK6CU3RJJJEGOZC2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 18/04/22 7:29 pm, malmiteria wrote:

It's an arbitrary choice that the C3 feature itself makes, and the programmer 
is left guessing what that choice was, unless they can take the time to learn 
C3 in depth.


Even if you do, it's still an arbitrary choice to prefer the leftmost
method, which might be what you want or might not.

The "guessing" in the Zen is a tongue-in-cheek way of referring to
picking something as a default when there isn't any strong reason to
think it will be what is most often wanted. If there's any literal
guessing involved, it's on the part of the language designer.

--
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/JEHUSQKTLQQGA7FEVPMQI5TAZP6VZ4L7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 16/04/22 10:46 pm, Steven D'Aprano wrote:

On Sat, Apr 16, 2022 at 05:56:13PM +1200, Greg Ewing wrote:



There's nothing incoherent or inconsistent about the way C++
and Eiffel do MI.


Good thing I never said that they were incoherent or inconsistent.


You seemed to be implying that, though. You claim that the C3
algorithm is the only way to get MI that is coherent and consistent.
If that's true, then since C++ and Eiffel don't use C3, they must
not be coherent and consistent.


There is no *guessing* in the C3 linearization algorithm.


"Guessing" in the context of that Zen line means making an arbitrary
choice that may or may not be what the programmer wants. It doesn't
mean choosing at random.

--
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/H7DCU2P2465PWU2NNTLVQURWG6VCIOGT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 16/04/22 11:13 pm, Steven D'Aprano wrote:


So we might say that all inheritance is delegation, but not all
delegation is inheritance. We might even go further and say that any
delegation to a superclass (not just the direct parent) is a form of
manual inheritance.


To my way of thinking, delegation is when you call a method of
a *different* object. With a super call (either explicit or
implicit) you're calling a different method of the *same* object.

Think about the ordinary meaning of the word "delegation".
When you delegate a task, you give it to someone *else* to do.
If instead you just find a different way of doing it yourself,
you wouldn't call that delegation.

So I would say that none of the things we're talking about here
are examples of delegation.

--
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/HE2HDBITU7PLOJCCQ6UKFKZSZDZM44Z6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditions for a coherent MI relationship [was Re: Re: mro and super don't feel so pythonic]

[Greg Ewing]

On 16/04/22 10:26 pm, Steven D'Aprano wrote:

C++ and Eiffel are even stricter (more restrictive) than Python. They
don't just exclude class hierarchies which are inconsistent, they
exclude class hierarchies with perfectly good linearizations because
they have a method conflict.


No, they don't *exclude* such hierarchies, they just require you
to resolve the conflicts explicitly.


no matter
how many times I say that other choices for MI are legitimate and maybe
even better than Python's choice


So by saying that something is "not full MI", you didn't mean to
imply that it is somehow inferior and less desirable? Because that's
what you sounded like you were saying, and why everyone is pushing
back so hard on it.


The requirement for automatic conflict resolution is kinda necessary for
it to be inheritance


You seem to have a very different idea of what "inheritance" means
from everyone else here.

--
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/CWZLJUDADDF6YGIBCNJA3XDGGTV2522G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 16/04/22 12:56 pm, Steven D'Aprano wrote:

If you exclude models of MI which are logically incoherent and
inconsistent, (such as Python's prior to version 2.3), then Python's
model of MI is objectively as complete as you can get.


You seem to be assuming that "full MI" has to include a fully
automatic means of method resolution.

There's nothing incoherent or inconsistent about the way C++
and Eiffel do MI. The main difference is that they require you
to explicitly resolve conflicts between inherited methods --
which is arguably more Pythonic than Python, since they refuse
the temptation to guess.

--
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/J5I3MLGZPMOKBRTPANQIE74RMRSHUBJM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 15/04/22 10:37 pm, Steven D'Aprano wrote:
If you look at languages that implement MI, and pick the implementations 
which allow it with the fewest restrictions, then that is "full MI".



I believe that Python (and other languages) allow MI with
the smallest set of restrictions, namely that there is a C3
linearization possible


But before Python adopted the C3 algorithm, it was less
restrictive about the inheritance graph. So by your definition,
current Python does not do full MI!


If you have to manually call a specific method, as shown here:

https://devblogs.microsoft.com/oldnewthing/20210813-05/?p=105554

you're no longer using inheritance, you're doing delegation.


You could also say that Python automatically delegates to the first
method found by searching the MRO.

Why is one of these delegation and not the other?

--
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/GJIZENRGIZCDPLXPXQ6MBYKEUR33ZGV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 15/04/22 4:45 am, malmiteria wrote:

malmiteria xD not malmalitia


Sorry! Should have gone to Specsavers...

--
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/MWDXAJDS37HPCKKWX7FSCPJFS72SKPFM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 13/04/22 8:29 am, Steven D'Aprano wrote:

When multiple parent provide candidate to a method resolution, raise an error.


Then you aren't doing full MI any more,


That sounds like a "true Scotsman" argument. Who defines what
"full MI" means?

I can think of at least two languages that do something very
similar to what malmalitia is proposing: C++ and (if I remember
rightly) Eiffel. I don't think I've heard anyone claim that
C++ doesn't do "full MI".

Here's a C++ example:

#include 

class A {
  public:
void f() {
  printf("f in A\n");
  }
};

class B {
  public:
void f() {
  printf("f in B\n");
  }
};

class AB: virtual A, virtual B {
};

int main() {
  AB ab;
  ab.f();
}

and compiling it gives this:

mi.cpp:22:6: error: member 'f' found in multiple base classes of 
different types

  ab.f();
 ^
mi.cpp:5:10: note: member found by ambiguous name lookup
void f() {
 ^
mi.cpp:12:10: note: member found by ambiguous name lookup
void f() {
 ^
1 error generated.

--
Greg



 just a limited, restricted

version known as traits.



The child class now has to redefine the method, and in the body of that method, 
can decide which parent method call, or in what order call them.
That's essentially the basic idea of my proposal.
What makes this impossible for you?


Its not impossible, I have been telling you about traits since my
earliest posts in this thread.

Maybe you need to stop thinking you have invented some brilliant idea
which has solved a problem nobody else has noticed, and read some of the
Artima links I have days ago.



I think i've adressed most if not all problems i had raised against it.


Except the most important one: why are you using multiple inheritence
when you clearly don't want multiple inheritence, instead you want
delegation?



Linearisation is litterally an operation that consist into converting
a multiple inheritance tree into a simple inheritance tree.


That is absolutely not what linearization does.


That's bound to lose some info,


No, the point of linearization is to avoid losing info.



and can't cover all cases.


Correct, there are inconsistent inheritence hierarchy which are
impossible to linearise because they are inconsistent. It is better to
get an error when you try to define the inconsistent hierarchy, rather
than pretend it is consistent and then wonder why inheritence is not
working and methods are called in inconsistent order.




___
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/7RPZNLARFS5B6WXSQ5XIHMR2MPNO5UL5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing]

On 8/04/22 7:03 pm, Christopher Barker wrote:

Are you SURE your accounting software is doing the right thing?  ;-)


Well, I've only ever seen precision problems manifest themselves
once, and that was when I wrote a script that used repeated
multiplications by 10 as part of a process to convert a number
into words. I had to put some rounding steps into that to make
it work properly.

Other than that, if you were adding up about a billion monetary
amounts in one go without any rounding, you might get a problem.
I've never seen anyone do that, though. :-)

Also -- if it uses 64 bit floats, it'll have problems with trillions of 
dollars :-)


If your business is that big, you would not be using this particular
accounting package!

--
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/YCNNELCHQJYH5IXUIXH6CQFURNWNT5KE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 7/04/22 11:11 pm, malmiteria wrote:

But if there was a way to tell super what class it should be a proxy of, that 
would be very easy to explain : when there's two parent, just give the parent 
you want to target as an argument to super.


That sounds like exactly what Class.method(self) does today. Why
do we need another way to do it?

 It requires knowing a *lot* about the classes you're inheriting from, 
*today*, and that's a problem I'm trying to adress.

And you being able to tell those 2 classes have some sort of common ancestry 
wouldn't be of much help if you don't already know about MRO and the effect it 
might have on inherited classes in case of multiple inheritance.


That's not the kind of knowledge I'm talking about. You need to know
a lot about how those particular classes behave -- what their methods
do, whether they would conflict with each other in any way, what the
consequences would be of calling them in various orders, etc.

You seem to think that removing the MRO and making super work the
way you imagine it should would make it easy to grab any bunch of
arbitrary classes and inherit from them and everything would be fine
and dandy. It would not!


The Mixin use case, where we explicitely use the super ability to side jump so 
that our mixin 'specialise' the last class in MI order would really benefit 
from a feature allowing a class to select a parent after being defined.


I still don't understand how you expect a particular super call
in a particular method to somehow be able to jump sideways when
you want it to and not other times. You'll have to provide a
detailed example, not just vague waffling about mixins and
proxying.

--
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/SFAQ3APFZXNFJQCHMO2Q7OAEMZ5D6I7Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 7/04/22 11:52 pm, malmiteria wrote:

I believe my gobelin exemple is a fair case of MI since we can definitely say 
halfbreed *is a* corruptedgobelin *and a* proudgobelin.


I'm not so sure about that. I would agree that it's a gobelin, just as
you are (presumably) a human.

But a child is *not* its parents -- it's a human in its own right that
happens to have some characteristics of one parent and some of the
other. I'm not sure MI is such a good way to model that kind of
relationship.

--
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/KCV4Y3XNW5IVDMOCGWSNOZZ2DTZBDA5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing]

On 8/04/22 6:01 am, David Mertz, Ph.D. wrote:
Because the module implements 
http://speleotrove.com/decimal/decarith.html 



Well, yes, but someone made the decision to implement that
particular standard rather than one of the ones with fixed
precision. I'm asking why *that* decision was made.

--
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/ROKPSO32J5E5ICSERT2XVQLB4VF6RFID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing]

On 8/04/22 5:15 am, Christopher Barker wrote:
I actually have almost the opposite position -- variable precision is 
the most useful part of the Decimal type ;-)


So can you elaborate on how you use variable precision?

Note the docs again: "End users typically would not expect 1.1 + 2.2 to 
display as 3.3003 as it does with binary floating point." -- 
so it's really about the display, not the precision or accuracy of the 
result.


I don't think it's entirely about the display. It's also about
things like sum([1/10] * 10) == 1 being False. This is where
"human-friendly" display actually makes things worse, because
repr() makes it *look* like 1/10 equals decimal 1.0, but it really
doesn't.

Calculating interest, inflation, who knows what could easily 
introduce non-exactly-representable-in-decimal numbers.


Yes, but when it comes to the point of e.g. adding some interest
to an account, the amount of interest needs to be an exact
multiple of 0.01 dollars. And if you add up all the interest
transferred during your nightly run, it had better exactly
equal the amount taken out of the account the interest is being
paid from.

I do agree, however, that you don't need *floating point* for
this, and fixed point would probably be better.

BTW, there's an accounting package I work with that uses binary
floating point for money, and seems to get away with it. Probably
because everything that goes into the database gets rounded to
a defined number of decimal places, so errors don't get a chance
to accumulate to the point where they would cause a problem.
It does make me a bit nervous, though. :-)

--
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/5C5726DYJI2UHUQBAH7HAYSP4HZM3DRP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing]

On 7/04/22 9:53 am, Chris Angelico wrote:

how else would you do variable-precision in the standard library?


Maybe the mistake was in thinking that we need variable
precision at all.

If the goal of Decimal was to provide arithmetic that
"works like your calculator", well, most calculators have
a fixed precision of 10 or so digits, which seems to be
fine for most things.

So why *do* we have variable precision in Decimal?

--
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/OECXPUSG2SD3YEVEQ4OXCP7NODOYJ3XR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 7/04/22 5:22 am, malmiteria wrote:

Also, i believe the idea of using anything but super to access a parent methods 
is far from obvious to most people.


That might be true for people who learned Python recently enough. When
I started using Python, super didn't even exist, so I got used to
thinking of Class.method as the *normal* way to call inherited
methods. When super first appeared I saw it as something you only use
when you particularly need it, i.e. when doing cooperative MI.


This alone justifies the idea that any newcomer to this kind of problem would 
try to use super, at least at first.
And possibly wouldn't expect super targeting to behave like it does.


If I were teaching a newcomer about super, I wouldn't even tell them
that it *has* a class argument. So they wouldn't have any expectation
about targeting, because they wouldn't know about it.


if proudgobelin and corruptegobelin are published by a game_engine library, the 
game_engine user would most likely not be aware (nor should he care) that they 
both inherit from a same parent.


If someone is going to munge those classes together using MI, they'd
better learn everything they possibly can about them. It's a delicate
operation that requires knowing a *lot* about the classes you're
blending together.

In this case, the fact that both class names have the form
Gobelin would make me suspect quite strongly that they
*do* have some common ancestry.

--
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/MOIQ3XPXI5O5HX4VRFFOBHIILNA35GQT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing]

On 6/04/22 8:58 pm, Mark Dickinson via Python-ideas wrote:

I'd be curious to know what alternatives you see. When a user writes `x + y` 
with both `x` and `y` instances of `decimal.Decimal`, the decimal module needs 
to know what precision to compute the result to (as well as what rounding mode 
to use, etc.). Absent a thread-local context or task-local context, where would 
that precision information come from?


I'm not sure, but my feeling is that if I want to limit results
to a specific number of digits, I'm going to want much finer
grained control, like specifying it for each individual
operation. The current design doesn't fit any use case I can
see myself needing.

--
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/6U2UFON6XYMW66AGTFDHJ2LFVVSE3B7F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 6/04/22 10:41 am, Chris Angelico wrote:

I don't think anyone would ever say that a
parsec (several light years) should be considered equivalent to a
second of latitude (a handful of meters) just because they both have
an angular size of one second!


Although if you're Han Solo then it's a unit of time. :-)

--
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/ISL3AB2A3PNO4DUY3XYYZO5HIVL757TJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 6/04/22 5:52 am, malmiteria wrote:

Some exemple i give including, but not limited to the gobelin exemple are a 
fair use case in which you'd want to use the argumented version of super.


No, the gobelin example is an example of when NOT to use super().

Multiple people have told you that, but you don't seem to be
listening.


The exemple i always give : you have multiple view class, you have the 
permission mixin, so you (as a lib author) wanna provide all possible 
combinations of simple view class, and permission mixin augmented view class.
today's only (reasonable) way is ML.


I would need convincing that this isn't better done by
composition than MI. Give the View class a Permissions
attribute that determines what it's allowed to do.


Essentially, (i'm talking about what i understand you consider a properly 
designed ML scenario):
```
class A(P1,P2): ...
```
Is 100% equivalent of
```
class A(P2,P1): ...
```
correct me if i'm wrong.


No, what I'm saying is that if you have

class A: ...
class B: ...
class C(A, B): ...
class D(E, F): ...
class E(C, D): ...

you shouldn't have to worry about how A, B, E and F get interleaved
in the MRO of E. You can rely on A being before B and E being before
F, but E could come either before or after B, etc.


Also, i do wanna mention that you do in fact care, to some extent to which 
order things are called in.
Not always, but in some cases you do, and not being able to target one of the 
parent first, instead of the default one, when the default one is not 
appropriate is a problem.


Well, I disagree. I still maintain that if you need to target a
particular base class, super() is the wrong thing to use and will
only lead to difficulties if you try to use it that way.

I actually think super() is misnamed and should really be called
next_class() or something like that. There might be less confusion
about its intended use then.

--
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/YJJZN2Y7KD6Y7HV6SBWDJ2EAEICN64A2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Greg Ewing]

On 5/04/22 4:17 pm, Chris Angelico wrote:

If your application
needs to use both statute and nautical miles in the same module (most
likely the main module), then it's going to have an issue,


If there's a single global registry, and they both register the
unit under the same name, then there will be problems if both
modules are imported by the same program, even if the two units
are never used together in the same module.


What's your proposal?


I'm not sure, but we really need to avoid having a global
registry.

Treating units as ordinary names looked up as usual would
be the simplest thing to do.

If you really want units to be in a separate namespace,
I think it would have to be per-module, with some variant
of the import statement for getting things into it.

from units.si import units *
from units.imperial import units inch, ft, mile
from units.nautical import units mile as nm


It's more like using decimal.getcontext() and making
changes. That's global.


Personally I think giving Decimal a global context was a mistake,
so arguing that "it's no worse than Decimal" isn't going to do much
to convince me. :-)

But in any case, a Decimal context and the proposed global unit
registry are very different things. Just because one doesn't seem
to cause problems doesn't mean the other won't either.

--
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/TOD2KJLONTUHRGNITAFVGQD3QSLDIJBS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 6/04/22 4:57 am, Eric Fahlgren wrote:
On Tue, Apr 5, 2022 at 7:49 AM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote:

>

It's only there now for backwards compatibility.

Not always.  I have an example, where a method creates a closure that 
calls super, requiring the class/self pair as there isn't enough context 
for parameterless super.


Fair point, but you're still using it to keep track of the class
defining the method concerned, not to target some other class
in the MRO.

BTW, it seems to me that such a closure should also participate
in the magic behind argumentless super. Seems like it should be
possible.

--
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/6IZQSUKRLCZYJZ4QGHIED2I3VHUTCS6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 6/04/22 3:47 am, Christopher Barker wrote:
And they are -- degrees latitude and degrees longitude are very 
different units :-)


I'm thinking more of a local Cartesian coordinate system rather
than lat-long.

Think about this: You're driving north in a car that's 3m long.
You turn east. Do you now have to measure the length of your
car in different units?

And what about the circumference of a circle? It's going in
uncountably many directions at different points. Do we need
a similarly uncountable number of units to measure it?

Or do we just say "all distances are in metres" and be done
with it?

--
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/HIS2LE7JBCTJDHC3WCDOXI6BJJRLZDS7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 6/04/22 3:30 am, Stephen J. Turnbull wrote:

suppose I
wanted to know how many cm there are in an in:

 cm_per_in = 1 * in / 1 * cm

Of course that's a silly mistake, but the (sole, IMO) advantage of the
original proposal is that you can't make that silly mistake.


Well, you can make the same silly mistake any time you mix
multiplication and division in an expression, so we should
really be lobbying to fix the borked precedence of * and /
in general. :-)

--
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/LE3I25TXXXE7PFXU2IFT63D4GHOFEJ3W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 5/04/22 5:57 am, malmiteria wrote:

When you're actually in need to passing arguments to super, you very likely know what 
class you're gonna be targeting, and having to run MRO logic in reverse to call super to 
the class that comes first before your target in MRO order is what i refer to as 
"working around MRO".


I think you misunderstand the reason why super() accepts a class
argument.

It's purely for historical reasons. Originally super() couldn't
tell on its own which class it was being called from, and had
to be told.

It's only there now for backwards compatibility. It's not
intended for picking and choosing which class to target --
that's what explicit class.method calls are for.

You object to that on the basis that it would prevent other
neat stuff that relies on things *not* targeting specific
inherited methods.

But you can't have it both ways! A particular method either
targets a particular base class for its inherited calls or
it doesn't. You're trying to have your cake and eat it too.

--
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/76PAC4J2REJJQPCW5UAPELJW4WWPUCTU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 5/04/22 6:36 am, Chris Angelico wrote:

5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you
prefer, 50mm².

Fuel economy is a unit of area.


This misses the rather important point that it's not just
litres of empty space, it's litres *of fuel*. You really
need to consider "litres of fuel" to be an indivisible
unit that doesn't cancel with a distance.

Alternatively, measure the fuel by mass rather than volume.
Then your fuel consumption is in kg/100km, which is in
far less danger of being cancelled down.

Or you could measure the fuel in moles... but then since
moles are dimensionless, you get reciprocal distance...

Who would have thought units could be such fun?

--
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/DZ3AOKKJRGDT35WNHTHLZHOTIU6AM65I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 5/04/22 6:05 am, Ethan Furman wrote:
It seems to me that these "unitless' units actually have units, even if 
they *appear* to cancel each other out.


I think it's more that units alone don't capture everything
that's important about the physical situation.

Another example: the capacitance of a capacitor is the area of the 
plates divided by the distance between them and multiplied by a

constant. Unit-wise, an area divided by a length is just a length,
so the constant has units of farads per metre. But the metres don't
correspond to a length you can measure anywhere.

--
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/EZUJEOSZIDQ4AS7A7K6HI6674MCRZVWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 5/04/22 6:05 am, Chris Angelico wrote:

In any case: the
speed of light might be 1, but it's still 1 distance divided by 1
time.


If you truly embrace the idea of space and time forming a
single 4-dimensional continuum, this makes about as much
sense as insisting that north-south and east-west distances
are measured in different units.

--
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/WFYGRY4KL5CJU5XFLMVQCZNX33AGCNIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 5/04/22 5:17 am, Steven D'Aprano wrote:

However, I suspect that having an array of unit objects rather than
low-level machine ints or floats will reduce the performance of numpy a
lot.


If numpy were to incorporate units, I would expect there to be
just one unit tag for the whole array.

--
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/G33JPTBRX3CKJLCVIAIE2U55OFQUUEYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 5/04/22 12:27 am, David Mertz, Ph.D. wrote:

On Mon, Apr 4, 2022, 2:17 AM Brian McCall
 > For instance, I don't think there would be much uproar if "teaspoons" 
were left out of any kind of implementation.


Apparently someone other than you does the cooking in you household!


Wouldn't recommend this, the National Union of Chefs, Cooks, Cuisiniers
and Other Professional Culinary Persons would be out on strike until 
teaspoons were included.


--
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/OW66NGT6ICEFUH7PVLGUYDMBGYMEJH2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 4/04/22 10:46 pm, Steven D'Aprano wrote:

Now tell me that
before you ran the code, or read my analysis of it, you would have
predicted that super(ProudGobelin, self) would skip ProudGobelin's
method and call CorruptedGobelin's method.


I could have told you that it would skip ProudGobelin, because
that's what super does. It starts looking in the MRO *after* the
class you pass it, never in that class itself.

It does this because the way it's intended to be used is to
pass it the class in which the method you're calling it from is
defined. It's designed that way because originally there was no
other way for it to tell where to start searching. Now that
we have argumentless super, there's no longer any need to do
that.

As for telling which method it *would* call, I could probably
figure it out for a simple inheritance hierarchy like this.

I could certainly have told you that ProudGobelin's method
would be called at *some* point in the chain after HalfBreed's,
because ProudGobelin appears above HalfBreed in the inheritance
hierarchy.

I would say that's all you should *need* to know. If you're
using super at all with MI, your methods should all be designed
so that it *doesn't matter* exactly what order they get called in,
other than the fact that methods further up the hierarchy are
called after methods further down.

If that's not the case, then super is the wrong tool for the job.

I would also say that if you're passing super anything *other*
than the class where the method is defined, you're trying to
be too clever by half, and will get bitten.

--
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/AKT74FSMKGSQNZFUVNZB6UQH5QXMW3C5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 4/04/22 7:59 pm, Chris Angelico wrote:

How often do you ACTUALLY need them to be local to a module? When is
this ever a concern?


As long as there are competing *implementations* of units there will
be potential for conflicts, even if the actual units being represented
are the same.

--
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/6DZNCRWO5YBLDEZ4QMD3MZ47VONIUBZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 4/04/22 3:45 pm, David Mertz, Ph.D. wrote:

An electron volt is a unit of energy. Or of mass. Or of momentum.


Well, in relativity they're all really the same thing, or
at least interconvertible.

But there are more glaring examples of this. What do you get
when you multiply a number of newtons by a number of metres?
It could be either joules of energy or newton-metres of
torque, depending on what you're doing. You definitely
don't want to add those together!

I'm not sure how you teach a unit system to deal with things
like that. Somehow when you do the multiplication you have
to specify whether you're calculating energy or torque.

--
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/HJ3ODB625ZOWVY2NIDOQ2ZEGUA36Z3BI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 4/04/22 2:42 pm, Ricky Teachey wrote:

height = 5ft + 4.5in

Surely we ought to be able to add these values. But what should the 
resulting tag be?


One answer might be that the tag only tracks what kind of quantity it
is -- length, mass, time, etc. Internally the number would be
represented in a standard unit for each quantity.

Whether to display it as feet or inches or a combination of both would
then be a matter of formatting. A default could be chosen based on the
magnitude of the number, and if you wanted something else you would have
to specify it, just as with any other formatting decision.


Should we be able to write it like this?

height = 5ft 4.5in


With my "no new syntax" suggestion there would be no question here --
the only way to write it would be

height = 5 * ft + 4.5 * in

--
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/EE6HH7WARD4YIZWGJC4EJN6PMMK3QPWU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 4/04/22 10:47 am, dn wrote:

You wouldn't believe it - have interrupted typing here to receive a
package. However, the clothing delivered is NOT the size ordered...


Let me guess, you ordered it in cm but they delivered it in inches?-)

--
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/ECXWLWZWPY243BGRAZI63TB4RZ3MH6UI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom literals, a la C++

[Greg Ewing]

On 4/04/22 10:20 am, Chris Angelico wrote:

import sys
sys.register_numeric_suffix("m", lambda n: unit(n, "meter"))
sys.register_numeric_suffix("mol", lambda n: unit(n, "mole"))


A global registry seems like a really bad idea. What if two
libraries want to use different, incompatible implementations
of units?

--
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/NWOGVNFEPA7K4JUGEGKRC4U7HVV4DWVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

[Greg Ewing]

On 4/04/22 9:45 am, Ethan Furman wrote:

Well, if we're spit-balling ideas, what about:

     63_lbs

    77_km/hr


I'm not convinced there's a need for new syntax here.

63*lbs

77*km/hr

With appropriate definitions of lbs, km and hr these
can be made to construct numbers with attached units.

--
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/42FJEIJ4HV2GOCMZKN2TMTIDFMPBNBPY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 4/04/22 9:35 am, malmiteria wrote:

And just to make it clear, I am not under the impression super can only target 
one class.
What i'm saying here is that it is the most common impression the average 
developper would have.


How do you know this? Have you undertaken a survey of
randomly selected average developers?

--
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/ZEJ56SQTWK5LKHCAVEYUCSX63SEGRJUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mro and super don't feel so pythonic

[Greg Ewing]

On 4/04/22 9:12 am, malmiteria wrote:

So, allow me to make it clear, I do get its value. Its value appears in the 
other use cases i account for, and wanna provide dedicated features for. 
(before getting rid of super and MRO's ability to provide those use case).


So, if I understand correctly:

1. You hate the existing MRO and super() mechanism with a passion
and want to rip it out.

2. People have objected that this would remove useful funcionality.

3. You address 2 by proposing a bunch of new mechanisms to replace
the lost functionality.

But you haven't adequately justified step 1 yet. There's no point in
discussing any of your other proposals until we get past that.

--
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/W27RDSCUXXWD3MWHMQ7M6LR3DB2ZIDX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a replace method to tuples

[Greg Ewing]

On 15/03/22 6:14 am, wfdc via Python-ideas wrote:

The whole *point* is that namedtuples let you use *named fields* rather than 
indices. That's the point. That's the purpose.


I would say the point of namedtuple is to let you use either field
names or indices, whichever makes the most sense for what you're
doing at the time. Otherwise why not just use a regular class?

--
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/6Z3SGL4AJEBS2W4URZ5D4UH4KKPC6IAX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Greg Ewing]

On 8/03/22 12:32 pm, Chris Angelico wrote:

All I can see is that
changes get proposed on typing-sig and actually make it into the
language, but changes that get proposed on python-ideas are invariably
shot down in flames,


Typing is an area of Python that is under active development, so
it is somewhat malleable, and there are still real problems that
actually need to be solved.

On the other hand, the core syntax of Python has been well
established for a long time. Most of the proposals for adding
to it nowadays tend to be of the "wouldn't it nice if..."
variety that are not addressing anything that's widely seen
as a problem. It's not surprising that such suggestions
rarely succeed.


no matter how good or bad.


If an idea can be shot down in flames that easily, it wasn't
really such a good idea when seen in the wider context.

It's not just the merits of the idea itself that need to be
considered, but whether it brings enough benefit to be worth
the disruption of introducing it. As Python matures and
solidifies, that bar becomes harder and harder to clear.

--
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/TBFFQ2UCFSDTFBDARK67AU4YTOHXKALQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Greg Ewing]

On 3/03/22 9:50 pm, Steven D'Aprano wrote:

While you can put the block on the same line as the colon using
semicolons:

 if condition: print(1); print(2)  # Legal.


and there's nothing to stop you from making arbitrarily long
lines using this feature...

if condition: print(1); print(2); print(buckle); print(my_shoe); 
print("Is this line long enough yet?")


So if Python is opinionated about line lengths, it's rather
selectively opinionated.

--
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/X6QQV5GDVCIVIDFYS6G5WEMUG2WG65BH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Greg Ewing]

On Wed, 2 Mar 2022 at 09:58, Rob Cliffe via Python-ideas
 wrote:


Without testing, I am sure it would be slower.


Does that mean if you do test it, it'll be faster? :-)

--
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/CUD6VCUAD7MJEXPZPHSUNGYDP2LOYWGP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Greg Ewing]

On 2/03/22 12:50 pm, Rob Cliffe via Python-ideas wrote:
As I see it, the original meaning of an exception (in whatever language) 
is "something unexpected has happened" or "something has gone wrong".


Using exceptions for flow control has always been acceptable in
Python. The iterator protocol relies on it, for example.

--
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/LECKY3GEIKHX67QPN42UZZOXWG3GAT4V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code

[Greg Ewing]

On 20/01/22 12:52 pm, Christopher Barker wrote:
On Wed, Jan 19, 2022 at 2:12 PM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote:


Those particular brackets are really confusing because they're half
square and half round. 


And THAT is why this is a bad idea.


It doesn't mean it's a bad idea in general, just that we would have to
be careful what kinds of brackets we allow.

--
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/L3NJPQLCY6FTB3LE67GQVLEAOXLPIHNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Greg Ewing]

On 20/01/22 3:17 am, Joao S. O. Bueno wrote:

But upon seeing a method call, we can just think first of a runtime behavior
Correctly, btw. Any optimization there would be an exception, that 
people would

have to know by heart.


Frozensets are immutable, so nobody should be making any
assumptions about whether equal frozensets are the same
object or not -- just as with ints, strings, etc.

It would be just as legitimate e.g. for "ABC".upper()
to return the same string object. There is no exception
here to be learned.

--
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/IIHLAEPGKV3QOWVXH3CIWCZ53LOPXGCT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code

[Greg Ewing]

On 20/01/22 3:45 am, Alexandre Brault wrote:

On 2022-01-18 6:12 p.m., Chris Angelico wrote:

3) Optional semantic difference: 【1, 2, 3】 is exactly the same as (1,
2, 3), but 【1, 2, 3) would be an error.


What does it say about the viability of this idea that until the second
part of that sentence, I thought it would be equivalent to [1, 2, 3]?


Those particular brackets are really confusing because they're half
square and half round. I would expect it to mean [(1, 2, 3)].

--
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/PO4ZMNPI5DZHBT7ZY3PQLEAQTVOVEPVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Greg Ewing]

On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:

I'm happy with the
     f{ ... }


Fine with me too.

I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on a constant
set would immediately benefit from it.

--
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/DWNELMJRPH5MJDKS2USTCS2FU5O4RY7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Greg Ewing]

On 19/01/22 6:41 am, Rob Cliffe via Python-ideas wrote:

I'm happy with the
     f{ ... }


Fine with me too.

I'd also be happy with making frozenset a keyword. It's hard to
imagine it breaking any existing code, it avoids having to make any
syntax changes, and all current uses of frozenset() on a constant
set would immediately benefit from it.

--
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/X72PHEE2Y7IO5VI7XDGZM7MJTG3XSSID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Greg Ewing]

U+2744 Snowflake, anyone?

my_frozenset = ❄{1, 2, 3}

--
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/M5KUU65YVZVY72VVSIW33ZANNMBAFJEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: inline Python functions and methods

[Greg Ewing]

On 11/12/21 5:40 pm, TobiasHT wrote:

> The right function to perform inlining on shall be determined at runtime and 
cached in the same scope as where it’s performing it’s operations from cases where 
the program performs large iterations or even in infinite loops and other cases 
that need optimization.


If it's to be a run-time optimisation, you could consider dropping
the inline declaration and just have the implementation decide
whether it's worth inlining things, based on factors such as the
size of the function and how often it's called.

Then the language wouldn't have to be changed at all, and programmers
wouldn't need to have foresight to decide when to declare things
inline.

--
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/UXKJ4JA42IGZXN6CITX2USZKJ3FGOTRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

[Greg Ewing]

On 11/12/21 1:22 pm, Christopher Barker wrote:

Darn — the P and A are swapped there.


"Argument" and "actual" both start with "A" -- does that help?

--
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/6XS45CV4GJHYGMEAHKLTBKXEFFDSK3TX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Greg Ewing]

On 9/12/21 12:50 am, tmkehrenb...@gmail.com wrote:

The main criticism, I think, was that it is weird to have the docstring
*below* the attribute.


I don't think that's a problem. The docstring of a class or function
is also below the name of the class or function. I think it's
actually more consistent that way.

It seems excessive to invent a whole new type of string just for
this purpose. The neat thing about the docstring convention is that
it doesn't require any special syntax.

It would also raise some other questions, such as what happens if
you use a d-string in some other context? Does it just behave as
an ordinary string? Is it disallowed?


# in my_module.py:
d"Number of days in a week."
DAYS_PER_WEEK: Final = 7


Does this mean you could also use it on module-level functions?

d"This function is really important."
def f():
...

That would give you two different ways to document a function,
and it seems you could use both of them at the same time,
which could be confusing. If you're looking for documentation
of a function, there are two places you would have to look --
in the function itself, and in the module where it's defined.
Similarly for classes.

--
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/H5LQ5EHICVUOW75FYW6DMZAEYZBA2GAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: inline Python functions and methods

[Greg Ewing]

On 9/12/21 2:07 am, TobiasHT wrote:

If a function fails to be inlined at compiletime due to dynamic behavior of 
python, then the normal function call behavior can be the fallback


The problem is that the compiler might *think* it knows where the
module is at compile time, but at run time it turns out to be
different.

Maybe you could come up with some scheme to allow this to be
detected and invalidate all the code resulting from inlining its
functions, but that could get very complicated and it would be
hard to be sure it works properly in all situations.

Another thing to consider is that all this would only help
with calling stand-alone functions, which is a relatively rare
thing to do in Python. Most of the time you're calling a method
of some object, and you don't know until each call which
function that will be. That's another reason I'm doubtful
it would help much in practice.

--
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/ONQMUNJGLASTQCVC7WPAWXKTMENOW2HP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: inline Python functions and methods

[Greg Ewing]

On 9/12/21 12:03 am, Steven D'Aprano wrote:

does that mean that the compiler will translate the above to:

 def eggs(a, b, c):
 def spam(*args):
 # Do something with args...
 thing = spam(a, b, c)
 ...


If that's what's intended, it wouldn't really be an inline function.
And I doubt it would make any significant difference to speed,
because looking up the function is only a small part of what makes
function calls expensive in Python -- most of it is in the parameter
processing, which can get quite complicated.

What inlining usually means is to copy the body of the function
in place of the call, with appropriate parameter substitutions.

That would eliminate most of the overhead of a function call, but
there are problems with doing it in Python. Imported modules would
have to be located and parsed at compile time, something that doesn't
currently happen. And it can't be done in general-- the location of an
imported module isn't know for sure until run time, because changes
can be made dynamically to sys.path.

--
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/HOI6WUVSPEGJEYXEOKRTNIA42WVOZYNJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

[Greg Ewing]

On 2/12/21 4:40 am, Paul Moore wrote:

the
intended use is that people must supply a list[int] or not supply the
argument *at all*.


I don't think this is a style of API that we should be encouraging
people to create, because it results in things that are very
awkward to wrap.

--
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/TUQPAOSSNHGS5QZPWE7OQF5XF2IIUVBV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

[Greg Ewing]

On 27/11/21 11:34 am, Eric V. Smith wrote:

Would adding something to the Iterator ABC really also add it to my 
class Foo?


No, your class would need changing to inherit from the Iterator ABC.

This is a big problem in general with "just add it to the ABC" ideas.
A huge number of existing classes don't inherit from the relevant
ABC because there currently isn't any need to do so.

Fundamentally, Python is not organised around the concept of ABCs
the way some other languages such as Java are. Instead, it's
organised around informal protocols.

They're informal in the sense that there's no need to inherit from
a particular class in order to conform -- you just implement the
required methods and you're good to go.

As a consequence, there is strong pressure to keep the number of
required methods to a minimum. It also means that adding required
methods to a protocol late in the life of the language is effectively
impossible.

--
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/7DOHL2JEAJ454PT6MZWQ3ZSDG4GVPNOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

[Greg Ewing]

On 23/11/21 3:15 am, Remy wrote:

Iterators to implement 'transformational' functions like map, filter, flat_map, 
'reductional' functions like reduce, sum, join, and 'evaluate' functions like 
to_list and to_set.


This would place a burden on all iterators to implement a large
and complex interface. This goes directly against the philosophy of
Python protocols, which is to be as minimal as possible. Do one thing,
and do it well.

It would also be a huge backwards-incompatible change.

And where do you stop? You've picked an arbitrary subset of things
one might want to do with an iterator. Why those particular ones?
What about the contents of the itertools module? Should they be
included too? Why or why not?

--
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/JNFVFZT22ZMPAEHH2VG5NEHI3LAC33IB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Greg Ewing]

On 1/11/21 4:59 am, David Mertz, Ph.D. wrote:

     b = b


I don't want to live in a universe where this could be anything
other than a no-op in Python.

--
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/DLAGNLEB6GIGIP3OQ7YGVFP5S4RQ4STR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Invalidate list iterators after size changes?

[Greg Ewing]

On 9/10/21 11:24 am, Tyler Hou via Python-ideas wrote:

Right now, the following code is valid in Python 3.9 (and infinitely loops):

```
lst = [1, 2, 3]
for i in lst:
 lst.append(i)
```

1. If the size of a list, set, or dict changes, invalidate all existing 
iterators to that containers.


This would break Plex. I use a loop like that as part of the
NFA-to-DFA conversion to calculate the epsilon-closure of a
state (although obviously there are conditions on adding things
to the list that ensure it terminates).

--
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/MRSG4GVX5C6BFJFUURPA2FXARWBHTDE7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?

[Greg Ewing]

On 7/09/21 5:46 am, C. Titus Brown via Python-ideas wrote:

Maybe Greg missed that DictReader.open didn’t exist and was in fact what I was 
asking for!


Sorry about that, I thought you were asking for context manager methods
to be added to an existing file-like object.

If csv.DictReader had a close() method you could use closing() on it,
but it seems it doesn't, so closing() doesn't really help here.

--
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/SI55YOIAXFMWS5EUPXQZ4OZHYMQAHGNO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?

[Greg Ewing]

On 6/09/21 3:07 am, C. Titus Brown via Python-ideas wrote:

with csv.DictReader.open(filename) as r:
for row in r:
   …


You can do this now:

from contextlib import closing
with closing(csv.DictReader.open(filename)) as r:
   ...

IMO this is preferable than going around adding context manager
methods to everything that has open-like functionality.

--
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/RGCQJZSVMKBU36YK27XGXJI3OUQFBL2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Greg Ewing]

On 4/09/21 4:32 am, Guido van Rossum wrote:
The question is, would anyone ever want to make a distinction between 
the two in *real* code?


Another problem with this idea is that there isn't just one user
and one author. Library code often calls other library code written
by a different author, so a user error at one level is an implementation
error at another.

--
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/HDBNPF72K7RXWGKML4UDONDCGAQH36G4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Complete recursive pickle dump

[Greg Ewing]

On 27/08/21 11:27 pm, Evan Greenup via Python-ideas wrote:

If it contains function it will persist all its attribute, and code object.

For example, if user pickle recursively dump a numpy ndarray into a pickle 
file, when user pickle load this file from a system which doesn't install 
numpy, its method should all works properly like transpose, reshape ...


By design, pickle doesn't save code objects, but even if it did, most
of numpy is not written in Python, so it wouldn't help in that case.

You're effectively asking for pickling of binary machine code, which
would be very difficult to do. Even if you were successful, the
resulting pickle would be very closely tied to both a platform
and a particular version of Python and all its libraries.


As the example of numpy ndarray, when doing recursively dump, large part of 
numpy library's content will be persist except those really lose or none 
coupled part.


Selecting individual machine code routines out of numpy and saving
and restoring them individually is probably not feasible, so you
would have to just dump the whole lot as one binary blob. At that
point it would be a lot easier and more reliable just to tell the
user to install numpy.

--
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/5SSGKEOX43LIRPW6QND27OXY5EMJK3CW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Greg Ewing]

On 6/07/21 9:56 am, Jim Baker wrote:


d = deferred_tag"Some expr: {:(x*2)}"

All that is happening here is that this being wrapped in a lambda, which 
captures any scope lexically as usual.


Is there reason to think this will be a common enough requirement
to justify having an abbreviated syntax for a parameterless lambda
that's only available in template expressions?

--
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/LCDEAE5DLEJ6ELDT5XLBONO4ZZPHS3TO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Greg Ewing]

On 6/07/21 8:39 am, Guido van Rossum wrote:
FWIW, we could make f-strings properly nest  too... So this is 
not an argument for backticks.


An argument might be that single and double quotes currently do
not nest and never have done, so having them start to nest but only
in the context of f-strings could be confusing. Whereas backticks
are currently unused, and they used to nest back when they were
used, so giving them a new nesting usage will be unsurprising to
those with long enough memories.

--
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/K3HXQ26X7TAHABRETMU2EILG4EQ2CXK4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Flatten function (was: Deprecate sum of lists)

[Greg Ewing]

On 21/06/21 6:04 am, Sebastian Berg wrote:

* `flatten()` (alwasy copy)
* `ravel()` (copies if needed, and additionally ensures contiguity)
* `reshape(-1)` (copies if needed)

They are all subtly different, unfortunately.


There's also a .flat attribute, that returns a 1-d iterator!

--
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/K6MEDWIRNXK6ES5RKM22SESPZFNBHFWZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Greg Ewing]

On 9/04/21 2:59 am, anthony.flury via Python-ideas wrote:
I was wondering whether a worthwhile extension might be to allow the 
`with` statement to have an `except` and `else` clauses


I don't think I would find this very useful. My application-level
exception handling is rarely that close to the file operations,
it's usually at a much higher level.

--
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/OHZFRDHZZRLH25IXNUSQXFIF734I5773/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reverse polish notation

[Greg Ewing]

On 4/04/21 6:50 am, Chris Angelico wrote:

Algebra gives us a HIGHLY compact notation (far too compact to be
truly useful in computing, as it's very blackboard/paper oriented)


Anyone up for allowing Mathjax in Python source?

--
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/SYG5FQ4FRWK5TNGD2NVLZ27GPMFZZKUU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reverse polish notation

[Greg Ewing]

On 3/04/21 6:15 pm, David Mertz wrote:
It's a long time ago, but I'm pretty sure I used ticker tape adding 
machines with a big ENTER button to separate numbers... Then the 
operation, usually +, at the end.


That seems unlikely. If you don't tell it what to do with the
numbers until the very end, it needs a stack big enough to hold
all of them. Early RPN calculators typically had a very small
stack, usually about 4 items.

HP calculators had an ENTER button, but you only used it to
separate the first two numbers, then used + or whatever after
subsequent ones.


384
423
827
563 +
--


Isn't that what you learned in grade school?


Yes, but there the paper is your stack, and it's big enough to
hold quite a few numbers.

You were also probably taught to add the numbers up column by
column, which is quite different from the way a calculator or
computer does it!

I vaguely recall as a child using a mechanical one where you pulled a 
lever between lines as the "enter".


I wouldn't call that an "enter" lever, rather a "+" lever,
since it was almost certainly adding the entered number to
its accumulator. There will also have been some kind of
mode switch to make it subtract instead of add.

--
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/UTVPQ7PEMR7L34EWWG6K36GKULJAAQPW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reverse polish notation

[Greg Ewing]

On 3/04/21 5:07 pm, John wrote:

This fails when it's like b*((x*2^(3-a))-(7*c)), since
you now have to look back and forth and get a handle on what each of
the terms is.  b x 2 3 a - ** * 7 c * - * is pretty much a set of
steps (3 - a, raise 2 to that, multiply x by that, multiply 7 by c and
subtract from the former results, multiply all that by b).


Seems to me you're looking back and forth just as much here.
You're starting somewhere in the middle (how did you know to
start there?) then looking left for the 2 and right for the **,
then left for the x and right for the *, etc. etc. etc.

The fact that you have to mentally follow a set of steps is
a *disadvantage* of RPN for me. I can look at b*((x*2^(3-a))-(7*c))
and just *see* various things about it. For example, I can see
that 2 is raised to the power 3-a. I can see that b is multiplying
everything else. None of those things are obvious at a glance to
me from the RPN.

Sure, I can figure it all out, but it takes work, and I'm not
confident that I haven't made a mistake. Which means I'd much
rather audit an infix expression than an RPN one.

--
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/SHKTCOYDYDSXFKDHXWXQ647UKA5VFK4O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reverse polish notation

[Greg Ewing]

On 3/04/21 4:33 pm, David Mertz wrote:
add all these 20 receipts together without needing 19 "+" signs, but 
just one at the end.


Um, that's not the way any RPN calculator I've seen works. You
still need to press the "+" key 19 times, just in slightly
different places.

To get by with just one "+" you would need some way to bracket
the arguments, then you have something more like backwards Lisp
with at least as many parens as infix.

--
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/JGBUDC6HHQU4FBJSBDFXAIVBYUT5OFVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reverse polish notation

[Greg Ewing]

On 3/04/21 3:51 pm, John wrote:

Can't argue that long equations are hard to read.  The question is
which is harder.  A slew of parenthesis makes a mess that's difficult
to detangle.


In my experience, RPN is always harder to read than infix. A slew of
parens can be confusing, but a bunch of operators piled up at the end
of an expression doesn't make it any better for me.

I once had the need to write substantial amounts of Postscript by
hand (it was for Sun's NeWS window server), and I found it so tedious
and hard to get right that I devised an infix language and wrote a
compiler to translate it into Postscript. The project went much more
smoothly after that!

--
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/AJIZB63T2X64FKYK6PG3BRL7HOQ5GG4N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggesting feature for python - Big Set, Big Dictionary

[Greg Ewing]

On 24/03/21 7:47 am, Chris Angelico wrote:

On Wed, Mar 24, 2021 at 5:35 AM Vijay Patel  wrote:

>

Suggestion:
1. Big Set, Big Dictionary -

>

How would it be stored on disk? Would it be in some sort of database?
If so, check out a database access module


Also remember that virtual memory is a thing. If your Python data
structure is bigger than your RAM, it will get paged out to disk
anyway, so you might not need to do anything.

--
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/SFP2URO4Z3TNXTWPDRBLBJY32SUDDEGI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Multiple dispatch transpilation

[Greg Ewing]

On 17/03/21 2:54 am, Marvin van Aalst wrote:
it 
should in principle be possible to transform the code from 
|Class.method|to |method(class:type)|, *before compilation*essentially 
allowing the same optimizations.


I don't think this transformation would help with anything.
If the static analysis can work out what class of object a name
refers to, and what methods and attributes it has, it can
generate code that is just as efficient.

--
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/ZEWMGYXCXXRMXRJJ32TQP3U5V2OLMRGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Greg Ewing]

On 13/03/21 5:02 am, Ned Batchelder wrote:
I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  In 
those worlds, to keep the editing smooth, people moved the commas to the 
beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that.

--
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/4E5NN7ENLKMOS2IBAPC7FUXIKU3JBFZE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Integer concatenation to byte string

[Greg Ewing]

On 2/03/21 7:01 am, mmax42...@gmail.com wrote:

Currently, the only way to concatenate an integer to a bytes object is by 
converting the integer to bytes with a function call before concatenating.


No, it's not:

>>> b = bytearray()
>>> b.append(42)
>>> b
bytearray(b'*')


--
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/2UDCU5CZLTGQKU3WMEIIQ3QAXL3ZAD6I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

On 19/02/21 9:43 am, Steven D'Aprano wrote:

Although I have heard from Ruby enthusiasts that the ability to write
large, complex, multi-statement anonymous block functions is really
useful, its not something I can personally say I have missed.


Ruby may be somewhat different here, because Ruby's equivalent
of things like the iterator protocol work by passing in a block
of code representing the loop body, so having an easy way to
write that is important.

--
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/OWJSH7YOKDASTILTGNMPW4YTBGV3SZPU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

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

[Greg Ewing]

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

[Greg Ewing]

On 17/02/21 7:10 am, Steven D'Aprano wrote:

Its no more "magic" than tuple, deque, iterator,
coroutine, ordinal, modulus, etc, not to mention those ordinary English
words with specialised jargon meanings like float, tab, zip, thread,
key, promise, trampoline, tree, hash etc.


Actually, I think it is -- all those words build on a pre-existing
meaning in some way, and in most cases you can trace the etymology
back to something the person is most likely already familiar with.
Lambda, on the other hand, is a completely fresh arbitrary choice.

I agree that the technical meaning has to be taught in any case,
though.

--
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/WBTJLJ4NSARXBPJM4VYSJRVFIRT2DQHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

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." :-)

--
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/UW6436X65TGMC4D5ROIW4MH7GYUJQS5L/
Code of Conduct: http://python.org/psf/codeofconduct/