🌐 Mailman 3 May 2024 - Python-list - python.org

Issues with uninstalling python versions on windows server
by Tripura Seersha May 10, 2024

May 10, 2024

Hi Team, I am working on an automation related to uninstalling and installing python versions on different windows servers. I have observed that uninstallation is working only with the account/login using which the python version is installed. But for automation, we are not aware which account is being used for installation on different machines. Also, with the approach of using msiexec.exe to uninstall different components of python version, though all the components are uninstalled successfully but still an entry for this version shows in the control panel with the options: Modify, repair and uninstall. I am unable to identify which component has still remained as a part of the installer. Could you please help me resolve these issues. Thanks, Tripura

3 5

[RELEASE] Python 3.13.0 beta 1 released
by Thomas Wouters May 8, 2024

May 8, 2024

After a little bit of excitement discovering new bugs during the release, *it’s done*: 3.13.0 beta 1 is released, the 3.13 branch has been created, and features for 3.13 are frozen! The main branch is now 3.14.0a0. https://www.python.org/downloads/release/python-3130b1/ *This is a beta preview of Python 3.13* Python 3.13 is still in development. This release, 3.13.0b1, is the first of four beta release previews of 3.13. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We *strongly encourage* maintainers of third-party Python projects to *test with 3.13* during the beta phase and report issues found to the Python bug tracker <https://github.com/python/cpython/issues> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be *extremely important* to get as much exposure for 3.13 as possible during the beta phase. Please keep in mind that this is a preview release and its use is *not* recommended for production environments. <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#major-new-…>Major new features of the 3.13 series, compared to 3.12 Some of the new major new features and changes in Python 3.13 are: <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#new-featur…>New features - A new and improved interactive interpreter <https://docs.python.org/3.13/whatsnew/3.13.html#a-better-interactive-interp…>, based on PyPy <https://pypy.org>’s, featuring multi-line editing and color support, as well as colorized exception tracebacks <https://docs.python.org/3.13/whatsnew/3.13.html#improved-error-messages> . - An *experimental* free-threaded build mode <https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>, which disables the Global Interpreter Lock, allowing threads to run more concurrently. - A preliminary, *experimental* JIT <https://docs.python.org/3.13/whatsnew/3.13.html#experimental-jit-compiler>, providing the ground work for significant performance improvements. - The (cyclic) garbage collector is now incremental <https://docs.python.org/3.13/whatsnew/3.13.html#incremental-garbage-collect…>, which should mean shorter pauses for collection in programs with a lot of objects. - A modified version of mimalloc <https://github.com/microsoft/mimalloc> is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode. - Docstrings now have their leading indentation stripped <https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes>, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.) - The dbm module <https://docs.python.org/3.13/library/dbm.html> has a new dbm.sqlite3 backend <https://docs.python.org/3.13/whatsnew/3.13.html#dbm> that is used by default when creating new files. <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#typing-3> Typing - Support for type defaults in type parameters <https://peps.python.org/pep-0696/>. - A new type narrowing annotation <https://peps.python.org/pep-0742/>, typing.TypeIs. - A new annotation for read-only items in TypeDicts <https://peps.python.org/pep-0705/>. <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#removals-a…>Removals and new deprecations - PEP 594 (Removing dead batteries from the standard library) <https://peps.python.org/pep-0594/> scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3. - Many other removals <https://docs.python.org/3.13/whatsnew/3.13.html#removed> of deprecated classes, functions and methods in various standard library modules. - C API removals <https://docs.python.org/3.13/whatsnew/3.13.html#id10> and deprecations <https://docs.python.org/3.13/whatsnew/3.13.html#id9>. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.) - New deprecations <https://docs.python.org/3.13/whatsnew/3.13.html#deprecated>, most of which are scheduled for removal from Python 3.15 or 3.16. (Hey, *fellow core developer,* if a feature you find important is missing from this list, let Thomas know <thomas(a)python.org>.) For more details on the changes to Python 3.13, see What’s new in Python 3.13 <https://docs.python.org/3.13/whatsnew/3.13.html>. The next pre-release of Python 3.13 will be 3.13.0b2, currently scheduled for 2024-05-28. <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#more-resou…>More resources - Online Documentation <https://docs.python.org/3.13/> - PEP 719 <https://peps.python.org/pep-0719/>, 3.13 Release Schedule - Report bugs at Issues · python/cpython · GitHub <https://github.com/python/cpython/issues>. - Help fund Python directly <https://www.python.org/psf/donations/python-dev/> (or via GitHub Sponsors <https://github.com/sponsors/python>), and support the Python community <https://www.python.org/psf/donations/>. <https://discuss.python.org/t/python-3-13-0b1-now-available/52891#enjoy-the-…>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 droopy Amsterdam, Your release team, Thomas Wouters @thomas <https://discuss.python.org/u/thomas> Łukasz Langa @ambv <https://discuss.python.org/u/ambv> Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>

