On 19/05/2007 3.21, Guido van Rossum wrote:
>>> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
>>> Operators) by Greg Ewing.
>>>
>>> It is time to reject it due to lack of interest, or revive it!
>> Didn't you post something about this a short time ago,
>> suggesting you were
Jim Jewett wrote:
> On the other hand, I'm not sure how often users of non-latin languages
> will want to mix in latin letters. The tech report suggested that it
> is fairly common to use all of (Hiragana | Katakana | Han | Latin) in
> Japanese text, but I'm not sure whether it would be normal to
On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> Operators) by Greg Ewing.
-1. "and" and "or" affect the flow of control. It's a matter
of taste, but I feel the benefit is too small here to add
another flow-control q
Giovanni Bajo wrote:
> On 19/05/2007 3.21, Guido van Rossum wrote:
>
While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
Operators) by Greg Ewing.
It is time to reject it due to lack of interest, or revive it!
>>> Didn't you post something about
On 19/05/2007 19.12, Neil Toronto wrote:
> There's a fairly common one, actually, that comes up quite a lot in
> Numpy. Currently, best practice is a wart. Here's some code of mine for
> evaluating log probabilities from the Multinomial family:
>
> class Multinomial(DistFamily):
> @
Giovanni Bajo wrote:
> Another workaround could be:
>
> return scipy.where(
> "xsum != n or psum < 0.9 or "
> "psum > 1.01 or not scipy.isfinite(result)",
> -scipy.inf, result)
>
> with the necessary magic to pull out variables from the stack frame. Parsing
> could be done
> Giovanni Bajo wrote:
>> Another workaround could be:
Before focusing mental talents on workarounds and implementations,
it would be worthwhile to consider whether the idea would help or
hurt the language. The and/or keywords already have some complexity
due to their returning non-boolean values
On 5/19/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Giovanni Bajo wrote:
> >> Another workaround could be:
>
> Before focusing mental talents on workarounds and implementations,
> it would be worthwhile to consider whether the idea would help or
> hurt the language. The and/or keywords al
Raymond Hettinger wrote:
>> Giovanni Bajo wrote:
>>> Another workaround could be:
>
> Before focusing mental talents on workarounds and implementations,
> it would be worthwhile to consider whether the idea would help or
> hurt the language. The and/or keywords already have some complexity
> due
Raymond Hettinger wrote:
> Someone once proposed overloadable behavior for the "is" operator.
> IMO, the reasons for rejecting that idea also apply to this proposal.
The reason for rejecting that is that it would leave us
with no way of reliably testing whether two references
point to the same obj
Raymond Hettinger wrote:
> FWIW, the peephole optimizer takes advantage of the current meaning
> of and/or to generate faster code.
Can you give some examples of the sort of optimisations
that are done? It may still be possible to do them --
the AND1 and OR1 bytecodes in my proposal are condition
Bob Ippolito wrote:
> Would "and" and "or" still be able to properly short-circuit given
> this proposal?
Yes. I was very careful to ensure that all the existing semantics
are preserved in the case of no overloads, and also that overloads
can mimic all of the existing semantics if they need to.
From: "Andrew Koenig" <[EMAIL PROTECTED]>
> (I'm feeling slightly pedantic today, so I want to say that the proposal
> doesn't make it any easier to identify modules that engage in I/O -- it
> makes it easier to identify modules that assuredly do not engage in I/O.
u = urllib.urlopen('http://www.p
On 5/19/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
> > FWIW, the peephole optimizer takes advantage of the current meaning
> > of and/or to generate faster code.
>
> Can you give some examples of the sort of optimisations
> that are done?
Look in Python/peephole.c, functi
Jason Orendorff wrote:
> Look in Python/peephole.c,
Which version of Python is this in? I can't find a file by
that name anywhere in my 2.3, 2.4.3 or 2.5 sources.
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman
On 5/19/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
> > Look in Python/peephole.c,
>
> Which version of Python is this in? I can't find a file by
> that name anywhere in my 2.3, 2.4.3 or 2.5 sources.
http://svn.python.org/view/python/trunk/Python/peephole.c?rev=54086&view=ma
Phillip J. Eby wrote:
> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>> Determining the class object to use
>> '''
>>
>> The exact mechanism for associating the method with the defining
>> class is not
>> specified in this PEP, and should be chosen for maximum per
Tim Delaney wrote:
> Phillip J. Eby wrote:
>> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>>> Determining the class object to use
>>> '''
>>>
>>> The exact mechanism for associating the method with the defining
>>> class is not
>>> specified in this PEP, and shou
18 matches
Mail list logo
