Mailman 3 August 2025 - Python-list

Re: can you improve this text-only beginner copy program?
by Mark Bourne Sept. 25, 2025

Sept. 25, 2025

Stefan Ram wrote: > Ethan Carter <ec1828(a)somewhere.edu> wrote or quoted: >> def copy(s, d): >> """Copies text file named S to text file named D.""" >> with open(s) as src: >> with open(d, "w") as dst: >> try: >> dst.write(src.read()) >> except Exception: >> os.remove(d) >> raise > > In Python there are several ways to format docstrings. > > One possibility is to use conventions from "Sphinx" and to use > "reStructuredText". Then, it might look as follows, giving some > prominence to the names of parameters, though some find that > this is already too much markup in the source code: > > """ > Copy the contents of the text file whose path is given by the > parameter ``s`` to the text file whose path is given by ``d``. > > :param s: Path to the source text file to copy from. > :type s: str > :param d: Path to the destination text file to copy to. > :type d: str > :raises OSError: If an I/O error occurs during writing. On error, > the destination file will be removed if it was > partially written. > """ > > Sphinx can then extract such documentation from your source code > and generate webpages or PDF books from it. I don't know if Sphinx can extract types from type hints but, at least if the docstring is just for humans reading the code, using those can reduce the markup in the docstring: ``` def copy(s: int, d: int) -> None: """ Copy the contents of the text file whose path is given by the parameter ``s`` to the text file whose path is given by ``d``. :param s: Path to the source text file to copy from. :param d: Path to the destination text file to copy to. :raises OSError: If an I/O error occurs during writing. On error, the destination file will be removed if it was partially written. """ ``` Aside from acting as documentation of the expected argument and return types, type hints can also be read by type checkers to help find places where objects of the wrong types might be passed. Type hints don't make any difference at runtime, so you could still call `copy(1, 2)` and it'll copy a file named "1" to a file named "2", but type checkers would flag that as a possible bug - it should be `copy("1", "2")` if that's really what you intend. Maybe type hints are considered a bit advanced for just starting out, it would seem a good idea to learn about type hints along with the rest of Python rather than something bolted on afterwards (even if "bolted on afterwards" is how they came into the Python language!) -- Mark.

2 1

Access to return / exception context in finally block
by marius.spix＠web.de Sept. 2, 2025

Sept. 2, 2025

Dear mailing list, there is currently no direct way to observe the current interpreter state in a finally block without tracing. My idea is introducing an immutable __exit_context__ magic variable, which would have one of three possible values: * ReturnContext(value), if a return statement is about to exit the try, except or else block * ExceptionContext(exc, tb, caught: bool), if an exception has occured in the try, except or else block * None, if the try block completes normally without return or exception This variable would allow to inspect the cause, why a try block is left and make post-processing easier without using workarounds like storing the exception in a temporary variable. sys.exc_info() is not always useful, because it always returns (None, None, None) when the exception has been caught in the except block. This is an example, how __exit_context__ could be used: def f(x): try: return 10 / x except ZeroDivisionError: pass finally: if isinstance(__exit_context__, ExceptionContext): log_error(__exit_context__.exc) return 0 elif isinstance(__exit_context__, ReturnContext): log_return(__exit_context__.value) return __exit_context__.value + 1 I wonder if it would be a candidate for a PEP to be implemented in the Python standard. Best regards Marius Spix

3 6

Python documentary
by Larry Martell Aug. 31, 2025

Aug. 31, 2025

https://www.youtube.com/watch?v=GfH4QL4VqJ0 Watched this last night. Overall I enjoyed it (but my wife, who is not a programmer, fell asleep). My only quibble is that they spent too much time talking about the walrus controversy.

5 4

ANN: Python Meeting Düsseldorf - 10.09.2025
by eGenix Team Aug. 29, 2025

Aug. 29, 2025

