On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > But I know that everyone and their email client is against me on this
> > one, so I am not going to really try to tear into this. But I do
> > think that lambda needs a renaming. Speaking as someone who still
> > fo
Brett Cannon wrote:
> But I know that everyone and their email client is against me on this
> one, so I am not going to really try to tear into this. But I do
> think that lambda needs a renaming. Speaking as someone who still
> forgets that Python's lambda is not the same as those found in
> fun
Mark Edgington wrote:
> Does anyone have any comments about applying the following patch to
> asynchat?
That patch looks wrong. What does it mean to "run in a thread"?
All code runs in a thread, all the time: sometime, that thread
is the main thread.
Furthermore, I can't see any presumed thread
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and ti
Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
>
T
Does anyone have any comments about applying the following patch to
asynchat? It should not affect the behavior of the module in any way
for those who do not want to use the feature provided by the patch. The
point of the patch is to make it easy to use asynchat in a multithreaded
application
Patch / Bug Summary
___
Patches : 391 open ( +0) / 3038 closed (+10) / 3429 total (+10)
Bugs: 915 open ( +9) / 5540 closed (+21) / 6455 total (+30)
RFE : 209 open ( +2) / 197 closed ( +0) / 406 total ( +2)
New / Reopened Patches
__
difflib e
Alex Martelli wrote:
> On 2/6/06, Aahz <[EMAIL PROTECTED]> wrote:
>...
>
>>>def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
>>> diff = abs(x - y)
>>> ave = (abs(x) + abs(y))/2
>>> return diff < absolute_err or diff/ave < relative_err
>>>
>>>Also, separating the two terms with
2006/2/6, Raymond Hettinger <[EMAIL PROTECTED]>:
> The original Numeric definition is likely to be better for people who know
> what they're doing; however, I still question whether it is an appropriate
> remedy for the beginner issue
> of why 1.1 + 1.1 + 1.1 doesn't equal 3.3.
Beginners won't kn
[Chris Smith]
> Does it help to spell it like this?
>
> def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
> diff = abs(x - y)
> ave = (abs(x) + abs(y))/2
> return diff < absolute_err or diff/ave < relative_err
There is a certain beauty and clarity to this presentation; howe
Steven Bethard wrote:
> Guido van Rossum wrote:
>> After so many attempts to come up with an alternative for lambda,
>> perhaps we should admit defeat. I've not had the time to follow the most
>> recent rounds, but I propose that we keep lambda, so as to stop wasting
>> everybody's talent and time
On 2/6/06, Aahz <[EMAIL PROTECTED]> wrote:
...
> > def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
> > diff = abs(x - y)
> > ave = (abs(x) + abs(y))/2
> > return diff < absolute_err or diff/ave < relative_err
> >
> > Also, separating the two terms with 'or' rather than '+' ma
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
+1.
This would remove my s
On Mon, Feb 06, 2006, Chris or Leslie Smith wrote:
>Aahz:
>>Alex:
>>>
> || def areclose(x,y,rtol=1.e-5,atol=1.e-8):
> || return abs(x-y) |
> | Looks interesting. I don't quite understand what atol/rtol are,
> | though.
>
> Does it help to spell it like this?
>
> def areclose(x, y, relativ
||
|| def areclose(x,y,rtol=1.e-5,atol=1.e-8):
|| return abs(x-y)http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Now consider how nice it would be, on occasion, to be able to operate
> on an integer that's guaranteed to be 8, 16, 32, or 64 bits, to
> ensured the desired shifting/masking behavior for certain kinds of
> low-level programming; and also on one
On 2/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> What we should do in 3.0 is not entirely clear to me. It would be nice
> if there was only a single type (named 'int', of course) with two
> run-time representations, one similar to the current int and one
> similar to the current long
On 2/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/6/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> > yeah... the problem is differentiating the empty set from an empty dict.
> > The only alternative that occured to me was the not-so-nice and
> > not-backwards-compatible "{:}" for an em
Donovan Baarda <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote:
> > Along the lines of "not every x line function should be a builtin", "not
> > every builtin should have syntax". I think that sets have particular
> > uses, but I don't believe those uses ar
On 2/6/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Is PEP 237 phase C to be implemented sooner than py3k,
> making isinstance(, int) a transparently distinction-hiding alias
> for
> isinstance(, integer), or outright illegal? IOW, will
> isinstance(, int)
> be _guaranteed_ to be a bug, thus r
On 2/6/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> yeah... the problem is differentiating the empty set from an empty dict.
> The only alternative that occured to me was the not-so-nice and
> not-backwards-compatible "{:}" for an empty dict and "{}" for an empty
> set.
How about spelling the e
On Mon, 2006-02-06 at 15:36 +0100, Ronald Oussoren wrote:
> On Monday, February 06, 2006, at 03:12PM, Donovan Baarda <[EMAIL PROTECTED]>
> wrote:
>
> >On Fri, 2006-02-03 at 20:02 +0100, "Martin v. Löwis" wrote:
> >> Donovan Baarda wrote:
> >> > Before set() the standard way to do them was to use
On Monday, February 06, 2006, at 03:12PM, Donovan Baarda <[EMAIL PROTECTED]>
wrote:
>On Fri, 2006-02-03 at 20:02 +0100, "Martin v. Löwis" wrote:
>> Donovan Baarda wrote:
>> > Before set() the standard way to do them was to use dicts with None
>> > Values... to me the "{1,2,3}" syntax would have
On Mon, 6 Feb 2006 09:05:01 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>On Mon, Feb 06, 2006 at 05:33:57AM +, Bengt Richter wrote:
>
>> Perhaps I missed a py3k assumption in this thread (where I see in the PEP
>> that "Remove distinction between int and long types" is core item number
>>
On Fri, 2006-02-03 at 20:02 +0100, "Martin v. Löwis" wrote:
> Donovan Baarda wrote:
> > Before set() the standard way to do them was to use dicts with None
> > Values... to me the "{1,2,3}" syntax would have been a logical extension
> > of the "a set is a dict with no values, only keys" mindset. I
On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> wrote:
[...]
> > Nuff was a fairy... though I guess it depends on where you draw the
> > line; should [1,2,3] be list(1,2,3)?
>
> Who is "Nuff"?
fairynuff... :-)
> Along the lines of "not every x line f
On Mon, Feb 06, 2006 at 05:33:57AM +, Bengt Richter wrote:
> Perhaps I missed a py3k assumption in this thread (where I see in the PEP
> that "Remove distinction between int and long types" is core item number
> one)?
http://www.python.org/peps/pep-0237.html -- an ungoing process, not a
Py3K-
27 matches
Mail list logo
