headers
Jacob Rus | 1 Aug 2009 01:07
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 level of the file, so I have no idea why
>>>>    this function exists, except to make the code more confusing.
>>>
>>> It could potentially be used for testing, but that's a guess.
>>
>> Here's an abridged version of this function. I don’t think there’s any
>> reason for this that I can see.
>>
>>    def _default_mime_types():
>>        global suffix_map
>>        global encodings_map
>>        global types_map
>>        global common_types
>>
>>        suffix_map = {
>>            '.tgz': '.tar.gz', #...
>>            }
>>
>>        encodings_map = {
>>            '.gz': 'gzip', #...
>>            }
>>
>>        types_map = {
>>            '.a'      : 'application/octet-stream', #...
>>            }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Rus | 1 Aug 2009 04:53
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 of the module-global 'init' function, which 
>>     makes an instance of the class, and then maps all of the 
>>     functions in the module global namespace to instance methods. 
>>     But confusingly, all such functions are also defined 
>>     independently of the init function, with definitions such as:
>>   
>>         def guess_type(url, strict=True):
>>             if not inited:
>>                 init()
>>             return guess_type(url, strict)
> 
> I can't speak for any of your other complaints, but I know that this
> weird init stuff is fixed in trunk.

Actually, this fix changes the semantics of the code quite
substantially (not in any way that is incompatible with the
extremely vague documentation, but in a way that might break any
code that relies on the Python <=2.6 behavior). If such a change is
okay, then we can do quite a bit of implementation change under
these new semantics.

Cheers,
Jacob Rus

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Reedy | 1 Aug 2009 05:03
Picon
Favicon

Re: standard library mimetypes module pathologically broken?

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
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Sean Reifschneider | 2 Aug 2009 02:00
Gravatar

Re: REVIEW: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.

"make test" in both python and py3k trunks were happy with this change, so
I've documented the issue in Issue #6624 and committed it in 
74277 (2.x) and 74278 (3.x).

Sean
--

-- 
 "The only thing more expensive than hiring a professional is hiring
 an amateur."  -- Red Adair,  Oil Well Fire-Fighter
Sean Reifschneider, Member of Technical Staff <jafo <at> tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Vincent Legoll | 2 Aug 2009 00:40
Picon

pylinting the stdlib

Hello,

I've fed parts of the stdlib to pylint and after some filtering
there appears to be some things that looks strange, I've
filled a few bugs to the tracker for them.

6623 Lib/ftplib.py netrc class parsing problem
6622 [RFC] wrong variable used in Lib/poplib.py
6621 [RFC] Remove leftover use of Carbon module from Lib/binhex.py
6620 Variable may be used before first being assigned to in Lib/locale.py
6619 Remove duplicated function in Lib/inspect.py

Is this useless and taking reviewer's time for nothing ?

Please advise, if this is deemed useful, I'll continue further

--

-- 
Vincent Legoll
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 2 comments |
headers
Jacob Rus | 2 Aug 2009 06:03
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 understandable to someone reading the code.
>
> That all sounds reasonable.

Okay, as a start, I did a simple code cleanup that I think fixes some
potential bugs (any code using its own instance of the MimeTypes class
should now be insulated from other same-process users of the module),
chops out 80 or 90 lines, removes some redundant code paths, clarifies
some of the micro level behavior of some chunks of code, adds a bit
more to the docstring at the top of the file, and makes the program
flow somewhat clearer … *without* changing the semantics of the module
or its included list of MIME types.

Here's a diff:
http://pastie.textmate.org/568329

And here's the whole file:
http://pastie.textmate.org/568333

This change does require any tests that previously called
_default_mime_types() to instead call init().

Any thoughts?
Jacob Rus
(Continue reading)

Permalink | Reply | 20 comments |
headers
Jacob Rus | 2 Aug 2009 06:58
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Jacob Rus | 2 Aug 2009 08:37
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 code flow understandable to someone reading the code.
>>
>> That all sounds reasonable.
>
> Okay, as a start, I did a simple code cleanup that I think fixes some
> potential bugs (any code using its own instance of the MimeTypes class
> should now be insulated from other same-process users of the module),
> chops out 80 or 90 lines, removes some redundant code paths, clarifies
> some of the micro level behavior of some chunks of code, adds a bit
> more to the docstring at the top of the file, and makes the program
> flow somewhat clearer … *without* changing the semantics of the module
> or its included list of MIME types.

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 code), and makes the
behavior of the code much clearer, I think, by making it very obvious
how the singleton instance is actually working.

Additionally, this version brings the lazy loading of Apache
mime.types files to every MimeTypes instance, and makes the
read_mime_types() function behave as expected (only getting the
(Continue reading)

Permalink | Reply | 18 comments |
headers
Michael Foord | 2 Aug 2009 12:53
Picon
Favicon
Gravatar

Re: standard library mimetypes module pathologically broken?

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 they're there, and
>>>> make the code flow understandable to someone reading the code.
>>>>         
>>> That all sounds reasonable.
>>>       
>> Okay, as a start, I did a simple code cleanup that I think fixes some
>> potential bugs (any code using its own instance of the MimeTypes class
>> should now be insulated from other same-process users of the module),
>> chops out 80 or 90 lines, removes some redundant code paths, clarifies
>> some of the micro level behavior of some chunks of code, adds a bit
>> more to the docstring at the top of the file, and makes the program
>> flow somewhat clearer … *without* changing the semantics of the module
>> or its included list of MIME types.
>>     
>
> 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 code), and makes the
> behavior of the code much clearer, I think, by making it very obvious
(Continue reading)

Permalink | Reply | 16 comments |
headers
Paul Moore | 2 Aug 2009 13:45
Picon
Gravatar

Re: standard library mimetypes module pathologically broken?

2009/8/2 Michael Foord <fuzzyman <at> 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 suite to use your
replacement initialisation function where needed (if you didn't
already do that).

Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 15 comments |

Gmane