[Nick Coghlan]
And here we see why I'm such a fan of the term 'deferred expression'
instead of 'anonymous function'.
Python's lambda expressions *are* the former, but they are
emphatically *not* the latter.
Let me emphatically disagree. Your POV is entirely syntactical, which
IMO is a
[Keith Dart]
In SNMP, for example, a Counter32 is basically an unsigned int, defined
as IMPLICIT INTEGER (0..4294967295). One cannot efficiently translate
and use that type in native Python. Currently, I have defined an
unsigned type as a subclass of long, but I don't think that would be
Gerrit Holl writes:
What would happen if...
Raymond replies:
Every molecule in your body would simultaneously implode at the speed of
light.
So you're saying it triggers C-language undefined behavior?
-- Michael Chermside
___
Python-Dev mailing
Michael Hudson [EMAIL PROTECTED] writes:
I'm not expecting anyone else to think hard about this on recent form,
so I'll think about it for a bit and then fix it in the way that seems
best after that. Feel free to surprise me.
And so that's what I did. I think I got this right, but threads
lambda x,y: x+y*y
lambda x,y: y**2+x
are essentialy the same functions with different implementations [1].
Except that they are not. Think of __pow__, think of __add__ and __radd__.
You know the difference between the concept of a function and it's
On Mon, 20 Jun 2005, Guido van Rossum wrote:
[Keith Dart]
In SNMP, for example, a Counter32 is basically an unsigned int, defined
as IMPLICIT INTEGER (0..4294967295). One cannot efficiently translate
and use that type in native Python. Currently, I have defined an
unsigned type as a subclass
On Mon, 20 Jun 2005, Keith Dart wrote:
But then I wouldn't know if it overflowed 32 bits. In my usage, the
integer will be translated to an unsigned (32 bit) integer in another
system (SNMP). I want to know if it will fit, and I want to know early if
there will be a problem, rather than later
Excuse me if I couldn't find that in the existing PEPs, but
wouldn't that be useful to have a construct that explicitly
tells that we know an exception of specific type could happen
within a block, like:
--
ignore TypeError:
do stuff
[else:
do other stuff]
On 6/20/05, Dmitry Dvoinikov [EMAIL PROTECTED] wrote:
Excuse me if I couldn't find that in the existing PEPs, but
wouldn't that be useful to have a construct that explicitly
tells that we know an exception of specific type could happen
within a block, like:
ignore TypeError:
do stuff
