Detect naming typos (AttributeError) in function names

[Christian Buhtz via Python-list]

Hello,

I would like to know how to detect (e.g. via a linter) typos in function 
names imported from another module.


Let's assume this given Python code snippet.

import foo
foo.baR()

The package "foo" do contain a function named "bar()" (all lower case 
letters). The function "baR()" does not exist in "foo". This cause an 
AttributeError when run with a Python interpreter.


The described error is not detected in my IDE (Emacs with eglot, pylsp 
and flake8) and not by flake8 on the shell. Because the involved tools 
do not look inside the "foo" package if "baR()" really exist.


Can I fix this somehow?

I am aware that this would get detected by a unit test. That is the way 
I do prefer in most cases. But sometimes not all code segments are 
covered by tests. I'm more interested in using a linter or something 
else for that.


Kind
Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Detect naming typos (AttributeError) in function names

[Christian Buhtz via Python-list]

Hello Dieter,

thanks for your reply.

Am 06.11.2023 19:11 schrieb Dieter Maurer:

One option is a test suite (--> Python's "unittest" package)
with a sufficiently high coverage (near 100 %).


Yes, that is the primary goal. But it is far away in the related 
project.


I got a hint that "pylint" is able to detect problems like this.
--
https://mail.python.org/mailman/listinfo/python-list

Request to Review: Tutorial about Python Packaging offering different use case

[Christian Buhtz via Python-list]

Hello,

I would like to point to my Python Packaging Tutorial explaining several 
common use cases using minimal demo projects.




I am not an expert and assume that some of my solutions might not be the 
best. So I would appreciate if you can review them.


Background of that project: I am member of FOSS maintainer team and 
prepare the migration of Back In Time 
(https://github.com/bit-team/backintime) from a makefile based 
build-system to a modern Python Build system using pyproject.toml & Co. 
To explore some expect able problems and possible solutions I created 
this minimal examples. I also do plan a tutorial repo about Debian 
Python Packaging using the same approach with minimal examples 
illustrating different use cases.


Thanks in advance,
Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Christian Buhtz via Python-list]

What is the "command line" on your Windows 11?

On Windows 10 it usually is "cmd.exe" (Windows Command Prompt).
On Windows 11 it usually is the "Terminal" which is different from 
cmd.exe.

--
https://mail.python.org/mailman/listinfo/python-list

Re: shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[Christian Buhtz via Python-list]

Thank you very much for all your responses.

Am 24.10.2024 17:17 schrieb Left Right:

To investigate this, I'd edit the file with the assertion and make it
print the actual value found in os.lstat and func.  My guess is that
they are both somehow "lstat", but with different memory addresses.


My reporter provided this [1]. I think this is the relevant output:

=== short test summary info 

FAILED test/test_plugin_usercallback.py::SystemTest::test_local_snapshot 
- As...
FAILED test/test_uniquenessset.py::General::test_ctor_defaults - 
AssertionError
FAILED test/test_uniquenessset.py::General::test_deep_check - 
AssertionError
FAILED 
test/test_uniquenessset.py::General::test_fail_equal_without_equal_to
FAILED test/test_uniquenessset.py::General::test_size_mtime - 
AssertionError
FAILED test/test_uniquenessset.py::General::test_unique_myself - 
AssertionError
FAILED 
test/test_uniquenessset.py::General::test_unique_size_but_different_mtime
== 7 failed, 267 passed, 16 skipped in 20.79s 
==

os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
os.lstat=
make: Leaving directory 
'/home/johannes/rpmbuild/BUILD/backintime-1.5.3-build/backintime-1.5.3-rc1/common'


RPM build errors:



[1] -- 





--
https://mail.python.org/mailman/listinfo/python-list

Re: shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[Christian Buhtz via Python-list]

Hello Barry,

thank you for your reply and clarifying the Fedora aspects.

Am 25.10.2024 00:44 schrieb Barry:

What do you mean by the real file sustem?

You cannot write to the /usr file system. Is that what your tests do?
If so that needs changing.


Asking the right questions brings up to important details. While I was 
writing and trying to explain that the relevant test does use 
""tempfile.TemporaryDirectory" as a context, I realized that "PyFakeFS" 
is used in the back [1].


But that makes me wonder. On a "regular" system all tests are running. 
So the issue might exist because of a combination of 3 factors: 
shutil.rmtree(), PyFakeFS in a chroot/mock build environment.


[1] -- 


--
https://mail.python.org/mailman/listinfo/python-list

Re: shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[Christian Buhtz via Python-list]

Am 25.10.2024 09:06 schrieb Christian Buhtz via Python-list:

On a "regular" system all tests are running.


To clarify: "regular" does not exclude PyFakeFS. It means on my own 
local development machine and on the TravsCI machines (Ubuntu 22 with 
Python 3.9 up to 3.13) and using PyFakeFS in that test, everything is 
fine.

Only when mock/chroot is involved that happens.
--
https://mail.python.org/mailman/listinfo/python-list

shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[Christian Buhtz via Python-list]

Hello,
I am upstream maintainer of "Back In Time" [1] investigating an issue a 
distro maintainer from Fedora reported [2] to me.


On one hand Fedora seems to use a tool called "mock" to build packages 
in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write 
to the real file system.
One test fails because a temporary directory is cleaned up using 
shutil.rmtree(). Please see the output below.


I am not familiar with Fedora and "mock". So I am not able to reproduce 
this on my own.
It seems the Fedora maintainer also has no clue how to solve it or why 
it happens.


Can you please have a look (especially at the line "assert func is 
os.lstat").
Maybe you have an idea what is the intention behind this error raised by 
an "assert" statement inside "shutil.rmtree()".


Thanks in advance,
Christian Buhtz

[1] -- 
[2] -- 

__ General.test_ctor_defaults 
__

self = 
def test_ctor_defaults(self):
"""Default values in constructor."""

  with TemporaryDirectory(prefix='bit.') as temp_name:

test/test_uniquenessset.py:47:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

/usr/lib64/python3.13/tempfile.py:946: in __exit__
self.cleanup()
/usr/lib64/python3.13/tempfile.py:950: in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
/usr/lib64/python3.13/tempfile.py:930: in _rmtree
_shutil.rmtree(name, onexc=onexc)
/usr/lib64/python3.13/shutil.py:763: in rmtree
_rmtree_safe_fd(stack, onexc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

stack = []
onexc = .onexc at 
0xb39bc860>

def _rmtree_safe_fd(stack, onexc):
# Each stack item has four elements:
# * func: The first operation to perform: os.lstat, os.close or 
os.rmdir.
#   Walking a directory starts with an os.lstat() to detect 
symlinks; in
#   this case, func is updated before subsequent operations and 
passed to

#   onexc() if an error occurs.
# * dirfd: Open file descriptor, or None if we're processing the 
top-level
#   directory given to rmtree() and the user didn't supply 
dir_fd.
# * path: Path of file to operate upon. This is passed to 
onexc() if an

#   error occurs.
# * orig_entry: os.DirEntry, or None if we're processing the 
top-level
#   directory given to rmtree(). We used the cached stat() of 
the entry to

#   save a call to os.lstat() when walking subdirectories.
func, dirfd, path, orig_entry = stack.pop()
name = path if orig_entry is None else orig_entry.name
try:
if func is os.close:
os.close(dirfd)
return
if func is os.rmdir:
os.rmdir(name, dir_fd=dirfd)
return

# Note: To guard against symlink races, we use the standard
# lstat()/open()/fstat() trick.

  assert func is os.lstat

E   AssertionError
/usr/lib64/python3.13/shutil.py:663: AssertionError

--
https://mail.python.org/mailman/listinfo/python-list

Re: shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[Christian Buhtz via Python-list]

As you can see in the linked issue it seems it was an incompatibility
between the version of Python and PyFakeFS.

In the end it was a Fedora packaging bug because that pyfakefs version
was not compatible with Python 3.13.

Thanks in advance for helping out.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strategies for avoiding having to use --break-system-packages with pip

[Christian Buhtz via Python-list]

Hello Chris,

I do have similar "problems" and still try to get used to the "new way".

Other might correct me. I am not sure yet.

To my current understanding the way to go is to install Python 
applications via "pipx". That make the application available in your 
system but also isolate it in its own virtual environment. Of course you 
should prefer to install applications from your GNU/Linux distros 
official repository if available.


If you install a Python package (library, not an application) you should 
create your own Python environment via venv for example. Pipx is not 
intended to install Python packages that are not applications.


Regrads,
Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Trailer for upcoming Python documentary

[Christian Buhtz via Python-list]

Am 18.05.2025 22:16 schrieb Larry Martell via Python-list:

https://youtu.be/pqBqdNIPrbo?si=P2ukSXnDj3qy3HBJ


Awesome! Which release channels will be used? How can we pay?
--
https://mail.python.org/mailman/listinfo/python-list