On Sun, 05 Feb 2006 18:47:13 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] (Bengt Richter) wrote:
>> Are you just lecturing me personally (in which case off list would be more
>> appropriate),
>> or do you include the authors of the 17 files I count under > prefix>/Lib tha
On Sun, 5 Feb 2006 18:08:58 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 2/5/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>> On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>> >1. If your Python code distinguishes between ints and longs, it has a
>> >bug.
>>
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.
Per
| making the implied return statment visible might also be a good idea,
| e.g.
|
|lambda x, y: return x + y
|
| or even
|
|def (x, y): return x + y
|
Although I don't understand the implications of making such a change, the 2nd
alternative above looks very nice. Whenever I write a la
[EMAIL PROTECTED] (Bengt Richter) wrote:
> Are you just lecturing me personally (in which case off list would be more
> appropriate),
> or do you include the authors of the 17 files I count under /Lib
> that have
> isinstance(, int) in them?
> Or would you like to rephrase that with suitable qua
On 2/5/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >1. If your Python code distinguishes between ints and longs, it has a
> >bug.
> Are you just lecturing me personally (in which case off list would be more
> approp
On 5 feb 2006, at 18:43, 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
On Sun, 05 Feb 2006 18:45:52 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
[...]
>Psst, Nick, how about
>(x*y for x,y in ()) ? # "()" as mnemonic for call args
D'oh, sorry, that should have been illegal syntax, e.g.,
(x*y for x,y in *) ? # "*" as mnemonic for call *args
so
(x*y for x
You don't have to keep writing notes to python-dev on this patch.
It is assigned to me and when I get a chance to go through it in detail,
it has a good likelihood of going in (if no issues arise).
Raymond
- Original Message -
From: "Crutcher Dunnavant" <[EMAIL PROTECTED]>
To: "Martin v.
I've significantly re-worked the patch to permit globals to be
arbitrary mappings.
The regression tests continue to all pass.
http://sourceforge.net/tracker/index.php?func=detail&aid=1402289&group_id=5470&atid=305470
On 1/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Crutcher Dunnavant w
[Crutcher Dunnavant[
> Which reminds me, we need to support roman numeral constants.
One of my more-normal relatives reminded me that this is Super Bowl XL
Sunday, so your demand is more topical than it would ordinarily be.
Alas, there's already a PEP on this, and it was already rejected. See
PE
Which reminds me, we need to support roman numeral constants.
A silly implementation follows.
class RomanNumeralDict(dict):
def __getitem__(self, key):
if not self.has_key(key) and self.isRN(key):
return self.decodeRN(key)
return dict.__getitem__(self, key)
def isRN(self, key):
[Guido]
> 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.
Huh! Was someone b
+1
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 an
+1 on retaining lambda
-1 on any name change
On Sun, 5 Feb 2006, Paul Moore wrote:
> 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 rece
> 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 -- trying to cover all t
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
On Sun, 5 Feb 2006 13:48:51 -0500, "Raymond Hettinger" <[EMAIL PROTECTED]>
wrote:
[...]
>
[...]
>A language suitable for beginners should be easy to learn, but it should not
>leave them permanently crippled. All of the above are sets of training
>wheels
>that don't come off. To misquote Einstei
On Sunday 05 February 2006 12:43, 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
On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] (Bengt Richter) wrote:
>> Martin v. Lowis <[EMAIL PROTECTED]> wrote:
>> >Bengt Richter wrote:
>> >>>The typical way of processing incoming ints in C is through
>> >>>PyArg_ParseTuple, which already h
On Feb 5, 2006, at 11:31 AM, Raymond Hettinger wrote:
> [Bob Ipppolito]
>> For those of us that already know what we're doing with floating
>> point, areclose would be very convenient to have.
>
> Do you agree that the original proposed use (helping newbs ignore
> floating
> point realities)
[Bob Ipppolito]
> For those of us that already know what we're doing with floating
> point, areclose would be very convenient to have.
Do you agree that the original proposed use (helping newbs ignore floating
point realities) is misguided and error-prone?
Just curious, for your needs, do you w
On Feb 5, 2006, at 10:48 AM, Raymond Hettinger wrote:
>>> So I was wondering if module math (and
>>> perhaps by symmetry module cmath, too) shouldn't grow a function
>>> 'areclose' (calling it just 'close' seems likely to engender
>>> confusion, since 'close' is more often used as a verb than as
Terry Reedy wrote:
> If 3.0 comes with a conversion program, then I would like to see 'lambda'
> replaced with either 'def' or another abbreviation like 'edef' (expression
> def) or 'func'.
making the implied return statment visible might also be a good idea, e.g.
lambda x, y: return x + y
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
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.
>
>--
>
Georg Brandl wrote:
> Alex Martelli wrote:
>>So I was wondering if module math (and perhaps by symmetry module cmath,
>> too) shouldn't grow a function 'areclose' ...maybe ... 'almost_equal')
>> def areclose(x, y, rtol=1.e-5, atol=1.e-8):
>> return abs(x-y)
> atol sounds suspicious to me, bu
>>So I was wondering if module math (and
>> perhaps by symmetry module cmath, too) shouldn't grow a function
>> 'areclose' (calling it just 'close' seems likely to engender
>> confusion, since 'close' is more often used as a verb than as an
>> adjective; maybe some other name would work better, e.g
On Sat, 4 Feb 2006 20:17:15 +0100, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>>> I believe that usage of a keyword with the name of a Greek letter also
>>> contributes to people considering something broken.
>>
>> Aye, I agree there are serious problems with the current syntax
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I guess I misstated myself slightly - I've previously advocated re-using
> the
> 'def' keyword, so there are obviously parallels I want to emphasize.
If 3.0 comes with a conversion program, then I would like to see 'la
Alex Martelli wrote:
> When teaching some programming to total newbies, a common frustration
> is how to explain why a==b is False when a and b are floats computed
> by different routes which ``should'' give the same results (if
> arithmetic had infinite precision). Decimals can help, but an
On Sun, Feb 05, 2006, Alex Martelli wrote:
>
> But pulling in the whole of Numeric just to have that one handy
> function is often overkill. So I was wondering if module math (and
> perhaps by symmetry module cmath, too) shouldn't grow a function
> 'areclose' (calling it just 'close' seems l
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.
--
--Guido van Rossum (home page: h
[EMAIL PROTECTED] (Bengt Richter) wrote:
> Martin v. Lowis <[EMAIL PROTECTED]> wrote:
> >Bengt Richter wrote:
> >>>The typical way of processing incoming ints in C is through
> >>>PyArg_ParseTuple, which already has the code to coerce long->int
> >>>(which in turn may raise an exception for a rang
When teaching some programming to total newbies, a common frustration
is how to explain why a==b is False when a and b are floats computed
by different routes which ``should'' give the same results (if
arithmetic had infinite precision). Decimals can help, but another
approach I've found u
Giovanni Bajo wrote:
>>ctime should be provided to report whatever ctime used to report in
>>the past (i.e. creation_time on Windows, status_change_time on Unix).
>
>
> In other words, if there are mistakes in the old API, this is the time to
> fix them. Why should we carry them over to a new API
On Sat, 04 Feb 2006 11:11:08 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>>>The typical way of processing incoming ints in C is through
>>>PyArg_ParseTuple, which already has the code to coerce long->int
>>>(which in turn may raise an excepti
On Sun, February 5, 2006 13:57, "Martin v. Löwis" wrote:
> I think the path module should provide these under a different name:
> creation_time and status_change_time. Either of these might be absent.
+1. This is exactly what I proposed, in fact.
> ctime should be provided to report whatever ct
Hye-Shik Chang wrote:
> Thomas and I collaborated on integration into the ctypes repository
> and testing on various platforms yesterday. My patches for Python
> are derived from ctypes CVS with a change of only one line.
Not sure whether you think you need further approval: if you are ready
to c
Nick Coghlan wrote:
> I guess my point is that expressions are appropriate sometimes, functions are
> appropriate other times, and it *is* possible to give reasonably simple
> guidelines as to which one is most appropriate when (one consumer->deferred
> expression, multiple consumers->named func
Terry Reedy wrote:
>>Note that this is the opposite of normal Python policy: Python does not
>>attempt to create cross-platform abstractions, but instead chooses to
>>expose platform differences.
>
>
> I had the opposite impression about Python -- that it generally masks such
> differences.
I t
Phillip J. Eby wrote:
>>- ctime() is documented to be unportable: it has different semantics on UNIX
>>and Windows. I believe the class should abstract from these details.
>
>
> Note that this is the opposite of normal Python policy: Python does not
> attempt to create cross-platform abstraction
Nick Coghlan <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Duncan Booth wrote:
>> I'm not convinced by the rationale given why atime,ctime,mtime and
>> size are methods rather than properties but I do find this PEP much
>> more agreeable than the last time I looked at it.
>
> A better r
43 matches
Mail list logo