1 0

Re: Use of statement 'global' in scripts.
by Greg Ewing May 8, 2024

May 8, 2024

On 8/05/24 1:32 pm, Popov, Dmitry Yu wrote: > The statement 'global', indicating variables living in the global scope, is very suitable to be used in modules. I'm wondering whether in scripts, running at the top-level invocation of the interpreter, statement 'global' is used exactly the same way as in modules? The 'global' statement declares a name to be module-level, so there's no reason to use it at the top level of either a script or a module, since everything there is module-level anyway. You only need it if you want to assign to a module-level name from within a function, e.g. spam = 17 def f(): global spam spam = 42 f() # spam is now 42 A script is a module, so everything that applies to modules also applies to scripts. -- Greg

2 1

Use of statement 'global' in scripts.
by Popov, Dmitry Yu May 7, 2024

May 7, 2024

Dear Sirs. The statement 'global', indicating variables living in the global scope, is very suitable to be used in modules. I'm wondering whether in scripts, running at the top-level invocation of the interpreter, statement 'global' is used exactly the same way as in modules? If there are any differences, I would really appreciate any comments on this. Regards, Dmitry Popov Lemont, IL USA

1 0

Re: Python Dialogs
by Loris Bennett May 6, 2024

May 6, 2024

ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Me (indented by 2) and the chatbot (flush left). Lines lengths > 72! Is there a name for this kind of indentation, i.e. the stuff you are writing not being flush left? It is sort of contrary to what I think of as "normal" indentation. You seem to use it in all your postings, too, which hurts my brain, but I guess that's my problem :-) [snip (40 lines)] -- This signature is currently under constuction.

4 3

Re: how to discover what values produced an exception?
by Alan Bawden May 6, 2024

May 6, 2024

Thomas Passin <list1(a)tompassin.net> writes: On 5/3/2024 9:56 AM, Johanne Fairchild via Python-list wrote: > How to discover what values produced an exception? Or perhaps---why > doesn't the Python traceback show the values involved in the TypeError? > For instance: > > --8<-------------------------------------------------------->8--- >>>> (0,0) < 4 > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: '<' not supported between instances of 'tuple' and 'int' > --8<-------------------------------------------------------->8--- > > It could have said something like: > > --8<-------------------------------------------------------->8--- > TypeError: '<' not supported between instances of 'tuple' and 'int' > in (0,0) < 4. > --8<-------------------------------------------------------->8--- > > We would know which were the values that caused the problem, which would > be very helpful. In this example it would not help at all to know the actual values. Knowing that you are trying to compare incomparable types is enough. In general, it absolutely can help. The programmer can sometimes recognize where a value of unexpected type came from just by looking at it, allowing her to quickly deduce just what went wrong without further investigation. A good error message shouldn't withhold any information that can _easily_ be included. Debugging is more art than science, so there is no real way to predict what information might prove useful in solving the crime. I emphasized "easily" because of course you have to draw the line somewhere. The fact that Python error messages often fail to mention the actual objects that caused the error has always annoyed me. I've always presumed that for some reason it just wasn't easy to do. And it's never been more than a minor annoyance to me. So the OP is not wrong for wishing for this. Other programming languages do it. Other Python programmers miss it. - Alan

2 1

Re: Python Dialogs
by jak May 6, 2024

May 6, 2024

Stefan Ram ha scritto: > ram(a)zedat.fu-berlin.de (Stefan Ram) wrote or quoted: >> translation services are gonna interpret line breaks as > > I just beefed up my posting program to replace "gonna". > > Now I won't come across like some street thug, but rather > as a respectable member of human society! > > # replace complete words > replacements =\ > { rb'kind of': b'kind of', > rb'trying to': b'trying to', > rb'got to': b'got to', > rb'gonna': b'going to', > } > lines =\ > [ re.sub( rb"\b(" + b"|".join( replacements.keys() ) + rb")\b", > lambda x: replacements[ x.group() ], line ) > if len( line )and line[ 0 ]not in b'>|' else line for line in lines ] > I present to you the brutality to which your posts are subjected: for(d = s = pCLipb; *s != TEXT('\0'); s++) { if(d == pCLipb) { if(*s != TEXT(' ') && *s != TEXT('\n') && *s != TEXT('\r')) *d++ = *s; } else if(*s == TEXT(' ') || *s == TEXT('\n') || *s == TEXT('\r')) { if(d[-1] != TEXT(' ')) *d++ = TEXT(' '); } else *d++ = *s; } *d = TEXT('\0');

