Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-20 Thread Paul Moore
2009/8/14 Nick Coghlan ncogh...@gmail.com: Georg Brandl wrote: Nick Coghlan schrieb: P.S. For anyone else that is slow like me, take a close look at PEP 387... What should we see, other than that we have two PEPs on the same topic that should be merged? Benjamin wrote the second one, so he

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-16 Thread Jacob Rus
Antoine Pitrou: After a fair amount of discussion on Rietveld, I think you should post another patch without the deprecations. (since the discussion was fairly long, I won't repeat here the reasons I gave unless someone asks me to ) Besides, it would be nice to have the additional tests you

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-14 Thread Nick Coghlan
Georg Brandl wrote: Nick Coghlan schrieb: P.S. For anyone else that is slow like me, take a close look at PEP 387... What should we see, other than that we have two PEPs on the same topic that should be merged? Benjamin wrote the second one, so he obviously knows there's a written

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-14 Thread Jacob Rus
11 Aug 2009, Benjamin Peterson wrote: 2009/8/11 Jacob Rus: I have some other questions: How does one deprecate part of a standard library API? How can we alert users to the deprecation? When can the deprecated parts be removed? Basically, you add a DeprecationWarning to the API. Then remove

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-13 Thread Georg Brandl
Nick Coghlan schrieb: Nick Coghlan wrote: Benjamin Peterson wrote: rant If python-dev was more interested, we would have a policy for this. *cough* /rant PEP 5 isn't enough? (I'll grant that PEP could probably do with mentioning the use of warnings.warn(DeprecationWarning) explicitly, but

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-12 Thread Eric Smith
Benjamin Peterson wrote: Then, you might garner some more reviews by putting your patch up on Rietveld; it makes reviewing much painful. ... much _less_ painful, I hope! ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-12 Thread Nick Coghlan
Benjamin Peterson wrote: rant If python-dev was more interested, we would have a policy for this. *cough* /rant PEP 5 isn't enough? (I'll grant that PEP could probably do with mentioning the use of warnings.warn(DeprecationWarning) explicitly, but the policy itself seems fine) Cheers, Nick.

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-12 Thread Nick Coghlan
Nick Coghlan wrote: Benjamin Peterson wrote: rant If python-dev was more interested, we would have a policy for this. *cough* /rant PEP 5 isn't enough? (I'll grant that PEP could probably do with mentioning the use of warnings.warn(DeprecationWarning) explicitly, but the policy itself

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-12 Thread Jacob Rus
Benjamin Peterson wrote: It looks like you need to add some tests for the bugs you fixed to test_mimetypes. While you're at it, you could improve that test generally, since it's not exactly extensive. Okay, I'll try to do this sometime in the next few days, if I get the chance. Then, you

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-11 Thread Jacob Rus
Glyph Lefkowitz wrote: Jacob Rus wrote: No, [changing the semantics in 3.x] is bad.  If I may quote Guido: http://www.artima.com/weblogs/viewpost.jsp?thread=227041 So, once more for emphasis: Don't change your APIs at the same time as porting to Py3k! Please follow this policy as much as

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-11 Thread Nick Coghlan
Jacob Rus wrote: Well, I've had some patches up at http://bugs.python.org/issue6626 for over a week now, and my updated version should have identical semantics to the current module, just with the module's *actual* behavior clear to anyone reading the code, some serious edge-case bugs fixed,

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-11 Thread Benjamin Peterson
2009/8/11 Jacob Rus jacobo...@gmail.com: I have some other questions: How does one deprecate part of a standard library API? How can we alert users to the deprecation? When can the deprecated parts be removed? Basically, you add a DeprecationWarning to the API. Then remove it in the next

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Jacob Rus
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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Michael Foord
Jacob Rus wrote: 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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Paul Moore
2009/8/2 Michael Foord fuzzy...@voidspace.org.uk: [...] In this version, tests would want to call the _init_singleton() function to reset to defaults. [...] Please post the patches to the Python bug tracker:   http://bugs.python.org Thanks The patch you post should also patch the test

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Robert Lehmann
On Sat, 01 Aug 2009 23:37:18 -0700, Jacob Rus wrote: 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

[Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Jim Jewett
[It may be worth creating a patch; I think most of these comments would be better on the bug-tracker.] (1) In a few cases, it looked like you were changing parameter names between files and filenames. This might break code that was calling it with keyword arguments -- as I typically would for

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Jacob Rus
Jim Jewett wrote: [It may be worth creating a patch; I think most of these comments would be better on the bug-tracker.] I'm going to do that shortly. (1)  In a few cases, it looked like you were changing parameter names between files and filenames.  This might break code that was calling

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Jacob Rus
Robert Lehmann wrote: Jacob Rus wrote: 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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-02 Thread Glyph Lefkowitz
On Sun, Aug 2, 2009 at 4:17 PM, Jacob Rus jacobo...@gmail.com wrote: Robert Lehmann wrote: Jacob Rus wrote: 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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-01 Thread Jacob Rus
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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-08-01 Thread Jacob Rus
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] standard library mimetypes module pathologically broken?

2009-07-31 Thread Jacob Rus
Hi all, In an attempt to figure out some twisted.web code, I was reading through the Python Standard Library’s mimetypes module today, and was shocked at the poor quality of the code. I wonder how the mimetypes code made it into the standard library, and whether anyone has ever bothered to read

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Brett Cannon
On Fri, Jul 31, 2009 at 14:16, Jacob Rus jacobo...@gmail.com wrote: Hi all, In an attempt to figure out some twisted.web code, I was reading through the Python Standard Library’s mimetypes module today, and was shocked at the poor quality of the code. I wonder how the mimetypes code made it

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Andrew McNabb
On Fri, Jul 31, 2009 at 09:16:02PM +, Jacob Rus wrote: * The operation is crazy: It defines a MimeTypes class which actually stores the type mappings, but this class is designed to be a singleton. The way that such a design is enforced is through the use of the

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread R. David Murray
On Fri, 31 Jul 2009 at 15:17, Brett Cannon wrote: * It creates a _default_mime_types() function which declares a bunch of global variables, and then immediately calls _default_mime_types() below the definition. There is literally no difference in result between this and just putting

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Brett Cannon
On Fri, Jul 31, 2009 at 15:38, Jacob Rus jacobo...@gmail.com wrote: Brett Cannon wrote: Jacob Rus wrote: * It defines __all__: I didn’t even realize __all__ could be used for single-file modules (w/o submodules), but it definitely shouldn’t be here. __all__ is used to control

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Jacob Rus
Brett Cannon wrote:  * It creates a _default_mime_types() function which declares a    bunch of global variables, and then immediately calls    _default_mime_types() below the definition. There is literally    no difference in result between this and just putting those    variables at the top

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Jacob Rus
Brett Cannon wrote: Jacob Rus wrote:  * It defines __all__: I didn’t even realize __all__ could be used    for single-file modules (w/o submodules), but it definitely    shouldn’t be here. __all__ is used to control what a module exports when used in an import *, nothing more. Thus it's use

Re: [Python-Dev] standard library mimetypes module pathologically broken?

2009-07-31 Thread Terry Reedy
Jacob Rus wrote: Okay. Well I'd still like to hear a bit about what people really need before trying to make a new API. Try asking some specific question on python-list. How to you use the stdlib mimetypes module? ___ Python-Dev mailing list