Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable
In article <[email protected]>, Nick Coghlan wrote: > Steven Bethard wrote: > > On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote: > >> Note that such an approach would then require an altaltinstall command > >> in order to be able to install a specific version of python 3.x without > >> changing the python3 alias (e.g. installing 3.2 without overriding 3.1). > > > > I wasn't suggesting that there shouldn't be a "python3.1", > > "python3.2", etc. I'm more concerned about "fullinstall" creating > > "python3" instead of regular "python". > > If I understand Tony's summary correctly, the situation after Benjamin's > latest checkin is as follows: > > 2.x altinstall: > - installs python2.x executable > > 2.x fullinstall (default for "make install"): > - installs python2.x executable > - adjusts (or creates) python symlink to new executable > > 3.x altinstall (default for "make install"): > - installs python3.x executable > - adjusts (or creates) python3 symlink to new executable > > 3.x fullinstall: > - installs python3.x executable > - adjusts (or creates) python3 symlink to new executable > - adjusts (or creates) python symlink to new executable Note that versioning is also an unresolved issue for the scripts installed by setup.py; pydoc, idle, 2to3, and smtpd.py. See: http://bugs.python.org/issue5756 Whatever is implemented for python itself should likely apply to them as well. -- Ned Deily, [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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote: > That said, I'm starting to wonder if an even better option may be to > just drop the kwargs support from the function and require people to > always supply a parameters dictionary. That would simplify the signature > to the quite straightforward: > > def add_query_params(url, params, allow_dups=True, sep='&') That's the most straightforward and I like this more than the one below. > I agree that isn't a good option, but mapping True/False/None to those > specific behaviours also seems rather arbitrary (specifically, it is > difficult to remember which of "allow_dups=False" and "allow_dups=None" > means to ignore any duplicate keys and which means to ignore only > duplicate items). I'd say it's less of a problem when using named arguments, i.e. you read it as: allow_dups=True : yes allow_dups=False : effeminately no :), allow_dups=None : strictly no which more or less corresponds to the behaviour. > It also doesn't provide a clear mechanism for > extension (e.g. what if someone wanted duplicate params to trigger an > exception?) > > Perhaps the extra argument should just be a key/value pair filtering > function, and we provide functions for the three existing behaviours > (i.e. allow_duplicates(), ignore_duplicate_keys(), > ignore_duplicate_items()) in the urllib.parse module. This would be the most flexible and conceptually right (ye olde strategy pattern), but would clutter the API. > Note that your implementation and docstring currently conflict with each > other - the docstring says "pass them via a dictionary in second > argument:" but the dictionary is currently the third argument (the > docstring also later refers to passing OrderedDictionary as the second > argument). It's a mistake that exemplifies once again that positional args are awkward :). --- So, gentlemen, either def add_query_params(url, params, allow_dups=True, sep='&') or def allow_duplicates(...) def remove_duplicate_values(...) ... def add_query_params(url, params, strategy=allow_duplicates, sep='&') ___ 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] #!/usr/bin/env python --> python3 where applicable
Nick Coghlan writes: > 3. Change the shebang lines in Python standard library scripts to be > version specific and update release.py to fix them all when bumping the > version number in the source tree. +1 I think that it's probably best to leave "python", "python2", and "python3" for the use of downstream distributors. ISTR that was what Guido concluded, in the discuss that led to Python 3 defaulting to altinstall---it wasn't just convenient because Python 3 is a major change, but that experience has shown that deciding which Python is going to be "The python" on somebody's system just isn't a decision that Python should make. Sure, the difference between Python 2 and Python 3 is big enough to be a hairy nuisance 95% of the time, while the difference between Python 2.5 and Python 2.6 is so only 5% of the time. But the fact is that incompatibilities arise with a minor version bump, too, and all the major distros that I know about have some way to select the default Python version that will be "python". That's not because they want to distinguish between Python 2 and Python 3, nor between Python 2 and Python 1. ___ 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] #!/usr/bin/env python --> python3 where applicable
> I think that it's probably best to leave "python", "python2", and > "python3" for the use of downstream distributors. ISTR that was what > Guido concluded, in the discuss that led to Python 3 defaulting to > altinstall---it wasn't just convenient because Python 3 is a major > change, but that experience has shown that deciding which Python is > going to be "The python" on somebody's system just isn't a decision > that Python should make. Yes. However, at the language summit in Chicago, it was agreed that the installation should also provide a python3 symlink. I don't recall the agreement wrt. to the names of executables on Windows. Regards, 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] #!/usr/bin/env python --> python3 where applicable
2009/4/19 Steven Bethard : > On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson > wrote: >> 2009/4/18 Nick Coghlan : >>> I see a few options: >>> 1. Abandon the "python" name for the 3.x series and commit to calling it >>> "python3" now and forever (i.e. actually make the decision that Mitchell >>> refers to). >> >> I believe this was decided on sometime (the sprints?). > > That's an unfortunate decision. When the 2.X line stops being > maintained (after 2.7 maybe?) we're going to be stuck with the "3" > suffix forever for the "real" Python. > > Why doesn't it make more sense to just use "python3" only for > "altinstall" and "python" for "fullinstall"? Agreed. Personally, I'm -0 on this decision. I'd be -1 if I was a Linux user, or if I thought that it would be applied to Windows as well. As it is, my -0 is based on "it doesn't affect me, but it seems wrong to have the official name be different things depending on platform". Paul. ___ 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] #!/usr/bin/env python --> python3 where applicable
Martin v. Löwis wrote: >> I think that it's probably best to leave "python", "python2", and >> "python3" for the use of downstream distributors. ISTR that was what >> Guido concluded, in the discuss that led to Python 3 defaulting to >> altinstall---it wasn't just convenient because Python 3 is a major >> change, but that experience has shown that deciding which Python is >> going to be "The python" on somebody's system just isn't a decision >> that Python should make. > > Yes. However, at the language summit in Chicago, it was agreed that > the installation should also provide a python3 symlink. > > I don't recall the agreement wrt. to the names of executables on > Windows. The installer still leaves PATH alone by default, doesn't it? That means the Windows version selection is done by naming the directory. Although I guess choosing a file association for .py files becomes rather more interesting... Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] #!/usr/bin/env python --> python3 where applicable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Peterson wrote: > 2009/4/18 Nick Coghlan : >> Benjamin Peterson wrote: >>> 2009/4/18 Mitchell L Model : Some library files, such as pdb.py, begin with #!/usr/bin/env python In various discussions regarding some issues I submitted I was told that the decision had been made to call Python 3.x release executables python3. (One of the conflicts I ran into when I made 'python' a link to python3.1 was that some tools used in making the HTML documentation haven't been upgraded to run with 3.) Shouldn't all library files that begin with the above line be changed so that they read 'python3' instead of python? Perhaps I should have just filed this as an issue, but I'm not confident of the state of the plan to move to python3 as the official executable name. >>> That sounds correct. Please file a bug report. >> As Kevin pointed out, while this is a problem, changing the affected >> scripts to say "python3" instead isn't the right answer. >> >> All that happened with the Python 3 installers is that they do >> 'altinstall' rather than 'fullinstall' by default, thus leaving the >> 'python' alias alone. There is no "python3" alias unless a user creates >> it for themselves (or a distro packager does it for them). > > I've actually implemented a python3 alias for 3.1. > >> I see a few options: >> 1. Abandon the "python" name for the 3.x series and commit to calling it >> "python3" now and forever (i.e. actually make the decision that Mitchell >> refers to). > > I believe this was decided on sometime (the sprints?). It was at the Language Summit. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ6zg3+gerLs4ltQ4RAt2ZAKDRGXMXBRs5FiHLnC0MQt56janafwCdGytm /nrHCiifI/KibI+ljppr3aA= =uYha -END PGP SIGNATURE- ___ 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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Sun, Apr 19, 2009 at 1:38 AM, Mart Sõmermaa wrote: > On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote: >> That said, I'm starting to wonder if an even better option may be to >> just drop the kwargs support from the function and require people to >> always supply a parameters dictionary. That would simplify the signature >> to the quite straightforward: >> >> def add_query_params(url, params, allow_dups=True, sep='&') > > That's the most straightforward and I like this more than the one below. > >> I agree that isn't a good option, but mapping True/False/None to those >> specific behaviours also seems rather arbitrary (specifically, it is >> difficult to remember which of "allow_dups=False" and "allow_dups=None" >> means to ignore any duplicate keys and which means to ignore only >> duplicate items). > > I'd say it's less of a problem when using named arguments, i.e. you read it > as: > > allow_dups=True : yes > allow_dups=False : effeminately no :), > allow_dups=None : strictly no > > which more or less corresponds to the behaviour. > >> It also doesn't provide a clear mechanism for >> extension (e.g. what if someone wanted duplicate params to trigger an >> exception?) >> >> Perhaps the extra argument should just be a key/value pair filtering >> function, and we provide functions for the three existing behaviours >> (i.e. allow_duplicates(), ignore_duplicate_keys(), >> ignore_duplicate_items()) in the urllib.parse module. > > This would be the most flexible and conceptually right (ye olde > strategy pattern), but would clutter the API. > >> Note that your implementation and docstring currently conflict with each >> other - the docstring says "pass them via a dictionary in second >> argument:" but the dictionary is currently the third argument (the >> docstring also later refers to passing OrderedDictionary as the second >> argument). > > It's a mistake that exemplifies once again that positional args are awkward > :). > > --- > > So, gentlemen, either > > def add_query_params(url, params, allow_dups=True, sep='&') > > or > > def allow_duplicates(...) > > def remove_duplicate_values(...) > > ... > > def add_query_params(url, params, strategy=allow_duplicates, sep='&') +1 for the strategy approach. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] #!/usr/bin/env python --> python3 where applicable
> The installer still leaves PATH alone by default, doesn't it? Correct. However, people frequently set the path "by hand", so they would probably appreciate a python3 binary (and pythonw3? python3w?). Of course, those people could also manually copy/rename the executable. > Although I guess choosing a file association for .py files becomes > rather more interesting... Indeed. We could register a py3 extension (and py3w? pyw3?), but then .py might remain associated with python3, even though people want it associated with python 2. Regards, 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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
Mart Sõmermaa wrote: > On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote: > > That said, I'm starting to wonder if an even better option may be to > > just drop the kwargs support from the function and require people to > > always supply a parameters dictionary. That would simplify the signature > > to the quite straightforward: > > > > def add_query_params(url, params, allow_dups=True, sep='&') Or even better, stop trying to use a mapping, and just make the "params" value a list of (name, value) pairs. That way you can stop fiddling around with "allow_dups" and just get rid of it. Bill ___ 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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
Bill Janssen wrote:
Mart Sõmermaa wrote:
On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote:
That said, I'm starting to wonder if an even better option may be to
just drop the kwargs support from the function and require people to
always supply a parameters dictionary. That would simplify the signature
to the quite straightforward:
def add_query_params(url, params, allow_dups=True, sep='&')
Or even better, stop trying to use a mapping, and just make the "params"
value a list of (name, value) pairs. That way you can stop fiddling
around with "allow_dups" and just get rid of it.
Reluctant +1, it seems the best solution. You can always use {}.items()
if you still want to store the params in a mapping.
Michael
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Bill Janssen parc.com> writes: > > Or even better, stop trying to use a mapping, and just make the "params" > value a list of (name, value) pairs. You can even accept both a list of (name, value) pairs /and/ some **kwargs, like the dict constructor does. It would be a pity to drop the user-friendliness of kwargs just to satisfy some rare and obscure requirement. Regards Antoine. ___ 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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Antoine Pitrou wrote: > Bill Janssen parc.com> writes: > > > > Or even better, stop trying to use a mapping, and just make the "params" > > value a list of (name, value) pairs. > > You can even accept both a list of (name, value) pairs /and/ some **kwargs, > like > the dict constructor does. It would be a pity to drop the user-friendliness of > kwargs just to satisfy some rare and obscure requirement. This whole discussion seems a bit "rare and obscure" to me. I've built URLs for years without this method, and never felt the lack. What bugs me is the lack of a way to build multipart-formdata payloads, the only standard way to send non-Latin1 strings as part of a request. I'd like to suggest we move this off python-dev, and to either the Web-SIG or stdlib-sig mailing lists, which are probably more interested in all of this. Bill ___ 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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Bill Janssen parc.com> writes: > > This whole discussion seems a bit "rare and obscure" to me. I've built > URLs for years without this method, and never felt the lack. What bugs me > is the lack of a way to build multipart-formdata payloads, the only standard > way to send non-Latin1 strings as part of a request. ?? What's the problem with sending non-Latin1 data without multipart-formdata? ___ 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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Antoine Pitrou wrote: > Bill Janssen parc.com> writes: > > > > This whole discussion seems a bit "rare and obscure" to me. I've built > > URLs for years without this method, and never felt the lack. What bugs me > > is the lack of a way to build multipart-formdata payloads, the only standard > > way to send non-Latin1 strings as part of a request. > > ?? What's the problem with sending non-Latin1 data without multipart-formdata? I should have said, as values for a FORM submission. There are two ways to encode form values for a FORM submission, application/x-www-form-urlencoded, and multipart/form-data. As per http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4: ``The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that contain files, non-ASCII data, and binary data.'' And we don't support this in the http client-side standard library code. (Do we? Haven't looked lately.) The same section also says: ``Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').'' That "the ASCII code of the character" seemingly restricts it to ASCII... But this is complicated by the fact that most browsers try to use the character set the server will understand, and the widely used technique to accomplish this is to use the same charset the page the FORM occurs in uses. Unless this is set explicitly, it defaults to Latin-1. I prefer to avoid all this uncertainty, and use a well-defined format when submitting a form, so I tend to use multipart/form-data, which allows explicit control over this. Bill ___ 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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Bill Janssen parc.com> writes:
>
> ``The content type "application/x-www-form-urlencoded" is inefficient
> for sending large quantities of binary data or text containing non-ASCII
> characters.
The fact that it's "inefficient" (i.e. takes more bytes than an optimal encoding
scheme would) doesn't mean that it doesn't work.
There are millions of Web sites out there which allow you to submit non-ASCII
data without resorting to "multipart/form-data" encoding. The situations where
the submitted text is huge enough that encoding efficiency matters are probably
insanely rare.
> But this is complicated by the fact that most browsers try to use the
> character set the server will understand, and the widely used technique
> to accomplish this is to use the same charset the page the FORM occurs
> in uses. Unless this is set explicitly, it defaults to Latin-1.
Look out there, many Web pages specify a different character set than
Latin-1... UTF8 is quite a common choice in the modern world.
Also, browsers will encode those characters that cannot be encoded in the
character set using HTML escapes ("&1234;"). This means you can enter any
unicode text into any form, regardless of the encoding of the source page. It's
up to the Web application to decode the text, sure, but any decent Web framework
or toolkit should do it for you.
Regards
Antoine.
___
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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Mon, 20 Apr 2009 05:26:59 am Bill Janssen wrote: > Mart Sõmermaa wrote: > > On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote: > > > That said, I'm starting to wonder if an even better option may be > > > to just drop the kwargs support from the function and require > > > people to always supply a parameters dictionary. That would > > > simplify the signature to the quite straightforward: > > > > > > def add_query_params(url, params, allow_dups=True, sep='&') > > Or even better, stop trying to use a mapping, and just make the > "params" value a list of (name, value) pairs. That way you can stop > fiddling around with "allow_dups" and just get rid of it. Surely it should support any mapping? That's what I do in my own code. People will use regular dicts for convenience when they don't care about order or duplicates, and (name,value) pairs, or an OrderedDict, when they do. I suppose you could force people to write params.items() if params is a dict, but it seems wrong to force an order on input data when it doesn't require one. -- Steven D'Aprano ___ 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] [Python-ideas] Proposed addtion to url lib.parse in 3.1 (and urlparse in 2.7)
Antoine Pitrou wrote:
> Bill Janssen parc.com> writes:
> >
> > ``The content type "application/x-www-form-urlencoded" is inefficient
> > for sending large quantities of binary data or text containing non-ASCII
> > characters.
>
> The fact that it's "inefficient" (i.e. takes more bytes than an optimal
> encoding
> scheme would) doesn't mean that it doesn't work.
Absolutely. I'm just quoting the spec to you. In any case, being able to send
multipart/form-data would be a nice thing to have, if only for file uploads.
> Look out there, many Web pages specify a different character set than
> Latin-1... UTF8 is quite a common choice in the modern world.
Sure. But nowhere does a spec say that this page charset should be used
in sending the values of a FORM using application/x-www-form-urlencoded
in a new HTTP request. It's just a convention some browsers use.
> Also, browsers will encode those characters that cannot be encoded in the
> character set using HTML escapes ("&1234;"). This means you can enter any
Sure, some browsers will. Others will apparently replace them with
question marks. It's undefined.
> unicode text into any form, regardless of the encoding of the source page.
> It's
> up to the Web application to decode the text, sure, but any decent Web
> framework
> or toolkit should do it for you.
Bill
___
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
