Aw: Re: The task is to invent names for things

[Karsten Hilbert]

> > I don't know. A mediocre name conveys at least some information, and
> > that seems to be better than none. On the other hand it might be just
> > enough to lead the reader astray which wouldn't happen with a
> > non-sensical name.

I was thinking that a nonsensical name might lead readers to
go beyond the name when trying to understand code, and would
prompt me to improve upon the name upon reading my own code (and
having acquired, likely, a better understanding of the concept
that's to be named).

Karsten

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: walrus with a twist :+= or ...

[Avi Gross via Python-list]

Correct, I left out a bit, not wisely.

I am trying to remember the last time (outside of classes) I have ever had
to use bitwise operators nontrivially and it may have been around 1980 when
I had to implement an encryption algorithm. Of course, when I was working in
UNIX, I often had to combine bitwise things to specify all kinds on 1-bit
flags when say opening a file. 

So we now have so many candidates FOR COMPLETENESS to add as variants of the
Walrus operator, that I might vote to do NONE of them, if anyone ever asked.

I do want to remind people though that these operators often serve a purpose
in Python as using them means you do not need to specify an argument twice
and you can specify some dunder methods that make it more efficient to type:

obj += obj2

rather than

obj = obj + obj2

So there may be a valid argument, not just about completeness, to implement
something BUT as we got along fine before a walrus came along, ...

or did we?


-Original Message-
From: Python-list  On
Behalf Of MRAB
Sent: Wednesday, October 27, 2021 9:21 PM
To: python-list@python.org
Subject: Re: walrus with a twist :+= or ...

On 2021-10-28 02:06, Avi Gross via Python-list wrote:
> I just realized I left out **= so my apologies. Are there other such 
> abbreviations and does anyone use them?
> 
You forgot about the bitwise operators: |=  &=  ^=

> -Original Message-
> From: Python-list 
>  On Behalf Of Avi 
> Gross via Python-list
> Sent: Wednesday, October 27, 2021 8:57 PM
> To: python-list@python.org
> Subject: walrus with a twist :+= or ...
> 
> I realized that the person seeking completeness in Python may next ask 
> why the Walrus operator, :=, is not properly extended to include a 
> whole assortment of allowed assignment operators
>   
> 
> I mean in normal python programs you are allowed to abbreviate
> 
> x = x + 5
> 
> with
> 
> x += 5
> 
> Similarly you have other operators like
> 
> x *= 2
> 
> And, of course, the constantly used operator:
> 
> x %= 2
> 
> So how does one extend a walrus operator if they ever decide to give 
> in and add it to the language just for completeness?
> 
> Sadly, a simple test shows they neglected to use a :+= operator in the
> latest:
> 
 (walrus := 2)
> 
> 2
> 
 walrus
> 
> 2
> 
 (wallrus :+= 2)
> 
>File "", line 1
> 
>  (wallrus :+= 2)
> 
>   ^
> 
> SyntaxError: invalid syntax
> 
> (Yes, I know how to spell walrus, but making a point.)
> 
> On a serious note, if it was ever considered a good idea, what would 
> be an acceptable sequence of symbols that might not break or confuse 
> existing programs and what would we call it? I mean what animal, of
course.
> 
> What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=
> 
> Or do we not just add a colon in front and make it a tad different as in
:=+
> or :+=:   or maybe realize the futility of perfection! After all, you can
> easily use some functions to get a result such as:
> 
> x := func(x, "+", 5)
> 
> x := func_add(x, 5)
> 
> or many other work-arounds.
> 
> Can we all forget I asked? I am sort of being sarcastic.
> 
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Abdur-Rahmaan Janhangeer]

@Chris @Peter


See that famous benchmark

https://www.techempower.com/benchmarks/#section=data-r20

Like routinely PHP frameworks appear higher up than py
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: walrus with a twist :+= or ...

[Avi Gross via Python-list]

My apologies, again. I got Chris going and although quite humorous, we may
want to allow a slew of emoticons!

But a serious question is now that we sort of have UNICODE, and even many
editors and other programs support it, perhaps it might make sense for some
operations in computer languages to make use of them. Some languages might
replace something like <- with an arrow symbol and those with special
symbols like Inf might use the infinity symbol instead. More importantly,
adding new operators might get easier. Some existing languages like APL used
overstrikes to create some symbols. Some languages have a built-in extension
method such as R that allows you to create arbitrary functions by placing
them between % signs as in %>% or %percentile% 

If Python wanted to add more flexibility than admittedly it already has,
then possibly something like I jokingly suggested as a walrus version of :=
might be doable by just defining some new function bound to a symbol which,
when run, is told of the operands on either side. 

But dreaming aside, from an academician and programmer as well as a lazy bum
side of me, it is often perhaps easiest to design a new language practically
from scratch with ideas that it completely follow the paradigms you want.
SCALA is an example among others. Both a strength and weakness in Python as
it has grown is that it does so many things in so many ways as more and more
is grafted on. The relatively few existing symbols are overloaded too much
so it takes some context to figure out when a : or parenthesis or even %
sign means one of multiple things. The recent discussion sort of highlighted
how a comma meaning multiple things may be confusing. if we extend a
feature. 

One reasonable design might be to expand the allowed symbols and use them as
needed. A colon might be used only one way. If you need a :: operator, it
can be a single token and a single character, perhaps clearly having the two
parts closer together or one part slightly raised or lowered. A += and >=
operator may again be the one symbol version so that + and = always mean the
same thing.

But it is a tad too late to make an existing language or users on existing
keyboards, do this. A language course I am using makes compromises so using
a partial pop-up keyboard lets me select characters with special twists like
an umlaut rather than showing a plain U or perhaps a :U instead of Ü or
allowing an SS to be typed instead of ß. When used on character-only
scenarios, obviously you let the users mis-spell these ways but that is not
an ideal way to learn a language or write in it.

-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Wednesday, October 27, 2021 9:11 PM
To: Python 
Subject: Re: walrus with a twist :+= or ...

On Thu, Oct 28, 2021 at 11:58 AM Avi Gross via Python-list
 wrote:
> On a serious note, if it was ever considered a good idea, what would 
> be an acceptable sequence of symbols that might not break or confuse 
> existing programs and what would we call it? I mean what animal, of
course.
>
>
>
> What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=
>

What we need is a few more generic operators that can be put together
appropriately. For instance, when you need a copy of a list, you can use the
"robot face" operator:

stuff[:]

Perhaps we need some more slice variants. We can already grin:

stuff[
:D
]

and stick out our tongues:

stuff[
:P
]

and even gasp in surprise:

stuff[
:O
]

but the language has an emotional bias towards sadness:

stuff[
:(
)]

since there's no corresponding happiness emoji, nor even ambivalence:

stuff[
:|
]

However, a wry smile is permitted.

stuff[
:\
]

The lack of language support for such a fundamental emotion as happiness is
a major flaw and needs to be corrected ASAP.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Chris Angelico]

On Thu, Oct 28, 2021 at 11:55 AM Eli the Bearded <*@eli.users.panix.com> wrote:
> The choice of a non-sensical is perfectly fine _when_ it's a major
> component. Kafka, Python, Java, Rust. Those are all non-sensically named,
> in that the name doesn't fit what it is, by pun, initials, or reference.
> Someone just liked the name and applied it to thing being build. The
> designer of Kafka liked the author. Guido liked Monty Python. Java is
> named for coffee. Rust is named for a fungus.
>
> Those all work. But if you are writing a new web framework and you name
> your method to log stuff to a remote server "Britney" because you were
> listening the singer, that's not perfectly fine, even you want to make
> "Oops, I did it again" jokes about your logged errors.
>

More generally: You can pick any name you like if the identity of your
creation is, well, entirely your creation. What does "Python" mean in
terms of programming languages? It means exactly what Guido and the
subsequent developers made of it. What's LPC? Originally, "Lars Pensjo
C". But it became "this language", if that makes sense. I'm known as
"Rosuav". What does that word mean? It means me. Nothing more and
nothing less.

