[issue41122] functools.singledispatchfunction has confusing error message if no positional arguments are passed in
Change by Mark Grandi : -- title: functools.singledispatchfunction has confusing error message if no position arguments are passed in -> functools.singledispatchfunction has confusing error message if no positional arguments are passed in ___ Python tracker <https://bugs.python.org/issue41122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41122] functools.singledispatchfunction has confusing error message if no position arguments are passed in
New submission from Mark Grandi :
this is with python 3.8:
```plaintext
PS C:\Users\mark> py -3 --version --version
Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit
(AMD64)]
```
So when using functools.singledispatch or functools.singledispatchmethod, you
need to provide at least 1 positional argument so it can dispatch based on the
type of said argument
however, with `functools.singledispatchmethod`, you get an error message that
is confusing and not obvious what the problem is.
Example with `functools.singledispatchmethod`:
```
class NegatorTwo:
@singledispatchmethod
def neg(arg):
raise NotImplementedError("Cannot negate a")
@neg.register
def _(self, arg: int):
return -arg
@neg.register
def _test(self, arg: bool):
return not arg
if __name__ == "__main__":
n = NegatorTwo()
print(n.neg(0))
print(n.neg(False))
print(n.neg(arg=0))
```
you end up getting:
```plaintext
PS C:\Users\mark> py -3 C:\Users\mark\Temp\singledisp.py
0
True
Traceback (most recent call last):
File "C:\Users\mark\Temp\singledisp.py", line 58, in
print(n.neg(arg=0))
File "C:\Python38\lib\functools.py", line 910, in _method
method = self.dispatcher.dispatch(args[0].__class__)
IndexError: tuple index out of range
```
but with just regular `functools.singledispatch`:
```plaintext
@functools.singledispatch
def negate_func(arg):
raise NotImplementedError("can't negate")
@negate_func.register
def negate_int_func(arg:int):
return -arg
@negate_func.register
def negate_bool_func(arg:bool):
return not arg
if __name__ == "__main__":
print(negate_func(0))
print(negate_func(False))
print(negate_func(arg=0))
```
you get an error that tells you what actually is wrong:
```plaintext
PS C:\Users\mark> py -3 C:\Users\mark\Temp\singledisp.py
0
True
Traceback (most recent call last):
File "C:\Users\mark\Temp\singledisp.py", line 63, in
print(negate_func(arg=0))
File "C:\Python38\lib\functools.py", line 871, in wrapper
raise TypeError(f'{funcname} requires at least '
TypeError: negate_func requires at least 1 positional argument
```
it seems that the code in `functools.singledispatchmethod` needs to check to
see if `args` is empty, and throw a similar (if not the same) exception as
`functools.singledispatch`
--
components: Library (Lib)
messages: 372406
nosy: markgrandi
priority: normal
severity: normal
status: open
title: functools.singledispatchfunction has confusing error message if no
position arguments are passed in
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41122>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39679] functools: singledispatchmethod doesn't work with classmethod
Mark Grandi added the comment: same issue here, if we can't fix it then maybe we should edit the documentation to not suggest that @classmethod works? -- nosy: +markgrandi ___ Python tracker <https://bugs.python.org/issue39679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38805] locale.getlocale() returns a non RFC1766 language code
New submission from Mark Grandi :
It seems that something with windows 10, python 3.8, or both changed where
`locale.getlocale()` is now returning strange results
According to the documentation:
https://docs.python.org/3/library/locale.html?highlight=locale%20getlocale#locale.getlocale
, the language code should be in RFC1766 format:
Language-Tag = Primary-tag *( "-" Subtag )
Primary-tag = 1*8ALPHA
Subtag = 1*8ALPHA
Whitespace is not allowed within the tag.
but in python 3.8, I am getting a language code that doesn't meet RFC1766 specs:
PS C:\Users\auror> py -3
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
('English_United States', '1252')
('en_US', 'cp1252')
>>>
on the same machine, with python 3.7.4:
PS C:\Python37> .\python.exe
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
(None, None)
('en_US', 'cp1252')
>>>
also interesting that the encoding is different in py3.8 between
`locale.getlocale()` and `locale.getdefaultlocale()`, being '1252' and
'cp1252', this might not be related though as it was present in python 3.7.4
these issues might be related, but stuff found hwen searching for 'locale' bugs:
https://bugs.python.org/issue26024
https://bugs.python.org/issue37945
--
components: Library (Lib)
messages: 356637
nosy: markgrandi
priority: normal
severity: normal
status: open
title: locale.getlocale() returns a non RFC1766 language code
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under "optional arguments"
Mark Grandi added the comment: Is there anything that can be done to help this issue move along? I just ran into it just now -- nosy: +markgrandi ___ Python tracker <https://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13516] Gzip old log files in rotating handlers
Mark Grandi added the comment: While I will say that is slightly easier than subclassing, it still requires a function, or a variation of that to be present in every project that wants to have a RotatingHandler + compression, and extra lines if you use logging.config.dictConfig, as you will need to reference an external function rather than just specifying the filename = *.gz I don't see this this simple feature would add much maintainer overhead, as lzma.open, bz2.open and gz.open are all pretty simple to use and are all already in the stdlib -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13516] Gzip old log files in rotating handlers
Mark Grandi added the comment: I just ran into this myself, and would challenge the notion that just because few people complain about the fact that built in compression isn't built in for logging handlers (such as TimedRotatingFileHandler), that it isn't a needed feature. This is such a common feature in pretty much everything that it would be nice to have it built in rather than having a custom RotatingHandler subclass that just compresses the logs and does nothing else in every project I work with. While not python, i searched github for logback/slf4j (java logging framework) entries for their equivilent of TimedRotatingFileHandler and I found quite a few results: https://github.com/search?utf8=%E2%9C%93=fileNamePattern%2F%3E*.gz+language%3AXML=Code=searchresults you don't even have to change the API of it, it could act the same way as the tarfile module, where if the 'filename' argument ends in one of "bz2", "gz" or 'xz" then it is compressed with that compression type, and if not, then it doesn't compress it (what it does now) and, that is how logback/slf4j does it as well (http://logback.qos.ch/manual/appenders.html#fwrpFileNamePattern) -- nosy: +markgrandi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Mark Grandi added the comment: Oh, I didn't realize that both REG_QWORD and REG_QWORD_LITTLE_ENDIAN had the same value, that works then. -- resolution: fixed -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Mark Grandi added the comment: in 'test_winreg.py', there should probably be a test that covers REG_QWORD_LITTLE_ENDIAN, even if they are essentially equivalent Also, in Py2Reg and Reg2Py, it seems that both are missing the 'case' clause for REG_QWORD_LITTLE_ENDIAN as well case REG_QWORD: case REG_QWORD_LITTLE_ENDIAN: And sure, i would have the documentation changes listed in 'Doc/whatsnew/3.6.rst'. And now that I think about it, the documentation in '/Doc/library/winreg.rst' should probably mention that REG_QWORD and REG_QWORD_LITTLE_ENDIAN are new as of python 3.6 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Mark Grandi added the comment: @hakril: ok, that makes sense, I'm not a windows/win32 programmer by any means so I was mostly going on the microsoft web docs also the patch by hakril includes the documentation from my patch, so that patch should be the one considered (as a FYI) -- versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Mark Grandi added the comment: why do you say that QWORD is not present in windows.h? I found it here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx typedef unsigned __int64 QWORD; -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Mark Grandi added the comment: I Attempted to modify Reg2Py and Py2Reg to handle the QWORDs, this is assuming that the only thing that needs to change is just using PyLong_AsUnsignedLongLong()/FromUnsignedLongLong() instead of just UnsignedLong() the patch has the same changes as the 'part1' patch + the Py2Reg and Reg2Py changes -- Added file: http://bugs.python.org/file37825/winreg_add_qword_constants_part2_markgrandi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
New submission from Mark Grandi: The winreg module has constants for the different Windows registry types: https://docs.python.org/3/library/winreg.html?highlight=winreg#value-types It also links to the Microsoft documentation on the registry types, and I noticed that python doesn't have constants for 2 of the types (really just 1), REG_QWORD and REG_QWORD_LITTLE_ENDIAN (same as REG_QWORD). So I added the constants in winreg.c, which I think is right, as its the same format as the other ones, and I edited the documentation inside of winreg.c, which is the same changes i made to the docs in winreg.rst, except it doesn't have the markdown/rst/whatever formatting markers. I also made notes on REG_DWORD_LITTLE_ENDIAN that it is equivalent to REG_DWORD. I also tested to make sure that the documentation builds fine, but I haven't tested building python with the winreg.c changes, as I don't have access to a windows computer that can compile it at the moment. Some concerns: 1: I have no idea if REG_QWORD is defined on 32 bit windows, I would assume it would be, but I can't check at the moment. 2: There should probably be some switch statement entries in the Reg2Py() and Py2Reg() functions that deal with QWORDs, and dealing with if the python build is 32 bit vs 64 bit. I'm not comfortable with the python C internals to do that myself. My initial patch is attached, with the documentation + changes to winreg.c that just add the constants to the module -- components: Windows files: winreg_add_qword_constants_part1_markgrandi.patch keywords: patch messages: 232442 nosy: markgrandi, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Winreg module doesn't support REG_QWORD, small DWORD doc update versions: Python 3.4 Added file: http://bugs.python.org/file37411/winreg_add_qword_constants_part1_markgrandi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
New submission from Mark Grandi: In the asyncio documentation, specifically asyncio-eventloop.rst, in the description for BaseEventLoop.call_at(), it has: Arrange for the *callback* to be called at the given absolute timestamp *when* (an int or float), using the same time reference as :meth:`time`. This links to the time module's time.time() method, which is incorrect as well as confusing, as the event loop's clock is NOT the same as time.time(), and it even says so on the top of the 'delayed calls' section According the python documentation guide, it should have a period before it to make it refer to a method that is within the same module. I however decided to change it to `BaseEventLoop.time()`, because when i see the text 'time()', even if it links to the right method, still makes me think of time.time(), which is again confusing and generally incorrect. Attached is a patch file, its a trivial change, but i did regenerate the docs and confirmed that it works, and clicking the link takes you to the right method in the page. -- assignee: docs@python components: Documentation files: markgrandi_asyncio-eventloop.rst.patch keywords: patch messages: 230764 nosy: docs@python, markgrandi priority: normal severity: normal status: open title: Typo in asyncio-eventloop.rst, time() link is wrong type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37141/markgrandi_asyncio-eventloop.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22808 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
Mark Grandi added the comment: I don't have an idea how to make it easier and still meet all/most requirements and without cluttering up the api. That is what i mentioned in my original post, a lot of the time users just _don't care_ about a lot of the stuff that a tar archive can store (permission bits, uid/gid, etc). Say i'm on my mac. I can select a bunch of files and then right click - compress. Pretending that it saves the resulting archive as a .tar.gz rather then a .zip, that's really it. The user doesn't care about the permission bits, uid/gid or any of that, they just want a compressed archive. While the api does do a good job of exposing the low level parts of the api with TarInfo, being able to set all the stuff manually or have it figured out through gettarinfo() calling os.stat() My original reasoning for this bug report is that its way too hard to do it for in-memory files, as those don't have file descriptors so os.stat() fails. But why can't we just make it so: gettarinfo() is called * if it's a regular file, it continues as it does not * if it is NOT a regular file (no file descriptor), then it returns a TarInfo object with the 'name' and 'size' set, and the rest of the fields set to default values (the current user's uid and gid, acceptable permission bits and the correct type for a regular file (REGFILE?) * if gettarinfo() is called with a non regular file and it's name has a slash, then its assumed to be a folder structure, so then it will add the correct TarInfo with type = DIRTYPE and then insert the file underneath that folder, sorta how zipfile works. I looked at the tarfile.py code and it seems it does this already. This just adds the needed easy use case for the tarfile module, as the complicated low level api is there, we just need something that users just want to create an archive without worrying too much about the low level stuff. So then they can just: import tarfile, io fileToAdd = io.BytesIO(hello world!.encode(utf-8)) with tarfile.open(sample.tar, mode=w) as tar: # this TarInfo object has: #name = 'somefile.txt' #type = REGTYPE (or whatever is 'just a regular file') #uid = 501, gid = 20, gname=staff, uname=markgrandi, mode=644 tmpTarInfo = tar.gettarinfo(somefile.txt, fileToAdd) tar.addfile() So basically its just having defaults for the TarInfo object when gettarinfo() is given a file that doesn't have a file descriptor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
Mark Grandi added the comment: I still don't see why TarFile.add() can't be changed to accept a file like object so users don't have to fumble around with a TarInfo object when they just want add a file like object, and don't care about the permission bits and whatnot. It also says un the TarInfo section that you get those objects from gettarinfo(), and its not clear (at least to me) that you can just manually construct one, and that you only need the size property set. I still the easiest way to solve this is to have gettarinfo() or add() accept file like objects that don't have file descriptors, as it would go a long way to simplifying the use of this module as well. (in zip file you don't ever have to worry about ZipInfo objects unless you need them...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
Mark Grandi added the comment: I was just thinking that if os.stat fails, then you try getting the size by just calling len() on it, as stuff like io.BytesIO and io.StringIO will respond to that. But if we are not changing the behavior of the API, at the very least there needs to be documentation changes / an example of adding a file that does not have a file descriptor. I can do that if needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
New submission from Mark Grandi:
So I ran into this problem today, where near impossible to create a
tarfile.TarFile object, then add files to the archive, when the files are in
memory file-like objects (like io.BytesIO, io.StringIO, etc)
code example:
###
import tarfile, io
tarFileIo = io.BytesIO()
tarFileObj = tarfile.open(fileobj=tarFileIo, mode=w:xz)
fileToAdd = io.BytesIO(hello world!.encode(utf-8))
# fixes AttributeError: '_io.BytesIO' object has no attribute 'name'
fileToAdd.name=helloworld.txt
# fails with 'io.UnsupportedOperation: fileno'
tarInfo = tarFileObj.gettarinfo(arcname=helloworld.txt, fileobj=fileToAdd)
# never runs
tarFileObj.addfile(tarInfo, fileobj=fileToAdd)
###
this was previously reported as this bug: http://bugs.python.org/issue10369 but
I am unhappy with the resolution of its not a bug, and the 'hack' that Lars
posted as a solution. My reasons:
1: The zipfile module supports writing in memory files / bytes , using the
following code (which is weird but it works)
tmp = zipfile.ZipFile(tmp.zip, mode=w)
import io
x = io.BytesIO(hello world!.encode(utf-8))
tmp.writestr(helloworld.txt, x.getbuffer())
tmp.close()
2: the 'hack' that Lars posted, while it works, this is unintuitive and
confusing, and isn't the intended behavior. What happens if your script is
cross platform, what file do you open to give to os.stat()? In the code posted
it uses open('/etc/passwd/') for the fileobj parameter to gettarinfo(), but
that file doesn't exist on windows, now not only are you doing this silly hack,
you have to have code that checks platform.system() to get a valid file that is
known to exist for every system, or use sys.executable, except the
documentation for that says it can return None or an empty string.
3: it is easy to fix (at least to me), in tarfile.gettarinfo(), if fileobj is
passed in, and it doesn't have a fileno, then to create the TarInfo object, you
set 'name' to be the arcname parameter, size = len(fileobj), then have default
(maybe overridden by keyword args to gettarinfo()) values for
uid/gid/uname/gname.
On a random tar.gz file that I downloaded from sourceforge, the uid/gid are
'500' (when my gid is 20 and uid is 501), and the gname/uname are just empty
strings. So its obvious that those don't matter most of the time, and when they
do matter, you can modify the TarInfo object after creation or pass in values
for them in a theoretical keywords argument to gettarinfo().
If no one wants to code this I can provide a patch, I just want the previous
bug report's status of not a bug to be reconsidered.
--
components: Library (Lib)
messages: 225374
nosy: markgrandi
priority: normal
severity: normal
status: open
title: tarfile can't add in memory files (reopened)
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22208
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Changes by Mark Grandi markgra...@gmail.com: -- nosy: +markgrandi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Mark Grandi added the comment: are any more changes needed to the code that is already posted as a patch in this bug report? or are the changes you wanted to see happen in msg157669 not happen yet? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Mark Grandi added the comment:
Where are you even seeing these json property lists? I just checked the most
recent documentation for NSPropertyListSerialization, and they have not updated
the enum for NSPropertyListFormat. It seems that if even Apple doesn't support
writing json property lists with their own apis then we shouldn't worry about
supporting it?
see:
https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSPropertyListSerialization_Class/Reference/Reference.html
enum {
NSPropertyListOpenStepFormat = kCFPropertyListOpenStepFormat,
NSPropertyListXMLFormat_v1_0 = kCFPropertyListXMLFormat_v1_0,
NSPropertyListBinaryFormat_v1_0 = kCFPropertyListBinaryFormat_v1_0
}; NSPropertyListFormat;
typedef NSUInteger NSPropertyListFormat;
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14455
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Mark Grandi markgra...@gmail.com added the comment: Hi, I noticed in the latest message that d9pounces posted that JSON format does not allow dates and data, so XML is used by default to write files.. Rthe XML version of plists also do not really 'support' those types, and they are converted as follows: NSData - Base64 encoded data NSDate - ISO 8601 formatted string (from http://en.wikipedia.org/wiki/Property_list#Mac_OS_X) So really it should be the same thing when converting to json no? -- nosy: +markgrandi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
