Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mimetypes doesn't recognize .csv #58160

Closed
iwd32900 mannequin opened this issue Feb 6, 2012 · 16 comments
Closed

mimetypes doesn't recognize .csv #58160

iwd32900 mannequin opened this issue Feb 6, 2012 · 16 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@iwd32900
Copy link
Mannequin

iwd32900 mannequin commented Feb 6, 2012

BPO 13952
Nosy @terryjreedy, @pitrou, @merwok, @bitdancer, @sandrotosi, @akheron, @berkerpeksag
Files
  • issue13952.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2016-04-09.05:20:24.653>
    created_at = <Date 2012-02-06.17:43:55.748>
    labels = ['type-bug', 'library']
    title = "mimetypes doesn't recognize .csv"
    updated_at = <Date 2016-04-09.05:20:24.652>
    user = 'https://bugs.python.org/iwd32900'

    bugs.python.org fields:

    activity = <Date 2016-04-09.05:20:24.652>
    actor = 'berker.peksag'
    assignee = 'none'
    closed = True
    closed_date = <Date 2016-04-09.05:20:24.653>
    closer = 'berker.peksag'
    components = ['Library (Lib)']
    creation = <Date 2012-02-06.17:43:55.748>
    creator = 'iwd32900'
    dependencies = []
    files = ['29187']
    hgrepos = []
    issue_num = 13952
    keywords = ['patch']
    message_count = 16.0
    messages = ['152751', '152752', '152757', '152759', '152761', '152762', '153106', '153129', '153137', '153163', '182774', '262730', '262789', '263063', '263066', '263070']
    nosy_count = 12.0
    nosy_names = ['terry.reedy', 'pitrou', 'eric.araujo', 'r.david.murray', 'sandro.tosi', 'python-dev', 'petri.lehtinen', 'berker.peksag', 'iwd32900', 'Paul.Cauchon', 'gmwils', 'Werner Van Geit']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue13952'
    versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']

    @iwd32900
    Copy link
    Mannequin Author

    iwd32900 mannequin commented Feb 6, 2012

    The mimetypes module does not respond with "text/csv" for files that end in ".csv", and I think it should :) For goodness sake, "text/tab-delimited-values" is in there as ".tsv", and that seems much less used (to me).

    @iwd32900 iwd32900 mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Feb 6, 2012
    @bitdancer
    Copy link
    Member

    Yes, but text/tab-delimited-values/.tsv is older. .tsv dates from the days of Gopher, but text/csv was formalized only in October of 2005. Presumably nobody has asked for it before, for some odd reason.

    Now we get to debate again whether updating mimetypes with a registered type can be considered a bug fix. We've gone both ways in the past, as far as I can tell. This one has the advantage of actually having a formal IANA registration, unlike the last couple.

    @pitrou
    Copy link
    Member

    pitrou commented Feb 6, 2012

    I would argue the embedded mime-types dictionary should at least mirror current IANA assignments, which are already present in up-to-date Unix systems:

    >>> mimetypes.guess_type("foo.csv")
    ('text/csv', None)

    So not having text/csv is IMHO a bug.
    Also it would be nice if there were an easy way to keep the mime-types dictionary up-to-date wrt. a system's mime-types file.

    @bitdancer
    Copy link
    Member

    As far as I know having it mirror the IANA registry is the intent (there's a comment in the module that can be read as implying that). So I'd be inclined to treat this one as a bug and fix it in 2.7 and 3.2 as well as 3.3.

    I'm not sure what you mean by your final comment, since by default the system mime types are read on both Unix and Windows and merged with the built in table.

    @pitrou
    Copy link
    Member

    pitrou commented Feb 6, 2012

    I'm not sure what you mean by your final comment, since by default the
    system mime types are read on both Unix and Windows and merged with
    the built in table.

    I mean to have our built-in table mirror a recent Unix system's
    mime-types table. There could be a special switch to mimetypes.py, which
    would output the Python code of a dict mirroring /etc/mime.types (or
    "/etc/mime.types" + the current built-in table) when run. Then it would
    be easy to integrate the changes back into the code.

    @bitdancer
    Copy link
    Member

    Ah, analagous to the way keyword.py regenerates its embedded table based on the actual python grammar? Yes, that would be nice.

    @merwok
    Copy link
    Member

    merwok commented Feb 11, 2012

    I’ve been one to argue that additions to the mimetypes registry are clearly new features. Now if two senior devs like you think otherwise, I’m reconsidering. These additions can’t possibly break code, can they? So I can agree with a viewpoint that mimetypes should match what the IANA publishes and that adding missing types is a bugfix. (It’s less disturbing than updating HTMLParser for example, and I agree with that.) Georg’s inclusion of a registry addition for IIRC 3.2.2 would also indicate RM support for this viewpoint.

    About Antoine’s remark: mimetypes already reads mime.types files, so even if our internal registry is not up-to-date the module should know about all types present in /etc/mime.types.

    @pitrou
    Copy link
    Member

    pitrou commented Feb 11, 2012

    About Antoine’s remark: mimetypes already reads mime.types files, so
    even if our internal registry is not up-to-date the module should know
    about all types present in /etc/mime.types.

    The point was about systems which don't have a /etc/mime.types
    (Windows).

    @bitdancer
    Copy link
    Member

    On Windows we do (now) read from the registry as well. My guess is there are a lot more Windows systems out there with outdated registries then there are unix systems with outdated /etc/mime files, though.

    @terryjreedy
    Copy link
    Member

    One solution would be to update our mimetypes file just before a new version, and then leave it until the next, just as we update unicodedata to current unicode and then leave it alone for bugfix releases. Rather than the entire IANA file, which has a lot of useless stuff, we might update from the most recent *nix files (assuming that they have less than 'everything').

    @gmwils
    Copy link
    Mannequin

    gmwils mannequin commented Feb 23, 2013

    Patch against 2.7 to add csv to the internal list. It is popular enough as a format, that it should work even if the system mime files are stale.

    @WernerVanGeit
    Copy link
    Mannequin

    WernerVanGeit mannequin commented Apr 1, 2016

    Will this patch ever make it into the main python version ? I just ran into exactly this issue (mimetypes returns None as mimetype of csv file on Windows)

    @berkerpeksag
    Copy link
    Member

    I will commit bpo-13952.patch this weekend to 2.7, 3.5 and default.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Apr 9, 2016

    New changeset 711672506b40 by Berker Peksag in branch '3.5':
    Issue bpo-13952: Add .csv to mimetypes.types_map
    https://hg.python.org/cpython/rev/711672506b40

    New changeset 5143f86ffe57 by Berker Peksag in branch 'default':
    Issue bpo-13952: Add .csv to mimetypes.types_map
    https://hg.python.org/cpython/rev/5143f86ffe57

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Apr 9, 2016

    New changeset e704e0786332 by Berker Peksag in branch '2.7':
    Issue bpo-13952: Add .csv to mimetypes.types_map
    https://hg.python.org/cpython/rev/e704e0786332

    @berkerpeksag
    Copy link
    Member

    Thanks for the patch, Geoff.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants