[Python-announce] Austin -- CPython frame stack sampler v3.6 is now available
I am delighted to announce the 3.6 release of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running in a production environment, with minimal impact on performance. https://github.com/P403n1x87/austin The main highlights of the new release are the support for Python 3.12, and the support for sub-interpreters. More details about what's new and bug-fixes can be found in the change-log https://github.com/P403n1x87/austin/blob/master/ChangeLog Installing Austin on your system is now easier than ever, thanks to it being available from PyPI. Simply run pip install austin-dist on any supported combination of architecture and platform and the Austin binaries are ready for you to use. More installation options are available in the README file from the GitHub repository, along with usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. As for ways of using Austin, the Austin VS Code extension provides a smooth interactive profiling experience, with interactive flame graphs straight into the text editor to allow you to quickly jump to the source code with a simple click. You can find the extension on the Visual Studio Marketplace and install it directly from VS Code: https://marketplace.visualstudio.com/items?itemName=p403n1x87.austin-vscode To see how to make the best of Austin with VS Code to find and fix performance issues, check out this blog post, which shows you the editor extension in action on a real Python project: https://p403n1x87.github.io/how-to-bust-python-performance-issues.html Austin is a pure C application that has no dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin An Austin docker image, based on the latest Ubuntu image, is also available from Docker Hub: https://hub.docker.com/r/p403n1x87/austin Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above-listed sources. You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). Austin is a free and open-source project. A lot of effort goes into its development to ensure the best performance and that it stays up-to-date with the latest Python releases. If you find it useful, consider sponsoring this project on GitHub at https://github.com/sponsors/P403n1x87. All the best, Gabriele https://github.com/P403n1x87/austin;>Austin 3.6 - frame stack sampler for CPython. (04-Oct-23) ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
Re: type annotation vs working code
Am Wed, Oct 04, 2023 at 05:25:04PM +1300 schrieb dn via Python-list:
> The first question when dealing with the Singleton Pattern is what to do when
> more than
> one instantiation is attempted:
>
> - silently return the first instance
This, in my case.
> and so, returning to the matter of 'readability':
>
> - the name "Borg" de-railed comprehension
>
> - _instances:dict = {} implied the tracking of more than one
Child classes, yes, each being a Singleton.
> or a Singleton() class defined, which is then sub-classed, ie
>
> class Something( Singleton ):
Could have been but the legacy codebase came with Borg ...
> - from there, plenty of 'templates' exist for Singletons,
... which was taken from the Web ages ago.
> - this article (https://python-patterns.guide/gang-of-four/singleton/)
Reading.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unable to completely remove Python 3.10.9 (64 bit) from Computer
On 25.9.2023 19.58, Pau Vilchez via Python-list wrote: Hello Python Team, I am somehow unable to completely remove Python 3.10.9 (64 Bit) from my computer. I have tried deleting the Appdata folder then repairing and then uninstalling but it still persists in the remove/add program function in windows 10. I am just trying to reinstall it because I didn’t add it to the path correctly, any help is greatly appreciated. This is a Windows issue and not actually Python -specific. It may happen to every program you install. If something is installed by the normal way using the W10 installer it should be removable too. If not there should be some error. Very Respectfully, Pau Vilchez -- https://mail.python.org/mailman/listinfo/python-list
Unable to completely remove Python 3.10.9 (64 bit) from Computer
Hello Python Team, I am somehow unable to completely remove Python 3.10.9 (64 Bit) from my computer. I have tried deleting the Appdata folder then repairing and then uninstalling but it still persists in the remove/add program function in windows 10. I am just trying to reinstall it because I didn’t add it to the path correctly, any help is greatly appreciated. Very Respectfully, Pau Vilchez -- https://mail.python.org/mailman/listinfo/python-list
Re: type annotation vs working code
On 04/10/2023 19.41, Chris Angelico via Python-list wrote: On Wed, 4 Oct 2023 at 15:27, dn via Python-list wrote: - should the class have been called either; class SomethingSingleton(): or a Singleton() class defined, which is then sub-classed, ie class Something( Singleton ): in order to better communicate the coder's intent to the reader? TBH, I don't think it's right to have a Singleton class which is subclassed by a bunch of different singletons. They aren't really subclasses of the same class. I could imagine Singleton being a metaclass, perhaps, but otherwise, they're not really similar to each other. I'm with you on this - should have made Singleton() an ABC. Yes, would only be a skeleton around which concrete singleton classes could be built. Like you, I v.rarely use them - but which means that the ABC is useful because it would save me from having to remember the curly-bits all-over-again... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: type annotation vs working code
On Wed, 4 Oct 2023 at 17:47, Greg Ewing via Python-list wrote: > > On 4/10/23 5:25 pm, dn wrote: > > The first question when dealing with the Singleton Pattern is what to do > > when more than one instantiation is attempted > > My preferred way of handling singletons is not to expose the class > itself, but a function that creates an instance the first time it's > called, and returns that instance subsequently. The problem then > doesn't arise. > That's one option. Personally, I don't use them very much, but if I do, it's usually actually as a class that never gets instantiated: class PileOfAttributes: x = 1 y = 2 spam = "ham" ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: type annotation vs working code
On 4/10/23 5:25 pm, dn wrote: The first question when dealing with the Singleton Pattern is what to do when more than one instantiation is attempted My preferred way of handling singletons is not to expose the class itself, but a function that creates an instance the first time it's called, and returns that instance subsequently. The problem then doesn't arise. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: type annotation vs working code
On Wed, 4 Oct 2023 at 15:27, dn via Python-list wrote: > - should the class have been called either; > > class SomethingSingleton(): > > or a Singleton() class defined, which is then sub-classed, ie > > class Something( Singleton ): > > in order to better communicate the coder's intent to the reader? TBH, I don't think it's right to have a Singleton class which is subclassed by a bunch of different singletons. They aren't really subclasses of the same class. I could imagine Singleton being a metaclass, perhaps, but otherwise, they're not really similar to each other. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