But when you need the name to evoke some other meaning, you need to be
as close as possible to that meaning. Obviously that's never going to
be perfect, but the closer you can come, the more useful the name will
be. The purest example would be "X meets Y" names, like a Python
interface to libcurl called pycurl. Nobody has any doubts or
disagreements about what that name means!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: walrus with a twist :+= or ...

[MRAB]

On 2021-10-28 02:06, Avi Gross via Python-list wrote:

I just realized I left out **= so my apologies. Are there other such
abbreviations and does anyone use them?


You forgot about the bitwise operators: |=  &=  ^=


-Original Message-
From: Python-list  On
Behalf Of Avi Gross via Python-list
Sent: Wednesday, October 27, 2021 8:57 PM
To: python-list@python.org
Subject: walrus with a twist :+= or ...

I realized that the person seeking completeness in Python may next ask why
the Walrus operator, :=, is not properly extended to include a whole
assortment of allowed assignment operators
  


I mean in normal python programs you are allowed to abbreviate

x = x + 5

with

x += 5

Similarly you have other operators like

x *= 2

And, of course, the constantly used operator:

x %= 2

So how does one extend a walrus operator if they ever decide to give in and
add it to the language just for completeness?

Sadly, a simple test shows they neglected to use a :+= operator in the
latest:


(walrus := 2)


2


walrus


2


(wallrus :+= 2)


   File "", line 1

 (wallrus :+= 2)

  ^

SyntaxError: invalid syntax

(Yes, I know how to spell walrus, but making a point.)

On a serious note, if it was ever considered a good idea, what would be an
acceptable sequence of symbols that might not break or confuse existing
programs and what would we call it? I mean what animal, of course.

What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=

Or do we not just add a colon in front and make it a tad different as in :=+
or :+=:   or maybe realize the futility of perfection! After all, you can
easily use some functions to get a result such as:

x := func(x, "+", 5)

x := func_add(x, 5)

or many other work-arounds.

Can we all forget I asked? I am sort of being sarcastic.


--
https://mail.python.org/mailman/listinfo/python-list

Re: walrus with a twist :+= or ...

[Chris Angelico]

On Thu, Oct 28, 2021 at 11:58 AM Avi Gross via Python-list
 wrote:
> On a serious note, if it was ever considered a good idea, what would be an
> acceptable sequence of symbols that might not break or confuse existing
> programs and what would we call it? I mean what animal, of course.
>
>
>
> What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=
>

What we need is a few more generic operators that can be put together
appropriately. For instance, when you need a copy of a list, you can
use the "robot face" operator:

stuff[:]

Perhaps we need some more slice variants. We can already grin:

stuff[
:D
]

and stick out our tongues:

stuff[
:P
]

and even gasp in surprise:

stuff[
:O
]

but the language has an emotional bias towards sadness:

stuff[
:(
)]

since there's no corresponding happiness emoji, nor even ambivalence:

stuff[
:|
]

However, a wry smile is permitted.

stuff[
:\
]

The lack of language support for such a fundamental emotion as
happiness is a major flaw and needs to be corrected ASAP.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: walrus with a twist :+= or ...

[Avi Gross via Python-list]

I just realized I left out **= so my apologies. Are there other such
abbreviations and does anyone use them?

-Original Message-
From: Python-list  On
Behalf Of Avi Gross via Python-list
Sent: Wednesday, October 27, 2021 8:57 PM
To: python-list@python.org
Subject: walrus with a twist :+= or ...

I realized that the person seeking completeness in Python may next ask why
the Walrus operator, :=, is not properly extended to include a whole
assortment of allowed assignment operators

 

I mean in normal python programs you are allowed to abbreviate

 

x = x + 5

 

with

 

x += 5

 

Similarly you have other operators like

 

x *= 2

 

And, of course, the constantly used operator:

 

x %= 2

 

So how does one extend a walrus operator if they ever decide to give in and
add it to the language just for completeness?

 

Sadly, a simple test shows they neglected to use a :+= operator in the
latest:

 

>>> (walrus := 2)

2

>>> walrus

2

>>> (wallrus :+= 2)

  File "", line 1

(wallrus :+= 2)

 ^

SyntaxError: invalid syntax

 

(Yes, I know how to spell walrus, but making a point.)

 

On a serious note, if it was ever considered a good idea, what would be an
acceptable sequence of symbols that might not break or confuse existing
programs and what would we call it? I mean what animal, of course.

 

What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=  

 

Or do we not just add a colon in front and make it a tad different as in :=+
or :+=:   or maybe realize the futility of perfection! After all, you can
easily use some functions to get a result such as:

 

x := func(x, "+", 5)

x := func_add(x, 5)

 

or many other work-arounds.

 

Can we all forget I asked? I am sort of being sarcastic.

 

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

walrus with a twist :+= or ...

[Avi Gross via Python-list]

I realized that the person seeking completeness in Python may next ask why
the Walrus operator, :=, is not properly extended to include a whole
assortment of allowed assignment operators

 

I mean in normal python programs you are allowed to abbreviate

 

x = x + 5

 

with

 

x += 5

 

Similarly you have other operators like

 

x *= 2

 

And, of course, the constantly used operator:

 

x %= 2

 

So how does one extend a walrus operator if they ever decide to give in and
add it to the language just for completeness?

 

Sadly, a simple test shows they neglected to use a :+= operator in the
latest:

 

>>> (walrus := 2)

2

>>> walrus

2

>>> (wallrus :+= 2)

  File "", line 1

(wallrus :+= 2)

 ^

SyntaxError: invalid syntax

 

(Yes, I know how to spell walrus, but making a point.)

 

On a serious note, if it was ever considered a good idea, what would be an
acceptable sequence of symbols that might not break or confuse existing
programs and what would we call it? I mean what animal, of course.

 

What do these look like in some fonts? :+=   :-=   :*=   :/=   :%=  

 

Or do we not just add a colon in front and make it a tad different as in :=+
or :+=:   or maybe realize the futility of perfection! After all, you can
easily use some functions to get a result such as:

 

x := func(x, "+", 5)

x := func_add(x, 5)

 

or many other work-arounds.

 

Can we all forget I asked? I am sort of being sarcastic.

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Eli the Bearded]

In comp.lang.python, Peter J. Holzer  wrote:
 ^^

> On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote:
>> In that situation, is it preferable to choose a nonsensical
>> name over a mediocre one ?
> I don't know. A mediocre name conveys at least some information, and
> that seems to be better than none. On the other hand it might be just
> enough to lead the reader astray which wouldn't happen with a
> non-sensical name.

C is named as a pun on the earlier B, which was derived from BCPL, the
Barely Complete Programming Language. Unix is a pun on Multix, Linux
a personalization of Unix. sed is a portmanteaux of "stream editor".
AWK is named for the authors' initials. Perl started out as an
initialism (Practical Extraction and Report Language, I think), which
the manpage used to lead with. Ruby is named as a play on Perl, it's a
different four letter gem, and Ruby has obvious Perl influence.

But "Python"? What's Python named for? Hint, it's a pretty "non-sensical
name" for a computer language.

> But since perfect names are hard to find, using nonsensical instead of
> mediocre names would mean choosing nonsensical names most of the time.
> So I'll stick with mediocre names if in doubt.

The choice of a non-sensical is perfectly fine _when_ it's a major
component. Kafka, Python, Java, Rust. Those are all non-sensically named,
in that the name doesn't fit what it is, by pun, initials, or reference.
Someone just liked the name and applied it to thing being build. The
designer of Kafka liked the author. Guido liked Monty Python. Java is
named for coffee. Rust is named for a fungus. 

Those all work. But if you are writing a new web framework and you name
your method to log stuff to a remote server "Britney" because you were
listening the singer, that's not perfectly fine, even you want to make
"Oops, I did it again" jokes about your logged errors.

