Re: [Python-Dev] Calling base class methods from C
class List(list): def append(self, x): print x List.append(self, x) # What is the C equivalent of this call? Always literally what you write in Python (assuming you meant list.append): PyObject_CallMethod(PyList_Type, append, OO, self, x); HTH, Martin ___ 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] Breaking calls to object.__init__/__new__
Blake Ross wrote: C++ ensures that virtual bases are only constructed once, As far as I remember, C++ ensures this by not calling the base constructors automatically at all, leaving you to explicitly call the constructors of all the virtual bases that you inherit. You could adopt the same solution in Python - have methods called init_xxx in each class Xxx, and call them all from the __init__ method of the most-derived class. -- Greg ___ 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] Breaking calls to object.__init__/__new__
G == Guido van Rossum [EMAIL PROTECTED] writes: G There are different philosophies about the correct style for G cooperative super calls. G The submitter of the bug report likes to remove consumed arguments G and pass the others on, having something at the root that complains G about any unused arguments. It has the problem that you mention: if G multiple classes might be interested in the *same* argument they G won't see it. The other style is to pass *all* arguments down, and G let everyone cherry-pick them. The last call then just throws them G away. This has the problem that misspelled arguments are silently G ignored rather than being diagnosed at the point where you can do G something about it. G I don't know what the best practice is (like Greg Ewing, I don't G use either style myself) but I've got a feeling that it must be G easier to solve the former problem than the latter (also I don't G know that the former actually occurs in practice). I'm following up to the above, as I'm not sure where the best place to jump into this discussion is. I think the problem is more general that just consuming and/or passing on. In the typical style of passing args to super classes that I've seen, __init__ methods in the call chain also don't really even know *whether* they should use an argument. There is also the problem of argument change over time. E.g., suppose I'm the writer of a class X and, unbeknownst to me, someone writes class Y(X,Z), where Z is some other class. Suppose Z's __init__ expects an argument called z. If I one day add an argument called z, that has totally different semantics, things get really hairy. I'm the writer of X, I'm unaware of classes Y and Z, and if someone passes me an z argument then naturally I want to (try to) use it. There are other examples like this, and argument name clashes can be more specific (like 'limit' or 'debug'). In general, we're faced with a situation that is also both time-sensitive and semantics-sensitive. Class writers shouldn't need to know all future argument changes to other classes potentially upstream or downstream from them in the call chain. Given an unstructured mess of arguments, you don't know what to consume, what to ignore, what to pass on, etc., and you don't know the future. Although this sounds much more difficult than simple diamond inheritance, I think there's an easy way to solve it. When writing a class, you know 1) what arguments your __init__ method wants, and 2) what arguments your superclass(es) __init__ methods want. You know the second thing from reading the API/docs of your superclasses - that's why you're calling them. You want to be able, for example, to route a 'limit' argument to one of your super classes and another different 'limit' argument to another of your super classes. You want this to work even if one or more of your superclasses (now or in the future) in turn decides to call some other super class that also has a 'limit' argument with entirely different (or the same) semantics. Etc. An easy solution is for __init__ to receive and pass a dictionary whose keys are class names and whose values are dictionaries of arguments intended for that class. That way, an __init__ method in a class knows exactly which arguments are intended for it. It can detect extra args, missing args, misspelt args, etc. It can also prepare args for its known immediate superclasses (those from which it subclasses) - and it does know these classes as it is explicitly subclassing from them. It can leave arguments that are intended for the __init__ methods in other classes alone. It can create different arguments of the same name for its different superclasses. It can change its signature (adding and dropping args) without affecting the args passed to its superclass. Classes earlier in the call chain can do the same without affecting the args received by this class. It is also immune to differences in superclass name ordering by subclasses (i.e., a subclass of X and Y should be able to be class Z(X,Y) or class(Y,Z) without screwing up the args received by either X.__init__ or Y.__init__. An __init__ could also safely del its own arguments once it has extracted/used them. In some odd cases it might like to pass them along, perhaps even adding something (like a None key to its sub-dictionary) to indicate that it has already been called (yes, this sounds like weird - I'm just mentioning that it would be possible). There's also no need for any special top-level subclasses of object that simply ignore all their arguments (though you _could_ add one if you wanted to be strict and insist that all __init__ methods del their args). This approach adheres nicely to the explicit is better than implicit maxim. I think the implicit situation is unsolvable. I guess this could all be dressed up nicely using a metaclass that pulled out any available args, made them available to the __init__ as regular keyword args, and made available the special
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote: super() has always felt strange to me. When used in __init__? Or in general? If the former, that's because it's a unique Python wart to even be able to use super for __init__. Now, with PEP 3102 and the strict __init__, not so much. Works for me. :-) -- --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] Breaking calls to object.__init__/__new__
On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote: On 3/21/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote: super() has always felt strange to me. When used in __init__? Or in general? If the former, that's because it's a unique Python wart to even be able to use super for __init__. In general. Too many things could fail without errors, so it wasn't obvious how to use it correctly. None of the articles I've read helped either. I've been thinking about writing an article that explains how to use super(), so let's start here :) This is a long post that I'll probably eventually copy-paste-and-edit into an article of some sort, when I get the time. Please do comment, except with 'MI is insane' -- I already know that. Nevertheless, I think MI has its uses. super() is actually extremely straight-forward (except for the call syntax) and the only sane way (that I can think of) of doing co-operative multiple inheritance. Note 'co-operative'. It's not the same thing as using MI for 'mixins'. Co-operative MI isn't always (or often) useful, but it's the only way to make complexer-than-mixins MI not make mush of your brain when users do something unexpected. If you can do with composition or refactoring to make the desire for MI go away, that is probably a better solution. I'm not advocating MI over simpler solutions, but I am advocating *correct* MI over *incorrect* MI :) (And if Python 3.0 is indeed going to have abstract baseclasses, MI is going to be a lot more common, so getting it right is getting more and more important.) Bottom line is, for any given method (with as specific signature and semantics), you need a baseclass that implements that method but does not call its superclass. (It can be an empty implementation, if you want, as long as it at least has it and does not raise an exception. I believe object.__init__'s odd behaviour was a (possibly unconcious) attempt to make it such a baseclass for __init__.) Any class that wants to provide implementation of that method (in a co-operative manner) has at least derive from that baseclass. No class that does not derive from that baseclass must implement the method(s) (at least, not if it is to be part of the MI hierarchy.) Each method should use super() to call the baseclass version. In order to change the signature of a method in part of the MI tree, you need to extract the changed signature in its own hierarchy: provide a new baseclass (which inherits from the original baseclass) with the changed signature, but rather than not call the baseclass method, it calls the baseclass method with the original signature. All classes that implement the changed signature should then derive from that second baseclass. Classes multiply-inheriting from two classes where one of the two's methods are changed with respect to the common baseclass, should put the most-specific class first (this is generally good advice when doing multiple inheritance :) Mixing baseclasses with different signatures but similar semantics is not much easier this way, although IMHO the semantics are less surprising. (This goes for mixing baseclasses that change the signature of *different methods*, too: both classes are 'more specific' than the other class.) Say you have: class A: def spam(self, msg): print msg class B(A): def spam(self, msg, times): for i in range(times): super(B, self).spam(msg) class C(A): def spam(self, msg, finish): super(C, self).spam(msg) print finish There is no way straightforward way to combine them into a class D(B, C). You could make each subclass take arbitrary keyword(-only) arguments and 'consume' them (as suggested in this thread) only in the baseclasses-for-that-signature: class B(A): def spam(self, msg, times, **kwargs): for i in range(times): super(B, self).spam(msg, **kwargs) class C(A): def spam(self, msg, finish, **kwargs): super(C, self).spam(msg, **kwargs) print finish ... but that means adding **kwargs to *all* changed-in-derived-class methods that *might* want to co-operate with changed-differently methods. Notice, though, that the baseclass does *not* take arbitrary keywords (they should all have been consumed by the derived-baseclasses), so you still get checking for unused/misspelled keyword arguments. It happens in a slightly confusing place (the basemostest class for a method) but the message is just as clear. Another way to do it is to insert a new class between B and C, which implements the baseclass signature (not B's) but calls its superclass with C's signature. It has to either invent the extra argument to C's signature on the spot, or fetch it from someplace else, though: # 'helper' class to insert inbetween B and C class BtoC(C): def spam(self, msg): super(BtoC, self).spam(msg, self.finish) # New signature-baseclass for B and C combined class BandC(B, BtoC, C): def spam(self, msg, times,
Re: [Python-Dev] Breaking calls to object.__init__/__new__
Phillip J. Eby wrote: The whole point of being co-operative in a metaclass is to allow other metaclasses to be safely mixed in -- and they may be metaclasses from a completely different library or framework. Some of these use cases might now be addressable using class decorators instead of mixing metaclasses. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] Breaking calls to object.__init__/__new__
On 3/21/07, Blake Ross [EMAIL PROTECTED] wrote: At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote: Also make a big distinction between super calls of __init__ (which are a Pythonic wart and don't exist in other languages practicing multiple inheritance AFAIK) Since I filed the bug, I should clarify that the primary reason I'm using super-init is to avoid multiple construction of a shared base (even if the base is just object, since I'd prefer not to rely on object's initializer being a no-op). C++ ensures that virtual bases are only constructed once, so there's no concern as to multiple construction. Is there a Python pattern better than super-init that provides the same guarantee? (Apologies if this appears in the wrong place; I just joined the list and I'm not seeing a way to participate in an existing thread.) Welcome to the group! You seem to have stirred up quite the discussion. Regarding where to ask for advice on that particular issue, python-dev is *not* the place; comp.lang.python would be more appropriate. Though perhaps Greg Ewing's suggestion is all you need. :-) -- --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] Adding timeout to socket.py and httplib.py
On 3/22/07, Alan Kennedy [EMAIL PROTECTED] wrote: [Alan] - Explicitly check that the address passed is a tuple of (string, integer) [Facundo] In the code, I'll just make host, port = address, I don't think it will be a problem at all. Remember that this function primary use is for higher level libraries, and that address in socket enviroment is always, always, (host, port). It's rather unfortunate that the tuple needs to be unpacked at all. Why? Instead, it should be possible to simply pass the address tuple directly to the socsket.getaddrinfo() function, and let it worry about the tuple-ness of the address, raising exceptions accordingly. The socket.getaddrinfo() function, unlike every other python socket function, takes separate host and port parameters. Which forces every user of the socket.getaddrinfo function to do the same unnecessary and potentially error-prone address tuple unpacking. I have raised a feature request to change this. [1685962] socket.getaddrinfo() should take an address tuple. It's unlikely to be granted. Getaddrinfo(), like gethostname() and a few other things, lives at a different abstraction level than the basic socket object; it is only relevant for IP sockets, not for other types of addresses. The Python call just wraps the system call which has a similar API. While from a purist POV you might want to move all IP-related APIs out of the pure socket module (and this would include SSL), in practice, nobody cares. -- --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] Breaking calls to object.__init__/__new__
Greg Ewing schrieb: Blake Ross wrote: C++ ensures that virtual bases are only constructed once, As far as I remember, C++ ensures this by not calling the base constructors automatically at all, leaving you to explicitly call the constructors of all the virtual bases that you inherit. That's not true. A virtual base constructor is always called directly from the most-specific constructor (i.e. from the constructor of the object being created). If no explicit base constructor call is present in that constructor, an implicit call to the default constructor is made. So if the base class does not have a default constructor, you indeed need to explicitly add a constructor call into each subclass. HTH, Martin ___ 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] Breaking calls to object.__init__/__new__
Following up to myself, with some examples.
I probably haven't done this as cleanly as is possible, but below are a
bunch of classes and subclasses that cleanly deal with passing around
arguments, even when those args conflict in name, etc., as outlined in my
previous mail.
Here's the general class __init__ pattern:
class myclass(A, B, C, ...):
def __init__(self, **kwargs):
initargs = kwargs.setdefault('__initargs__', {}) # 1
Aargs = initargs.setdefault(A, {})# 2
Aargs['limit'] = 10 # 3
Bargs = initargs.setdefault(B, {})# 4
Bargs['limit'] = 'wednesday' # 5
super(myclass, self).__init__(**kwargs) # 6
myargs = initargs.get(myclass, {})# 7
limit = myargs.get('limit', 7)# 8
if 'huh?' in myargs: raise Exception # 9
In words, the steps are:
1. Pull the __initargs__ key out of **kwargs, or create it. This gives you
the top-level dictionary containing your own arguments, if any, and the
args for your superclass(es), if any.
2. Get the arguments for superclass A, and
3. Add an argument for A.__init__
4 5. Do the same for superclass B. We don't alter args for Superclass C.
6. Call super, passing **kwargs along (this contains the original
__initargs__ that was sent to us, or the one we made in step 1 if
there was no prior __initargs__.
7. Our arguments, if any, are in initargs too. Get them.
8. Pull out one of our args, or set a default.
9. Check we didn't get any unexpected args, etc.
Some comments:
- This isn't too ugly, I don't think, but it does require mentioning your
class and superclasses by name. There are many advantages (see last mail)
if you're willing to do this.
- You can combine positional args and explicit keyword args in a class if
you choose, and you can then disambiguate or complain if you like (class
sub4 in the example code below does this). You can also take those
explicit args and stuff them into the __initargs__ for your superclasses,
as/if needed. Explicit args might be a slight pain to deal with, but you
need them as you don't want to destroy the simple class instantiation
mechanism of python that passes args normally to __init__.
- It does require that classes cooperate to a small extent. E.g., you don't
probably don't want the __init__ class in one of your super classes to go
fiddling with initargs[myclass] before myclass even gets to see its own
args (though this particular nit could be solved by having myclass copy /
remove its args before calling super).
- A class could also optionally delete it args once done. In that case it's
cleaner to have line 7 use initargs.setdefault(myclass, {}) so a del
initargs[myclass] always just works.
- If you don't want to mess with the args to your superclasses, don't. In
that case lines 2-5 go away in the above (and 1 and 6 could be swapped).
- You can add *args to all your __init__ methods. This allows your class to
sit in the middle of a class chain where a lower method wants to pass a
positional argument on to a higher class (that wasn't written according
to the above pattern). So the args just gets passed along. It's not as
nice, but it doesn't break anything (by silently not passing on any
positional args that may be present). Classes written using the above
pattern can just ignore all positional args.
- If I were encouraging doing something like the above in python proper,
I think I'd allow line 1 to read
initargs = kwargs.setdefault(None, {})
which adopts the convention that the __init__ keywords are passed in the
None slot of kwargs. Currently you can't do this, as python complains
that all keyword args must be strings. While this goes against explicit
is better that implicit, using __initargs__ as I have done is polluting
the keyword space and would probably one day cause someone a problem.
There's some example code below.
Terry
class err(Exception): pass
class sum(object):
def __init__(self, **kwargs):
print - in sum
initargs = kwargs.setdefault('__initargs__', {})
super(sum, self).__init__(**kwargs)
myargs = initargs.get(sum, {})
limit = myargs.get('limit', 5)
print my limit is %d % limit
class daylimitmaker(object):
def __init__(self, **kwargs):
print - in daylimitmaker
initargs = kwargs.setdefault('__initargs__', {})
super(daylimitmaker, self).__init__(**kwargs)
myargs = initargs.get(daylimitmaker, {})
limit = myargs.get('limit', 'sunday (last day of the week)')
print my limit is '%s' % limit
class lastday(object):
def __init__(self, **kwargs):
print - in lastday
initargs = kwargs.setdefault('__initargs__', {})
Re: [Python-Dev] Breaking calls to object.__init__/__new__
At 05:02 PM 3/22/2007 +1200, Greg Ewing wrote: Phillip J. Eby wrote: The whole point of being co-operative in a metaclass is to allow other metaclasses to be safely mixed in -- and they may be metaclasses from a completely different library or framework. Some of these use cases might now be addressable using class decorators instead of mixing metaclasses. I think we can rule that hypothesis out, since Zope and PEAK have had class decorators for maybe 3-4 years now. Class decorators don't let you provide metaclass methods or properties, for example. (Unless you just use the decorator to mix in the metaclass, which puts you right back where you started.) ___ 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] Patchs and bugs resume
Martin v. Löwis wrote: When you do, make sure you take a look at roundup's search facilities. Roundup keeps a 'last activity' field, on which you can search and sort, and a 'creation date' field (likewise). Could you please point me to documentation about the new tracker? I want to study the best way to extract information from it (right now, I'm just pulling htmls from SF and parsing them, and that's not easy, fast, nor clean). Thank you! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Adding timeout to socket.py and httplib.py
[Alan] - Explicitly check that the address passed is a tuple of (string, integer) [Facundo] In the code, I'll just make host, port = address, I don't think it will be a problem at all. Remember that this function primary use is for higher level libraries, and that address in socket enviroment is always, always, (host, port). It's rather unfortunate that the tuple needs to be unpacked at all. Instead, it should be possible to simply pass the address tuple directly to the socsket.getaddrinfo() function, and let it worry about the tuple-ness of the address, raising exceptions accordingly. The socket.getaddrinfo() function, unlike every other python socket function, takes separate host and port parameters. Which forces every user of the socket.getaddrinfo function to do the same unnecessary and potentially error-prone address tuple unpacking. I have raised a feature request to change this. [1685962] socket.getaddrinfo() should take an address tuple. Regards, Alan. ___ 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] Patchs and bugs resume
Could you please point me to documentation about the new tracker? I want to study the best way to extract information from it (right now, I'm just pulling htmls from SF and parsing them, and that's not easy, fast, nor clean). The tracker software is roundup. It's documentation is at http://roundup.sourceforge.net/ However, I suggest that you just create/recover your account at bugs.python.org (recover using your SF account name), then go to Search, customize a search, perform it, and look at the 'Download as CSV' link. HTH, Martin ___ 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] Adding timeout to socket.py and httplib.py - Updated
Georg Brandl wrote: There are others who can judge the new API and implementation better than me, but I can review the formal issues as soon as the API is accepted. The API is accepted now, I proposed it and Guido say ok 24hs ago, ;) I'll update the patch to that API, and let you know through here... Thank you!!! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Extended Buffer Interface/Protocol
Greg Ewing wrote: Travis Oliphant wrote: I'm talking about arrays of pointers to other arrays: i.e. if somebody defined in C float B[10][20] then B would B an array of pointers to arrays of floats. No, it wouldn't, it would be a contiguously stored 2-dimensional array of floats. An array of pointers would be float *B[10]; followed by code to allocate 10 arrays of 20 floats each and initialise B to point to them. You are right, of course, that example was not correct. I think the point is still valid, though. One could still use the shape to indicate how many levels of pointers-to-pointers there are (i.e. how many pointer dereferences are needed to select out an element). Further dimensionality could then be reported in the format string. This would not be hard to allow. It also would not be hard to write a utility function to copy such shared memory into a contiguous segment to provide a C-API that allows casual users to avoid the details of memory layout when they are writing an algorithm that just uses the memory. I can imagine cases like that coming up in practice. For example, an image object might store its data as four blocks of memory for R, G, B and A planes, each of which is a contiguous 2d array with shape and stride -- but you want to view it as a 3d array byte[plane][x][y]. All we can do is have the interface actually be able to describe it's data. Users would have to take that information and write code accordingly. In this case, for example, one possibility is that the object would raise an error if strides were requested. It would also raise an error if contiguous data was requested (or I guess it could report the R channel only if it wanted to). Only if segments were requested could it return an array of pointers to the four memory blocks. It could then report itself as a 2-d array of shape (4, H) where H is the height. Each element of the array would be reported as %sB % W where W is the width of the image (i.e. each element of the 2-d array would be a 1-d array of length W. Alternatively it could report itself as a 1-d array of shape (4,) with elements (H,W)B A user would have to write the algorithm correctly in order to access the memory correctly. Alternatively, a utility function that copies into a contiguous buffer would allow the consumer to not care about exactly how the memory is layed out. But, the buffer interface would allow the utility function to figure it out and do the right thing for each exporter. This flexibility would not be available if we don't allow for segmented memory in the buffer interface. So, I don't think it's that hard to at least allow the multiple-segment idea into the buffer interface (as long as all the segments are the same size, mind you). It's only one more argument to the getbuffer call. -Travis ___ 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] deprecate commands.getstatus()
Hi all, I posted about adding 'get_output', 'get_status_output', and 'get_status_output_errors' to subprocess here, http://ivory.idyll.org/blog/mar-07/replacing-commands-with-subprocess and got some interesting responses. Briefly, my original proposal was to add these three functions: output = get_output(cmd, input=None, cwd=None, env=None) (status, output) = get_status_output(cmd, input=None, cwd=None, env=None) (status, output, errout) = get_status_output_errors(cmd, input=None, cwd=None, env=None) Commenters convinced me to propose a few additions. In order of estimated plausibility, * first, all sensical keyword args to subprocess.Popen (everything but universal_newlines, stdout, stderr, and bufsize, which don't make much sense in the context of the proposed functions) should be accepted by the 'get_' functions. This complicates the function signatures but does make them potentially much more useful. * second, I'd like to add a 'require_success' bool keyword, that is by default False (and does nothing in that case). However, when True, the functions would emulate check_call, i.e. they would raise CalledProcessError when the returncode was not zero. * third, the 'popen2' module should be deprecated for 2.6. I don't see that it has anything in it that subprocess doesn't have. Thoughts? --titus p.s. This has been a fun learning process... ;) ___ 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] deprecate commands.getstatus()
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor the popen2 module at all, and do everything via the subprocess module. I wonder if we should even get rid of os.system(); then there should be a subprocess.system() instead. And do we even need os.fork(), os.exec*(), os.spawn*()? On 3/22/07, Titus Brown [EMAIL PROTECTED] wrote: Hi all, I posted about adding 'get_output', 'get_status_output', and 'get_status_output_errors' to subprocess here, http://ivory.idyll.org/blog/mar-07/replacing-commands-with-subprocess and got some interesting responses. Briefly, my original proposal was to add these three functions: output = get_output(cmd, input=None, cwd=None, env=None) (status, output) = get_status_output(cmd, input=None, cwd=None, env=None) (status, output, errout) = get_status_output_errors(cmd, input=None, cwd=None, env=None) Commenters convinced me to propose a few additions. In order of estimated plausibility, * first, all sensical keyword args to subprocess.Popen (everything but universal_newlines, stdout, stderr, and bufsize, which don't make much sense in the context of the proposed functions) should be accepted by the 'get_' functions. This complicates the function signatures but does make them potentially much more useful. * second, I'd like to add a 'require_success' bool keyword, that is by default False (and does nothing in that case). However, when True, the functions would emulate check_call, i.e. they would raise CalledProcessError when the returncode was not zero. * third, the 'popen2' module should be deprecated for 2.6. I don't see that it has anything in it that subprocess doesn't have. Thoughts? --titus p.s. This has been a fun learning process... ;) ___ 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/guido%40python.org -- --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] deprecate commands.getstatus()
Guido van Rossum schrieb: Sounds good to me. In 3.0 we should probably not have os.popen*(), nor the popen2 module at all, and do everything via the subprocess module. I wonder if we should even get rid of os.system(); then there should be a subprocess.system() instead. And do we even need os.fork(), os.exec*(), os.spawn*()? I don't know about about *os*.fork; I surely like to have posix.fork. The posix module exposes many OS functions as-is. This has the advantage that their semantics are crystal-clear: they do whatever the system call does (which, ideally, is what POSIX specifies for it). So you can do systems programming in Python, and only need good knowledge of the underlying system calls (i.e. using Python as a better C). For the subsystem module, the semantics is not so clear, in border cases. Regards, Martin ___ 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] deprecate commands.getstatus()
\Martin v. Löwis\ [EMAIL PROTECTED] wrote: And do we even need os.fork(), os.exec*(), os.spawn*()? I don't know about about *os*.fork; I surely like to have posix.fork. The posix module exposes many OS functions as-is. This has the advantage that their semantics are crystal-clear: they do whatever the system call does (which, ideally, is what POSIX specifies for it). So you can do systems programming in Python, and only need good knowledge of the underlying system calls (i.e. using Python as a better C). I definitely agree. Removing the POSIX system call mappings would make Python less useful and general-purpose. Yes it's nice to have high-level utility functions like those in the subprocess module, but I think it's very important for the low-level functions to be there too when you need them. ___ 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] deprecate commands.getstatus()
On 3/22/07, Jon Ribbens [EMAIL PROTECTED] wrote: \Martin v. Löwis\ [EMAIL PROTECTED] wrote: And do we even need os.fork(), os.exec*(), os.spawn*()? I don't know about about *os*.fork; I surely like to have posix.fork. The posix module exposes many OS functions as-is. This has the advantage that their semantics are crystal-clear: they do whatever the system call does (which, ideally, is what POSIX specifies for it). So you can do systems programming in Python, and only need good knowledge of the underlying system calls (i.e. using Python as a better C). I definitely agree. Removing the POSIX system call mappings would make Python less useful and general-purpose. Yes it's nice to have high-level utility functions like those in the subprocess module, but I think it's very important for the low-level functions to be there too when you need them. Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? I also hear no opposition against killign os.system() and os.popen(). -- --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] Breaking calls to object.__init__/__new__
Can we move this to c.l.py or python-ideas? I don't think it has any bearing on the decision on whether object.__init__() or object.__new__() should reject excess arguments. Or if it does I've lost the connection through the various long articles. I also would like to ask Mr. Olsen to tone down his rhetoric a bit. There's nothing unpythonic about designing an API using positional arguments. --Guido On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote: On 3/22/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote: In general. Too many things could fail without errors, so it wasn't obvious how to use it correctly. None of the articles I've read helped either. I've been thinking about writing an article that explains how to use super(), so let's start here :) This is a long post that I'll probably eventually copy-paste-and-edit into an article of some sort, when I get the time. Please do comment, except with 'MI is insane' -- I already know that. Nevertheless, I think MI has its uses. I'm going to be blunt, and I apologize if I offend. In short, your article is no better than any of the others. TOOWTDI What you've done is list off various ways why multiple inheritance and super() can fail, and then provide a toolbox from which a programmer can cobble together a solution to fit their exact needs. It's not pythonic. What we need is a *single* style that can be applied consistently to 90+% of problems while still requiring minimal effort to read later. Using keyword arguments and consuming them is the best I've seen so far. Sure it's a little verbose, but the verbosity is repetitive and easy to tune out. It also requires the classes to cooperate. News flash: Python isn't C++ or Java. Python uses a shared __dict__ rather than private namespaces in each class. Python *always* requires the classes to cooperate. If you want to combine uncooperative classes you need to use delegation. I'm sure somebody could whip up a metaclass to automate it, especially with the new metaclass syntax, not to mention ABCs to say I'm string-ish when you're delegating str. -- Adam Olsen, aka Rhamphoryncus -- --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] deprecate commands.getstatus()
Guido van Rossum wrote: On 3/22/07, Jon Ribbens [EMAIL PROTECTED] wrote: \Martin v. Löwis\ [EMAIL PROTECTED] wrote: And do we even need os.fork(), os.exec*(), os.spawn*()? I don't know about about *os*.fork; I surely like to have posix.fork. The posix module exposes many OS functions as-is. This has the advantage that their semantics are crystal-clear: they do whatever the system call does (which, ideally, is what POSIX specifies for it). So you can do systems programming in Python, and only need good knowledge of the underlying system calls (i.e. using Python as a better C). I definitely agree. Removing the POSIX system call mappings would make Python less useful and general-purpose. Yes it's nice to have high-level utility functions like those in the subprocess module, but I think it's very important for the low-level functions to be there too when you need them. Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? I also hear no opposition against killign os.system() and os.popen() Except that 'os.system' is really easy to use and I use it rarely enough that I *always* have to RTFM for subprocess which makes you jump through a few more (albeit simple) hoops. Additionally, AFAIK subprocess is still broken for py2exe'd applications which is a problem. All the best, Michael Foord ___ 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] deprecate commands.getstatus()
Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? Right, I personally would not miss it. It's also not a system call, but a library function on both Windows and Unix (the equivalent of exposing fork would be to expose CreateProcessEx - something that I think Python should do out of the box, and not just when PythonWin is installed - but you can now get it through ctypes). I also hear no opposition against killign os.system() and os.popen(). Both are library functions; I can implement them in Python on top of what is there (plus popen is based on stdio, which we declared evil). So yes, the can go. Regards, Martin ___ 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] Breaking calls to object.__init__/__new__
On 3/22/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote: In general. Too many things could fail without errors, so it wasn't obvious how to use it correctly. None of the articles I've read helped either. I've been thinking about writing an article that explains how to use super(), so let's start here :) This is a long post that I'll probably eventually copy-paste-and-edit into an article of some sort, when I get the time. Please do comment, except with 'MI is insane' -- I already know that. Nevertheless, I think MI has its uses. I'm going to be blunt, and I apologize if I offend. In short, your article is no better than any of the others. TOOWTDI What you've done is list off various ways why multiple inheritance and super() can fail, and then provide a toolbox from which a programmer can cobble together a solution to fit their exact needs. It's not pythonic. What we need is a *single* style that can be applied consistently to 90+% of problems while still requiring minimal effort to read later. Using keyword arguments and consuming them is the best I've seen so far. Sure it's a little verbose, but the verbosity is repetitive and easy to tune out. It also requires the classes to cooperate. News flash: Python isn't C++ or Java. Python uses a shared __dict__ rather than private namespaces in each class. Python *always* requires the classes to cooperate. If you want to combine uncooperative classes you need to use delegation. I'm sure somebody could whip up a metaclass to automate it, especially with the new metaclass syntax, not to mention ABCs to say I'm string-ish when you're delegating str. -- Adam Olsen, aka Rhamphoryncus ___ 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] deprecate commands.getstatus()
On Thu, Mar 22, 2007 at 09:34:46PM +, Michael Foord wrote: - Guido van Rossum wrote: - Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), - that abomination invented by Microsoft? I also hear no opposition - against killign os.system() and os.popen() - - Except that 'os.system' is really easy to use and I use it rarely enough - that I *always* have to RTFM for subprocess which makes you jump through - a few more (albeit simple) hoops. Hopefully the patch I'm making will change that, no? I could add in a 'system'-alike call easily enough; that was suggested. But I think returncode = subprocess.call(program) is pretty simple, isn't it? - Additionally, AFAIK subprocess is still broken for py2exe'd applications - which is a problem. Explain? cheers, --titus ___ 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] deprecate commands.getstatus()
Guido van Rossum [EMAIL PROTECTED] wrote: Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? I also hear no opposition against killign os.system() and os.popen(). As long as os.system migrates to subprocess.system (as you originally suggested), I'm +1 with everything mentioned in this thread. - 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
Re: [Python-Dev] deprecate commands.getstatus()
On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? I also hear no opposition against killign os.system() and os.popen() Except that 'os.system' is really easy to use and I use it rarely enough that I *always* have to RTFM for subprocess which makes you jump through a few more (albeit simple) hoops. So let's add subprocess.system() which takes care of the hoops (but still allows you more flexibility through optional keyword parameters). Additionally, AFAIK subprocess is still broken for py2exe'd applications which is a problem. That doesn't sound like an API design concern -- it's a bug that just needs to be fixed somewhere. -- --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] deprecate commands.getstatus()
Titus Brown wrote: On Thu, Mar 22, 2007 at 09:34:46PM +, Michael Foord wrote: - Guido van Rossum wrote: - Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), - that abomination invented by Microsoft? I also hear no opposition - against killign os.system() and os.popen() - - Except that 'os.system' is really easy to use and I use it rarely enough - that I *always* have to RTFM for subprocess which makes you jump through - a few more (albeit simple) hoops. Hopefully the patch I'm making will change that, no? I could add in a 'system'-alike call easily enough; that was suggested. But I think returncode = subprocess.call(program) is pretty simple, isn't it? Probably. I can just never remember it (I didn't remember it when typing that email). My fault, os.system is just easier to remember - make an os system call. :-) - Additionally, AFAIK subprocess is still broken for py2exe'd applications - which is a problem. Explain? Programs created with py2exe (or frozen in other ways I believe - including the Wing IDE for example), fail with an error similar to the following : Traceback (most recent call last): File main.py, line 133, in module main() File main.py, line 125, in main launch_launcher() File main.py, line 98, in launch_launcher subprocess.Popen([path], stderr = childstderr) File subprocess.pyc, line 586, in ___init___ File subprocess.pyc, line 681, in _get_handles File subprocess.pyc, line 722, in _make_inheritable TypeError: an integer is required The problem is detailed here : http://www.py2exe.org/index.cgi/Py2ExeSubprocessInteractions if you used py2exe to create a Windows program as opposed to a console program, and you launched the py2exe program by clicking rather than by running if from a command window, then the parent process has no handle to inherit. subprocess.Popen will throw an exception (TypeError: an integer is required) because GetStdHandle returns None (Although the workaround as listed there is reported not to work and I haven't put the effort into experimenting.) If subprocess is supposed to be the main way that users launch sub-processes it would be nice if it worked for py2exe without the users (who are often newbies) having to put a workaround in place. Currently of course 'os.system' is often sufficient workaround. :-) All the best, Michael Foord cheers, --titus ___ 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] deprecate commands.getstatus()
On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote: - On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote: - Guido van Rossum wrote: - Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), - that abomination invented by Microsoft? I also hear no opposition - against killign os.system() and os.popen() - - Except that 'os.system' is really easy to use and I use it rarely enough - that I *always* have to RTFM for subprocess which makes you jump through - a few more (albeit simple) hoops. - - So let's add subprocess.system() which takes care of the hoops (but - still allows you more flexibility through optional keyword - parameters). How would this differ from subprocess.call()? http://docs.python.org/lib/node530.html (And should I add this in my patch, or is this for Py3k?) --titus ___ 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] deprecate commands.getstatus()
* Titus Brown wrote: On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote: - On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote: - Guido van Rossum wrote: - Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), - that abomination invented by Microsoft? I also hear no opposition - against killign os.system() and os.popen() - - Except that 'os.system' is really easy to use and I use it rarely enough - that I *always* have to RTFM for subprocess which makes you jump through - a few more (albeit simple) hoops. - - So let's add subprocess.system() which takes care of the hoops (but - still allows you more flexibility through optional keyword - parameters). How would this differ from subprocess.call()? http://docs.python.org/lib/node530.html It doesn't implement the system() spec: http://opengroup.org/onlinepubs/007908799/xsh/system.html nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2 ___ 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] Breaking calls to object.__init__/__new__
On 3/22/07, Guido van Rossum [EMAIL PROTECTED] wrote: Can we move this to c.l.py or python-ideas? I don't think it has any bearing on the decision on whether object.__init__() or object.__new__() should reject excess arguments. Or if it does I've lost the connection through the various long articles. It's about use-cases involving what object.__init__() does. However, as it supports the decision that has been already made, you are right in that it no longer belongs on python-dev. I'll move further replies somewhere else. I also would like to ask Mr. Olsen to tone down his rhetoric a bit. There's nothing unpythonic about designing an API using positional arguments. Again, I apologize for that. But the unpythonic comment referred only to providing an assortment of unobvious choices, rather than a single obvious one (perhaps with specialty options rarely used). It was not in reference to my previous argument against positional arguments. -- Adam Olsen, aka Rhamphoryncus ___ 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] deprecate commands.getstatus()
On Thu, Mar 22, 2007 at 11:12:26PM +0100, Andr? Malo wrote: - * Titus Brown wrote: - - On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote: - - On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote: - - Guido van Rossum wrote: - - Sure. os.fork() and the os.exec*() family can stay. But - os.spawn*(), - that abomination invented by Microsoft? I also hear - no opposition - against killign os.system() and os.popen() - - - - Except that 'os.system' is really easy to use and I use it rarely - enough - that I *always* have to RTFM for subprocess which makes you - jump through - a few more (albeit simple) hoops. - - - - So let's add subprocess.system() which takes care of the hoops (but - - still allows you more flexibility through optional keyword - - parameters). - - How would this differ from subprocess.call()? - - http://docs.python.org/lib/node530.html - - It doesn't implement the system() spec: - http://opengroup.org/onlinepubs/007908799/xsh/system.html - - nd OK, but I'm still confused. This isn't about moving os.system into subprocess, it's about reimplementing os.system *with* subprocess.Popen, right? And how would that be substantially different from call()? Different defaults? (like shell=True, close_fds=False?) --titus ___ 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] Adding timeout to socket.py and httplib.py
Guido van Rossum wrote: It's unlikely to be granted. ... The Python call just wraps the system call which has a similar API. What about letting it accept both? Maintaining strict consistency with the C API here at the cost of causing pain on almost all uses of the function seems to be a case of purity beating practicality. -- Greg ___ 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] deprecate commands.getstatus()
Titus Brown wrote: * second, I'd like to add a 'require_success' bool keyword, that is by default False (and does nothing in that case). However, when True, the functions would emulate check_call, i.e. they would raise CalledProcessError when the returncode was not zero. By the no-constant-parameters principle, I think it would be better to have another set of functions for this. They should be named without 'status' in the names, since if the function returns at all, the status is always going to be zero. -- Greg ___ 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] deprecate commands.getstatus()
Guido van Rossum wrote: I wonder if we should even get rid of os.system(); then there should be a subprocess.system() instead. That sounds okay, since system() isn't actually a system call, despite its name. And do we even need os.fork(), os.exec*(), os.spawn*()? Since fork() and exec() are directly wrapping actual system calls, I think they should stay in os. I'm not sure about spawn() -- on Unix it's not a direct system call, but it might be on Windows. -- Greg ___ 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] deprecate commands.getstatus()
Titus Brown wrote: I could add in a 'system'-alike call easily enough; that was suggested. But I think returncode = subprocess.call(program) is pretty simple, isn't it? Something to keep in mind is that system() doesn't directly launch a process running the command, it uses a shell. So it's not just simple sugar for some subprocess.* call. -- Greg ___ 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] deprecate commands.getstatus()
On 22 Mar, 08:38 pm, [EMAIL PROTECTED] wrote: And do we even need os.fork(), os.exec*(), os.spawn*()? Maybe not os.spawn*, but Twisted's spawnProcess is implemented (on UNIX) in terms of fork/exec and I believe it should stay that way. The subprocess module isn't really usable for asynchronous subprocess communication. ___ 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] deprecate commands.getstatus()
On 22 Mar, 09:37 pm, [EMAIL PROTECTED] wrote: Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? Right, I personally would not miss it. It's also not a system call, but a library function on both Windows and Unix (the equivalent of exposing fork would be to expose CreateProcessEx - something that I think Python should do out of the box, and not just when PythonWin is installed - but you can now get it through ctypes). I also hear no opposition against killign os.system() and os.popen(). Both are library functions; I can implement them in Python on top of what is there (plus popen is based on stdio, which we declared evil). So yes, the can go. In the long term (read: 3k) I think I agree completely. It seems that this is a clear-cut case of TATMWTDI (there are too many ways to do it) and the subprocess module should satisfy all of these use-cases. I also like Martin's earlier suggestion of calling the remaining OS process-manipulation functions posix.fork, etc. I think it would be a lot clearer to read and maintain the implementation of subprocess (and asynchronous equivalents, like Twisted's process support) if the platform back-ends were explicitly using APIs in platform-specific modules. The current Twisted implementation misleadingly looks like the UNIX implementation is cross-platform because it uses functions in the os module, whereas the Windows implementation uses win32all. ___ 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] deprecate commands.getstatus()
On 3/22/07, Greg Ewing [EMAIL PROTECTED] wrote: Titus Brown wrote: I could add in a 'system'-alike call easily enough; that was suggested. But I think returncode = subprocess.call(program) is pretty simple, isn't it? Something to keep in mind is that system() doesn't directly launch a process running the command, it uses a shell. So it's not just simple sugar for some subprocess.* call. subprocess.call(ls | grep tmp, shell=True) svn-commit.2.tmp svn-commit.tmp The more important difference is the encoding of the return value: system() has magic to encode signal-related termination of the child process. -Mike ___ 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] minidom and DOM level 2
On 3/22/07, Jason Orendorff [EMAIL PROTECTED] wrote: The lib ref claims that minidom supports DOM Level 1. Does anyone know what parts of Level 2 are not implemented? I wasn't able to find anything offhand. It seems to be more a matter of what's not documented, or what's not covered by the regression tests. So. I'd be happy to do some diffing between the implementation, documentation, tests, and the Recommendation, and submit patches for whatever needs it. If anyone thinks that's worthwhile. Anyone? It obviously wouldn't hurt to have level 2 compliance. So I am definitely not going to tell you to not do it. =) -Brett ___ 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
