Re: Lambda returning tuple question, multi-expression
On 3/8/2023 11:19 PM, aapost wrote: > In both cases (as per my intent) Well, that's the trouble. You haven't stated your intent, so we're forced to try to reverse engineer it. Below I state what my reverse-engineering effort thinks is your intent. It would be better if you actually said clearly what you want to achieve. So as far as the examples given above (which I can't really parse), if you meant for passing in a bool value, to do so would require something like: b.config(command=lambda enabled: config_b_and_entries(enabled)) As best as I can understand what you are trying to do here, it seems like you want to enable/disable those Entry widgets when you configure the b widget to be enabled/disabled. That way their states would all track each other, with only a single command needing to be issued. That seems like a sensible goal. The function config_b_and_entries() that I suggested is not meant to be the target of a lambda expression that is the argument of b.config(). It is meant to be called *instead* of b.config(command = lambda.). I can't see any benefit of trying to force this coordination of states by using an obscure lambda expression when you can achieve the same result with a straightforward, easy to read function or method call. OTOH, if you are not trying to achieve this coordination of states, then what are you trying to do? Don't go making us guess any more. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lambda returning tuple question, multi-expression
On 3/8/23 16:56, aapost wrote:
Thomas > Cameron
def set_entries_enabled_state(enabled = True):
state = 'normal' if enabled else 'disabled'
for e in (e1, e2, e3):
e.config(state=state)
def config_b_and_entries(enabled = True):
state = 'normal' if enabled else 'disabled'
b.config(state = state)
set_entries_enabled_state(enabled)
I admit adding commenting might be useful to clearly express intent for
patterns I don't commonly see. But when you are managing a bunch of
widgets and experimenting with the design, the variable name word salad
approach 'in the name of readability' starts to melt your brain a bit
and it all starts too look like a wall of..:
the_thing.the_things_thing.do_this_thing_to_that_other_thing_but_only_if_this_one_time()
So the button b in the example only needs a reference to a callable
configured, set with the command= parameter in .config()
The code:
def func():
pass
b.config(command=func)
Is equivalent. So that if the button is clicked, code at func (or the
lambda) gets called.
In both cases (as per my intent), care about the return values of the
expressions does not matter and I am fairly certain regardless of what
the callable returns, it does not get evaluated/assigned/considered
anywhere. (at least that is how I have been considering it, a void
foo(void) if you will..). Now as far as the tuple, yes, left to right
evaluation is what I expect, (hope anyway, lol),
meaning (3, False, 1, x := 5+9, print("hello{}".format(x)))
would return a tuple of (3, False, 1, 14, None) which gets assigned to
nothing and the string "hello14" printed to console.
Now.. When you want to assign a callable that requires args, the main
examples people give are a combo of them both,
def func(x,y,z):
pass
x = y = x = "something"
b.config(command=lambda x,y,z: func(x,y,z))
So as far as the examples given above (which I can't really parse), if
you meant for passing in a bool value, to do so would require something
like:
b.config(command=lambda enabled: config_b_and_entries(enabled))
Which that type of thing to me gets even harder to grok after a while,
and I guess for me I find having to go to a different scope or a
separate file to parse a bunch of definitions like these:
def set_entries_enabled_state(enabled = True):
def config_b_and_entries(enabled = True):
ends up taking me out of an object oriented focus / headspace of the
layout at hand.
And it is sort of like.. Ok I can either
b.config(command=lambda: (
a.expr,
b.expr.update({something: "morecomplicated"}),
c.expr
)
)
OR..
b.config(command=lambda a=a, b=b, c=c, s=something: foo(a, b, c, s))
somewhere else:
def foo(a, b, c, something):
a.expr
b.expr.update({something: "morecomplicated"})
c.expr
When you are trying to add a bit of dynamic feel to the tediousness of
the widget management, keeping things kind of contained to their object
just feels more natural to me (at the moment anyway).. (all the packing,
unpacking, making collections of widgets within frames appear or go away
based on states, colour changes based on input, dynamic widget
generation and where their relative attachment should go, etc)
I read a lot of sentiment against complicated lambdas suggesting one
should go for more functions, but I guess I feel pushing a more
complicated lambda to contain behavior more closely to an instance feels
more intuitive at the moment (and the sentiment against it doesn't
really resonate with me), so long as it isn't introducing some inherent
behavioral flaw or bug I am blind to..
Of course I might change my mind at some point during a refactor and
think "what the hell is that, why didn't I just..".. Which will probably
come in a few weeks. lol
One additional note on the Thread comment, I haven't really needed to
dig in to that too deeply, but Threading is amazing for tkinter UI
troubleshooting,
if you add something like:
t = threading.Thread(target=maintk.mainloop)
and run it with python -i
so long has you have attached every widget to some relative position on
to the root (maintk in this case), you can interact with any
object/widget directly live to see what is going on or what a change does.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Feature migration
Greg, Yes, it is very possible from other sources. I doubt it hurts if a popular language, albeit not compiled the same way, uses a feature. I see it a bit as more an impact on things like compiler/interpreter design in that once you see it can reasonably be implemented, some features look doable. I will say the exact methods and rules are different enough and interact with things differently. As an example, you can use an "end" statement at the end of a block to signal what is ending. As regularly repeated. There is no one right way but there are ways supported by the language you are in and others ways that are NOT supported. -Original Message- From: Python-list On Behalf Of Greg Ewing via Python-list Sent: Wednesday, March 8, 2023 5:47 PM To: python-list@python.org Subject: Re: Feature migration On 9/03/23 8:29 am, avi.e.gr...@gmail.com wrote: > They seem to be partially copying from python a > feature that now appears everywhere but yet strive for some backwards > compatibility. They simplified the heck out of all kinds of expressions by > using INDENTATION. It's possible this was at least parttly inspired by functional languages such as Haskell. Haskell has always allowed indentation as one way of expressing structure. Python wasn't the first language to use indentation semantically. -- Greg -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: JOB | Lead Linux Sysadmin (Edinburgh/London)
There's a link at the bottom of each message to the list info pager. Follow the directions on that page to unsubscribe. Skip On Wed, Mar 8, 2023, 5:38 PM Thomas Gregg wrote: > Is there any way to be removed from this list? > Thank you, Tom > > On Wed, Mar 8, 2023 at 3:51 PM Skip Montanaro > wrote: > > > > Hello, I'm working with an employer that is looking to hire someone in > > > (Edinburgh or London) that can administer on-prem and vmware > > > platforms. > > > > > > > James, > > > > If you haven't already, please post to the Phone Jobs Board: > > > > https://www.python.org/jobs/ > > > > Skip > > > > > > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Lambda returning tuple question, multi-expression
On 08Mar2023 16:56, aapost wrote: When making a UI there are a lot of binding/trace operations that need to occur that lead to a lot of annoying 1 use function definitions. I don't really see lambda use like below. Giving 2 working lambda examples using a returned tuple to accomplish multiple expressions - what sort of gotchas, if any, might make the following bad practice if I am missing something? There're no real gotchas: tuples are evaluated left to right, so you should have things happen in the order you've expressed them (if the order matters). What you lose with a lambda is control constructs like loops and if-statements (well, there's the `x if foo else y` but that gets cumbersome quickly). Once things get complicated you may want to define a more complication function using `def`: def callback1(): ... do complicated stuff ... b.config(command=callback1) The only other issue, which applies across the board with GUIs and is nothing specific to lambdas is that the GUI only renders and operates while the main loop is running. When your callbacks do trivial stuff you're fine. If they block (eg waiting for user input or network calls etc) the GUI is also blocked. You need threads or other concurrent approaches if the GUI is to stay responsive. The flip side of that is that a concurrent context like a Thread should not interact with the GUI directly. In things like Qt I've actually had that mistake crash the app because the Qt framework is (was?) not thread safe. You need to arrange that GUI actions occur in the main programme thread. I think the same applies with tk, and is anyway probably good practice for any GUI. It's not as hard as it sounds - typically when something happens asynchronously you arrange to issue an "event", and the GUI mainloop will process that as it happens - the event callback will be fired (called) by the main loop itself and thus the callback gets to do its thing in the main loop. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Lambda returning tuple question, multi-expression
On 3/8/2023 4:56 PM, aapost wrote: b = tk.Button(master=main, text="Enable") b.config( command=lambda: ( e1.config(state="normal"), e2.config(state="normal"), e3.config(state="normal") ) ) It's hard to understand what you are trying to do here. I don't remember just now what .config() will return, but the lambda will return a tuple of *something*, probably (None, None, None). Even if the tuple does contain three non-None values, config() requires named parameters, not a tuple. In the course of executing the lambda, your three controls e1, e2, and e2 will get configured, but you could just write a function to do that: def set_entries_enabled_state(enabled = True): state = 'normal' if enabled else 'disabled' for e in (e1, e2, e3): e.config(state=state) def config_b_and_entries(enabled = True): state = 'normal' if enabled else 'disabled' b.config(state = state) set_entries_enabled_state(enabled) This is easy to read and understand. (I may not have remembered some Tk details correctly). -- https://mail.python.org/mailman/listinfo/python-list
Re: JOB | Lead Linux Sysadmin (Edinburgh/London)
Is there any way to be removed from this list? Thank you, Tom On Wed, Mar 8, 2023 at 3:51 PM Skip Montanaro wrote: > > Hello, I'm working with an employer that is looking to hire someone in > > (Edinburgh or London) that can administer on-prem and vmware > > platforms. > > > > James, > > If you haven't already, please post to the Phone Jobs Board: > > https://www.python.org/jobs/ > > Skip > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Feature migration
On 9/03/23 8:29 am, avi.e.gr...@gmail.com wrote: They seem to be partially copying from python a feature that now appears everywhere but yet strive for some backwards compatibility. They simplified the heck out of all kinds of expressions by using INDENTATION. It's possible this was at least parttly inspired by functional languages such as Haskell. Haskell has always allowed indentation as one way of expressing structure. Python wasn't the first language to use indentation semantically. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Lambda returning tuple question, multi-expression
When making a UI there are a lot of binding/trace operations that need
to occur that lead to a lot of annoying 1 use function definitions. I
don't really see lambda use like below.
Giving 2 working lambda examples using a returned tuple to accomplish
multiple expressions - what sort of gotchas, if any, might make the
following bad practice if I am missing something?
Example 1:
import tkinter as tk
main = tk.Tk()
e1 = tk.Entry(master=main)
e1["state"] = "disabled"
e1.pack()
e2 = tk.Entry(master=main)
e2["state"] = "disabled"
e2.pack()
e3 = tk.Entry(master=main)
e3["state"] = "disabled"
e3.pack()
b = tk.Button(master=main, text="Enable")
b.config(
command=lambda: (
e1.config(state="normal"),
e2.config(state="normal"),
e3.config(state="normal")
)
)
b.pack()
Example 2:
import tkinter as tk
main = tk.Tk()
l = tk.Label(master=main)
l.a = {"seconds":0}
l._updater = lambda: (
l.a.update({"seconds": 1 + l.a["seconds"]}),
l.config(text=l.a["seconds"]),
l.after(ms=1000, func=l._updater)
)
l._updater()
l.pack()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fast full-text searching in Python (job for Whoosh?)
On 3/8/2023 3:27 PM, Peter J. Holzer wrote: On 2023-03-08 00:12:04 -0500, Thomas Passin wrote: On 3/7/2023 7:33 AM, Dino wrote: in fact it's a dilemma I am facing now. My back-end returns 10 entries (I am limiting to max 10 matches server side for reasons you can imagine). As the user keeps typing, should I restrict the existing result set based on the new information or re-issue a API call to the server? Things get confusing pretty fast for the user. You don't want too many cooks in kitchen, I guess. Played a little bit with both approaches in my little application. Re-requesting from the server seems to win hands down in my case. I am sure that them google engineers reached spectacular levels of UI finesse with stuff like this. Subject of course to trying this out, I would be inclined to send a much larger list of responses to the client, and let the client reduce the number to be displayed. The latency for sending a longer list will be smaller than establishing a new connection or even reusing an old one to send a new, short list of responses. That depends very much on how long that list can become. If it's 200 matches - sure, send them all, even if the client will display only 10 of them. Probably even for 2000. But if you might get 20 million matches you surely don't want to send them all to the client. Yes, of course. OTOH, if you have 2000+ possibilities it's basically pointless to send them to the client. You can send the first 10, and hope that will be worth something (it probably won't). You can send all 2000 and let the client show the first say 10, but that probably won't be worth much either. If you have some way to prioritize them, you can include the scores and send the top say 100 what you send to the client, and let the client figure out what to do. If you are going to have that many responses you will need some more complex and sophisticated approach anyway, so the whole discussion would not be applicable. And this would be getting miles (kms) away from the OP's situation. -- https://mail.python.org/mailman/listinfo/python-list
Re: JOB | Lead Linux Sysadmin (Edinburgh/London)
> Hello, I'm working with an employer that is looking to hire someone in > (Edinburgh or London) that can administer on-prem and vmware > platforms. > James, If you haven't already, please post to the Phone Jobs Board: https://www.python.org/jobs/ Skip > -- https://mail.python.org/mailman/listinfo/python-list
Re: Fast full-text searching in Python (job for Whoosh?)
On 2023-03-08 00:12:04 -0500, Thomas Passin wrote: > On 3/7/2023 7:33 AM, Dino wrote: > > in fact it's a dilemma I am facing now. My back-end returns 10 > > entries (I am limiting to max 10 matches server side for reasons you > > can imagine). As the user keeps typing, should I restrict the > > existing result set based on the new information or re-issue a API > > call to the server? Things get confusing pretty fast for the user. > > You don't want too many cooks in kitchen, I guess. > > Played a little bit with both approaches in my little application. > > Re-requesting from the server seems to win hands down in my case. > > I am sure that them google engineers reached spectacular levels of UI > > finesse with stuff like this. > > Subject of course to trying this out, I would be inclined to send a much > larger list of responses to the client, and let the client reduce the number > to be displayed. The latency for sending a longer list will be smaller than > establishing a new connection or even reusing an old one to send a new, > short list of responses. That depends very much on how long that list can become. If it's 200 matches - sure, send them all, even if the client will display only 10 of them. Probably even for 2000. But if you might get 20 million matches you surely don't want to send them all to the client. 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
Feature migration
This may be of interest to a few and is only partially about Python. In a recent discussion, I mentioned some new Python features (match) seemed related to a very common feature that has been in a language like SCALA for a long time. I suggested it might catch on and be used as widely as in SCALA and become the pythonic way to do many things, whatever that means, even as it's origins lie elsewhere. This motivated me to go take a new look at SCALA and I was a bit surprised. I will only mention two aspects as they relate to python. One is that they made a version 3 that has significant incompatibilities with version 2. Sounds familiar? The other fascinated me. They seem to be partially copying from python a feature that now appears everywhere but yet strive for some backwards compatibility. They simplified the heck out of all kinds of expressions by using INDENTATION. Lots of curly braces are now gone or optional. You need to indent carefully, and in places it is not quite the same as python. It is way more readable. Python always had indentation as a key feature. Since SCALA did not, it allows you to set options to turn off the new feature, sort of. As I have been saying, all kinds of ideas in computer science can migrate to new and existing languages, often not quite the same way. I am not endorsing SCALA, just noting that I suspect Python had some influence. -- https://mail.python.org/mailman/listinfo/python-list
Re: RE: Fast full-text searching in Python (job for Whoosh?)
On 3/7/2023 2:02 PM, avi.e.gr...@gmail.com wrote: Some of the discussions here leave me confused as the info we think we got early does not last long intact and often morphs into something else and we find much of the discussion is misdirected or wasted. Apologies. I'm the OP and also the OS (original sinner). My "mistake" was to go for a "stream of consciousness" kind of question, rather than a well researched and thought out one. You are correct, Avi. I have a simple web UI, I came across the Whoosh video and got infatuated with the idea that Whoosh could be used for create a autofill function, as my backend is already Python/Flask. As many have observed and as I have also quickly realized, Whoosh was overkill for my use case. In the meantime people started asking questions, I responded and, before you know it, we are all discussing the intricacies of JavaScript web development in a Python forum. Should I have stopped them? How? One thing is for sure: I am really grateful that so many used so much of their time to help. A big thank you to each of you, friends. Dino -- https://mail.python.org/mailman/listinfo/python-list
Re: Fast full-text searching in Python (job for Whoosh?)
On 3/7/2023 1:28 PM, David Lowry-Duda wrote: But I'll note that I use whoosh from time to time and I find it stable and pleasant to work with. It's true that development stopped, but it stopped in a very stable place. I don't recommend using whoosh here, but I would recommend experimenting with it more generally. Thank you, David. Noted. -- https://mail.python.org/mailman/listinfo/python-list
JOB | Lead Linux Sysadmin (Edinburgh/London)
Hello, I'm working with an employer that is looking to hire someone in (Edinburgh or London) that can administer on-prem and vmware platforms. Consequently, I had hoped that some members of this group may like to discuss further. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James -- https://mail.python.org/mailman/listinfo/python-list