Where naming has a great importance to understanding, it needs to be
done carefully. Mediocre names work, but can be confusing. For the
remote logging example, there's probably not a lot of difficulty with
mediocre. If you're doing something with a multiple of things, do you
call it a "pod", "cluster", "group", "set", etc? You can pick one but
then when you have multiples of multiples, you'll want to pick another
and if you do it wrong it will confuse people. A Kubernetes "cluster"
will run replica "sets" of "pods" (each of which have one or more
"containers", but "containers" is a word that predates Kubernetes).

If your framework runs "sets" of "clusters" that reversal of heirarchy
ends up being more likely to confuse. Or look at the mess that AWS has
for Elasticache Redis: you can have a "cluster" that provides redundancy
in case something fails. Or you can run in "cluster mode" which shards
the data across multiple independent nodes. If you want redundancy
in "cluster mode" you can can have groups of replicas.

Redis no replication or sharding:   Node

Redis non-cluster mode cluster: Node Replica-Node1 ...

Redis cluster mode cluster no replicaion:
Shard-1-Primary-Node
Shard-2-Primary-Node
...

Redis cluster mode cluster with replicas:
Shard-1-Primary-Node Shard-1-Replica-Node-1 ...
Shard-2-Primary-Node Shard-2-Replica-Node-1 ...
...

Maybe this is Redis's fault or maybe it's AWS's, I don't know the
history of these names, I've only used it on AWS. But whoever did the
naming did a "mediocre" job to come up with something that's called a
"Redis cluster-mode enabled cluster".

https://aws.amazon.com/blogs/database/work-with-cluster-mode-on-amazon-elasticache-for-redis/

Elijah
--
naming is hard, unless it's easy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Thu, Oct 28, 2021 at 11:08 AM Avi Gross via Python-list
 wrote:
>
> Dave,
>
> You make me wonder about unintended side effects. Are we allowing the ++ and
> --- operations into Python through a side door?
>

class IncrementableInteger(int):
def __pos__(self): return HalfIncremented(self)
def __neg__(self): return HalfDecremented(self)

class HalfIncremented(IncrementableInteger):
def __pos__(self): return IncrementableInteger(self + 1)

class HalfDecremented(IncrementableInteger):
def __neg__(self): return IncrementableInteger(self - 1)

Up to you to make the actual mutation work but have fun making a
nightmare for subsequent maintainers!

ChrisA
PS. Nobody's ever stopping you from def __add_(self, other): return
self * other + 3
Just sayin'.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New assignmens ...

[Avi Gross via Python-list]

Dave,

You make me wonder about unintended side effects. Are we allowing the ++ and
--- operations into Python through a side door?

any context that allows you to insert the walrus operator like:

index := index + 1
index := index - 1

Is now similar to notations in C/C++ and others like 
++index
--index

If you can set or reset a variable this way, it can even look more efficient
that counting by 2 or more which in C would look like:

++(++index)

Of course we now would get suggestions to just add the pre-increment
operator to Python, and while we are added, for completeness, add the
post-increment version of index++ ...

I mean if cost is no object, and worrying how it may impact current programs
or conflicts is nothing to be concerned about in the interest of some
academic purity ...


-Original Message-
From: Python-list  On
Behalf Of dn via Python-list
Sent: Wednesday, October 27, 2021 4:38 AM
To: python-list@python.org
Subject: Re: New assignmens ...

On 24/10/2021 22.23, O365 Dict wrote:
> Well I have the following use case:
> 
> while (temp_result := calculate_next_couple(a, b))[1]:
> a, b = temp_result
> more calculations
> 
> Which IMO would be clearer if I could just write:
> 
> while ((a, b) := calculate_next_couple(a,b))[1]:
> more calculations
> 
> Of course it would even more clear if I could write something like:
> 
> while (a, b) := calculate_next_couple(a, b); b:
> more calculations
> 
> or
> 
> do:
> a, b = calculate_next_couple(a, b)
> while b:
> more calculations


Found (all of) the above less-than-obvious to read. Putting it in front of
trainees this morning caused only confusion - even the currently-legal
variation.


Accordingly: is this a job for the walrus operator at all? Let's "talk of
many [other] things"*.


Is this an algorithmic complexity, or a complicated way to look at (and
manipulate) data?

Well, judging from the code (above), use of the walrus certainly presumes
the former. Instead let's review any possibility of the latter (if only for
academic interest)...


What do we want out of the first line? (in no particular order)

1 use calculate_next_couple() to compute (new) a from an (old) a and b
2 use calculate_next_couple() to compute (new) b from an (old) a and b
3 use (new) b to decide if the loop should execute or terminate

The 'problem' then, has been phrased as these three objectives ask too much
of the (current implementation of the) walrus-operator.


NB after one (or more) cycles, when the loop 'returns to the top', what I've
termed 'new' a and b (above), will become (my reference) the 'old'
pair/tuple.


That all looks simple. What is dn complaining about?


Could we use a data structure to continue to keep things straight-forward?

class my_class():
def __init__( self, a, b )->None;
self.a = a
self.b = b

instance = my_class( a, b )


Sorry, you're probably becoming impatient with me. Surely I'm typing more
code than necessary? Maybe, but there are other measures of
code-quality/good-practice/etc, and there's likely more to 'it' than just
these few lines...


First consideration: the algorithm needs us to 'feed' the while-condition.
So let's flesh-out:

def is_more( self )->bool:
# you know what goes here - I don't, but that's not the issue
# the return value is all that matters
return is_there_any_more_data_to_calculate?

In which case, the loop becomes:

while instance.is_more():
more calculations

and 'readability' improves immeasurably!

NB for extra credit, turn the boolean function into a "property", and be
able to omit the (unsightly?) parentheses from the 'call'!


But, not so fast - what about the calculation itself, currently embedded in
calculate_next_couple()?

Well, those details are out of my sight, and I'm assuming include reasonable
complexity - otherwise you wouldn't propose this as a good-example. Allow me
to muddle-through with:

def calculate_next_couple( self )->None:
self.a = calculation of 'new' a
self.b = calculation of 'new' b

To avoid an 'extra' call against the instance from the while-loop, execute
the 'calculate' method from either __init__() or is_more(), as appropriate
(given that it likely needs to precede the return from the latter -
particularly if the computation is 'expensive'). The choice may be
subject-dependent ...


Now within "more calculations", one assumes, references to "a" and "b"
will need to be amended to become 'instance.a' and 'instance.b'. More
typing! What about preserving our fingers?


Readability will further improve when "a" and "b" (etc) are replaced by
'real names'.

The processing steps within "more calculations" could be reviewed. Some may
be candidates for inclusion as my_class methods - which would even enable
further simplifications and/or encapsulation of code-suites relevant to the
application, and/or "a" and 

RE: Create a contact book

[Avi Gross via Python-list]

I used to be on the Tutor list for python and found it was not for me. Yes, we 
should refer people there especially those who seem to have HW and would like 
some gentle coaching but not outright answers.

What frustrated me is that rarely would we be told by people what they had 
learned and were allowed to use. Beginners rarely are supposed to use advanced 
features or modules like numpy or pandas or often even list comprehensions. 
Most conversations there have to be a back and forth asking questions and 
waiting for answers and repeat ad nauseum. Or give them general advice like 
what kinds of data structures and algorithm they think make sense before making 
an actual program, then finding out what python commands and techniques would 
be useful. The idea is to have them show us their solution and point out what 
may be wrong or bridge a minor gap or explain an error message. It was not 
really a place to discuss language design like here, or offer obscure 
algorithms for finding primes. It is more a place where you might program the 
Sieve of Ἐρατοσθένους more plainly and simply! LOL!

The reality is that many forms of "assistance" do verge on cheating BUT anyone 
with a browser can now find tons of information on so many things online. I 
just did a search with these words:

"python prime numbers from 1 to 100 "

I found answers ranging from complete to hints.  Other similar requests 
returned plenty more.

So why ask here? Why waste the valuable time of so many (albeit mine is not 
that valuable, LOL) when most here probably have no interest?

And, if someone here answered, would that make it less or more likely they were 
caught if anyone wondered why their answer was so good?

