If you're trying to write tests, perhaps a better use-case would be
something like:
with required_exception(SomeError):
do something that should cause SomeError
Yes, you are right, that'd be a better and more flexible way,
thank you.
Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/
Keith Dart wrote:
I guess I just clarify this more. My unsigned type really is an object
that represents a type of number from the external system. Previously,
there was a nice, clean mapping between external types and Python types.
Now there is not so clean a mapping. Not that that makes it a
On 6/20/05, Keith Dart [EMAIL PROTECTED] wrote:
On Mon, 20 Jun 2005, Guido van Rossum wrote:
[...]
By far the easiest way to do arithmetic mod 2**32 is to just add
0x to the end of your expression. For example, simulating the
effect of multiplying an unsigned long by 3 would be x =
On 6/20/05, Keith Dart [EMAIL PROTECTED] wrote:
However, since it is sometimes necessary to interface to other systems
with Python, I see no reason why Python should not have a full set of
built in numeric types corresponding to the machine types and, in turn,
other system types. Then it would
Dmitry Dvoinikov writes:
The reason for that being self-tests with lots and lots of
little code snippets like this:
try:
c().foo()
except TypeError:
pass
Paul Du Boise already responded explaining that PEP 343 probably handles
the task you want. I just wanted to mention that you
I suspect that you wanted either:
try:
c().foo()
fail('Should have raised TypeError')
except TypeError:
pass # expected
Right, of course I use something along these lines:
try:
c().foo()
except TypeError:
pass
else:
assert False, c.foo() should have
Guido van Rossum wrote:
[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
Keith Dart wrote:
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,
[Raymond]
The above recommendations should get the PEP ready for judgement
day.
[David Eppstein]
I thought judgement day already happened for this PEP in the Parade
of
PEPs. No?
The parade's text said the main gripe was having the index in the
middle, rather than right after the keyword.
On Tue, 21 Jun 2005, Guido van Rossum wrote:
[two messages mixed]
Huh? C unsigned ints don't flag overflow either -- they perform
perfect arithmetic mod 2**32.
I was talking about signed ints. Sorry about the confusion. Other
scripting languages (e.g. perl) do not error on overflow.
In my
It was possible in PEP 340 and in early drafts of PEP 346, but it
isn't possible in PEP 343.
In PEP 343, the statement template *cannot* suppress exceptions - it
can react to them, and it can turn them into different exceptions, but
that's all.
...doing homework...
The following code,
Patch / Bug Summary
___
Patches : 338 open ( +0) / 2866 closed ( +5) / 3204 total ( +5)
Bugs: 914 open ( +5) / 5060 closed (+13) / 5974 total (+18)
RFE : 188 open ( +0) / 170 closed ( +0) / 358 total ( +0)
New / Reopened Patches
__
update
Nick Coghlan wrote:
Guido van Rossum wrote:
But as long as we are describing the
present state we should call a spade a spade, etc.
I guess I take a syntactic view of the status quo, because, while
lambdas may be implemented as anonymous functions, the current syntax
doesn't let me
13 matches
Mail list logo
