[issue38656] mimetypes for python 3.7.5 fails to detect matroska video
Michael Lazar added the comment: Greetings, I just encountered this issue [0] and I agree with the sentiment that the documentation is currently misleading. Particularly, > By default, it provides access to the same database as the rest of this > module. The initial database is a copy of that provided by the module, and > may be extended by loading additional mime.types-style files into the > database using the read() or readfp() methods. The mapping dictionaries may > also be cleared before loading additional data if the default data is not > desired. “as the rest of the module” implies to me that it should behave the same way as mimetypes.guess_type() does. The documentation only has one other reference to this built-in list of mimetypes, and the default values are hidden behind underscored variable names. I would re-word this as "By default, it provides access to a database of well-known values defined internally by the python module. Unlike the other mimetypes convenience functions, it does not include definitions from the list of mimetypes.knownfiles. The initial database may be extended by loading additional mime.types-style files into the database using the read() or readfp() methods. The mapping dictionaries may also be cleared before loading additional data if the default data is not desired." I would be happy to submit a PR if others agree. [0] https://github.com/michael-lazar/jetforce/issues/38 ------ nosy: +michael-lazar ___ Python tracker <https://bugs.python.org/issue38656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32861] urllib.robotparser: incomplete __str__ methods
Change by Michael Lazar <lazar.michae...@gmail.com>: -- keywords: +patch pull_requests: +5500 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32861] urllib.robotparser: incomplete __str__ methods
New submission from Michael Lazar <lazar.michae...@gmail.com>: Hello, I have stumbled upon a couple of inconsistencies in urllib.robotparser's __str__ methods. These appear to be unintentional omissions; basically the code was modified but the string methods were never updated. 1. The RobotFileParser.__str__ method doesn't include the default (*) User-agent entry. >>> from urllib.robotparser import RobotFileParser >>> parser = RobotFileParser() >>> text = """ ... User-agent: * ... Allow: /some/path ... Disallow: /another/path ... ... User-agent: Googlebot ... Allow: /folder1/myfile.html ... """ >>> parser.parse(text.splitlines()) >>> print(parser) User-agent: Googlebot Allow: /folder1/myfile.html >>> This is *especially* awkward when parsing a valid robots.txt that only contains a wildcard User-agent. >>> from urllib.robotparser import RobotFileParser >>> parser = RobotFileParser() >>> text = """ ... User-agent: * ... Allow: /some/path ... Disallow: /another/path ... """ >>> parser.parse(text.splitlines()) >>> print(parser) >>> 2. Support was recently added for `Crawl-delay` and `Request-Rate` lines, but __str__ does not include these. >>> from urllib.robotparser import RobotFileParser >>> parser = RobotFileParser() >>> text = """ ... User-agent: figtree ... Crawl-delay: 3 ... Request-rate: 9/30 ... Disallow: /tmp ... """ >>> parser.parse(text.splitlines()) >>> print(parser) User-agent: figtree Disallow: /tmp >>> 3. Two unnecessary trailing newlines are being appended to the string output (one for the last RuleLine and one for the last Entry) (see above examples) Taken on their own these are all minor issues, but they do make things quite confusing when using robotparser from the REPL! -- components: Library (Lib) messages: 312259 nosy: michael-lazar priority: normal severity: normal status: open title: urllib.robotparser: incomplete __str__ methods type: behavior versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31348] webbrowser BROWSER with MacOSXOSAScript type
New submission from Michael Lazar:
Hello,
I have found that [1] is an open issue, but I have discovered what appears to
be a completely separate bug than the one described in that ticket. The issue
is that there is no way to specify a MacOSXOSAScript browser using the BROWSER
variable. The _synthesize() command fails at the "if not shutil.which(cmd)"
line, because OSAScript browsers are not commands in the system path. As a
result, the value specified by BROWSER will get re-mapped to a GenericBrowser
type, which is useless for most people on macOS.
Here's an example:
$ BROWSER=firefox python3
Python 3.6.1 (default, Apr 4 2017, 09:36:47)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> for name in webbrowser._tryorder:
... print('%s: %s' % (name, webbrowser._browsers[name.lower()]))
...
firefox: [None, ]
MacOSX: [None, ]
chrome: [None, ]
firefox: [None, ]
safari: [None, ]
links: [None, ]
elinks: [None, ]
lynx: [None, ]
w3m: [None, ]
Note that on macOS, firefox is defined in the webbrowser module as
register("firefox", None, MacOSXOSAScript('firefox'), -1)
[1] http://bugs.python.org/issue24955
--
components: Library (Lib)
messages: 301294
nosy: michael-lazar
priority: normal
severity: normal
status: open
title: webbrowser BROWSER with MacOSXOSAScript type
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31348>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: Got it, I found some examples and it didn't look too complicated so I took a shot at it. Is there anything else that needs to be added? Does the documentation need to be updated at all? btw, thanks for the rapid iteration. I appreciate you taking the time to help guide me though this :) -- Added file: http://bugs.python.org/file43710/mailcap_v4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Changes by Michael Lazar <lazar.michae...@gmail.com>: Added file: http://bugs.python.org/file43706/mailcap_v3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: Whoops -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: That works for me, patch updated to match your suggestion. So to recap, the proposed fix implements the following changes to the api: getcaps() The returned dict now has an additional `lineno` field. There's a *slim* chance that this could break behavior for somebody who relies on the output for something other than passing it to findmatch(). readmailcapfiles() Marked as deprecated, but the behavior will remain the same. lookup(caps, ...) If the caps dict contains `lineno`, the metadata will be used to sort the matching entries. If the caps dict does not contain `lineno`, for example if it was constructed manually, the behavior will remain the same. findmatch(caps, ...) Same as lookup() -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: I can certainly do that. Although in addition to adding a keyword argument, we would also have to change the return signature to switch between modes like this: if lineno is None: return caps else: return caps, lineno Overall I'm not a fan of this technique and would like to avoid it if possible. The problem is that we have to keep track of the current line between successive calls to readmailcapfile(). An alternative would be to go back to using lineno as a generator. This is close to what I had in the initial patch. lineno = itertools.count() caps = readmailcapfile(fp, lineno=lineno) caps = readmailcapfile(fp2, lineno=lineno) caps = readmailcapfile(fp3, lineno=lineno) ...etc Happy to hear any insights you have on this. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: Submitting an updated patch; simplified the implementation and updated test_mailcap.py -- Added file: http://bugs.python.org/file43695/mailcap_v2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: Alright thanks, I've submitted a patch -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Changes by Michael Lazar <lazar.michae...@gmail.com>: -- keywords: +patch Added file: http://bugs.python.org/file43682/mailcap.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14977] mailcap does not respect precedence in the presence of wildcards
Michael Lazar added the comment: Hello. In my opinion this is a pretty major deficiency. I was trying to add definitions to my ~/.mailcap file (which should take priority over system mailcap files) but they weren't getting applied because of the wildcard bug. This was prohibiting me from using mailcap, so I wrote a patch and submitted it to PyPI. I've never contributed before; what would be the first step towards submitting this to python? https://github.com/michael-lazar/mailcap_fix https://pypi.python.org/pypi/mailcap-fix/0.1.0 -- nosy: +michael-lazar ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
