Re: Confusing behavior of PYTHONWARNINGS
Op 16/09/2023 om 10:17 schreef Meowxiik via Python-list: Hello, For the third time I am trying to work with `PYTHONWARNINGS` filter, and for the third time I am having a terrible time. I'd like to seek your assistance, I have a few questions: **Question 1:** Does the environment variable only matter at python interpreter startup time? If I set the same variable before python start, it seems to work, but it doesn't work trough os.environ. It does appear to be hinted at in the docs, but imho not clear enough. Yes, environment variables are only relevant when the interpreter starts up. The documentation (on the command line environment in general, not specific to PYTHONWARNINGS) says "These environment variables influence Python’s behavior, they are processed before the command-line switches other than -E or -I.". That implies they don't do anything if changed after startup. More specific to warnings, the documentation for the -W option (which is referenced in the PYTHONWARNINGS environment variable) says "Warnings can also be controlled using the PYTHONWARNINGS environment variable and from within a Python program using the warnings module." implying the same, and giving an alternative for controlling warnings from within Python. **Question 2:** Why do the following filters not work for filtering `urllib3.exceptions.InsecureRequestWarning` - `PYTHONWARNINGS=ignore:::urllib3.exceptions` - `PYTHONWARNINGS=ignore:::urllib3` - `PYTHONWARNINGS=ignore:::urllib3.exceptions` - `PYTHONWARNINGS=ignore::urllib3.exceptions.InsecureRequestWarning` None of these filter the warning. The last one has the audacity to complain about "invalid module name: 'urllib3.exceptions'" which is very confusing to me, given that that specific module is fully importable during runtime, which I have tested. The only one I managed to get working is `ignore:Unverified`, where "Unverified" is the first word of the actual message, however I truly strongly dislike this solution. I'd like to try this out myself, but I'm not familiar with urllib3 and I can't get to issue that warning; instead it throws exceptions (I tried a simple request with some of the URL's listed on https://badssl.com). How can I get urllib3 to issue that warning? Also, which version of Python are you using, and on which operating system? -- "Most of us, when all is said and done, like what we like and make up reasons for it afterwards." -- Soren F. Petersen -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP668 / pipx and "--editable" installs
On 2023-09-15 14:15:23 +, c.buhtz--- via Python-list wrote: > I tried to install it via "pipx install -e .[develop]". It's pyproject.toml > has a bug: A missing dependency "dateutil". But "dateutil" is not available > from PyPi for Python 3.11 (the default in Debian 12). But thanks to great > Debian they have a "python3-dateutil" package. I installed it. Sidenote: PyPI does have several packages with "dateutil" in their name. From the version number (2.8.2) I guess that "python-dateutil" is the one packaged in Debian 12. This can be installed via pip: % lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm (dateutil) % pip install python-dateutil Collecting python-dateutil Downloading python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB) 247.7/247.7 kB 3.1 MB/s eta 0:00:00 Collecting six>=1.5 Downloading six-1.16.0-py2.py3-none-any.whl (11 kB) Installing collected packages: six, python-dateutil Successfully installed python-dateutil-2.8.2 six-1.16.0 hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doc call `__init__` as a method rather than function?
Op 15/09/2023 om 15:05 schreef anthony.flury via Python-list: Like all of the other methods you shouldn't ever need to call them directly : these are called dunder methods and represent functions and features which are called by other operators. The only recommended way to call A.__init__ is to create an instance of A : obj = A() - the __init__ method gets called automatically with a newly created object. There is an exception: super().__init__() to call the base class's __init__ (normally from the derived class's __init__) -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doc call `__init__` as a method rather than function?
Thanks for all repliers: @Tony & @Cameron, I do know related stuffs about the dunder methods, and your explanation just make it to be more clear, thank you! @Roel, you just caught everyone here, we do miss it even though we know it and use it regularly! @Clara > its both, depending on how you're getting it. Might can be more clear: its both, depending on how you're using/getting it. And I think I can mark this question as resolved, and with the following conclusions: As @Clara mentioned, we need to know that "all methods are functions", so we do can call `__init__` as a method or a function, or we can be avoid to have such discussion like Dan, and call it "the initializer" (However, you will need to think about “what is this is” for other functions :). ). As @Alan mentioned, and according to the Wikipedia, in computer programming field, "method" is: > A method in object-oriented programming (OOP) is a procedure associated with > an object, and generally also a message. An object consists of state data and > behavior; these compose an interface, which specifies how the object may be > used. A method is a behavior of an object parametrized by a user. For `__init__` and other functions in classes, we usually use them by writing code `obj.action()`, so we usually will call them as methods, so here, we call `action` or `__init__` as a method. However, if you use them by writing code `Clz.action(obj)`, then you'd better (or must?) to call them as functions, and it is not a "daily use case" in daily development, and in some languages, this behavior won't even be possible. **So, its kinda a "Majority rule" to call `__init__` (functions in classes) as a method.** === BTW, in Wikipedia, the "static methods" section is a very interesting: > Static methods are meant to be relevant to all the instances of a class > rather than to any specific instance. This explanation might can "group" some functions back to "methods" :) However, let's still remember: All methods are functions, but not every function is a method. Thanks again for helping, you guys are really nice! -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP668 / pipx and "--editable" installs
On 9/18/23 02:16, Peter J. Holzer via Python-list wrote: On 2023-09-15 14:15:23 +, c.buhtz--- via Python-list wrote: I tried to install it via "pipx install -e .[develop]". It's pyproject.toml has a bug: A missing dependency "dateutil". But "dateutil" is not available from PyPi for Python 3.11 (the default in Debian 12). But thanks to great Debian they have a "python3-dateutil" package. I installed it. Sidenote: PyPI does have several packages with "dateutil" in their name. From the version number (2.8.2) I guess that "python-dateutil" is the one packaged in Debian 12. This can be installed via pip: It *is* the case that package name is not always equal to importable name. That certainly occurs in the universe of Python packages on PyPI; it's if anything much more likely on Linux distributions which have to share the package name namespace with a lot more than just Python packages (just for starters, what seems like billions of Perl packages), so you're even more likely to see names like python-foo or python3-foo when the thing you import is foo. That has nothing to do virtualenvs, of course. The use of a virtualenv for a project actually makes it more likely that you discover unstated dependencies, which is generally a good thing. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP668 / pipx and "--editable" installs
On 2023-09-18 10:16 "Peter J. Holzer via Python-list" wrote: > On 2023-09-15 14:15:23 +, c.buhtz--- via Python-list wrote: > > I tried to install it via "pipx install -e .[develop]". It's > > pyproject.toml has a bug: A missing dependency "dateutil". But > > "dateutil" is not available from PyPi for Python 3.11 (the default > > in Debian 12). But thanks to great Debian they have a > > "python3-dateutil" package. I installed it. > > This can be installed via pip: I'm aware of this. But this is not the question. I would like to know and understand why my via "pipx" installed package "hyperorg" is not able to see the systems packages installed via "apt install python3-dateutils"? Is this the usual behavior? Is this correct? What is the design decision behind it? Is it really the intention of PEP668 that pipx-installed packages are not allowed to use system packages? -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP668 / pipx and "--editable" installs
On 9/18/23 12:56, c.buhtz--- via Python-list wrote: On 2023-09-18 10:16 "Peter J. Holzer via Python-list" wrote: On 2023-09-15 14:15:23 +, c.buhtz--- via Python-list wrote: I tried to install it via "pipx install -e .[develop]". It's pyproject.toml has a bug: A missing dependency "dateutil". But "dateutil" is not available from PyPi for Python 3.11 (the default in Debian 12). But thanks to great Debian they have a "python3-dateutil" package. I installed it. This can be installed via pip: I'm aware of this. But this is not the question. I would like to know and understand why my via "pipx" installed package "hyperorg" is not able to see the systems packages installed via "apt install python3-dateutils"? Is this the usual behavior? Is this correct? Yes. By default, the virtualenv contains just what you've installed. It's designed to give you tight control over what's installed, so you can track dependencies, avoid accidental inclusions, etc. As usual, you don't have to accept the default. For example, for the venv module: usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] [--prompt PROMPT] [--upgrade-deps] ENV_DIR [ENV_DIR ...] Creates virtual Python environments in one or more target directories. positional arguments: ENV_DIR A directory to create the environment in. options: -h, --helpshow this help message and exit --system-site-packages Give the virtual environment access to the system site-packages dir. ... -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP668 / pipx and "--editable" installs
On 9/18/2023 2:56 PM, c.buhtz--- via Python-list wrote: On 2023-09-18 10:16 "Peter J. Holzer via Python-list" wrote: On 2023-09-15 14:15:23 +, c.buhtz--- via Python-list wrote: I tried to install it via "pipx install -e .[develop]". It's pyproject.toml has a bug: A missing dependency "dateutil". But "dateutil" is not available from PyPi for Python 3.11 (the default in Debian 12). But thanks to great Debian they have a "python3-dateutil" package. I installed it. This can be installed via pip: I'm aware of this. But this is not the question. I would like to know and understand why my via "pipx" installed package "hyperorg" is not able to see the systems packages installed via "apt install python3-dateutils"? Is this the usual behavior? Is this correct? What is the design decision behind it? Is it really the intention of PEP668 that pipx-installed packages are not allowed to use system packages? One way this could happen is if the hyperorg package got installed by a different version of Python than the system version. I've lost track of just how your installation is set up so this may not apply. But, for example, if the system is using Python 3.10.x and you installed hyperorg using Python 3.11, that would be such a situation. The apt-installed packages will get installed into the system python directories, rather than to the Python 3.11 directories. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Launcher Pops Up When Py-based App Is Running (Mac)
On 17/09/2023 13.20, James Greenham via Python-list wrote: Hello, On the face of it, the Python-Mac mailing list is largely inactive so I'm posting here since it looks like this one is livelier. What happens when doGrab() is called from the REPL, after being 'fed' data you expect is valid? (per a unit-test) What code-level debugging has been exercised? Have you tried running the code in a debugger, in order to step into the (assumed) doGrab error? Sadly, this code is so old as to have grown whiskers. - are all the called-modules, eg webkit and the OpSys; still offering the appropriate interfaces, and continuing to behave in the expected fashion? (anything relevant in those Release Notes?) - in theory, Python 2 will still run. However, a reasonable proportion of today's Python-coders are unlikely to have ever used it. (Sunsetting Python 2 https://www.python.org/doc/sunset-python-2/) - were this code to be written using today's libraries, it is unlikely to look anything like this (which may also be contributing to the dearth of replies) -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
