Re: Letter replacer - suggestions?
On 07/12/2020 16:48, Bischoop wrote: I worked on my wee script that replaces a letters: https://bpa.st/OYBQ . I would like to have some suggestions about the code from more experienced programmers, the code does work and do its job but perhaps could work in a better way. Thanks Sure! First of all, the code could be simplified by using the replace() method of the str class (https://docs.python.org/3/library/stdtypes.html#str.replace). Now a few comments on the code specifically: while True: What is this for? It looks like all it does is cause the program to get caught in an infinite loop if there's an exception... for element in word_list: for x in change_this_list: You can loop over strings as well - there's no need to convert them to lists. to = word_list.index(element) There's a nice trick to get the index while looping: write for (idx, character) in enumerate(word): then you don't have to use the index method. This also works if a character appears multiple times in the word, in which case I think your code will fail (but I haven't tried it) (Obviously apply this to the other loop as well, mutadis mutandis, to get rid of both index() calls) word_list[to] = replace_with_list[replace] Okay, this is something you can't do with a str because they're immutable. Generally I'd avoid modifying the thing you're looping over; it works in this case when you're replacing elements of a list, but it probably won't do what you want if you're deleting or adding items. I'd put new_word_list = [] somewhere at the top, and build it up element by element with new_word_list.append(). But what you're doing is fine too as long as you keep in mind that changing the thing you're looping over can be dangerous in other cases. Hope this helps Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASE] Python 3.9.1 is now available, together with 3.10.0a3 and 3.8.7rc1
On 12/7/2020 8:33 PM, Pablo Galindo Salgado wrote: It's starting to get very cold (at least on the Northern hemisphere) so we have been carefully packaging a total of three new Python releases to keep you warm these days! Python 3.9.1 is the first maintenance release of Python 3.9, and also the first version of Python to support macOS 11 Big Sur natively on Apple Silicon. Go get it here: https://www.python.org/downloads/release/python-391/ On my Windows 10 machine, only test_locale failed. https://bugs.python.org/issue37945 has not come to a conclusion yet. Maintenance releases for the 3.9 series will continue at regular bi-monthly intervals, with **3.9.2** planned for Monday, 2021-02-08. Python 3.10a3 is the third alpha release of Python 3.10. You can get it here: https://www.python.org/downloads/release/python-3100a3/ test_os test_pydoc test_webbrowser also fail for me Python 3.10a3 is the release preview of the next maintenance release of This should be 3.8.7rc1 ... Python 3.8. You can get it here: https://www.python.org/downloads/release/python-387rc1/ test_compileall also fails for me Assuming no critical problems are found prior to **2020-12-21** , the currently scheduled release date for **3.8.7** , no code changes are planned between this release candidate and the final release. That being said, please keep in mind that this is a pre-release of 3.8.7 and as such its main purpose is testing -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
PyDev 8.1.0 Released
PyDev 8.1.0 Release Highlights - *Interactive Console* - The selection for which console to open may be saved. (*#PyDev-1112*) - When the *current editor* option is selected, the related interpreter is no longer asked. (*#PyDev-1112*) - *Debugger* (updated to pydevd 2.2.0) - Better support for Python flags when auto-attaching to subprocesses. - Fixes to path translation (when debugging in a different machine). - Catch warnings related to *imp* import from *pkg_resources*. - No longer crashing when running with *Pyjion* (patch by Anthony Shaw). - *Others* - Code analysis now supports *from __future__ import anotations*. ( *#PyDev-1040*) - AST pretty-printing supports printing slices. (*#PyDev-1106*) - Code-completion with auto imports for the builtin module is no longer shown. (*#PyDev-1117*) - MyPy messages from a different file are no longer shown in the current editor. (*#PyDev-1114*) About PyDev PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development, now also available for Python on Visual Studio Code. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. It is also available as a standalone through LiClipse with goodies such as multiple cursors, theming and support for many other languages, such as Django Templates, Jinja2, Html, JavaScript, etc. Links: PyDev: http://pydev.org PyDev Blog: http://pydev.blogspot.com PyDev on VSCode: http://pydev.org/vscode LiClipse: http://www.liclipse.com PyVmMonitor - Python Profiler: http://www.pyvmmonitor.com/ Cheers, Fabio Zadrozny -- https://mail.python.org/mailman/listinfo/python-list
RE: linear algebric equations
Yes. Import os, and use os.system( ) to call your Fortran (or C) executable. If the executable saves results in a file or files, Python can read them in an format a nice overall report. In html or xml, if you like. Using Python as glue, the execution time will be exactly what it was for your executable, because Python will call it; and in a second of so after it finishes Python can read in results and format whatever report you like. --- Joseph S. -Original Message- From: Tito Sanò Sent: Monday, December 7, 2020 11:59 AM To: python-list@python.org Subject: linear algebric equations Regarding the solution of linear algebraic equations I noticed a big difference in the computation time in Python compared to the old fortran language. I have compared both the linelg and lapack.dgesv-lapack.zgesv modules with the fortan: dgelg and f04adf. The difference in computation time is enormous: for example for 430 degrees of freedom it is about 24 min in Python versus about 1 sec in fortran. Is it possible to get better performance in Python? Thanks in advance Tito Sano' Roma Italy Cell: 339 6903895 -- https://mail.python.org/mailman/listinfo/python-list
Re: linear algebric equations
On Mon, 7 Dec 2020 at 20:38, Tito Sanò wrote: > Is it possible to get better performance in Python? Have you installed BLAS for Scipy? What OS do you have? -- https://mail.python.org/mailman/listinfo/python-list
Re: linear algebric equations
Am 07.12.20 um 17:59 schrieb Tito Sanò: Regarding the solution of linear algebraic equations I noticed a big difference in the computation time in Python compared to the old fortran language. I have compared both the linelg and lapack.dgesv-lapack.zgesv modules with the fortan: dgelg and f04adf. The difference in computation time is enormous: for example for 430 degrees of freedom it is about 24 min in Python versus about 1 sec in fortran. There must be something seriously wrong. If I understand correctly, you want to solve an 430x430 matrix with LU decompositino (that is what dgesv from LAPACK does). The following code takes less than a second on my machine: ==430.py== import numpy as np # create a 430x430 random matrix A = np.random.randn(430,430) # right hand side b = np.ones(430) # solve it x = np.linalg.solve(A, b) print(x) time python3 430.py real0m0.318s user0m0.292s sys 0m0.046s If it takes longer than 1s, there is something wrong with your system. Christian -- https://mail.python.org/mailman/listinfo/python-list
Property type hints?
Would this be a reasonably correct way to annotate a property with a
type hint?
>>> class Foo:
... bar: int
... @property
... def bar(self):
... return 1
...
>>> foo = Foo()
>>> import typing
>>> typing.get_type_hints(foo)
{'bar': }
I could also decorate the property method return value:
... def bar(self) -> int:
I don't see the point though, because you can't access it with get_type_hints.
--
https://mail.python.org/mailman/listinfo/python-list
numpy/python (image) problem
Hi! I am looking at some code, that I found somewhere in the internet, to compute DCT for each 8x8 block in an gray (2D) image (512x512). This is the code: def dct2(a): return scipy.fft.dct(scipy.fft.dct(a,axis=0,norm='ortho'),axis=1,norm='ortho') imsize=im.shape dct=np.zeros(imsize) # Do 8x8 DCT on image (in-place) for i in r_[:imsize[0]:8]: # Seems the same as "for i in np.arange(0,imsize[0],8)"! for j in r_[:imsize[1]:8]: dct[i:(i+8),j:(j+8)]=dct2(im[i:(i+8),j:(j+8)]) I tried to do the same thing with: imsize=im.shape im8=im.reshape(imsize[0]*imsize[1]//8//8,8,8) dct_test=np.asarray([dct2(im8x) for im8x in im8]) dct_test=dct_test.reshape(imsize) so that dct_test should be equal to (previous) dct. But they are completely different. What am I doing wrong? Thanks a lot. -- https://mail.python.org/mailman/listinfo/python-list
