From phd at phdru.name Mon Dec 2 08:22:21 2024 From: phd at phdru.name (Oleg Broytman) Date: Mon, 2 Dec 2024 16:22:21 +0300 Subject: Cheetah 3.4.0 Message-ID: Hello! I'm pleased to announce version 3.4.0, the final release of branch 3.4 of CheetahTemplate3. What's new in CheetahTemplate3 ============================== This release spans two topics: adapting to Python 3.13 and fixes in import hooks. Bug fixes: - Fixed ``ImportHooks``: it must raise ``ModuleNotFoundError`` instead of ``ImportError``. - Fixed absolute import in ``ImportHooks`` under Python 3. - Use ``cache_from_source`` in ``ImportManager`` to find out ``.pyc``/``.pyo`` byte-code files. - Fixed unmarshalling ``.pyc``/``.pyo`` byte-code files in ``ImportManager``. - Fixed ``Template.webInput``: Use ``urllib.parse.parse_qs`` instead of ``cgi.FieldStorage``; Python 3.13 dropped ``cgi``. - Fixed ``_namemapper.c``: Silent an inadvertent ``TypeError`` exception in ``PyMapping_HasKeyString`` under Python 3.13+ caused by ``_namemapper`` looking up a key in a non-dictionary. - Fixed ``_namemapper.c``: Silence ``IndexError`` when testing ``name[attr]``. Some objects like ``re.MatchObject`` implement both attribute access and index access. This confuses ``NameMapper`` because it expects ``name[attr]`` to raise ``TypeError`` for objects that don't implement mapping protocol. - Fixed mapping test in ``NameMapper.py``: Python 3.13 brough a new mapping type ``FrameLocalsProxy``. - Fixed another ``RecursionError`` in ``ImportHooks`` under PyPy3. Tests: - tox: Run tests under Python 3.13. CI: - CI(GHActions): Switch to ``setup-miniconda``. - CI(GHActions): Run tests under Python 3.13. Build/release: - Rename sdist to lowercase; different build tools produce different case. This is important because stupid PyPI doesn't ignore sdists in different cases but also doesn't allow uploading. So we use single case, all lower. Also see PEP 625. What is CheetahTemplate3 ======================== Cheetah3 is a free and open source (MIT) Python template engine. It's a fork of the original CheetahTemplate library. Python 2.7 or 3.4+ is required. Where is CheetahTemplate3 ========================= Site: https://cheetahtemplate.org/ Download: https://pypi.org/project/CT3/3.4.0 News and changes: https://cheetahtemplate.org/news.html StackOverflow: https://stackoverflow.com/questions/tagged/cheetah Mailing lists: https://sourceforge.net/p/cheetahtemplate/mailman/ Development: https://github.com/CheetahTemplate3 Developer Guide: https://cheetahtemplate.org/dev_guide/ Example ======= Install:: $ pip install CT3 # (or even "ct3") Below is a simple example of some Cheetah code, as you can see it's practically Python. You can import, inherit and define methods just like in a regular Python module, since that's what your Cheetah templates are compiled to :) :: #from Cheetah.Template import Template #extends Template #set $people = [{'name' : 'Tom', 'mood' : 'Happy'}, {'name' : 'Dick', 'mood' : 'Sad'}, {'name' : 'Harry', 'mood' : 'Hairy'}] How are you feeling? Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From roel at roelschroeven.net Tue Dec 3 04:41:06 2024 From: roel at roelschroeven.net (Roel Schroeven) Date: Tue, 3 Dec 2024 10:41:06 +0100 Subject: super().__init__() and bytes Message-ID: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> We can use super().__init__() in the __init__() method of a derived class to initialize its base class. For example: import string class MyTemplate(string.Template): ??? def __init__(self, template_string): ??????? super().__init__(template_string) print(MyTemplate('Hello ${name}').substitute(name="Pedro")) This works, and prints "Hello Pedro" as expected. Note that I passed template_string in the super().__init__() call, and that is what used to initialize the base class. So far nothing special. When I try the same with bytes as base class though, that doesn't work (at least in the Python version I'm using, which is CPython 3.11.2 64-bit on Windows 10): class MyBytes(bytes): ??? def __init__(self, data): ??????? super().__init__(data) print(MyBytes(b'abcdefghijlkmn')) This results in an exception: Traceback (most recent call last): ? File "test_mybytes.py", line 4, in ??? print(MyBytes(b'abcdefghijlkmn')) ????????? ^^^^^^^^^^^^^^^^^^^^^^^^^^ ? File "test_mybytes.py", line 3, in __init__ ??? super().__init__(data) TypeError: object.__init__() takes exactly one argument (the instance to initialize) I'm passing two arguments (data and the implicit self), and apparently that's one too many. Let's try without arguments (i.e. only the implicit self): class MyBytes(bytes): ??? def __init__(self, data): ??????? super().__init__() print(MyBytes(b'abcdefghijlkmn')) Now it works, and prints b'abcdefghijlkmn'. The same happens with int as base class, and presumably a number of other classes. That behavior is beyond my understanding, so I have some questions that might hopefully lead to a better understanding: (1) How does that work? How does my argument end up in the code that initializes the instance state? (2) How can I customize the argument is passed? For example, what if I want to do something like (supersimple example) super().__init__(data * 2)? (3) Why is bytes (and int, ...) different? Is it because it's a builtin? Or implemented in C? Or something else? -- "Man had always assumed that he was more intelligent than dolphins because he had achieved so much ? the wheel, New York, wars and so on ? whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man ? for precisely the same reasons." -- Douglas Adams From roel at roelschroeven.net Tue Dec 3 05:01:00 2024 From: roel at roelschroeven.net (Roel Schroeven) Date: Tue, 3 Dec 2024 11:01:00 +0100 Subject: super().__init__() and bytes In-Reply-To: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> References: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> Message-ID: Op 3/12/2024 om 10:41 schreef Roel Schroeven via Python-list: > [...] > When I try the same with bytes as base class though, that doesn't work > (at least in the Python version I'm using, which is CPython 3.11.2 > 64-bit on Windows 10): > > class MyBytes(bytes): > ??? def __init__(self, data): > ??????? super().__init__(data) > print(MyBytes(b'abcdefghijlkmn')) > > This results in an exception: > > Traceback (most recent call last): > ? File "test_mybytes.py", line 4, in > ??? print(MyBytes(b'abcdefghijlkmn')) > ????????? ^^^^^^^^^^^^^^^^^^^^^^^^^^ > ? File "test_mybytes.py", line 3, in __init__ > ??? super().__init__(data) > TypeError: object.__init__() takes exactly one argument (the instance > to initialize) > > I'm passing two arguments (data and the implicit self), and apparently > that's one too many. Let's try without arguments (i.e. only the > implicit self): > > class MyBytes(bytes): > ??? def __init__(self, data): > ??????? super().__init__() > print(MyBytes(b'abcdefghijlkmn')) > > Now it works, and prints b'abcdefghijlkmn'. The same happens with int > as base class, and presumably a number of other classes. As a follow-up, it looks like this behavior is because bytes and int are immutable. When I try with bytesarray instead of bytes, which works largely the same but is mutable, things do work as I expect. There's a hint in the documentation of __new__(): "__new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation". But that doesn't tell me why using super().__init__() doesn't work for immutable classes. The documentation for __init__() says " If a base class has an __init__() method, the derived class?s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: super().__init__([args...])". So does that mean that bytes and int not have an __init__() method? Is there a link between being immutable and not having __init__()? -- "Man had always assumed that he was more intelligent than dolphins because he had achieved so much ? the wheel, New York, wars and so on ? whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man ? for precisely the same reasons." -- Douglas Adams From ajm at flonidan.dk Tue Dec 3 07:55:59 2024 From: ajm at flonidan.dk (Anders Munch) Date: Tue, 3 Dec 2024 12:55:59 +0000 Subject: super().__init__() and bytes In-Reply-To: References: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> Message-ID: Roel Schroeven wrote: > As a follow-up, it looks like this behavior is because bytes and int are immutable. Yes. > But that doesn't tell me why using super().__init__() doesn't work for immutable classes. bytes.__init__ does work, but it's just an inherited object.__init__, which does nothing, and takes no parameters. __init__ cannot change the value of the bytes object; the value is set by bytes.__new__ and cannot change after that. Best not to define an __init__ method at all, just use __new__. Something like: class BytesSubclass(bytes): def __new__(cls, whatever, arguments, you, like): bytesvalue = compute(whatever, arguments, you, like) ob = bytes.__new__(cls, bytesvalue) ob.some_other_att = compute_something_else(whatever, arguments, you, like) return ob regards, Anders From roel at roelschroeven.net Tue Dec 3 09:24:55 2024 From: roel at roelschroeven.net (Roel Schroeven) Date: Tue, 3 Dec 2024 15:24:55 +0100 Subject: super().__init__() and bytes In-Reply-To: References: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> Message-ID: Op 3/12/2024 om 13:55 schreef Anders Munch via Python-list: > Roel Schroeven wrote: > > As a follow-up, it looks like this behavior is because bytes and int are immutable. > > Yes. OK. > > But that doesn't tell me why using super().__init__() doesn't work for immutable classes. > > bytes.__init__ does work, but it's just an inherited object.__init__, which does nothing, and takes no parameters. > __init__ cannot change the value of the bytes object; the value is set by bytes.__new__ and cannot change after that. I see now why __init__, being a regular method, can't change an object's value (or attributes in general) if that object is immutable. I'm not sure why I didn't think of that before. It's not entirely clear to me though how bytes.__new__ *can* set an object's value. Isn't __new__ also a regular function? Are these immutable classes special cases in the language that can't be recreated in the same way with user-defined classes? Not that that's something I want to do, and it's also not terribly important to me, but I'm trying to better understand what's going on. > Best not to define an __init__ method at all, just use __new__. > > Something like: > > class BytesSubclass(bytes): > def __new__(cls, whatever, arguments, you, like): > bytesvalue = compute(whatever, arguments, you, like) > ob = bytes.__new__(cls, bytesvalue) > ob.some_other_att = compute_something_else(whatever, arguments, you, like) > return ob Thanks, that works perfectly. That's also more important than understanding all the nitty-gritty details (I feel a basic understanding is important, but not necessarily always all the low-level details). -- "There is no cause so noble that it will not attract fuggheads." -- Larry Niven From mohammadrezasaveji at gmail.com Mon Dec 2 07:06:50 2024 From: mohammadrezasaveji at gmail.com (Mohammadreza Saveji) Date: Mon, 2 Dec 2024 15:36:50 +0330 Subject: Cheetah 3.4.0 In-Reply-To: References: Message-ID: Thanks a lot Oleg sincerely yours On Mon, Dec 2, 2024 at 5:27?PM Oleg Broytman via Python-list < python-list at python.org> wrote: > Hello! > > I'm pleased to announce version 3.4.0, the final release > of branch 3.4 of CheetahTemplate3. > > > What's new in CheetahTemplate3 > ============================== > > This release spans two topics: adapting to Python 3.13 and > fixes in import hooks. > > Bug fixes: > > - Fixed ``ImportHooks``: it must raise ``ModuleNotFoundError`` > instead of ``ImportError``. > > - Fixed absolute import in ``ImportHooks`` under Python 3. > > - Use ``cache_from_source`` in ``ImportManager`` to find out > ``.pyc``/``.pyo`` byte-code files. > > - Fixed unmarshalling ``.pyc``/``.pyo`` byte-code files > in ``ImportManager``. > > - Fixed ``Template.webInput``: Use ``urllib.parse.parse_qs`` > instead of ``cgi.FieldStorage``; Python 3.13 dropped ``cgi``. > > - Fixed ``_namemapper.c``: Silent an inadvertent ``TypeError`` exception > in ``PyMapping_HasKeyString`` under Python 3.13+ > caused by ``_namemapper`` looking up a key in a non-dictionary. > > - Fixed ``_namemapper.c``: Silence ``IndexError`` when testing > ``name[attr]``. Some objects like ``re.MatchObject`` implement both > attribute access and index access. This confuses ``NameMapper`` because > it expects ``name[attr]`` to raise ``TypeError`` for objects that don't > implement mapping protocol. > > - Fixed mapping test in ``NameMapper.py``: > Python 3.13 brough a new mapping type ``FrameLocalsProxy``. > > - Fixed another ``RecursionError`` in ``ImportHooks`` under PyPy3. > > Tests: > > - tox: Run tests under Python 3.13. > > CI: > > - CI(GHActions): Switch to ``setup-miniconda``. > > - CI(GHActions): Run tests under Python 3.13. > > Build/release: > > - Rename sdist to lowercase; different build tools produce different > case. > This is important because stupid PyPI doesn't ignore sdists > in different cases but also doesn't allow uploading. > So we use single case, all lower. Also see PEP 625. > > > What is CheetahTemplate3 > ======================== > > Cheetah3 is a free and open source (MIT) Python template engine. > It's a fork of the original CheetahTemplate library. > > Python 2.7 or 3.4+ is required. > > > Where is CheetahTemplate3 > ========================= > > Site: > https://cheetahtemplate.org/ > > Download: > https://pypi.org/project/CT3/3.4.0 > > News and changes: > https://cheetahtemplate.org/news.html > > StackOverflow: > https://stackoverflow.com/questions/tagged/cheetah > > Mailing lists: > https://sourceforge.net/p/cheetahtemplate/mailman/ > > Development: > https://github.com/CheetahTemplate3 > > Developer Guide: > https://cheetahtemplate.org/dev_guide/ > > > Example > ======= > > Install:: > > $ pip install CT3 # (or even "ct3") > > Below is a simple example of some Cheetah code, as you can see it's > practically > Python. You can import, inherit and define methods just like in a regular > Python > module, since that's what your Cheetah templates are compiled to :) :: > > #from Cheetah.Template import Template > #extends Template > > #set $people = [{'name' : 'Tom', 'mood' : 'Happy'}, {'name' : 'Dick', > 'mood' : 'Sad'}, {'name' : 'Harry', 'mood' : > 'Hairy'}] > > How are you feeling? >
    > #for $person in $people >
  • > $person['name'] is $person['mood'] >
  • > #end for >