I do not mind helping people when I have the time and inclination and 
especially not if the request is properly shown and it is easy to maybe even 
copy and run it and quickly see some minor thing they were not aware of. But 
spending days tutoring someone who starts seeming to know very little, not 
something I want to do.

If I wanted, I might even get $15 an hour tutoring any number of subjects, but 
then again, a job at McDonalds might pay as well and with benefits. 

My view is that the goal of Education includes learning how to do it by 
yourself, or do something similar again after getting minimal help. People 
taking classes should normally have enough local help.

-Original Message-
From: Python-list  On 
Behalf Of dn via Python-list
Sent: Wednesday, October 27, 2021 12:15 AM
To: python-list@python.org
Subject: Re: Create a contact book

On 27/10/2021 04.16, Avi Gross via Python-list wrote:
> Chris,
> 
> I think it is time someone set up a business where they do the 
> homework for people for a mere $1,000 or so per hour. Anonymously, of 
> course. And we can refer requests for free homework advice there.
> 
> Maybe the answer to this request is to suggest they use FACEBOOK which 
> seemingly keeps you in contact and lets you add friends and view them 
> 
> On Tue, Oct 26, 2021 at 5:30 PM anders Limpan  wrote:
>>
>> i would like to create a contact book were you can keep track of your 
>> friends. With this contact book you will both be able to add friends 
>> and view which friends that you have added. anyone interested in 
>> helping me out with this one ?=)
>>
> 
> Here at Homeworks Anonymous, the first step is admitting that what you 
> have is a homework problem. :) This isn't a project, this is something 
> you're doing for a course, and it's not really fair to pretend 
> otherwise :)
> 
> ChrisA


It's a balancing-act:
- on the one hand writing (their) code is not helping a trainee to learn (and 
certainly not in the manner the trainer intended)
- on the other, we should try to welcome and encourage new-comers to our 
list/the Python eco-system.

That said, I've often recommended folk switch/also subscribe to the Tutor list, 
but can't say if many actually did.


"Essay Mills" are back in the news in the UK with a proposal to make them 
completely illegal. The Times Educational Supplement printed an article 
two~three weeks ago 
(https://www.timeshighereducation.com/student/advice/tempted-pay-your-essays-here-are-six-reasons-not
- likely behind a pay-wall - if so, apologies).

The author identified six reasons for not using an Essay Mill:
(the labels are his, the summaries beyond them are mine)


1 Harsh penalties - if caught

2. Fool no more - plagiarism software these days is not only comparing 'this 
work' with others' assignment returns, but this with your other submissions, ie 
noting if your personal writing style changes!

3. Career impact - how it impacts employment (possibilities) if such is either 
on your record or becomes evident later

4. On the record - if the 'mill' has your record, what if they're hacked? Do 
they have better security than the many organisations which have been breached?

5. No guarantee of anonymity - your shadow-author will have a 'hold'
over you, fore

Re: The task is to invent names for things

[Peter J. Holzer]

On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote:
> Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:
> > xyzzy = lambda x: 2 * x
> >   . Sometimes, this can even lead to "naming paralysis", where
> >   one thinks excessively long about a good name. To avoid this
> >   naming paralysis, one can start out with a mediocre name. In
> >   the course of time, often a better name will come to one's mind.
> 
> In that situation, is it preferable to choose a nonsensical
> name over a mediocre one ?

I don't know. A mediocre name conveys at least some information, and
that seems to be better than none. On the other hand it might be just
enough to lead the reader astray which wouldn't happen with a
non-sensical name.

But since perfect names are hard to find, using nonsensical instead of
mediocre names would mean choosing nonsensical names most of the time.
So I'll stick with mediocre names if in doubt.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[dn via Python-list]

On 27/10/2021 23.41, Karsten Hilbert wrote:
> Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:
> 
>> xyzzy = lambda x: 2 * x
>>
>>   . Sometimes, this can even lead to "naming paralysis", where
>>   one thinks excessively long about a good name. To avoid this
>>   naming paralysis, one can start out with a mediocre name. In
>>   the course of time, often a better name will come to one's mind.
> 
> In that situation, is it preferable to choose a nonsensical
> name over a mediocre one ?


I've often debated this with myself - it's related to adding:

"""Docstring."""

immediately after typing a class/function/method definition - because my
head is too full of the code to be written - and those linters can be
clamorously insistent!

Thus, isn't the answer "yes!".


Cognitive over-load is the issue: We can only hold so many thoughts
in-mind at a given point in time.
(the size of "many" being up for debate, highly variable between
individuals, and between the same person at different times or under
different conditions - see also "in the zone")


With today's powerful IDEs, in particular Find-and-Replace-All functions
(noted that PyCharm has a Refactor facility which includes such, and
with code-aware 'intelligence' cf 'blind' string-matching), it really is
easier to go with a 'first thought name' and the promise of re-visiting
the choice later.

When 'later' arrives, eg when the value is being utilised differently
(an earlier comment in this thread), there is a natural/QA process to
(re-)think the name according to its different aspects over time.


That said... there is a risk that you (OK, "I") don't re-visit the
choice and "asdf" (easy for US-keyboard users) 'slips through' to Code
Review. Oops! You do Code Review don't you?


An opposing thought might be that if you have sat-down and sketched-out
a design - a high-level 'how' you are going to deliver the requirements,
many 'names' will be 'set' during that process - I think an integral
component of Domain-Driven Design (DDD) philosophy.

An eminently-sensible piece of advice underlying such thinking is that
the spec/requirement should be written in the user's terms (those of the
"domain"). Thus, the easiest (and accuracy/consistency promoting) path,
is to maintain the use of that terminology/names all the way through
from spec to code.

Above also reduces my cognitive load - an appealing characteristic for
such a lazy "bear of little brain"...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Chris Angelico]

On Thu, Oct 28, 2021 at 7:54 AM Karsten Hilbert  wrote:
>
> Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico:
>
> > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:
> > >
> > > > Many operations in computing are fully reversible. After you do
> > > > something, you can undo it. After you assign, you can unassign. And
> > > > after you ite, you can unite!
> > >
> > > I wonder whether Japanese programmers would agree.
> >
> > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate?
>
> ite is the -te form (in some uses like a gerundium) of aru
> (to go, to walk)
>
> so, to un-go, revert-the-having-gone-ness, I genuinely wonder ...
>
> On the other hand, Japanese is full of wondrous word-play at
> levels undreamt of by us ASCIInarians.
>
Ah ha, neat :) Thank you.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 12:41:56PM +0200 schrieb Karsten Hilbert:

> Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:
>
> > xyzzy = lambda x: 2 * x
> >
> >   . Sometimes, this can even lead to "naming paralysis", where
> >   one thinks excessively long about a good name. To avoid this
> >   naming paralysis, one can start out with a mediocre name. In
> >   the course of time, often a better name will come to one's mind.
>
> In that situation, is it preferable to choose a nonsensical
> name over a mediocre one ?

That one was a genuine question, BTW, not a snark remark.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico:

> > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:
> >
> > > Many operations in computing are fully reversible. After you do
> > > something, you can undo it. After you assign, you can unassign. And
> > > after you ite, you can unite!
> >
> > I wonder whether Japanese programmers would agree.
>
> Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate?

ite is the -te form (in some uses like a gerundium) of aru
(to go, to walk)

so, to un-go, revert-the-having-gone-ness, I genuinely wonder ...

On the other hand, Japanese is full of wondrous word-play at
levels undreamt of by us ASCIInarians.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Peter J. Holzer]

On 2021-10-27 23:49:59 +0400, Abdur-Rahmaan Janhangeer wrote:
> See this:
> https://github.com/walkor/webman
> 
> Why similar frameworks do not exist in Python. Is it because
> of lack of lib contributors or due to an inherent difference in Py
> and PHP? Thanks!

The comparison table contains only PHP based frameworks.

How do you know that no Python based frameworks of similar performance
exist?

(And is the benchmark even meaningful?)

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Chris Angelico]

