[issue41376] site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected
Change by Phil Elson : -- keywords: +patch pull_requests: +20740 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21602 ___ Python tracker <https://bugs.python.org/issue41376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41376] site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected
New submission from Phil Elson : The documentation for site.getusersitepackages() states at https://docs.python.org/3.10/library/site.html#site.getusersitepackages: Return the path of the user-specific site-packages directory, USER_SITE. If it is not initialized yet, this function will also set it, respecting PYTHONNOUSERSITE and USER_BASE. Yet the implementation does not agree: ``` $ python -c "import site; print(site.getusersitepackages())" /home/user/.local/lib/python3.7/site-packages $ PYTHONNOUSERSITE=1 python -c "import site; print(site.getusersitepackages())" /home/user/.local/lib/python3.7/site-packages ``` (same result for -s and -I flags) -- assignee: docs@python components: Documentation messages: 374139 nosy: docs@python, pelson priority: normal severity: normal status: open title: site.getusersitepackages() incorrectly claims that PYTHONNOUSERSITE is respected versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Phil Elson added the comment: FWIW - this doesn't appear to have been backported to v2.7.x. As a result, the ./Modules/ld_so_aix reference still exists in _sysconfigdata.py in v2.7.8 (and therefore I was unable to build numpy). The workaround is easy enough, it is just something that is worth noting. -- nosy: +pelson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21917] Python 2.7.7 Tests fail, and math is faulty
Phil Elson added the comment:
I just wanted to say that I am seeing the same issue with similar build flags
for the xlc compiler.
Finding the correct compile flags may well be the problem here.
For the record, since I think this is related to the flags which are being
passed to os.open, I've been looking at the following:
http://bugs.python.org/issue19749
https://github.com/pypa/pip/issues/849
I actually have access to a python2.7 which does work on this OS (which I
didn't compile), which allowed me to identify the following difference:
$ ./python
Python 2.7.8 [C] on aix7
import os; print os..O_NOFOLLOW
137438953472
$ /usr/bin/python
Python 2.7.6 [C] on aix7
import os; print os.O_NOFOLLOW
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'O_NOFOLLOW'
My workaround therefore is to put the following in sitecustomize:
import os; os.__dict__.pop('O_NOFOLLOW', None)
And as a result make test no longer fails.
Any idea what it is we're missing in the configure step which is erroneously
putting O_NOFOLLOW in os?
--
nosy: +pelson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21917
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Phil Elson added the comment:
I didn't see a test case relating to the example in his comment, namely
f.format({0:{}}, 'foo', 5)
Did I miss it?
The example should fail, which it wouldn't have done with the patch previously
proposed. I believe the case is covered by the block:
with self.assertRaises(ValueError):
fmt.format(foo{1}{}, bar, 6)
Though there is no harm in adding another test along the lines of:
with self.assertRaises(ValueError):
fmt.format({0:{}}, bar, 6)
If you think it is worthwhile?
I'm uncertain which documentation to update since the method which has had its
signature updated is private and is called solely by Formatter.vformat .
Cheers,
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13598
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16382] Better warnings exception for bad category
Phil Elson added the comment: Ok. I think I've done all of the actions from the reviews. I'm not sure if I should remove the old patches or not? Thanks, -- Added file: http://bugs.python.org/file29304/pelson_warnings_fix_4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16382 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17351] Fixed python3 descriptor documentation example + removal of explicit object inheritance in docs
New submission from Phil Elson: The example at http://docs.python.org/3.4/howto/descriptor.html#properties does not run due to the old style raise AttributeError, message form. This patch fixes the problem, and also goes through the docs to remove explicit sub-classing from object. The only remaining instances of this now are: $ grep -r -E class .*\(object\)\: Doc/* Doc/howto/pyporting.rst: class UnicodeMixin(object): Doc/reference/compound_stmts.rst: class Foo(object): Doc/tools/sphinxext/pyspecific.py:class PyDecoratorMixin(object): Doc/whatsnew/2.6.rst:class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst:class C(object): Which are all (minus tools/sphinxext/pyspecific) referring to python2 in some context. I'm not bound to fixing the explicit object subclassing, so if it is better off not being here, that's fine. Cheers, -- assignee: docs@python components: Documentation files: pelson_doc_decorator.diff keywords: patch messages: 183458 nosy: docs@python, pelson, rhettinger priority: normal severity: normal status: open title: Fixed python3 descriptor documentation example + removal of explicit object inheritance in docs versions: Python 3.1 Added file: http://bugs.python.org/file29305/pelson_doc_decorator.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16382] Better warnings exception for bad category
Changes by Phil Elson pelson@gmail.com: Added file: http://bugs.python.org/file28072/pelson_warnings_fix_3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16382 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16382] Better warnings exception for bad category
Changes by Phil Elson pelson@gmail.com: Added file: http://bugs.python.org/file28053/pelson_warnings_fix_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16382 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16382] Better warnings exception for bad category
New submission from Phil Elson:
When passing an invalid Warning subclasses to the warnings.warn function, a
bare issubclass exception is raised:
import warnings
warnings.warn('hello world', 'not a valid warning type')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: issubclass() arg 1 must be a class
This exception is consistent accross both Python/_warnings.c and
Lib/warnings.py implementations, but I feel it could be more helpful/explicit
about the nature problem.
To test both cases I have been using the following code (python3.4):
import test.support
py_warnings = test.warnings = test.support.import_fresh_module('warnings',
blocked=['_warnings'])
c_warnings = test.support.import_fresh_module('warnings',
fresh=['_warnings'])
Now:
py_warnings.warn('hello world', '')
Traceback (most recent call last):
File stdin, line 1, in module
File lib/python3.4/warnings.py, line 168, in warn
assert issubclass(category, Warning)
TypeError: issubclass() arg 1 must be a class
c_warnings.warn('hello world', '')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: issubclass() arg 1 must be a class
Additionally, there is a difference in the denotational semantics of None
between the c and py warnings implementation:
py_warnings.warn('Hello world', None)
__main__:1: UserWarning: Hello world
c_warnings.warn('Hello world', None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: issubclass() arg 1 must be a class
I can understand that python does not allow the concept of an optional
positional arguments and therefore it is arguable that the signatures of the
two functions are inevitably going to be different. I defer to someone more
knowledgeable in Python to decide if this is a problem, and whether it should
be made consistent.
Attached is a patch to address these two issues, with associated tests. Please
review (n.b. I am a python developer at heart, and only dabble in C when I have
to, so extra scrutiny on the C would be valuable to me) and I'd be happy to get
any necessary changed applied to the patch asap.
In short, as a result of applying this patch, the following results ensue:
py_warnings.warn('hello world', '')
Traceback (most recent call last):
File stdin, line 1, in module
File lib/python3.4/warnings.py, line 175, in warn
'Got {!r}'.format(Warning, category)) from None
ValueError: category must be a subclass of class 'Warning'.Got ''
c_warnings.warn('hello world', '')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: category must be a subclass of class 'Warning'. Got ''.
c_warnings.warn('hello world', None)
__main__:1: UserWarning: hello world
Thanks!
--
components: Library (Lib)
files: pelson_warnings_fix.diff
keywords: patch
messages: 174421
nosy: pelson
priority: normal
severity: normal
status: open
title: Better warnings exception for bad category
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27824/pelson_warnings_fix.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16382
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Changes by Phil Elson pelson@gmail.com: -- nosy: +pelson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13598 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Phil Elson added the comment:
The current patch fails to catch the fact that auto vs manual numbering has
been used in following corner case:
from string import Formatter
print(Formatter().format({0:{}}, 'foo', 5))
To fix this, without adding state to the formatter instance, some more
information is going to need to be passed to the _vformat method.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13598
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Phil Elson added the comment: Ramchandra's fix looks fairly good, although there is at least one remaining issue (see my last comment). I have attached a patch which addresses (and tests) this. I'd be happy to pick this up if there are any remaining issues that need to be addressed, otherwise: I hope this helps. Thanks, -- Added file: http://bugs.python.org/file27810/pelson_issue13598.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13598 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
