Jason Orendorff schrieb:
> The lib ref claims that minidom supports DOM Level 1. Does anyone
> know what parts of Level 2 are not implemented?
Most prominently, minidom only implements the Core module of DOM
level 2, none of Views, Events, Style, Traversal and Range, or
HTML. Whether anything is
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 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 be
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
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 expo
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 asynchrono
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
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()
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
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 cas
On 3/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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()
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*(
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 lo
* 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 Micr
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
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() an
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
"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 origina
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 th
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 wri
> 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
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
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 hi
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. Thi
"\"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-clea
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
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*()
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:
ou
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 a
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 throug
> 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:
[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 en
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 th
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 mi
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 cla
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 inhe
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 i
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 t
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 o
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
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
> "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> a
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 sol
43 matches
Mail list logo
