Re: [Python-Dev] urlparse.urlunsplit should be smarter about +
Senthil Kumaran writes:
> Not all urls have the 'authority' component after the scheme. (sip
> based urls for e.g) urlparse differentiates those by maintaining a
> list of scheme names which will follow the pattern of parsing, and
> joining for the urls which have a netloc (or authority component).
> This is in general according to RFC 3986 itself.
This actually quite at variance with the RFC. The grammar in section
3 doesn't make any reference to schemes as being significant in
parsing. Whether an authority component is to be parsed or not is
entirely dependent on the presence or absence of the "//" delimiter
following the scheme and its colon delimiter. AFAICS, if the "//"
delimiter is present, an authority component (possibly empty) *must*
be present in the parse. Presumably an unparse should then include
that empty component in the generated URI (ie, a "scheme:///..." URI).
Thus, it seems that by the RFC, regardless of any registration,
urlparse.unsplit(urlparse.split('git+file:///foo/bar'))
should produce 'git+file:///foo/bar' (or perhaps raise an error in
"validation" mode). The only question is whether registration of
'git+file' as a use_netloc scheme should force
urlparse.unsplit(urlparse.split('git+file:/foo/bar'))
to return 'git+file:///foo/bar', or whether 'git+file:/foo/bar' would
be acceptable (or better).
None of what I wrote here or elsewhere takes account of backward
compatibility, it is true. I'm only talking about the letter of the
RFC.
___
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
Re: [Python-Dev] urlparse.urlunsplit should be smarter about +
On Mon, May 10, 2010 at 05:11:12PM +0900, Stephen J. Turnbull wrote: > > Not all urls have the 'authority' component after the scheme. (sip > > based urls for e.g) urlparse differentiates those by maintaining a > > list of scheme names which will follow the pattern of parsing, and > > joining for the urls which have a netloc (or authority component). > > This is in general according to RFC 3986 itself. > > This actually quite at variance with the RFC. The grammar in section I should have said, 'treatment of urls with authority' and 'treatment of urls without authority' in terms of parsing and joining is as per RFC. How it is doing practically is by maintaining a list of urls with known scheme names which use_netloc. -- Senthil Many Myths are based on truth -- Spock, "The Way to Eden", stardate 5832.3 ___ 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
Re: [Python-Dev] urlparse.urlunsplit should be smarter about +
Senthil Kumaran writes: > I should have said, 'treatment of urls with authority' and 'treatment > of urls without authority' in terms of parsing and joining is as per > RFC. How it is doing practically is by maintaining a list of urls > with known scheme names which use_netloc. Why do that if you can get better behavior based purely on syntactic analysis? ___ 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
Re: [Python-Dev] What's New text on future maintenance
On May 06, 2010, at 09:33 PM, Benjamin Peterson wrote: >I don't think there's any point in being hypothetical about. I believe >we've already said that maintence for 2.7 will last for at least 5 >years, so let's proclaim it. +1. If our goal is to move our community to Python 3, then I think we do them the biggest service to be explicit about our intentions for maintenance of 2.7 and the future of Python 2. -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 7 updated
On 9 May, 2010, at 20:33, Antoine Pitrou wrote: > > Hello, > > The untabification of C files didn't produce any noticeable problem on > the buildbots. I've updated PEP 7 with the mention that all C files > should be 4-space indented, and removed the obsolete wording about > some files being indented with tabs. Does anyone know of a way to teach vim that C sources in a python checkout should have 4-space indents without changing the defaults for other C files? Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] vim (was: PEP 7 updated)
On Mon, May 10, 2010 at 04:09:06PM +0200, Ronald Oussoren wrote: > Does anyone know of a way to teach vim that C sources in a python checkout > should have 4-space indents without changing the defaults for other C files? BufReadPre /usr/local/src/Python/*/*.c set sts=4 sw=4 Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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
Re: [Python-Dev] vim (was: PEP 7 updated)
On Mon, 10 May 2010 20:40:00 +0400, Oleg Broytman wrote: > On Mon, May 10, 2010 at 04:09:06PM +0200, Ronald Oussoren wrote: > > Does anyone know of a way to teach vim that C sources in a python checkout > > should have 4-space indents without changing the defaults for other C > > files? > > BufReadPre /usr/local/src/Python/*/*.c set sts=4 sw=4 Alternatively you could sniff the file for leading tabs and set the "filetype" or the tab setting based on that. I think Brett has a vimrc somewhere that does something like that. --David ___ 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
Re: [Python-Dev] vim (was: PEP 7 updated)
On Mon, May 10, 2010 at 11:10, R. David Murray wrote: > On Mon, 10 May 2010 20:40:00 +0400, Oleg Broytman wrote: > > On Mon, May 10, 2010 at 04:09:06PM +0200, Ronald Oussoren wrote: > > > Does anyone know of a way to teach vim that C sources in a python > checkout should have 4-space indents without changing the defaults for other > C files? > > > > BufReadPre /usr/local/src/Python/*/*.c set sts=4 sw=4 > > Alternatively you could sniff the file for leading tabs and set the > "filetype" or the tab setting based on that. I think Brett has a vimrc > somewhere that does something like that. > Misc/Vim/python.vim does what you need to do. ___ 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
Re: [Python-Dev] PEP 7 updated
On Mon, May 10, 2010 at 07:09, Ronald Oussoren wrote: > > On 9 May, 2010, at 20:33, Antoine Pitrou wrote: > > > > > Hello, > > > > The untabification of C files didn't produce any noticeable problem on > > the buildbots. I've updated PEP 7 with the mention that all C files > > should be 4-space indented, and removed the obsolete wording about > > some files being indented with tabs. > > Does anyone know of a way to teach vim that C sources in a python checkout > should have 4-space indents without changing the defaults for other C files? > :help autocmd-patterns has this example, which should be easy to adapt: :autocmd BufRead /vim/src/*.c set cindent Set the 'cindent' option for C files in the /vim/src directory. > Ronald > > > ___ > 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/ddborowitz%40gmail.com > > -- It is better to be quotable than to be honest. -Tom Stoppard Borowitz ___ 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
Re: [Python-Dev] urlparse.urlunsplit should be smarter about +
On Mon, May 10, 2010 at 05:56:29PM +0900, Stephen J. Turnbull wrote: > Senthil Kumaran writes: > > > I should have said, 'treatment of urls with authority' and 'treatment > > of urls without authority' in terms of parsing and joining is as per > > RFC. How it is doing practically is by maintaining a list of urls > > with known scheme names which use_netloc. > > Why do that if you can get better behavior based purely on syntactic > analysis? For the cases for just parsing and splitting, the syntactic behaviours are fine enough. I agree with your comments and reinstatement of RFC rules in the previous emails. The problem as we know off, comes while unparsing and joining, ( also I have not yet looked at the relative url joining behaviour where redundant /'s can be ignored). As you may already know, when the data is ParseResult(scheme='file', netloc='', path='/tmp/junk.txt', params='', query='', fragment='') You might expect the output to be file:///tmp/junk.txt Original might be same too. But for: ParseResult(scheme='x', netloc='', path='/y', params='', query='', fragment='') One can expect a valid output to be: x:/y Your suggestion of netloc/authority being differentiate by '' and None seems a good one to analyze. Also, by keeping a registry of valid schemes, are you not proposing something very similar to uses_netloc? But with a different API to handle parsing based on registry values. Is my understanding of your proposal correct? FWIW, I looked at the history of uses_netloc list and it seems that it been there from the first version when urlparse module followed different rfc specs for different protocols (telnet, sip etc), so any changes should be carefully incorporated as not to break the existing solutions. -- Senthil ___ 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
