[Python-Dev] subprocess.call() and stdin

2005-06-21 Thread Stuart Bishop
Redirecting to python-dev for discussion. When I invoke subprocess.call(), I often want to ensure that the subprocess' stdin is closed. This ensures it will die if the subprocess attempts to read from stdin rather than block. This could be done if the subprocess.call() helper closes the input if

Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-21 Thread Josiah Carlson
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'

[Python-Dev] Weekly Python Patch/Bug Summary

2005-06-21 Thread Kurt B. Kaiser
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 th

Re: [Python-Dev] Explicitly declaring expected exceptions for a block

2005-06-21 Thread Dmitry Dvoinikov
> 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,

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Keith Dart
On Tue, 21 Jun 2005, Ron Adam wrote: > 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, fl

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Keith Dart
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. > >> I

Re: [Python-Dev] Propose updating PEP 284 -- Integer for-loops

2005-06-21 Thread Raymond Hettinger
[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 keywor

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Ron Adam
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

Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

2005-06-21 Thread Nick Coghlan
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 entir

Re: [Python-Dev] Explicitly declaring expected exceptions for a block

2005-06-21 Thread Nick Coghlan
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.exce

Re: [Python-Dev] Explicitly declaring expected exceptions for ablock

2005-06-21 Thread Dmitry Dvoinikov
> try: > c().foo() > except TypeError: > pass > else: > assert False, "c.foo() should have thrown TypeError" In fact, the above code actually expects foo to throw particular exception, not exactly the same as the original requirement. More of expect TypeError: c().foo() and s

Re: [Python-Dev] Explicitly declaring expected exceptions for ablock

2005-06-21 Thread Dmitry Dvoinikov
> 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() shoul

Re: [Python-Dev] Explicitly declaring expected exceptions for ablock

2005-06-21 Thread Michael Chermside
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

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Guido van Rossum
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

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Guido van Rossum
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 w

Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

2005-06-21 Thread Shane Hathaway
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