/This announcement is in German since it targets a local user group//meeting in Düsseldorf, Germany/ Ankündigung Python Meeting Düsseldorf - September 2025 <https://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2025-09-10> Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. *10.09.2025, 18:00 Uhr* Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk <http://www.duesseldorf.de/jugendamt/fam/famfoe/bueh/ac/index.shtml> Düsseldorfer Arcaden <http://www.duesseldorf-arcaden.de/anfahrt.html>, Bachstr. 145, 40217 Düsseldorf <http://maps.google.com/maps?q=51.209169,6.775339&layer=c&sll=51.209353,6.77…> Programm Bereits angemeldete Vorträge: * Arkadius Schuchhardt: *Python Ökosystem innerhalb von Snowflake * * Marc-André Lemburg: *ETL with Python and DuckDB * * Marc-André Lemburg: *Running unrestricted Claude Code in a Docker container* (LT) Weitere Vorträge können gerne noch angemeldet werden. Bei Interesse, bitte unter info(a)pyddf.de melden. Startzeit und Ort Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden. Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. >>> Eingang in Google Street View <http://bit.ly/11sCfiw> *⚠️ Wichtig*: Bitte nur dann anmelden, wenn ihr absolut sicher seid, dass ihr auch kommt. Angesichts der begrenzten Anzahl Plätze, haben wir kein Verständnis für kurzfristige Absagen oder No-Shows. Einleitung Das Python Meeting Düsseldorf <http://pyddf.de/> ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet. Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal <http://www.youtube.com/pyddf/>, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen. Veranstaltet wird das Meeting von der eGenix.com GmbH <https://www.egenix.com/>, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research <http://www.clark-consulting.eu/>, Düsseldorf: Format Das Python Meeting Düsseldorf <http://pyddf.de/> nutzt eine Mischung aus (Lightning) Talks und offener Diskussion. Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit HDMI und FullHD Auflösung steht zur Verfügung. (Lightning) Talk Anmeldung bitte formlos per EMail an info(a)pyddf.de <mailto:info@pyddf.de?subject=Anmeldung Lightning Talk Python Meeting Düsseldorf> Kostenbeteiligung Das Python Meeting Düsseldorf <http://pyddf.de/> wird von Python Nutzern für Python Nutzer veranstaltet. Da Tagungsraum, Beamer und Getränke Kosten produzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. Anmeldung Da wir nur 25 Personen in dem angemieteten Raum empfangen können, möchten wir bitten, sich vorher anzumelden. *Meeting Anmeldung* bitte per Meetup <https://www.meetup.com/Python-Meeting-Dusseldorf/> Weitere Informationen Weitere Informationen finden Sie auf der Webseite des Meetings: https://pyddf.de/ Viel Spaß ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 29 2025) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

1 0

can you improve this text-only beginner copy program?
by Ethan Carter Aug. 29, 2025

Aug. 29, 2025

The program below only copies text files on purpose---because we haven't learned about binary files in this course yet. (So I could catch a UnicodeDecodeError while writing.) If an exception is raised while writing, I need to delete the file that was created. Can you think of anything I'm missing? I'm sure you can improve it by making it more efficient for not reading the entire file into memory---I'm aware of that, but also not going in that direction right now. (I will worry about that when I write a new version that does binary reading.) In summary, don't demand too much of a Python beginner here. Thanks! # -*- mode: python; python-indent-offset: 2 -*- import os import sys def copy(s, d): """Copies text file named S to text file named D.""" with open(s) as src: with open(d, "w") as dst: try: dst.write(src.read()) except Exception: os.remove(d) raise def usage(program): return f"""usage: python {program} source.txt destination.txt""" def main(argc, argv): if argc != 3: raise SystemExit(usage(argv[0])) copy(argv[1], argv[2]) if __name__ == "__main__": main(len(sys.argv), sys.argv)

7 7

Re: can you improve this text-only beginner copy program?
by Ethan Carter Aug. 29, 2025

Aug. 29, 2025

ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Ethan Carter <ec1828(a)somewhere.edu> wrote or quoted: >>Can you think of anything I'm missing? > > The correctness of a program as a solution to an assignment > depends on the exact wording of the assignment, so it's a > bit difficult to say without seeing it. You're right. There's no written statement. The exercise was suggested by the teacher while in class. It was something like ``write a program that copies text files by getting source and destination via the command-line.'' >> """Copies text file named S to text file named D.""" > > This is not entirely clear, since case is significant in Python > ("S" is not the same as "s"), and it is ambiguous whether it refers > to a file actually named "S" or to a file whose name is provided as > a str object bound to the name "s" in the function's source code. This is how docstrings are traditionally written in GNU EMACS ELISP code---they upcase argument names of the procedure being documented. I can't recall who taught me this, but I believe it was Robert Chassel in his book ``An Introduction to Emacs Lisp'' that's included in the GNU EMACS itself. But, yeah, if the Python community doesn't do that, it's all what you say. Thanks for your attention! PS. Is it just me or there's just us in this used-to-be-very-active group? Thanks for being my teacher here. Have a good day!

5 4

Re: can you improve this text-only beginner copy program?
by Thomas Passin Aug. 28, 2025

Aug. 28, 2025

On 8/27/2025 1:45 PM, Stefan Ram wrote: > Ethan Carter <ec1828(a)somewhere.edu> wrote or quoted: >> You're right. There's no written statement. The exercise was suggested >> by the teacher while in class. It was something like ``write a program >> that copies text files by getting source and destination via the >> command-line.'' > > Well then, I'd think about using "shutil", e.g., "shutil.copy". > Check it out in "The Python Library Reference"; it's 11.10.1 in > release 3.13.0a0. It sounds like the main point of the exercise may have been to use command line arguments. The Original Post tried to do this in a complicated and clumsy (non-Pythonic) way. Easier and more Pythonic would be to delete the def main() block and then: if __name__ == '__main__': import sys # could import this at start of file if len(sys.argv) == 3: copy(sys.argv[1], sys.argv[2]) else: print(usage(sys.argv[0])) or perhaps easier to read: if __name__ == '__main__': import sys # could import this at start of file try: prog, src, dest = sys.argv except: print(usage(sys.argv[0])) sys.exit(1) # or some other error code copy(src, dest) >> But, yeah, if the Python community doesn't do that, it's all what you >> say. > > Community or no community, in Python, you can have: > > def f( s, S ): > return 2*s+S > > . Should the docs then say, "returns 2*S+S"? > >> PS. Is it just me or there's just us in this used-to-be-very-active >> group? Thanks for being my teacher here. Have a good day! > > Thanks, you too! > > On one hand, many people seem to prefer websites for discussions > nowadays. On the other hand, if I had not responded, probably > someone else would have. >