On Thu, Oct 28, 2021 at 6:52 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> See this:
> https://github.com/walkor/webman
>
> Why similar frameworks do not exist in Python. Is it because
> of lack of lib contributors or due to an inherent difference in Py
> and PHP? Thanks!
>

It depends entirely on what that benchmark is measuring, and how
tightly that framework was optimized for the benchmark. In real-world
code, performance is seldom dictated by the framework. I can get
100TPS with naive code on a naive database implementation, and
improving that is going to be more about improving the database or the
application rather than the framework.

Of course, tools that can't brag about readability, usability,
maintainability, etc, will naturally brag about their benchmark
results, regardless of how significant - or otherwise - they really
are.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does loading PDB slow down execution?

[Peter J. Holzer]

On 2021-10-27 15:47:08 -0400, Benjamin Schollnick wrote:
> > On Oct 27, 2021, at 1:01 PM, Unixnut  wrote:
[...]
> > Excellent, many thanks for confirming. I can leave the execution running 
> > then.
> 
> But it’s pointless to import pdb, if you aren’t going to use it.

Please read the first mail in this thread.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Why so fast a web framework?

[Abdur-Rahmaan Janhangeer]

See this:
https://github.com/walkor/webman

Why similar frameworks do not exist in Python. Is it because
of lack of lib contributors or due to an inherent difference in Py
and PHP? Thanks!

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does loading PDB slow down execution?

[Benjamin Schollnick]

> On Oct 27, 2021, at 1:01 PM, Unixnut  wrote:
> 
> On 06/10/2021 18:30, Dieter Maurer wrote:
>> Unixnut wrote at 2021-10-3 22:03 +0100:
>>> If I run a python3 program with "import pdb" in the code, would it
>>> execute slower than without loading the debugger?
>> Importing `pdb` does not slow down the application significantly
>> (it just adds the import time but does not otherwise affect the
>> application).
>> Only when you execute code under debugger control, the
>> execution is significantly slowed down (because the debugger
>> gets informed (via callbacks) about important "event"s (entering
>> a line, function call, function return, exception) during
>> the execution).
> Excellent, many thanks for confirming. I can leave the execution running then.

But it’s pointless to import pdb, if you aren’t going to use it.

I would suggest that a best practice would be to only import pdb, if and when 
you were going to be performing the debugging.
(So maybe set a boolean constant, that would cause the import, and debugging 
code to be executed.

-- 
https://mail.python.org/mailman/listinfo/python-list

Get a Joke in Python

[Python 4 Fun]

Get a Joke in Python. Pyjokes - is a python library / module for one line joke 
program based on programmers. You can get funny one-liner random jokes at every 
run also available in following " languages " & " categories ". Supported 
Languages By Pyjokes English — ‘en’ Spanish — ‘es’ Italian — ‘it’ German — ‘de’ 
Galician — ‘gl’ Basque — ‘eu’ Categories Included In Pyjokes For geeky jokes 
-’neutral’ (It is chosen by default) For Chris Norris Jokes — ‘chuck’. If you 
want all type of jokes — ‘all’ There is one more category known as ‘twister’ 
which only works for the German Language (‘de’) and mostly includes tongue 
twister. Read the documentation available on https://pyjok.es for more info. 
:::Lets Code::: Install pyjokes if you haven't  pip install pyjokes This 
Program will give you one-liner Joke #pip install pyjokes # importing module i
[Read More...]

https://pysnakeblog.blogspot.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Abdur-Rahmaan Janhangeer]

I no longer track the threads on the subject ... Many simultaneous ones
ongoing!

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Thu, Oct 28, 2021 at 4:34 AM Christman, Roger Graydon  wrote:
> Do you put special code in next_couple() to recognize that the provided 
> arguments
> are actually the first couple so it can return those unmodified, but then 
> require its
> own mental note not to give you an infinite loop forever returning that first 
> couple?
>
> Do you have to define a special case such as (a,b) = (0,0) or (None,None) to 
> tell
> next_couple that you really want the first one?   That seems a little 
> counter-intuitive
> to have something named "next" need a special input to mean "first",

In some cases, there is a very real special startup value (a seed).
For instance, if we're calculating something relating to the
Mandelbrot set:

# The point we're working with
c = (0.25 + 0.125j)
# Always start here
z = (0 + 0j) # or just 0
while abs(z := z*z+c) < 2:
...


Though in this case, you don't look for a next_couple, you look for a
single next value, and the other value is constant.

But it all depends on the exact process being done, which is why I've
been asking for real examples.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does loading PDB slow down execution?

[Unixnut]

On 06/10/2021 18:30, Dieter Maurer wrote:

Unixnut wrote at 2021-10-3 22:03 +0100:

If I run a python3 program with "import pdb" in the code, would it
execute slower than without loading the debugger?


Importing `pdb` does not slow down the application significantly
(it just adds the import time but does not otherwise affect the
application).

Only when you execute code under debugger control, the
execution is significantly slowed down (because the debugger
gets informed (via callbacks) about important "event"s (entering
a line, function call, function return, exception) during
the execution).

Excellent, many thanks for confirming. I can leave the execution running 
then.

--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Thu, Oct 28, 2021 at 4:03 AM Antoon Pardon  wrote:
>
> So suppose I have an arbitrary number of simple statements. The
> latter possible using results from previous assignment and at the
> end a condition to control the one and a half loop. How do you write
> the python code so that the one and a half loop is easy to recognize?
>

The most general way to write a loop-and-a-half is to invert the
condition and break. For cases too complicated to fit into the loop
header, that would be the obvious solution.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New assignmens ...

[Avi Gross via Python-list]

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.

Python is not only a real-world set of applications but an evolving one with
a huge embedded base. We have seen how hard it was for some to move when 2.X
and 3.X versions were not upward compatible. Some have refused to move. So
adding new features must not only be done carefully with an eye for  path
upward but also to not destroy existing programs when possible. When a
change is needed, it is often done in stages with some things being
deprecated for a while before the change.

So the half-submerged  walrus operator was added instead of the flying
walrus operator with anti-gravity built in. If the proposal had been to
allow EVERYTHING you and others are suggesting, it is quite possible we
would never have had anything changed and no walrus. True, in another decade
or so, they might have gotten around to adding the unrestricted walrus. or
not.

What we have today is a path that may lead to more functionality
incrementally. If people are using the walrus and like it and it makes
coding easier AND they ask for more, it may come, at incremental cost.

-Original Message-
From: Python-list  On
Behalf Of Antoon Pardon
Sent: Wednesday, October 27, 2021 2:59 AM
To: python-list@python.org
Subject: Re: New assignmens ...



Op 26/10/2021 om 00:24 schreef Chris Angelico:
> TBH, I don't think there's a lot of value in multiple-assignment, 
> since it has a number of annoying conflicts of syntax and few viable 
> use-cases. But if you have great examples of "x.y :=" or "x[y] :=", 
> then by all means, post on python-ideas to propose widening the scope.

I think you should seperate the costs from the benefits. It is not because
the costs can be high there is little value.

And how do you count use cases? What about the following pattern:

while (a, b) := next_couple(a,b)[-1]:
 ...

Is that one use case or is that a use case for each kind of couple?

And even if the benefits are little per case, they can add up with every
occasion such a case pops up.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Christman, Roger Graydon]

On 27/10/2021 8:28, Anton Pardon wrote:
>>> Suppose I would like to write a loop as follows:
>>.   >while ((a, b) := next_couple(a, b))[1]:
>>   >do needed calculations
>>
>>
>>> What I can do is write it as follows:
>>>  while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
>>   >do needed calculations
>>
>>> I really don't see what is gained by "forcing" me to right the second code 
>>> over the first.
>> No, nobody is forcing you to write it the second way over the first.
>> Nobody is forcing you to use the walrus operator at all!
>>
>> Instead, I would recommend something more like:
>>
>> while b:
>>   do needed calculations
>>   (a,b) = next_couple(a,b)

