Re: New assignmens ...
It seemed weird to me that only an identifier was allowed to be the target of an assignment expression. Then it occurred to me that function definitions are another place where only identifiers are allowed, but where I could imagine an attributeref or a subscription being used. E.g. def table[i](x): ... would mean the same thing as: def _temp_(x): ... table[i] = _temp_ I don't immediately see that this would screw up the grammar in any way, so why not allow it? A `def` statement is just another form of assignment, so just as for `:=` expressions, we should allow the target to be as general as possible! I'm guessing that about 70% of you will think that this is a horrible idea, 10% of you will find it compelling, and the remaining 20% will find themselves conflicted. You can count me in that last category... -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
Op 23/10/2021 om 03:22 schreef Stefan Ram: > Paulo da Silva writes: >> Well, I didn't follow the discussion of this new feature, but the reason >> I can see behind allowing it seems so valid for for ctr:=ctr-1 as for >> self.ctr:=self.ctr-1. The kind of use is exactly the same. One is for a >> normal function, the other for a method. > The intention of the introduction of the assignment expression > was to allow grab the values of subexpressions so as to be able > to later use these value. This can be done with an identifier: > > if env_base := os.environ.get( "PYTHONUSERBASE", None ): > return env_base > > . I am wondering what use cases are there for having something > different than an identifier on the left side. 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 -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Unable to Install Matplotlib & Pandas for Python 3.10
Hello, I downloaded & installed Python 3.10 but it didn't replace Python 3.9. And now I can't install Matplotlib & Pandas. What should I do? -- https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ...
On Mon, Oct 25, 2021 at 2:13 AM Alan Bawden wrote:
>
> It seemed weird to me that only an identifier was allowed to be the
> target of an assignment expression. Then it occurred to me that
> function definitions are another place where only identifiers are
> allowed, but where I could imagine an attributeref or a subscription
> being used. E.g.
>
> def table[i](x):
> ...
>
> would mean the same thing as:
>
> def _temp_(x):
> ...
> table[i] = _temp_
>
> I don't immediately see that this would screw up the grammar in any way,
> so why not allow it? A `def` statement is just another form of
> assignment, so just as for `:=` expressions, we should allow the target
> to be as general as possible!
>
> I'm guessing that about 70% of you will think that this is a horrible
> idea, 10% of you will find it compelling, and the remaining 20% will
> find themselves conflicted. You can count me in that last category...
This has come up periodically, but it's a bit tricky to define some of
the edge cases, like what the function's name should be. But it would
definitely help with building dispatch tables. Currently, I tend to
build them with a decorator:
tools = {}
def tool(f):
tools[f.__name__] = f
return f
@tool
def frobnicate(): ...
@tool
def spamify(): ...
In theory, it would be possible to do this:
def tools["frobnicate"](): ...
But I'm not sure that it's truly better.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unable to Install Matplotlib & Pandas for Python 3.10
On 2021-10-24 12:41, Anik Dey wrote: Hello, I downloaded & installed Python 3.10 but it didn't replace Python 3.9. And now I can't install Matplotlib & Pandas. What should I do? Multiple versions of Python can exist alongside each other. You haven't said what you mean by "can't install". If you're on Windows, you can install libraries by using the Windows Command Prompt and typing: py -3.10 -m pip install matplotlib py -3.10 -m pip install pandas "py" is the Python launcher and "py -3.10" will make it run Python 3.10 specifically. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to Install Matplotlib & Pandas for Python 3.10
On 10/24/21 09:46, MRAB wrote: On 2021-10-24 12:41, Anik Dey wrote: Hello, I downloaded & installed Python 3.10 but it didn't replace Python 3.9. And now I can't install Matplotlib & Pandas. What should I do? Multiple versions of Python can exist alongside each other. You haven't said what you mean by "can't install". If you're on Windows, you can install libraries by using the Windows Command Prompt and typing: py -3.10 -m pip install matplotlib py -3.10 -m pip install pandas except... if there aren't wheels yet. easy to check: https://pypi.org/project/matplotlib/#files https://pypi.org/project/pandas/#files and... there aren't. stick with 3.9 for now if you really need these, or go with one of the unofficial builds that can be found with some searching. -- https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ...
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 could make an argument that everywhere you can put in a character string should also allow a regular expression but why? It makes no sense to allow you to supply a filename to create using a regular expression as you are not matching anything. Worse, perfectly valid string that may contain a dollar sign or period or many other characters used in regular expression may really be messed up if evaluated as a regular expression. So is it any wonder NOBODY suggests the above be done? As Chris has said, something was added to Python that is a partial implementation. There are fairly reasonable ways to do additional things and until recently, those were the proper and only way. But the recent change does not preclude a later upgrade if anyone is not only convinced it is worth doing but of higher priority than the scarce resources needed to do lots of other worthy and requested things including fixing bugs. 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. Now if anyone wants to donate a few hundred thousand dollars if used to make the change, or offer to do it free, who knows? Of course, this means anyone using the feature may need to check your version of Python to see if the feature exists before ... -Original Message- From: Python-list On Behalf Of Alan Bawden Sent: Sunday, October 24, 2021 3:53 AM To: [email protected] Subject: Re: New assignmens ... It seemed weird to me that only an identifier was allowed to be the target of an assignment expression. Then it occurred to me that function definitions are another place where only identifiers are allowed, but where I could imagine an attributeref or a subscription being used. E.g. def table[i](x): ... would mean the same thing as: def _temp_(x): ... table[i] = _temp_ I don't immediately see that this would screw up the grammar in any way, so why not allow it? A `def` statement is just another form of assignment, so just as for `:=` expressions, we should allow the target to be as general as possible! I'm guessing that about 70% of you will think that this is a horrible idea, 10% of you will find it compelling, and the remaining 20% will find themselves conflicted. You can count me in that last category... -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to Install Matplotlib & Pandas for Python 3.10
On 2021-10-24 23:59, Mats Wichmann wrote: On 10/24/21 09:46, MRAB wrote: > On 2021-10-24 12:41, Anik Dey wrote: >> Hello, I downloaded & installed Python 3.10 but it didn't replace Python >> 3.9. And now I can't install Matplotlib & Pandas. What should I do? >> > Multiple versions of Python can exist alongside each other. > > You haven't said what you mean by "can't install". > > If you're on Windows, you can install libraries by using the Windows > Command Prompt and typing: > > py -3.10 -m pip install matplotlib > py -3.10 -m pip install pandas except... if there aren't wheels yet. easy to check: https://pypi.org/project/matplotlib/#files https://pypi.org/project/pandas/#files and... there aren't. stick with 3.9 for now if you really need these, or go with one of the unofficial builds that can be found with some searching. Ah, yes, Christoph Gohlke's site has them: https://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib -- https://mail.python.org/mailman/listinfo/python-list
what's unsafe to do in a __getattr__?
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(). I don't want to write a massive essay here but hoping to give enough to set the context. There's a class that's a kind of proxy, so there's some "magic" that could be present. The magic is detected by looking for a kind of memo annotation, so the __getattr__ starts with this: # Methods that make this class act like a proxy. def __getattr__(self, name): attr = getattr(self.__dict__['__subject'], name) and that's what blows up. It happens for a user doing something we... ahem... don't expect. They just picked up the Py3-only version of the project and now they're getting the issue. Nothing in the project defined a __reduce__ex__ function, but one is picked up from the base "object" type, so copy.copy generates some pickle information and passes it to copy._reconstruct as the state parameter. This stanza: if state is not None: ... if hasattr(y, '__setstate__'): y.__setstate__(state) so our class's __getattr__ is called to look for __setstate__. But at this stage, the copy's instance has only been created, the operations that will fill in the details haven't happened yet, so we take a KeyError. So apparently the attempt in the __getattr__ to go fishing in our own dict for something we set ourselves is unsafe. Is there a guideline for what you can / cannot expect to be safe to do? My naiive expectations would be that when __getattr__ is called, you can expect an instance to have been already initialized, but if I'm not reading the copy module wrong, that's not always true. Is a better answer for this class to provide a __copy__ method to more precisely control how copying happens? -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter][Windows]Unexpected state report for the tab key
On 10/24/21, Stefan Ram wrote: > [email protected] (Stefan Ram) writes: >>tab_down_hllDll.GetKeyState(tab_down_VK_TAB) & 0b1000 > > In the meantime, I read about "GetAsyncKeyState". I thought that > this would solve my problem, but no. Odd. It works for me in the classic console and the Windows Terminal pseudoconsole. The tab key's up/down state is updated immediately. import ctypes import msvcrt import time kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) user32 = ctypes.WinDLL('user32', use_last_error=True) VK_TAB = 0x09 def tab_down(): return bool(user32.GetAsyncKeyState(VK_TAB) & 0x8000) def flush_console_input(): """Flush the input buffer of the process (pseudo)console.""" try: with open('conin$') as f: h = msvcrt.get_osfhandle(f.fileno()) kernel32.FlushConsoleInputBuffer(h) except OSError: pass def test(): for i in range(100): print('tab down:', tab_down()) time.sleep(0.1) flush_console_input() test() Flushing the console input buffer isn't necessary. I just prefer it instead of leaving the key presses in the buffer. Usually a GUI wants GetKeyState() instead, which is synchronized with input messages in the thread's message queue as they're processed. But GetAsyncKeyState() should do what you want, if you don't need synchronization with input messages. -- https://mail.python.org/mailman/listinfo/python-list
