[RELEASE] Python 3.13.0 beta 4 released.
Python 3.13.0b4, the final beta of Python 3.13, is now available: https://www.python.org/downloads/release/python-3130b4/ *This is a beta preview of Python 3.13* Python 3.13 is still in development. This release, 3.13.0b4, is the *final* beta release preview of 3.13. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We *strongly encourage* maintainers of third-party Python projects to *test with 3.13* during the beta phase and report issues found to the Python bug tracker <https://github.com/python/cpython/issues> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have *no ABI changes* after this final beta release, and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be *extremely important* to get as much exposure for 3.13 as possible during the beta phase. Please keep in mind that this is a preview release and its use is *not* recommended for production environments. <https://discuss.python.org/t/python-3-13-0b4-now-available/58565#major-new-features-of-the-313-series-compared-to-312-1>Major new features of the 3.13 series, compared to 3.12 Some of the new major new features and changes in Python 3.13 are: <https://discuss.python.org/t/python-3-13-0b4-now-available/58565#new-features-2>New features - A new and improved interactive interpreter <https://docs.python.org/3.13/whatsnew/3.13.html#a-better-interactive-interpreter>, based on PyPy <https://pypy.org>’s, featuring multi-line editing and color support, as well as colorized exception tracebacks <https://docs.python.org/3.13/whatsnew/3.13.html#improved-error-messages> . - An *experimental* free-threaded build mode <https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>, which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well. - A preliminary, *experimental* JIT <https://docs.python.org/3.13/whatsnew/3.13.html#experimental-jit-compiler>, providing the ground work for significant performance improvements. - The locals() builtin function (and its C equivalent) now has well-defined semantics when mutating the returned mapping <https://docs.python.org/3.13/whatsnew/3.13.html#defined-mutation-semantics-for-locals>, which allows debuggers to operate more consistently. - The (cyclic) garbage collector is now incremental <https://docs.python.org/3.13/whatsnew/3.13.html#incremental-garbage-collection>, which should mean shorter pauses for collection in programs with a lot of objects. - A modified version of mimalloc <https://github.com/microsoft/mimalloc> is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode. - Docstrings now have their leading indentation stripped <https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes>, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.) - The dbm module <https://docs.python.org/3.13/library/dbm.html> has a new dbm.sqlite3 backend <https://docs.python.org/3.13/whatsnew/3.13.html#dbm> that is used by default when creating new files. - The minimum supported macOS version was changed from 10.9 to *10.13 (High Sierra)*. Older macOS versions will not be supported going forward. - WASI is now a Tier 2 supported platform <https://peps.python.org/pep-0011/#tier-2>. Emscripten is no longer an officially supported platform <https://peps.python.org/pep-0011/#no-longer-supported-platforms> (but Pyodide <https://pyodide.org> continues to support Emscripten). <https://discuss.python.org/t/python-3-13-0b4-now-available/58565#typing-3> Typing - Support for type defaults in type parameters <https://peps.python.org/pep-0696/>. - A new type narrowing annotation <https://peps.python.org/pep-0742/>, typing.TypeIs. - A new annotation for read-only items in TypeDicts <https://peps.python.org/pep-0705/>. - A new annotation for marking deprecations in the type system <https://peps.python.org/pep-0702>. <https://discuss.python.org/t/python-3-13-0b4-now-available/58565#removals-and-new-deprecations-4>Removals and new deprecations - PEP 594 (Removing dead batteries from the standard library) <https://peps.python.org/pep-0594/> scheduled removals of many deprecated modul
Re: Password Hash Validation (Posting On Python-List Prohibited)
On Fri, 21 Jun 2024 06:32:58 - (UTC), I wrote: > On Fri, 21 Jun 2024 03:40:55 - (UTC), I wrote: > >> I think I will create my own wrapper using ctypes. > > Done <https://gitlab.com/ldo/nixcrypt>. The repo now includes an example script that exercises the various functions of the module. -- https://mail.python.org/mailman/listinfo/python-list
Re: python repl vi mode line editing not working.
I see the literal 'escape' character + 'k', when it should let me edit previous commands. I did have to compile my own python because I'm using 2.7 on this machine. I figured it out. I needed to apt install libreadline-dev. -- https://mail.python.org/mailman/listinfo/python-list
Re: python repl vi mode line editing not working.
For this to work, the Python implementation should use the same readline library as your shell, I guess. It works in python3, so I guess my problem is that I'm compiling python (I think kubuntu dropped python2), but I don't see any relevant options in the configure help. -- https://mail.python.org/mailman/listinfo/python-list
python repl vi mode line editing not working.
Kubuntu 24.04. sinewave:toby ~(1)> cat .inputrc set editing-mode vi set keymap vi sinewave:toby ~(1)> cat .editrc bind -v bind \\t rl_complete sinewave:toby ~(1)> python Python 2.7.18 (default, Jul 8 2024, 12:49:12) [GCC 13.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. 1 1 2 2 ^[k I see the literal 'escape' character + 'k', when it should let me edit previous commands. I did have to compile my own python because I'm using 2.7 on this machine. Thanks for any help. Toby -- https://mail.python.org/mailman/listinfo/python-list
Re: python for irc client
Daniel via Python-list writes: > One thing missing is a good textmode irc client that will connect to > quassel core. > > I've seen efforts to make a plugin for weechat but, to date, I don't see much > progress on that end. > > In your wisdom, would python be a good environment to accomplish this? I'd > likely use extended ascii and colors. The point would be to minimize the > memory footprint of the application. One feature of weechat you may be interested in is it's relay mode: https://weechat.org/files/doc/weechat/stable/weechat_user.en.html#relay If you flipped this architecture around you should be able to run weechat as your bouncer then connect quassel or any other client to weechat with it's IRC relay mode. Weechat also has a list of remote interfaces that can use this https://weechat.org/about/interfaces/ OTOH if you prefer the setup you've got I've had 0 issues with the Python plugins I've written for weechat. A Quassel/weechat proxy plugin should be pretty straight forward and if you prefer a standalone bridge, as others have suggested Python is great for that too! -- https://mail.python.org/mailman/listinfo/python-list
Re: Best (simplest) way to share data (Posting On Python-List Prohibited)
Lawrence D'Oliveiro wrote: > On Sat, 6 Jul 2024 08:28:41 +0100, Chris Green wrote: > > > One fairly obvious way is to have single process/script which reads the > > A2D values continuously and writes them to a file. All other scripts > > then read from the file as needed, a simple file lock can then be used > > to prevent simultaneous access (well, simultaneous access when the > > writing process is writing). > > The thing with a file is, it persists even when the collector process is > not running. Do you want data that persists when the collector process is > not running? > > Is this a history of values, or just a snapshot of current values? A > history of values could be written to a database. Databases provide their > own transactions and interlocking to prevent readers from reading partial > updates. > There's a separate (crontab driven) process that writes the history to a sqlite3 database, > If it’s a snapshot of current values, that does not persist when the > collector process is not running, then why not just keep the data in the > memory of the collector process, and have it concurrently listen on a > socket for connections from readers requesting a copy of the current data? That's exactly the sort of solution I was wondering about. Is there a ready made module/library for handling this sort of thing? Basically it will just be a string of a few tens of characters that would be kept up to date by one process and asked for by all the others. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: python for irc client
inhahe writes: > On Thu, Jul 4, 2024 at 5:14 AM Daniel via Python-list < > python-list@python.org> wrote: > >> Hi guys - >> >> I have historical experience developing sofwtare for my own use. It has >> been >> quite a while since doing so and the advent of new languages has brought me >> here. Python has built quite a reputation. It would be fun to pick up a >> new language while I'm at it. >> >> I've been a consumer of IRC since the nineties and have been running an >> instance of quassel core on an old laptop for the last decade. Over the >> years, my use of xwindows has dramatically decreased and I spend 90% of my >> computer time with multiple panes of tmux while I do my usual daily fun. >> One >> thing missing is a good textmode irc client that will connect to quassel >> core. >> >> I've seen efforts to make a plugin for weechat but, to date, I don't see >> much >> progress on that end. >> >> In your wisdom, would python be a good environment to accomplish this? I'd >> likely use extended ascii and colors. The point would be to minimize the >> memory footprint of the application. >> >> I don't use standard desktop computers anymore - I'm writing this on my >> beloved pi400 using emacs. >> >> Thanks >> >> Daniel >> -- >> https://mail.python.org/mailman/listinfo/python-list > > > I think Python would be a great language to write an IRC client in, it's a > rapid-development language, and also Python is particularly good for text > manipulation and the IRC protocol is textual rather than binary. But, if > your only purpose for using Python is to reduce the memory footprint, I'm > not sure. I don't know specifically, but I'd guess Python has a higher > memory footprint than, say, C, because it's a high-level language. For > example, each variable has to be boxed, and also the interpreter has to be > loaded.. > > Regarding high ASCII, I don't know if that works in IRC, but either way, > ASCII isn't really enough nowadays. You need to support Unicode; > specifically, UTF-8. Okay great. Since my original post, I settled on UTF8. I have to create a list of requirements for v1.0 to limit scope creep and I can actually get this done. I may put it on github and solicit for assistance at some point. Thanks for the response, both of them. I'll look at the other code and see how I can fold it in. What I have to find out, still, is how the core server manages the messages. I suspect the core does all the sending and receiving and the client just sends the packets to core for management. That's just a guess though. I still have to review the liraries, this is a new idea hatched last night so I have yet to investigate much. My initial thought was C++ but this would be my first termianl-only application in many years so I thought a different coding platform would be effective. Daniel -- https://mail.python.org/mailman/listinfo/python-list
Re: python for irc client
Hi. Just FYI, I use Erc (in Emacs). I'm not a very advanced user, perhaps, but I never felt like I miss anything. That's not to stop you from making your own, but if you just need a decent text client for IRC, then there's already at least one. On Thu, Jul 4, 2024 at 11:30 AM inhahe via Python-list wrote: > > On Thu, Jul 4, 2024 at 5:22 AM inhahe wrote: > > > > > > > On Thu, Jul 4, 2024 at 5:14 AM Daniel via Python-list < > > python-list@python.org> wrote: > > > >> > >> In your wisdom, would python be a good environment to accomplish this? > > > > > > > I think Python would be a great language to write an IRC client in, it's a > > rapid-development language, and also Python is particularly good for text > > manipulation and the IRC protocol is textual rather than binary. > > > > Oh yeah, I forgot I was going to mention that Twisted has already done a > lot of the dirty work for you if you make it in Python...they have twisted. > words.protocols.irc, which implements the IRC protocol. (I don't know if > it's up to date and supports ircv3, though.) > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: python for irc client
On Thu, Jul 4, 2024 at 5:22 AM inhahe wrote: > > > On Thu, Jul 4, 2024 at 5:14 AM Daniel via Python-list < > python-list@python.org> wrote: > >> >> In your wisdom, would python be a good environment to accomplish this? > > > I think Python would be a great language to write an IRC client in, it's a > rapid-development language, and also Python is particularly good for text > manipulation and the IRC protocol is textual rather than binary. > Oh yeah, I forgot I was going to mention that Twisted has already done a lot of the dirty work for you if you make it in Python...they have twisted. words.protocols.irc, which implements the IRC protocol. (I don't know if it's up to date and supports ircv3, though.) -- https://mail.python.org/mailman/listinfo/python-list
Re: python for irc client
On Thu, Jul 4, 2024 at 5:14 AM Daniel via Python-list < python-list@python.org> wrote: > Hi guys - > > I have historical experience developing sofwtare for my own use. It has > been > quite a while since doing so and the advent of new languages has brought me > here. Python has built quite a reputation. It would be fun to pick up a > new language while I'm at it. > > I've been a consumer of IRC since the nineties and have been running an > instance of quassel core on an old laptop for the last decade. Over the > years, my use of xwindows has dramatically decreased and I spend 90% of my > computer time with multiple panes of tmux while I do my usual daily fun. > One > thing missing is a good textmode irc client that will connect to quassel > core. > > I've seen efforts to make a plugin for weechat but, to date, I don't see > much > progress on that end. > > In your wisdom, would python be a good environment to accomplish this? I'd > likely use extended ascii and colors. The point would be to minimize the > memory footprint of the application. > > I don't use standard desktop computers anymore - I'm writing this on my > beloved pi400 using emacs. > > Thanks > > Daniel > -- > https://mail.python.org/mailman/listinfo/python-list I think Python would be a great language to write an IRC client in, it's a rapid-development language, and also Python is particularly good for text manipulation and the IRC protocol is textual rather than binary. But, if your only purpose for using Python is to reduce the memory footprint, I'm not sure. I don't know specifically, but I'd guess Python has a higher memory footprint than, say, C, because it's a high-level language. For example, each variable has to be boxed, and also the interpreter has to be loaded.. Regarding high ASCII, I don't know if that works in IRC, but either way, ASCII isn't really enough nowadays. You need to support Unicode; specifically, UTF-8. -- https://mail.python.org/mailman/listinfo/python-list
python for irc client
Hi guys - I have historical experience developing sofwtare for my own use. It has been quite a while since doing so and the advent of new languages has brought me here. Python has built quite a reputation. It would be fun to pick up a new language while I'm at it. I've been a consumer of IRC since the nineties and have been running an instance of quassel core on an old laptop for the last decade. Over the years, my use of xwindows has dramatically decreased and I spend 90% of my computer time with multiple panes of tmux while I do my usual daily fun. One thing missing is a good textmode irc client that will connect to quassel core. I've seen efforts to make a plugin for weechat but, to date, I don't see much progress on that end. In your wisdom, would python be a good environment to accomplish this? I'd likely use extended ascii and colors. The point would be to minimize the memory footprint of the application. I don't use standard desktop computers anymore - I'm writing this on my beloved pi400 using emacs. Thanks Daniel -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix PyRun - One file Python Runtime 2.5.0
*ANNOUNCING* eGenix PyRun - One file Python Runtime Version 2.5.0 Python runtime taking up just 4-6MB on disk This announcement is also available on our web-site for online reading: https://www.egenix.com/company/news/eGenix-PyRun-2.5.0-GA.html *INTRODUCTION* *eGenix PyRun*™ <https://www.egenix.com/company/legal/trademarks.html> is our open source, one file, no installation version of Python, making the distribution of a Python interpreter to run Python based scripts and applications to Unix based systems simple and efficient. eGenix PyRun's executable only needs 4-6MB on disk, but still supports most Python applications and scripts. Compared to a regular Python installation of typically 100MB on disk, eGenix PyRun is ideal for applications and scripts that need to be distributed to containers, VMs, clusters, client installations, customers or end-users. It makes "installing" Python on a Unix based system as simple as copying a single file. eGenix has been using eGenix PyRun as run-time for the Linux version of mxODBC Connect Server <https://www.egenix.com/products/python/mxODBCConnect/> product since 2008 with great success and decided to make it available as a stand-alone open-source product. We provide the source archive to build your own *eGenix PyRun on Github* <https://github.com/eGenix/egenix-pyrun>, as well as a few binary distributions to get you started on Linux x86_64. In the future, we will set up automated builds for several other platforms. Please see the product page for more details: >>> eGenix PyRun - One file Python Runtime <https://www.egenix.com/products/python/PyRun/> *NEWS* This major release of eGenix PyRun <https://www.egenix.com/products/python/PyRun> comes with the following enhancements: * Added support for *Python 3.8 - 3.11* * Removed support for Python 3.5-3.7 * Modernized the directory setup and build * Changed the license to the *Apache2 license* * Extracted the code from our internal mono-repo to put on Github * *Relaunched the project on Github* For a complete list of changes, please see the *eGenix PyRun Changelog <https://www.egenix.com/products/python/PyRun/changelog.html>*. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jul 01 2024) Python Projects, Coaching and Support ...https://www.egenix.com/ Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.13.0 beta 3 released.
The *next to last* Python 3.13 beta version, beta 3, is now released: https://www.python.org/downloads/release/python-3130b3/ *This is a beta preview of Python 3.13* Python 3.13 is still in development. This release, 3.13.0b3, is the third of four beta release previews of 3.13. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We *strongly encourage* maintainers of third-party Python projects to *test with 3.13* during the beta phase and report issues found to the Python bug tracker <https://github.com/python/cpython/issues> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be *extremely important* to get as much exposure for 3.13 as possible during the beta phase. Please keep in mind that this is a preview release and its use is *not* recommended for production environments. <https://discuss.python.org/t/python-3-13-0-beta-3-now-available/56847#major-new-features-of-the-313-series-compared-to-312-1>Major new features of the 3.13 series, compared to 3.12 Some of the new major new features and changes in Python 3.13 are: <https://discuss.python.org/t/python-3-13-0-beta-3-now-available/56847#new-features-2>New features - A new and improved interactive interpreter <https://docs.python.org/3.13/whatsnew/3.13.html#a-better-interactive-interpreter>, based on PyPy <https://pypy.org>’s, featuring multi-line editing and color support, as well as colorized exception tracebacks <https://docs.python.org/3.13/whatsnew/3.13.html#improved-error-messages> . - An *experimental* free-threaded build mode <https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>, which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well. - A preliminary, *experimental* JIT <https://docs.python.org/3.13/whatsnew/3.13.html#experimental-jit-compiler>, providing the ground work for significant performance improvements. - The (cyclic) garbage collector is now incremental <https://docs.python.org/3.13/whatsnew/3.13.html#incremental-garbage-collection>, which should mean shorter pauses for collection in programs with a lot of objects. - A modified version of mimalloc <https://github.com/microsoft/mimalloc> is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode. - Docstrings now have their leading indentation stripped <https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes>, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.) - The dbm module <https://docs.python.org/3.13/library/dbm.html> has a new dbm.sqlite3 backend <https://docs.python.org/3.13/whatsnew/3.13.html#dbm> that is used by default when creating new files. - The minimum supported macOS version was changed from 10.9 to *10.13 (High Sierra)*. Older macOS versions will not be supported going forward. <https://discuss.python.org/t/python-3-13-0-beta-3-now-available/56847#typing-3> Typing - Support for type defaults in type parameters <https://peps.python.org/pep-0696/>. - A new type narrowing annotation <https://peps.python.org/pep-0742/>, typing.TypeIs. - A new annotation for read-only items in TypeDicts <https://peps.python.org/pep-0705/>. <https://discuss.python.org/t/python-3-13-0-beta-3-now-available/56847#removals-and-new-deprecations-4>Removals and new deprecations - PEP 594 (Removing dead batteries from the standard library) <https://peps.python.org/pep-0594/> scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3. - Many other removals <https://docs.python.org/3.13/whatsnew/3.13.html#removed> of deprecated classes, functions and methods in various standard library modules. - C API removals <https://docs.python.org/3.13/whatsnew/3.13.html#id10> and deprecations <https://docs.python.org/3.13/whatsnew/3.13.html#id9>. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.) - New deprecations <https://docs.python.org/3.13/whatsnew/3
Re: [Tutor] How to install tensorflow on Python 2.7 in Windows?
On 6/26/24 09:29, marc nicole wrote: Browsing the available version of tensorflow for the dates before January 2021 (date when Python 2.7 stopped being supported) I can't find a tensorflow version for Python 2.7 that works under Windows. The reference site I use is https://pypi.org/project/tensorflow/ Anybody can point out a compatible .whl file with Python 2.7 and Windows? The last version of tensorflow to support Python 2.7 was indeed 2.1, and I don't think there was *ever* an official Windows wheel for Python 2, but I'm not that expert to be completely sure. tensorflow support on Windows has never been good, and in a way they've given up, at least part of the fight: they no longer produce official releases for Windows with GPU support (although you may be able to get one from the vendor that produces the GPU hardware like Nvidia or Intel, or from a third party like Amazon Web Services). The official recommendation for WIndows used to be "build your own" (which nearly always failed), then for a few years they tried making Windows builds, now the new "best practice" recommendation is to install on WSL if you want to run on a Windows box (this *might* work for you, unless you're also on an ancient Windows that won't run WSL). Or, try seeing if you can find a docker setup (which, again, will give you a Linux environment running tensorflow). Note that like your other problem, getting numpy going, this is going to be an uphill battle trying to cobble things together to run on 2.7. This is really the problem when something like Python goes out of date / out of support: it's not that it magically stops working, it's that vast amounts of the ecosystem around it stop providing support for *their* bits on the old version, and the combinations become progressively harder to make work. -- https://mail.python.org/mailman/listinfo/python-list
How to install tensorflow on Python 2.7 in Windows?
Browsing the available version of tensorflow for the dates before January 2021 (date when Python 2.7 stopped being supported) I can't find a tensorflow version for Python 2.7 that works under Windows. The reference site I use is https://pypi.org/project/tensorflow/ Anybody can point out a compatible .whl file with Python 2.7 and Windows? -- https://mail.python.org/mailman/listinfo/python-list
RE: [Tutor] How to go about a simple object grabbing in python (given coordinates of arms and objects)
Marc, Several people have supplied feedback on whether your request is a good fit for here. Ultimately it is up to the owner/moderator. In particular, your request to the Tutor List may not fit the purpose and be a bit complex and to the main Python List also outside some common usage whether it is about a specific module or product you are using, or asking about algorithms in a very general way. You question has evolved to being about algorithms, more than about Python as a basic language or even commonly used modules. So, I suggest you simplify your model and then maybe bring it in-line with the module(s) you showed us you were using. Some of what you ask sounds like it would be extremely commonly done in things like robotics, or even just machines with moving parts. Consider the somewhat related concept often seen of how you get from one place to another in parts of Manhattan where most of the streets run either in one direction or the orthogonal direction. How do you get from say East 14th Street at 1st Avenue to West 28th Street and 11th Avenue? This is a slight imitation of how to move a robotic arm that can mainly either go one way or another but not both at once. And, in the real world, parts of Manhattan are more complex with streets ending or renaming or running more diagonally or huge voids like Central Park. The number of solutions is huge for walking, and smaller for driving as some streets are one way. But assuming you avoid wasteful paths (except when roads are closed for endless purposes) and you do not take a path through Brooklyn, Queens and The Bronx and back to Manhattan as in the NY Marathon that also touches another borough, the solutions mainly look like this: Go as far horizontally as you need and then as far vertically. Or, do vertical, then horizontal. Or lots of combined versions such as climbing stairs by doing a block or three one way then some in the other and repeat. The above is referred to as Manhattan Distance, as compared to other measures like Euclidean distance. So back to your robot arm, you can see a set of simple solutions where you make a sort of triangle with the direct Euclidean arm being a hypoteneuse and the X and Y movements are the other two sides. You can then break up your problem as heading one way and pausing and turning the other way and stopping just short of the object you want. If there are no obstacles, you can do that in either order. Or, you could alternate in smaller amounts and get to the same destination. Grabbing it would be something else I will not address except to say that depending on what is grabbing and how it is shaped, you may need to aim not for the object, but the appropriate distance and direction so that when you stop moving, the "grasper" can close on it, again, avoiding existing obstacles. And note, speed is a consideration as many things need to be approached slowly and gently. Next, consider what it would mean if you could have a combined motion based on both operations allowed at the same time. Consider a robot that is on wheels that can move horizontally while also having a "lift" component that lifts the part with the graspers vertically. Both could be programmed to run in tandem at appropriate speeds so the graspers are traveling along the hypotenuse I mention and are going the shortest path. This might be faster and more economical in other ways but can be more complex. And, it may be the robot does not have power or computing ability to do both at the same time. Your design is beyond vague. Both of the approaches above make a plan and carry it out. But in the real world, many algorithms must adjust and work somewhat probabilistically. One algorithm for say catching a moving object, especially one that can change speed and direction a bit, like a running dog or a kite flying in the wind, is to locate where the object seems to be now, perhaps just a direction and a guess at distance, and maybe with some observation make a guess at where it might be at some time in the future that is approximately when you might move the robot near there. Then, use a technique like above (or completely different) that perhaps aims to get you something like halfway there. Monitor along the way to update your position and the newest destination position (if it is moving) and re-evaluate and adjust for the next round and maybe evaluate again as you approach halfway or so, again. Eventually, if you are close, slow down and gradually try to come to a stop where you can grab. If the object reacts to your attempting to go after it, it can be complex. And, you may overshoot and sort of circle back. Now, expand the problem more if needed. What does the robot look like. How many places can it bend? For example, can it have something like two or more elbows, perhaps one allowing twisting of up to 30 degrees and one moving forward and backward and another al
Tkinter and astral characters (was: Decoding bytes to text strings in Python 2)
On 2024-06-24 01:14:22 +0100, MRAB via Python-list wrote:
> Tkinter in recent versions of Python can handle astral characters, at least
> back to Python 3.8, the oldest I have on my Windows PC.
I just tried modifying
https://docs.python.org/3/library/tkinter.html#a-hello-world-program
to display "Hello World \N{ROCKET}" instead (Python 3.10.12 as included
with Ubuntu 22.04). I don't get a warning or error, but the emoji isn't
displayed either.
I suspect that the default font doesn't include emojis and Tk isn't
smart enough to fall back to a different font (unlike xfce4-terminal
which shows the emoji just fine).
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
Re: [Tutor] How to go about a simple object grabbing in python (given coordinates of arms and objects)
What are the parameters to account for in this type of algorithm? are there some checks to perform the arm moves ? for example angle moves or cartesian moves based on some distance thresholds? Any idea about the pseudo-algorithm is welcome. Thanks. Le dim. 23 juin 2024 à 10:33, Alan Gauld via Tutor a écrit : > On 22/06/2024 13:41, marc nicole wrote: > > > So, given the x,y,z coordinates of a target object and the offset x,y,z > of > > arms of a robot, what is a good algorithm to perform to grab the object > > between the hands (either from both sides or from below all using both > > hands). > > > > Specifically, my problem is applied to a NAO robot environment where I > > retrieve a target object coordinates using the following code: > > This is almost entirely outside the Python domain and all within > your 3rd party environment. Do they have a user forum or mailing > list? You will probably get better results asking there? > > Another possibility is that you are using a Python wrapper around > a C (or other language) library and there might be FAQs, fora or > lists supporting that. If so you should be able to translate > their examples to your Python code? > > In terms of generic solutions the only thing I can suggest that > might help is to research collision detection algorithms. > Wikipedia is likely a good starting point. > > -- > 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 > > > > ___ > Tutor maillist - tu...@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
On Mon, 24 Jun 2024 at 10:18, MRAB via Python-list wrote: > Tkinter in recent versions of Python can handle astral characters, at > least back to Python 3.8, the oldest I have on my Windows PC. Good to know, thanks! I was hoping that would be the case, but I don't have a Windows system to check on, so I didn't want to speak without facts. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
On 2024-06-24 00:30, Chris Angelico via Python-list wrote: On Mon, 24 Jun 2024 at 08:20, Rayner Lucas via Python-list wrote: In article , ros...@gmail.com says... > > If you switch to a Linux system, it should work correctly, and you'll > be able to migrate the rest of the way onto Python 3. Once you achieve > that, you'll be able to operate on Windows or Linux equivalently, > since Python 3 solved this problem. At least, I *think* it will; my > current system has a Python 2 installed, but doesn't have tkinter > (because I never bothered to install it), and it's no longer available > from the upstream Debian repos, so I only tested it in the console. > But the decoding certainly worked. Thank you for the idea of trying it on a Linux system. I did so, and my example code generated the error: _tkinter.TclError: character U+1f40d is above the range (U+-U+) allowed by Tcl So it looks like the problem is ultimately due to a limitation of Tcl/Tk. Yep, that seems to be the case. Not sure if that's still true on a more recent Python, but it does look like you won't get astral characters in tkinter on the one you're using. [snip] Tkinter in recent versions of Python can handle astral characters, at least back to Python 3.8, the oldest I have on my Windows PC. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
On Mon, 24 Jun 2024 at 08:20, Rayner Lucas via Python-list wrote: > > In article , > ros...@gmail.com says... > > > > If you switch to a Linux system, it should work correctly, and you'll > > be able to migrate the rest of the way onto Python 3. Once you achieve > > that, you'll be able to operate on Windows or Linux equivalently, > > since Python 3 solved this problem. At least, I *think* it will; my > > current system has a Python 2 installed, but doesn't have tkinter > > (because I never bothered to install it), and it's no longer available > > from the upstream Debian repos, so I only tested it in the console. > > But the decoding certainly worked. > > Thank you for the idea of trying it on a Linux system. I did so, and my > example code generated the error: > > _tkinter.TclError: character U+1f40d is above the range (U+-U+) > allowed by Tcl > > So it looks like the problem is ultimately due to a limitation of > Tcl/Tk. Yep, that seems to be the case. Not sure if that's still true on a more recent Python, but it does look like you won't get astral characters in tkinter on the one you're using. > I'm still not sure why it doesn't give an error on Windows and Because of the aforementioned weirdness of old (that is: pre-3.3) Python versions on Windows. They were built to use a messy, buggy hybrid of UCS-2 and UTF-16. Sometimes this got you around problems, or at least masked them; but it wouldn't be reliable. That's why, in Python 3.3, all that was fixed :) > instead either works (when UTF-8 encoding is specified) or converts the > out-of-range characters to ones it can display (when the encoding isn't > specified). But now I know what the root of the problem is, I can deal > with it appropriately (and my curiosity is at least partly satisfied). Converting out-of-range characters is fairly straightforward, at least as long as your Python interpreter is correctly built (so, Python 3, or a Linux build of Python 2). "".join(c if ord(c) < 65536 else "?" for c in text) > This has given me a much better understanding of what I need to do in > order to migrate to Python 3 and add proper support for non-ASCII > characters, so I'm very grateful for your help! > Excellent. Hopefully all this mess is just a transitional state and you'll get to something that REALLY works, soon! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
In article , r...@zedat.fu- berlin.de says... > > I didn't really do a super thorough deep dive on this, > but I'm just giving the initial impression without > actually being familiar with Tkinter under Python 2, > so I might be wrong! > > The Text widget typically expects text in Tcl encoding, > which is usually UTF-8. > > This is independent of the result returned by sys.get- > defaultencoding()! > > If a UTF-8 string is inserted directly as a bytes object, > its code points will be displayed correctly by the Text > widget as long as they are in the BMP (Basic Multilingual > Plane), as you already found out yourself. Many thanks, you've helped me greatly in understanding what's happening. When I tried running my example code on a different system (Python 2.7.18 on Linux, with Tcl/Tk 8.5), I got the error: _tkinter.TclError: character U+1f40d is above the range (U+-U+) allowed by Tcl So, as your reply suggests, the problem is ultimately a limitation of Tcl/Tk itself. Perhaps I should have spent more time studying the docs for that instead of puzzling over the details of character encodings in Python! I'm not sure why it doesn't give the same error on Windows, but at least now I know where the root of the issue is. I am now much better informed about how to migrate the code I'm working on, so I am very grateful for your help. Thanks, Rayner -- https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
In article , ros...@gmail.com says... > > If you switch to a Linux system, it should work correctly, and you'll > be able to migrate the rest of the way onto Python 3. Once you achieve > that, you'll be able to operate on Windows or Linux equivalently, > since Python 3 solved this problem. At least, I *think* it will; my > current system has a Python 2 installed, but doesn't have tkinter > (because I never bothered to install it), and it's no longer available > from the upstream Debian repos, so I only tested it in the console. > But the decoding certainly worked. Thank you for the idea of trying it on a Linux system. I did so, and my example code generated the error: _tkinter.TclError: character U+1f40d is above the range (U+-U+) allowed by Tcl So it looks like the problem is ultimately due to a limitation of Tcl/Tk. I'm still not sure why it doesn't give an error on Windows and instead either works (when UTF-8 encoding is specified) or converts the out-of-range characters to ones it can display (when the encoding isn't specified). But now I know what the root of the problem is, I can deal with it appropriately (and my curiosity is at least partly satisfied). This has given me a much better understanding of what I need to do in order to migrate to Python 3 and add proper support for non-ASCII characters, so I'm very grateful for your help! Thanks, Rayner -- https://mail.python.org/mailman/listinfo/python-list
How to go about a simple object grabbing in python (given coordinates of arms and objects)
Hello to all of this magnificent community!
I have this problem I had already spent a few days on and still can't
figure out a proper solution.
So, given the x,y,z coordinates of a target object and the offset x,y,z of
arms of a robot, what is a good algorithm to perform to grab the object
between the hands (either from both sides or from below all using both
hands).
Specifically, my problem is applied to a NAO robot environment where I
retrieve a target object coordinates using the following code:
tracker_service= session.service("ALTracker")
xyz_pos = tracker_service.getTargetPosition(motion.FRAME_TORSO)
src:
http://doc.aldebaran.com/2-8/naoqi/motion/control-cartesian.html#motion-cartesian-effectors
Then I get to move the right arm towards nearby the object using the
following code:
effector = "RArm"
frame = motion.FRAME_TORSO
effector_offset =
almath.Transform(self.motion.getTransform(effector, frame, False))
effector_init_3d_position = almath.position3DFromTransform(
effector_offset)
target_3d_position = almath.Position3D(target_position)
move_3d = target_3d_position - effector_init_3d_position
moveTransform = almath.Transform.fromPosition(move_3d.x,
move_3d.y, move_3d.z)
target_transformer_list = list(moveTransform.toVector())
times = [2.0]
axis_mask_list = motion.AXIS_MASK_VEL
self.motion.transformInterpolations(effector, frame,
target_transformer_list, axis_mask_list, times).
src:
http://doc.aldebaran.com/1-14/dev/python/examples/almath/index.html?highlight=offset
This question is specific to NAO environment but in general how to go
about this task? what is a most common algorithm used in this case? Do
I have to also get the side of the object in order to know where
exactly the arms should be placed?
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] How to go about a simple object grabbing in python (given coordinates of arms and objects)
My code is just an attempt at the task, it is not exact as what relates to
the coordinates (e.g., doesn't account for the size of the object. I would
like to have a idea on the general approach to such problems (even a pseudo
code would do)
"Get the hands rapidly enough in the vicinity and then do some fine
coordinated motions to capture the object and then presumably move it."
seems to be a good approach indeed,
The grabbing with both hands code should be more precise.
Thanks for the help anyways!
Le sam. 22 juin 2024 à 23:04, ThreeBlindQuarks
a écrit :
> Marc,
>
> Could you specify what is wrong with what you are doing? you show us code
> that uses an environment you point to that is largely outside of basic
> Python.
>
> There is no one way to get from point A to point B and various constraints
> you have not mentioned can apply. How many joints does the assemblage have
> and what are the limits and costs associated with each. Cam there be
> barriers along a route, including to the side where they may brush part of
> your equipment. Are other things moving (independently even) that may end
> up blocking.
>
> You seem to need both "hands" and presumably at the same time. So
> solutions can take that into account. You need to define what is meant by
> contacting the object to move and you don't want to approach it and hit
> with some speed.
>
> So, the problem may be in parts. Get the hands rapidly enough in the
> vicinity and then do some fine coordinated motions to capture the object
> and then presumably move it.
>
> If you could point to what code is not doing what is expected, someone who
> knows the details or is willing to learn, might help, If you want an
> overall algorithm, there may be some people could share but they may not
> easily translate into the package of sorts you are using.
>
> But the web site you point us to may well already contain examples of
> doing some aspects that you might learn from.
>
> For me, this is too detailed to focus on as I struggle to figure out how
> to move my hands to different parts of my keyboard while looking ...
>
> And that may be one variant of an algorithm where instead of trying to
> move all the way, you move art-way and LOOK where you are, then repeat.
>
>
> Sent with Proton Mail secure email.
>
> On Saturday, June 22nd, 2024 at 8:41 AM, marc nicole
> wrote:
>
> > Hello to all of this magnificent community!
> >
> > I have this problem I had already spent a few days on and still can't
> > figure out a proper solution.
> >
> > So, given the x,y,z coordinates of a target object and the offset x,y,z
> of
> > arms of a robot, what is a good algorithm to perform to grab the object
> > between the hands (either from both sides or from below all using both
> > hands).
> >
> > Specifically, my problem is applied to a NAO robot environment where I
> > retrieve a target object coordinates using the following code:
> >
> > tracker_service= session.service("ALTracker")
> > xyz_pos = tracker_service.getTargetPosition(motion.FRAME_TORSO)
> >
> >
> > src:
> >
> http://doc.aldebaran.com/2-8/naoqi/motion/control-cartesian.html#motion-cartesian-effectors
> >
> >
> > Then I get to move the right arm towards nearby the object using the
> > following code:
> >
> > effector = "RArm"
> >
> > frame = motion.FRAME_TORSO
> > effector_offset =
> > almath.Transform(self.motion.getTransform(effector, frame, False))
> > effector_init_3d_position = almath.position3DFromTransform(
> > effector_offset)
> >
> > target_3d_position = almath.Position3D(target_position)
> > move_3d = target_3d_position - effector_init_3d_position
> > moveTransform = almath.Transform.fromPosition(move_3d.x,
> > move_3d.y, move_3d.z)
> > target_transformer_list = list(moveTransform.toVector())
> > times = [2.0]
> > axis_mask_list = motion.AXIS_MASK_VEL
> > self.motion.transformInterpolations(effector, frame,
> > target_transformer_list, axis_mask_list, times).
> >
> > src:
> http://doc.aldebaran.com/1-14/dev/python/examples/almath/index.html?highlight=offset
> > This question is specific to NAO environment but in general how to go
> > about this task? what is a most common algorithm used in this case? Do
> > I have to also get the side of the object in order to know where
> > exactly the arms should be placed?
> > ___
> > Tutor maillist - tu...@python.org
> > To unsubscribe or change subscription options:
> > https://mail.python.org/mailman/listinfo/tutor
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Decoding bytes to text strings in Python 2
On Sat, 22 Jun 2024 at 03:28, Rayner Lucas via Python-list wrote: > I'm curious about something I've encountered while updating a very old > Tk app (originally written in Python 1, but I've ported it to Python 2 > as a first step towards getting it running on modern systems). > > I am using Python 2.7.18 on a Windows 10 system. If there's any other > relevant information I should provide please let me know. Unfortunately, you're running into one of the most annoying problems from Python 2 and Windows: "narrow builds". You don't actually have proper Unicode support. You have a broken implementation that works for UCS-2 but doesn't actually support astral characters. If you switch to a Linux system, it should work correctly, and you'll be able to migrate the rest of the way onto Python 3. Once you achieve that, you'll be able to operate on Windows or Linux equivalently, since Python 3 solved this problem. At least, I *think* it will; my current system has a Python 2 installed, but doesn't have tkinter (because I never bothered to install it), and it's no longer available from the upstream Debian repos, so I only tested it in the console. But the decoding certainly worked. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Decoding bytes to text strings in Python 2
I'm curious about something I've encountered while updating a very old Tk app (originally written in Python 1, but I've ported it to Python 2 as a first step towards getting it running on modern systems). The app downloads emails from a POP server and displays them. At the moment, the code is completely unaware of character encodings (which is something I plan to fix), and I have found that I don't understand what Python is doing when no character encoding is specified. To demonstrate, I have written this short example program that displays a variety of UTF-8 characters to check whether they are decoded properly: Example Code import Tkinter as tk window = tk.Tk() mytext = """ \xc3\xa9 LATIN SMALL LETTER E WITH ACUTE \xc5\x99 LATIN SMALL LETTER R WITH CARON \xc4\xb1 LATIN SMALL LETTER DOTLESS I \xef\xac\x84 LATIN SMALL LIGATURE FFL \xe2\x84\x9a DOUBLE-STRUCK CAPITAL Q \xc2\xbd VULGAR FRACTION ONE HALF \xe2\x82\xac EURO SIGN \xc2\xa5 YEN SIGN \xd0\x96 CYRILLIC CAPITAL LETTER ZHE \xea\xb8\x80 HANGUL SYLLABLE GEUL \xe0\xa4\x93 DEVANAGARI LETTER O \xe5\xad\x97 CJK UNIFIED IDEOGRAPH-5B57 \xe2\x99\xa9 QUARTER NOTE \xf0\x9f\x90\x8d SNAKE \xf0\x9f\x92\x96 SPARKLING HEART """ mytext = mytext.decode(encoding="utf-8") greeting = tk.Label(text=mytext) greeting.pack() window.mainloop() End Example Code This works exactly as expected, with all the characters displaying correctly. However, if I comment out the line 'mytext = mytext.decode (encoding="utf-8")', the program still displays *almost* everything correctly. All of the characters appear correctly apart from the two four-byte emoji characters at the end, which instead display as four characters. For example, the "SNAKE" character actually displays as: U+00F0 LATIN SMALL LETTER ETH U+FF9F HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK U+FF90 HALFWIDTH KATAKANA LETTER MI U+FF8D HALFWIDTH KATAKANA LETTER HE What's Python 2 doing here? sys.getdefaultencoding() returns 'ascii', but it's clearly not attempting to display the bytes as ASCII (or cp1252, or ISO-8859-1). How is it deciding on some sort of almost-but- not-quite UTF-8 decoding? I am using Python 2.7.18 on a Windows 10 system. If there's any other relevant information I should provide please let me know. Many thanks, Rayner -- https://mail.python.org/mailman/listinfo/python-list
glibc strverscmp called from python
So there's been discussion in comp.lang.c and comp.unix.shell
about doing a "versionsort(3)" type sort on a list
of parameters. glibc offers strverscmp(3) for this type
of sort, and here I am posting a q python program to expose
that to its sort routine for commentary and future reference.
Caveat: I know just enough python to be dangerous -- wrote
this using ChatGPT. It is a learning experience, comments
very much appreciated.
- -%<- -
#!/usr/bin/python3
import ctypes
from ctypes import c_char_p, c_int
import os
import sys
# Load the C standard library (libc)
libc = ctypes.CDLL("libc.so.6")
# Define the prototype of strverscmp
# int strverscmp (const char *s1, const char *s2)
libc.strverscmp.argtypes = [c_char_p, c_char_p]
libc.strverscmp.restype = c_int
# Define a comparison function for Python sorting
def version_compare(x, y):
return libc.strverscmp(x.encode('utf-8'), y.encode('utf-8'))
# Define a key function for sorting
def version_key(s):
class K:
def __init__(self, s):
self.s = s
def __lt__(self, other):
return version_compare(self.s, other.s) < 0
def __gt__(self, other):
return version_compare(self.s, other.s) > 0
def __eq__(self, other):
return version_compare(self.s, other.s) == 0
def __le__(self, other):
return version_compare(self.s, other.s) <= 0
def __ge__(self, other):
return version_compare(self.s, other.s) >= 0
def __ne__(self, other):
return version_compare(self.s, other.s) != 0
return K(s)
# Function to escape special characters
def shell_escape(s):
return s.replace(" ", "\\ ").replace("\n", "\\n").replace("\t", "\\t")
# Parse command-line arguments
args = sys.argv[1:]
# Sort the list using the version key
sorted_args = sorted(args, key=version_key)
# Print each sorted, escaped value on a new line
for arg in sorted_args:
print(shell_escape(arg))
- -%<- -
--
-v
--
https://mail.python.org/mailman/listinfo/python-list
Re: in Python: (101 102 103 201 202 203 301 302 303 401 402 403 )
On 2024-06-14 06:10:06 -, candycanearter07 via Python-list wrote:
> Phil Carmody wrote at 12:01 this Thursday (GMT):
> > I'd say you can't beat the verbosity, or lack thereof of just plain
> > zsh/bash:
> > $ echo {1,2,3,4}0{1,2,3}
> > 101 102 103 201 202 203 301 302 303 401 402 403
>
>
> I /think/ you can replace it with {1...4} and {1...3}? I know there is
> some syntax for "range of numbers" but I can't remember it exactly.
Only two dots, not three:
% echo {1..4}0{1..3}
101 102 103 201 202 203 301 302 303 401 402 403
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
Re: Suggested python feature: allowing except in context maneger
On 2024-06-13 23:49, Cameron Simpson via Python-list wrote: On 13Jun2024 19:44, dieter.mau...@online.de wrote: Why not use: ``` try: with open()... ... except FileNotFoundError: ... ``` This is exactly what the OP was expressing dissatisfaction with. I'm -1 on the idea myself - not every combination of things needs additional syntactic support, and doing stuff like merging an `except` with a `wtih` is bound to introduce some weird corner case, complicating its semantics. I agree. If python allowed statement lambdas you could write what you want above within the language (albeit a bit clumsily). It's very handy. jan Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggested python feature: allowing except in context maneger
The example exception is not what bothers me. The syntax change is nowhere near as useful as `with` and context managers. They provide an excellent idiom for resource usage and release. Your suggestion complicates the `with` statement and brings only a tiny indentation reduction over the `with`-inside-`try` idiom. It brings no semantic changes or new features. I also don't see the added value. If you desperately want to get rid of an indentation level, you could use an except hook. https://docs.python.org/3/library/sys.html#sys.excepthook -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggested python feature: allowing except in context maneger
On 14Jun2024 09:07, Yair Eshel wrote: Cameron, I'm not really sure I got your point. I've used the "file not found" exception as an example for a behavior typical on context managers. This could be a failure to connect to DB, or threads. It also applies to any kind of possible exception, whether cased by the context manager itself or the lines inside it. Long story short, this syntax change is as useful as context managers are The example exception is not what bothers me. The syntax change is nowhere near as useful as `with` and context managers. They provide an excellent idiom for resource usage and release. Your suggestion complicates the `with` statement and brings only a tiny indentation reduction over the `with`-inside-`try` idiom. It brings no semantic changes or new features. That is why I'm -1: the benefit is triviailly small to my eye. -- https://mail.python.org/mailman/listinfo/python-list
Re: in Python: (101 102 103 201 202 203 301 302 303 401 402 403 )
Phil Carmody wrote at 12:01 this Thursday (GMT):
> Paul Rubin writes:
>> HenHanna writes:
>>> is there another (simple) way to write this?
>>
>> Yes, but please consider doing these easy exercises yourself instead of
>> fobbing them onto other people.
>
> Hen's probably just an experimental GPT. You, with your limited
> resources, can never train it.
>
> I'd say you can't beat the verbosity, or lack thereof of just plain zsh/bash:
> $ echo {1,2,3,4}0{1,2,3}
> 101 102 103 201 202 203 301 302 303 401 402 403
>
> Phil
I /think/ you can replace it with {1...4} and {1...3}? I know there is
some syntax for "range of numbers" but I can't remember it exactly.
--
user is generated from /dev/urandom
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggested python feature: allowing except in context maneger
Cameron, I'm not really sure I got your point. I've used the "file not found" exception as an example for a behavior typical on context managers. This could be a failure to connect to DB, or threads. It also applies to any kind of possible exception, whether cased by the context manager itself or the lines inside it. Long story short, this syntax change is as useful as context managers are On Fri, 14 Jun 2024, 01:49 Cameron Simpson, wrote: > On 13Jun2024 19:44, dieter.mau...@online.de > wrote: > >Why not use: > >``` > >try: > > with open()... > >... > >except FileNotFoundError: > > ... > >``` > > This is exactly what the OP was expressing dissatisfaction with. > > I'm -1 on the idea myself - not every combination of things needs > additional syntactic support, and doing stuff like merging an `except` > with a `wtih` is bound to introduce some weird corner case, complicating > its semantics. > > Cheers, > Cameron Simpson > -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggested python feature: allowing except in context maneger
On 13Jun2024 19:44, dieter.mau...@online.de wrote: Why not use: ``` try: with open()... ... except FileNotFoundError: ... ``` This is exactly what the OP was expressing dissatisfaction with. I'm -1 on the idea myself - not every combination of things needs additional syntactic support, and doing stuff like merging an `except` with a `wtih` is bound to introduce some weird corner case, complicating its semantics. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Suggested python feature: allowing except in context maneger
Yair Eshel wrote at 2024-6-13 13:01 +0300:
> ...
>I would like to suggest an alternative syntax, that will, in a sense, apply
>the best of both worlds:
>
>import logging
>with open('sample_data/README.md') as f:
> print (len(f.read()))
>except FileNotFoundError:
> logging.error("File not")
Are you aware that in the case of a `FileNotFoundError`
no context manager is created (the context manager is the `f`
in your code).
Why not use:
try:
with open()...
...
except FileNotFoundError:
...
I do not think that your use case requires a `with` extension.
--
Dieter
--
https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
Hey, everyone! I believe the original question has been answered, and tempers seem to be flaring in sub-threads, so let's call this thread done and move on to other interesting topics. Thank you for your support! -- ~Ethan~ Moderator -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggested python feature: allowing except in context maneger
> On 13 Jun 2024, at 11:01, Yair Eshel via Python-list > wrote: > > I read this is a good place to give some suggestions for features in > python. Best place these days is to raise an idea on https://discuss.python.org/ Beware that this idea has come up in the past and was rejected. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: in Python: (101 102 103 201 202 203 301 302 303 401 402 403 )
Paul Rubin writes:
> HenHanna writes:
>> is there another (simple) way to write this?
>
> Yes, but please consider doing these easy exercises yourself instead of
> fobbing them onto other people.
Hen's probably just an experimental GPT. You, with your limited
resources, can never train it.
I'd say you can't beat the verbosity, or lack thereof of just plain zsh/bash:
$ echo {1,2,3,4}0{1,2,3}
101 102 103 201 202 203 301 302 303 401 402 403
Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
Chris Angelico wrote: > On Thu, 13 Jun 2024 at 10:58, wrote: > > > > Chris, > > > > You seem to have perceived an insult that I remain unaware of. > > If you're not aware that you're saying this, then don't say it. > Er, um, that really makes no sense! :-) How can one not say something that one isn't aware of saying? -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Suggested python feature: allowing except in context maneger
Hello. I read this is a good place to give some suggestions for features in
python. If not, please let me know.
This is an example of a code I normally use in my everyday work:
import logging
try:
with open('sample_data/READM.md') as f:
print (len(f.read()))
except FileNotFoundError:
logging.error("File not found")
As you can see I have 2 levels of indentation, which can add some pain to
the work with the context manager. This code without context manager, can
be replaced by this code:
import logging
try:
f = open('sample_data/READM.md') as f:
print (len(f.read()))
except FileNotFoundError:
logging.error("File not found")
finally:
f.close()
And while this offers less indentations, it skips the usage of the very
handy context manager.
I would like to suggest an alternative syntax, that will, in a sense, apply
the best of both worlds:
import logging
with open('sample_data/README.md') as f:
print (len(f.read()))
except FileNotFoundError:
logging.error("File not")
As "with" applies the behavior of the "try / finally" it feels like a
natural part of this syntax. This could provide a cleaner code.
If this idea is accepted, there are several things that need to be
discussed, like what to do with "else" or "finally" statement following a
context manager. I'm not sure about the proper way to handle this.
With hopes for an even more readable future
Yair
--
בברכה,
יאיר אשל כהנסקי
מתכנת וטכנאי מילים
https://www.inspect-element.net/YouAreHere/#/start
--
https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 10:58, wrote: > > Chris, > > You seem to have perceived an insult that I remain unaware of. If you're not aware that you're saying this, then don't say it. > I looked up FUD and sharply disagree with suggestions I am trying to somehow > cause Fear, Uncertainty or Doubt. I simply asked if another such update ... > as a hypothetical. Had I asked what impact Quantum Computers might have on > existing languages, would that also be FUD, or just a speculation in a > discussion. What DID you intend by your comments? Were you trying to imply that work spent upgrading to Python 3 would have to be redone any day now when this hypothetical massively-incompatible Python 4 is released? Or what? What WERE you trying to say? If you don't understand how damaging it can be to say that sort of thing, **don't say it**. Otherwise, expect responses like this. I *detest* the attitude that you can make vague disparaging comments and then hide behind claims that you had no idea how damaging you were being. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Couldn't install numpy on Python 2.7
Chris, You seem to have perceived an insult that I remain unaware of. I have no special knowledge, like you do, of plans made for changes to the pthon language and implementation. I was asking a hypothetical question about what some users would do if python came out with a newer major version. I have seen people often wait until some software that tries to get updated too frequently makes multiple updates and then finally give in and skip the intermediates. I wondered if something like a version 4.0 might get people still using version 2 might finally come around and also if some version 3 users would not be thrilled with something not stable enough. I have no favorite ideas here and can see a balance between adding features or fixing flaws and on the other side, not discomfiting many and especially when in many cases, the original people who wrote software are no longer there nor budgets to pay for changes. I looked up FUD and sharply disagree with suggestions I am trying to somehow cause Fear, Uncertainty or Doubt. I simply asked if another such update ... as a hypothetical. Had I asked what impact Quantum Computers might have on existing languages, would that also be FUD, or just a speculation in a discussion. Either way, I am taking any further discussion along these lines offline and will not continue here. -Original Message- From: Python-list On Behalf Of Chris Angelico via Python-list Sent: Wednesday, June 12, 2024 7:23 PM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On Thu, 13 Jun 2024 at 09:20, wrote: > My point was that version 4 COULD HAPPEN one day and I meant INCOMPATIBLE > version not 4. Obviously we can make a version 4 that is not incompatible > too. This is still FUD. Back your words with something, or stop trying to imply that there's another incompatible change just around the corner. Do you realise how insulting you are being to the developers of Python by these implications? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 09:20, wrote: > My point was that version 4 COULD HAPPEN one day and I meant INCOMPATIBLE > version not 4. Obviously we can make a version 4 that is not incompatible > too. This is still FUD. Back your words with something, or stop trying to imply that there's another incompatible change just around the corner. Do you realise how insulting you are being to the developers of Python by these implications? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Couldn't install numpy on Python 2.7
Chris, I don't want to get off message and debate whether my "jokes" are jokes, let alone funny. Obviously, they often aren't. What I meant by joking here does seem relevant. As the years pass, there can come a time when it is suggested that a language (any language including python) is no longer useful to many in the community as it has not kept up with changes in the industry or whatever. Suggestions are made for changes and additions that that not be backward compatible. They can be somewhat minor things like new keywords that have not been reserved and where programs that exist might be scanned for use of that keyword, and you simply replace those names with was_keyword or something and the programs will generally run. But there can be major changes too and there can be a choice to just create a new language that has some similarities to python 3 (or PERL version whatever) or just name it the same but a version higher much like has happened. My point was that version 4 COULD HAPPEN one day and I meant INCOMPATIBLE version not 4. Obviously we can make a version 4 that is not incompatible too. I have experience in other languages where disconnects happen at various levels. Some functions in a collection such as a package are removed perhaps to replace them with a more abstract version that does much more. Do you remove the old one immediately or do you make a new name for the new one and perhaps in some way mark the old one for deprecation with a pointer to the new one to be used as soon as reasonable? I have seen many approaches. I have seen entire packages yanked. I have seen parts that used to be in the distribution as if built-in and then taken out and vice versa. The point is you do not need a 4.0 to be incompatible. The incompatibility, or need to change, can happen anytime when you are importing things like numpy which is released whenever they want to and is not part of the python distribution. Also, as we have seen at times, other modules you may have imported, in some languages, can mask names you are using in your program that you may not even be aware are there. Much can go wrong with software and keeping current can also give you problems when something released may have inadvertent changes or bugs. So much of our code is voluntary and as noted earlier, some python variants/distributions simply may not have anyone interested in keeping them up to date. You as a user, take your chances. -Original Message----- From: Python-list On Behalf Of Chris Angelico via Python-list Sent: Wednesday, June 12, 2024 5:52 PM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On Thu, 13 Jun 2024 at 07:36, wrote: > But if the goal was to deprecate python 2 and in some sense phase it out, it > is perhaps not working well for some. Frankly, issuing so many updates like > 2.7 and including backporting of new features has helped make it possible to > delay any upgrade. The goal was to improve Python. I don't think anyone's ever tried to "kill off" Python 2 - not in the sense of stopping people from using it - but there haven't been any changes, not even security fixes, in over four years. > And, yes, I was KIDDING about python 4. I am simply suggesting that there > may well be a time that another shift happens that may require another > effort to get people on board a new and perhaps incompatible setup. Kidding, eh? It sure sounded like you were trying to imply that there would inevitably be another major breaking change. It definitely smelled like FUD. Maybe your jokes just aren't funny. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Wed, 12 Jun 2024 at 23:52, Greg Ewing via Python-list wrote: > On 13/06/24 10:09 am, Chris Angelico wrote: > > So if anyone > > actually does need to use pip with Python 2.7, they probably need to > > set up a local server > > You should also be able to download a .tar.gz from PyPI and use pip > to install that. Although you'll have to track down the dependencies > yourself in that case. It is almost certainly better to download the wheel (.whl) file rather than the sdist (.tar.gz) file. Building NumPy from source needs not just compilers etc but also you first need to build/install a BLAS library. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 08:46, Oscar Benjamin via Python-list wrote: > I don't know much about SSL and related networking things especially > on Windows. I would be surprised if pip on old Python can't install > from current PyPI though. I imagine that something strange has > happened like a new version of pip running on an old version of Python > or old Python on new OS (or old PyCharm...). > > There is no problem using Python 2.7 with pip and PyPI on this Linux > machine but I guess it has a newer SSL library provided by the OS: Sadly, I would NOT be surprised if this is indeed a problem on Windows. You're exactly right - on Linux, it can use a newer SSL library from the OS. Of course, this does assume that you've updated your OS, which is far from a guarantee, but since this has security implications there's a good chance you can update it while retaining a legacy system. On Thu, 13 Jun 2024 at 08:51, Greg Ewing via Python-list wrote: > On 13/06/24 10:09 am, Chris Angelico wrote: > > So if anyone > > actually does need to use pip with Python 2.7, they probably need to > > set up a local server > > You should also be able to download a .tar.gz from PyPI and use pip > to install that. Although you'll have to track down the dependencies > yourself in that case. Also a possibility; in my opinion, losing dependency management is too big a cost, so I would be inclined to set up a local server. But then, I would be using a newer SSL library and not have the problem in the first place. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On 13/06/24 4:31 am, avi.e.gr...@gmail.com wrote: It seems Microsoft is having a problem where something lik 2/3 of Windows users have not upgraded from Windows 10 after many years At least Python 3 is a clear improvement over Python 2 in many ways. Whereas the only thing Microsoft seems to have done with Windows in recent times is change it in ways that nobody wants, so there is understandable resistance to upgrading even if it's possible. On 13/06/24 10:09 am, Chris Angelico wrote: > So if anyone > actually does need to use pip with Python 2.7, they probably need to > set up a local server You should also be able to download a .tar.gz from PyPI and use pip to install that. Although you'll have to track down the dependencies yourself in that case. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Wed, 12 Jun 2024 at 23:11, Chris Angelico via Python-list wrote: > > On Thu, 13 Jun 2024 at 07:57, Oscar Benjamin via Python-list > wrote: > > They are seeing a warning that explicitly says "You can upgrade to a > > newer version of Python to solve this". I don't know whether that SSL > > warning is directly connected to pip not finding any versions of numpy > > but with the available information so far that seems like the first > > thing to consider. > > I think it is; AIUI, with an ancient SSL library, pip is unable to > download packages safely from the current pypi server. So if anyone > actually does need to use pip with Python 2.7, they probably need to > set up a local server, using older encryption protocols (which should > therefore NOT be made accessible to the internet). Since pip can't > contact the upstream pypi, there's no available numpy for it to > install. I don't know much about SSL and related networking things especially on Windows. I would be surprised if pip on old Python can't install from current PyPI though. I imagine that something strange has happened like a new version of pip running on an old version of Python or old Python on new OS (or old PyCharm...). There is no problem using Python 2.7 with pip and PyPI on this Linux machine but I guess it has a newer SSL library provided by the OS: $ pip install numpy DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality. Collecting numpy Downloading numpy-1.16.6-cp27-cp27mu-manylinux1_x86_64.whl (17.0 MB) || 17.0 MB 14.3 MB/s Installing collected packages: numpy Successfully installed numpy-1.16.6 If it is actually the case that pip on Python 2.7 (on Windows) cannot download from PyPI then an easier option rather than creating a local server would just be to download the numpy wheels from PyPI using a browser: https://pypi.org/project/numpy/1.15.4/#files Then you can do pip install .\numpy-1.15.4-cp27-none-win_amd64.whl Using a newer version of Python is still my primary suggestion though. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 07:57, Oscar Benjamin via Python-list wrote: > They are seeing a warning that explicitly says "You can upgrade to a > newer version of Python to solve this". I don't know whether that SSL > warning is directly connected to pip not finding any versions of numpy > but with the available information so far that seems like the first > thing to consider. I think it is; AIUI, with an ancient SSL library, pip is unable to download packages safely from the current pypi server. So if anyone actually does need to use pip with Python 2.7, they probably need to set up a local server, using older encryption protocols (which should therefore NOT be made accessible to the internet). Since pip can't contact the upstream pypi, there's no available numpy for it to install. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Wed, 12 Jun 2024 at 22:38, AVI GROSS via Python-list wrote: > > The discussion though was about a specific OP asking if they can fix their > problem. One solution being suggested is to fix a deeper problem and simply > make their code work with a recent version of python 3. The OP has not replied with any explanation as to why they are using Python 2.7 and has not said whether they have any existing code that only works with Python 2.7. It is unclear at this point whether there is any reason that they shouldn't just install a newer version of Python. They are seeing a warning that explicitly says "You can upgrade to a newer version of Python to solve this". I don't know whether that SSL warning is directly connected to pip not finding any versions of numpy but with the available information so far that seems like the first thing to consider. It is entirely reasonable to start by suggesting to use a newer version of Python until some reason is given for not doing that. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 07:36, wrote: > But if the goal was to deprecate python 2 and in some sense phase it out, it > is perhaps not working well for some. Frankly, issuing so many updates like > 2.7 and including backporting of new features has helped make it possible to > delay any upgrade. The goal was to improve Python. I don't think anyone's ever tried to "kill off" Python 2 - not in the sense of stopping people from using it - but there haven't been any changes, not even security fixes, in over four years. > And, yes, I was KIDDING about python 4. I am simply suggesting that there > may well be a time that another shift happens that may require another > effort to get people on board a new and perhaps incompatible setup. Kidding, eh? It sure sounded like you were trying to imply that there would inevitably be another major breaking change. It definitely smelled like FUD. Maybe your jokes just aren't funny. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Couldn't install numpy on Python 2.7
Chris, Since you misunderstood, my statement was that making an incompatible set of changes to create Python 3 in the first place was a decision made by some and perhaps not one that thrilled others who already had an embedded base of programs or ones in the pipeline that would need much work to become comparable. And, of course, users of a program who continued to use python 2, also have to find a way to ... But if the goal was to deprecate python 2 and in some sense phase it out, it is perhaps not working well for some. Frankly, issuing so many updates like 2.7 and including backporting of new features has helped make it possible to delay any upgrade. And, yes, I was KIDDING about python 4. I am simply suggesting that there may well be a time that another shift happens that may require another effort to get people on board a new and perhaps incompatible setup. I have seen things like that happen in multiple phases including phases where the new tools are not an upgrade, but brand new. An example might be if accompany decided to switch to another existing language because they want better error detection and faster execution or new features that may take forever to arrive in what they are using or that supply various services by humans to help them. The discussion though was about a specific OP asking if they can fix their problem. One solution being suggested is to fix a deeper problem and simply make their code work with a recent version of python 3. But another solution could be to step backward to a version of python 2 that still has numpy support, or as was suggested, find out what other modules they are using are interfering with the program being satisfied with the last version of numpy being used and perhaps find a way to get ... In the long run, though, continuing with python 2 will likely cause ever more such headaches if you want the latest and greatest of things like numpy. -Original Message- From: Python-list On Behalf Of Chris Angelico via Python-list Sent: Wednesday, June 12, 2024 2:00 PM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On Thu, 13 Jun 2024 at 03:41, AVI GROSS via Python-list wrote: > > Change is hard even when it may be necessary. > > The argument often is about whether some things are necessary or not. > > Python made a decision but clearly not a unanimous one. What decision? To not release any new versions of Python 2? That isn't actually the OP's problem here - the Python interpreter runs just fine. But there's no numpy build for the OP's hardware and Python 2.7. So if you want to complain about Python 2.7 being dead, all you have to do is go through all of the popular packages and build binaries for all modern computers. If that sounds easy, go ahead and do it; if it sounds hard, realise that open source is not a democracy, and you can't demand that other people do more and more and more unpaid work just because you can't be bothered upgrading your code. > My current PC was not upgradable because of the new hardware requirement > Microsoft decided was needed for Windows 11. Yes, and that's a good reason to switch to Linux for the older computer. > I mention this in the context of examples of why even people who are fairly > knowledgeable do not feel much need to fix what does not feel broken. It doesn't feel broken, right up until it does. The OP has discovered that it *IS* broken. Whining that it doesn't "feel broken" is nonsense when it is, in fact, not working. > When is Python 4 coming? Is this just another content-free whine, or are you actually curious about the planned future of Python? If the latter, there is **PLENTY** of information out there and I don't need to repeat it here. Please don't FUD. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 06:55, Thomas Passin via Python-list wrote: > The project cannot move to a Python-3 compatible version because Jython > 3.xx doesn't exist and may never exist. The saving grace is that my > project doesn't have to use packages like numpy, scipy, and so forth. Exactly. If you don't need to ALSO use something newer, there's nothing stopping you from continuing with the old version. And that's fine! As long as you're okay with not getting updates, you're welcome to do whatever you like - including running Windows 98 on an ancient PC and editing your documents on that. (Yes, I know someone who did that, long after Win 98 was dead to most of us.) > Thunderbird and everything else worked perfectly for me during that > week. True, there were a few Windows-only programs I missed, but I used > other similar programs even if I didn't like them as much. It's true. And there ARE solutions to that, although it's a bit rough trying to run them on low hardware (Wine works nicely for some programs, less so for others; VirtualBox is really not gonna be happy with a small fraction of your limited RAM). But if your needs are simple, even a crazily low-end system is sufficient. > It's amazing > how little resources Linux installs need, even with a GUI. Of course, > 4GB RAM is limiting whether you are on Linux or Windows - you can't > avoid shuffling all those GUI bits around - but with a little care it > worked great. And with the external SSD the laptop was a lot snappier > than it ever was when it was new. One of the big differences with Linux is that you have a choice of desktop environments, from "none" (just boot straight into a terminal) on up. Some of them are a bit of a compromise in terms of how well you can get your work done, but let's say you had an even MORE ancient system with maybe one gig of memory... I'd rather have a super-light desktop environment even if it doesn't have everything I'm normally accustomed to! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On 6/12/2024 1:59 PM, Chris Angelico via Python-list wrote: On Thu, 13 Jun 2024 at 03:41, AVI GROSS via Python-list wrote: Change is hard even when it may be necessary. The argument often is about whether some things are necessary or not. Python made a decision but clearly not a unanimous one. What decision? To not release any new versions of Python 2? That isn't actually the OP's problem here - the Python interpreter runs just fine. But there's no numpy build for the OP's hardware and Python 2.7. So if you want to complain about Python 2.7 being dead, all you have to do is go through all of the popular packages and build binaries for all modern computers. If that sounds easy, go ahead and do it; if it sounds hard, realise that open source is not a democracy, and you can't demand that other people do more and more and more unpaid work just because you can't be bothered upgrading your code. I support a Tomcat project that has some java code and most of the code is for Jython 2.7. Jython 2.7 is approximately on a par with Python 2.7. Any Python-only code from the standard library will probably run, but of course any C extensions cannot. The nice thing about using Jython in a java environment is that it can call any java object, and java code can call Jython objects and their methods. The project cannot move to a Python-3 compatible version because Jython 3.xx doesn't exist and may never exist. The saving grace is that my project doesn't have to use packages like numpy, scipy, and so forth. Also, the project is very mature and almost certainly won't need to create functionality such packages would enable. It would be nice to be able to use some newer parts of the standard library, but there it is. Jython does support "from __future__ import" and I make use of that for the print function and the like. My current PC was not upgradable because of the new hardware requirement Microsoft decided was needed for Windows 11. Yes, and that's a good reason to switch to Linux for the older computer. I have a 2012-vintage laptop that in modern terms has a very small supply of RAM and a very slow hard drive. When my newer Windows 10 computer was going to be out of service for a while, I put a Linux distro on an external SSD and copied things I needed to work on to it, including my Thunderbird email profile directory. Thunderbird and everything else worked perfectly for me during that week. True, there were a few Windows-only programs I missed, but I used other similar programs even if I didn't like them as much. It's amazing how little resources Linux installs need, even with a GUI. Of course, 4GB RAM is limiting whether you are on Linux or Windows - you can't avoid shuffling all those GUI bits around - but with a little care it worked great. And with the external SSD the laptop was a lot snappier than it ever was when it was new. I mention this in the context of examples of why even people who are fairly knowledgeable do not feel much need to fix what does not feel broken. It doesn't feel broken, right up until it does. The OP has discovered that it *IS* broken. Whining that it doesn't "feel broken" is nonsense when it is, in fact, not working. When is Python 4 coming? Is this just another content-free whine, or are you actually curious about the planned future of Python? If the latter, there is **PLENTY** of information out there and I don't need to repeat it here. Please don't FUD. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Thu, 13 Jun 2024 at 03:41, AVI GROSS via Python-list wrote: > > Change is hard even when it may be necessary. > > The argument often is about whether some things are necessary or not. > > Python made a decision but clearly not a unanimous one. What decision? To not release any new versions of Python 2? That isn't actually the OP's problem here - the Python interpreter runs just fine. But there's no numpy build for the OP's hardware and Python 2.7. So if you want to complain about Python 2.7 being dead, all you have to do is go through all of the popular packages and build binaries for all modern computers. If that sounds easy, go ahead and do it; if it sounds hard, realise that open source is not a democracy, and you can't demand that other people do more and more and more unpaid work just because you can't be bothered upgrading your code. > My current PC was not upgradable because of the new hardware requirement > Microsoft decided was needed for Windows 11. Yes, and that's a good reason to switch to Linux for the older computer. > I mention this in the context of examples of why even people who are fairly > knowledgeable do not feel much need to fix what does not feel broken. It doesn't feel broken, right up until it does. The OP has discovered that it *IS* broken. Whining that it doesn't "feel broken" is nonsense when it is, in fact, not working. > When is Python 4 coming? Is this just another content-free whine, or are you actually curious about the planned future of Python? If the latter, there is **PLENTY** of information out there and I don't need to repeat it here. Please don't FUD. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Couldn't install numpy on Python 2.7
Change is hard even when it may be necessary. The argument often is about whether some things are necessary or not. Python made a decision but clearly not a unanimous one. My current PC was not upgradable because of the new hardware requirement Microsoft decided was needed for Windows 11. I bought a new one a while back and turned it on in another room and then set it aside because replacing the current one in the current position will be a pain, especially with getting all my wires and so on, and since I do not want to use a full copy of my data including many obsolete things, that will be another pain to get what I need, if I can remember. Complicating issues also include licenses for things in fixed amounts and the likelihood of messing up the hardware/software I have that records shows from cable to my hard disk, possibly needing to buy a new one. I mention this in the context of examples of why even people who are fairly knowledgeable do not feel much need to fix what does not feel broken. I have wondered if instead of doing what Microsoft wants, if maybe switching to Linux of some kinds makes as much sense. I suspect some may simply upgrade to an Apple product. And think of all the PC's that may effectively be discarded as they may not even be usable if donated. We live in a rapidly developing age and hence one with regularly and irregularly scheduled rounds of obsolescence. When is Python 4 coming? -Original Message- From: Python-list On Behalf Of MRAB via Python-list Sent: Wednesday, June 12, 2024 12:56 PM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On 2024-06-12 17:31, AVI GROSS via Python-list wrote: > I am sure there is inertia to move from an older product and some people > need a reason like this where the old becomes untenable. > > It seems Microsoft is having a problem where something lik 2/3 of Windows > users have not upgraded from Windows 10 after many years and have set a > deadline in a year or so for stopping updates. In that case, hardware was a > concern for some as Windows 11 did not work on their machines. With > upgrading python, the main concern is having to get someone to examine old > code and try to make it compatible. > In the case of Windows, my PC is over 10 years old yet performs perfectly well for my needs. It can't run Windows 11. Therefore, I'm in the process of migrating to Linux, and I still have over a year to achieve that before support ends. > But anyone doing new code in Python 2 in recent years should ... > Indeed... > -----Original Message- > From: Python-list On > Behalf Of Gordinator via Python-list > Sent: Wednesday, June 12, 2024 10:19 AM > To: python-list@python.org > Subject: Re: Couldn't install numpy on Python 2.7 > > On 12/06/2024 12:30, marc nicole wrote: >> I am trying to install numpy library on Python 2.7.15 in PyCharm but the >> error message I get is: >> >> ERROR: Could not find a version that satisfies the requirement numpy (from >>> versions: none) >>> ERROR: No matching distribution found for numpy >>> c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: >>> InsecurePlatformWarning: A true SSLContext object is not available. This >>> prevents urllib3 fro >>> m configuring SSL appropriately and may cause certain SSL connections to >>> fail. You can upgrade to a newer version of Python to solve this. For > more >>> information, see >>> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings >>>InsecurePlatformWarning, >> >> >> Any clues? > > Why are you using Python 2? Come on, it's been 16 years. Ya gotta move > on at some point. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On 2024-06-12 17:31, AVI GROSS via Python-list wrote: I am sure there is inertia to move from an older product and some people need a reason like this where the old becomes untenable. It seems Microsoft is having a problem where something lik 2/3 of Windows users have not upgraded from Windows 10 after many years and have set a deadline in a year or so for stopping updates. In that case, hardware was a concern for some as Windows 11 did not work on their machines. With upgrading python, the main concern is having to get someone to examine old code and try to make it compatible. In the case of Windows, my PC is over 10 years old yet performs perfectly well for my needs. It can't run Windows 11. Therefore, I'm in the process of migrating to Linux, and I still have over a year to achieve that before support ends. But anyone doing new code in Python 2 in recent years should ... Indeed... -Original Message- From: Python-list On Behalf Of Gordinator via Python-list Sent: Wednesday, June 12, 2024 10:19 AM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On 12/06/2024 12:30, marc nicole wrote: I am trying to install numpy library on Python 2.7.15 in PyCharm but the error message I get is: ERROR: Could not find a version that satisfies the requirement numpy (from versions: none) ERROR: No matching distribution found for numpy c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 fro m configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings InsecurePlatformWarning, Any clues? Why are you using Python 2? Come on, it's been 16 years. Ya gotta move on at some point. -- https://mail.python.org/mailman/listinfo/python-list
RE: Couldn't install numpy on Python 2.7
I am sure there is inertia to move from an older product and some people need a reason like this where the old becomes untenable. It seems Microsoft is having a problem where something lik 2/3 of Windows users have not upgraded from Windows 10 after many years and have set a deadline in a year or so for stopping updates. In that case, hardware was a concern for some as Windows 11 did not work on their machines. With upgrading python, the main concern is having to get someone to examine old code and try to make it compatible. But anyone doing new code in Python 2 in recent years should ... -Original Message- From: Python-list On Behalf Of Gordinator via Python-list Sent: Wednesday, June 12, 2024 10:19 AM To: python-list@python.org Subject: Re: Couldn't install numpy on Python 2.7 On 12/06/2024 12:30, marc nicole wrote: > I am trying to install numpy library on Python 2.7.15 in PyCharm but the > error message I get is: > > ERROR: Could not find a version that satisfies the requirement numpy (from >> versions: none) >> ERROR: No matching distribution found for numpy >> c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: >> InsecurePlatformWarning: A true SSLContext object is not available. This >> prevents urllib3 fro >> m configuring SSL appropriately and may cause certain SSL connections to >> fail. You can upgrade to a newer version of Python to solve this. For more >> information, see >> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings >> InsecurePlatformWarning, > > > Any clues? Why are you using Python 2? Come on, it's been 16 years. Ya gotta move on at some point. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On 12/06/2024 12:30, marc nicole wrote: I am trying to install numpy library on Python 2.7.15 in PyCharm but the error message I get is: ERROR: Could not find a version that satisfies the requirement numpy (from versions: none) ERROR: No matching distribution found for numpy c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 fro m configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings InsecurePlatformWarning, Any clues? Why are you using Python 2? Come on, it's been 16 years. Ya gotta move on at some point. -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On Wed, 12 Jun 2024 at 21:32, marc nicole via Python-list wrote: > > I am trying to install numpy library on Python 2.7.15 in PyCharm but the > error message I get is: > > You can upgrade to a newer version of Python to solve this. The answer is right there in the error message. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Couldn't install numpy on Python 2.7
I am trying to install numpy library on Python 2.7.15 in PyCharm but the error message I get is: ERROR: Could not find a version that satisfies the requirement numpy (from > versions: none) > ERROR: No matching distribution found for numpy > c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: > InsecurePlatformWarning: A true SSLContext object is not available. This > prevents urllib3 fro > m configuring SSL appropriately and may cause certain SSL connections to > fail. You can upgrade to a newer version of Python to solve this. For more > information, see > https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings > InsecurePlatformWarning, Any clues? -- https://mail.python.org/mailman/listinfo/python-list
Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
On 6/10/2024 6:29 AM, Rob Cliffe wrote:
import itertools
def chunk1(seq):
return [ ch * len(list(grp)) for (ch, grp) in itertools.groupby(s) ]
def chunk2(seq):
return [ (ch, len(list(grp))) for (ch, grp) in itertools.groupby(s) ]
s='aaabbaa'
print(chunk1(s))
print(chunk2(s))
###
Program output:
['aaa', 'bb', '', 'aa']
[('a', 3), ('b', 2), ('c', 4), ('a', 2)]
Rob Cliffe
thank you... OMG... For 10 minutes... i was SO mystified by
the question...
How can this code work??? , when it's
> def chunk1(seq):
and it's [s] within the def-body ?
it seemed as if the Compiler was doing a DWIM (Do what i mean) trick.
On 09/06/2024 22:20, HenHanna via Python-list wrote:
Chunk, ChunkC -- nice simple way(s) to write these in Python?
(Chunk '(a a b a a a b b))
==> ((a a) (b) (a a a) (b b))
(Chunk '(a a a a b c c a a d e e e e))
==> ((a a a a) (b) (c c) (a a) (d) (e e e e))
(Chunk '(2 2 foo bar bar j j j k baz baz))
==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz))
_
(ChunkC '(a a b b b))
==> ((a 2) (b 3))
(ChunkC '(a a b a a a b b))
==> ((a 2) (b 1) (a 3) (b 2))
--
https://mail.python.org/mailman/listinfo/python-list
RE: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
Rob,
That is a fairly straightforward and elegant solution if using an added mode
called itertools.
I went a different way by creating my own focused iterator and calling it, when
needed, to produce one or the other of the results requested in the functions
named chunk() and chunkc(). But note my version operates to produce lists no
matter what the input was. It produces lists nestled within lists. Presumably
it could be adjusted to check if the input was a tuple and then return a
grouping of tuples within a tuple.
The code, just for fun, is below and probably could be more elegant! LOL!
### CODE START
# Iterator version to be called as needed or all at once as with ChunkC
def ChunkIterator(seq):
# Purpose is to evaluate a list and return a list
# of lists with each one containing the longest run
# of each item.
# Handle an empty list
if len(seq) == 0: return container
# Initialize the first item in a copy.
# The first item is now in a initialized list.
gathered = [last := seq[0]]
# Loop over the remaining items and yield as needed.
for item in seq[1:]:
if len(gathered) == 0: gathered = [item]
elif item == last: gathered.append(item)
else: # not equal means yield result and start anew for next group
yield(gathered)
gathered = [last := item]
# After loop completes, any remaining data is returned as the function
terminates.
if len(gathered) > 0: yield(gathered)
# Accesory function that runs the iterator to completion into a list.
def Chunk(seq): return list(ChunkIterator(seq))
# Function that simplifies the Chunks as an item and a number of instances.
def ChunkC(seq):
return [[group[0], len(group)] for group in ChunkIterator(seq)]
### CODE END
### EXAMPLES
>>> tuple(Chunk([1, 2, 2, 'c', 'c', 'c', 'singleton']))
([1], [2, 2], ['c', 'c', 'c'], ['singleton'])
>>> chunk([1, 2, 2, 'c', 'c', 'c', 'singleton'])
[[1], [2, 2], ['c', 'c', 'c'], ['singleton']]
>>> chunkC([1, 2, 2, 'c', 'c', 'c', 'singleton'])
[[1, 1], [2, 2], ['c', 3], ['singleton', 1]]
# COMMENTS
The current version has flaws I have not bothered correcting. Just for a demo.
-----Original Message-
From: Python-list On
Behalf Of Rob Cliffe via Python-list
Sent: Monday, June 10, 2024 9:29 AM
To: python-list@python.org
Subject: Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
import itertools
def chunk1(seq):
return [ ch * len(list(grp)) for (ch, grp) in itertools.groupby(s) ]
def chunk2(seq):
return [ (ch, len(list(grp))) for (ch, grp) in itertools.groupby(s) ]
s='aaabbaa'
print(chunk1(s))
print(chunk2(s))
###
Program output:
['aaa', 'bb', '', 'aa']
[('a', 3), ('b', 2), ('c', 4), ('a', 2)]
Rob Cliffe
On 09/06/2024 22:20, HenHanna via Python-list wrote:
>
> Chunk, ChunkC -- nice simple way(s) to write these in Python?
>
>
> (Chunk '(a a ba a a b b))
> ==> ((a a) (b) (a a a) (b b))
>
>
> (Chunk '(a a a a b c c a a d e e e e))
> ==> ((a a a a) (b) (c c) (a a) (d) (e e e e))
>
>
> (Chunk '(2 2 foo bar bar j j j k baz baz))
> ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz))
>
> _
>
> (ChunkC '(a a b b b))
> ==> ((a 2) (b 3))
>
> (ChunkC '(a a b a a a b b))
> ==> ((a 2) (b 1) (a 3) (b 2))
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
import itertools
def chunk1(seq):
return [ ch * len(list(grp)) for (ch, grp) in itertools.groupby(s) ]
def chunk2(seq):
return [ (ch, len(list(grp))) for (ch, grp) in itertools.groupby(s) ]
s='aaabbaa'
print(chunk1(s))
print(chunk2(s))
###
Program output:
['aaa', 'bb', '', 'aa']
[('a', 3), ('b', 2), ('c', 4), ('a', 2)]
Rob Cliffe
On 09/06/2024 22:20, HenHanna via Python-list wrote:
Chunk, ChunkC -- nice simple way(s) to write these in Python?
(Chunk '(a a b a a a b b))
==> ((a a) (b) (a a a) (b b))
(Chunk '(a a a a b c c a a d e e e e))
==> ((a a a a) (b) (c c) (a a) (d) (e e e e))
(Chunk '(2 2 foo bar bar j j j k baz baz))
==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz))
_
(ChunkC '(a a b b b))
==> ((a 2) (b 3))
(ChunkC '(a a b a a a b b))
==> ((a 2) (b 1) (a 3) (b 2))
--
https://mail.python.org/mailman/listinfo/python-list
RE: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
> i was just curiuos about simple, clever way to write it in Python It depends on what you mean by "clever". For some, it was like a suggestion on using something already available such as itertools.groupby, perhaps even better if it is actually compiled in from a language like C and perhaps more efficient. For some who like to Scheme, only a recursive solution may be considered clever! For some who have absorbed ideas in languages like python, perhaps they would implement it the way I described as an iterator that is efficient in the sense that it delivers things just in time and quits if not iterated further. An example might be if you asked to get groups of consecutive digits in the calculated indefinite value of a number like pi or e or looked at how many digits in a row were the same for prime numbers but wanted to quit after the first billion. Some may like some kind of functional programming method. Some want short code and some want efficiency and some even like something written in a subtle way so others have trouble understanding it, as in the obfuscated C contests. What you do need to consider is what exactly are your requirements. Your examples are trivial so maybe we need to think about what it means to gather together what is supplied in one container, into a container containing other grouped containers. First, what python containers should be handled? Yes, you probably mean a list but if handed a tuple, should it return the same, or always return a list for the top level and perhaps even deeper levels? There are many containers in python including (ordered) dictionaries where the keys may be unique, but you may want to see if the contents have some order, numpy arrays, and so on. And, are all the contents required to be atomic? What does it mean for items in a row to be equal? If I have a sublist, should I unlist to make it flat first, or should it be an error, or should each such sublist be compared for full equality or even relative equality so that (a (b c) (c b) d) actually accepts (b c) and (c b) as the same for the purpose? For that matter, is 1.0 matched to 1 or even "1" or perhaps an object that has that value in some way such as when comparing arbitrary objects? There can be many such questions and some elegant methods get less elegant if they need to handle too much. You need to explain what to do when a bad unintended case is found, such as perhaps an empty list or ... To just do what your examples ask, again, seems easy enough. It is the usual code if not done too elegantly. Write a function that accepts a list (or tries to coerce what it gets into a copy as a list. It returns an empty list if it has nothing, otherwise pops off the first item and then loops on the rest. When items match the current first item, extend a sublist and when they don't, yield what you have and start a new sublist. After the loop, anything remaining is returned. Simple enough? Note to get your result properly, since it is an iterator, you need to either be calling it iteratively, or do something like: Result = list(chunk(something)) To force it to run to completion. -Original Message- From: Python-list On Behalf Of HenHanna via Python-list Sent: Sunday, June 9, 2024 10:37 PM To: python-list@python.org Subject: Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3)) On 6/9/2024 7:05 PM, avi.e.gr...@gmail.com wrote: > I remembered that HenHanna had been hard to deal with in the past and when > my reply to him/her/them bounced as a bad/fake address it came back to me > that I am better off not participating in this latest attempt to get us to > perform then probably shoot whatever we say down. > > A considerate person would ask questions more clearly and perhaps explain > what language they are showing us code from and so on. > > Life is too short to waste. > > -Original Message----- > From: Python-list On > Behalf Of HenHanna via Python-list > Sent: Sunday, June 9, 2024 5:20 PM > To: python-list@python.org > Subject: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3)) > > Chunk, ChunkC -- nice simple way(s) to write these in Python? > > > (Chunk '(a a ba a a b b)) > ==> ((a a) (b) (a a a) (b b)) > > > (Chunk '(a a a a b c c a a d e e e e)) > ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) > > > (Chunk '(2 2 foo bar bar j j j k baz baz)) > ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) > > _ > > (ChunkC '(a a b b b)) >==> ((a 2) (b 3)) > > (ChunkC '(a a b a a a b b)) >==> ((a 2) (b 1) (a 3) (b 2)) i was just curiuos about simple, clever way to write it in Python in Scheme (Gauche) (use srfi-1) ;; span (define (gp x) (if (null? x) '() (let-values (((F L)
Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
On 6/9/2024 7:05 PM, avi.e.gr...@gmail.com wrote: I remembered that HenHanna had been hard to deal with in the past and when my reply to him/her/them bounced as a bad/fake address it came back to me that I am better off not participating in this latest attempt to get us to perform then probably shoot whatever we say down. A considerate person would ask questions more clearly and perhaps explain what language they are showing us code from and so on. Life is too short to waste. -Original Message- From: Python-list On Behalf Of HenHanna via Python-list Sent: Sunday, June 9, 2024 5:20 PM To: python-list@python.org Subject: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3)) Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a ba a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) i was just curiuos about simple, clever way to write it in Python in Scheme (Gauche) (use srfi-1) ;; span (define (gp x) (if (null? x) '() (let-values (((F L) (span (cut equal? (car x) <>) x))) (cons F (gp L) (print (gp '(ab ba a a b b b b))) (print (gp '(c c c a d d d d a e e e e e))) (define (gpC x) (map (lambda (x) (list (car x) (length x))) (gp x))) (print (gpC '(ab ba a a b b b b))) (print (gpC '(c c c a d d d d a e e e e e))) -- https://mail.python.org/mailman/listinfo/python-list
Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
On 6/9/2024 3:50 PM, MRAB wrote: On 2024-06-09 22:20, HenHanna via Python-list wrote: Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a b a a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) You can make use of itertools.groupby. Thanks! i'll try it. Scheme (Gauche) (use srfi-1) ; span (define (gp x) (if (null? x) '() (let-values (((F L) (span (cut equal? (car x) <>) x))) (cons F (gp L) (print (gp '(ab ba a a b b b b))) (print (gp '(c c c a d d d d a e e e e e))) -- https://mail.python.org/mailman/listinfo/python-list
RE: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
I remembered that HenHanna had been hard to deal with in the past and when my reply to him/her/them bounced as a bad/fake address it came back to me that I am better off not participating in this latest attempt to get us to perform then probably shoot whatever we say down. A considerate person would ask questions more clearly and perhaps explain what language they are showing us code from and so on. Life is too short to waste. -Original Message- From: Python-list On Behalf Of HenHanna via Python-list Sent: Sunday, June 9, 2024 5:20 PM To: python-list@python.org Subject: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3)) Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a ba a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
HH, Before bothering, it might be helpful if you spelled out a bit more in the way of requirements that would satisfy you and perhaps show your attempts. Your examples suggest it would be fairly simple to create an iterator, for example, that would yield as it examined one item at a time until it ran out or the next item was not the same. It could then either return a tuple it had collected so far since the last yield, or for what you call chunkC, return a tuple containing one copy of the item and a count of how many. But if you want something else, such as a list all at once, that too would be trivial, perhaps leveraging the above. -Original Message- From: Python-list On Behalf Of HenHanna via Python-list Sent: Sunday, June 9, 2024 5:20 PM To: python-list@python.org Subject: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3)) Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a ba a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
On 2024-06-09 22:20, HenHanna via Python-list wrote: Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a ba a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) You can make use of itertools.groupby. -- https://mail.python.org/mailman/listinfo/python-list
in Python? -- Chunk -- (ChunkC '(a a b b b)), ==> ((a 2) (b 3))
Chunk, ChunkC -- nice simple way(s) to write these in Python? (Chunk '(a a ba a a b b)) ==> ((a a) (b) (a a a) (b b)) (Chunk '(a a a a b c c a a d e e e e)) ==> ((a a a a) (b) (c c) (a a) (d) (e e e e)) (Chunk '(2 2 foo bar bar j j j k baz baz)) ==> ((2 2) (foo) (bar bar) (j j j) (k) (baz baz)) _ (ChunkC '(a a b b b)) ==> ((a 2) (b 3)) (ChunkC '(a a b a a a b b)) ==> ((a 2) (b 1) (a 3) (b 2)) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.12.4 released
Last minute bugs in test environments notwithstanding, 3.12.4 is now available! https://www.python.org/downloads/release/python-3124/ <https://www.python.org/downloads/release/python-3124/> <https://discuss.python.org/t/python-3-12-4-now-available/55128#this-is-the-third-maintenance-release-of-python-312-1>This is the third maintenance release of Python 3.12 Python 3.12 is the newest major release of the Python programming language, and it contains many new features and optimizations. 3.12.4 is the latest maintenance release, containing more than 250 bugfixes, build improvements and documentation changes since 3.12.3. <https://discuss.python.org/t/python-3-12-4-now-available/55128#major-new-features-of-the-312-series-compared-to-311-2>Major new features of the 3.12 series, compared to 3.11 <https://discuss.python.org/t/python-3-12-4-now-available/55128#new-features-3>New features - More flexible f-string parsing <https://docs.python.org/3.12/whatsnew/3.12.html#pep-701-syntactic-formalization-of-f-strings>, allowing many things previously disallowed (PEP 701 <https://peps.python.org/pep-0701/>). - Support for the buffer protocol <https://docs.python.org/3.12/whatsnew/3.12.html#pep-688-making-the-buffer-protocol-accessible-in-python> in Python code (PEP 688 <https://peps.python.org/pep-0688/>). - A new debugging/profiling API <https://docs.python.org/3.12/whatsnew/3.12.html#pep-669-low-impact-monitoring-for-cpython> (PEP 669 <https://peps.python.org/pep-0669/>). - Support for isolated subinterpreters <https://docs.python.org/3.12/whatsnew/3.12.html#pep-684-a-per-interpreter-gil> with separate Global Interpreter Locks (PEP 684 <https://peps.python.org/pep-0684>). - Even more improved error messages <https://docs.python.org/3.12/whatsnew/3.12.html#improved-error-messages>. More exceptions potentially caused by typos now make suggestions to the user. - Support for the Linux perf profiler <https://docs.python.org/3.12/howto/perf_profiling.html> to report Python function names in traces. - Many large and small performance improvements <https://docs.python.org/3.12/whatsnew/3.12.html#optimizations> (like PEP 709 <https://peps.python.org/pep-0709/> and support for the BOLT binary optimizer), delivering an estimated 5% overall performance improvement. <https://discuss.python.org/t/python-3-12-4-now-available/55128#type-annotations-4>Type annotations - New type annotation syntax <https://docs.python.org/3.12/whatsnew/3.12.html#pep-695-type-parameter-syntax> for generic classes (PEP 695 <https://peps.python.org/pep-0695/>). - New override decorator <https://docs.python.org/3.12/whatsnew/3.12.html#pep-698-override-decorator-for-static-typing> for methods (PEP 698 <https://peps.python.org/pep-0698>). <https://discuss.python.org/t/python-3-12-4-now-available/55128#deprecations-5> Deprecations - The deprecated wstr and wstr_length members of the C implementation of unicode objects were removed, per PEP 623 <https://peps.python.org/pep-0623/>. - In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). - The deprecated smtpd and distutils modules have been removed (see PEP 594 <https://peps.python.org/pep-0594/> and PEP 632 <https://peps.python.org/pep-0632/>. The setuptools package continues to provide the distutils module. - A number of other old, broken and deprecated functions, classes and methods <https://docs.python.org/3.12/whatsnew/3.12.html#removed> have been removed. - Invalid backslash escape sequences in strings now warn with SyntaxWarning instead of DeprecationWarning, making them more visible. (They will become syntax errors in the future.) - The internal representation of integers has changed in preparation for performance enhancements. (This should not affect most users as it is an internal detail, but it may cause problems for Cython-generated code.) For more details on the changes to Python 3.12, see What’s new in Python 3.12 <https://docs.python.org/3.12/whatsnew/3.12.html>. <https://discuss.python.org/t/python-3-12-4-now-available/55128#more-resources-6>More resources - Online Documentation <https://docs.python.org/3.12/>. - PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12 Release Schedule. - Report bugs via GitHub Issues <https://github.com/python/cpython/issues>. - Help fund Python directly <https://www.python.org/psf/donations/python-dev/> or via GitHub Sponsors <https://github.com/sponsors/python>, and support the Python community <https://www.python.org/psf/donations/>. <https://discuss.python.org/t/pytho
[RELEASE] Python 3.13.0 beta 2 released.
After a little bit of a delay (I blame the flat tire on my rental car), 3.13.0b2 is released: https://www.python.org/downloads/release/python-3130b2/ <https://www.python.org/downloads/release/python-3130b2/> <https://discuss.python.org/t/3-13-0b2-now-available/55056#this-is-a-beta-preview-of-python-313-1>This is a beta preview of Python 3.13 Python 3.13 is still in development. This release, 3.13.0b2, is the second of four beta release previews of 3.13. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We *strongly encourage* maintainers of third-party Python projects to *test with 3.13* during the beta phase and report issues found to the Python bug tracker <https://github.com/python/cpython/issues> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be *extremely important* to get as much exposure for 3.13 as possible during the beta phase. *Two particularly noteworthy changes in beta 2 involve the macOS installer we provide:* - The minimum supported macOS version was changed from 10.9 to *10.13 (High Sierra)*. Older macOS versions will not be supported going forward. - The macOS installer package now includes an optional additional build of Python 3.13 with the experimental free-threading feature enabled. The free-threaded version, python3.13t, is separate from and co-exists with the traditional GIL-only installation. The free-threaded build is not installed by default; use the Customize option of the installer as explained in the installer readme. Since this is an experimental feature, there may be late-breaking issues found; see the free-threaded macOS build issue <https://github.com/python/cpython/issues/120098> on GitHub for the most recent status. Please keep in mind that this is a preview release and its use is *not* recommended for production environments. <https://discuss.python.org/t/3-13-0b2-now-available/55056#major-new-features-of-the-313-series-compared-to-312-1>Major new features of the 3.13 series, compared to 3.12 Some of the new major new features and changes in Python 3.13 are: <https://discuss.python.org/t/3-13-0b2-now-available/55056#new-features-2>New features - A new and improved interactive interpreter <https://docs.python.org/3.13/whatsnew/3.13.html#a-better-interactive-interpreter>, based on PyPy <https://pypy.org>’s, featuring multi-line editing and color support, as well as colorized exception tracebacks <https://docs.python.org/3.13/whatsnew/3.13.html#improved-error-messages> . - An *experimental* free-threaded build mode <https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>, which disables the Global Interpreter Lock, allowing threads to run more concurrently. - A preliminary, *experimental* JIT <https://docs.python.org/3.13/whatsnew/3.13.html#experimental-jit-compiler>, providing the ground work for significant performance improvements. - The (cyclic) garbage collector is now incremental <https://docs.python.org/3.13/whatsnew/3.13.html#incremental-garbage-collection>, which should mean shorter pauses for collection in programs with a lot of objects. - A modified version of mimalloc <https://github.com/microsoft/mimalloc> is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode. - Docstrings now have their leading indentation stripped <https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes>, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.) - The dbm module <https://docs.python.org/3.13/library/dbm.html> has a new dbm.sqlite3 backend <https://docs.python.org/3.13/whatsnew/3.13.html#dbm> that is used by default when creating new files. <https://discuss.python.org/t/3-13-0b2-now-available/55056#typing-3>Typing - Support for type defaults in type parameters <https://peps.python.org/pep-0696/>. - A new type narrowing annotation <https://peps.python.org/pep-0742/>, typing.TypeIs. - A new annotation for read-only items in TypeDicts <https://peps.python.org/pep-0705/>. <https://discuss.python.org/t/3-13-0b2-now-available/55056#removals-and-new-deprecations-4>Removals and new deprecations - PEP 594 (Removing dead batteries from the standard library) <https://peps.py
Cannot install python properly - python310.dll not found - no pip
Hi. I'm attempting to install and use stable diffusion. However, while installing python 3.10.6, I'm getting the error that the python 310.dll is not found. I've made sure the PATH option is enabled, but it makes no difference. I've also removed and reinstalled python multiple times. Even though I get that error, the python still installs, but when I open the webui-user.bat file in the stable diffusion folder, it opens up the command center and says that there's no module named pip. Please advise on how to fix this problem. Thank you, Jay Cadet Architectural 3D Artist / Photographer studio JPC [p] 516.567.1996 | [w] studiojpc.com<http://studiojpc.com> | [ig] @studiojpc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lprint = ( Lisp-style printing ( of lists and strings (etc.) ) in Python )
On 2024-05-30 21:47:14 -0700, HenHanna via Python-list wrote:
> [('the', 36225), ('and', 17551), ('of', 16759), ('i', 16696), ('a', 15816),
> ('to', 15722), ('that', 11252), ('in', 10743), ('it', 10687)]
>
> ((the 36225) (and 17551) (of 16759) (i 16696) (a 15816) (to 15722) (that
> 11252) (in 10743) (it 10687))
>
>
> i think the latter is easier-to-read, so i use this code
>(by Peter Norvig)
This doesn't work well if your strings contain spaces:
Lprint(
[
["Just", "three", "words"],
["Just", "three words"],
["Just three", "words"],
["Just three words"],
]
)
prints:
((Just three words) (Just three words) (Just three words) (Just three words))
Output is often a compromise between readability and precision.
> def lispstr(exp):
># "Convert a Python object back into a Lisp-readable string."
> if isinstance(exp, list):
This won't work for your example, since you have a list of tuples, not a
list of lists and a tuple is not an instance of a list.
> return '(' + ' '.join(map(lispstr, exp)) + ')'
> else:
> return str(exp)
>
> def Lprint(x): print(lispstr(x))
I like to use pprint, but it's lacking support for user-defined types. I
should be able to add a method (maybe __pprint__?) to my classes which
handle proper formatting (with line breaks and indentation).
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
Lprint = ( Lisp-style printing ( of lists and strings (etc.) ) in Python )
;;; Pls tell me about little tricks you use in Python or Lisp.
[('the', 36225), ('and', 17551), ('of', 16759), ('i', 16696), ('a',
15816), ('to', 15722), ('that', 11252), ('in', 10743), ('it', 10687)]
((the 36225) (and 17551) (of 16759) (i 16696) (a 15816) (to 15722) (that
11252) (in 10743) (it 10687))
i think the latter is easier-to-read, so i use this code
(by Peter Norvig)
def lispstr(exp):
# "Convert a Python object back into a Lisp-readable string."
if isinstance(exp, list):
return '(' + ' '.join(map(lispstr, exp)) + ')'
else:
return str(exp)
def Lprint(x): print(lispstr(x))
--
https://mail.python.org/mailman/listinfo/python-list
Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)
On 29/05/24 06:49, Gilmeh Serda via Python-list wrote: Solved by using a different method. Hedonist for hire... no job too easy! This combination of sig-file and content seems sadly ironic. How about CONTRIBUTING to the community by explaining 'the solution' to people who may find a similar problem - in the similar manner to the various members who have helped YOU, voluntarily (and despite the paucity of source-information and response)? -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)
On Tue, May 28, 2024 at 9:48 PM Gilmeh Serda via Python-list < python-list@python.org> wrote: > > Solved by using a different method. > > - - - And that was how? TIA -- https://mail.python.org/mailman/listinfo/python-list
Re: Weird Stuff (Markdown, syntax highlighting and Python)
On 5/26/2024 2:28 AM, Gilmeh Serda via Python-list wrote:
The web claims (I think on all pages I've read about Markdown and Python)
that this code should work, with some very minor variants on the topic:
```python
import os
with open(os.path.join('/home/user/apath', 'somefile')) as f:
print(f.read())
```
There are different flavors of Markdown, so that might be a factor so
far as details of the block are concerned.
What do you mean by it not "working"? What do you see and what did you
expect to see? What did you see different when you used the next example?
How did you generate the output HTML file?
However, that is not the case. At least not for me (using Python 3.12.3).
If instead I type it:
#!python
import os
with open(os.path.join('/home/user/apath', 'somefile')) as f:
print(f.read())
As an indented block (four spaces) and a shebang, THEN it works. You even
get line numbers by default.
N.b. if you don't know, you also need to generate a css file using
pygments to make this work.
Not until I started to read the markdown source code and its docs pages,
the coin dropped.
I'm posting this for other Markdown newbies that otherwise probably would
spend hours trying to make it work.
Speaking of Markdown. Does anybody out there have any idea how to turn on
table borders, adjust them (color/width/etc.) and such things? Currently I
have to add HTML to do so, which works, but isn't very nice. I'd hate to
spend an additional day or two, hunting for this info.
References:
https://pypi.org/project/Markdown/
https://python-markdown.github.io/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Weird Stuff (Markdown, syntax highlighting and Python)
With reference to another reply here, the "Weird stuff" came from
reading the question, finding it unclear, and only later realising that
whereas most people write Markdown-formatted documents for later
processing, or perhaps docstrings in Markdown-format for collection by
documentation systems; here, the objective appears to be using Python to
generate Markdown.
How much have you used Markdown to any serious degree, before attempting
this feat?
On 26/05/24 18:28, Gilmeh Serda via Python-list wrote:
The web claims (I think on all pages I've read about Markdown and Python)
that this code should work, with some very minor variants on the topic:
There are so many "variants", the problem is not "minor"!
Markdown users learn to use their tool (again, see @Grant's question)
and work within the implementation of that "variant".
Like any other non-standardised tool, the users of some particular
'version' often fail to realise that others using different versions may
not enjoy the same experience. Plus-one for standardisation!
At the end of the message, the web.refs reveal use of a package which is
based upon a variant of Markdown that is 20-years old(!), albeit with
some updates to suit yet another variant. Neither variant-author famous
for collaboration. The phrase YMMV springs to mind...
Some ten years ago, an effort was made to standardise Markup, and it
ended-up being called CommonMark. Why is it not called "Standard
Markdown" one might ask? Because the fellow who 'invented' Markdown
objected. This very objection has likely led directly to your
confusions, because the particular PyPi package is based upon that
original definition...
Whereas, Markdown 3.6 is the most-recently updated Markdown search-hit
on PyPi today, have you tried any of the others (which, ironically, may
offer more recent and/or more standardised coverage)?
This has worked in all of the Markdown processors I have used or tried-out:
The (?reasonable) 'common-core', offers single back-ticks for code,
triple back-ticks for a code-block, and the latter with or without a
language specification which *usually* kicks-in syntax highlighting.
```python
import os
with open(os.path.join('/home/user/apath', 'somefile')) as f:
print(f.read())
```
However, that is not the case. At least not for me (using Python 3.12.3).
It's not Python 3 that is the problem. It is the "Markdown 3.6" package!
If instead I type it:
I've not seen the hash-bang combination in-the-wild (but YMMV!)
#!python
import os
with open(os.path.join('/home/user/apath', 'somefile')) as f:
print(f.read())
As an indented block (four spaces) and a shebang, THEN it works. You even
get line numbers by default.
An indented-block is NOT necessarily the same as a code-block - just as
"code" is not necessarily "Python".
Line numbers are great - although if a code snippet is extracted from
the middle of some example code-file, the original line-numbers won't
line-up with Markdown's...
N.b. if you don't know, you also need to generate a css file using
pygments to make this work.
That's not what the package's docs suggest:
https://python-markdown.github.io/extensions/fenced_code_blocks/
Not until I started to read the markdown source code and its docs pages,
the coin dropped.
I'm posting this for other Markdown newbies that otherwise probably would
spend hours trying to make it work.
Speaking of Markdown. Does anybody out there have any idea how to turn on
table borders, adjust them (color/width/etc.) and such things? Currently I
have to add HTML to do so, which works, but isn't very nice. I'd hate to
spend an additional day or two, hunting for this info.
Again, heavily dependent upon the tool in-use. For example, most SSGs
and doc-tools (which accept Markdown) have a .css or theming-system
which enables 'decorations'.
References:
https://pypi.org/project/Markdown/
https://python-markdown.github.io/
Further reading:
https://en.wikipedia.org/wiki/Markdown
https://commonmark.org
https://pypi.org/search/?q=markdown
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Weird Stuff (Markdown, syntax highlighting and Python)
On 2024-05-26, Gilmeh Serda via Python-list wrote:
> The web claims (I think on all pages I've read about Markdown and Python)
> that this code should work, with some very minor variants on the topic:
>
> ```python
>
> import os
>
> with open(os.path.join('/home/user/apath', 'somefile')) as f:
> print(f.read())
> ```
>
> However, that is not the case.
For me, that block formats as expected using Python markdown.
What do you mean by "this code should work [...] that is not the case"?
What markdown rendering engine are you using?
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 20/05/2024 10:58, Peter J. Holzer wrote: On 2024-05-20 00:26:03 +0200, Roel Schroeven via Python-list wrote: Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08: Modern debian (ubuntu) and fedora block users installing using pip. Even if you're telling it to install in ~/.local? I could see not allowing to run it as root. I assumed pip install --user would work, but no. I tried it (on Debian 12 (bookworm)): $ pip install --user docopt error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. Exactly the same output for sudo pip install. This message (quoted in all its glory) is too long to be useful. The important bit is at the end: You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. (I admit I didn't see this the first time I got this message) python3 -m pip install --user --break-system-packages does indeed install into ~/.local/lib/python3.XX/site-packages. This inconvenient, but otoh I have accidentally installed packages into ~/.local in the past, so maybe it's good to make that more explicit. hp Perhaps an alias like so: $ alias 'pip install'='pip install --user --break-system-packages' Would work here? Someone please advise if that is a good idea. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
I'm on Manjaro Of course, I'm not here to tell you how to use your computer, and it's great that you're using Linux, but I'd suggest that you look into installing Arch Linux proper. Arch Linux isn't as difficult as people make it out to be (I'd argue that anyone who's had to deal with the Calamares installer has seen worse), and it's hugely rewarding as it gives you a fundamental overview of how your system operates and what makes it tick, since you need to install it yourself manually. Plus, Manjaro holds back packages by about a month or so, sometimes more, which breaks AUR packages, which are designed around Arch Linux's packages, which are newer. On top of this, the Manjaro team just can't be trusted with basic things like not having their SSL certs expire on their website (this has happened half a dozen times in the past, which is embarassing, given that things like certbot make installing a certificate the easiest thing in the world). Again, I'm not some power hungry elitist Arch Linux shill or whatever, it's your computer, use it how you want, these are just my suggestions. Don't say I didn't warn you though :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-20 00:26:03 +0200, Roel Schroeven via Python-list wrote: > Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08: > > > Modern debian (ubuntu) and fedora block users installing using pip. > > > > Even if you're telling it to install in ~/.local? I could see not allowing > > to run it as root. > > I assumed pip install --user would work, but no. I tried it (on Debian 12 > (bookworm)): > > > $ pip install --user docopt > > error: externally-managed-environment > > > > × This environment is externally managed > > ╰─> To install Python packages system-wide, try apt install > > python3-xyz, where xyz is the package you are trying to > > install. > > > > If you wish to install a non-Debian-packaged Python package, > > create a virtual environment using python3 -m venv path/to/venv. > > Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make > > sure you have python3-full installed. > > > > If you wish to install a non-Debian packaged Python application, > > it may be easiest to use pipx install xyz, which will manage a > > virtual environment for you. Make sure you have pipx installed. > > > > See /usr/share/doc/python3.11/README.venv for more information. > > > > note: If you believe this is a mistake, please contact your Python > > installation or OS distribution provider. You can override this, at the > > risk of breaking your Python installation or OS, by passing > > --break-system-packages. > > hint: See PEP 668 for the detailed specification. > > Exactly the same output for sudo pip install. This message (quoted in all its glory) is too long to be useful. The important bit is at the end: > > You can override this, at the risk of breaking your Python > > installation or OS, by passing --break-system-packages. (I admit I didn't see this the first time I got this message) python3 -m pip install --user --break-system-packages does indeed install into ~/.local/lib/python3.XX/site-packages. This inconvenient, but otoh I have accidentally installed packages into ~/.local in the past, so maybe it's good to make that more explicit. 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
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 5/19/2024 6:00 PM, Karsten Hilbert via Python-list wrote: Am Sun, May 19, 2024 at 10:45:09PM +0100 schrieb Barry via Python-list: On 18 May 2024, at 16:27, Peter J. Holzer via Python-list wrote: I don't think Linux users have to deal with venvs Modern debian (ubuntu) and fedora block users installing using pip. You must use a venv to pip install packages from pypi now. Which makes one wonder how one is supposed to package Python applications requiring modules not yet packaged by Debian. I confess, I sometimes install those packages using pip's self-warning option "--break-system-packages". Naturally I only install them with --user. Another option besides venvs is to install a different version of Python from python.org, not by using the system installer. For example, if your system version is, say, 3.8.10 (as it is on my Mint VM), install 3.11.9 and make sure you always launch pip with python3.11 -m pip I have done this on some VMs, and use the system's Python on some others. Happily none of my Linux VMs are critical for anything. I can blow them away and recreate them without worry. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 5/19/2024 6:34 PM, Grant Edwards via Python-list wrote: On 2024-05-19, Barry via Python-list wrote: On 18 May 2024, at 16:27, Peter J. Holzer via Python-list wrote: I don't think Linux users have to deal with venvs Modern debian (ubuntu) and fedora block users installing using pip. You can't even use pip to do "user" installs? Nope, often not. The error messages I've gotten do tell you to use the "--break-system-packages" flag if you really, really want to install the package. So python3 -m pip install --user --break-system-packages [--upgrade] Or install an additional version of Python that isn't managed by the system. Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 5/19/2024 6:08 PM, Skip Montanaro via Python-list wrote: Modern debian (ubuntu) and fedora block users installing using pip. Even if you're telling it to install in ~/.local? I could see not allowing to run it as root. I honestly haven't tried. Maybe I should... 樂 I have an old laptop running XUbuntu 22.04 which I generally only use to compile the most recent branches on GitHub (main, 3.12, & 3.13 at the moment). On some (maybe all) of my Linux VMs, pip - the one installed for the system - won't install something even with --user unless you use the --break-system-packages flag. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19, Barry via Python-list wrote: > > >> On 18 May 2024, at 16:27, Peter J. Holzer via Python-list >> wrote: >> >> I don't think Linux users have to deal with venvs > > Modern debian (ubuntu) and fedora block users installing using pip. You can't even use pip to do "user" installs? -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19, Gilmeh Serda via Python-list wrote: > On Sun, 19 May 2024 08:32:46 +0100, Alan Gauld wrote: > >> I've honestly never experienced this "nightmare". >> I install stuff and it just works. > > Hear! Hear! Me too! And all that. > > I'm on Manjaro, which is a tad finicky about other people touching its > Python since it's used for lots of things. I install things for myself > only. > > Was there a reason they chose the name Pip? I always assumed it was in honor of the PIP (Peripheral Interchange Program?) utility that was used to copy files around on CP/M and DEC's PDP-11 OSes. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08: Modern debian (ubuntu) and fedora block users installing using pip. > Even if you're telling it to install in ~/.local? I could see not allowing to run it as root. I assumed pip install --user would work, but no. I tried it (on Debian 12 (bookworm)): $ pip install --user docopt error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. Exactly the same output for sudo pip install. For easy reference here's a link to that PEP 668: https://peps.python.org/pep-0668/ Which links to the "Externally Managed Environments" on the PyPA specs page: https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments -- "If you don't read the newspaper, you're uninformed. If you read the newspaper, you're mis-informed." -― Onbekend (dikwijls toegeschreven aan Mark Twain, waarschijnlijk onterecht) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
Modern debian (ubuntu) and fedora block users installing using pip. > Even if you're telling it to install in ~/.local? I could see not allowing to run it as root. I honestly haven't tried. Maybe I should... 樂 I have an old laptop running XUbuntu 22.04 which I generally only use to compile the most recent branches on GitHub (main, 3.12, & 3.13 at the moment). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
Am Sun, May 19, 2024 at 10:45:09PM +0100 schrieb Barry via Python-list: > > On 18 May 2024, at 16:27, Peter J. Holzer via Python-list > > wrote: > > > > I don't think Linux users have to deal with venvs > > Modern debian (ubuntu) and fedora block users installing using pip. > You must use a venv to pip install packages from pypi now. Which makes one wonder how one is supposed to package Python applications requiring modules not yet packaged by Debian. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
> On 18 May 2024, at 16:27, Peter J. Holzer via Python-list > wrote: > > I don't think Linux users have to deal with venvs Modern debian (ubuntu) and fedora block users installing using pip. You must use a venv to pip install packages from pypi now. This is implemented in python and pip and enabled by the distros. There are ways to turn off the blocking, but it’s strongly discouraged by the distros. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19 at 18:13:23 +, Gilmeh Serda via Python-list wrote: > Was there a reason they chose the name Pip? Package Installer for Python https://pip.pypa.io/en/stable/index.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19 19:13, Gilmeh Serda via Python-list wrote: On Sun, 19 May 2024 08:32:46 +0100, Alan Gauld wrote: I've honestly never experienced this "nightmare". I install stuff and it just works. Hear! Hear! Me too! And all that. I'm on Manjaro, which is a tad finicky about other people touching its Python since it's used for lots of things. I install things for myself only. Was there a reason they chose the name Pip? [snip] From https://pip.pypa.io/en/stable/: "pip is the package installer for Python." It's an acronym. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19 at 18:13:23 +, Gilmeh Serda via Python-list wrote: > Was there a reason they chose the name Pip? Package Installer for Python https://pip.pypa.io/en/stable/index.html Every time I see PIP, I think Peripheral Interchange Program, but I'm old. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 5/19/2024 3:32 AM, Alan Gauld via Python-list wrote: On 18/05/2024 19:12, Piergiorgio Sartor via Python-list wrote: [snip] The dependency nightmare created by python, pip and all the rest cannot be resolved otherwise. I've honestly never experienced this "nightmare". I install stuff and it just works. One way it can bite even you is if you have a program installed whose requirements claim it needs a certain library of version no higher than X, and you already already have a later version of that library installed since one of your other programs requires it. Pip won't install the new program because of this conflict. In reality, you may know the the new program would work fine with the version of the library you installed, but the packagers of the new program didn't realize they should have updated their requirements. With venvs, you can have separate environments for each. Of course this doesn't help if you need both packages in the same environment... -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 2024-05-19, Alan Gauld via Python-list wrote: >> The dependency nightmare created by python, pip >> and all the rest cannot be resolved otherwise. > > I've honestly never experienced this "nightmare". > I install stuff and it just works. Same here. I occasonlly use pip to install something that isn't packaged for Gentoo, but it doesn't seem to cause problems — let alone nightmares. I also occasionally package something myself. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