> But AIU the walrus operator was introduced so we no longer needed, to write 
> such code,
> with the calculation of the next candidate at the bottom and the test at the 
> top.
> You just confirmed the walrus operator is not very useful once the next 
> candidate is
> no longer just a name.

I must disagree with the first sentence here regarding why the walrus operator 
was introduced.
I read through the PEP, and saw nothing about that in the Rationale.   I do see 
the loop-and-a-half
example, but that actually had its next candidate value near the top (just 
before a break).

I'm going to provide two loop-and-a-half segments to illustrate my 
interpretation
of this PEP and the purpose of the walrus operator:

Without the walrus:

total = 0
value = input()
while value >= 0:
 total += value
 value = input()
print(total)

With the walrus:

total = 0
while (value := input()) > 0:
 total += value
print(total)

In terms of the PEP -- I want to compare each input value to 0 for the loop 
test,
but I also want to preserve that value, to add to the total.   There is a 
subexpression
(input()) within a larger expression (compared to 0) that I wish to name for 
reuse.

Now contrast with this example:

Without the walrus:

replay = True
while replay:
play_game()
replay = input("Play again? ") in ['y','Y','yes','Yes']

(I think it silly to ask about playing again at first).

With the walrus:

replay = None
while replay==None or (replay := input("Play again? ") in ['y','Y','yes','Yes']:
 play_game()

To use the walrus operator here, I have to fabricate a value that would
allow me to bypass the input operation, that cannot be otherwise produced.
I do not find this second version any clearer or more intuitive than the first
(and the PEP did emphasize the value of clarity).

Now reading this in terms of the PEP, where I subexpression (the input)
in a larger expression (seeing if it is the list), I do not really seem to have
a compelling reason to name the value of that subexpression, since I am
not using it for any other purpose, so I could keep the input in the while
condition without using the walrus operator:

first_play = True
while first_play or input("Play again? ") in ['y','Y','yes','Yes']:
play_game()
first_play = False

I do not find this particularly clearer or better than my first version
with the test at the bottom, again since it requires me to do some extra
machinery to avoid the undesired input before the first repetition.
But I might also still argue that this is a little bit clearer than the
walrus alternative above.

My claim from these two examples is that the walrus is helpful to
reduce duplicating or recomputing subexpressions, not simply just
to facilitate code movement.   It is not at all useful for a while loop
condition if the subexpression you wish to evaluate depends on
whether or not this is the first iteration of the loop.

Which then gets me back to your own illustrated use-case for
which I had raised a few questions/objections to before:

while ((a, b) := next_couple(a, b))[1]:
   do needed calculations

What is the name of the value you wish to test?b
What is this actually testing?   element [1] of a tuple

So already the code is unclear (and was made worse
when you said the existing walrus operator forced you
to make a list of three elements, two assigned with the
walrus, and then using a subscript of [-1] to get what you wanted.
My proposed solution explicitly tested b, since that
seemed to be what was of interest:

 while b:
do needed calculations
 (a,b) = next_couple(a,b)

To which you had replied:
> But AIU the walrus operator was introduced so we no longer needed, to write 
> such code,
> with the calculation of the next candidate at the bottom and the test at the 
> top.
> You just confirmed the walrus operator is not very useful once the next 
> candidate is
> no longer just a name.

Okay, I would be happy to confirm my belief that the walrus is not very useful
when the thing you wish to test is not the same as the thing you with to assign.

But to relate this use case to my earlier loop-and-a-half examples:

(a,b) := next_couple(a,b)

presumes that there is are values for a and b to begin with for that first call 

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 18:16 schreef Christman, Roger Graydon:

On 27/10/2021 at 12:45  Antoon Pardon wrote:

However with the introduction of the walrus operator there is a
way to simulate a significant number of one and a half loops.
Consider the following:

  >do
  >   a = expr1
  >   b = expr2
  >   while 2 * a > b:
  >  more calculations


We could write that now as

  >while [
  >a := expr1,
  >   b := expr2,
  >   2 * a > b][-1]:
  >  more calculations

Why don't you try this?


Because this is about a general idea, not about the specifics of the example.
 

while 2 * (a := expr1) > (b := expr2):
   more calculations

It seems you are just compelled to create tuple and lists
in all of your use-cases, even when they serve no purpose.


Do you have a procedure that will always eliminate a list and will be
more or less as readable as the one and a half loop?

I know the list serves no purpose, other than to provide a way to
easily write the calculations in the order that seems most natural.

But being able to write calculations in the order that makes them
more understandable is IMO worth more than eliminating the list.
Even if the list serves no real purpose in the calculations.

So suppose I have an arbitrary number of simple statements. The
latter possible using results from previous assignment and at the
end a condition to control the one and a half loop. How do you write
the python code so that the one and a half loop is easy to recognize?

--
Antoon Pardon

--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Christman, Roger Graydon]

On 27/10/2021 at 12:45  Antoon Pardon wrote:
> However with the introduction of the walrus operator there is a
> way to simulate a significant number of one and a half loops.

> Consider the following:

 >do
 >   a = expr1
 >   b = expr2
 >   while 2 * a > b:
 >  more calculations

> We could write that now as

 >while [
 >a := expr1,
 >   b := expr2,
 >   2 * a > b][-1]:
 >  more calculations

Why don't you try this?

while 2 * (a := expr1) > (b := expr2):
  more calculations

It seems you are just compelled to create tuple and lists
in all of your use-cases, even when they serve no purpose.

Roger Christman
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Peter J. Holzer]

On 2021-10-27 22:00:16 +1100, Chris Angelico wrote:
> On Wed, Oct 27, 2021 at 9:41 PM Karsten Hilbert  
> wrote:
> > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:
> > > Many operations in computing are fully reversible. After you do
> > > something, you can undo it. After you assign, you can unassign. And
> > > after you ite, you can unite!
> >
> > I wonder whether Japanese programmers would agree.
> 
> Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate?

Don't know about Japanese but it works in Latin (FSVO "works").

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Chris Angelico]

On Wed, Oct 27, 2021 at 9:41 PM Karsten Hilbert  wrote:
>
> Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:
>
> > Many operations in computing are fully reversible. After you do
> > something, you can undo it. After you assign, you can unassign. And
> > after you ite, you can unite!
>
> I wonder whether Japanese programmers would agree.
>

Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 11:59 schreef Chris Angelico:

You can argue the word "need" all you like, but the fact remains that
YOU want a change, so YOU have to convince people of the benefits.


That is true. But there is nothing wrong in asking what might convince
people.

But I'll give you my thought below and you can decide in how far this
is convincing to you.

I regularly come with a problem for which a one and a half loop is very
suited to solve it. Unfortunately python doesn't have a one and a half
loop. However with the introduction of the walrus operator there is a
way to simulate a significant number of one and a half loops.

Consider the following:

do
a = expr1
b = expr2
   while 2 * a > b:
   more calculations

We could write that now as

while [
a := expr1,
b := expr2,
2 * a > b][-1]:
more calculations

Now there is some ugly side on the above and it may not be obvious at first
what is going on, but once you understand it is a rather easy idiom. I certainly
prefer it over writing something like

while True:
a = expr1
b = expr2
if not (2 * a > b):
break
more calculations.

So for me any limitation on the walrus operator that is removed is a plus 
because
it will allow me to write more one and a half loops in more natural way.

Off course should the python developers decide to intoduce a real one and a half
loop all the above is probably a whole let useful.

--
Antoon Pardon

--
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:

> xyzzy = lambda x: 2 * x
>
>   . Sometimes, this can even lead to "naming paralysis", where
>   one thinks excessively long about a good name. To avoid this
>   naming paralysis, one can start out with a mediocre name. In
>   the course of time, often a better name will come to one's mind.

In that situation, is it preferable to choose a nonsensical
name over a mediocre one ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:

> Many operations in computing are fully reversible. After you do
> something, you can undo it. After you assign, you can unassign. And
> after you ite, you can unite!

I wonder whether Japanese programmers would agree.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to store the result of df.count() as a new dataframe in Pandas?