1 0

how to discover what values produced an exception?
by Johanne Fairchild May 3, 2024

May 3, 2024

How to discover what values produced an exception? Or perhaps---why doesn't the Python traceback show the values involved in the TypeError? For instance: --8<-------------------------------------------------------->8--- >>> (0,0) < 4 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'tuple' and 'int' --8<-------------------------------------------------------->8--- It could have said something like: --8<-------------------------------------------------------->8--- TypeError: '<' not supported between instances of 'tuple' and 'int' in (0,0) < 4. --8<-------------------------------------------------------->8--- We would know which were the values that caused the problem, which would be very helpful.

5 4

Re: Python Dialogs (Posting On Python-List Prohibited)
by Alan Bawden May 3, 2024

May 3, 2024

Lawrence D'Oliveiro <ldo(a)nz.invalid> writes: > Assume you have an expression "s.replace('a','b').replace('c','d'). > replace('e','f').replace('g','h')". Its value is a string which > is the value of s, but with "a" replaced by "b", "c" replaced by > "d", "e" replaced by "f" and "g" replaced by "h". How to modify > this expression, so that "a", "c", "e", and "g", respectively, > are replaced only if they are words (but not parts of words)? import re replacements = (("a", "b"), ("c", "d"), ("e", "f"), ("g", "h")) text = "this be a test g eg" "".join \ ( repl.get(s, s) for repl in (dict(replacements),) for s in re.split("\\b(" + "|".join(re.escape(s[0]) for s in replacements) + ")\\b", text) ) How about just: repl = { "a" : "b", "c" : "d", "e" : "f", "g" : "h", } "".join(repl.get(s, s) for s in re.split(r"\b", text)) - Alan

1 0

Re: UTF_16 question
by jak May 1, 2024

May 1, 2024

Richard Damon ha scritto: >> On Apr 29, 2024, at 12:23 PM, jak via Python-list <python-list(a)python.org> wrote: >> >> Hi everyone, >> one thing that I do not understand is happening to me: I have some text >> files with different characteristics, among these there are that they >> have an UTF_32_le coding, utf_32be, utf_16_le, utf_16_be all of them >> without BOM. With those utf_32_xx I have no problem but with the >> UTF_16_xx I have. If I have an utf_16_le coded file and I read it with >> encoding='utf_16_le' I have no problem I read it, with >> encoding='utf_16_be' I can read it without any error even if the data I >> receive have the inverted bytes. The same thing happens with the >> utf_16_be codified file, I read it, both with encoding='utf_16_be' and >> with 'utf_16_le' without errors but in the last case the bytes are >> inverted. What did I not understand? What am I doing wrong? >> >> thanks in advance >> >> -- >> https://mail.python.org/mailman/listinfo/python-list > > That is why the BOM was created. A lot of files can be “correctly” read as either UTF-16-LE or UTF-1-BE encoded, as most of the 16 bit codes are valid, so unless the wrong encoding happens to hit something that is invalid (most likely something looking like a Surrogage Pair without a match), there isn’t an error in reading the file. The BOM character was specifically designed to be an invalid code if read by the wrong encoding (if you ignore the possibility of the file having a NUL right after the BOM) > > If you know the files likely contains a lot of “ASCII” characters, then you might be able to detect that you got it wrong, due to seeing a lot of 0xXX00 characters and few 0x00XX characters, but that doesn’t create an “error” normally. > Thanks to you too for the reply. I was actually looking for a way to distinguish "utf16le" texts from "utf16be" ones. Unfortunately, whoever created this log file archive thought that the BOM was not important and so omitted it. Now they want to switch to "utf8 " and also save the previous. Fortunately I can be sure that the text of the log files is in some European language, so after converting the file to "utf8" I make sure that most of the bytes are less than the value 0x7F and if not I reconvert them by replacing "utf16 " "le" with "be" or vice versa. The strategy seems to be working. In the future, by writing files in "utf8" they will no longer have problems like this.

1 0