[issue40235] confusing documentation for IOBase.__exit__
Daniel Holth added the comment: Possibly the best io module example I've found https://github.com/python/cpython/blob/master/Lib/_compression.py -- ___ Python tracker <https://bugs.python.org/issue40235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40235] confusing documentation for IOBase.__exit__
Daniel Holth added the comment: Thanks, I'm sorry I didn't save when I was having my strange problem. The io module is still practically undocumented. It should have examples subclasses for each class, perhaps a link to the PEP and a link to a Python implementation of the module. -- stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue40235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams
Change by Daniel Holth : -- nosy: +dholth ___ Python tracker <https://bugs.python.org/issue36129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40233] Awkward to set compression on writeable ZipFile.open()
Daniel Holth added the comment: My mistake. It honors ZipInfo if passed. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40235] confusing documentation for IOBase.__exit__
New submission from Daniel Holth : The io documentation says: IOBase is also a context manager and therefore supports the with statement. In this example, file is closed after the with statement’s suite is finished—even if an exception occurs: with open('spam.txt', 'w') as file: file.write('Spam and eggs!') I read this to mean that my own subclass of io.BufferedIOBase would call close() when used as a context manager. Instead, it is necessary to provide an implementation of __exit__ that calls close() to get this behavior. The documentation lists Mixin Methods, but I couldn't find a definition of the term "Mixin Methods" in the docs. -- components: IO messages: 366032 nosy: dholth priority: normal severity: normal status: open title: confusing documentation for IOBase.__exit__ versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40233] Awkward to set compression on writeable ZipFile.open()
New submission from Daniel Holth : It looks like this is the current API to set compression at the individual file level when writing with ZipFile.open() z.compression = zipfile.ZIP_STORED data_writer = z.open(zip_info or filename, "w") z.compression = saved It would be useful to have a parameter or to honor the compression setting of the passed ZipInfo. -- components: Library (Lib) messages: 366028 nosy: alanmcintyre, dholth, serhiy.storchaka, twouters priority: normal severity: normal status: open title: Awkward to set compression on writeable ZipFile.open() versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API
Daniel Holth added the comment: Oh, I can avoid this problem by setting Py_LIMITED_API to 0x3030 or greater. -- ___ Python tracker <http://bugs.python.org/issue27499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API
Daniel Holth added the comment: Here it is. https://mail.python.org/pipermail/python-3000/2008-November/015344.html On Sat, Nov 22, 2008 at 06:29, Barry Warsaw wrote: > > On Nov 22, 2008, at 4:05 AM, Martin v. Löwis wrote: > >> I just noticed that the Python 3 C API still contains PY_SSIZE_T_CLEAN. >> >> This macro was a transition mechanism, to allow extensions to use >> Py_ssize_t in PyArg_ParseTuple, while allowing other module continue >> to use int. >> >> In Python 3, I would like the mechanism, making Py_ssize_t the only >> valid data type for size in, say, s# parsers. >> >> Is it ok to still change that? > > Given that we just released the last planned candidate, I'd say it was too > late to change this for Python 3.0. > But we can at least document that the macro is a gone as soon as 3.0 final is out the door. -Brett -- ___ Python tracker <http://bugs.python.org/issue27499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API
New submission from Daniel Holth: When compiling my cryptacular extension https://bitbucket.org/dholth/cryptacular I noticed -DPy_LIMITED_API -DPY_SSIZE_T_CLEAN creates a binary that does not actually use the limited api. This causes segfaults on Linux but does not appear to cause problems on Windows. I found some emails suggestid PY_SSIZE_T_CLEAN was supposed to go away entirely? -- components: Extension Modules messages: 270252 nosy: dholth priority: normal severity: normal status: open title: PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
Daniel Holth added the comment: This bit me also. Is there other documentation for how many arguments MethodType() should take? -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue25435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
Daniel Holth added the comment: https://hg.python.org/cpython/file/2.6/Lib/zipfile.py#l331 Python 2.6 zipfile supports utf8 properly. It has only improved since then. -- ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
Daniel Holth added the comment: The documentation should read The ZIP file format supports Unicode filenames. If you have unicode filenames, zipfile will encode them to and from utf-8 internally, but if you pass bytes filenames to write() then they will be stored without a specified encoding. Even though the format itself supports Unicode, historically Windows' built-in ZIP utility has interpreted all ZIP filenames as CP437 also known as DOS Latin. There is a fix from Microsoft for Windows 7 available here: https://support.microsoft.com/en-us/kb/2704299 -- ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
Daniel Holth added the comment: " ... zipfile will encode them to and from utf-8 internally, and the encoding is marked in a standard flag inside the archive member." -- ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
Daniel Holth added the comment: The current documentation says "Note There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin." This is bad advice because if you convert the filenames to bytes before passing them to zipfile, it won't remember that they should be unicode. Instead it should say "The ZIP file format supports Unicode filenames. If you have unicode filenames, zipfile will encode them to and from utf-8 internally. If you pass bytes filenames to write() then they will be stored without a specified encoding." I am not sure what current versions of WinZip or Windows file manager do. -- ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
Daniel Holth added the comment: This is a simple documentation bug about the ZIP file format supporting utf-8 and 'no encoding' filenames depending on whether two bits are set in a flag inside the archive member. Bug 10614 appears to be a different issue about out-of-band encoding information that you could pass to Python's zipfile implementation. -- ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27344] zipfile *does* support utf-8 filenames
New submission from Daniel Holth: The zipfile documentation says "There is no official file name encoding for ZIP files." However ZIP and zipfile supports utf-8 filenames; this has been true for a long time, at least since Python 2.7. -- assignee: docs@python components: Documentation messages: 268727 nosy: dholth, docs@python priority: normal severity: normal status: open title: zipfile *does* support utf-8 filenames versions: Python 2.7, Python 3.6 ___ Python tracker <http://bugs.python.org/issue27344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] let code force str(bytes) to raise an exception
Daniel Holth added the comment: What if we changed it so that Python code could only disable str_bytes() process-wide, editing the original flag? Would that be fatal to debuggers and the repl? -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] let code force str(bytes) to raise an exception
Daniel Holth added the comment: Then you prefer the older three year old patch that adds to pystate.h ? http://bugs.python.org/review/18373/#ps8545 I remember not being happy with how complicated it turned out, and perhaps having problems with not wanting the "warn once" behavior? It seems more Pythonic to store the flag in a dict. -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] let code force str(bytes) to raise an exception
Daniel Holth added the comment: My reasoning was that str(bytes) would normally be called so rarely that who cares. On Fri, May 27, 2016, at 09:02 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > strbytes.patch of #27134: adding calls to > PyThreadState_GetDict()+PyDict_GetItemString() seems inefficient for a > rare use case > > I would prefer to modify the existing Py_BytesWarningFlag flag. > > The flag is process-wide. If it's an issue, we can use a thread-local > storage (TLS) for the flag in C. > > FYI get_exec_path() uses the following code to temporarely ignore the > warning: > > # {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a > # BytesWarning when using python -b or python -bb: ignore the warning > with warnings.catch_warnings(): > warnings.simplefilter("ignore", BytesWarning) > ... > > -- > > ___ > Python tracker > <http://bugs.python.org/issue18373> > ___ -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] let code force str(bytes) to raise an exception
Daniel Holth added the comment: Better to continue discussion here. Attached is my second, simpler version of the feature. A context manager is included: with string.StrBytesRaises(): str(b'bytes') # raises an exception In a normal program, you might just set the flag to True, but in a library that has no hope of setting the -bb flag you might use it during serialization rather than checking isinstance() on all input. -- title: implement sys.get/setbyteswarningflag() -> let code force str(bytes) to raise an exception versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43029/strbytes.patch ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27134] allow str(bytes) raises an exception to be controlled programmatically
Daniel Holth added the comment: Continuing discussion in the older bug -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue27134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Changes by Daniel Holth : Removed file: http://bugs.python.org/file30787/byteswarningflag.patch ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: Superceded by http://bugs.python.org/issue27134 , a simpler solution providing a with StrBytesRaises(): context manager. -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27134] allow str(bytes) raises an exception to be controlled programmatically
New submission from Daniel Holth: When I discovered str(b'bytes') in my Python 3 program was causing errors to be serialized to disk, I was unhappy. It turns out there is a command line option to turn it off, but the vulnerable serialization code is not going to be able to set that argument; or the one-argument-per-shebang limit we have in Linux was already used for something else. Instead, provide a threadlocal variable that causes str(bytes) to raise. A context manager makes it simple to use for just a portion of your code: with string.StrBytesRaises(): no_str_bytes_here() If not set or False then Python behaves as before. -- components: Unicode files: strbytes.patch keywords: patch messages: 266465 nosy: dholth, ezio.melotti, haypo priority: normal severity: normal status: open title: allow str(bytes) raises an exception to be controlled programmatically type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43024/strbytes.patch ___ Python tracker <http://bugs.python.org/issue27134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23491] PEP 441 - Improving Python Zip Application Support
Daniel Holth added the comment: On Thu, Feb 26, 2015, at 09:41 AM, Paul Moore wrote: > > Paul Moore added the comment: > > Following on from that, the code to make an archive executable is > currently > > os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC) > > Should I use "... | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH"? If so, > do I need to protect that with an "if not Windows" test? (I've tested the > existing code and it does nothing on Windows, so I omitted the test at > the moment). Is there any *other* way I should be making a file > executable on Unix? > > (Side note: Maybe there should be an os.make_executable(pathname) or > similar that does the right thing in a cross-platform way?) The chmod + umask analog that will work not just on a newly created file is umask = os.umask(0) # must change umask to get umask os.umask(umask) # restore previous umask os.chmod(new_archive, os.stat(new_archive).st_mode | ((stat.stat.S_IXUSR|stat.S_IXGRP|stat.S_IXOTH) & ~umask)) If I understand the man page correctly, "chmod +x filename" does exactly the above. Depending on the umask the command may or may not create a world / group / user executable file. -- ___ Python tracker <http://bugs.python.org/issue23491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23491] PEP 441 - Improving Python Zip Application Support
Daniel Holth added the comment: Create and open executable file respecting the Unix user's umask: os.fdopen(os.open(filename, os.O_CREAT|os.O_RDWR), "rw") On Tue, Feb 24, 2015, at 02:34 PM, Paul Moore wrote: > > Paul Moore added the comment: > > Thanks, I'll fix for the next iteration of the patch. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue23491> > ___ -- ___ Python tracker <http://bugs.python.org/issue23491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23491] PEP 441 - Improving Python Zip Application Support
Daniel Holth added the comment: Spelling raise PackError("Cannot spacify entry point if the source has __main__.py") -- ___ Python tracker <http://bugs.python.org/issue23491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers)
Daniel Holth added the comment: I am not the copyright holder, I only maintain the pypi package for python-ntlm. I might have 10 lines of my own code in the whole package. If running on Windows it would be great to have out of the box "native windows NTLM" which can be done somehow with the win32 module, I think... It may also be possible to use Kerberos authentication (NTLMv2) instead of NTLM in most cases these days; since after Windows 2000 according to Wikipedia. On Fri, Sep 26, 2014, at 01:51 AM, Senthil Kumaran wrote: > > Senthil Kumaran added the comment: > > Yes, urllib2 does not have any support for NTML based authentication. > And it is a long pending feature request too. > > For 2.7, the best way to handle this might be, instead of crashing on > WWW-Authenticate: Negotiate, which is a valid response from IIS (1). It > should detect it and fail with a helpful message to use a 3rdparty > handler along with urllib2 [2] > > And for 3.5, I think it is worthy to consider adding the support in > stdlib. > @Daniel Holth - I see you are the owner of it. If we choose to adopt it, > do you give permission to reuse portions of code (with correct > attribution) in the stdlib? > > 1) http://msdn.microsoft.com/en-us/library/ms995330#http-sso-2_topic1 > 2) https://code.google.com/p/python-ntlm/ > > -- > assignee: -> orsenthil > nosy: +dholth > > ___ > Python tracker > <http://bugs.python.org/issue22496> > ___ -- ___ Python tracker <http://bugs.python.org/issue22496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: As an aside, why wouldn't I run my program with -bb? One reason is that the following code won't work on Linux: #!/usr/bin/env python -bb Instead of passing -bb to Python, it will look for an executable called "python -bb", and it's not likely to find it. The original reason was that I did not know about -bb. -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20531] TypeError in e-mail.parser when non-ASCII is present
Daniel Holth added the comment: We do this. https://bitbucket.org/dholth/wheel/src/tip/wheel/pkginfo.py?at=default I appreciate the long-term goal. The policy system is really neat. We are going to json largely because the next version of the metadata is more nested. The decision had nothing to do with the email module itself. -- ___ Python tracker <http://bugs.python.org/issue20531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20531] TypeError in e-mail.parser when non-ASCII is present
Daniel Holth added the comment: In bdist_wheel I've gone to some lengths to re-use the email module to parse and generate "RFC822 inspired" documents. The output is not a valid e-mail but it is useful. It is awkward to use the email module this way. We will sidestep the issue hopefully this year by switching to json. -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue20531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: Just mitigating the bug that -bb is not the default... -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: Thanks. I guess I know who to ask now. It was just painful seeing so much import-time computation, pretty much guaranteed to happen every time Python starts up, being wasted on a feature that is rarely used. On the Raspberry Pi the majority of the import time is spent building this table and the speed difference is noticeable. On Mon, Jan 6, 2014, at 10:22 AM, Larry Hastings wrote: > > Larry Hastings added the comment: > > Since this isn't a bugfix, it was inappropriate to check this in after > feature-freeze for 3.4. However it looks harmless enough, so I'm not > asking you to revert it at this time. > > I guess it's easier to get forgiveness than permission, huh. > > -- > nosy: +larry > > ___ > Python tracker > <http://bugs.python.org/issue18515> > ___ -- ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: Fixed in http://hg.python.org/cpython/rev/536a2cf5f1d2 -- ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18585] Add a text truncation function
Daniel Holth added the comment: Previous changeset was meant for #18515 -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue18585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: I am withdrawing zipfile-no-crc32.patch. It did not work correctly. zdlazy.patch should go in. It avoids creating the rarely-needed crc32 table until the first time it is needed, saving some memory and the majority of time needed to import the module. zdlazy.patch should not affect its C replacement at all, except that the rarely-needed CRC32 table that we are not generating becomes a never-needed table. -- ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18532] hashlib.HASH objects should officially expose the hash name
Daniel Holth added the comment: fwiw pypy 2 supports HASH.name but the older 1.9 (still part of some Linux distributions) did not. -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue18532> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: I tried it on a raspberry pi. zipfile takes 36 ms to import and 10 ms if it does not generate the crctable. -- ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: It takes 706 microseconds. On my machine %timeit import sys; del sys.modules['zipfile']; import zipfile "import zipfile" takes 2.51 ms without the patch and 1.7 ms with the patch. On Sat, Jul 20, 2013, at 12:13 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > How much time take it? > > -- > > ___ > Python tracker > <http://bugs.python.org/issue18515> > ___ -- ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
Daniel Holth added the comment: Someone who has a better understanding of zipfile may be able to get zlib.crc32(bytes[ch], running_crc) to work correctly. This patch that passes the zipfile tests generates the crctable only when _ZipDecrypter() is instantiated. -- Added file: http://bugs.python.org/file30991/zdlazy.patch ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import
New submission from Daniel Holth: http://hg.python.org/cpython/file/e7305517260b/Lib/zipfile.py#l460 I noticed this table taking up time on import. I'd guess that it pre-dates zlib.crc32 which is imported at the top of the file. I also suspect that most of the time this table isn't even used at all. -- files: zipfile-no-crc32.patch keywords: patch messages: 193408 nosy: dholth priority: normal severity: normal status: open title: zipfile._ZipDecryptor generates wasteful crc32 table on import versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30990/zipfile-no-crc32.patch ___ Python tracker <http://bugs.python.org/issue18515> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: Python 3 is supposed to make it easier to do Unicode correctly. str(bytes) does not. I felt strongly enough about that to write this patch. With this feature my library can have control in a way that is much more practical than ensuring a particular flag has been passed to the interpreter. It might make sense to modify the patch so str(bytes) can throw a regular exception instead of a warning while under the influence of the new flag. The reason being that the warning will be suppressed the second time around but for this use case you wouldn't want that. -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: On Thu, Jul 18, 2013, at 04:22 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > I don't know why your patch is putting this in the thread state, > though... If you have multiple threads one thread might want exceptions when str(bytes), and the other might not. str(bytes) has been an insidious problem for me. No exceptions, seemingly working code, and b'' in serialized data. I am motivated to turn it off. -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
Daniel Holth added the comment: You would just enable this during your serialization code, and if (perhaps someone is calling your library and passing it the wrong type) they would be guarded against this common error. On Sat, Jul 6, 2013, at 12:15 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Why wouldn't you just enable bytes warning and fix all the code to work > correctly? > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue18373> > ___ -- ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18373] implement sys.get/setbyteswarningflag()
New submission from Daniel Holth: This patch lets the user get/set the byteswarningflag() to control whether warnings are emitted at runtime (pursuant to the configuration of the warnings module, of course). The idea is that a user who is concerned with interacting with bytes correctly would use a context manager to set str(bytes) to raise exceptions during a critical serialization. TODO the hypothetical context manager would also have to push/pop the warnings state to work correctly. Maybe str(bytes) can raise a regular exception if byteswarningflag() is high enough? TODO don't know if this plays nicely when there are no threads -- files: byteswarningflag.patch keywords: patch messages: 192372 nosy: dholth priority: normal severity: normal status: open title: implement sys.get/setbyteswarningflag() versions: Python 3.4 Added file: http://bugs.python.org/file30787/byteswarningflag.patch ___ Python tracker <http://bugs.python.org/issue18373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18354] http://www.python.org/doc/ has outdated note
New submission from Daniel Holth: Please remove the note. Note A new documentation project, which will be merged into the Python documentation soon, covers creating, installing and distributing Python packages: The Hitchhiker's Guide to Packaging (creating and distributing Python packages) -- assignee: docs@python components: Documentation messages: 192251 nosy: dholth, docs@python priority: normal severity: normal status: open title: http://www.python.org/doc/ has outdated note type: enhancement ___ Python tracker <http://bugs.python.org/issue18354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16104] Use multiprocessing in compileall script
New submission from Daniel Holth: compileall would benefit approximately linearly from additional CPU cores. There should be an option. The noisy output would have to change. Right now it prints "compiling" and then "done" synchronously with doing the actual work. -- messages: 171744 nosy: dholth priority: normal severity: normal status: open title: Use multiprocessing in compileall script ___ Python tracker <http://bugs.python.org/issue16104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: Sorry, I won't be able to get around to this any time soon. The patch to fix this bug (in the CPython3 source code) is too intertwined with the other distutils2 fixes. Anyone is welcome to fish for it in my bitbucket. -- status: open -> languishing ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Daniel Holth added the comment: re-tweak treatment of md5 in hashlib docs (the SHA-2 family is currently recommended by http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html) -- Added file: http://bugs.python.org/file26648/hashlib.patch ___ Python tracker <http://bugs.python.org/issue15468> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Daniel Holth added the comment: Taking a second look it is pretty good. The only other thing that might be worth mentioning explicitly is that the "always present" hashes don't actually use OpenSSL. "Constructors for hash algorithms that are always present in this module are md5(), sha1(), sha224(), sha256(), sha384(), and sha512(). Additional algorithms may also be available depending upon the OpenSSL library that Python uses on your platform." -- ___ Python tracker <http://bugs.python.org/issue15468> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Daniel Holth added the comment: Not to mention its continued popularity as a password hash, surpassed only by double-rot13. You've convinced me, it is reasonable to continue to support, nay, recommend md5 for the non-FIPS world. This hash function continues to have raving fans, especially in applications such as hashing data that is either read from or written to disk where the computational and storage cost of using a more modern hash is too severe for the majority of new applications. -- ___ Python tracker <http://bugs.python.org/issue15468> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
New submission from Daniel Holth : md5() has been obsolete since 1996. It has no place as the first item in hashlib's list of "guaranteed to be available" hashes, and it doesn't work when Python has been compiled to be FIPS-compliant. The documentation should be edited to make md5's availability as non-obvious as possible. -- messages: 166577 nosy: dholth priority: normal severity: normal status: open title: Edit docs to hide hashlib.md5() versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue15468> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Daniel Holth added the comment: While you are at it, can you edit the docs to put md5() at the bottom of the page at the back of the list in a 2-point font and raise a DeprecationWarning("This function is totally lame, and it is slower than SHA-3, get with the program.") the first time it is used? I don't agree that md5 has a legitimate place in systems designed after 1996. -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11624] distutils should support a custom list of exported symbols for Windows dlls.
Daniel Holth added the comment: I must have missed the export_symbols keyword argument to Extension(), or it was added. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue11624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: I appreciate it. I had trouble using the patch system after that. I will see whether I can generate a better one. Daniel Holth On Jul 3, 2012, at 12:49 AM, Éric Araujo wrote: > > Éric Araujo added the comment: > > Did a first review on Rietveld, but I see that the patch may be outdated (it > had no tests). > > -- > versions: +3rd party, Python 3.4 -Python 3.3 > > ___ > Python tracker > <http://bugs.python.org/issue11880> > ___ -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: Yes, but I had some trouble attaching a good patch to the issue tracker itself. On Thu, Jun 14, 2012, at 02:28 PM, David Barnett wrote: > > David Barnett added the comment: > > Is this ready and just waiting to be merged now? > > -- > nosy: +mu_mind > > ___ > Python tracker > <http://bugs.python.org/issue11880> > ___ -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8084] pep-0370 on osx duplicates existing functionality
Daniel Holth added the comment: Please mention Apple's OS X Python behavior in the PEP. The Python that comes with OS X Lion doesn't seem to follow the PEP regarding ~/.local ; this deserves a mention. -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue8084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14921] New trove classifier for simple printers of nested lists
Changes by Daniel Holth : -- resolution: -> postponed status: open -> closed ___ Python tracker <http://bugs.python.org/issue14921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14921] New trove classifier for simple printers of nested lists
New submission from Daniel Holth : Based on the supply, there is a tremendous demand for printers of nested lists (as long as they are not too complicated). But how will I find and compare the available options? Add a trove classifier Topic :: Nested Lists to ease the search burden. -- messages: 161624 nosy: dholth priority: normal severity: normal status: open title: New trove classifier for simple printers of nested lists type: enhancement ___ Python tracker <http://bugs.python.org/issue14921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
Changes by Daniel Holth : Removed file: http://bugs.python.org/file25642/65c3af0d283b.diff ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
Changes by Daniel Holth : -- keywords: +patch Added file: http://bugs.python.org/file25642/65c3af0d283b.diff ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
Daniel Holth added the comment: A tuple of (macro, '1') seems to do the trick define_macros has to be space-separated, not comma-separated -- hgrepos: +127 ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
Daniel Holth added the comment: Looks like it can go into [build_ext] but not per-extension -- ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: branch updated with regression test (add an entry_points.txt to test_command_install_data.py) and get_distinfo_file() can get any file inside the .dist-info directory. -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
New submission from Daniel Holth : from build_ext.py: # XXX not honouring 'define_macros' or 'undef_macros' -- the # CCompiler API needs to change to accommodate this, and I # want to do one thing at a time! -- ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14843] support define_macros / undef_macros in setup.cfg
Changes by Daniel Holth : -- assignee: eric.araujo components: Distutils2 nosy: alexis, dholth, eric.araujo, tarek priority: normal severity: normal status: open title: support define_macros / undef_macros in setup.cfg type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Changes by Daniel Holth : -- keywords: +patch Added file: http://bugs.python.org/file25623/50a0da981b7e.diff ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: Fixed closure mistake in remote tip -- hgrepos: +126 ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Daniel Holth added the comment: Implemented in https://bitbucket.org/dholth/cpython/changeset/c493a5179621 Advice on writing the unit test would be appreciated. -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14518] Add bcrypt $2a$ to crypt.py
Changes by Daniel Holth : -- components: +Library (Lib) versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue14518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14518] Add bcrypt $2a$ to crypt.py
New submission from Daniel Holth : The prefix for bcrypt '$2a$' is supported on many systems and could be added to crypt.py Could the documentation mention the available rounds parameter for most of these newer hashes? And that Unicode strings are automatically converted to utf-8 before being passed into the OS crypt() function, or is that just assumed to be common knowledge? -- messages: 157679 nosy: dholth priority: normal severity: normal status: open title: Add bcrypt $2a$ to crypt.py ___ Python tracker <http://bugs.python.org/issue14518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12022] AttributeError should report the same details when raised by lookup_special() as when raised in the REPL
Daniel Holth added the comment: Thank you Benjamin for following up on this issue -- ___ Python tracker <http://bugs.python.org/issue12022> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12022] AttributeError should report the same details when raised by lookup_special() as when raised in the REPL
Daniel Holth added the comment: Python should explain AttributeError in the same way when it's raised by the interpreter. The with: statement below should raise the second AttributeError, not the first. import transaction with transaction: pass >>> AttributeError: __exit__ import sys sys.__exit__ >>> AttributeError: 'module' object has no attribute '__exit__' -- title: improve special method lookup error message -> AttributeError should report the same details when raised by lookup_special() as when raised in the REPL ___ Python tracker <http://bugs.python.org/issue12022> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12022] 'transaction' module-as-context-manager thwarted by Python 2.7.1
New submission from Daniel Holth : "How much do we care about special method lookup?" Python recently bypasses __getattr__ entirely when looking up context managers. http://mail.python.org/pipermail/python-dev/2009-May/089535.html Could this be the reason that ZODB's transaction module, which attempts to be a context manager by declaring manager = ThreadTransactionManager() __enter__ = manager.get __exit__ = manager.__exit__ Does not work in Python 2.7.1 on Ubuntu 11.04 or RHEL5? Frustratingly, the exception is no more specific than an AttributeError, even though hasattr(transaction, '__exit__')? I would prefer to never get AttributeError: transaction.__exit__ when hasattr(transaction, '__exit__') as I find that to be very confusing. Maybe the interpreter could raise SpecialAttributeError('transaction.__exit__ is not sufficiently special') instead. http://svn.zope.org/repos/main/transaction/trunk/transaction/__init__.py -- components: Interpreter Core messages: 135365 nosy: dholth priority: normal severity: normal status: open title: 'transaction' module-as-context-manager thwarted by Python 2.7.1 type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12022> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Daniel Holth added the comment: from docs.python.org: platform.python_implementation() Returns a string identifying the Python implementation. Possible return values are: ‘CPython’, ‘IronPython’, ‘Jython’. New in version 2.6. ... and it seems pypy identifies itself as 'PyPy'. -- ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com