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 it
[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 fo
On Fri, Jul 31, 2009 at 14:16, Jacob Rus 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 into the stan
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 m
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 tho
On Fri, Jul 31, 2009 at 15:38, Jacob Rus 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 what
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
v
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
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
Pyt
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 u
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
Pyth
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
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 th
2009/8/2 Michael Foord :
[...]
>> 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 suite to use your
rep
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 i
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
> c
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-p
On Sun, Aug 2, 2009 at 4:17 PM, Jacob Rus 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 (though I wo
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
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
> fix
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 it in
the next major version.
If
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
http://mail.python.org/mailm
Benjamin Peterson wrote:
>
> If python-dev was more interested, we would have a policy for this. *cough*
>
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.
--
Nic
Nick Coghlan wrote:
> Benjamin Peterson wrote:
>>
>> If python-dev was more interested, we would have a policy for this. *cough*
>>
>
> 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 se
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
Nick Coghlan schrieb:
> Nick Coghlan wrote:
>> Benjamin Peterson wrote:
>>>
>>> If python-dev was more interested, we would have a policy for this. *cough*
>>>
>>
>> PEP 5 isn't enough? (I'll grant that PEP could probably do with
>> mentioning the use of warnings.warn(DeprecationWarning) explici
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
depr
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
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 y
2009/8/14 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 obvi
30 matches
Mail list logo