[Tim Williams]

On Tue, Oct 26, 2021 at 6:36 PM Shaozhong SHI 
wrote:

> Hello,
>
> The result of df.count() appears to be a series object.  How to store the
> result of df.count() as a new dataframe in Pandas?
>
> That is data anyhow.
>
> Regards,
>
> David
> --
> https://mail.python.org/mailman/listinfo/python-list




Have you tried something like

df_count = pd.DataFrame(df.count())
?
(Untested, but I've converted Series objects to DataFrames doing something
similar before.)
This is more of a pandas question. Why don't you ask this on stackoverflow?

https://stackoverflow.com/questions/tagged/pandas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Wed, Oct 27, 2021 at 8:20 PM Antoon Pardon  wrote:
>
>
>
> Op 27/10/2021 om 10:49 schreef Chris Angelico:
> > On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon  wrote:
> >>> So if you want this added, show a use-case that makes it look way
> >>> better than the alternatives (including a generator, a mid-loop break,
> >>> etc).
> >> Way better according to which criteria? IMO to realy make something like
> >> this you would need a one and a half loop. But although at some time there
> >> was a strong indication it would get included, the idea was eventually 
> >> discarted.
> >>
> >> So I'll argue for incremental better if I see a possibility. A few 
> >> incremental
> >> betters can eventually result in something that is way better than the 
> >> original.
> > According to any criteria you like. Remember, the onus is not on the
> > status quo to justify itself; the onus is on someone who wants to make
> > a change.
>
> Then don't answer that I can justify it according to any criteria I like.
> It will have to be done according to criteria that are important to the
> people who like the status quo. That it will be justified according to
> criteria I like, will be totally unimportant.
>
> > Demonstrate that a change is needed by showing the benefits.
>
> Nothing is needed. But the walrus operator wasn't needed either. Asking to
> show something is needed is putting a burden on who wants to advocate for
> this, that isn't put on others.
>

You can argue the word "need" all you like, but the fact remains that
YOU want a change, so YOU have to convince people of the benefits.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Peter J. Holzer]

On 2021-10-24 11:23:48 +0200, O365 Dict wrote:
> do:
> a, b = calculate_next_couple(a, b)
> while b:
> more calculations

I actually like that syntax.

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Peter J. Holzer]

On 2021-10-27 19:05:52 +1100, Chris Angelico wrote:
> On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon  wrote:
> > while (a, b) := next_couple(a,b)[-1]:
> >  ...
[...]

> I'm not sure that it's much of a use-case; isn't it an infinite loop as 
> written?
> 
> And that's the problem. With multiple-assignment, the overall value is
> going to be the tuple, so you then have to add extra parentheses and
> subscripting to get what you want to check.

Right. I think for that you would want something like what Go does in
if:

if [assignment-statement ;] condition {
statements
}

Then you could write

while a, b = next_couple(a,b); b:
...

That doesn't even need the walrus operator.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 10:49 schreef Chris Angelico:

On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon  wrote:

So if you want this added, show a use-case that makes it look way
better than the alternatives (including a generator, a mid-loop break,
etc).

Way better according to which criteria? IMO to realy make something like
this you would need a one and a half loop. But although at some time there
was a strong indication it would get included, the idea was eventually 
discarted.

So I'll argue for incremental better if I see a possibility. A few incremental
betters can eventually result in something that is way better than the original.

According to any criteria you like. Remember, the onus is not on the
status quo to justify itself; the onus is on someone who wants to make
a change.


Then don't answer that I can justify it according to any criteria I like.
It will have to be done according to criteria that are important to the
people who like the status quo. That it will be justified according to
criteria I like, will be totally unimportant.


Demonstrate that a change is needed by showing the benefits.


Nothing is needed. But the walrus operator wasn't needed either. Asking to
show something is needed is putting a burden on who wants to advocate for
this, that isn't put on others.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 10:38 schreef dn via Python-list:

On 24/10/2021 22.23, O365 Dict wrote:

Well I have the following use case:

 while (temp_result := calculate_next_couple(a, b))[1]:
 a, b = temp_result
 more calculations

Which IMO would be clearer if I could just write:

 while ((a, b) := calculate_next_couple(a,b))[1]:
 more calculations

Of course it would even more clear if I could write something like:

 while (a, b) := calculate_next_couple(a, b); b:
 more calculations

or

 do:
 a, b = calculate_next_couple(a, b)
 while b:
 more calculations


Found (all of) the above less-than-obvious to read. Putting it in front
of trainees this morning caused only confusion - even the
currently-legal variation.


A lot of python idioms are less than obvious for trainees when they first
encounter them. I don't think "Is obvious for trainess" is a good measure
to evaluate possible future programming constructs.


Accordingly: is this a job for the walrus operator at all? Let's "talk
of many [other] things"*.

...


That all looks simple. What is dn complaining about?


Could we use a data structure to continue to keep things straight-forward?


Yes off course we could. Before the walrus operator was introduced, we could
also introduce extra code so that we wouldn't need the walrus operator at all.



...
Hope the above gives you some ideas/pause for thought!


No they don't. You have taken an example to illustrate an idea and
treated it as if it was some production code you had to review.

What you are suggesting boils downto that if one has a loop in which
one has two work variables, with a condition on those variable to
control a loop. In order to make use of the walrus operator we should
combine those two work variables into some kind of instance no matter
how contrived.

--
Antoon Pardon.


--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Wed, Oct 27, 2021 at 7:39 PM dn via Python-list
 wrote:
> Accordingly: is this a job for the walrus operator at all? Let's "talk
> of many [other] things"*.

+1

> Could we use a data structure to continue to keep things straight-forward?
>
> class my_class():
> def __init__( self, a, b )->None;
> self.a = a
> self.b = b
>
> instance = my_class( a, b )
>
>
> Sorry, you're probably becoming impatient with me. Surely I'm typing
> more code than necessary? Maybe, but there are other measures of
> code-quality/good-practice/etc, and there's likely more to 'it' than
> just these few lines...
>
>
> First consideration: the algorithm needs us to 'feed' the
> while-condition. So let's flesh-out:
>
> def is_more( self )->bool:
> # you know what goes here - I don't, but that's not the issue
> # the return value is all that matters
> return is_there_any_more_data_to_calculate?
>
> In which case, the loop becomes:
>
> while instance.is_more():
> more calculations
>
> and 'readability' improves immeasurably!

I'd be inclined to write all of this as a generator function, yielding
a series of tuples, but YMMV.

> * this gratuitous and somewhat awkward expression is me claiming to be
> clever by quoting Lewis Carroll - if he isn't sick of me
> baiting-the-hook, it might earn extra brownie-points (or another groan)
> from @Chris...

Given that you were talking about a walrus, I think it was quite apt :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon  wrote:
> > So if you want this added, show a use-case that makes it look way
> > better than the alternatives (including a generator, a mid-loop break,
> > etc).
>
> Way better according to which criteria? IMO to realy make something like
> this you would need a one and a half loop. But although at some time there
> was a strong indication it would get included, the idea was eventually 
> discarted.
>
> So I'll argue for incremental better if I see a possibility. A few incremental
> betters can eventually result in something that is way better than the 
> original.

According to any criteria you like. Remember, the onus is not on the
status quo to justify itself; the onus is on someone who wants to make
a change.

Demonstrate that a change is needed by showing the benefits.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 10:05 schreef Chris Angelico:

On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon  wrote:



Op 26/10/2021 om 00:24 schreef Chris Angelico:

TBH, I don't think there's a lot of value in multiple-assignment,
since it has a number of annoying conflicts of syntax and few viable
use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
then by all means, post on python-ideas to propose widening the scope.

I think you should seperate the costs from the benefits. It is not because
the costs can be high there is little value.

And how do you count use cases? What about the following pattern:

while (a, b) := next_couple(a,b)[-1]:
  ...

Is that one use case or is that a use case for each kind of couple?

And even if the benefits are little per case, they can add up with every
occasion such a case pops up.


