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
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 s
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
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
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 a
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.
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-frien
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 si
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 signatu
> 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 cho
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. Th
-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 s
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
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
>
> 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 ex
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
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 straightforwa
In article <49eab0c2.8040...@gmail.com>,
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
>
18 matches
Mail list logo