> > Oleg. > -- > Oleg Broytman https://phdru.name/ phd at phdru.name > Programmers don't die, they just GOSUB without RETURN. > -- > https://mail.python.org/mailman/listinfo/python-list > From greg.ewing at canterbury.ac.nz Tue Dec 3 18:14:17 2024 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 4 Dec 2024 12:14:17 +1300 Subject: super().__init__() and bytes In-Reply-To: References: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> Message-ID: On 4/12/24 3:24 am, Roel Schroeven wrote: > It's not entirely clear to me though how bytes.__new__ *can* set an > object's value. Isn't __new__ also a regular function? Yes, but the __new__ methods of the builtin immutable objects (int, str, bytes, etc.) are implemented in C, and so are able to do things that Python methods cannot. -- Greg From thomas at python.org Tue Dec 3 19:04:18 2024 From: thomas at python.org (Thomas Wouters) Date: Wed, 4 Dec 2024 01:04:18 +0100 Subject: [RELEASE] Python 3.13.1, 3.12.8, 3.11.11, 3.10.16 and 3.9.21 are now available Message-ID: Another big release day! Python 3.13.1 and 3.12.8 were regularly scheduled releases, but they do contain a few security fixes. That makes it a nice time to release the security-fix-only versions too, so everything is as secure as we can make it. Python 3.13.1 Python 3.13?s first maintenance release. My child is all growed up now, I guess! Almost 400 bugfixes, build improvements and documentation changes went in since 3.13.0, making this the very best Python release to date. https://www.python.org/downloads/release/python-3131/ Python 3.12.8 Python 3.12 might be slowly reaching middle age, but still received over 250 bugfixes, build improvements and documentation changes since 3.12.7. https://www.python.org/downloads/release/python-3128/ Python 3.11.11 I know it?s probably hard to hear, but this is the *second* security-only release of Python 3.11. Yes, really! Oh yes, I know, I know, but it?s true! Only 11 commits went in since 3.11.10. https://www.python.org/downloads/release/python-31111/ Python 3.10.16 Python 3.10 received a total of 14 commits since 3.10.15. Why more than 3.11? Because it needed a little bit of extra attention to keep working with current GitHub practices, I guess. https://www.python.org/downloads/release/python-31016/ Python 3.9.21 Python 3.9 isn?t quite ready for pasture yet, as it?s set to receive security fixes for at least another 10 months. Very similarly to 3.10, it received 14 commits since 3.9.20. https://www.python.org/downloads/release/python-3921/ Stay safe and upgrade! As always, upgrading is highly recommended to all users of affected versions. Enjoy the new releases Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from your tireless, tireless release team, Thomas Wouters Ned Deily Steve Dower Pablo Galindo Salgado ?ukasz Langa From jsf80238 at gmail.com Tue Dec 3 20:13:46 2024 From: jsf80238 at gmail.com (Jason Friedman) Date: Tue, 3 Dec 2024 18:13:46 -0700 Subject: [RELEASE] Python 3.13.1, 3.12.8, 3.11.11, 3.10.16 and 3.9.21 are now available In-Reply-To: References: Message-ID: ? On Tue, Dec 3, 2024 at 5:06?PM Thomas Wouters via Python-list < python-list at python.org> wrote: > Another big release day! Python 3.13.1 and 3.12.8 were regularly scheduled > releases, but they do contain a few security fixes. That makes it a nice > time to release the security-fix-only versions too, so everything is as > secure as we can make it. > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3131-1 > >Python > 3.13.1 > > Python 3.13?s first maintenance release. My child is all growed up now, I > guess! Almost 400 bugfixes, build improvements and documentation changes > went in since 3.13.0, making this the very best Python release to date. > https://www.python.org/downloads/release/python-3131/ > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3128-2 > >Python > 3.12.8 > > Python 3.12 might be slowly reaching middle age, but still received over > 250 bugfixes, build improvements and documentation changes since 3.12.7. > https://www.python.org/downloads/release/python-3128/ > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-31111-3 > >Python > 3.11.11 > > I know it?s probably hard to hear, but this is the *second* security-only > release of Python 3.11. Yes, really! Oh yes, I know, I know, but it?s true! > Only 11 commits went in since 3.11.10. > https://www.python.org/downloads/release/python-31111/ > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-31016-4 > >Python > 3.10.16 > > Python 3.10 received a total of 14 commits since 3.10.15. Why more than > 3.11? Because it needed a little bit of extra attention to keep working > with current GitHub practices, I guess. > https://www.python.org/downloads/release/python-31016/ > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3921-5 > >Python > 3.9.21 > > Python 3.9 isn?t quite ready for pasture yet, as it?s set to receive > security fixes for at least another 10 months. Very similarly to 3.10, it > received 14 commits since 3.9.20. > https://www.python.org/downloads/release/python-3921/ > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-stay-safe-and-upgrade-6 > >Stay > safe and upgrade! > > As always, upgrading is highly recommended to all users of affected > versions. > < > https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-enjoy-the-new-releases-7 > >Enjoy > the new releases > > Thanks to all of the many volunteers who help make Python Development and > these releases possible! Please consider supporting our efforts by > volunteering yourself or through organization contributions to the Python > Software Foundation. > > Regards from your tireless, tireless release team, > Thomas Wouters > Ned Deily > Steve Dower > Pablo Galindo Salgado > ?ukasz Langa > -- > https://mail.python.org/mailman/listinfo/python-list > From roel at roelschroeven.net Wed Dec 4 06:38:33 2024 From: roel at roelschroeven.net (Roel Schroeven) Date: Wed, 4 Dec 2024 12:38:33 +0100 Subject: super().__init__() and bytes In-Reply-To: References: <3cc6272f-b151-474a-a83c-7f3339734bf5@roelschroeven.net> Message-ID: Op 4/12/2024 om 0:14 schreef Greg Ewing via Python-list: > On 4/12/24 3:24 am, Roel Schroeven wrote: >> It's not entirely clear to me though how bytes.__new__ *can* set an >> object's value. Isn't __new__ also a regular function? > > Yes, but the __new__ methods of the builtin immutable objects (int, > str, bytes, etc.) are implemented in C, and so are able to do things > that Python methods cannot. Aha, yes, that's what I already suspected, but I wasn't sure. Thanks for confirming that. All clear now. Thanks to Anders and Greg for explaining this to me. "In the old days, writers used to sit in front of a typewriter and stare out of the window. Nowadays, because of the marvels of convergent technology, the thing you type on and the window you stare out of are now the same thing.? -- Douglas Adams From mk1853387 at gmail.com Mon Dec 9 14:19:27 2024 From: mk1853387 at gmail.com (marc nicole) Date: Mon, 9 Dec 2024 20:19:27 +0100 Subject: How to catch a fatal error in Python 2.7? Message-ID: Hello, The fatal error exits the program with a code -1 while referencing the memory address involved and nothing else. How to catch it in Python 2.7? PS: please not I am not talking about exceptions but an error resulting from the disconnection of my bluetooth microphone abruptly and leading to the halting of the whole program, I need to be able to do something when it occurs. Thanks for the help! From torriem at gmail.com Mon Dec 9 14:38:43 2024 From: torriem at gmail.com (Michael Torrie) Date: Mon, 9 Dec 2024 12:38:43 -0700 Subject: How to catch a fatal error in Python 2.7? In-Reply-To: References: Message-ID: <6190ce2a-a5bf-6872-1714-e1f8677e0add@gmail.com> On 12/9/24 12:19 PM, marc nicole via Python-list wrote: > Hello, > > The fatal error exits the program with a code -1 while referencing the > memory address involved and nothing else. > > How to catch it in Python 2.7? Does the problem occur with Python 3.x? At this date, Python 2.7 is only supported by your vendor if you are using an enterprise Linux distribution. I don't think there is a way to recover from that error in your python script. It could be a bug in the Python interpreter (which will never be fixed in 2.7), or it could be a bug in a library somewhere. The latter is most likely. There's nothing you can do about it from a Python script to recover. > PS: please not I am not talking about exceptions but an error resulting > from the disconnection of my bluetooth microphone abruptly and leading to > the halting of the whole program, I need to be able to do something when it > occurs. > > Thanks for the help! From thjmmj15 at gmail.com Mon Dec 9 18:59:49 2024 From: thjmmj15 at gmail.com (Tim Johnson) Date: Mon, 9 Dec 2024 14:59:49 -0900 Subject: ModuleNotFoundError for youtube_dl Message-ID: <52495180-0498-4819-9baf-8e6a0717a26d@gmail.com> Recently did a refresh of ubuntu 24.04 With no code changes am now getting a *ModuleNotFoundError *for youtube_dl Relevant code is import sys sys.path.append("/home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl") import youtube_dl ' Navigating to /home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl, I see the following tim at beelink:~/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl$ ls aes.py??? compat.py?? extractor??? jsinterp.py? options.py __pycache__? swfinterp.py? utils.py??? YoutubeDL.py cache.py? downloader? __init__.py? __main__.py? postprocessor socks.py???? update.py???? version.py I've been retired from python programming for 10 years now, and just tinker or write stuff for myself to use on my own workstation, so I have obviously forgotten a lot (if you don't use it you lose it, right) I hope that someone can help me correct this. thanks tim From thjmmj15 at gmail.com Mon Dec 9 20:41:15 2024 From: thjmmj15 at gmail.com (Tim Johnson) Date: Mon, 9 Dec 2024 16:41:15 -0900 Subject: ModuleNotFoundError for youtube_dl In-Reply-To: <52495180-0498-4819-9baf-8e6a0717a26d@gmail.com> References: <52495180-0498-4819-9baf-8e6a0717a26d@gmail.com> Message-ID: <0ef85f40-9617-4097-bc86-9dffd02ea15f@gmail.com> On 12/9/24 14:59, Tim Johnson wrote: > > Recently did a refresh of ubuntu 24.04 > > With no code changes am now getting a *ModuleNotFoundError *for youtube_dl > > Relevant code is > > import sys > sys.path.append("/home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl") > > import youtube_dl ' > > Navigating to > /home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl, > > I see the following > > tim at beelink:~/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl$ > ls > aes.py??? compat.py?? extractor??? jsinterp.py? options.py > __pycache__? swfinterp.py? utils.py??? YoutubeDL.py > cache.py? downloader? __init__.py? __main__.py? postprocessor > socks.py???? update.py???? version. > I should not have appended 'youtube_dl' to the path. I used the content from /home/tim/.local/share/pipx/shared/lib/python3.12/site-packages/pipx_shared.pth ("/home/tim/.local/share/pipx/shared/lib/python3.12/site-packages") and added that to /usr/lib/python3.12/sitecustomize.py as appended to sys.path and it appears to be solved. From jkn+es at nicorp.co.uk Tue Dec 10 17:35:22 2024 From: jkn+es at nicorp.co.uk (jkn) Date: Tue, 10 Dec 2024 22:35:22 +0000 Subject: ModuleNotFoundError for youtube_dl In-Reply-To: References: <52495180-0498-4819-9baf-8e6a0717a26d@gmail.com> <0ef85f40-9617-4097-bc86-9dffd02ea15f@gmail.com> Message-ID: On 10/12/2024 01:41, Tim Johnson wrote: > > On 12/9/24 14:59, Tim Johnson wrote: >> >> Recently did a refresh of ubuntu 24.04 >> >> With no code changes am now getting a *ModuleNotFoundError *for >> youtube_dl >> >> Relevant code is >> >> import sys >> sys.path.append("/home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl") >> >> import youtube_dl ' >> >> Navigating to >> /home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl, >> >> I see the following >> >> tim at beelink:~/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl$ ls >> aes.py??? compat.py?? extractor??? jsinterp.py? options.py >> __pycache__? swfinterp.py? utils.py??? YoutubeDL.py >> cache.py? downloader? __init__.py? __main__.py? postprocessor >> socks.py???? update.py???? version. >> > I should not have appended 'youtube_dl' to the path. I used the content > from > /home/tim/.local/share/pipx/shared/lib/python3.12/site-packages/pipx_shared.pth > > ("/home/tim/.local/share/pipx/shared/lib/python3.12/site-packages") and > added that to /usr/lib/python3.12/sitecustomize.py as appended to sys.path > > and it appears to be solved. FWIW I think youtube_dl has largely been supplanted by the (maintained) 'yt-dlp' these days J^n From aotto1968 at t-online.de Fri Dec 13 05:36:01 2024 From: aotto1968 at t-online.de (aotto1968) Date: Fri, 13 Dec 2024 11:36:01 +0100 Subject: it's a shame... python error over error Message-ID: it's a shame... almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python installation __isn't__ properly "understood". -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by default. -> example here is the "mono-build" with the following installation. make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird betreten HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory make[2]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird betreten HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory make[2]: F?r das Ziel ?install-exec-am? ist nichts zu tun. make[2]: F?r das Ziel ?install-data-am? ist nichts zu tun. make[2]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen [debug]dev1usr at linux02:~/src/mono.git> ldd HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 linux-vdso.so.1 (0x00007ffd18e9a000) libpython3.12d.so.1.0 => HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 (0x00007f9c5d374000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000) libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000) libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000) /lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000) From aotto1968 at t-online.de Fri Dec 13 05:44:00 2024 From: aotto1968 at t-online.de (aotto1968) Date: Fri, 13 Dec 2024 11:44:00 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 13.12.24 11:36, aotto1968 wrote: > it's a shame... > almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python > installation __isn't__ properly "understood". > > -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by default. > > -> example here is the "mono-build" with the following installation. > 1. The build is done with my user and the installation is done as root. 2. The setup proper find *my* python3 because my PATH etc is setup well. 3. root is an other environment and root does *not* have my environment. 4. root uses *my* python3 without *my* environment and is *not* able to find *my* libpython3.12d.so.1.0 5. obviously the *python3* is *not* able to create the right environment from the installation directory of the *python3* executable. From aotto1968 at t-online.de Fri Dec 13 05:49:11 2024 From: aotto1968 at t-online.de (aotto1968) Date: Fri, 13 Dec 2024 11:49:11 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 13.12.24 11:44, aotto1968 wrote: > On 13.12.24 11:36, aotto1968 wrote: >> it's a shame... >> almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python >> installation __isn't__ properly "understood". >> >> -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by >> default. >> >> -> example here is the "mono-build" with the following installation. >> > > 1. The build is done with my user and the installation is done as root. > 2. The setup proper find *my* python3 because my PATH etc is setup well. > 3. root is an other environment and root does *not* have my environment. > 4. root uses *my* python3 without *my* environment and is *not* able to find > ?? *my* libpython3.12d.so.1.0 > 5. obviously the *python3* is *not* able to create the right environment from > ? the installation directory of the *python3* executable. even the `sudo -E make install` with "-E, --preserve-env" does help. From barry at barrys-emacs.org Fri Dec 13 13:24:29 2024 From: barry at barrys-emacs.org (Barry) Date: Fri, 13 Dec 2024 18:24:29 +0000 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: > On 13 Dec 2024, at 15:54, aotto1968 via Python-list wrote: > > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory This is a debug build? Try setting LD_LIBRARY_PATH to point at the folder that contains the .so. Test with `ldd python3` which will show which .so libs python3 needs and if they are found. This is what I see on Fedora 41 as an example of the output. $ ldd /usr/bin/python3 linux-vdso.so.1 (0x0000ffffb8515000) libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 (0x0000ffffb7ea0000) libc.so.6 => /lib64/libc.so.6 (0x0000ffffb7cd0000) libm.so.6 => /lib64/libm.so.6 (0x0000ffffb7c20000) /lib/ld-linux-aarch64.so.1 (0x0000ffffb84d0000) Barry From aotto1968 at t-online.de Fri Dec 13 15:56:54 2024 From: aotto1968 at t-online.de (aotto1968) Date: Fri, 13 Dec 2024 21:56:54 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 13.12.24 19:24, Barry wrote: > > >> On 13 Dec 2024, at 15:54, aotto1968 via Python-list wrote: >> >> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file or directory > > This is a debug build? > > Try setting LD_LIBRARY_PATH to point at the folder that contains the .so. > Test with `ldd python3` which will show which .so libs python3 needs and if they are found. > > This is what I see on Fedora 41 as an example of the output. > > $ ldd /usr/bin/python3 > linux-vdso.so.1 (0x0000ffffb8515000) > libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 (0x0000ffffb7ea0000) > libc.so.6 => /lib64/libc.so.6 (0x0000ffffb7cd0000) > libm.so.6 => /lib64/libm.so.6 (0x0000ffffb7c20000) > /lib/ld-linux-aarch64.so.1 (0x0000ffffb84d0000) > > Barry > > the problem is *not* to setup an environment variable, the problem is that python is *not* able to setup the *python* environment by it self. From hjp-python at hjp.at Sat Dec 14 04:56:57 2024 From: hjp-python at hjp.at (Peter J. Holzer) Date: Sat, 14 Dec 2024 10:56:57 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: <20241214095657.s3solqdmwulqqhvt@hjp.at> On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote: > it's a shame... > almost every tool I touch that uses "python" in some way has some > configuration error because apparently a __private__ python installation > __isn't__ properly "understood". > > -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by default. > > -> example here is the "mono-build" with the following installation. > > make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird betreten > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared > libraries: libpython3.12d.so.1.0: cannot open shared object file: No such > file or directory What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is HOME/src/mono.git/acceptance-tests trying to use it? [...] > make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen > [debug]dev1usr at linux02:~/src/mono.git> ldd HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 > linux-vdso.so.1 (0x00007ffd18e9a000) > libpython3.12d.so.1.0 => HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 (0x00007f9c5d374000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000) > libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000) > libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000) > libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000) > /lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000) So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you invoke it from the shell (to confirm that, try actually invoking it instead of running ldd on it), but not when it's called from whatever make is doing in the acceptance-tests directory. So it might be because it's in a different directory ("HOME/ext/..." is a relative path. That will not work in a different directory. Also "HOME" is a strange choice for a directory name. Did you mean $HOME?) or because the acceptance tests set up their own environment. I'd test the first idea first. Cd into HOME/src/mono.git/acceptance-tests and try to invoke HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From torriem at gmail.com Sat Dec 14 10:27:29 2024 From: torriem at gmail.com (Michael Torrie) Date: Sat, 14 Dec 2024 08:27:29 -0700 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: <5e184152-6b91-6c81-4df6-5c761e13c232@gmail.com> On 12/13/24 1:56 PM, aotto1968 via Python-list wrote: > the problem is *not* to setup an environment variable, the problem is that python is *not* > able to setup the *python* environment by it self. You're mistaken in this case. Nothing you've posted indicates the problem is in Python itself. Something isn't quite right with your linker and the linker search paths. LD_LIBRARY_PATH is one way to force the linker to use the correct search path. Python has no direct influence over the linker search paths, other than to list what shared libraries it is linked against, or to manually add paths to the linker in /etc/ld.so.conf.d/ during package installation. The ld.so linker is responsible for finding the files and linking them in, not Python. In your case it seems unable to do so, for whatever reason. Since your custom version of python3 does seem to link to the so properly, it seems as though something isn't right in the environment of the mono build process. Again, nothing to do with Python. The linker isn't even getting to the bit where it links in libpython3. From torriem at gmail.com Sat Dec 14 10:30:19 2024 From: torriem at gmail.com (Michael Torrie) Date: Sat, 14 Dec 2024 08:30:19 -0700 Subject: it's a shame... python error over error In-Reply-To: <20241214095657.s3solqdmwulqqhvt@hjp.at> References: <20241214095657.s3solqdmwulqqhvt@hjp.at> Message-ID: <913f5f26-6a70-f91c-60df-f47e721fd70e@gmail.com> On 12/14/24 2:56 AM, Peter J. Holzer via Python-list wrote: > So it might be because it's in a different directory ("HOME/ext/..." is > a relative path. That will not work in a different directory. Also > "HOME" is a strange choice for a directory name. Did you mean $HOME?) or > because the acceptance tests set up their own environment. > > I'd test the first idea first. Cd into > HOME/src/mono.git/acceptance-tests and try to invoke > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there. Indeed something is not right with his ld.so search paths. The original error report indicates the linker cannot even find the libpython so file, so this cannot be a problem with Python since the linker hasn't even found it. I don't see how he expects python to fix this configuration issue magically for mono's build scripts. From ruppert at hs-worms.de Sat Dec 14 02:39:35 2024 From: ruppert at hs-worms.de (Martin Ruppert) Date: Sat, 14 Dec 2024 07:39:35 -0000 (UTC) Subject: Division-Bug in decimal and mpmath Message-ID: Hi, the division 0.4/7 provides a wrong result. It should give a periodic decimal fraction with at most six digits, but it doesn't. Below is the comparison of the result of decimal, mpmath, dc and calc. 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 0.05714285714285715 builtin: 0.4/7 Both decimal and mpmath give an identical result, which is not a periodic decimal fraction with at most six digits. calc and dc provide as well an identical result, which *is* a periodic decimal fraction with six digits, so I think that's right. Below ist the python-script, with which the computation was done. Best regards Martin Ruppert #!/usr/bin/env python3 from decimal import Decimal as dec from mpmath import * from os import popen import decimal z=.4 nen=7 decimal.getcontext().prec=60 print(dec(z)/dec(nen),end=' ');print(f"decimal: {z}/{nen}") mp.dps=60 a=fdiv(z,nen);print(a,end=' ');print(f"mpmath: {z}/{nen}") f=popen(f"dc -e'61k{z} {nen}/f'") for i in f:i=i.rstrip() f.close() print(f"0{i}",end=' ');print(f"dc: {z}/{nen}") f=popen(f"calc 'config(\"display\",61);{z}/{nen}'") j=0 for i in f: if j>0:i=i.rstrip();print(i,end=' ');print(f"calc: {z}/{nen}") j+=1 f.close() print(f"{z/nen}",end=' ');print(f"builtin: {z}/{nen}") -- ruppert at hs-worms.de From nntp.mbourne at spamgourmet.com Sat Dec 14 07:08:29 2024 From: nntp.mbourne at spamgourmet.com (Mark Bourne) Date: Sat, 14 Dec 2024 12:08:29 +0000 Subject: Division-Bug in decimal and mpmath In-Reply-To: References: Message-ID: Martin Ruppert wrote: > Hi, > > the division 0.4/7 provides a wrong result. It should give a periodic > decimal fraction with at most six digits, but it doesn't. > > Below is the comparison of the result of decimal, mpmath, dc and calc. > > 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 > 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 > 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 > 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 > 0.05714285714285715 builtin: 0.4/7 > > Both decimal and mpmath give an identical result, which is not a > periodic decimal fraction with at most six digits. > > calc and dc provide as well an identical result, which *is* a periodic > decimal fraction with six digits, so I think that's right. I looks like you might be running into limitations in floating-point numbers. At least with decimal, calculating 4/70 instead of 0.4/7 appears to give the correct result. As does: ``` from decimal import Decimal as dec z2 = dec(4) / dec(10) print(z2 / dec(nen)) ``` You can also pass a string, and `dec("0.4")/dec(10)` gives the correct result as well. Your `z` is a float, and therefore limited by the precision of a float. It doesn't represent exactly 0.4, since that can't be exactly represented by a float. Anything you do from then on is limited to that precision. I can't easily find documentation for dc and calc (links from PyPI are either broken or don't exist), but I'm guessing they use some heuristics to determine that the float passed in very close to 0.4 so that was probably intended, rather than using the exact value represented by that float. > Below ist the python-script, with which the computation was done. > > Best regards > Martin Ruppert > > #!/usr/bin/env python3 > from decimal import Decimal as dec > from mpmath import * > from os import popen > import decimal > > z=.4 > nen=7 > > decimal.getcontext().prec=60 > print(dec(z)/dec(nen),end=' ');print(f"decimal: {z}/{nen}") > > mp.dps=60 > a=fdiv(z,nen);print(a,end=' ');print(f"mpmath: {z}/{nen}") > > f=popen(f"dc -e'61k{z} {nen}/f'") > for i in f:i=i.rstrip() > f.close() > print(f"0{i}",end=' ');print(f"dc: {z}/{nen}") > > f=popen(f"calc 'config(\"display\",61);{z}/{nen}'") > j=0 > for i in f: > if j>0:i=i.rstrip();print(i,end=' ');print(f"calc: {z}/{nen}") > j+=1 > f.close() > > print(f"{z/nen}",end=' ');print(f"builtin: {z}/{nen}") > From aotto1968 at t-online.de Sat Dec 14 12:31:22 2024 From: aotto1968 at t-online.de (aotto1968) Date: Sat, 14 Dec 2024 18:31:22 +0100 Subject: it's a shame... python error over error In-Reply-To: References: <20241214095657.s3solqdmwulqqhvt@hjp.at> Message-ID: On 14.12.24 10:56, Peter J. Holzer wrote: > On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote: >> it's a shame... >> almost every tool I touch that uses "python" in some way has some >> configuration error because apparently a __private__ python installation >> __isn't__ properly "understood". >> >> -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by default. >> >> -> example here is the "mono-build" with the following installation. >> >> make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird betreten >> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared >> libraries: libpython3.12d.so.1.0: cannot open shared object file: No such >> file or directory > > What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is > HOME/src/mono.git/acceptance-tests trying to use it? > > [...] >> make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen >> [debug]dev1usr at linux02:~/src/mono.git> ldd HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 >> linux-vdso.so.1 (0x00007ffd18e9a000) >> libpython3.12d.so.1.0 => HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 (0x00007f9c5d374000) >> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000) >> libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000) >> libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000) >> libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000) >> libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000) > > So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find > HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you > invoke it from the shell (to confirm that, try actually invoking it > instead of running ldd on it), but not when it's called from whatever > make is doing in the acceptance-tests directory. > > So it might be because it's in a different directory ("HOME/ext/..." is > a relative path. That will not work in a different directory. Also > "HOME" is a strange choice for a directory name. Did you mean $HOME?) or > because the acceptance tests set up their own environment. > > I'd test the first idea first. Cd into > HOME/src/mono.git/acceptance-tests and try to invoke > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there. > > hp > The CORE problem is that python3 works well in *my* environment but the installation is done as root and root does not use *my* environment. the mono build search for a working python3 and find *my* > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 The build is fine but after switch to root for installation > sudo make install the root user call *my* python3 and fail. From rosuav at gmail.com Sat Dec 14 14:12:33 2024 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 15 Dec 2024 06:12:33 +1100 Subject: it's a shame... python error over error In-Reply-To: References: <20241214095657.s3solqdmwulqqhvt@hjp.at> Message-ID: On Sun, 15 Dec 2024 at 06:05, aotto1968 via Python-list wrote: > The CORE problem is that python3 works well in *my* environment but the > installation is done as root and root does not use *my* environment. > So, it's an environment problem, NOT a Python problem. You messed up your installation. Start over, rebuild. ChrisA From 2QdxY4RzWzUUiLuE at potatochowder.com Sat Dec 14 14:21:06 2024 From: 2QdxY4RzWzUUiLuE at potatochowder.com (2QdxY4RzWzUUiLuE at potatochowder.com) Date: Sat, 14 Dec 2024 14:21:06 -0500 Subject: Division-Bug in decimal and mpmath In-Reply-To: References: Message-ID: On 2024-12-14 at 12:08:29 +0000, Mark Bourne via Python-list wrote: > Martin Ruppert wrote: > > Hi, > > > > the division 0.4/7 provides a wrong result. It should give a periodic > > decimal fraction with at most six digits, but it doesn't. > > > > Below is the comparison of the result of decimal, mpmath, dc and calc. > > > > 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 > > 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 > > 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 > > 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 > > 0.05714285714285715 builtin: 0.4/7 > > > > Both decimal and mpmath give an identical result, which is not a > > periodic decimal fraction with at most six digits. > > > > calc and dc provide as well an identical result, which *is* a periodic > > decimal fraction with six digits, so I think that's right. > > I looks like you might be running into limitations in floating-point > numbers. At least with decimal, calculating 4/70 instead of 0.4/7 appears > to give the correct result. As does: > ``` > from decimal import Decimal as dec > z2 = dec(4) / dec(10) > print(z2 / dec(nen)) > ``` > You can also pass a string, and `dec("0.4")/dec(10)` gives the correct > result as well. > > Your `z` is a float, and therefore limited by the precision of a float. It > doesn't represent exactly 0.4, since that can't be exactly represented by a > float. Anything you do from then on is limited to that precision. > > I can't easily find documentation for dc and calc (links from PyPI are > either broken or don't exist), but I'm guessing they use some heuristics to > determine that the float passed in very close to 0.4 so that was probably > intended, rather than using the exact value represented by that float. I'm going to guess that since dc is a shell utility and calc is either another shell utility or the calculator in emacs, and that they both do their own conversion from a string to an internal representation without going through an IEEE float. Why couldn't we have evolved with eight fingers on each hand? ;-) From torriem at gmail.com Sun Dec 15 00:21:20 2024 From: torriem at gmail.com (Michael Torrie) Date: Sat, 14 Dec 2024 22:21:20 -0700 Subject: it's a shame... python error over error In-Reply-To: References: <20241214095657.s3solqdmwulqqhvt@hjp.at> Message-ID: On 12/14/24 10:31 AM, aotto1968 via Python-list wrote: > The CORE problem is that python3 works well in *my* environment but the > installation is done as root and root does not use *my* environment. > > the mono build search for a working python3 and find *my* > > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 > The build is fine but after switch to root for installation > > sudo make install > the root user call *my* python3 and fail. mono build is failing even before you get to running your python3. That's not something python developers can fix. From nntp.mbourne at spamgourmet.com Sun Dec 15 06:59:40 2024 From: nntp.mbourne at spamgourmet.com (Mark Bourne) Date: Sun, 15 Dec 2024 11:59:40 +0000 Subject: Division-Bug in decimal and mpmath In-Reply-To: References: Message-ID: 2QdxY4RzWzUUiLuE at potatochowder.com wrote: > On 2024-12-14 at 12:08:29 +0000, > Mark Bourne via Python-list wrote: > >> Martin Ruppert wrote: >>> Hi, >>> >>> the division 0.4/7 provides a wrong result. It should give a periodic >>> decimal fraction with at most six digits, but it doesn't. >>> >>> Below is the comparison of the result of decimal, mpmath, dc and calc. >>> >>> 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 >>> 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 >>> 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 >>> 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 >>> 0.05714285714285715 builtin: 0.4/7 >>> >>> Both decimal and mpmath give an identical result, which is not a >>> periodic decimal fraction with at most six digits. >>> >>> calc and dc provide as well an identical result, which *is* a periodic >>> decimal fraction with six digits, so I think that's right. >> >> I looks like you might be running into limitations in floating-point >> numbers. At least with decimal, calculating 4/70 instead of 0.4/7 appears >> to give the correct result. As does: >> ``` >> from decimal import Decimal as dec >> z2 = dec(4) / dec(10) >> print(z2 / dec(nen)) >> ``` >> You can also pass a string, and `dec("0.4")/dec(10)` gives the correct >> result as well. >> >> Your `z` is a float, and therefore limited by the precision of a float. It >> doesn't represent exactly 0.4, since that can't be exactly represented by a >> float. Anything you do from then on is limited to that precision. >> >> I can't easily find documentation for dc and calc (links from PyPI are >> either broken or don't exist), but I'm guessing they use some heuristics to >> determine that the float passed in very close to 0.4 so that was probably >> intended, rather than using the exact value represented by that float. > > I'm going to guess that since dc is a shell utility and calc is either > another shell utility or the calculator in emacs, and that they both do > their own conversion from a string to an internal representation without > going through an IEEE float. Oh yes. Thinking the question was about 4 different Python packages, I'd just looked up the packages with those names on PyPI and hadn't noticed they were separate commands being called via popen! In that case, the string formatting of a float in the commands defaults to 6 decimal places, and `z` is rounded back to 0.4 rather than the exact value represented by the float. From there, as you say, `dc` and `calc` probably handle that string similarly to `decimal.Decimal` being passed the string "0.4". > Why couldn't we have evolved with eight fingers on each hand? ;-) Yeah, it would have made conversions to and from binary somewhat more intuitive... -- Mark. From oscar.j.benjamin at gmail.com Sun Dec 15 16:29:18 2024 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Sun, 15 Dec 2024 21:29:18 +0000 Subject: Division-Bug in decimal and mpmath In-Reply-To: References: Message-ID: On Sat, 14 Dec 2024 at 19:02, Mark Bourne via Python-list wrote: > > Martin Ruppert wrote: > > Hi, > > > > the division 0.4/7 provides a wrong result. It should give a periodic > > decimal fraction with at most six digits, but it doesn't. > > > > Below is the comparison of the result of decimal, mpmath, dc and calc. ... > > I looks like you might be running into limitations in floating-point > numbers. At least with decimal, calculating 4/70 instead of 0.4/7 > appears to give the correct result. As does: > ``` > from decimal import Decimal as dec > z2 = dec(4) / dec(10) > print(z2 / dec(nen)) > ``` > You can also pass a string, and `dec("0.4")/dec(10)` gives the correct > result as well. For completeness this is how to do it with mpmath: >>> from mpmath import mp >>> mp.dps = 60 >>> mp.mpf('0.4') / 7 mpf('0.0571428571428571428571428571428571428571428571428571428571428549') You can also use SymPy: >>> from sympy import Rational >>> a = Rational('0.4') / 7 >>> a 2/35 >>> a.evalf(60) 0.0571428571428571428571428571428571428571428571428571428571429 SymPy uses mpmath for evalf but it allows doing exact calculations first and then evaluating the final exact expression to however many digits are desired at the end which means that you don't need to accumulate rounding errors before calling evalf. -- Oscar From aotto1968 at t-online.de Mon Dec 16 02:08:46 2024 From: aotto1968 at t-online.de (aotto1968) Date: Mon, 16 Dec 2024 08:08:46 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 13.12.24 11:36, aotto1968 wrote: > it's a shame... > almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python > installation __isn't__ properly "understood". > > -> I think after ~30 years *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by default. > > -> example here is the "mono-build" with the following installation. > > make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird betreten > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open > shared object file: No such file or directory > make[2]: F?r das Ziel ?install-exec-am? ist nichts zu tun. > make[2]: F?r das Ziel ?install-data-am? ist nichts zu tun. > make[2]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen > make[1]: Verzeichnis ?HOME/src/mono.git/acceptance-tests? wird verlassen > [debug]dev1usr at linux02:~/src/mono.git> ldd HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 > ??????? linux-vdso.so.1 (0x00007ffd18e9a000) > ??????? libpython3.12d.so.1.0 => HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 (0x00007f9c5d374000) > ??????? libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000) > ??????? libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000) > ??????? libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000) > ??????? libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000) > ??????? libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000) > ??????? /lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000) > If I read the answers I come to the conclusion that the "supporters" at python doesn't ever understand the problem. From hjp-python at hjp.at Mon Dec 16 10:30:53 2024 From: hjp-python at hjp.at (Peter J. Holzer) Date: Mon, 16 Dec 2024 16:30:53 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: <20241216153053.abrlik3xykiq6tqe@hjp.at> On 2024-12-16 08:08:46 +0100, aotto1968 via Python-list wrote: > On 13.12.24 11:36, aotto1968 wrote: > > it's a shame... > > almost every tool I touch that uses "python" in some way has some > > configuration error because apparently a __private__ python installation > > __isn't__ properly "understood". [...] > > If I read the answers I come to the conclusion that the "supporters" at python We are not "the supporters at python". None of us is paid for doing support. Most of us are just users of Python discussing the language and helping each other when we can (some of us are also contributors to Python). > doesn't ever understand the problem. Quite possibly, but in that case you haven't explained it well enough. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From grant.b.edwards at gmail.com Mon Dec 16 14:06:56 2024 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Mon, 16 Dec 2024 14:06:56 -0500 (EST) Subject: it's a shame... python error over error References: Message-ID: <4YBqDw3rJFznVFv@mail.python.org> On 2024-12-16, aotto1968 via Python-list wrote: > If I read the answers I come to the conclusion that the "supporters" > at python doesn't ever understand the problem. You should definitely demand to speak to the manager and request your money back. -- Grant From hugo at python.org Tue Dec 17 11:36:11 2024 From: hugo at python.org (Hugo van Kemenade) Date: Tue, 17 Dec 2024 18:36:11 +0200 Subject: [RELEASE] Python 3.14.0 alpha 3 is out Message-ID: O Alpha 3, O Alpha 3, how lovely are your branches! https://www.python.org/downloads/release/python-3140a3/ This is an early developer preview of Python 3.14. Python 3.14 is still in development. This release, 3.14.0a3, is the third of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649: deferred evaluation of annotations * PEP 741: Python configuration C API * PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. * Improved error messages * (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be 3.14.0a4, currently scheduled for 2025-01-14. More resources: * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different A mince pie is a small, round covered tart filled with ?mincemeat?, usually eaten during the Christmas season ? the UK consumes some 800 million each Christmas. Mincemeat is a mixture of things like apple, dried fruits, candied peel and spices, and originally would have contained meat chopped small, but rarely nowadays. They are often served warm with brandy butter. According to the Oxford English Dictionary, the earliest mention of Christmas mince pies is by Thomas Dekker, writing in the aftermath of the 1603 London plague, in Newes from Graues-end: Sent to Nobody (1604): Ten thousand in London swore to feast their neighbors with nothing but plum-porredge, and mince-pyes all Christmas. Here?s a meaty recipe from Rare and Excellent Receipts, Experienc?d and Taught by Mrs Mary Tillinghast and now Printed for the Use of her Scholars Only (1678): XV. How to make Mince-pies. To every pound of Meat, take two pound of beef Suet, a pound of Corrants, and a quarter of an Ounce of Cinnamon, one Nutmeg, a little beaten Mace, some beaten Colves, a little Sack & Rose-water, two large Pippins, some Orange and Lemon peel cut very thin, and shred very small, a few beaten Carraway-seeds, if you love them the Juyce of half a Lemon squez?d into this quantity of meat; for Sugar, sweeten it to your relish; then mix all these together and fill your Pie. The best meat for Pies is Neats-Tongues, or a leg of Veal; you may make them of a leg of Mutton if you please; the meat must be parboyl?d if you do not spend it presently; but if it be for present use, you may do it raw, and the Pies will be the better. Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a snowy and slippery Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower ?ukasz Langa From garyfallidis at gmail.com Tue Dec 17 15:29:27 2024 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Tue, 17 Dec 2024 15:29:27 -0500 Subject: Join us for the 2025 DIPY Workshop! - March 17-21 Online! - Early Bird Ends Jan 3rd! Message-ID: Dear All, DIPY is a software that analyzes structural and diffusion MRI images using Python. We are excited to invite you to our upcoming DIPY workshop, which will take place from March 17 to March 21, 2025. This year, we promise an enriching experience as we dive into the world of AI in advanced imaging and data analytics. Our distinguished keynote speakers include Prof. Simon Warfield (Harvard Medical School), Prof. Alexandra Badea (Duke University), Prof. Franco Pestilli (University of Texas at Austin), Prof. Marco Palombo (Cardiff University), and Prof. Julien Cohen-Adad (Polytechnique Montreal). Additionally, Koudoro, Descoteaux, Tang, Rokem, Chandio, Fadnavis, Henriques, Legarreta, and others will present various techniques in medical imaging, including (but not limited to) pre-processing, reconstruction, denoising, microstructure modeling, tractography, and visualization. This year?s highlights include the overview of our *new ultra-fast tracking* API by Girard (CPU) and Kruper (GPU) and much more! The DIPY workshop aims to train the next generation of scientists, doctors, and engineers who will shape the future of medical imaging. Your participation will contribute greatly to the success of this event. As is customary for the DIPY workshop, the following will be available: - Daily hands-on sessions for guided practice - Opportunities for attendees to present their work or problems of interest - Certificates of Attendance Please visit our website *here* to register for the workshop. We look forward to your participation and to exploring the exciting work of imaging science together. DIPY is also offering Early Bird discounts until January 3rd, 2025. Register soon to take advantage of these offers! For any concerns, please email *workshop at dipy.org *. On behalf of the DIPY team, Eleftherios Garyfallidis, PhD DIPY Founder & Lead Associate Professor Intelligent Systems Engineering Indiana University Luddy Hall 700 N Woodlawn Bloomington, IN 47408 GRG | DIPY | FURY From torriem at gmail.com Tue Dec 17 23:30:06 2024 From: torriem at gmail.com (Michael Torrie) Date: Tue, 17 Dec 2024 21:30:06 -0700 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 12/16/24 12:08 AM, aotto1968 via Python-list wrote: > If I read the answers I come to the conclusion that the "supporters" at python doesn't ever understand the problem. Sorry you feel that way. Various people gave the best advice they could based on what you had provided. You were given some good advice and even a few very specific things to try to determine the root problem which you don't seem to have done. I've used linux for 30 years and I've never seen a relative path used for a linker search path. What provided this path to the linker? From phd at phdru.name Fri Dec 20 07:58:00 2024 From: phd at phdru.name (Oleg Broytman) Date: Fri, 20 Dec 2024 15:58:00 +0300 Subject: SQLObject 3.12.0 Message-ID: Hello! I'm pleased to announce version 3.12.0, the release of branch 3.12 of SQLObject. What's new in SQLObject ======================= Drivers ------- * Add support for CyMySQL; there're some problems with unicode yet. * Separate ``psycopg`` and ``psycopg2``; ``psycopg`` is actually ``psycopg3`` now; not all tests pass. * Minor fix in getting error code from PyGreSQL. * Dropped ``oursql``. It wasn't updated in years. * Dropped ``PySQLite2``. Only builtin ``sqlite3`` is supported. Tests ----- * Run tests with Python 3.13. * Run tests with ``psycopg-c``; not all tests pass. * Fix ``test_exceptions.py`` under MariaDB, PostgreSQL and SQLite. * ``py-postgres``: Set ``sslmode`` to ``allow``; upstream changed default to ``prefer``. CI -- * Run tests with ``PyGreSQL`` on w32, do not ignore errors. * Skip tests with ``pg8000`` on w32. * GHActions: Switch to ``setup-miniconda``. * GHActions: Python 3.13. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject ================= SQLObject is a free and open-source (LGPL) Python object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL/MariaDB (with a number of DB API drivers: ``MySQLdb``, ``mysqlclient``, ``mysql-connector``, ``PyMySQL``, ``mariadb``), PostgreSQL (``psycopg2``, ``PyGreSQL``, partially ``pg8000`` and ``py-postgresql``), SQLite (builtin ``sqlite3``); connections to other backends - Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB) - are less debugged). Python 2.7 or 3.4+ is required. Where is SQLObject ================== Site: http://sqlobject.org Download: https://pypi.org/project/SQLObject/3.12.0 News and changes: http://sqlobject.org/News.html StackOverflow: https://stackoverflow.com/questions/tagged/sqlobject Mailing lists: https://sourceforge.net/p/sqlobject/mailman/ Development: http://sqlobject.org/devel/ Developer Guide: http://sqlobject.org/DeveloperGuide.html Example ======= Install:: $ pip install sqlobject Create a simple class that wraps a table:: >>> from sqlobject import * >>> >>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:') >>> >>> class Person(SQLObject): ... fname = StringCol() ... mi = StringCol(length=1, default=None) ... lname = StringCol() ... >>> Person.createTable() Use the object:: >>> p = Person(fname="John", lname="Doe") >>> p >>> p.fname 'John' >>> p.mi = 'Q' >>> p2 = Person.get(1) >>> p2 >>> p is p2 True Queries:: >>> p3 = Person.selectBy(lname="Doe")[0] >>> p3 >>> pc = Person.select(Person.q.lname=="Doe").count() >>> pc 1 Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From oscar.j.benjamin at gmail.com Sun Dec 22 18:32:30 2024 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Sun, 22 Dec 2024 23:32:30 +0000 Subject: Lengthy numbers In-Reply-To: References: Message-ID: On Sun, 22 Dec 2024 at 19:17, Gilmeh Serda via Python-list wrote: > > Was just playing with numbers and stumbled on something I've never seen > before. ... > > >>> 9**9**4 > Traceback (most recent call last): > File "", line 1, in > ValueError: Exceeds the limit (4300 digits) for integer string conversion; > use sys.set_int_max_str_digits() to increase the limit > > Explanation: > https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889 I think that the original security concern was mainly motivated by the string to int direction i.e. calling int(s) for a possibly large string s (possibly from an untrusted source) might be slow with CPython. To solve that problem conversions from string->int and int->string were disallowed. Now that more time has passed it becomes clearer that disabling int->string conversion is more likely to be the thing that people bump into as a result of this limitation (as you just did). I find it harder to see what the security problem is in that direction but I don't think this will be changed. CPython has an implementation of arbitrarily large integers but an important part of it is hobbled. If you do want to work with such large integers then I recommend using either gmpy2's gmpy2.mpz type or python-flint's flint.fmpz type. At the same time it is not hard to run into slowness with integers e.g. 10**10**10 but that won't come up in string parsing if not using eval. Not a likely security issue but I am suddenly reminded of this dangerous snippet: x = [0]; x.extend(iter(x)) If you want to test it then make sure to save your work etc and be prepared to hard reset the computer. On this machine Ctrl-C doesn't work for this but Ctrl-\ does if you do it quick enough. -- Oscar From mohammadrezasaveji at gmail.com Sun Dec 22 08:10:40 2024 From: mohammadrezasaveji at gmail.com (Mohammadreza Saveji) Date: Sun, 22 Dec 2024 16:40:40 +0330 Subject: SQLObject 3.12.0 In-Reply-To: References: Message-ID: thank a lot Oleg. have a nice day. On Fri, Dec 20, 2024 at 4:56?PM Oleg Broytman via Python-list < python-list at python.org> wrote: > Hello! > > I'm pleased to announce version 3.12.0, the release of branch > 3.12 of SQLObject. > > > What's new in SQLObject > ======================= > > Drivers > ------- > > * Add support for CyMySQL; there're some problems with unicode yet. > > * Separate ``psycopg`` and ``psycopg2``; > ``psycopg`` is actually ``psycopg3`` now; not all tests pass. > > * Minor fix in getting error code from PyGreSQL. > > * Dropped ``oursql``. It wasn't updated in years. > > * Dropped ``PySQLite2``. Only builtin ``sqlite3`` is supported. > > Tests > ----- > > * Run tests with Python 3.13. > > * Run tests with ``psycopg-c``; not all tests pass. > > * Fix ``test_exceptions.py`` under MariaDB, PostgreSQL and SQLite. > > * ``py-postgres``: Set ``sslmode`` to ``allow``; > upstream changed default to ``prefer``. > > CI > -- > > * Run tests with ``PyGreSQL`` on w32, do not ignore errors. > > * Skip tests with ``pg8000`` on w32. > > * GHActions: Switch to ``setup-miniconda``. > > * GHActions: Python 3.13. > > For a more complete list, please see the news: > http://sqlobject.org/News.html > > > What is SQLObject > ================= > > SQLObject is a free and open-source (LGPL) Python object-relational > mapper. Your database tables are described as classes, and rows are > instances of those classes. SQLObject is meant to be easy to use and > quick to get started with. > > SQLObject supports a number of backends: MySQL/MariaDB (with a number of > DB API drivers: ``MySQLdb``, ``mysqlclient``, ``mysql-connector``, > ``PyMySQL``, ``mariadb``), PostgreSQL (``psycopg2``, ``PyGreSQL``, > partially ``pg8000`` and ``py-postgresql``), SQLite (builtin ``sqlite3``); > connections to other backends > - Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB) - are less > debugged). > > Python 2.7 or 3.4+ is required. > > > Where is SQLObject > ================== > > Site: > http://sqlobject.org > > Download: > https://pypi.org/project/SQLObject/3.12.0 > > News and changes: > http://sqlobject.org/News.html > > StackOverflow: > https://stackoverflow.com/questions/tagged/sqlobject > > Mailing lists: > https://sourceforge.net/p/sqlobject/mailman/ > > Development: > http://sqlobject.org/devel/ > > Developer Guide: > http://sqlobject.org/DeveloperGuide.html > > > Example > ======= > > Install:: > > $ pip install sqlobject > > Create a simple class that wraps a table:: > > >>> from sqlobject import * > >>> > >>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:') > >>> > >>> class Person(SQLObject): > ... fname = StringCol() > ... mi = StringCol(length=1, default=None) > ... lname = StringCol() > ... > >>> Person.createTable() > > Use the object:: > > >>> p = Person(fname="John", lname="Doe") > >>> p > > >>> p.fname > 'John' > >>> p.mi = 'Q' > >>> p2 = Person.get(1) > >>> p2 > > >>> p is p2 > True > > Queries:: > > >>> p3 = Person.selectBy(lname="Doe")[0] > >>> p3 > > >>> pc = Person.select(Person.q.lname=="Doe").count() > >>> pc > 1 > > Oleg. > -- > Oleg Broytman https://phdru.name/ phd at phdru.name > Programmers don't die, they just GOSUB without RETURN. > -- > https://mail.python.org/mailman/listinfo/python-list > From mk1853387 at gmail.com Tue Dec 24 12:27:21 2024 From: mk1853387 at gmail.com (marc nicole) Date: Tue, 24 Dec 2024 18:27:21 +0100 Subject: How to go about describing my software with a component diagram? Message-ID: Hello community, I have created a Python code where a main algorithm uses three different modules (.py) after importing them. To illustrate and describe it I have created the following component diagram? [image: checkso.PNG] Could it be improved for better description and readability? Thanks! From mk1853387 at gmail.com Tue Dec 24 12:27:59 2024 From: mk1853387 at gmail.com (marc nicole) Date: Tue, 24 Dec 2024 18:27:59 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: the diagram is also attached here Le mar. 24 d?c. 2024 ? 18:27, marc nicole a ?crit : > Hello community, > > I have created a Python code where a main algorithm uses three different > modules (.py) after importing them. > > To illustrate and describe it I have created the following component > diagram? > > > [image: checkso.PNG] > > Could it be improved for better description and readability? > > > Thanks! > From torriem at gmail.com Tue Dec 24 14:00:23 2024 From: torriem at gmail.com (Michael Torrie) Date: Tue, 24 Dec 2024 12:00:23 -0700 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: On 12/24/24 10:27 AM, marc nicole via Python-list wrote: > the diagram is also attached here This text-only mailing list does not allow attachments, just FYI. From mk1853387 at gmail.com Tue Dec 24 15:42:23 2024 From: mk1853387 at gmail.com (marc nicole) Date: Tue, 24 Dec 2024 21:42:23 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: it is here https://i.sstatic.net/ykk5Wd0w.png Le mar. 24 d?c. 2024 ? 20:03, Michael Torrie via Python-list < python-list at python.org> a ?crit : > On 12/24/24 10:27 AM, marc nicole via Python-list wrote: > > the diagram is also attached here > > This text-only mailing list does not allow attachments, just FYI. > > -- > https://mail.python.org/mailman/listinfo/python-list > From PythonList at DancesWithMice.info Tue Dec 24 15:49:03 2024 From: PythonList at DancesWithMice.info (dn) Date: Wed, 25 Dec 2024 09:49:03 +1300 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: On 25/12/24 08:00, Michael Torrie via Python-list wrote: > On 12/24/24 10:27 AM, marc nicole via Python-list wrote: >> the diagram is also attached here > > This text-only mailing list does not allow attachments, just FYI. Many devs use Markdown (or similar) text-only file-formats for technical documentation. A tool for including block-graphics in these is "Mermaid" (https://mermaid.js.org/intro/). -- Regards, =dn From PythonList at DancesWithMice.info Tue Dec 24 15:46:43 2024 From: PythonList at DancesWithMice.info (dn) Date: Wed, 25 Dec 2024 09:46:43 +1300 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: On 25/12/24 06:27, marc nicole via Python-list wrote: > Hello community, > > I have created a Python code where a main algorithm uses three different > modules (.py) after importing them. > > To illustrate and describe it I have created the following component > diagram? > > > [image: checkso.PNG] > > Could it be improved for better description and readability? Possibly - so little detail as to topic and any hints in the diagram redacted! What messages do you want to communicate with this diagram? Given that the three modules are subordinate contributors to the script/algorithm, place the three modules inside a larger "Algorithm" shape. -- Regards, =dn From mk1853387 at gmail.com Tue Dec 24 16:05:35 2024 From: mk1853387 at gmail.com (marc nicole) Date: Tue, 24 Dec 2024 22:05:35 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: I want to convey the idea that main.py (main algorithm) imports 3 modules (V, S, M) (each of them containing .py scripts related to different functionalities) and use their methods accordingly as per the requirement: basically the structure of my code and how the modules relate to each other. Le mar. 24 d?c. 2024 ? 21:56, dn via Python-list a ?crit : > On 25/12/24 06:27, marc nicole via Python-list wrote: > > Hello community, > > > > I have created a Python code where a main algorithm uses three different > > modules (.py) after importing them. > > > > To illustrate and describe it I have created the following component > > diagram? > > > > > > [image: checkso.PNG] > > > > Could it be improved for better description and readability? > > > Possibly - so little detail as to topic and any hints in the diagram > redacted! What messages do you want to communicate with this diagram? > > Given that the three modules are subordinate contributors to the > script/algorithm, place the three modules inside a larger "Algorithm" > shape. > > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list > From mk1853387 at gmail.com Tue Dec 24 16:08:42 2024 From: mk1853387 at gmail.com (marc nicole) Date: Tue, 24 Dec 2024 22:08:42 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: The full python package (pypi) being represented as the outermost frame here including the 4 sub-frames) Le mar. 24 d?c. 2024 ? 22:05, marc nicole a ?crit : > I want to convey the idea that main.py (main algorithm) imports 3 modules > (V, S, M) (each of them containing .py scripts related to > different functionalities) and use their methods accordingly as per the > requirement: basically the structure of my code and how the modules relate > to each other. > > Le mar. 24 d?c. 2024 ? 21:56, dn via Python-list > a ?crit : > >> On 25/12/24 06:27, marc nicole via Python-list wrote: >> > Hello community, >> > >> > I have created a Python code where a main algorithm uses three different >> > modules (.py) after importing them. >> > >> > To illustrate and describe it I have created the following component >> > diagram? >> > >> > >> > [image: checkso.PNG] >> > >> > Could it be improved for better description and readability? >> >> >> Possibly - so little detail as to topic and any hints in the diagram >> redacted! What messages do you want to communicate with this diagram? >> >> Given that the three modules are subordinate contributors to the >> script/algorithm, place the three modules inside a larger "Algorithm" >> shape. >> >> -- >> Regards, >> =dn >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > From list1 at tompassin.net Tue Dec 24 16:44:26 2024 From: list1 at tompassin.net (Thomas Passin) Date: Tue, 24 Dec 2024 16:44:26 -0500 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: On 12/24/2024 4:08 PM, marc nicole via Python-list wrote: > The full python package (pypi) being represented as the outermost frame > here including the 4 sub-frames) > > Le mar. 24 d?c. 2024 ? 22:05, marc nicole a ?crit : > >> I want to convey the idea that main.py (main algorithm) imports 3 modules >> (V, S, M) (each of them containing .py scripts related to >> different functionalities) and use their methods accordingly as per the >> requirement: basically the structure of my code and how the modules relate >> to each other. As is, the diagram doesn't convey any of that. For example, main.py is a program, not an algorithm. we can't tell that main.py imports three modules. They might just as well be internal classes. If you want to communicate something you need to say or show what that thing is. This might be close to what you have said (I only show 2 of the 3 modules and I didn't have the page width for the bottom left-hand label) - ------------ | main.py | --implements--> Agorithm A ------------ / \ imports imports | | ? ? --------- -------- | V.py | | S.py | --implements--> Subalgorithm A.2 --------- -------- >> Le mar. 24 d?c. 2024 ? 21:56, dn via Python-list >> a ?crit : >> >>> On 25/12/24 06:27, marc nicole via Python-list wrote: >>>> Hello community, >>>> >>>> I have created a Python code where a main algorithm uses three different >>>> modules (.py) after importing them. >>>> >>>> To illustrate and describe it I have created the following component >>>> diagram? >>>> >>>> >>>> [image: checkso.PNG] >>>> >>>> Could it be improved for better description and readability? >>> >>> >>> Possibly - so little detail as to topic and any hints in the diagram >>> redacted! What messages do you want to communicate with this diagram? >>> >>> Given that the three modules are subordinate contributors to the >>> script/algorithm, place the three modules inside a larger "Algorithm" >>> shape. >>> >>> -- >>> Regards, >>> =dn >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> >> From george at fischhof.hu Tue Dec 24 17:00:26 2024 From: george at fischhof.hu (George Fischhof) Date: Tue, 24 Dec 2024 23:00:26 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: marc nicole via Python-list ezt ?rta (id?pont: 2024. dec. 24., K 22:09): > The full python package (pypi) being represented as the outermost frame > here including the 4 sub-frames) > > Le mar. 24 d?c. 2024 ? 22:05, marc nicole a ?crit : > > > I want to convey the idea that main.py (main algorithm) imports 3 modules > > (V, S, M) (each of them containing .py scripts related to > > different functionalities) and use their methods accordingly as per the > > requirement: basically the structure of my code and how the modules > relate > > to each other. > > > > Le mar. 24 d?c. 2024 ? 21:56, dn via Python-list > > > a ?crit : > > > >> On 25/12/24 06:27, marc nicole via Python-list wrote: > >> > Hello community, > >> > > >> > I have created a Python code where a main algorithm uses three > different > >> > modules (.py) after importing them. > >> > > >> > To illustrate and describe it I have created the following component > >> > diagram? > >> > > >> > > >> > [image: checkso.PNG] > >> > > >> > Could it be improved for better description and readability? > >> > >> > >> Possibly - so little detail as to topic and any hints in the diagram > >> redacted! What messages do you want to communicate with this diagram? > >> > >> Given that the three modules are subordinate contributors to the > >> script/algorithm, place the three modules inside a larger "Algorithm" > >> shape. > >> > >> -- > >> Regards, > >> =dn > >> -- > >> https://mail.python.org/mailman/listinfo/python-list > >> > > > -- > https://mail.python.org/mailman/listinfo/python-list Hi, also there are some tools which can generate class hierarchy diagram from code. for example here is a post https://stackoverflow.com/questions/77421030/how-to-generate-the-uml-diagram-from-the-python-code pyreverse is now part of pylint if I remember well. BR George > > From list1 at tompassin.net Tue Dec 24 16:18:54 2024 From: list1 at tompassin.net (Thomas Passin) Date: Tue, 24 Dec 2024 16:18:54 -0500 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: Message-ID: <0c3c9d66-39a2-491c-9e86-9c9cd6df814a@tompassin.net> On 12/24/2024 3:42 PM, marc nicole via Python-list wrote: > it is here https://i.sstatic.net/ykk5Wd0w.png This diagram does not make much sense to me: 1. What is the purpose of the diagram and who is it intended for? 2. A module and an algorithm are different kinds of things, yet they are connected together as if they are the same. 3. Connecting lines should always be labeled, preferably with direction indicators that augment the labels. Otherwise the viewer has to imagine what the nature of the connection is. 4. It's better if different kinds of things look different. That could be a different box shape, a different color, or some other visual difference. Here I am thinking about the box labeled "Algorithm". We can't tell if it is intended to mean "A library module that implements a certain algorithm", "An algorithm that the three components cooperate to implement", "The top-level module for computing an algorithm that contains three modules", or something else. From mk1853387 at gmail.com Wed Dec 25 05:08:30 2024 From: mk1853387 at gmail.com (marc nicole) Date: Wed, 25 Dec 2024 11:08:30 +0100 Subject: How to go about describing my software with a component diagram? In-Reply-To: <0c3c9d66-39a2-491c-9e86-9c9cd6df814a@tompassin.net> References: <0c3c9d66-39a2-491c-9e86-9c9cd6df814a@tompassin.net> Message-ID: the purpose of the diagram is to convey a minimalistic idea about the structure of the code/implementation/software Le mer. 25 d?c. 2024 ? 01:49, Thomas Passin via Python-list < python-list at python.org> a ?crit : > On 12/24/2024 3:42 PM, marc nicole via Python-list wrote: > > it is here https://i.sstatic.net/ykk5Wd0w.png > > This diagram does not make much sense to me: > > 1. What is the purpose of the diagram and who is it intended for? > 2. A module and an algorithm are different kinds of things, yet they are > connected together as if they are the same. > 3. Connecting lines should always be labeled, preferably with direction > indicators that augment the labels. Otherwise the viewer has to imagine > what the nature of the connection is. > 4. It's better if different kinds of things look different. That could > be a different box shape, a different color, or some other visual > difference. Here I am thinking about the box labeled "Algorithm". We > can't tell if it is intended to mean "A library module that implements a > certain algorithm", "An algorithm that the three components cooperate to > implement", "The top-level module for computing an algorithm that > contains three modules", or something else. > > -- > https://mail.python.org/mailman/listinfo/python-list > From arj.python at gmail.com Wed Dec 25 05:52:23 2024 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Wed, 25 Dec 2024 14:52:23 +0400 Subject: Python List is Not Dead Message-ID: Hey all, I have been following discussions on Discourse (discuss.python.org) these last times. I think that it definitely lacks some of the joys of the mailing list: 1/ Categories The discussion has fixed categories. No channel for fun posts, project releases or musings. 2/ Ui Good luck getting to the bottom of big threads. Hello JS! PS. You can but it's not intuitive. 3/ Quality I find great posts here and there on the mailing list. I can't seem to find great posts over there. Just sharing my POV. I like the mailing list ^^, Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From sch at fedora.email Wed Dec 25 08:45:38 2024 From: sch at fedora.email (Schimon Jehudah) Date: Wed, 25 Dec 2024 15:45:38 +0200 Subject: Python List is Not Dead In-Reply-To: References: Message-ID: <20241225154538.43e31c5c@workstation.localdomain> Abdur-Rahmaan. Good afternoon! I think, that if project Discourse would want to preserve and increase its popularity, then it should realize XMPP PubSub to communicate and manage posts, which is what project Libervia will do in near future. I use BitMessage, Email, LXMF, MQTT, and XMPP to communicate messsages, BBS, BitTorrent, eDonkey2000 and Gnutella to transfer files, and I recently have started to use Gemini and Gopher. HTML sites, with JS, are almost always result in wasting of time, and life is better without HTML browsers. I do not use HTML browsers anymore. Best regards, Schimon On Wed, 25 Dec 2024 14:52:23 +0400 Abdur-Rahmaan Janhangeer via Python-list wrote: > Hey all, > > I have been following discussions on Discourse (discuss.python.org) > these last times. > > I think that it definitely lacks some of the joys of the mailing list: > > 1/ Categories > > The discussion has fixed categories. No channel for fun posts, > project releases or musings. > > 2/ Ui > > Good luck getting to the bottom of big threads. Hello JS! > > PS. You can but it's not intuitive. > > 3/ Quality > > I find great posts here and there on the mailing list. I can't seem > to find great posts over there. > > Just sharing my POV. I like the mailing list ^^, > > Kind Regards, > > Abdur-Rahmaan Janhangeer > about | blog > > github > Mauritius From PythonList at DancesWithMice.info Wed Dec 25 14:29:53 2024 From: PythonList at DancesWithMice.info (dn) Date: Thu, 26 Dec 2024 08:29:53 +1300 Subject: How to go about describing my software with a component diagram? In-Reply-To: References: <0c3c9d66-39a2-491c-9e86-9c9cd6df814a@tompassin.net> Message-ID: <0a94d6aa-b034-4e61-85ac-8e3eecc0323e@DancesWithMice.info> On 25/12/24 10:05, marc nicole wrote: > I want to convey the idea that main.py (main algorithm) imports 3 > modules (V, S, M) (each of them containing .py scripts related to > different functionalities) and use their methods accordingly as per the > requirement: basically the structure of my code and how the modules > relate to each other. On 25/12/24 23:08, marc nicole via Python-list wrote: > the purpose of the diagram is to convey a minimalistic idea about the > structure of the code/implementation/software In which case, and assuming the "algorithm" is the application's script, what will the diagram say that is not conveyed by the three import statements which (almost) head-up the script? The difficulty you are presenting to respondents (and to eventual readers) is the paucity of information: block-labels, line/arrow labels, diagram title, expected reader(s), ... PS would it be better to keep the conversation to one Discussion List? > Le mer. 25 d?c. 2024 ? 01:49, Thomas Passin via Python-list < > python-list at python.org> a ?crit : > >> On 12/24/2024 3:42 PM, marc nicole via Python-list wrote: >>> it is here https://i.sstatic.net/ykk5Wd0w.png >> >> This diagram does not make much sense to me: >> >> 1. What is the purpose of the diagram and who is it intended for? >> 2. A module and an algorithm are different kinds of things, yet they are >> connected together as if they are the same. >> 3. Connecting lines should always be labeled, preferably with direction >> indicators that augment the labels. Otherwise the viewer has to imagine >> what the nature of the connection is. >> 4. It's better if different kinds of things look different. That could >> be a different box shape, a different color, or some other visual >> difference. Here I am thinking about the box labeled "Algorithm". We >> can't tell if it is intended to mean "A library module that implements a >> certain algorithm", "An algorithm that the three components cooperate to >> implement", "The top-level module for computing an algorithm that >> contains three modules", or something else. >> >> -- >> https://mail.python.org/mailman/listinfo/python-list >> -- Regards, =dn From aotto1968 at t-online.de Wed Dec 25 06:05:18 2024 From: aotto1968 at t-online.de (aotto1968) Date: Wed, 25 Dec 2024 12:05:18 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: I get angry? next python error? 1) The OpenSUSE command "cnf" checks if a special package feature is installed. 2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3 project directory and never changed the OpenSUSE installation. 3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s own "Python" and "Sqlite3" software. 4) Now the "cnf" fails with "Python" which apparently tries to use **my** SQLite3. > what a shame. > cnf jmc Traceback (most recent call last): File "/usr/bin/cnf", line 9, in import scout File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in import sqlite3 File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in from sqlite3.dbapi2 import * File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in from _sqlite3 import * ImportError: /usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_trace From aotto1968 at t-online.de Wed Dec 25 06:20:52 2024 From: aotto1968 at t-online.de (aotto1968) Date: Wed, 25 Dec 2024 12:20:52 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 25.12.24 12:05, aotto1968 wrote: > I get angry? > > next python error? > > 1) The OpenSUSE command "cnf" checks if a special package feature is installed. > 2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3 > project directory and never changed the OpenSUSE installation. > 3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s > own "Python" and "Sqlite3" software. > 4) Now the "cnf" fails with "Python" which apparently tries to use **my** SQLite3. > > > what a shame. > > > > cnf jmc > Traceback (most recent call last): > ? File "/usr/bin/cnf", line 9, in > ??? import scout > ? File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in > ??? import sqlite3 > ? File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in > ??? from sqlite3.dbapi2 import * > ? File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in > ??? from _sqlite3 import * > ImportError: /usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_trace > It is not only an *usage* error it is also an *security* error because: 1) "cnf" is using OS python > head /usr/bin/cnf #!/usr/bin/python3 import gettext import os ... 2) os "root" python > ls -al /usr/bin/python3 lrwxrwxrwx 1 root root 9 2. Dez 13:16 /usr/bin/python3 -> python3.6 > ls -al /usr/bin/python3.6 -rwxr-xr-x 2 root root 10560 2. Dez 13:16 /usr/bin/python3.6 3) using **my** local non-root library > ls -al NHI1_EXT/lib64/libsqlite3.so.0 lrwxrwxrwx 1 dev1usr users 19 23. Dez 22:09 NHI1_EXT/lib64/libsqlite3.so.0 -> libsqlite3.so.0.8.6 > ls -al NHI1_EXT/lib64/libsqlite3.so.0.8.6 -rwxr-xr-x 1 dev1usr users 3851872 23. Dez 22:09 NHI1_EXT/lib64/libsqlite3.so.0.8.6 From rosuav at gmail.com Wed Dec 25 17:55:30 2024 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 26 Dec 2024 09:55:30 +1100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list wrote: > It is not only an *usage* error it is also an *security* error because: > > 1) "cnf" is using OS python > 2) os "root" python > 3) using **my** local non-root library Yes. And YOU were the one who installed a new root Python. This is a feature. You have the power to update Python on your system. You managed to make a build of Python that attempts to link to a DLL using a relative path. That's a fault of the build that means it won't work as root. I don't understand the confusion here; isn't the solution here to build a new version with an absolute path, and update your installation? ChrisA From torriem at gmail.com Wed Dec 25 22:55:47 2024 From: torriem at gmail.com (Michael Torrie) Date: Wed, 25 Dec 2024 20:55:47 -0700 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote: > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list > wrote: >> It is not only an *usage* error it is also an *security* error because: >> >> 1) "cnf" is using OS python >> 2) os "root" python >> 3) using **my** local non-root library I think he means the cnf is using the "root" OS python in /usr/bin, but /usr/bin/python3 is trying to import his local build of sqlite3, which cause it to fail. I assume he would like cnf to not try to import his local sqlite3, and instead use the normal system one. If this is the case, then somehow his local, non-root sqlite3 library is being picked up by the system version of python. Aotto might want to run the "env" command and see if there are any search paths that have to do with Python. I can see how this could be a security issue. If you can figure out what's happening you might want to open a ticket with the OpenSUSE developers. This is Python related, but it's not necessarily python's fault per se. From torriem at gmail.com Wed Dec 25 22:57:26 2024 From: torriem at gmail.com (Michael Torrie) Date: Wed, 25 Dec 2024 20:57:26 -0700 Subject: it's a shame... python error over error In-Reply-To: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: On 12/25/24 8:55 PM, Michael Torrie wrote: > This is Python related, but > it's not necessarily python's fault per se. It's also a good reminder to use venv. Then there's no way of activating your custom python with its custom sqlite3 library unless you explicitly activate the venv. From rosuav at gmail.com Thu Dec 26 00:46:26 2024 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 26 Dec 2024 16:46:26 +1100 Subject: it's a shame... python error over error In-Reply-To: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list wrote: > > On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote: > > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list > > wrote: > >> It is not only an *usage* error it is also an *security* error because: > >> > >> 1) "cnf" is using OS python > >> 2) os "root" python > >> 3) using **my** local non-root library > > I think he means the cnf is using the "root" OS python in /usr/bin, but > /usr/bin/python3 is trying to import his local build of sqlite3, which > cause it to fail. I assume he would like cnf to not try to import his > local sqlite3, and instead use the normal system one. If this is the > case, then somehow his local, non-root sqlite3 library is being picked > up by the system version of python. Right. That's exactly what would happen if he'd built Python using absolute paths to libraries, which is the normal way to do it. And so the solution is to rebuild Python using absolute paths to libraries. ChrisA From PythonList at DancesWithMice.info Thu Dec 26 12:22:54 2024 From: PythonList at DancesWithMice.info (dn) Date: Fri, 27 Dec 2024 06:22:54 +1300 Subject: Python List is Not Dead In-Reply-To: References: Message-ID: On 25/12/24 23:52, Abdur-Rahmaan Janhangeer via Python-list wrote: > Hey all, > > I have been following discussions on Discourse (discuss.python.org) these > last times. > > I think that it definitely lacks some of the joys of the mailing list: > > 1/ Categories > > The discussion has fixed categories. No channel for fun posts, project > releases or musings. > > 2/ Ui > > Good luck getting to the bottom of big threads. Hello JS! > > PS. You can but it's not intuitive. +1 Also, as a conversation develops, irrelevant posts which don't add utility can be deleted making review easier. Issues/complaints raised about any communication medium are rarely solved by moving to some other. They typically relate to the way humans use the facility. The gossip-side of social media is an evident race for the bottom. Many (semi-)professional channels are infected by peoples' assumptions of similarity. Also, do I need to discuss the way so many people ask for help but give minimum assistance to their hoped-for respondents? https://www.catb.org/~esr/faqs/smart-questions.html ... -- Regards, =dn From torriem at gmail.com Thu Dec 26 13:33:29 2024 From: torriem at gmail.com (Michael Torrie) Date: Thu, 26 Dec 2024 11:33:29 -0700 Subject: it's a shame... python error over error In-Reply-To: References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: <0c9e650c-1789-ff47-cf5d-ee319d19602f@gmail.com> On 12/25/24 10:46 PM, Chris Angelico wrote: > Right. That's exactly what would happen if he'd built Python using > absolute paths to libraries, which is the normal way to do it. And so > the solution is to rebuild Python using absolute paths to libraries. You're right. Definitely appears to be a pretty major mis-configuration of his system. Not much we can do about that. From cs at cskk.id.au Thu Dec 26 17:47:34 2024 From: cs at cskk.id.au (Cameron Simpson) Date: Fri, 27 Dec 2024 09:47:34 +1100 Subject: Python List is Not Dead In-Reply-To: References: Message-ID: On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer wrote: >I have been following discussions on Discourse (discuss.python.org) >these last times. > >I think that it definitely lacks some of the joys of the mailing list: FYI, it has a very good "mailing list" mode. I use it that was >90% of the time, and file both posts from Discourse and posts from python-list into my "python" mail folder. From mohammadrezasaveji at gmail.com Fri Dec 27 15:53:14 2024 From: mohammadrezasaveji at gmail.com (Mohammadreza Saveji) Date: Sat, 28 Dec 2024 00:23:14 +0330 Subject: Python List is Not Dead In-Reply-To: References: Message-ID: thank you Mr. Jahangir. you are expert in python. On Fri, Dec 27, 2024 at 2:28?AM Cameron Simpson via Python-list < python-list at python.org> wrote: > On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer wrote: > >I have been following discussions on Discourse (discuss.python.org) > >these last times. > > > >I think that it definitely lacks some of the joys of the mailing list: > > FYI, it has a very good "mailing list" mode. I use it that was >90% of > the time, and file both posts from Discourse and posts from python-list > into my "python" mail folder. > -- > https://mail.python.org/mailman/listinfo/python-list > From kevinmwilson1956 at yahoo.com Sun Dec 29 02:16:43 2024 From: kevinmwilson1956 at yahoo.com (Kevin M. Wilson) Date: Sun, 29 Dec 2024 07:16:43 +0000 (UTC) Subject: Python List is Not Dead In-Reply-To: References: Message-ID: <1931923627.7822421.1735456603409@mail.yahoo.com> Excuse please, my failure. As I have not been following this discussion, why is the subject?"Python List Is NOT Dead" a subject for discussion? Has the list been moving towards?closing? KMW *************************************************** "When you pass through the waters, I will be with you: and when you?pass through the rivers, they will not sweep over?you. When?you walk?through the fire, you will not be burned: the flames will not set you ablaze."? ? ? Isaiah 43:2 On Saturday, December 28, 2024 at 05:37:34 AM MST, Mohammadreza Saveji via Python-list wrote: thank you Mr. Jahangir. you are expert in python. On Fri, Dec 27, 2024 at 2:28?AM Cameron Simpson via Python-list < python-list at python.org> wrote: > On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer wrote: > >I have been following discussions on Discourse (discuss.python.org) > >these last times. > > > >I think that it definitely lacks some of the joys of the mailing list: > > FYI, it has a very good "mailing list" mode. I use it that was >90% of > the time, and file both posts from Discourse and posts from python-list > into my "python" mail folder. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list From cs at cskk.id.au Sun Dec 29 17:10:59 2024 From: cs at cskk.id.au (Cameron Simpson) Date: Mon, 30 Dec 2024 09:10:59 +1100 Subject: Python List is Not Dead In-Reply-To: <1931923627.7822421.1735456603409@mail.yahoo.com> References: <1931923627.7822421.1735456603409@mail.yahoo.com> Message-ID: On 29Dec2024 07:16, Kevin M. Wilson wrote: >Excuse please, my failure. As I have not been following this discussion, why is the subject?"Python List Is NOT Dead" a subject for discussion? Has the list been moving towards?closing? No, the list's still around. But there was a significant migration to https://discuss.python.org/ which is a web forum running Discourse some time back, so python-list is a lot quieter these days. From mats at wichmann.us Sun Dec 29 19:39:09 2024 From: mats at wichmann.us (Mats Wichmann) Date: Sun, 29 Dec 2024 17:39:09 -0700 Subject: Python List is Not Dead In-Reply-To: References: <1931923627.7822421.1735456603409@mail.yahoo.com> Message-ID: <95e9953e-dece-432f-8ba1-d6a7849e3b8b@wichmann.us> On 12/29/24 15:10, Cameron Simpson via Python-list wrote: > On 29Dec2024 07:16, Kevin M. Wilson wrote: >> Excuse please, my failure. As I have not been following this >> discussion, why is the subject?"Python List Is NOT Dead" a subject for >> discussion? Has the list been moving towards?closing? > > No, the list's still around. But there was a significant migration to > https://discuss.python.org/ which is a web forum running Discourse some > time back, so python-list is a lot quieter these days. It's the somewhat parallel python-dev list that went away. This list still exists, but is now pretty low volume. From aotto1968 at t-online.de Thu Dec 26 02:34:43 2024 From: aotto1968 at t-online.de (aotto1968) Date: Thu, 26 Dec 2024 08:34:43 +0100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 25.12.24 23:55, Chris Angelico wrote: > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list > wrote: >> It is not only an *usage* error it is also an *security* error because: >> >> 1) "cnf" is using OS python >> 2) os "root" python >> 3) using **my** local non-root library > > Yes. And YOU were the one who installed a new root Python. This is a > feature. You have the power to update Python on your system. > > You managed to make a build of Python that attempts to link to a DLL > using a relative path. That's a fault of the build that means it won't > work as root. I don't understand the confusion here; isn't the > solution here to build a new version with an absolute path, and update > your installation? > > ChrisA sorry you don't understand the problem? > You managed to make a build of Python that attempts to link to a DLL I never touch the OpenSUSE python. the OpenSUSE python try to use my sqalite3. From aotto1968 at t-online.de Thu Dec 26 02:35:59 2024 From: aotto1968 at t-online.de (aotto1968) Date: Thu, 26 Dec 2024 08:35:59 +0100 Subject: it's a shame... python error over error In-Reply-To: References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: On 26.12.24 06:46, Chris Angelico wrote: > On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list > wrote: >> >> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote: >>> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list >>> wrote: >>>> It is not only an *usage* error it is also an *security* error because: >>>> >>>> 1) "cnf" is using OS python >>>> 2) os "root" python >>>> 3) using **my** local non-root library >> >> I think he means the cnf is using the "root" OS python in /usr/bin, but >> /usr/bin/python3 is trying to import his local build of sqlite3, which >> cause it to fail. I assume he would like cnf to not try to import his >> local sqlite3, and instead use the normal system one. If this is the >> case, then somehow his local, non-root sqlite3 library is being picked >> up by the system version of python. > > Right. That's exactly what would happen if he'd built Python using > absolute paths to libraries, which is the normal way to do it. And so > the solution is to rebuild Python using absolute paths to libraries. > > ChrisA next I don't change the OpenSUSE python and the OpenSUSE python is using *my* sqlite3. From aotto1968 at t-online.de Thu Dec 26 02:42:08 2024 From: aotto1968 at t-online.de (aotto1968) Date: Thu, 26 Dec 2024 08:42:08 +0100 Subject: it's a shame... python error over error In-Reply-To: References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: On 26.12.24 04:55, Michael Torrie wrote: > On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote: >> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list >> wrote: >>> It is not only an *usage* error it is also an *security* error because: >>> >>> 1) "cnf" is using OS python >>> 2) os "root" python >>> 3) using **my** local non-root library > > I think he means the cnf is using the "root" OS python in /usr/bin, but > /usr/bin/python3 is trying to import his local build of sqlite3, which > cause it to fail. I assume he would like cnf to not try to import his > local sqlite3, and instead use the normal system one. If this is the > case, then somehow his local, non-root sqlite3 library is being picked > up by the system version of python. > > Aotto might want to run the "env" command and see if there are any > search paths that have to do with Python. I can see how this could be a > security issue. If you can figure out what's happening you might want to > open a ticket with the OpenSUSE developers. This is Python related, but > it's not necessarily python's fault per se. Yes I using with *my* user *my* environment but never touch the *root* environment at all. the *root* python try to use *my* sqlite3 because *my* environment fit to *my* needs. /* just a reminder */ sqlite3 have a "special" (worse) setup that a change to the configuration also change the "api" ( a sqlite_function disappear or arrive ). If a tool like python using an extension that is linked to sqlite3 that extension will likely FAIL is I get an OTHER sqlite3 which is NOT the one the extension was build with. From aotto1968 at t-online.de Thu Dec 26 02:47:52 2024 From: aotto1968 at t-online.de (aotto1968) Date: Thu, 26 Dec 2024 08:47:52 +0100 Subject: it's a shame... python error over error In-Reply-To: References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> Message-ID: On 26.12.24 04:55, Michael Torrie wrote: > On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote: >> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list >> wrote: >>> It is not only an *usage* error it is also an *security* error because: >>> >>> 1) "cnf" is using OS python >>> 2) os "root" python >>> 3) using **my** local non-root library > > I think he means the cnf is using the "root" OS python in /usr/bin, but > /usr/bin/python3 is trying to import his local build of sqlite3, which > cause it to fail. I assume he would like cnf to not try to import his > local sqlite3, and instead use the normal system one. If this is the > case, then somehow his local, non-root sqlite3 library is being picked > up by the system version of python. > > Aotto might want to run the "env" command and see if there are any > search paths that have to do with Python. I can see how this could be a > security issue. If you can figure out what's happening you might want to > open a ticket with the OpenSUSE developers. This is Python related, but > it's not necessarily python's fault per se. You don't understand the problem if you think "/usr/bin/env" will solve the problem ? this will make it more worse. A "personal" python will use a "personal" configuration and probably is *not* build with sqlite3 support at all. a *root* tool should never ever use/call a non *root* (personal) setup. From aotto1968 at t-online.de Fri Dec 27 01:46:56 2024 From: aotto1968 at t-online.de (aotto1968) Date: Fri, 27 Dec 2024 07:46:56 +0100 Subject: it's a shame... python error over error In-Reply-To: References: <938ad572-1a5c-6395-5b16-0373eb0373e0@gmail.com> <0c9e650c-1789-ff47-cf5d-ee319d19602f@gmail.com> Message-ID: On 26.12.24 19:33, Michael Torrie wrote: > On 12/25/24 10:46 PM, Chris Angelico wrote: >> Right. That's exactly what would happen if he'd built Python using >> absolute paths to libraries, which is the normal way to do it. And so >> the solution is to rebuild Python using absolute paths to libraries. > > You're right. Definitely appears to be a pretty major mis-configuration > of his system. Not much we can do about that. > no, your are wrong. The problem is NOT that my user-account has a miss-configuration because my user-account works pretty well? The problem is that the *default* /usr/bin/python3 OpenSUSE installation using parts of *my* local *user* setup. From cl at isbd.net Fri Dec 27 03:58:45 2024 From: cl at isbd.net (Chris Green) Date: Fri, 27 Dec 2024 08:58:45 +0000 Subject: Python List is Not Dead References: Message-ID: <5r624l-gdn7.ln1@q957.zbmc.eu> Cameron Simpson wrote: > On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer wrote: > >I have been following discussions on Discourse (discuss.python.org) > >these last times. > > > >I think that it definitely lacks some of the joys of the mailing list: > > FYI, it has a very good "mailing list" mode. I use it that was >90% of > the time, and file both posts from Discourse and posts from python-list > into my "python" mail folder. Yes, it's the one saving grace of a Discourse forum, you can use it by E-Mail and it behaves quite nicely with a text mode E-Mail client such as mutt so you can keep threads separate, follow sub-threads, etc. Not quite as good as this list gatewayed to usenet though, there's really nothing so good as usenet for proper discourse (!). -- Chris Green ? From rosuav at gmail.com Mon Dec 30 01:10:18 2024 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 30 Dec 2024 17:10:18 +1100 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On Mon, 30 Dec 2024 at 15:02, aotto1968 via Python-list wrote: > > You managed to make a build of Python that attempts to link to a DLL > > I never touch the OpenSUSE python. the OpenSUSE python try to use my > sqalite3. You keep saying this, but do you even know what "make install" does? Are you capable of admitting that you were wrong, or are you going to keep digging this hole? ChrisA From torriem at gmail.com Mon Dec 30 12:29:12 2024 From: torriem at gmail.com (Michael Torrie) Date: Mon, 30 Dec 2024 10:29:12 -0700 Subject: it's a shame... python error over error In-Reply-To: References: Message-ID: On 12/26/24 12:34 AM, aotto1968 via Python-list wrote: > sorry you don't understand the problem? > > > You managed to make a build of Python that attempts to link to a DLL > > I never touch the OpenSUSE python. the OpenSUSE python try to use my > sqalite3. The *only* mechanism that would cause the system python binary to try to load modules and libraries from your local install is your environment (environment variables). From max at alcyone.com Mon Dec 30 19:26:27 2024 From: max at alcyone.com (Erik Max Francis) Date: Mon, 30 Dec 2024 16:26:27 -0800 Subject: Python List is Not Dead In-Reply-To: <5r624l-gdn7.ln1@q957.zbmc.eu> References: <5r624l-gdn7.ln1@q957.zbmc.eu> Message-ID: On 12/27/24 00:58, Chris Green via Python-list wrote: > Yes, it's the one saving grace of a Discourse forum, you can use it by > E-Mail and it behaves quite nicely with a text mode E-Mail client such > as mutt so you can keep threads separate, follow sub-threads, etc. > > Not quite as good as this list gatewayed to usenet though, there's > really nothing so good as usenet for proper discourse (!). Hear, hear! -- Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && Skype erikmaxfrancis The quality, not the longevity, of one's life is what is important. -- Dr. Martin Luther King, Jr. From grant.b.edwards at gmail.com Tue Dec 31 00:21:59 2024 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 31 Dec 2024 00:21:59 -0500 (EST) Subject: Python List is Not Dead References: <5r624l-gdn7.ln1@q957.zbmc.eu> Message-ID: <4YMhD76kCsznVDb@mail.python.org> On 2024-12-27, Chris Green via Python-list wrote: > Cameron Simpson wrote: >> On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer wrote: >> >I have been following discussions on Discourse (discuss.python.org) >> >these last times. >> > >> >I think that it definitely lacks some of the joys of the mailing list: >> >> FYI, it has a very good "mailing list" mode. I use it that was >90% of >> the time, and file both posts from Discourse and posts from python-list >> into my "python" mail folder. > > Yes, it's the one saving grace of a Discourse forum, you can use it by > E-Mail and it behaves quite nicely with a text mode E-Mail client such > as mutt so you can keep threads separate, follow sub-threads, etc. > > Not quite as good as this list gatewayed to usenet though, there's > really nothing so good as usenet for proper discourse (!). Don't forget you can also read this list (and thousands of others) via the NNTP server at news.gmane.io. There really is no better way to read lists that with a good news client. -- Grant From thjmmj15 at gmail.com Tue Dec 31 19:00:10 2024 From: thjmmj15 at gmail.com (Tim Johnson) Date: Tue, 31 Dec 2024 15:00:10 -0900 Subject: No module name mutagen Message-ID: <2aab58dd-378d-4218-868d-09eda6e8d292@gmail.com> Please let me grumble for a minute : I've been using python since before 1. 5, when I could email Guido van Rossum directly with questions and on? at least one occasion we swapped stories about our cats. I put six kids though college writing python, and now after being retired for ten years, I get my butt kicked by python dependencies every time I upgrade ubuntu. (I'm newly on 24.04) now. Now, after three weeks on using the following code correctly: from mutagen import mp3, id3, File as mutaFile from mutagen.id3 import ID3, TIT2, TPE1 I am as of today, getting an import error for mutagen. Mutagen package is installed at /root/.local/share/pipx/shared/lib/python3.12/site-packages and indeed, that is the content of /root/.local/share/pipx/shared/lib/python3.12/site-packages/pipx_shared.pth I have added that to my path and am still getting the error. Grrr... I am at a loss. don't know what to do. I am only using python script for command line utilities on my desktop and local network. Must I be using a virtual environment? If so, I would be happy to set one up if I am given the python-approved directions (lots of conflicting info out there....) Thanks Tim From list1 at tompassin.net Tue Dec 31 23:12:42 2024 From: list1 at tompassin.net (Thomas Passin) Date: Tue, 31 Dec 2024 23:12:42 -0500 Subject: No module name mutagen In-Reply-To: <2aab58dd-378d-4218-868d-09eda6e8d292@gmail.com> References: <2aab58dd-378d-4218-868d-09eda6e8d292@gmail.com> Message-ID: On 12/31/2024 7:00 PM, Tim Johnson via Python-list wrote: > Please let me grumble for a minute : I've been using python since before > 1. 5, when I could email Guido van Rossum directly with questions > > and on? at least one occasion we swapped stories about our cats. I put > six kids though college writing python, and now after > > being retired for ten years, I get my butt kicked by python dependencies > every time I upgrade ubuntu. (I'm newly on 24.04) now. > > Now, after three weeks on using the following code correctly: > > from mutagen import mp3, id3, File as mutaFile > from mutagen.id3 import ID3, TIT2, TPE1 > > I am as of today, getting an import error for mutagen. Mutagen package > is installed at /root/.local/share/pipx/shared/lib/python3.12/site-packages > > and indeed, that is the content of /root/.local/share/pipx/shared/lib/ > python3.12/site-packages/pipx_shared.pth > > I have added that to my path and am still getting the error. Grrr... > > I am at a loss. don't know what to do. I am only using python script for > command line utilities on my desktop and local network. > > Must I be using a virtual environment? If so, I would be happy to set > one up if I am given the python-approved directions > > (lots of conflicting info out there....) I go back to Python 1.52 (think I remember the minor version!) also, though I never emailed Guido. A different distro of mine in a VM just did an upgrade and changed the system python from 3.12.x to 3.13.y. Naturally, none of my installed packages were present in this new system python. I had to reinstall them all. Maybe this happened to you and you didn't realize. Even if you had created a venv, I believe you would have had to redo it. It's very annoying! One way to avoid this is to install your own, non-system Python. So if the system python is invoked by python3, yours might be invoked by, say, python3.12, or even python3.12.3. I've done that on a few VMs. One advantage of using either your own Python install or a venv is that it eliminates those warnings that say the system won't allow you to install something, and then you have to work around it. The way I use venvs - and I am not expert in them - is to create a directory to contain my venvs, such as ~/venv. Now let's say you have a project, call it proj1, that you want to develop or work with in its own venv. You create it like this: python3 -m venv ~/venv/proj1 This will create some directories including a site-packages directory, which will be the location of all packages that you install. The venv module will install the packages the system's Python already has. To use the new venv you have to "activate" it, which creates some paths and variables that cause Python to look first in the venv for modules. You have to source this script: source ~/venv/proj1/bin/activate The activate script will also add "(proj1)" to your terminal's prompt so you know it's in effect. Once the venv is activated, which obviously will only be in effect for that session in that terminal, you install as usual with pip (and pipx although I don't use pipx so I don't know if there's anything special to do for a venv): python3 -m pip install matplotlib # or whatever Don't use sudo or --user. You should be able to run pip directly in the venv, but I have developed the habit of using python3 -m pip because I can be sure I'm running the right version of pip with the right version of python. It's possible to end up with a bare "pip" invoked by an unexpected version of Python. I've been bitten by this before, especially on Windows where I've had several parallel Python installations.