I'm not sure that it's much of a use-case; isn't it an infinite loop as written?

And that's the problem. With multiple-assignment, the overall value is
going to be the tuple, so you then have to add extra parentheses and
subscripting to get what you want to check. That makes it far less
clean, far less tempting, far less valuable. You have to parenthesize
the assignment target (otherwise it'll build a tuple out of one value
and the assigned target), then parenthesize again, and subscript at
the end.


That is only a problem if you want to consider it one. This wouldn't be the
only place in python where you have to be careful with parentheses. IMO it
should be the responsibility of each programmer to decide which way to
program will be most clean. Maybe you are completly right and at the
same time it could still be more clean than the other possibilitie python
allows.


So if you want this added, show a use-case that makes it look way
better than the alternatives (including a generator, a mid-loop break,
etc).


Way better according to which criteria? IMO to realy make something like
this you would need a one and a half loop. But although at some time there
was a strong indication it would get included, the idea was eventually 
discarted.

So I'll argue for incremental better if I see a possibility. A few incremental
betters can eventually result in something that is way better than the original.

--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[dn via Python-list]

On 24/10/2021 22.23, O365 Dict wrote:
> Well I have the following use case:
> 
> while (temp_result := calculate_next_couple(a, b))[1]:
> a, b = temp_result
> more calculations
> 
> Which IMO would be clearer if I could just write:
> 
> while ((a, b) := calculate_next_couple(a,b))[1]:
> more calculations
> 
> Of course it would even more clear if I could write something like:
> 
> while (a, b) := calculate_next_couple(a, b); b:
> more calculations
> 
> or
> 
> do:
> a, b = calculate_next_couple(a, b)
> while b:
> more calculations


Found (all of) the above less-than-obvious to read. Putting it in front
of trainees this morning caused only confusion - even the
currently-legal variation.


Accordingly: is this a job for the walrus operator at all? Let's "talk
of many [other] things"*.


Is this an algorithmic complexity, or a complicated way to look at (and
manipulate) data?

Well, judging from the code (above), use of the walrus certainly
presumes the former. Instead let's review any possibility of the latter
(if only for academic interest)...


What do we want out of the first line? (in no particular order)

1 use calculate_next_couple() to compute (new) a from an (old) a and b
2 use calculate_next_couple() to compute (new) b from an (old) a and b
3 use (new) b to decide if the loop should execute or terminate

The 'problem' then, has been phrased as these three objectives ask too
much of the (current implementation of the) walrus-operator.


NB after one (or more) cycles, when the loop 'returns to the top', what
I've termed 'new' a and b (above), will become (my reference) the 'old'
pair/tuple.


That all looks simple. What is dn complaining about?


Could we use a data structure to continue to keep things straight-forward?

class my_class():
def __init__( self, a, b )->None;
self.a = a
self.b = b

instance = my_class( a, b )


Sorry, you're probably becoming impatient with me. Surely I'm typing
more code than necessary? Maybe, but there are other measures of
code-quality/good-practice/etc, and there's likely more to 'it' than
just these few lines...


First consideration: the algorithm needs us to 'feed' the
while-condition. So let's flesh-out:

def is_more( self )->bool:
# you know what goes here - I don't, but that's not the issue
# the return value is all that matters
return is_there_any_more_data_to_calculate?

In which case, the loop becomes:

while instance.is_more():
more calculations

and 'readability' improves immeasurably!

NB for extra credit, turn the boolean function into a "property", and be
able to omit the (unsightly?) parentheses from the 'call'!


But, not so fast - what about the calculation itself, currently embedded
in calculate_next_couple()?

Well, those details are out of my sight, and I'm assuming include
reasonable complexity - otherwise you wouldn't propose this as a
good-example. Allow me to muddle-through with:

def calculate_next_couple( self )->None:
self.a = calculation of 'new' a
self.b = calculation of 'new' b

To avoid an 'extra' call against the instance from the while-loop,
execute the 'calculate' method from either __init__() or is_more(), as
appropriate (given that it likely needs to precede the return from the
latter - particularly if the computation is 'expensive'). The choice may
be subject-dependent ...


Now within "more calculations", one assumes, references to "a" and "b"
will need to be amended to become 'instance.a' and 'instance.b'. More
typing! What about preserving our fingers?


Readability will further improve when "a" and "b" (etc) are replaced by
'real names'.

The processing steps within "more calculations" could be reviewed. Some
may be candidates for inclusion as my_class methods - which would even
enable further simplifications and/or encapsulation of code-suites
relevant to the application, and/or "a" and "b" and the processes around
them.

If the "calculation" of 'next_couple' currently involves looking-up
another data-structure, eg a list of data-points, then combining such
with/into my_class may well yield further simplifications,
encapsulations, and benefits - but all in-theory and complete ignorance
of your application...


Hope the above gives you some ideas/pause for thought!


* this gratuitous and somewhat awkward expression is me claiming to be
clever by quoting Lewis Carroll - if he isn't sick of me
baiting-the-hook, it might earn extra brownie-points (or another groan)
from @Chris...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 10:05 schreef Chris Angelico:

On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon  wrote:



Op 26/10/2021 om 00:24 schreef Chris Angelico:

TBH, I don't think there's a lot of value in multiple-assignment,
since it has a number of annoying conflicts of syntax and few viable
use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
then by all means, post on python-ideas to propose widening the scope.

I think you should seperate the costs from the benefits. It is not because
the costs can be high there is little value.

And how do you count use cases? What about the following pattern:

while (a, b) := next_couple(a,b)[-1]:
  ...

Is that one use case or is that a use case for each kind of couple?

And even if the benefits are little per case, they can add up with every
occasion such a case pops up.


I'm not sure that it's much of a use-case; isn't it an infinite loop as written?




And that's the problem. With multiple-assignment, the overall value is
going to be the tuple, so you then have to add extra parentheses and
subscripting to get what you want to check. That makes it far less
clean, far less tempting, far less valuable. You have to parenthesize
the assignment target (otherwise it'll build a tuple out of one value
and the assigned target), then parenthesize again, and subscript at
the end.

So if you want this added, show a use-case that makes it look way
better than the alternatives (including a generator, a mid-loop break,
etc).

ChrisA


--
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon  wrote:
>
>
>
> Op 26/10/2021 om 00:24 schreef Chris Angelico:
> > TBH, I don't think there's a lot of value in multiple-assignment,
> > since it has a number of annoying conflicts of syntax and few viable
> > use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
> > then by all means, post on python-ideas to propose widening the scope.
>
> I think you should seperate the costs from the benefits. It is not because
> the costs can be high there is little value.
>
> And how do you count use cases? What about the following pattern:
>
> while (a, b) := next_couple(a,b)[-1]:
>  ...
>
> Is that one use case or is that a use case for each kind of couple?
>
> And even if the benefits are little per case, they can add up with every
> occasion such a case pops up.
>

I'm not sure that it's much of a use-case; isn't it an infinite loop as written?

And that's the problem. With multiple-assignment, the overall value is
going to be the tuple, so you then have to add extra parentheses and
subscripting to get what you want to check. That makes it far less
clean, far less tempting, far less valuable. You have to parenthesize
the assignment target (otherwise it'll build a tuple out of one value
and the assigned target), then parenthesize again, and subscript at
the end.

So if you want this added, show a use-case that makes it look way
better than the alternatives (including a generator, a mid-loop break,
etc).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Antoon Pardon]

Op 26/10/2021 om 00:24 schreef Chris Angelico:

TBH, I don't think there's a lot of value in multiple-assignment,
since it has a number of annoying conflicts of syntax and few viable
use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
then by all means, post on python-ideas to propose widening the scope.


I think you should seperate the costs from the benefits. It is not because
the costs can be high there is little value.

And how do you count use cases? What about the following pattern:

while (a, b) := next_couple(a,b)[-1]:
...

Is that one use case or is that a use case for each kind of couple?

And even if the benefits are little per case, they can add up with every
occasion such a case pops up.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list