Re: [Python-Dev] Explicitly declaring expected exceptions for a block
> 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/ --- Original message follows --- > 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 >> [else: >> do other stuff] > If I understand PEP 343 correctly, it allows for easy implementation > of part of your request. It doesn't implement the else: clause, but > you don't give a use case for it either. > class ignored_exceptions(object): > def __init__(self, *exceptions): > self.exceptions = exceptions > def __enter__(self): > return None > def __exit__(self, type, value, traceback): > try: > raise type, value, traceback > except self.exceptions: > pass > with ignored_exceptions(SomeError): > do stuff > I don't see the use, but it's possible. >> The reason for that being self-tests with lots and lots of >> little code snippets like this: > 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 > paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicitly declaring expected exceptions for a block
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 > [else: > do other stuff] If I understand PEP 343 correctly, it allows for easy implementation of part of your request. It doesn't implement the else: clause, but you don't give a use case for it either. class ignored_exceptions(object): def __init__(self, *exceptions): self.exceptions = exceptions def __enter__(self): return None def __exit__(self, type, value, traceback): try: raise type, value, traceback except self.exceptions: pass with ignored_exceptions(SomeError): do stuff I don't see the use, but it's possible. > The reason for that being self-tests with lots and lots of > little code snippets like this: 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 paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Explicitly declaring expected exceptions for a block
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] being essintially identical to try: do stuff except TypeError: pass [else: do other stuff] -- The reason for that being self-tests with lots and lots of little code snippets like this: try: c().foo() except TypeError: pass which could be written as ignore TypeError: c().foo() Sincerely, Dmitry Dvoinikov http://www.targeted.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
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 (at conversion time). > > class unsigned(long): 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 problem with Python itself. 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 be easier (and probaby a bit faster) to interface to them. Perhaps Python could have an "integer" type for long/int unified types, and just "int" type as "normal" integers? -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
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 of long, but I don't think that would be >> speed or storage efficient. > > In my experience you can just use Python longs whenever a C API needs > an "unsigned" long. There's no need to subtype, and your assumption > that it would not be efficient enough is mistaken (unless you are > manipulating arrays with millions of them, in which case you should be > using Numeric, which has its own types for this purpose). (Want to > argue about the efficiency? Write a typical use case and time it.) Ok, I'll take your word for it. I don't have any performance problems now, in my usage, but I wanted to make sure that Python "shows well" in certain "bake offs" ;-) > 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 = (x * 3) & > 0x. 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 (at conversion time). One of the "selling points" of Python in previous versions was that you would get an OverFlowError on overflow, where other languages did not (they overflowed silently). So I subclassed long in 2.3, to get the same overflow exception: class unsigned(long): floor = 0L ceiling = 4294967295L bits = 32 _mask = 0xL def __new__(cls, val): return long.__new__(cls, val) def __init__(self, val): if val < self.floor or val > self.ceiling: raise OverflowError, "value %s out of range for type %s" % (val, self.__class__.__name__) def __repr__(self): return "%s(%sL)" % (self.__class__.__name__, self) def __add__(self, other): return self.__class__(long.__add__(self, other)) ... Again, because I want to catch the error early, before conversion to the external type. BTW, the conversion is done in pure Python (to a BER representation), so using a C type (via ctypes, or pyrex, or whatever) is not possible. > If there is a problem with ioctl() not taking long ints, that would be > a bug in ioctl, not a lacking data type or a problem with long ints. That must be it, then. Shall I file a bug somewhere? -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
>>>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 > infinitely many representations? That's why formal definitions exist. To clear up the archives, the problem is that Kay and Reinhold were talking about different things when they said "function". In arithmetic (and most sane extensions), those two lines are essentially the same function written different ways. In python those two lines represent two different functions, because x and y might not be (bound to) sane numbers. The variables could be bound to objects that redefine the addition, multiplication, and exponentiation operators. So y*y might not be the same as y**2, and x+y might not be the same as y+x. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple interpreters not compatible with current thread module
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 are tricky buggers so x-platform testing of CVS HEAD would be appreciated (heck, that would be appreciated anyway, I don't get the impression much of it is happening at the moment...). Cheers, mwh -- glyph: I don't know anything about reality. -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiple expression eval in compound if statement?
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 list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
[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 > speed or storage efficient. In my experience you can just use Python longs whenever a C API needs an "unsigned" long. There's no need to subtype, and your assumption that it would not be efficient enough is mistaken (unless you are manipulating arrays with millions of them, in which case you should be using Numeric, which has its own types for this purpose). (Want to argue about the efficiency? Write a typical use case and time it.) 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 = (x * 3) & 0x. If there is a problem with ioctl() not taking long ints, that would be a bug in ioctl, not a lacking data type or a problem with long ints. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
[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 shallow perspective. Semantically, lambdas ARE anonymous functions, and that's what counts. Since "deferred expression" is not defined in Python, you can't reasonably argue about whether that's what lambdas are, but intuitively for me the term refers to something more lightweight than lambdas. Now, whether the use cases for lambdas are better served by anonymous functions or by something else that might be called deferred expression, I don't know yet. But as long as we are describing the present state we should call a spade a spade, etc. (Alas, no time to follow the rest of this thread -- vacationing with little connectivity until EuroPython starts next week.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
