Re: New assignmens ...
On 25/10/2021 01:46, Avi Gross via Python-list wrote: No, many things need not be as general as possible once you consider how much work it may take to develop code and how many bugs and oddities might be introduced and even how much it may slow the interpreter. ... I imagine you can create some fairly complex examples you can suggest should be handled for generality including some very indirect references created dynamically. The code to recognize any abstract use of symbols may not only slow down every operation of even the simplest type but generate all kinds of error messages nobody will understand, let alone translate into other languages properly! Right now, it is simpler. An error message can say that only certain simple usages are allowed. I don't consider this a strong argument. Limiting the scope of the walrus operator will just force people organizing there code where they will use a normal assignment. So the resulting code will not be faster, less complex or generate less error messages because the complexity of the assignment that is needed is still the same. Or you force people to be "creative" as follows: 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. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter][Windows]Unexpected state report for the tab key
On 25/10/2021 02:57, Stefan Ram wrote: GetKeyState still returns that the tab key is pressed after the tab key already has been released. Well, how then am I going to make my slide show stop the moment the key is being released? Does tkinter allow you to trap KeyUp (and KeyDown) events? (I'm not familiar with tkinter, but in wxpython you can.) And if so, does trapping KeyUp solve the problem? Best wishes Rob Cliffe -- https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ...
Antoon,
Just to be clear. I am talking about a different measure of efficiency. If
you have code that handles a limited functionality properly it can be quite
simple. If you then expand the code to handle ever more situations, then it
may do things like a series of IF statements to determine which of many
things to do so it now takes a while to just reach the part that does the
most common case. I have seen people use code that knows what arguments to
expect and just does things simply, like adding two integers together. Then
the code is improved so it detects if either argument is floating point and
now does any needed conversions. Soon you add support for complex numbers or
character strings that look like "23" and then even parse "twelve dollars
and forty two cents" in English and then a few other languages. Next you
accept range objects and other things that make sense to add and accept an
undefined number of arguments and name the darn thing sum_everything() and
proudly show it off. It now has an amazing number of errors it can propagate
or warn about. But, you can still use it to add 2 and 2.
Now, yes, nobody needs a function to just add two numbers. If that bothers
you, make is add the absolute values or something a tad more interesting.
But the point is that any code that invokes sum_everything() may now pay a
penalty in terms of performance just in the beginning part where it tests
how many arguments it got, what types they are, and so on.
The topic here is the Python run-time parser though. It is reading your code
and doing whatever complex set of things it has to do to parse from a fairly
large set of possible valid programs as well as invalid ones. I have never
looked deeply at how it works but my guess is that somewhere in there are
concepts like:
simple_asignment_expression can look like THIS.
complex _assignment expression can look like simple_assignment_expression OR
THAT OR ...
So to parse code you often need to look at alternate ways of connecting
symbols and hopefully find the one and only way it has to be looked at.
Parentheses as an example have many possible meanings and you may not know
which meaning when you encounter it until you keep going and see where there
may be a matching one but ignore any within a character string. I won't go
on but the point is that the parser can jump through more hoops even in the
most usual cases when it has to look for new cases not originally designed
in.
Your argument that people using other techniques to get the functionality
they want is not really relevant as I do not deny it. My point is that the
most common ways NORMALLY used are the ones that drive the efficiency of a
system. So if adding functionality to include new cases/situations doubles
the time it takes to do the most common case and that is used 98% of the
time, then how much overall gain for the other 2% is needed to
counterbalance it?
I find a common pattern in software that often looks like extra layers
around a function call. There may be a function to create an object given a
character string argument like vector("integer", 1, 2, 3") or
vector("character", "a", "b") that lets you create all kinds of vectors.
Someone comes along with a bright idea to make programmers instead call
make_integer(1, 2, 3) and make_character("a", "b") and more like that. We
now have lots of new function that are just going to turn around and call
vector() with a different appropriate string as the first argument and pass
along the rest. We now have a function calling a second function. Yes, there
are many possible advantages here including ways to check if you are using
your code as intended. But there is overhead. And in a tight loop repeated
millions of times, can you blame a programmer who knows, if they just call
vector() directly, or perhaps a deeper function that vector() calls when it
knows it is using integers?
I will end with this. If someone wants to design a new language from scratch
and with a goal of starting with as general a set of concepts as they can,
fine. Design it carefully. Build it and if it works well enough, use it. But
to ask an existing language to add features or expand existing ones is not
at all the same thing and requires much more care. In python, you can find
areas that are a bit confusing such as how multiple inheritance in objects
is done. It can require some tweaking to make your objects in ways that the
right thing is inherited from the other objects the way you want if more
than one has the same method and you can have subtle errors. Arguably the
darn thing is too general and many other languages instead decide not to
support multiple inheritance and may use other interesting ways to get
similar functionality. But although this can be a very nice feature allowing
you to design quite sophisticated sets of objects that inherit all kinds of
nifty powers from other existing objects, it can be a drag on performance if
it does a search through a big mess to find the
Re: New assignmens ...
Message: 8 Date: Mon, 25 Oct 2021 11:20:52 +0200 From: Antoon Pardon To: python-list@python.org Subject: Re: New assignmens ... Message-ID: <5761dd65-4e87-8b8c-1400-edb821204...@vub.be> Content-Type: text/plain; charset=utf-8; format=flowed On 25/10/2021 11:20, 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 right 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) This requires even less typing than what you had before! But it also raises a whole lot of problems with this particular example: -- neither a nor b is defined in your sample while loop. It seems you would need to initialize a and b before your while loop (and mine) -- is b truly a boolean value, or are you short-cutting some other value? -- are a and b truly necessary parameters to next_couple, or are they just there to remind the function of its previous return values? If the latter, poerhaps you want a stream or list or something with yield This example (and some of the others I have seen) just highlight how programmers will take advantage of any new tool to help them write worse code than if they did not have the tool. In my mind, the walrus operator was designed to serve a particular niche case like this one: while (x := input()) > 0: where not having the operator required duplicating the input() operation both before the loop and at the end of the loop -- or more complicated cases where some additional operations had to be performed to get that test value for the while condition (such as getting the b out of (a,b)). But the walrus only adds a benefit if it is there to avoid the duplication of the code that is used to obtain that test condition. This next_couple example does not qualify, since apparently (a,b) are initialized by some other means (and not be a call to next_couple with undefined values) Or the other abuse I saw recently about using the walrus operator: while (self.ctr := self.ctr-1) > 0: -- there was no compelling reason for a loop counter to be a class variable (anyone who peeks at this counter when the loop is down would only see a zero) -- this requires self.ctr to be initialized to a value one higher than the first meaningful value (start at 11 if you want to count down from 10) So my recommended alternative, which furthermore also takes less typing: while ctr > 0: ... ctr = ctr-1 TL;DR: The Walrus operator serves the purpose as described in its PEP just as it is, and I see no compelling reason to expand its use. It is there to reduce code size by eliminating a duplication of code, If the code you write using the walrus operator is longer or more complicated than the code would be without it, you are misusing it. Roger Christman Pennsylvania State University -- https://mail.python.org/mailman/listinfo/python-list
Re: what's unsafe to do in a __getattr__?
On 10/25/21 10:48, Dieter Maurer wrote: Mats Wichmann wrote at 2021-10-24 19:10 -0600: Have run into a problem on a "mature" project I work on (there are many years of history before I joined), there are a combination of factors that combine to trigger a KeyError when using copy.copy(). ... There's a class that's a kind of proxy ... "Proxying" has become very difficult since the introduction of Python's "new style classes" and looking up "special methods" on the type rather then the type instance. This essentially means that the proxy must implement all "special methods" that may be relevant to the application. All special methods start and end with `"__"`. Your `__getattr__` could raise an `AttributeError` as soon as it is called with such a name. Thanks. Raising an AttributeError here was what I was going to propose so maybe I'll take your reply as validation I was on the right track. This stuff was definitely defined in an era before the new-style classes, might have to examine some other proxying classes to make sure there aren't other holes... thanks again, -- mats -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On Tue, Oct 26, 2021 at 3:07 AM Avi Gross via Python-list
wrote:
> I will end with this. If someone wants to design a new language from scratch
> and with a goal of starting with as general a set of concepts as they can,
> fine. Design it carefully. Build it and if it works well enough, use it.
I'll add to this: Please do exactly that! It's a great mental
exercise. Sometimes you'll end up using it as a domain-specific
language, or maybe it'll become a sort of ersatz command interpreter,
or something; other times, you do the work of designing it purely for
the effect of trying it, and you've learned how languages work.
What you'll find is that there are extremes that are utterly and
completely useless, such as Turing tarpits (almost no language
facilities, but technically possible to write anything), or things so
generic that they are nothing more than containers ("a script in this
language is whatever code will make it happen"). In between, every
programming language has to make decisions. What are its goals? What
kinds of problems should be easy to solve in this language? Is it
meant to be general-purpose and able to do most things, or
special-purpose but extremely elegant within its domain?
And along the way, you'll gain a better appreciation for every
language you work with, plus a mental comprehension that lets you
understand WHY this language or that language is good for some task.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: what's unsafe to do in a __getattr__?
Mats Wichmann wrote at 2021-10-24 19:10 -0600: >Have run into a problem on a "mature" project I work on (there are many >years of history before I joined), there are a combination of factors >that combine to trigger a KeyError when using copy.copy(). > ... >There's a class that's a kind of proxy ... "Proxying" has become very difficult since the introduction of Python's "new style classes" and looking up "special methods" on the type rather then the type instance. This essentially means that the proxy must implement all "special methods" that may be relevant to the application. All special methods start and end with `"__"`. Your `__getattr__` could raise an `AttributeError` as soon as it is called with such a name. -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
Op 25/10/2021 om 18:06 schreef Avi Gross via Python-list: > Antoon, > > Just to be clear. I am talking about a different measure of efficiency. No you are not. > > The topic here is the Python run-time parser though. Yes and that is what I am talking about. > It is reading your code > and doing whatever complex set of things it has to do to parse from a fairly > large set of possible valid programs as well as invalid ones. I have never > looked deeply at how it works but my guess is that somewhere in there are > concepts like: > > simple_asignment_expression can look like THIS. > complex _assignment expression can look like simple_assignment_expression OR > THAT OR ... > > So to parse code you often need to look at alternate ways of connecting > symbols and hopefully find the one and only way it has to be looked at. > Parentheses as an example have many possible meanings and you may not know > which meaning when you encounter it until you keep going and see where there > may be a matching one but ignore any within a character string. I won't go > on but the point is that the parser can jump through more hoops even in the > most usual cases when it has to look for new cases not originally designed > in. IMO that extra complexity is insignificant. You really don't reduce the complexity of your parser much if you would limit it so that indexes can only be names so that the programmer instead of being able to write: var = tab[some expression] is forced to write it as: index = some expression var = tab[index] Because all that machinery to evaluate some expression needs to be there anyway. In the same way we have already all the machinery present for assignments. By putting limits on the walrus code, you are not reducing complexity, you are increasing it. You are increasing complexity because you can't just reuse the code that handles an ordinary assignment. You now need specific code to limit it's use. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon wrote: > By putting limits on the walrus code, you are not reducing complexity, you > are increasing it. > You are increasing complexity because you can't just reuse the code that > handles an ordinary > assignment. You now need specific code to limit it's use. > What does this code do? while x, y := foo(): ... Is it more complicated or less complicated when arbitrary assignment targets are permitted? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
Op 25/10/2021 om 20:39 schreef Chris Angelico: > On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon wrote: >> By putting limits on the walrus code, you are not reducing complexity, you >> are increasing it. >> You are increasing complexity because you can't just reuse the code that >> handles an ordinary >> assignment. You now need specific code to limit it's use. >> > What does this code do? > > while x, y := foo(): > ... > > Is it more complicated or less complicated when arbitrary assignment > targets are permitted? Well I would guess it would do something similar to while [x, y := foo()]: ... -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On Tue, Oct 26, 2021 at 7:18 AM Antoon Pardon wrote: > > Op 25/10/2021 om 20:39 schreef Chris Angelico: > > On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon wrote: > >> By putting limits on the walrus code, you are not reducing complexity, you > >> are increasing it. > >> You are increasing complexity because you can't just reuse the code that > >> handles an ordinary > >> assignment. You now need specific code to limit it's use. > >> > > What does this code do? > > > > while x, y := foo(): > > ... > > > > Is it more complicated or less complicated when arbitrary assignment > > targets are permitted? > > Well I would guess it would do something similar to > > while [x, y := foo()]: > ... > And does it unpack what foo returns? Should it? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ...
We have had discussions debating if Python is a good language for teaching. The short answer is NO unless you only teach a small subset and the students know there is more they can learn as needed. The language is too rich and has too many ways to do seemingly anything and that is before you add more functionality. But that can make it a great language for developers. Assignments in middle of expressions are often syntactic sugar that may be re-arranged internally to similar code than what could be done other ways without it. It can lead to ambiguities. And it can make it harder for anyone other than the programmer that wrote it (or them a day later) to understand. So, while we are at it, why not add the ++ and --- operators that were deliberately NOT included in Python? Why not throw back pointers? The short answer is that there are plenty of programming languages to choose from and some of those do have the features you want and some do not want them. Sure, you might push in what you want but have you considered all the places it might be tried? Can you do it in a comprehension where an assignment is implicitly being done? [ var := 5 in range(10) ] The old adage is that some people will be given a finger and take a hand. I had NOTHING to do with the process but others here know more. Chris suggests that there was a compromise of sorts here and a choice to implement a limited subset of fuller functionality for NOW without ruling out doing some more later. So those wanting more, feel free to petition for it as an ADDITION but I suggest a more polite tone than trying to say the people who did it were idiots who did it badly. Personally, I don't care what is done and suspect I will rarely feel much need to use the current walrus operator, let alone an enhanced Odobenus rosmarus operator like ::== ... -Original Message- From: Python-list On Behalf Of Christman, Roger Graydon Sent: Monday, October 25, 2021 12:48 PM To: python-list@python.org Subject: Re: New assignmens ... Message: 8 Date: Mon, 25 Oct 2021 11:20:52 +0200 From: Antoon Pardon To: python-list@python.org Subject: Re: New assignmens ... Message-ID: <5761dd65-4e87-8b8c-1400-edb821204...@vub.be> Content-Type: text/plain; charset=utf-8; format=flowed On 25/10/2021 11:20, 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 right 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) This requires even less typing than what you had before! But it also raises a whole lot of problems with this particular example: -- neither a nor b is defined in your sample while loop. It seems you would need to initialize a and b before your while loop (and mine) -- is b truly a boolean value, or are you short-cutting some other value? -- are a and b truly necessary parameters to next_couple, or are they just there to remind the function of its previous return values? If the latter, poerhaps you want a stream or list or something with yield This example (and some of the others I have seen) just highlight how programmers will take advantage of any new tool to help them write worse code than if they did not have the tool. In my mind, the walrus operator was designed to serve a particular niche case like this one: while (x := input()) > 0: where not having the operator required duplicating the input() operation both before the loop and at the end of the loop -- or more complicated cases where some additional operations had to be performed to get that test value for the while condition (such as getting the b out of (a,b)). But the walrus only adds a benefit if it is there to avoid the duplication of the code that is used to obtain that test condition. This next_couple example does not qualify, since apparently (a,b) are initialized by some other means (and not be a call to next_couple with undefined values) Or the other abuse I saw recently about using the walrus operator: while (self.ctr := self.ctr-1) > 0: -- there was no compelling reason for a loop counter to be a class variable (anyone who peeks at this counter when the loop is down would only see a zero) -- this requires self.ctr to be initialized to a value one higher than the first meaningful value (start at 11 if you want to count down from 10) So my recommended alternative, which furthermore also takes less typing: while ctr > 0: ... ctr = ctr-1 TL;DR: The Walrus operator serves the purpose as described in its PEP just as it is, a
Re: New assignmens ...
On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list wrote: > Personally, I don't care what is done and suspect I will rarely feel much > need to use the current walrus operator, let alone an enhanced Odobenus > rosmarus operator like ::== ... > . wait what? Ah. Had to look that one up. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On 26/10/2021 10.45, Chris Angelico wrote: > On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list > wrote: >> Personally, I don't care what is done and suspect I will rarely feel much >> need to use the current walrus operator, let alone an enhanced Odobenus >> rosmarus operator like ::== ... >> > > . wait what? > > Ah. Had to look that one up. :) Each year I assist friends who own one of local orchards, at harvest time. I usually run the sealing machine, to preserve fruit which will be transported refrigerated. It is such a novelty to be asked to fill-out a time-sheet. Under "name" it asks for "position", so I entered "Erignathus barbatus" (bearded seal), which caused similar consternation, and for some days, until someone thought to look it up... Back on-topic, I am slightly curious:- aside from 'starting small' with an option to widen/'open-up' later, is there a particular reason why 'the walrus' has not been made available (could not be ...?) for use with object-attributes? -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Beginner in python
hi buddie am new to python somebody kindly advice the coding which will count odd number from 1 to 10 , and counting number from 1 tp 100 -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On Tue, Oct 26, 2021 at 9:19 AM dn via Python-list wrote: > Back on-topic, I am slightly curious:- > > aside from 'starting small' with an option to widen/'open-up' later, is > there a particular reason why 'the walrus' has not been made available > (could not be ...?) for use with object-attributes? I can't think of any other reasons. But the one you cite is quite an important one. In order to get real-world usage examples, the feature was rolled out in the restricted form, because threads like this are *exactly* how the value can be judged. So I do not in any way regret that assignment expressions were accepted in their current form, but also, don't be afraid to propose an opening up of the syntax. Be specific, and cite usage examples that would benefit. 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginner in python
On Tue, Oct 26, 2021 at 9:23 AM Kian Kwame wrote: > > hi buddie > am new to python somebody kindly advice the coding which will count odd > number from 1 to 10 , and counting number from 1 tp 100 Sounds like homework. What have you written so far? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Beginner in python
Chris, I was just about to suggest: 1+3+5+7+9 and 50*101 but that would mean helping with what does seem like fairly simple homework with no effort to show us what they already tried and got stuck with! So, ignore my attempts at trivial humor as I suspect some form of loop was anticipated. Avi -Original Message- From: Python-list On Behalf Of Chris Angelico Sent: Monday, October 25, 2021 6:25 PM To: Python Subject: Re: Beginner in python On Tue, Oct 26, 2021 at 9:23 AM Kian Kwame wrote: > > hi buddie > am new to python somebody kindly advice the coding which will count odd number from 1 to 10 , and counting number from 1 tp 100 Sounds like homework. What have you written so far? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ...
Stefan, Yes, I often pass even fairly trivial functions like "add" or "+" or whatever the language makes me say, to other functions in various forms of functional programing. My point is that my example may seem trivial and not necessary as an EXAMPLE of the greater point that may be easier to understand than something complex. A sum() is often a generalization of adding two things by allowing a second addition to the sub-sum and so on. But in a straightforward program where I am asking to add exactly two things, few would use sum(a,b) versus just a+b. On the other hand, in agreement with you, if I have two vectors or matrices or some other such data holder and I want to add each position to a corresponding position, then some kind of call to a function where I pass the two objects and the name of a function that adds two things, is a decent way to go. But it need not be a souped-up generalized_sum() function when a simple one will do and be faster when invoked so many times. And note often what is used is a temporary lambda anonymous function that may look like \(x,y) x+y ... or whatever syntax your language uses. -Original Message- From: Python-list On Behalf Of Stefan Ram Sent: Monday, October 25, 2021 12:57 PM To: python-list@python.org Subject: Re: New assignmens ... "Avi Gross" writes: >Now, yes, nobody needs a function to just add two numbers. If one uses a framework like "functools.reduce", the only way to reduce an iterable to its sum, is to do just that: Write a function to add two numbers. Of course, one can circumvent "functools.reduce" (or use "operator.add"), but in other cases there are frameworks that need to be used and where one sometimes does need to write functions (callbacks) as simple as "lambda: None". -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Create a contact book
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 ?=) -- https://mail.python.org/mailman/listinfo/python-list
Re: Create a contact book
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 -- https://mail.python.org/mailman/listinfo/python-list
