[Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity"
Chris Angelico
rosuav at gmail.com
Tue Jan 14 01:06:01 CET 2014
More information about the Python-Dev mailing list
Tue Jan 14 01:06:01 CET 2014
- Previous message: [Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity" - 2 use cases]
- Next message: [Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity" - 2 use cases]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 14, 2014 at 10:48 AM, Jim J. Jewett <jimjjewett at gmail.com> wrote: >> The barrier for entry to the standard library is higher than mere >> usefulness. > > Agreed. But "most programs will need it, and people will either > include (the same) 3rd-party library themselves, or write their > own workaround, or have buggy code" *is* sufficient. Well, no, that's not sufficient on its own either. But yes, it's a stronger argument. > But having a batch process crash one run in ten (where it didn't > crash at all under Python 2) is a bad thing. There are environments > where (once I knew about it) I would add chardet (if I could get > approval for the 3rd-party component). Having it *do the wrong thing* one run in ten is even worse. If you need chardet, then get approval for the third-party component. That's a political issue, not a technical one. "This needs to be in the stdlib because I'm not allowed to install anything else"? I hope not. Also, a PyPI package is free to update independently of the Python version schedule. The stdlib is bound. ChrisA
- Previous message: [Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity" - 2 use cases]
- Next message: [Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity" - 2 use cases]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list