[Python-Dev] Fwd: RFC - GoogleSOC proposal -cleanupurllib
Resending this; as i think my sf.net email alias got blocked by the python-dev. -- Forwarded message -- From: Senthil <[EMAIL PROTECTED]> Date: Mar 24, 2007 6:05 AM Subject: RFC - GoogleSOC proposal -cleanupurllib To: [email protected] Hi All, I have written a proposal to cleanup urllib as part of Google SoC. I am attaching the file 'soc1' with this email. Requesting you to go through the proposal and provide any feedback which I can incorporate in my submission. Thanks, Senthil -- O.R.Senthil Kumaran homepage: http://puggy.symonds.net/~senthil blog: http://phoe6.livejournal.com soc1 Description: Binary data ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hindsight on Py_UNICODE_WIDE?
> 1. In hindsight, what do you think about PEP 261, the Py_UNICODE_WIDE > build option? On balance, has this been good, bad, or indifferent? > What's good/bad about it? Unlike MAL, I think it was good choice, primarily for political reasons. People kept complaining that Python doesn't "really" support Unicode, and they went silence since this change was made. These days, Linux distributions always ship Python in UCS-4 mode (triggered by the fact that wchar_t is also UCS-4 on Linux); Windows distributions always chose UCS-2 (for the same reason: wchar_t is two bytes). If it weren't for Windows, I would suggest that always using UCS-4 is the simplest solution. FWIW, Smalltalk implementations (VisualWorks and Squeak in particular) seem to go the "multiple internal representations" route, even though they have mutable strings. If you put a wider character into a smaller string, the smaller string become:s transparently wider. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: RFC - GoogleSOC proposal -cleanupurllib
The original went through. You likely didn't get any responses because the proposal has text that is significantly longer than most other SoC proposals, and perhaps people just haven't had the time to read it yet. Also, I don't believe anyone else has posted the full text of their proposal publicly, usually it is "I would like to do this kind of thing, what do people think?". If I were to summarize your proposal, it would be "merge, clean up, and add features to urllib, urllib2, and urlparse". Sounds reasonable for Python 3, but remember that you will need to update any standard library module that currently uses urllib, urllib2, and urlparse to make sure that they pass the test suite, probably add tests to the test suite for your new module, and include documentation (I can't remember if any of that was in your proposal). - Josiah "Senthil Kumaran" <[EMAIL PROTECTED]> wrote: > Resending this; as i think my sf.net email alias got blocked by the > python-dev. > > > -- Forwarded message -- > From: Senthil <[EMAIL PROTECTED]> > Date: Mar 24, 2007 6:05 AM > Subject: RFC - GoogleSOC proposal -cleanupurllib > To: [email protected] > > > Hi All, > I have written a proposal to cleanup urllib as part of Google SoC. I > am attaching the file 'soc1' with this email. Requesting you to go > through the proposal and provide any feedback which I can incorporate > in my submission. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: RFC - GoogleSOC proposal -cleanupurllib
Senthil Kumaran wrote: > I have written a proposal to cleanup urllib as part of Google SoC. I am > attaching the file 'soc1' with this email. Requesting you to go through the > proposal and provide any feedback which I can incorporate in my submission. >From your proposal: > 2) In all modules, Follow the new RFC 2396 in favour of RFC 1738 and RFC 1808. > [...] > In all modules, follow the new RFC 2396 in favor of RFC 1738, RFC 1808. The > standards for URI described in RFC 2396 is different from older RFCs and > urllib, urllib2 modules implement the URL specifications based on the older > URL specification. This will need changes in urlparse and other parse > modules to handle URLS as specified in the RFC2396. The "new" RFC 2396 was superseded by STD 66 (RFC 3986) two years ago. Your failure to notice this development doesn't bode well :) j/k, although it does undermine confidence somewhat. I think the bugfixes sound great, but major enhancements and API refactorings need to be undertaken more cautiously. In any case, I have a few suggestions: - Read http://en.wikipedia.org/wiki/Uniform_Resource_Identifier. (I wrote the majority of it, and got peer review from the URI WG a while back). - Read http://en.wikipedia.org/wiki/Percent_encoding. (I wrote most of this too). - Familiarize yourself with STD 66. (i.e., don't trust anything I wrote ;)) Especially note its differences from RFC 2396 (summarized in an appendix). - Seek peer review for any changes that you attribute to changing standards. In my experience implementing a general-purpose URI processing library (http://cvs.4suite.org/viewcvs/4Suite/Ft/Lib/Uri.py?view=markup ), there were times when I thought the standard was saying a bit more than it really was, especially when it came to percent-encoding, which has several somewhat-conflicting conventions and standards governing it. I tried to cover these in the Wikipedia article. - Anticipate real-world use cases. If you go down the road of doing what the standards recommend (be aware of "should" vs "must" and whether it's directed at URI producers or consumers), you might lose sight of the fact that there's a reason, for example, people use encodings other than the recommended UTF-8 as the basis for percent-encoding. Similarly, expectations surrounding the behavior of 'file' URIs and path-portions thereof are sometimes less than optimal in the real world. If you're designing an API, be flexible, and seek review for any compatibilities you intend to introduce. - Be aware of the fact that people might have different expectations when they use different string types (unicode, str) in URI processing, and different levels of awareness of the levels of abstraction at which URI processing operates. It can be difficult to uniformly handle unicode and str. And then there's IRIs (RFC 3987)... For additional background, you might also check the python-dev discussion of urllib in Sep 2004, urlparse in Nov 2005, and the competing uriparse.py proposals (Apr, Jun 2006). Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SoC proposal: multimedia library
Hello everyone, I would like to participate as a student in google Summer of Code and I'm interested in feedback on a multimedia library for Python. The library I propose should have the following features: * the capability to extract and decompress video and audio from a few common multimedia file format; * and, vice versa, it can create a compressed video file from a series of still images and from uncompressed audio; * it should have an interface as simple and pythonic as possible; * it must be cross-platform, easy to extend and not be limited to a single file container format or to some specific audio or video compression format; * at least a subset of the supported formats should be available without any external dependency. Why? I think this can be an useful addition to the standard library: the goal isn't to reimplement a full fledged media player like mplayer or VLC, but to offer, e.g., a very simple way to add multimedia animations to a Tkinter application. Or, for an application that generates animations, a simple way to save them in a common file format that can be played by existing media players. How? I know that this may sound like a project way too big for SoC, but I think it may be feasible: I plan to split it in two parts. A low level part responsible for splitting encoded audio and video data from multimedia files (demuxing) and putting it together in new multimedia files (muxing). I plan to initially only support AVI and MOV/Quicktime files because they are relatively simple and well documented (and I have already written Python programs for manipulating these two formats, so I know them pretty well). New container formats can be added later and, if the library interface meets the requirements, existing application will be able to use them without any modification. The second part of the library is a collection of codecs for compressing and decompressing audio and video streams. I don't plan to invest too much time here: the idea is to write only a few ctypes wrappers around existing libraries for common formats (e.g. MPEG4/XVID and Theora for video and MP3 and Vorbis for audio) and/or use existing third-part Python bindings. Again, new codecs can be added later. Similar libraries. There are already a number of multimedia libraries both inside and outside of the standard library, but AFAIK they all have limitations: * a lot of them are specific for a single container format or codec (e.g. aifc, wave, oggpy, python-vorbis...); * they aren't cross-platform (e.g. videoreader). Is there any interest in a library of this kind (inside or outside of the stdlib)? Suggestions? Criticism? -- Lino Mastrodomenico E-mail: [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: multimedia library
"Lino Mastrodomenico" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Is there any interest in a library of this kind (inside or outside of | the stdlib)? | Suggestions? Criticism? There is a Python wrapping of the cross-platform Simple Directmedia Library (C) that is a major part of PyGame. Are you familiar with both and how does your proposal improve on the current situation. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Final (final?) update to patch about socket timeout...
Facundo Batista wrote: >> Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" >> buildbot. > > Also it fails in "g4 osx.4 trunk". In all the other platforms it works > ok. As usual, human error. Now I used the already present threading custom testing architecture in test_socket.py, and fixed an issue in httplib.py, and everything is ok. Well, not a big ok, some buildbots fails because other causes, and even the "alpha Tru64" fails in test_socket, but it was failing *before * my check ins, so I'm sure I didn't break anything. This process is finished. I'll continue to work in the other libraries. Sorry for the mess. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
