[issue35319] pkgutil.get_data() is a wrapper for a deprecated class
New submission from Kevin Norris : pkgutil.get_data()'s documentation[1] says it is a wrapper for importlib.abc.ResourceLoader.get_data(), but the latter's documentation[2] says the whole class is deprecated since 3.7. Please either: A. Formally deprecate pkgutil.get_data() (and ideally provide a "nice" alternative wrapper, so that I don't have to muck about with importlib's endless heterarchy of opaque objects which return other opaque objects). B. Modify pkgutil.get_data() to use ResourceReader instead of ResourceLoader. C. (A) or (B) has already been done, just document it. [1]: https://docs.python.org/3/library/pkgutil.html#pkgutil.get_data [2]: https://docs.python.org/3.8/library/importlib.html#importlib.abc.ResourceLoader -- assignee: docs@python components: Documentation, Library (Lib) messages: 330456 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: pkgutil.get_data() is a wrapper for a deprecated class type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
Kevin Norris added the comment: There is none. It raises a TypeError. See https://docs.python.org/3/reference/expressions.html#value-comparisons -- ___ Python tracker <https://bugs.python.org/issue34365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
New submission from Kevin Norris : The 3.x datetime documentation contains the following footnote: > In other words, date1 < date2 if and only if date1.toordinal() < > date2.toordinal(). In order to stop comparison from falling back to the > default scheme of comparing object addresses, date comparison normally raises > TypeError if the other comparand isn’t also a date object. However, > NotImplemented is returned instead if the other comparand has a timetuple() > attribute. This hook gives other kinds of date objects a chance at > implementing mixed-type comparison. If not, when a date object is compared to > an object of a different type, TypeError is raised unless the comparison is > == or !=. The latter cases return False or True, respectively. But in 3.x, comparison no longer falls back to comparing object addresses. Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course). But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around. -- assignee: docs@python components: Documentation messages: 323314 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses" versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28383] __hash__ documentation recommends naive XOR to combine but this is suboptimal
New submission from Kevin Norris: The documentation for __hash__ contains this text: "The only required property is that objects which compare equal have the same hash value; it is advised to somehow mix together (e.g. using exclusive or) the hash values for the components of the object that also play a part in comparison of objects." The recommendation of "using exclusive or" is likely to result in programmers naively doing this: def __hash__(self): return hash(self.thing1) ^ hash(self.thing2) ^ hash(self.thing3) In the event that (say) self.thing1 and self.thing2 have almost or exactly the same hash (with "almost" referring to bitwise differences rather than integral distance), this wipes out most or all of the entropy from both values and greatly increases the likelihood of hash collisions. Indeed, Python's own tuple type does not do this (while it does use XOR, it also does some other math to ensure the bits are as mixed up as is practical).[1] Because the correct algorithm is both nontrivial to implement and already exists in the tuple type's __hash__, I propose that the documentation be updated to recommend something like the following: def __hash__(self): return hash((self.thing1, self.thing2, self.thing3)) One possible wording: "The only required property is that objects which compare equal have the same hash value; it is advised to mix together the hash values of the components of the object that also play a part in comparison of objects by packing them into a tuple and hashing the tuple: [code example]" [1]: https://hg.python.org/cpython/file/fca5c4a63251/Objects/tupleobject.c#l348 -- assignee: docs@python components: Documentation messages: 278229 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: __hash__ documentation recommends naive XOR to combine but this is suboptimal type: performance versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module
Kevin Norris added the comment: >It could be misleading saying “the name of the current package”, because the >import could be relative to the a higher level parent package if more than one >dot is specified. While this is correct, Python still uses __package__ to determine what to import in that case. I simply replaced "__package__" with "the name of the current package" to make it easier to read, much as the original text replaces "__name__" with "the name of the current module." >Then point out that relative imports won’t work with ``python file.py`` or >interactive mode, but don’t mention “-m” (or the other ways to run scripts and >modules). SGTM if you can find a reasonable way of phrasing that. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module
New submission from Kevin Norris: The tutorial contains this statement: Note that relative imports are based on the name of the current module. Since the name of the main module is always "__main__", modules intended for use as the main module of a Python application must always use absolute imports. See <https://docs.python.org/3/tutorial/modules.html#intra-package-references>. The wording is slightly different in the 2.7 version of the tutorial to account for the existence of implicit relative imports, but it clearly states that explicit relative imports suffer from this limitation. As of PEP 366, this is no longer true. You can do (explicit) relative imports in the main module just fine (though with some minor caveats w.r.t. using the -m flag vs. specifying the .py file directly). PEP 366 has a Python-Version of 2.6, 3.0, so every sufficiently recent version of the tutorial is wrong. It's probably not a good idea to get too far into those caveats in the tutorial. I'd suggest wording like this: Note that relative imports are based on the name of the current package. If Python is invoked with the -m switch, it can determine the package name automatically, but if it is invoked directly as ``python file.py``, relative imports will not work because Python doesn't know what package file.py belongs to. It might be worth mentioning __package__ here, too, but we don't want to get too far down the rabbit hole of trivia (e.g. PEP 366 discusses sys.path manipulation, and for that you probably want to use __file__ instead of hard-coding the path, and then you have to talk about zipimports, and then, and then, and then...!). (For the record, is the 2.7 tutorial still under active support? Is it okay to report bugs in it?) -- assignee: docs@python components: Documentation messages: 258650 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: Tutorial incorrectly claims that (explicit) relative imports don't work in the main module type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24132] Direct sub-classing of pathlib.Path
Kevin Norris added the comment: If I were designing pathlib from scratch, I would not have a separate Path class. I would instead do something like this: In pathlib.py: if os.name == 'nt': Path = WindowsPath else: Path = PosixPath Alternatively, Path() could be a factory function that picks one of those classes at runtime. Of course, that still leaves the issue of where to put the method implementations which currently live in Path. We could change the name of Path to _Path and use the code above to continue providing a Path alias, but that might be too confusing. Another possibility is to pull those methods out into top-level functions and then alias them into methods in WindowsPath and PosixPath (perhaps using a decorator-like-thing to pass the flavor, instead of attaching it to the class). The main thing, though, is that Path should not depend on its subclasses. That really strikes me as poor design, since it produces issues like this one. -- nosy: +Kevin.Norris ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24132 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22299] resolve() on Windows makes some pathological paths unusable
Kevin Norris added the comment:
I'm a little concerned about this fix. In particular, if I understand the
design of the patch correctly, it is intended to produce this behavior:
Path('C:/foo').resolve() != Path('//?/C:/foo').resolve()
Since both paths are valid and both paths refer to the same file, some
developers may find this result counterintuitive. The Path.resolve() docs do
not expressly forbid it, however.
How many developers assume Path.resolve() is always the same for the same file?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22299
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22299] resolve() on Windows makes some pathological paths unusable
New submission from Kevin Norris:
Run Python as an administrator:
import pathlib
pth = pathlib.Path('//?/C:/foo.')
pth.mkdir()
pth.resolve().rmdir()
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python34\lib\pathlib.py, line 1141, in rmdir
self._accessor.rmdir(self)
File C:\Python34\lib\pathlib.py, line 323, in wrapped
return strfunc(str(pathobj), *args)
FileNotFoundError: [WinError 2] The system cannot find the file specified:
'C:\\foo.'
pth.rmdir()
You do not need to be an administrator so long as you can create a directory in
the requested location, but the \\?\ prefix only works with absolute paths so
it's easier to demonstrate in the root of the drive.
--
components: Library (Lib), Windows
messages: 226060
nosy: Kevin.Norris
priority: normal
severity: normal
status: open
title: resolve() on Windows makes some pathological paths unusable
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22299
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22299] resolve() on Windows makes some pathological paths unusable
Kevin Norris added the comment:
When the directory name is '...', the error is different:
pth = pathlib.Path('//?/C:/...')
pth.mkdir()
pth.resolve().rmdir()
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python34\lib\pathlib.py, line 1141, in rmdir
self._accessor.rmdir(self)
File C:\Python34\lib\pathlib.py, line 323, in wrapped
return strfunc(str(pathobj), *args)
PermissionError: [WinError 5] Access is denied: 'C:\\...'
pth.rmdir()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22299
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21832] collections.namedtuple does questionable things when passed questionable arguments
New submission from Kevin Norris: Code such as this: class Foo: def __str__(self): # Perhaps this value comes from user input, or # some other unsafe source return something_untrusted def isidentifier(self): # Perhaps it returns false in some esoteric case # which we don't care about. Assume developer # did not know about str.isidentifier() and # the name clash is accidental. return True collections.namedtuple(Foo(), ()) ...may result in arbitrary code execution. Since the collections documentation does not say that such things can happen, this could result in highly obscure security vulnerabilities. The easiest fix is to simply call str() on the typename argument to namedtuple(), as is currently done with the field_names argument. But IMHO this is like cleaning up an SQL injection with string sanitizing, instead of just switching to prepared statements. The switch to prepared statements route is conveniently available as a rejected patch for issue 3974. The above code will not work as such in Python 2.7, but more elaborate shenanigans can fool the sanitizing in that version as well. This issue was originally reported on secur...@python.org, where I was advised to file a bug report normally. -- components: Library (Lib) messages: 221394 nosy: Kevin.Norris priority: normal severity: normal status: open title: collections.namedtuple does questionable things when passed questionable arguments versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21832 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
