__cmp__ used to provide a convenient way to make all ordering operators work
by defining a single method. For better or worse, it's gone in 3.0.
To provide total ordering without __cmp__ one has to implement all of
__lt__, __gt__, __le__, __ge__, __eq__ and __ne__. However, in all but a few
cases
On Tue, Mar 10, 2009 at 3:57 PM, Michael Foord wrote:
> Is there something you don't like about this one:
> http://code.activestate.com/recipes/576529/
>
Yes -- it is not in the standard library. As I said, eventually all the
15,000 matches on Google Code need to update their code and copy that
s
See http://wiki.python.org/moin/ApplicationInfrastructure , "Version
handling" below for a possible strict version API.
The page is relevant for the general packaging discussion as well, although
it's not fully fleshed out yet.
MS
On Fri, Mar 27, 2009 at 5:11 PM, "Martin v. Löwis" wrote:
> Corr
> Instead of trying to parse some version string, distutils should
> require defining the version as tuple with well-defined entries -
> much like what we have in sys.version_info for Python.
>
> The developer can then still use whatever string format s/he wants.
>
> The version compare function wo
On Sat, Mar 28, 2009 at 12:37 AM, Ben Finney <
bignose+hates-s...@benfinney.id.au >wrote:
> "Martin v. Löwis" writes:
>
> > I don't mind the setuptools implementation being used as a basis
> > (assuming it gets contributed), but *independently* I think a
> > specfication is needed what version st
The general consensus in python-ideas is that the following is needed, so I
bring it to python-dev to final discussions before I file a feature request
in bugs.python.org.
Proposal: add add_query_params() for appending query parameters to an URL to
urllib.parse and urlparse.
Implementation:
http:
On Sun, Apr 12, 2009 at 3:23 PM, Jacob Holm wrote:
> Hi Mart
>
>>>> add_query_params('http://example.com/a/b/c?a=b', b='d', foo='/bar')
>>'http://example.com/a/b/c?a=b&b=d&foo=%2Fbar <
>> http://example.com/a/b/c?a=b&b=d&foo=%2Fbar>'
>>
>> Duplicates are discarded:
>>
>
> Why discard dupl
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou wrote:
> Mart Sõmermaa gmail.com> writes:
> >
> > Proposal: add add_query_params() for appending query parameters to an URL
> to
> urllib.parse and urlparse.
>
> Is there anything to /remove/ a query parameter?
I&#
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
wrote:
>
> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
> >
> >
> > On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> > wrote:
> >>
> >> Mart Sõmermaa gmail.com> writes:
> >> &
On Sat, Apr 18, 2009 at 3:41 PM, Nick Coghlan wrote:
> Yep - Guido has pointed out in a few different API design discussions
> that a boolean flag that is almost always set to a literal True or False
> is a good sign that there are two functions involved rather than just
> one. There are exception
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
11325: 51.32% larger
Mem max: 7776.000 -> 8676.000: 10.37% larger
Usage over time: http://tinyurl.com/yz96gw2
unpickle_list:
Min: 0.922200 -> 0.861167: 7.09% faster
Avg: 0.955964 -> 0.976829: 2.14% slower
Not significant
Stddev: 0.04374 -> 0.21061: 79.23% larger
Mem max: 6820.000
On Wed, Nov 4, 2009 at 5:54 PM, Collin Winter wrote:
> Do note that the --track_memory option to perf.py imposes some
> overhead that interferes with the performance figures.
Thanks for the notice, without -m/--track_memory the deviation in
results is indeed much smaller.
> I'd recommend
> runni
elved into the designs and considered their applicability to
Python?
Hoping-to-see-some-V8-and-Python-teams-collaboration-in-Mountain-View-ly
yours,
Mart Sõmermaa
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
On Tue, Jan 27, 2009 at 5:04 PM, Jesse Noller wrote:
> Hi Mart,
>
> This is a better discussion for the python-ideas list. That being
> said, there was a thread discussing this last year, see:
>
> http://mail.python.org/pipermail/python-dev/2008-October/083176.html
>
> -jesse
>
Indeed, sorry. In
15 matches
Mail list logo
