On 22-Jun-07, at 2:44 PM, Jean-Paul Calderone wrote:
> On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli
> <[EMAIL PROTECTED]> wrote:
>
> Could be. I don't find many of my programs to be bottlenecked on
> compilation time or import time, so these optimizations look like
> pure lose to me.
Nor
On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
>On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> ...
>>This is more reasonable, but it's still a new rule (and I personally
>>find rules which include undefined behavior to be distasteful -- but
>>your sugge
On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
...
> This is more reasonable, but it's still a new rule (and I personally
> find rules which include undefined behavior to be distasteful -- but
> your suggestion could be modified so that the name change is never
> respected to achieve
On Fri, 22 Jun 2007 14:06:07 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
>On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> ...
>> >> Calling abs() could change locals()['abs'], in which case a different
>> >> function would be called the next time through. You lookup 'abs' each
>
On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
...
> >> Calling abs() could change locals()['abs'], in which case a different
> >> function would be called the next time through. You lookup 'abs' each
> >> time just in case it's changed.
> >>
> >
> >I can't think of a reason to allo
On Fri, 22 Jun 2007 14:13:39 -0600, Neil Toronto <[EMAIL PROTECTED]> wrote:
>Andrew McNabb wrote:
>> On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote:
>>
(imap is faster in this case because the built-in name 'abs' is looked
up only once -- in the genexp, it's looked up each t
Andrew McNabb wrote:
> On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote:
>
>>> (imap is faster in this case because the built-in name 'abs' is looked
>>> up only once -- in the genexp, it's looked up each time, sigh --
>>> possibly the biggest "we should REALLY tweak the language to
On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote:
> > (imap is faster in this case because the built-in name 'abs' is looked
> > up only once -- in the genexp, it's looked up each time, sigh --
> > possibly the biggest "we should REALLY tweak the language to let this
> > be optimized se
Alex Martelli wrote:
> $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x
> in it.imap(abs,L): pass'
> 10 loops, best of 3: 3 usec per loop
> $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x
> in (abs(y) for y in L): pass'
> 10 loops, best of 3: 4.4
Guido writes:
> On 6/22/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > A given codec won't randomly decide to change its normalisation policy,
> > > though - so when you pick the codec, you're picking the normalisation as
> > > well.
> >
> > You're sure? Between CPython and Jython and IronPytho
On 6/22/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > A given codec won't randomly decide to change its normalisation policy,
> > though - so when you pick the codec, you're picking the normalisation as
> > well.
>
> You're sure? Between CPython and Jython and IronPython and
> JavascriptPython a
> A given codec won't randomly decide to change its normalisation policy,
> though - so when you pick the codec, you're picking the normalisation as
> well.
You're sure? Between CPython and Jython and IronPython and
JavascriptPython and ...? Might as well specify it up front.
Bill
___
> > > In practice, binary concerns do intrude even for text data; you may
> > > well want to save it back out in the original encoding, without any
> > > spurious changes.
>
> Then for the purposes of this discussion, it's not text, it's binary.
> In many cases it will need to be read as bytes
On 6/21/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
[Guido]
> > Have we agreed on the level of
> > normalization for source code yet? I'm pretty sure we have agreed on
> > *when* it happens, i.e. (logically) before the lexer starts scanning
> > the source code.
>
> That isn't actually my view:
Guido van Rossum writes:
> > If I ask for just one character, do I get only the o, without the
> > diaeresis, or do I get both (since they are linguistically one
> > letter), or does it depend on how some editor happened to store it?
>
> It should get you the next code unit as it comes out o
Daniel Stutzbach wrote:
> If the cookie is meant to be opaque to the caller, is there a reason
> that the cookie must be an integer?
>
> Specifying the return type as opaque might also reduce the temptation
> to do perform arithmetic on them, which will work for some codecs
> (ASCII), but brea
Bill Janssen wrote:
>> I'm not sure I 100% understand what you mean by "normalization policy"
>> (Q). Could you give an example?
>
> I was speaking of the 4 different normalization forms for Unicode,
> which can produce different code-point sequences. Since "strings" in
> Python-3000 aren't real
--- Greg Ewing <[EMAIL PROTECTED]> wrote:
> The word "add" has a wider connotation in English
> than
> "sum". [...]
Just to elaborate on the point...
And, likewise, symbolic operators have a wider
connotation in programming languages than do keywords.
Keywords can, and should, be more specifica
On Fri, Jun 22, 2007 at 07:11:14PM +1000, Nick Coghlan wrote:
> Bill Janssen wrote:
> >>> It should amount to "map(+, operands)".
> >> Or, to be pedantic, this:
> >>
> >> reduce(lambda x, y: x.__add__(y), operands)
> >
> > Don't you mean:
> >
> >reduce(lambda x, y: x.__add__(y), operand
Bill Janssen wrote:
>>> It should amount to "map(+, operands)".
>> Or, to be pedantic, this:
>>
>> reduce(lambda x, y: x.__add__(y), operands)
>
> Don't you mean:
>
>reduce(lambda x, y: x.__add__(y), operands[1:], operands[0])
This is a nice illustration of a fairly significant issue w
20 matches
Mail list logo
