Re: yield from () Was: Re: weirdness with list()
On 28Feb2021 23:47, Alan Gauld wrote: >On 28/02/2021 00:17, Cameron Simpson wrote: >> BUT... It also has a __iter__ value, which like any Box iterates over >> the subboxes. For MDAT that is implemented like this: >> >> def __iter__(self): >> yield from () > >Sorry, a bit OT but I'm curious. I haven't seen >this before: > >yield from () > >What is it doing? >What do the () represent in this context? It's an empty tuple. The yield from iterates over the tuple, yielding zero times. There are shorter ways to write that (eg outright omitting the yield), except when you're writing a generator function with only a single yield statement - then you need something like that to make it a generator. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: weirdness with list()
On 01Mar2021 14:10, Grant Edwards wrote: >That was certainly my reaction. Can you imagine the confusion if len() >of a list returned the number of bytes required for srorage insttead >of the number of elements? Yeah, well the ancestry of these classes is a binary deserialise/serialise base class, so __len__ _is_ the natural thing - the length of the object when serialised. The conflation came when making a recursive hierarchical system to parse ISO14496 files (MOV, MP4). These have variable sized binary records which can themselves enclose other records, often an array of other records. That led me down the path of making an __iter__ (not previously present), without considering the __len__ interaction. I've split these things apart now, and will probably go the full step of not providing __iter__ at all, instead requiring things to reach for the .boxes attribute or a generic .subboxes() method, since not all these things have .boxes (depends on the record type). The design question is answered, and I consider myself at least somewhat spanked. However, the primary question was about sidestepping list()'s preallocation feature. That is also answered. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: is not recognized as an internal or external command, operable program or batch file.
Hi, On Mon, Mar 1, 2021 at 12:56 PM singh.veer9--- via Python-list wrote: > >Dear Sir/Madam > >Sir I am facing the issue from 10 days. And I tried all the ways to remove >this or to come out of this problem >but as i try to install some PYTEST or OPENPYXL packages using pip it >gives the notification that there is no writeable path present due to that >I am not “is not recognized as an internal or external command, operable >program or batch file.” I am facing problem in running the test cases in >Pycharm for the PYTEST >please help me pls Usual stanza: How exactly did you try to install them? Which OS are you running? What version of Python? Thank you. > > > > > >Sent from [1]Mail for Windows 10 > > > > References > >Visible links >1. https://go.microsoft.com/fwlink/?LinkId=550986 > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.10.0a6 is available, now with 100% more pattern matching
Remember us? It's your friendly CPython release team and we have something we think you may like: The new alpha release of Python 3.10 is here, now with 100% more pattern matching. If I were you, I would download it and start playing with it. Extra points if you report us any bugs you find along the way! Are you confused about all this pattern matching business? Fear not, this release also includes some fantastic documentation and some shiny new "What's new" entries. Check them here and tell us how we can improve it: What's new: https://docs.python.org/3.10/whatsnew/3.10.html Tutorial: https://docs.python.org/3.10/tutorial/controlflow.html#match-statements Go get the new alpha here: https://www.python.org/downloads/release/python-3100a6/ *Note: The alpha was officially released yesterday, but my email client failed to deliver this email to the mailing lists so I am reposting it.* **This is an early developer preview of Python 3.10** # Major new features of the 3.10 series, compared to 3.9 Python 3.10 is still in development. This release, 3.10.0a6 is the sixth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is **not** recommended for production environments. Many new features for Python 3.10 are still being planned and written. Among the new major new features and changes so far: * [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from Unicode * [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing union types as X | Y * [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter Specification Variables * [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line numbers for debugging and other tools. * [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now the default. * [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional Length-Checking To zip. * [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context managers are now officially allowed. * [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate distutils module. * [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type Aliases * [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural Pattern Matching: Specification * [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural Pattern Matching: Motivation and Rationale * [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural Pattern Matching: Tutorial * (Hey, **fellow core developer,** if a feature you find important is missing from this list, [let Pablo know](mailto:[email protected] ).) The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release), currently scheduled for Monday, 2021-04-05. # More resources * [Online Documentation](https://docs.python.org/3.10/) * [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after Albert Einstein and Nathan Rosen), are connections between areas of space that can be modelled as vacuum solutions to the Einstein field equations, and that are now understood to be intrinsic parts of the maximally extended version of the Schwarzschild metric describing an eternal black hole with no charge and no rotation. Here, "maximally extended" refers to the idea that the spacetime should not have any "edges": it should be possible to continue this path arbitrarily far into the particle's future or past for any possible trajectory of a free-falling particle (following a geodesic in the spacetime). Although Schwarzschild wormholes are not traversable in both directions, their existence inspired Kip Thorne to imagine traversable wormholes created by holding the "throat" of a Schwarzschild wormhole open with exotic matter (material that has negative mass/energy). Regards from rainy London, Pablo Galindo Salgado -- https://mail.python.org/mailman/listinfo/python-list
Why assert is not a function?
I have a curiosity. Python, as many languages, has assert as a keyword. Can't it be implemented as a function? Is there an advantage to have it as a keyword? -- https://mail.python.org/mailman/listinfo/python-list
Re: try to install Python3.9.2 / setup failed
On 3/1/21 10:46 AM, [email protected] wrote: Hello Python Team, i tried to install SW above; the installation stopped with the message "one or more issues caused the setup to fail. Please the issues and then retry 0x80070642 installation stopped by user" What must i do go get the SW installed? Windows 10, file "python-3.9.2-amd64.exe" Best Regards from Lake of Constance Manfred Schmidt With all due respect to the Microsoft folks here, Windows installation is a bit of a mess. When it finds something it doesn't like, it tends to throw its hands up and give you back an error that has a chance of not being terribly helpful to you, the user: you get a hex code, and an error string that doesn't seem to apply (pretty sure your installation wasn't stopped by _you_, despite what it says, though it _possibly_ could have been stopped by an external actor, like an antivirus program). Often these kinds of problems don't have a lot to do with the thing being installed, and do have a lot to do with other conditions. In my experience, this means you need to run some of the fixit tools to make sure your system doesn't have corruption that is confusing it. Try the ones from Microsoft - there's usually no need for third-party ones. I've had good luck with the one in the following link, though obviously no guarantees it will take care of this _specific_ issue: https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On 01/03/2021 00:47, Alan Gauld via Python-list wrote: On 28/02/2021 00:17, Cameron Simpson wrote: BUT... It also has a __iter__ value, which like any Box iterates over the subboxes. For MDAT that is implemented like this: def __iter__(self): yield from () Sorry, a bit OT but I'm curious. I haven't seen this before: yield from () What is it doing? What do the () represent in this context? The 0-tuple ;) yield from x is syntactic sugar for for item in x: yield item Instead of () you can use any empty iterable. If x is empty nothing is ever yielded. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Wed, Mar 3, 2021 at 7:53 AM Marco Sulla wrote: > > I have a curiosity. Python, as many languages, has assert as a > keyword. Can't it be implemented as a function? Is there an advantage > to have it as a keyword? It could, but it would need some magic. A lot of test frameworks have their own set of assertions and you have to pick the one you want - for instance: assertEqual(x, y) instead of assert x == y The trouble is that, if you write a function for this, it will just get True or False, without any explanation of the cause - making it somewhat unhelpful when something goes wrong. To compensate, function equivalents inevitably have to have myriad types of assertions, where the language just needs one. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
yield from () Was: Re: weirdness with list()
Alan Gauld wrote at 2021-2-28 23:47 +: >yield from () "yield from iterator" is similar to "for i in iterator: yield i" (with special handling when data/exceptions are injected into the generator). Thus, "yield from ()" does essentially nothing with the side effect that the containing function is treated as generator function. -- Dieter -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On Wed, Mar 3, 2021 at 8:21 AM Dieter Maurer wrote: > > Alan Gauld wrote at 2021-2-28 23:47 +: > >yield from () > > "yield from iterator" is similar to "for i in iterator: yield i" (with > special handling when data/exceptions are injected into the generator). > > Thus, "yield from ()" does essentially nothing with the side effect > that the containing function is treated as generator function. > Another way to write the same thing is: if False: yield None This, too, will do nothing - in fact, it will be optimized out completely in current versions of CPython - but, again, will force the function to be a generator. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On 28/02/2021 23:47, Alan Gauld via Python-list wrote: > On 28/02/2021 00:17, Cameron Simpson wrote: > >> BUT... It also has a __iter__ value, which like any Box iterates over >> the subboxes. For MDAT that is implemented like this: >> >> def __iter__(self): >> yield from () > > Sorry, a bit OT but I'm curious. I haven't seen > this before: > > yield from () > > What is it doing? > What do the () represent in this context? > Thanks for the replies. I should have known better but I was thinking some cleverness with callables and completely forgot the empty tuple syntax. Oops! -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: is not recognized as an internal or external command, operable program or batch file.
Hello, this is windows setup issue related to the fact that python binary is not in execution path. For setting up you may find instructions by searching for "windows 10 put python to path". One result is following page: https://superuser.com/questions/143119/how-do-i-add-python-to-the-windows-path ma 1. maalisk. 2021 klo 20.54 singh.veer9--- via Python-list ( [email protected]) kirjoitti: >Dear Sir/Madam > >Sir I am facing the issue from 10 days. And I tried all the ways to > remove >this or to come out of this problem >but as i try to install some PYTEST or OPENPYXL packages using pip it >gives the notification that there is no writeable path present due to > that >I am not “is not recognized as an internal or external command, operable >program or batch file.” I am facing problem in running the test cases > in >Pycharm for the PYTEST >please help me pls > > > > > >Sent from [1]Mail for Windows 10 > > > > References > >Visible links >1. https://go.microsoft.com/fwlink/?LinkId=550986 > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
There is also the, I think seldom used, feature that calling python with '-O' removes all assert statements at parse/compile time (I believe for performance reasons) So for example: $ python -c 'assert False' Traceback (most recent call last): File "", line 1, in AssertionError But: $ python -O -c 'assert False' [no output] $ Ignoring the question about this feature being particularly useful, it would be much harder to implement if assert were a standard function (and re-bindable), as the 'arguments' in the assert construct are not even executed when '-O' is used (this is the performance gain): $ python -O -c 'assert DoesNotExist' Traceback (most recent call last): File "", line 1, in NameError: name 'DoesNotExist' is not defined vs. $ python -O -c 'assert DoesNotExist' [no output] $ so the compiler would have to do a lot of work to identify assert calls and remove them. Steve On Tue, Mar 2, 2021 at 9:04 PM Chris Angelico wrote: > On Wed, Mar 3, 2021 at 7:53 AM Marco Sulla > wrote: > > > > I have a curiosity. Python, as many languages, has assert as a > > keyword. Can't it be implemented as a function? Is there an advantage > > to have it as a keyword? > > It could, but it would need some magic. A lot of test frameworks have > their own set of assertions and you have to pick the one you want - > for instance: > > assertEqual(x, y) > > instead of > > assert x == y > > The trouble is that, if you write a function for this, it will just > get True or False, without any explanation of the cause - making it > somewhat unhelpful when something goes wrong. To compensate, function > equivalents inevitably have to have myriad types of assertions, where > the language just needs one. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On Tue, Mar 2, 2021 at 5:51 AM Alan Gauld via Python-list wrote: > > On 28/02/2021 00:17, Cameron Simpson wrote: > > > BUT... It also has a __iter__ value, which like any Box iterates over > > the subboxes. For MDAT that is implemented like this: > > > > def __iter__(self): > > yield from () > > Sorry, a bit OT but I'm curious. I haven't seen > this before: > > yield from () > > What is it doing? > What do the () represent in this context? > It's yielding all the elements in an empty tuple. Which is none of them, meaning that - for this simple example - iterating over the object will produce zero results. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python 3.10.0a6 is available, now with 100% more pattern matching
Remember us? It's your friendly CPython release team and we have something we think you may like: The new alpha release of Python 3.10 is here, now with 100% more pattern matching. If I were you, I would download it and start playing with it. Extra points if you report us any bugs you find along the way! Are you confused about all this pattern matching business? Fear not, this release also includes some fantastic documentation and some shiny new "What's new" entries. Check them here and tell us how we can improve it: What's new: https://docs.python.org/3.10/whatsnew/3.10.html Tutorial: https://docs.python.org/3.10/tutorial/controlflow.html#match-statements Go get the new alpha here: https://www.python.org/downloads/release/python-3100a6/ **This is an early developer preview of Python 3.10** # Major new features of the 3.10 series, compared to 3.9 Python 3.10 is still in development. This release, 3.10.0a6 is the sixth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is **not** recommended for production environments. Many new features for Python 3.10 are still being planned and written. Among the new major new features and changes so far: * [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from Unicode * [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing union types as X | Y * [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter Specification Variables * [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line numbers for debugging and other tools. * [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now the default. * [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional Length-Checking To zip. * [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context managers are now officially allowed. * [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate distutils module. * [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type Aliases * [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural Pattern Matching: Specification * [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural Pattern Matching: Motivation and Rationale * [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural Pattern Matching: Tutorial * (Hey, **fellow core developer,** if a feature you find important is missing from this list, [let Pablo know](mailto:[email protected] ).) The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release), currently scheduled for Monday, 2021-04-05. # More resources * [Online Documentation](https://docs.python.org/3.10/) * [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after Albert Einstein and Nathan Rosen), are connections between areas of space that can be modelled as vacuum solutions to the Einstein field equations, and that are now understood to be intrinsic parts of the maximally extended version of the Schwarzschild metric describing an eternal black hole with no charge and no rotation. Here, "maximally extended" refers to the idea that the spacetime should not have any "edges": it should be possible to continue this path arbitrarily far into the particle's future or past for any possible trajectory of a free-falling particle (following a geodesic in the spacetime). Although Schwarzschild wormholes are not traversable in both directions, their existence inspired Kip Thorne to imagine traversable wormholes created by holding the "throat" of a Schwarzschild wormhole open with exotic matter (material that has negative mass/energy). Regards from rainy London, Pablo Galindo Salgado -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
> On 2 Mar 2021, at 20:54, Marco Sulla wrote: > > I have a curiosity. Python, as many languages, has assert as a > keyword. Can't it be implemented as a function? Is there an advantage > to have it as a keyword? assert condition, expression Only is condition is false with expression be evaluated. So you can safely do expensive things I the expression with incuring and cost if the condition is True. With a function assert the 2nd part would have to evaluated regardless of the state of the condition. Which would slow down the code for no benefit. Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On Mon, 1 Mar 2021 at 19:51, Alan Gauld via Python-list wrote: > Sorry, a bit OT but I'm curious. I haven't seen > this before: > > yield from () > > What is it doing? > What do the () represent in this context? It's the empty tuple. -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On Tue, Mar 2, 2021 at 2:16 PM Chris Angelico wrote: > > On Tue, Mar 2, 2021 at 5:51 AM Alan Gauld via Python-list > wrote: > > > > On 28/02/2021 00:17, Cameron Simpson wrote: > > > > > BUT... It also has a __iter__ value, which like any Box iterates over > > > the subboxes. For MDAT that is implemented like this: > > > > > > def __iter__(self): > > > yield from () > > > > Sorry, a bit OT but I'm curious. I haven't seen > > this before: > > > > yield from () > > > > What is it doing? > > What do the () represent in this context? > > > > It's yielding all the elements in an empty tuple. Which is none of > them, meaning that - for this simple example - iterating over the > object will produce zero results. I discovered something new (to me) yesterday. Was writing a unit test for generator function and I found that none of the function got executed at all until I iterated on the return value. It was blowing my mind as I was debugging the test and had a BP set in the first line of the function but it was not hit when I called the function. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
Am 02.03.2021 um 23:09 schrieb Stestagg: > Ignoring the question about this feature being particularly useful, it It is useful because "assert" is primarily (if not purely and exclusive) a debugging tool during development and testing. In production code you don't want any asserts, but logging. Having "assert" being a function would make it much harder to get rid of it in production code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list wrote: > > Am 02.03.2021 um 23:09 schrieb Stestagg: > > Ignoring the question about this feature being particularly useful, it > > It is useful because "assert" is primarily (if not purely and > exclusive) a debugging tool during development and testing. > > In production code you don't want any asserts, but logging. Having > "assert" being a function would make it much harder to get rid of it > in production code. > Really? if PRODUCTION: def assert(*a, **kw): pass would work if it were a function :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
Am 03.03.2021 um 00:24 schrieb Chris Angelico: > On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list > wrote: >> >> Am 02.03.2021 um 23:09 schrieb Stestagg: >>> Ignoring the question about this feature being particularly useful, it >> >> It is useful because "assert" is primarily (if not purely and >> exclusive) a debugging tool during development and testing. >> >> In production code you don't want any asserts, but logging. Having >> "assert" being a function would make it much harder to get rid of it >> in production code. >> > > Really? Yes. > if PRODUCTION: > def assert(*a, **kw): pass > > would work if it were a function :) With the "if PRODUCTION" being superfluously in the production code (not to mention the possible NameError otherwise). -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Wed, Mar 3, 2021 at 10:48 AM Hexamorph wrote: > > Am 03.03.2021 um 00:24 schrieb Chris Angelico: > > On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list > > wrote: > >> > >> Am 02.03.2021 um 23:09 schrieb Stestagg: > >>> Ignoring the question about this feature being particularly useful, it > >> > >> It is useful because "assert" is primarily (if not purely and > >> exclusive) a debugging tool during development and testing. > >> > >> In production code you don't want any asserts, but logging. Having > >> "assert" being a function would make it much harder to get rid of it > >> in production code. > >> > > > > Really? > > Yes. > > > if PRODUCTION: > > def assert(*a, **kw): pass > > > > would work if it were a function :) > > With the "if PRODUCTION" being superfluously in the production code > (not to mention the possible NameError otherwise). > Whatever method you have for determining whether you're in debug or prod, you can use it to decide whether or not to create the function. It's that easy. That said, though... I prefer to keep my assertions in prod too. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: yield from () Was: Re: weirdness with list()
On 02Mar2021 15:06, Larry Martell wrote: >I discovered something new (to me) yesterday. Was writing a unit test >for generator function and I found that none of the function got >executed at all until I iterated on the return value. Aye. Generators are lazy - they don't run at all until you ask for a value. By contrast, this is unlike Go's goroutines, which are busy - they commence operation as soon as invoked and run until the first yield (channel put, I forget how it is spelled now). This can cause excessive CPU utilisation, but it handle for _fast_ production of results. Which is a primary goal in Go's design. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter long-running window freezes
On Wed, 24 Feb 2021 22:35:32 +1100
John O'Hagan wrote:
> Hi list
>
> I have a 3.9 tkinter interface that displays data from an arbitrary
> number of threads, each of which runs for an arbitrary period of time.
> A frame opens in the root window when each thread starts and closes
> when it stops. Widgets in the frame and the root window control the
> thread and how the data is displayed.
>
> This works well for several hours, but over time the root window
> becomes unresponsive and eventually freezes and goes grey. No error
> messages are produced in the terminal.
>
> Here is some minimal, non-threaded code that reproduces the problem on
> my system (Xfce4 on Debian testing):
>
> from tkinter import *
> from random import randint
>
> root = Tk()
>
> def display(label):
> label.destroy()
> label = Label(text=randint(0, 9))
> label.pack()
> root.after(100, display, label)
>
> display(Label())
> mainloop()
>
> This opens a tiny window that displays a random digit on a new label
> every .1 second. (Obviously I could do this by updating the text
> rather than recreating the label, but my real application has to
> destroy widgets and create new ones).
>
> This works for 3-4 hours, but eventually the window freezes.
Thanks to those that replied to this.
To summarise my tentative and incomplete conclusions, it seems that
tkinter doesn't like a lot of widgets being created and destroyed in a
long running process and will/may eventually freeze if this is done,
for a reason I haven't been able to fathom. Tk internally keeps names
of all widgets created, and this will cause a slow memory-use increase
if not prevented by manually re-using widget names, but this is not the
cause of the freezing.
Here is a simplified version of how I worked around the issue by
recycling widgets:
from tkinter import *
class WidgetHandler:
"Reuse tkinter widgets"
widget_cache = []
def __init__(self, main_window, *args):
self.datastream = MyDataStream(*args)
self.main_window = main_window
if self.widget_cache:
self.widget = self.widget_cache.pop()
self.clean(self.widget)
else:
self.widget = self.new_widget()
#add functionality to widgets, e.g:
self.widget.var.traceid = self.widget.var.trace('w', self.meth1)
self.widget.button.configure(command=self.meth2)
self.widget.button.pack()
#etc
self.widget.pack()
def clean(self, widget):
"Remove traces, clear text boxes, reset button states etc"
#e.g:
self.widget.var.trace_remove('write', var.traceid)
self.widget.button['state'] = 'normal'
#etc
def new_widget(self):
"Create widget and children without adding any commands, traces etc"
widget = Frame(self.main_window)
#e.g:
widget.var = StringVar()
widget.button = Checkbutton(widget, variable=widget.var)
#etc
return widget
def meth1(self, *e):
pass
#do something with self.datastream
def meth2(self):
pass
#do something else with self.datastream
#etc
def quit(self):
self.datastream.quit()
self.widget.pack_forget()
self.widget_cache.append(self.widget)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On 3/03/21 12:24 pm, Chris Angelico wrote: if PRODUCTION: def assert(*a, **kw): pass would work if it were a function :) But would cost you a useless function call for every assert in production mode. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: editor recommendations?
Ethan Furman wrote: > I'm currently using vim, and the primary reason I've stuck with it for so > long is because I can get truly black screens with it. By which I mean that > I have a colorful window title bar, a light-grey menu bar, and then a > light-grey frame around the text-editing window (aka the only window), and a > nice, black-background editing area. I use vim. It's actually extremely powerful, especially for text/code editing. I'd recommend reading one of the many books on using vim effectively. Also, plugins can really add a lot... -- rust 0x68caecc97f6a90122e51c0692c88d9cb6b58a3dc -- https://mail.python.org/mailman/listinfo/python-list
Re: editor recommendations?
On Tue, Mar 2, 2021 at 8:00 PM Russell wrote: > Ethan Furman wrote: > > I'm currently using vim, and the primary reason I've stuck with it for > so long is because I can get truly black screens with it. By which I mean > that I have a colorful window title bar, a light-grey menu bar, and then a > light-grey frame around the text-editing window (aka the only window), and > a nice, black-background editing area. > > I use vim. It's actually extremely powerful, especially for text/code > editing. I'd recommend reading one of the many books on using vim > effectively. Also, plugins can really add a lot... > On the subject of learning vim: There's an excellent vi cheat sheet available on the internet. I've put a copy of it at https://stromberg.dnsalias.org/~strombrg/vi.ref.6 vi is of course the predecessor of vim. But that cheat sheet is still great for learning much of vim. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why assert is not a function?
On Wed, Mar 3, 2021 at 2:06 PM Greg Ewing wrote: > > On 3/03/21 12:24 pm, Chris Angelico wrote: > > if PRODUCTION: > > def assert(*a, **kw): pass > > > > would work if it were a function :) > > But would cost you a useless function call for every assert > in production mode. > A micro-optimization that would almost never actually impact your code. But considering that I'm willing to keep *the entire check* active, it's possible I'm slightly biased in favour of debuggability at the cost of CPU... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: editor recommendations?
On Tue, Mar 2, 2021 at 8:11 PM Dan Stromberg wrote: > > On Tue, Mar 2, 2021 at 8:00 PM Russell wrote: > >> Ethan Furman wrote: >> > I'm currently using vim, and the primary reason I've stuck with it for >> so long is because I can get truly black screens with it. By which I mean >> that I have a colorful window title bar, a light-grey menu bar, and then a >> light-grey frame around the text-editing window (aka the only window), and >> a nice, black-background editing area. >> >> I use vim. It's actually extremely powerful, especially for text/code >> editing. I'd recommend reading one of the many books on using vim >> effectively. Also, plugins can really add a lot... >> > > On the subject of learning vim: There's an excellent vi cheat sheet > available on the internet. I've put a copy of it at > https://stromberg.dnsalias.org/~strombrg/vi.ref.6 > > vi is of course the predecessor of vim. But that cheat sheet is still > great for learning much of vim. > I just ran across: http://lib.ru/MAN/viref.txt ...which is pretty much the same thing, but converted to nice HTML. -- https://mail.python.org/mailman/listinfo/python-list
