houghts about this, or maybe some good (it
had better be *really* good) explanations why this code is the way
it is? I'd be happy to try to rewrite it, but I think I’d need a bit
of help figuring out how to make the rewrite backwards-compatible.
Note: someone e
y
which don’t break when the current docs are followed (anything
complicated is going to break unless the code is read a few times),
and assuming such uses it would be possible to swap out most of the
implementation for something relatively straight-forward. But if any
of the edges are pushed, the sema
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
Andrew McNabb wrote:
> 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
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
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
__
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 excep
way, back in 1997 or
whatever. I don't think there's necessarily any need for it these
days: reading the default files even should be blazingly fast, unless
the disk is otherwise thrashing: each is about a a 37k file, and there
are at most going to be 3 or 4 of them installed on one m
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
&
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!
>
the chance.
> Then, you might garner some more reviews by putting your patch up on
> Rietveld; it makes reviewing much painful.
Okay, now that svn.python.org is back up, here's a Rietveld link:
http://codereview.appspot.com/104091/show
Cheers,
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 De
en
just fixing the obvious implementation problems would be a big improvement.
Cheers,
Jacob Rus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
13 matches
Mail list logo
