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 "", 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] Explicitly declaring expected exceptions for ablock
> 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 still can be implemented under PEP 343, that's what
I meant under "more flexible".
Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/
--- Original message follows ---
>> 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/dmitry%40targeted.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] Explicitly declaring expected exceptions for a block
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. -- 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] 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] Is PEP 237 final -- Unifying Long Integers and Integers
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, 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? Sounds interresting. Not exactly stright-forward. What i have now is functional, but if speed becomes a problem then this might be useful. -- -- ~ 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) http://pytho
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
[Python-Dev] subprocess.call() and stdin
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 stdin=subprocess.PIPE, which may be the only sane way to handle this argument (I can't think of any use cases for spawning a subprocess with an input stream that nothing can write too). It could also be done by adding a subprocess.CLOSED constant, which if passed to Popen causes a new closed file descriptor to be given to the subprocess. Original Message Bugs item #1220113, was opened at 2005-06-14 15:04 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter Åstrand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. -- >Comment By: Stuart Bishop (zenzen) Date: 2005-06-22 16:12 Message: Logged In: YES user_id=46639 I can't think of any uses cases for wanting to create an inaccessible pipe and give it to the child. Wanting to pass a closed file handle is common. It is needed when calling a program that behaves differently if its stdin is a terminal or not. Or when you simply would prefer the subprocess to die if it attempts to read from its stdin rather than block. Using Popen instead of call is s simpler workaround than creating and closing a file descriptor and passing it in. Perhaps what is needed is a new constant, subprocess.CLOSED which creates a new file descriptor and closes it? This would be useful for Popen too, allowing call() to remain a think and trivially documented wrapper? -- Comment By: Peter Åstrand (astrand) Date: 2005-06-22 02:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behavíour. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ signature.asc Description: OpenPGP digital signature ___ 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
