Re: [Python-Dev] REVIEW: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
"make test" in both python and py3k trunks were happy with this change, so I've documented the issue in Issue #6624 and committed it in 74277 (2.x) and 74278 (3.x). Sean -- "The only thing more expensive than hiring a professional is hiring an amateur." -- Red Adair, Oil Well Fire-Fighter Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pylinting the stdlib
Hello, I've fed parts of the stdlib to pylint and after some filtering there appears to be some things that looks strange, I've filled a few bugs to the tracker for them. 6623 Lib/ftplib.py netrc class parsing problem 6622 [RFC] wrong variable used in Lib/poplib.py 6621 [RFC] Remove leftover use of Carbon module from Lib/binhex.py 6620 Variable may be used before first being assigned to in Lib/locale.py 6619 Remove duplicated function in Lib/inspect.py Is this useless and taking reviewer's time for nothing ? Please advise, if this is deemed useful, I'll continue further -- Vincent Legoll ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] standard library mimetypes module pathologically broken?
Brett Cannon wrote: > Jacob Rus wrote: >> At the very least, I >> think some changes can be made to this code without altering its basic >> function, which would clean up the actual mime types it returns, >> comment the exceptions to Apache and explain why they're there, and >> make the code flow understandable to someone reading the code. > > That all sounds reasonable. Okay, as a start, I did a simple code cleanup that I think fixes some potential bugs (any code using its own instance of the MimeTypes class should now be insulated from other same-process users of the module), chops out 80 or 90 lines, removes some redundant code paths, clarifies some of the micro level behavior of some chunks of code, adds a bit more to the docstring at the top of the file, and makes the program flow somewhat clearer … *without* changing the semantics of the module or its included list of MIME types. Here's a diff: http://pastie.textmate.org/568329 And here's the whole file: http://pastie.textmate.org/568333 This change does require any tests that previously called _default_mime_types() to instead call init(). Any thoughts? Jacob Rus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] standard library mimetypes module pathologically broken?
Jacob Rus wrote: > Here's a diff: > http://pastie.textmate.org/568329 > > And here's the whole file: > http://pastie.textmate.org/568333 Slightly better: http://pastie.textmate.org/568354 http://pastie.textmate.org/568355 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] standard library mimetypes module pathologically broken?
Jacob Rus wrote: > Brett Cannon wrote: >> Jacob Rus wrote: >>> At the very least, I >>> think some changes can be made to this code without altering its basic >>> function, which would clean up the actual mime types it returns, >>> comment the exceptions to Apache and explain why they're there, and >>> make the code flow understandable to someone reading the code. >> >> That all sounds reasonable. > > Okay, as a start, I did a simple code cleanup that I think fixes some > potential bugs (any code using its own instance of the MimeTypes class > should now be insulated from other same-process users of the module), > chops out 80 or 90 lines, removes some redundant code paths, clarifies > some of the micro level behavior of some chunks of code, adds a bit > more to the docstring at the top of the file, and makes the program > flow somewhat clearer … *without* changing the semantics of the module > or its included list of MIME types. Here is a somewhat more substantively changed version. This one does away with the 'inited' flag and the 'init' function, which might be impossible given that their documented (though I would be extremely surprised if anyone calls them in third-party code), and makes the behavior of the code much clearer, I think, by making it very obvious how the singleton instance is actually working. Additionally, this version brings the lazy loading of Apache mime.types files to every MimeTypes instance, and makes the read_mime_types() function behave as expected (only getting the mapping from an apache mime.types file rather than including some extra types as the current code does). In this version, tests would want to call the _init_singleton() function to reset to defaults. http://pastie.textmate.org/568399 http://pastie.textmate.org/568400 To reiterate: this should still behave identically to the current module in all reasonable conditions. I still haven't made any changes to the set of MIME types included in the file, or the behavior of the module. Some such changes should be made as well, but the changes so far should be relatively uncontroversial, I hope. Cheers, Jacob Rus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
