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] Is PEP 237 final -- Unifying Long Integers and Integers
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 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?
For your purposes, would it work to use the struct module to detect
overflows early?
import struct
struct.pack('i', 2 ** 33)
Traceback (most recent call last):
File stdin, line 1, in ?
OverflowError: long int too large to convert to int
Another possibility would be to add to the struct module a full set of
integer types with a fixed width: int8, uint8, int16, uint16, int32,
uint32, int64, and uint64. Code that's focused on integration with
other languages might benefit.
Shane
___
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 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 = (x * 3) 0x. But then I wouldn't know if it overflowed 32 bits. Huh? C unsigned ints don't flag overflow either -- they perform perfect arithmetic mod 2**32. 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). So check if it is = 2**32 (or 0, of course). 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: ... Again, because I want to catch the error early, before conversion to the external type. This is a very specialized application. Your best approach is to check for overflow before passing into the external API -- ideally the wrappers for that API should do so. 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? SourceForge. (python.org/dev for more info) -- --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] Is PEP 237 final -- Unifying Long Integers and Integers
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 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? Strongly disagree. (a) Stop worrying about speed. The overhead of a single Python bytecode execution is probably more than the cost of an integer operation in most cases. (b) I don't know what you call a normal integer any more; to me, unified long/int is as normal as they come. Trust me, that's the case for most users. Worrying about 32 bits becomes less and less normal. (c) The right place to do the overflow checks is in the API wrappers, not in the integer types. -- --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] Explicitly declaring expected exceptions for ablock
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 may need to
reconsider the task. The above snippet is almost certainly incorrect.
I suspect that you wanted either:
try:
c().foo()
fail('Should have raised TypeError')
except TypeError:
pass # expected
or perhaps this:
try:
c().foo()
except TypeError:
fail('Should not have raised TypeError')
There ARE situations when you want to allow an exception (but not
necessarily expect it) and do nothing when it occurs, but I don't
find them all that common, and I certainly don't find them arising
in unit tests.
-- 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] Explicitly declaring expected exceptions for ablock
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 thrown TypeError
and so if foo throws anything but TypeError I get traceback,
otherwise it's an assertion error and is reported as such.
This is probably just one of the many possible wording of the
same thing though.
Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/
--- Original message follows ---
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 may need to
reconsider the task. The above snippet is almost certainly incorrect.
I suspect that you wanted either:
try:
c().foo()
fail('Should have raised TypeError')
except TypeError:
pass # expected
or perhaps this:
try:
c().foo()
except TypeError:
fail('Should not have raised TypeError')
There ARE situations when you want to allow an exception (but not
necessarily expect it) and do nothing when it occurs, but I don't
find them all that common, and I certainly don't find them arising
in unit tests.
-- 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
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 syntactical, which IMO is a shallow perspective. Semantically, lambdas ARE anonymous functions, and that's what counts. Interesting. Knowing this, I think I better understand your desire to get rid of lambda expressions for Py3K. 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. As you say, it is a matter of looking at lambdas based on what the current syntax restricts them to (i.e. single expressions), rather than what the underlying machinery is capable of (i.e. full-fledged functions). 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. Like you (judging by your stated goals for Py3K), I don't have any use cases for full anonymous functions - named functions serve that role quite happily for me. Where I find lambda expressions useful is the role that Python's current syntax restricts them too - functions which consist of a single (usually simple) expression. For those, pulling the expression out and naming it would just end up hiding the meaningful sections of code behind a few pieces of boilerplate 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 *write* an arbitrary function as a lambda. Regardless, I believe the balance will eventually tip in some direction - either lambdas disappear entirely, become able support full anonymous functions, or else the idea of a 'deferred expression' becomes a defining characteristic, rather than a syntactic quirk. I figure it's all Py3K type stuff though, without any great urgency associated with it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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 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, 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? It seems to me, that maybe a single byte_buffer type, that can be defined to the exact needed byte lengths and have possible other characteristics to aid in interfacing to other languages or devices, would be a better choice. Then pythons ints, floats, etc... can uses what ever internal lengths is most efficient for the system it's compiled on and then the final result can be stored in the 'byte_buffer' for interfacing purposes. It would also be a good choice for bit manipulation when someone needs that, instead of trying to do it in an integer. Would something like that fulfill your need? Regards, Ron ___ 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] Propose updating PEP 284 -- Integer for-loops
[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. However, even after addressed the gripe, Guido still hated it. So, the PEP is now dead as a doornail. Raymond ___ 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 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 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). So check if it is = 2**32 (or 0, of course). That's exactly what I do. ;-) The unsigned subclass of long is part of the API, and checks the range when it is created (and they get created implicitly when operated on). (a) Stop worrying about speed. The overhead of a single Python bytecode execution is probably more than the cost of an integer operation in most cases. I am not thinking of the integer operation, but the extra Python bytecode necessary to implement the extra checks for overflow. Again, because I want to catch the error early, before conversion to the external type. This is a very specialized application. Your best approach is to check for overflow before passing into the external API -- ideally the wrappers for that API should do so. (c) The right place to do the overflow checks is in the API wrappers, not in the integer types. That would be the traditional method. I was trying to keep it an object-oriented API. What should know the overflow condition is the type object itself. It raises OverFlowError any time this occurs, for any operation, implicitly. I prefer to catch errors earlier, rather than later. (b) I don't know what you call a normal integer any more; to me, unified long/int is as normal as they come. Trust me, that's the case for most users. Worrying about 32 bits becomes less and less normal. By normal integer I mean the mathematical definition. Most Python users don't have to worry about 32 bits now, that is a good thing when you are dealing only with Python. However, if one has to interface to other systems that have definite types with limits, then one must hack around this feature. I was just thinking how nice it would be if Python had, in addition to unified (real, normal) integers it also had built-in types that could be more easily mapped to external types (the typical set of signed, unsigned, short, long, etc.).Yes, you can check it at conversion time, but that would mean extra Python bytecode. It seems you think this is a special case, but I think Python may be used as a glue language fairly often, and some of us would benefit from having those extra types as built-ins. -- -- ~ 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] Explicitly declaring expected exceptions for a block
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, combined from PEP 343 and Mr. Du Bois suggestion: -- from sys import exc_info 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 try: with = ignored_exceptions(TypeError) with.__enter__() try: try: raise TypeError() except: exc = exc_info() raise finally: with.__exit__(*exc) except: print exc_info() -- still yields exceptions.TypeError. Now, back to original question then, do you think it'd be beneficial to have some sort of exception ignoring or expecting statement ? Sincerely, Dmitry Dvoinikov http://www.targeted.org/ --- Original message follows --- Paul Du Bois wrote: 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. 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. And yes, this is deliberate - the control flow is too murky otherwise: with some_template(): raise TypeError print Hi! Does that code print Hi! or not? Under PEP 343, you know it doesn't, because the TypeError isn't trapped. If templates could actually suppress exceptions, you'd have no idea what the code does without looking up the definition of 'some_template' - this is a bad thing, which is why PEP 343 defines the semantics the way it does. However, I'm with Michael - every time I've needed something like this, I have had non-trivial code in either the 'except' or the 'else' blocks of the try statement. Regards, Nick. ___ 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] Weekly Python Patch/Bug Summary
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 the binhex module for Mach-O (2005-06-14) http://python.org/sf/1220874 opened by Bob Ippolito ftplib storbinary callback (2005-06-15) http://python.org/sf/1221598 opened by Phil Schwartz C++ compilation support for distutils (2005-06-17) http://python.org/sf/1222585 opened by Antti Honkela PEP 342/343 Generator enhancements (2005-06-18) http://python.org/sf/1223381 opened by Phillip J. Eby HP-UX ia64 64-bit Python executable (2005-06-21) http://python.org/sf/1225212 opened by Peter Kropf Patches Closed __ _csv.c leaks when dialect creation fails (2005-06-14) http://python.org/sf/1220242 closed by montanaro test_curses bugs (2004-08-09) http://python.org/sf/1005892 closed by akuchling no html file for modulefinder (2005-04-10) http://python.org/sf/1180012 closed by birkenfeld Restore GC support to set objects (2005-05-11) http://python.org/sf/1200018 closed by rhettinger change recall in IDLE shell to not overwrite current command (2005-05-06) http://python.org/sf/1196917 closed by kbk New / Reopened Bugs ___ buffer() object broken. (2005-06-15) CLOSED http://python.org/sf/1221424 opened by Ray Schumacher Incorrect documentation for InPlace Number operators (2005-06-15) CLOSED http://python.org/sf/1221477 opened by Daniel Stutzbach float() not accurate (2005-06-16) CLOSED http://python.org/sf/1222098 opened by Brian Dols Bad optparse help wrapping with multiple paragraphs (2005-06-16) http://python.org/sf/135 opened by Barry A. Warsaw Typo in section 5.3 of tutorial (2005-06-17) CLOSED http://python.org/sf/1222459 opened by uman tk + setlocale problems... (2005-06-17) http://python.org/sf/1222721 opened by Alex A. Naanou SimpleXMLRPCServer does not set FD_CLOEXEC (2005-06-17) http://python.org/sf/1222790 opened by Winfried Harbecke it's - its (2005-06-17) CLOSED http://python.org/sf/1222928 opened by Ed Swierk 2.4.1 .msi file won't install to different disk (2005-06-17) CLOSED http://python.org/sf/1222978 opened by Ray Trent race in os.makedirs() (2005-06-18) http://python.org/sf/1223238 opened by Mattias Engdegård subprocess.py abuse of errno (2005-06-20) http://python.org/sf/1223937 reopened by astrand subprocess.py abuse of errno (2005-06-20) http://python.org/sf/1223937 opened by Oren Tirosh error locale.getlocale() with LANGUAGE=eu_ES (2005-06-20) http://python.org/sf/1223976 opened by Zunbeltz Izaola Len too large with national characters (2005-06-20) CLOSED http://python.org/sf/1224047 opened by Henrik Winther Jensen int/long unification and hex() (2005-06-20) http://python.org/sf/1224347 opened by Josiah Carlson tokenize module does not detect inconsistent dedents (2005-06-21) CLOSED http://python.org/sf/1224621 opened by Danny Yoo rsplit introduces spurious CR (2005-06-21) http://python.org/sf/1224672 opened by Richard Prosser Line endings problem with Python 2.4.1 cause imports to fail (2005-06-21) http://python.org/sf/1225059 opened by Nicolas Lehuen inspect.isclass() fails with custom __getattr__ (2005-06-21) http://python.org/sf/1225107 opened by Jeremy Kloth Bugs Closed ___ float issue for NaN type in .pyc file (2004-12-07) http://python.org/sf/1080440 closed by mwh buffer() object broken. (2005-06-15) http://python.org/sf/1221424 closed by nascheme Incorrect documentation for InPlace Number operators (2005-06-15) http://python.org/sf/1221477 closed by rhettinger Replace MSVC memory allocator with ptmalloc2 (2005-06-07) http://python.org/sf/1216562 closed by loewis Sub threads execute in restricted mode (2005-03-15) http://python.org/sf/1163563 closed by mwh float() not accurate (2005-06-16) http://python.org/sf/1222098 closed by nascheme Typo in section 5.3 of tutorial (2005-06-17) http://python.org/sf/1222459 closed by rhettinger it's - its (2005-06-17) http://python.org/sf/1222928 closed by nascheme 2.4.1 .msi file won't install to different disk (2005-06-17) http://python.org/sf/1222978 closed by hacksoncode spurious blank page in dist.pdf (2005-05-27) http://python.org/sf/1209560 closed by birkenfeld subprocess.py abuse of errno (2005-06-20) http://python.org/sf/1223937 closed by astrand Len too large with national characters (2005-06-20) http://python.org/sf/1224047 closed by mwh tokenize module does not detect inconsistent dedents (2005-06-21)
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
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 *write* an arbitrary function as a lambda. You can write anything as a lambda, but it may not be easy. Regardless, I believe the balance will eventually tip in some direction - either lambdas disappear entirely, become able support full anonymous functions, or else the idea of a 'deferred expression' becomes a defining characteristic, rather than a syntactic quirk. I would put my money on the latter rather than the former. The moment functions start moving beyond a line or so is when they usually start begging for a name. - Josiah ___ 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
