New assignmens ...

Avi Gross avigross at verizon.net
Thu Oct 28 13:36:10 EDT 2021


Antoon,

 

You keep beating a dead horse. NOBODY denies there are benefits to suggestions like the one we are describing. It is a logical fallacy to keep arguing this way.

 

And nobody (meaning me) suggests costs are a dominant factor in decisions no matter the benefits. The realistic suggestion is to not only weight costs and benefits for one proposal but for all reasonable proposals and then choose.

 

I have no idea what the actual cost of changing the parser is. It may be trivial or very nontrivial. I do not know if the actual chosen change, from a range of possible implementations, will leave the speed of typical programs untouched or will add lots of overhead for all programs including the ones not using this feature. Nor do I know how many existing features might clash with the choice of implementation and need to be changed to resolve them or face lots of bug reports later.

 

So what I and others have said here is not based completely on known and measured facts. But before approving a proposal, some analysis and estimates must be made including a decision to just cancel any work if it over-runs targeted costs of various kinds.

 

Now for a dumb question. Many languages allow a form of setting a variable to a value like:

 

                assign(var, 5+sin(x))

 

If we had a function that then returned var or the value of var, cleanly, then would that allow an end run on the walrus operator?

 

if (assign(sign, 5+sin(x)) <= assign(cosign, 5+cos(x))) …

 

Not necessarily pretty and I am sure there may well be reasons it won’t work, but I wonder if it will work in more places than the currently minimal walrus operator.

 

From: Antoon Pardon <antoon.pardon at vub.be> 
Sent: Thursday, October 28, 2021 3:03 AM
To: Avi Gross <avigross at verizon.net>; python-list at python.org
Subject: Re: New assignmens ...

 

 

Op 27/10/2021 om 20:20 schreef Avi Gross:

I think anyone who suggests we should separate costs from benefits belongs
securely within the academic world and should remain there.
 
Practical things need to be built considering costs. Theoretical things,
sure, cost is not an issue.

 
Seperating costs from benefits doesn't mean costs are not an issue. It means
you don't deny de benefits because there are costs. Sure in the end the costs
may outweight the benefits but that is still not the same as there being no
benefits at all.
 
If you want to weight the costs against the benefits you need to acknowledge
both and not start by denying the benefits because you presume they will
not outweight the costs.
 
-- 
Antoon.


More information about the Python-list mailing list