1 0

PyPi mirrors
by dn Aug. 25, 2025

Aug. 25, 2025

Hi, Do you use a mirror in front of the PyPi "Cheese Shop"? - perhaps a server like DevPi or Bandersnatch? - perhaps a personal interest or your enterprise? - is there public instance such as unis and others mirroring Linux distros? -- Regards, =dn

1 0

entanglement.py: New tool for calling C++ symbols directly from Python using the C++ABI
by Adrian Johnston Aug. 22, 2025

Aug. 22, 2025

Hello, I recently hacked together a script called entanglement.py that uses libclang to parse C++ headers and generate a Python wrapper that can call the C++ symbols in a .so directly. The Itanium C++ ABI is easy enough to call from ctypes with 1 exception. Returning a class by value from C++ results in a missing constructor call because Python just calls memcpy. Otherwise references, this/self pointers, the object life-cycle, virtual functions using single inheritance and overloaded C++ operators are all easy to implement. While this is an experiment, I genuinely think C++ should be natively supported by script interpreters who can read some kind of pre-compiled C++ header and use that to talk directly to the .so. This is just a crude first attempt to move in that direction and other ABIs would require support. I would love feedback... Anyway, entanglement.py handles translating the entire object model, most of the C++ operators including the whole C++ life-cycle. Overloaded functions are selected by argument count and then first arg type. Being able to support C++'s re-opening namespaces and C++'s forward declaring nested classes did require monkey-patching in Python. Templates would have to be instantiated to be called in C++ and macros are not yet being converted. So for example, the generated code for an overloaded C++ constructor would look like this: def __init__(self,*_Args,**_Kwargs): assert not _Kwargs, 'Keyword arguments.' match _Len(_Args): case 0: return _ZN12OperatorTestC1Ev(_Ctypes.byref(self),) # type: ignore case 1: return _ZN12OperatorTestC1Ei(_Ctypes.byref(self),_Args[0]) # type: ignore case _: assert False, f'Arg count: {_Len(_Args)}' ... Then the "symbol table" for _ZN12OperatorTestC1Ev would look like this: _X=_Cdll._ZN12OperatorTestC1Ev # void OperatorTest() _X.argtypes=[_Ctypes.c_void_p,] _X.restype=None _ZN12OperatorTestC1Ev=_X The rest of the output is attached. Anyone familiar with ctypes should be able to read it. In theory ctypes could decode the argtypes and restype automatically because they are explicitly encoded in the C++ name mangling scheme. Where this script really shines is that it doesn't generate C++. Other tools I tried were eating 50% of my compile time and 50% of my .so size just to wrap 50 function calls. By comparison, this builds in a fraction of a second and is just a little more byte-code. Meanwhile, it allows you to write a Python wrapper for a C++ object model while barely knowing Python, let alone writing any. I can't speak to the overhead compared to the Python C API, however. Here is the script: https://github.com/whatchamacallem/hatchlingplatform/blob/master/entangleme… Here is the test poject. There are docs on that page. https://github.com/whatchamacallem/hatchlingplatform/tree/master/entangleme… Note: testpythonbindings.sh is in the parent directory above that and the path to libclang is hard-coded to work with Ubuntu LTS. (I swear I am more worried about finding libclang on your hard drive portably than I am about the portability of the rest of this.) I am tempted to write an improvement proposal asking for C++ support in Python. (In theory a description of the C++ interface could be added to the ELF file format and loaded that way.) Again, let me know what you think. Regards, Adrian

1 0

Re: not understanding the result of functools.reduce
by Ethan Carter Aug. 22, 2025

Aug. 22, 2025

ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Ethan Carter <ec1828(a)somewhere.edu> wrote or quoted: >>## The question is how to write such an operator. I wrote this one: >>def op(x, b): >> return isinstance(x, int) or b > > The main snag with your op function and how you're using > reduce is the switch-up in the argument order that "reduce" > expects versus how you set up op. > > "functools.reduce" calls the reducer function "op" with two > arguments: the accumulated value so far first, then the > next element from the iterable. > > You wrote "op" as "op(x, b)", where you treat "x" like an element > and "b" like a boolean accumulator, but actually "reduce" hands > the accumulator first, then the element. > > So when "reduce" runs, the first argument "x" is actually the boolean > accumulator, and the second "b" is the next element. You're a master. That happens to be the one thing I didn't check! I couldn't think of it, even though I'm well aware that not every binary operator is commutative. Such is life! Thanks so much!

1 0