On Jan 26, 2008 12:06 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > b) automate all aspects of adding modules that should not go
> > into pythonxy.dll according to the policy."
> >
> >
> > i.e. create visual studio project files for those modules? and make them
> > built automatical
Guido van Rossum wrote:
> I note that at least for built-in types there will be the naming
> convention that concrete implementation classes are all lowercase,
> like int, float, list, namedtuple, defaultdict, and so on, while the
> ABCs all have a Capitalized[Words] name: Hashable, Number, Real,
>
Neal Norwitz wrote:
> I'm not sure we should expose an API to clear the cache, but I don't
> have strong opinions either way. If we keep the ability to clear the
> cache, should we also consider some control over the int/float
> freelist? These are worse than the tuple/frame free lists since
> in
Brett Cannon wrote:
> Ignoring whether this is the right thing to do, should this be in sys or in
> gc?
Yeah, good idea. The gc module makes sense.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
On Jan 27, 8:27 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Along with the release of 2.5.2, I would also like to release
> new versions of 2.3 and 2.4. These will be security-only releases,
> and include a few security-relevant bug fixes that are still being
> finalized.
>
> As we don't hav
On Jan 27, 2008 3:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > Expose an API to clear the cache, and clear it at shutdown? It
> > should probably be part of interpreter shutdown anyway.
>
> Good point. I've implemented PyType_ClearCache and exposed it via
> sys._c
On Jan 27, 2008 3:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > Expose an API to clear the cache, and clear it at shutdown? It
> > should probably be part of interpreter shutdown anyway.
>
> Good point. I've implemented PyType_ClearCache and exposed it via
> sys._c
"Michael Urman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| 2) The semantics of int() are fuzzy; even non-numeric types
| (strings) are handled
One could just as well say that the semantics of float() are fuzzy since it
also handles strings.
The actual claim seems to have b
Phillip J. Eby wrote:
> Expose an API to clear the cache, and clear it at shutdown? It
> should probably be part of interpreter shutdown anyway.
Good point. I've implemented PyType_ClearCache and exposed it via
sys._cleartypecache(). The function is called during finalization, too.
Can somebody
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote:
> This is why len() is not a method:
>
> map(len, list_of_strings)
I disagree with that explanation -- I couldn't know that when I made
len() a function, because map() wasn't to become part of the language
for another 5-6 years.
My exp
On Jan 27, 2008 11:54 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > If I'm following this discussion properly, the advantage of trunc() is
> > that a Real-class-that-isn't-float can define a __trunc__ that can
> > return an Integer-class-that-isn't-int, right?
>
> Depends on what you compare
On Jan 27, 2008 12:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> >> > - trunc(), round(), floor() and ceil() should all be built-ins,
> >> > corresponding to __trunc__, __round__, __floor__ and __ceil__.
>
> In Py2.6, what will the signatures be?
> Last I heard, ceil() and floor() w
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 27, 2008, "Martin v. L?wis" wrote:
> >
> > Students just asked me why len() is not a method, and I didn't know a
> > good answer; the same holds for many other builtins. This is a clear
> > candidate for a method, IMO.
>
> This
On Sun, Jan 27, 2008, "Martin v. L?wis" wrote:
>
> Students just asked me why len() is not a method, and I didn't know a
> good answer; the same holds for many other builtins. This is a clear
> candidate for a method, IMO.
This is why len() is not a method:
map(len, list_of_strings)
What I d
[GvR]
>> > - trunc(), round(), floor() and ceil() should all be built-ins,
>> > corresponding to __trunc__, __round__, __floor__ and __ceil__.
In Py2.6, what will the signatures be?
Last I heard, ceil() and floor() were still going to be float-->float.
Raymond
___
At 05:05 PM 1/26/2008 -0800, Neal Norwitz wrote:
>Around Jan 13, the refleak hunting test that is reported on
>python-checkins started to report refleaks on virtually every run. I
>suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from
>patch #1700288 to cache methods. With this pa
> If I'm following this discussion properly, the advantage of trunc() is
> that a Real-class-that-isn't-float can define a __trunc__ that can
> return an Integer-class-that-isn't-int, right?
Depends on what you compare to. Compared to int(), the advantage is
that trunc() sends a clear message what
Along with the release of 2.5.2, I would also like to release
new versions of 2.3 and 2.4. These will be security-only releases,
and include a few security-relevant bug fixes that are still being
finalized.
As we don't have the infrastructure to produce full releases of 2.3
or 2.4 anymore, this wi
Guido van Rossum wrote:
> On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote:
>> Anyway I want just to say that if "implicit" conversion from float
>> to integer goes away then what happens to formatting conversion ?
>> Removing that too IMO would break a lot of code and it's IMO ve
On Jan 27, 2008 10:43 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - trunc(), round(), floor() and ceil() should all be built-ins,
> corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we
> have the four standard ways to go from Reals to Integers, which are
> properly extensibl
On Jan 27, 2008 10:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Then int() can be defined by deferring to trunc()
> > -- as opposed to round().
>
> That part is new and represents some progress. If I understand it
> correctly, it means that we won't have both __int__ and __trunc__
> mag
It is my pleasure to announce that I have been appointed as the release
manager for the upcoming releases. For 2.5.2, I would like to release
a candidate on February 14, and the final version on February 21. As
Guido already mentioned, this will be a bug fix release only; no new
features allowed.
On Jan 27, 2008 10:39 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> Is this a valid summary of the arguments so far?
>
> I see two arguments for the change:
>
> 1) The semantics of trunc() are clear: it maps R -> Z in a specific fashion
> 2) The semantics of int() are fuzzy; even non-numeric t
> Then int() can be defined by deferring to trunc()
> -- as opposed to round().
That part is new and represents some progress. If I understand it
correctly, it means that we won't have both __int__ and __trunc__
magic methods. That's a good thing.
Raymond
__
On Jan 27, 2008 10:29 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [Guido]
> >> There is actually quite an important signal to the reader that is
> >> present when you see trunc(x) but absent when you see int(x): with
> >> trunc(x), the implication is that x is a (Real) number. With int(x),
Is this a valid summary of the arguments so far?
I see two arguments for the change:
1) The semantics of trunc() are clear: it maps R -> Z in a specific fashion
2) The semantics of int() are fuzzy; even non-numeric types
(strings) are handled
Yet there will be a __trunc__ that will allow any
On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > - Deprecating int() is pretty radical, I think it would have to
> > happen in the distant future. OR not at all. I'm at best +0 on this,
> > more like exa
> [Guido]
>> There is actually quite an important signal to the reader that is
>> present when you see trunc(x) but absent when you see int(x): with
>> trunc(x), the implication is that x is a (Real) number. With int(x),
>> you can make no such assumption -- x could be a string, or it could be
>> a
On Jan 27, 2008 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > - Deprecating int() is pretty radical, I think it would have to
> > happen in the distant future. OR not at all. I'm at best +0 on this,
> > more like exa
[Raymond Hettinger]
>> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but
>> it doesn't match any experience I've had with any
>> programmer, ever.
[Christian Heimes]
> You haven't been doing newbie support in #python lately. Statements like
> Python is rounding wrong ar
On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Deprecating int() is pretty radical, I think it would have to
> happen in the distant future. OR not at all. I'm at best +0 on this,
> more like exactly 0. I realize that in practice this kills the idea.
> The "purist" argume
On Jan 27, 2008 12:29 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> This will be a bikeshed argument until Guido speaks out his
> preference/decision I guess.
>
> But isn't it a more common solution to name the base class just Number and
> derive from it by means of using Base.Numb
On Jan 26, 2008 11:14 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >. You may disagree, but that doesn't make it nuts.
>
> Too many thoughts compressed into one adjective ;-)
[snip]
> > I don't think that Excel should be held up as a shining example for
> > Python.
>
> It is simply a datapoi
Raymond Hettinger wrote:
> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but
> it doesn't match any experience I've had with any
> programmer, ever.
You haven't been doing newbie support in #python lately. Statements like
Python is rounding wrong are common. ;) It's ast
-On [20080127 03:25], Terry Reedy ([EMAIL PROTECTED]) wrote:
>I *think* I would prefer to any of these either
>ANumber or
>aNumber,
>which one can read as either an abbreviation of Abstract Number or simply a
>contraction of 'a Number' (a Real, an Integral, etc) taken
On Jan 26, 2008 11:14 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but
> it doesn't match any experience I've had with any
> programmer, ever.
In C, I'm pretty sure I've seen people write (long)x where they'd have
been
36 matches
Mail list logo
