Re: [Python-Dev] confusing exec error message in 3.0

[Steven D'Aprano]

On Thu, 28 Aug 2008 01:38:14 pm Guido van Rossum wrote:
> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <[EMAIL PROTECTED]> 
wrote:
...
> > I don't think M.__file__ should lie and say it was loaded from a
> > file that it wasn't loaded from. It's useful to be able to look at
> > a module and see what file it was actually loaded from.
>
> While appreciate the use case, there are way more use cases where
> there's code that must painstakingly strip the trailing 'c' or 'o'
> from __file__ in order to read the source code. Perhaps we should
> have a separate API for finding out whether a module was loaded from
> source or from a .pyc file; but I think it would be better to have
> such an API somewhere in the imp module. It's also possible to follow
> what goes on by watching the verbose -v output.

Thinking more about it, I'm quite enthusiastic about Brett Cannon's 
suggestion that modules should grow a __source__ attribute as well as 
__file__.

One disadvantage of a separate API is that it's relatively hard to 
discover, compared to dir(module) or help(module). I don't think I 
would have thought to look at a module "imp" (implementation?) when I 
needed that information. But perhaps that's a separate issue.

How would such an API work? Knowing nothing concrete about the 
implementation, I can think of two ways:

(1) Look at the module object and extract information from it that 
recorded what file it came from at the time, even if the Python path 
(or its contents) changed. This is the 2.x semantics of __file__.

(2) Look at the Python path as it exists now, and try to predict 
(postdict?) which file might have been used to import the module.

Of the two, I feel that postdiction is the worse solution. I imagine 
that this behaviour would be undesirable:

# not real code
>>> sys.path.append('somewhere')
>>> import parrot  # imports from 'somewhere/parrot.pyc'
>>> parrot.__file__
'somewhere/parrot.py'
>>> del sys.path[-1]
>>> sys.path.append('somewhere_else/different')
>>> imp.where_from(parrot)
'somewhere_else/different/parrot.py'

But maybe that can't happen and I'm worrying for nothing.


So what happens now? Does this need a PEP for further discussion?



-- 
Steven
___
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] Things to Know About Super

[Michele Simionato]

Alex Martelli wrote:
> What's DebugFrameworkMeta2?  I assume it's some kind of mix but I
> don't see it defined anywhere so I'm having to guess.

Sorry Alex, here is definition which got lost in cut&paste:

DebugFrameworkMeta2 = include_mixin(DebugMeta2, FrameworkMeta2)

> I'd like to understand what, in this example, removes the apparent
> "fragility" (or, lack of flexibility) where DebugMeta2 specifically
> uses mcl.__base__ -- IOW, if I have another "mixin metaclass" just
> like DebugMeta2 but called (say) RemotableMeta which does a print
> "Adding remoting features" and then also calls
> mcl.__base__.__new__(mcl ... just like DebugMeta2, what gets both of
> their __new__ methods called in the right order?

If you want to reimplement full cooperation between mixins classes
you must rework a bit the example, but it does not take a big effort
(see later). However my main point is: do we really want cooperative
methods? Multiple inheritance of metaclasses is perhaps
the strongest use case for multiple inheritance, but is it strong
enough? I mean, in real code how many times did I need that?
I would not mind make life harder for gurus and simpler for
application programmers. I do not think removing cooperation
would be so bad in practice. In many practical cases, one could just write
the metaclass by hand, in this example something like

class RemotableDebugFrameworkMeta(FrameworkMeta):
   def __new__(mcl, name, bases, dic):
   print "Adding remoting features to %s" % name
   print "Adding debugging features to %s" % name
   return FrameworkMeta.__new__(mcl, name, bases, dic)

Maybe you would need to duplicate a couple of lines and/or to introduce
an helper function, but you would have the benefit of having a more
explicit metaclass, with a simpler hierarchy (see the appendix for
an alternative solution).

> Maybe you could help me understand this by giving a fully executable
> Python snippet using __bases__[0] instead of the hypothetical
> __base__?

To the best of my knowledge __base__ is a valid class attribute,
it denotes the "right" class to use as base. Usually it is the same
as bases[0], but there is at least one case when it is different,
when composing old style and new style classes:

  >>> class OldStyle: pass
  >>> class NewStyle(object): pass
  >>> class New(OldStyle, NewStyle): pass
  >>> New.__bases__[0]
  
  >>> New.__base__
  

Appendix: how to reimplement cooperation in a single-inheritance world


Quoting Raymond: "To achieve substantially the
same functionality, you would likely have to
re-invent much of what super() does for us automatically, and
you would still be imposing constraits on the composed classes
that are substantially the same as what you have with inheritance."

Raymond of course is right, but I am arguing that one does not really
need to re-invent cooperation because the use case for cooperation
are exceedingly rare. Still, if one really wants to reimplement
cooperation, here is my take at the challenge:

$ cat cooperative_mixins.py
"Implements cooperative mixins using multiple-inheritance only"

## everything in three lines
def include_mixin(mixin, cls): # could be extended to use more mixins
# traits as in Squeak take the precedence over the base class
dic = vars(mixin).copy() # could be extended to walk the ancestors
dic['_%s__super' % mixin.__name__] = cls
return type(mixin.__name__ + cls.__name__, (cls,),  dic)

## examples:

class FrameworkMeta(type): # example metaclass
   def __new__(mcl, name, bases, dic):
   print "Adding framework features to %s" % name
   return type.__new__(mcl, name, bases, dic)

class DebugMeta(type): # mixin metaclass
   def __new__(mcl, name, bases, dic):
   print "Adding debugging features to %s" % name
   return mcl.__super.__new__(mcl, name, bases, dic)

class RemotableMeta(type): # another mixin metaclass
   def __new__(mcl, name, bases, dic):
   print "Adding remoting features to %s" % name
   return mcl.__super.__new__(mcl, name, bases, dic)

class FrameworkClass(object):
__metaclass__ = FrameworkMeta

DebugFrameworkMeta = include_mixin(DebugMeta, FrameworkMeta)

print ' creating DebugFrameworkClass'
class DebugFrameworkClass(FrameworkClass):
__metaclass__ = DebugFrameworkMeta

RemotableDebugFrameworkMeta = include_mixin(
   RemotableMeta, DebugFrameworkMeta)

print ' creating RemotableDebugFrameworkClass'
class RemotableDebugFrameworkClass(FrameworkClass):
__metaclass__ = RemotableDebugFrameworkMeta
___
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] confusing exec error message in 3.0

[Guido van Rossum]

On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:
>> Fredrik Lundh schrieb:
>> > (using 3.0a4)
>> >
>> >  >>> exec(open("file.py"))
>> >
>> > Traceback (most recent call last):
>> >File "", line 1, in 
>> > TypeError: exec() arg 1 must be a string, file, or code object, not
>> > TextIOWrapper
>> >
>> > so what's "file" referring to here?
>> >
>> > (the above works under 2.5, of course)
>>
>> See http://bugs.python.org/issue1762972 -- it has been decided to
>> drop that possibility.
>
> Hmmm... I have a concern with one of the patches in that issue; I refer
> to patch that changes the semantics of module's __file__ attribute.
>
> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked
> as a replacement for reload(), except that there were issues with file
> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was
> decided that M.__file__ should always point to the source file.
>
> But now that reload() is now moved into the imp module, I don't see that
> the justification for changing the semantics of M.__file__ still
> exists. imp.reload(M) is much better for interactive use than
> exec(open(M.__file__).read(), M.__dict__).
>
> Is there still a justification for having M.__file__ point to the source
> even if the module was actually loaded from the .pyc version? If so,
> what is that?
>
> Some years ago, as a newbie, I was having trouble with reload()
> repeatedly not picking up changes I was making to a module. The problem
> turned out to be user-error, but how I discovered that was by looking
> at M.__file__ and noticing that Python was loading the .pyc file
> instead of the .py file I was expecting. Had M.__file__ given
> misleading information, I would have been mislead for much longer.
> Here's a small contrived example under Python 2.5:
>
 import parrot
 parrot.__file__
> 'parrot.py'
 # pretend that I made changes to the source
> ... # in my editor, but forgot to save them
> ... reload(parrot)
> 
 parrot.__file__
> 'parrot.pyc'
>
>
> I don't think M.__file__ should lie and say it was loaded from a file
> that it wasn't loaded from. It's useful to be able to look at a module
> and see what file it was actually loaded from.

While appreciate the use case, there are way more use cases where
there's code that must painstakingly strip the trailing 'c' or 'o'
from __file__ in order to read the source code. Perhaps we should have
a separate API for finding out whether a module was loaded from source
or from a .pyc file; but I think it would be better to have such an
API somewhere in the imp module. It's also possible to follow what
goes on by watching the verbose -v output.

-- 
--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] confusing exec error message in 3.0

[Steven D'Aprano]

On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:
> Fredrik Lundh schrieb:
> > (using 3.0a4)
> >
> >  >>> exec(open("file.py"))
> >
> > Traceback (most recent call last):
> >File "", line 1, in 
> > TypeError: exec() arg 1 must be a string, file, or code object, not
> > TextIOWrapper
> >
> > so what's "file" referring to here?
> >
> > (the above works under 2.5, of course)
>
> See http://bugs.python.org/issue1762972 -- it has been decided to
> drop that possibility.

Hmmm... I have a concern with one of the patches in that issue; I refer 
to patch that changes the semantics of module's __file__ attribute.

Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked 
as a replacement for reload(), except that there were issues with file 
extensions (.py, .pyc, .pyo and even things like .pyc24). So it was 
decided that M.__file__ should always point to the source file.

But now that reload() is now moved into the imp module, I don't see that 
the justification for changing the semantics of M.__file__ still 
exists. imp.reload(M) is much better for interactive use than 
exec(open(M.__file__).read(), M.__dict__).

Is there still a justification for having M.__file__ point to the source 
even if the module was actually loaded from the .pyc version? If so, 
what is that?

Some years ago, as a newbie, I was having trouble with reload() 
repeatedly not picking up changes I was making to a module. The problem 
turned out to be user-error, but how I discovered that was by looking 
at M.__file__ and noticing that Python was loading the .pyc file 
instead of the .py file I was expecting. Had M.__file__ given 
misleading information, I would have been mislead for much longer. 
Here's a small contrived example under Python 2.5:

>>> import parrot
>>> parrot.__file__
'parrot.py'
>>> # pretend that I made changes to the source 
... # in my editor, but forgot to save them
... reload(parrot)

>>> parrot.__file__
'parrot.pyc'


I don't think M.__file__ should lie and say it was loaded from a file 
that it wasn't loaded from. It's useful to be able to look at a module 
and see what file it was actually loaded from.



-- 
Steven
___
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] confusing exec error message in 3.0

[Guido van Rossum]

2008/8/27 Fredrik Lundh <[EMAIL PROTECTED]>:
> Fredrik Lundh wrote:
>
>> (using 3.0a4)
>
> ahem.  I could have sworn that I installed a beta, but I guess the Windows
builds weren't fully synchronized when I did that.  I still get the same
error after updating to 3.0b2, though.

It's still there. It's a hold-over from 2.x where opened files were indeed
usable for exec(). It was a rarely-used feature that turned out to be hard
to implement given the continued reliance of the parser on  while
the I/O system no longer uses that, so it was dropped with very little
protests.

Please do fix it!

-- 
--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] Things to Know About Super

[Greg Ewing]

M.-A. Lemburg wrote:


The typical use is in mixin classes that can be used to
add functionality to base classes...


But this is just another waffly made-up example. I'm
talking about real-life use cases from actual code
that's in use.

--
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] Reference leak in thread._local

[Aahz]

On Wed, Aug 27, 2008, [EMAIL PROTECTED] wrote:
>
> I noticed that thread._local can leak references if objects are
> being stored inside the thread._local object whose destructors
> might release the GIL.

Please post this bug report & patch to bugs.python.org -- otherwise, it
will almost certainly get lost.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
___
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] confusing exec error message in 3.0

[Michael Foord]

Georg Brandl wrote:

Fredrik Lundh schrieb:
  

(using 3.0a4)

 >>> exec(open("file.py"))
Traceback (most recent call last):
   File "", line 1, in 
TypeError: exec() arg 1 must be a string, file, or code object, not 
TextIOWrapper


so what's "file" referring to here?

(the above works under 2.5, of course)



See http://bugs.python.org/issue1762972 -- it has been decided to drop
that possibility.

I've a patch that fixes the wrong error message in 
http://bugs.python.org/issue3706.
  


In order to obtain a string from a Python source code file, honouring 
encoding cookies, the tokenize module has a 'detect_encoding' function 
that could be useful.


Michael

Georg

___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

___
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] Reference leak in thread._local

[Ben . Cottrell]

I noticed that thread._local can leak references if objects are
being stored inside the thread._local object whose destructors
might release the GIL.

The way this happens is that in Modules/threadmodule.c, in the
_ldict() function, it does things like this:

Py_CLEAR(self->dict);
Py_INCREF(ldict);
self->dict = ldict;

If the Py_CLEAR ends up taking away the last reference to an object
contained in the dict, and a thread context switch occurs during that
object's deallocation, then self->dict might not be NULL on return
from Py_CLEAR; another thread might have run, accessed something in
the same thread._local object, and caused self->dict to be set to
something else (and Py_INCREF'ed). So when we blindly do the
assignment into self->dict, we may be overwriting a valid reference,
and not properly Py_DECREFing it.

The recent change (revision 64601 to threadmodule.c) did not address
context switches during the Py_CLEAR call; only context switches
during tp_init.

The attached patch (against trunk) is my first attempt at fixing this.
It detects if self->dict has been set to something else after the
Py_CLEAR, and retries the Py_CLEAR (because _ldict really only cares
about installing the proper value of self->dict for the currently
running thread).

However, I am still uncomfortable about the fact that local_getattro
and local_setattro discard the value returned from _ldict, and instead
hand off control to the PyObject_Generic layer and trust that by the
time self->dict is actually used, it still has the correct value for
the current thread. Would it be better to, say, inline a copy of the
PyObject_Generic* functions inside local_getattro/local_setattro,
and force the operations to be done on the actual dict returned by
_ldict()?

Thanks,

~Ben
Index: Modules/threadmodule.c
===
--- Modules/threadmodule.c	(revision 66050)
+++ Modules/threadmodule.c	(working copy)
@@ -278,7 +278,9 @@
 return NULL;
 		}
 
-		Py_CLEAR(self->dict);
+		while (self->dict != NULL) {
+			Py_CLEAR(self->dict);
+		}
 		Py_INCREF(ldict);
 		self->dict = ldict; /* still borrowed */
 
@@ -297,7 +299,9 @@
 	/* The call to tp_init above may have caused another thread to run.
 	   Install our ldict again. */
 	if (self->dict != ldict) {
-		Py_CLEAR(self->dict);
+		while (self->dict != NULL) {
+			Py_CLEAR(self->dict);
+		}
 		Py_INCREF(ldict);
 		self->dict = ldict;
 	}
___
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] confusing exec error message in 3.0

[Georg Brandl]

Fredrik Lundh schrieb:
> (using 3.0a4)
> 
>  >>> exec(open("file.py"))
> Traceback (most recent call last):
>File "", line 1, in 
> TypeError: exec() arg 1 must be a string, file, or code object, not 
> TextIOWrapper
> 
> so what's "file" referring to here?
> 
> (the above works under 2.5, of course)

See http://bugs.python.org/issue1762972 -- it has been decided to drop
that possibility.

I've a patch that fixes the wrong error message in 
http://bugs.python.org/issue3706.

Georg

___
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] confusing exec error message in 3.0

[Fredrik Lundh]

Fredrik Lundh wrote:


(using 3.0a4)


ahem.  I could have sworn that I installed a beta, but I guess the 
Windows builds weren't fully synchronized when I did that.  I still get 
the same error after updating to 3.0b2, though.


(the download page still says "This is an alpha release", btw.)



___
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] confusing exec error message in 3.0

[Fredrik Lundh]

(using 3.0a4)

>>> exec(open("file.py"))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: exec() arg 1 must be a string, file, or code object, not 
TextIOWrapper


so what's "file" referring to here?

(the above works under 2.5, of course)



___
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] subprocess insufficiently platform-independent?

[Fredrik Lundh]

Curt Hagenlocher wrote:


I've found the documentation for CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty
reliable.  And the mention of a ".com" in the docs suggests that the
description has been around for a while...


And I just described it as pretty vague ;-)

Reading it again, I realize that I completely missed the part that says:

"If the file name does not contain an extension, .exe is appended. 
Therefore, if the file name extension is .com, this parameter must 
include the .com extension. If the file name ends in a period (.) with 
no extension, or if the file name contains a path, .exe is not appended."




___
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] subprocess insufficiently platform-independent?

[Fredrik Lundh]

Guido van Rossum wrote:


I can't reproduce this as described.


Which Windows version? This sounds like one of those things that could
well vary by Windows version; if it works for you in Vista it may well
be broken in XP. It could also vary by other setup parameters besides
PATHEXT.


It works the same way on XP, at least:

>>> import subprocess
>>> cmd = ['svn', 'ls', '.']
>>> subprocess.call(cmd, shell=False)
svn: '.' is not a working copy
1

According to the MS docs, CreateProcess works the same way on at least 
2K, XP and Vista.  The documentation is a bit vague (as usual), but it 
contains an example that implies that CreateProcess always adds ".exe" 
if not already there, and that you need to use the command interpreter 
(that is, shell=True) if you want to run something that's not a Windows 
executable module (e.g. a batch file).




___
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] the explicit self

[Fredrik Lundh]

Kilian Klimek wrote:

Saying "your method must accept an extra parameter (which most people 
call 'self') that carries all object attributes" is hardly any more 
explicit then saying "there is a special variable (which is always named 
'this') that carries all object attributes".


in this context, implicit and explicit refers to the code, not the 
documentation.




___
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] subprocess insufficiently platform-independent?

[Curt Hagenlocher]

On Wed, Aug 27, 2008 at 9:43 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond <[EMAIL PROTECTED]> wrote:
>>>
>>> Then it works on Linux, but fails on Windows because it does not
>>> perform the Windows %PATHEXT% search that allows it to find that
>>> "svn.exe" is the actual executable to be invoked.
>>
>> I can't reproduce this as described.
>
> Which Windows version? This sounds like one of those things that could
> well vary by Windows version; if it works for you in Vista it may well
> be broken in XP. It could also vary by other setup parameters besides
> PATHEXT.

When passing the executable name to CreateProcess via the
lpCommandLine parameter, PATH is considered but PATHEXT is ignored.
The only extension that's automatically appended is ".exe", and only
if no other extension is present. This has been true for as long as I
can remember.

I've found the documentation for CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty
reliable.  And the mention of a ".com" in the docs suggests that the
description has been around for a while...

--
Curt Hagenlocher
[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] subprocess insufficiently platform-independent?

[Guido van Rossum]

On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond <[EMAIL PROTECTED]> wrote:
> Guido quotes a colleague:
>
>> """
>> Given a straightforward command list like:
>>
>> cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']
>>
>> You apparently cannot pass this list to any subprocess function
>> (subprocess.call() or otherwise) with a set of arguments that allow it
>> to "just work" on both Windows and non-Windows systems.
>>
>> If you call:
>>
>> subprocess.call(cmd, shell=False)
>>
>> Then it works on Linux, but fails on Windows because it does not
>> perform the Windows %PATHEXT% search that allows it to find that
>> "svn.exe" is the actual executable to be invoked.
>
> I can't reproduce this as described.

Which Windows version? This sounds like one of those things that could
well vary by Windows version; if it works for you in Vista it may well
be broken in XP. It could also vary by other setup parameters besides
PATHEXT.

 subprocess.call(['svn', 'ls'], shell=False)
> svn: '.' is not a working copy
> 1
>
> The reason this works is that Windows itself (CreateProcess) has support
> both for implied '.exe' extensions and searching $PATH.  Thus, PATHEXT
> handling isn't required for executables.
>
> I *can* reproduce with another extension - eg, 'svn.py' - for this test I
> had a 'foo.py' on my PATH (but not in the cwd), and .py in PATHEXT.
>
 import subprocess
 subprocess.call(['foo'], shell=False)
> ... fails
 subprocess.call(['foo'], shell=True)
> Hello
> 0
>
> So I can't see this problem for 'svn.exe' and at face value the behaviour on
> Windows looks quite correct - you *do* need the shell for this functionality
> on Windows (in the same way you would to execute a .bat file, for example)
>
>> If you call:
>>
>> subprocess.call(cmd, shell=True)
>>
>> Then it works on Windows (it finds the "svn.exe" executable), but it
>> fails on Linux because it *only* executes the first argument in the
>> list ("svn") and does not pass the remaining arguments in the list to
>> the "svn" invocation.
>
> It sounds like in this particular example at least, this behaviour on Linux
> is the problem?

I think so yes.

-- 
--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] Things to Know About Super

[Michele Simionato]

On Wed, Aug 27, 2008 at 4:30 PM, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Maybe you could help me understand this by giving a fully executable
> Python snippet using __bases__[0] instead of the hypothetical
> __base__?

Sorry Alex, I have the fully functional snippet but evidently I have
sent some other blurb instead (it was early in the morning)
It is on my machine at home and now I am at work, so have patience ;)

 Michele
___
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] Things to Know About Super

[Alex Martelli]

On Tue, Aug 26, 2008 at 10:24 PM, Michele Simionato
<[EMAIL PROTECTED]> wrote:
   ...
> .. code-block:: python
>
>  def include_mixin(mixin, cls): # could be extended to use more mixins
> # traits as in Squeak take the precedence over the base class
> dic = vars(mixin).copy() # could be extended to walk the ancestors
> return type(mixin.__name__ + cls.__name__, (cls,),  dic)

I don't see any use of this in your following example so I assume
you're introducing it just to be able to say that:

> In the fictional world there is not need for super since
> all hierarchies are linear and you can just call the base class;

Nevertheless I must be missing something in the following example:

> FrameworkMeta could have been written as
>
> .. code-block:: python
>
>  class FrameworkMeta2(type):
>def __new__(mcl, name, bases, dic):
>print "Adding framework features to %s" % name
>return type.__new__(mcl, name, bases, dic)
>
>
> and DebugMetas as
>
> .. code-block:: python
>
>  class DebugMeta2(type):
>def __new__(mcl, name, bases, dic):
>print "Adding debugging features to %s" % name
>return mcl.__base__.__new__(mcl, name, bases, dic)
>
>
> Notice that DebugMeta2 is performing a sort of cooperative call here
> (``mcl.__base__.__new__``) but dead simple since there is just one base class.
>
> The analogous of FrameworkClass can be defined as
>
 class FrameworkClass2(object):
> ... __metaclass__ = FrameworkMeta2
> Adding framework features to FrameworkClass2
>
> and the analogous of DebugFrameworkClass as
>
 class DebugFrameworkClass2(FrameworkClass2):
> ... __metaclass__ = DebugFrameworkMeta2

What's DebugFrameworkMeta2?  I assume it's some kind of mix but I
don't see it defined anywhere so I'm having to guess.

> Adding debugging features to DebugFrameworkClass2
> Adding framework features to DebugFrameworkClass2

But where does DebugMeta2 get injected or otherwise get into the
picture in this example, so that the "Adding debugging features" print
executes?  I don't see any code in your example that performs this
injection.

Maybe you're missing a key bit where you build DebugFrameworkMeta2 by
using that example include_mixin you have?

I'd like to understand what, in this example, removes the apparent
"fragility" (or, lack of flexibility) where DebugMeta2 specifically
uses mcl.__base__ -- IOW, if I have another "mixin metaclass" just
like DebugMeta2 but called (say) RemotableMeta which does a print
"Adding remoting features" and then also calls
mcl.__base__.__new__(mcl ... just like DebugMeta2, what gets both of
their __new__ methods called in the right order?

Maybe you could help me understand this by giving a fully executable
Python snippet using __bases__[0] instead of the hypothetical
__base__?


A;ex
___
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] the explicit self

[Kilian Klimek]

On Wed, Aug 27, 2008 at 9:14 AM, Cesare Di Mauro
<[EMAIL PROTECTED]>wrote:

> On 27 agu 2008 at 08:46:15, Kilian Klimek <[EMAIL PROTECTED]>
> wrote:
>
> > Hello,
> >
> > i know this has been discusses very much, i'm sorry,
> > but i can't help it. In a nutshell, the proposal is as
> > follows:
> >
> > 1. Self remains explicit (like it is now).
> > 2. if a class is a subclass of a special class, e.g.
> >named 'selfless', the self parameter is not required
> >and a special variable, named 'this' is provided.
> >
> >
> > For example:
> >
> > class Foo (selfless):
> > def __init__ (x, y):
> > this.x = x
> > ...
> >
> > A patch for 3.0b3 implementing this can be found at
> > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff
> >
> > regards,
> > Kilian Klimek
> >
>
> I disagree. From "The Zen of Python":
>
> Explicit is better than implicit.


no point in discussing this, but ...

someone else emailed me this one too and i don't see the point: writing down
'self' as the first paramenter of your method does not make it any more
explicit what it means. (If you want to consider readability: even worse,
you can name it whatever you want).

Saying "your method must accept an extra parameter (which most people call
'self') that carries all object attributes" is hardly any more explicit then
saying "there is a special variable (which is always named 'this') that
carries all object attributes".


>
> Readability counts.
> Special cases aren't special enough to break the rules.
> There should be one-- and preferably only one --obvious way to do it.
>
> Cheers,
> Cesare
>
___
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] Things to Know About Super

[M.-A. Lemburg]

On 2008-08-27 09:54, Greg Ewing wrote:
> Do you have a real-life example of this where multiple
> inheritance is actually used?
> 
> A non-contrived example or two would be a good thing to
> have in tutorials etc. where super() is discussed. It
> would help to convey the kinds of situations in which
> use of super() is and is not appropriate.

The typical use is in mixin classes that can be used to
add functionality to base classes, something you often find
in application frameworks, e.g.

class NewComponent(Feature1Mixin, Feature2Mixin, BaseComponent):
   ...

If the mixin classes have to override one of the methods defined
in BaseComponent, then they must pay attention to all other mixin
classes used to define the NewComponent.

Without super() (or some other mechanism of accessing the base
method, like e.g. mxTools' basemethod() for classic classes), the
mixins could potentially override methods defined by other mixin
classes which would then not get called.

As example, think of a typical application server method

def process_request(self, request):
...

To work properly, each implementation of the method in the mixin classes
and base class will have to be called - in the order they were defined
in the class definition.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] the explicit self

[Michael Foord]

Maciej Fijalkowski wrote:

You can provide selfless class as a class with special metaclass that
overloads __new__ and changes signature of each method. Not sure how
good is this, but requires no changes to the language and will work as
you want.

  


Are you advocating this Maciej? ;-)

There's an example that does this here:

http://www.voidspace.org.uk/python/articles/metaclasses.shtml#the-selfless-metaclass

Michael


Cheers,
fijal

On Wed, Aug 27, 2008 at 8:46 AM, Kilian Klimek
<[EMAIL PROTECTED]> wrote:
  

Hello,

i know this has been discusses very much, i'm sorry,
but i can't help it. In a nutshell, the proposal is as
follows:

1. Self remains explicit (like it is now).
2. if a class is a subclass of a special class, e.g.
   named 'selfless', the self parameter is not required
   and a special variable, named 'this' is provided.


For example:

class Foo (selfless):
def __init__ (x, y):
this.x = x
...

A patch for 3.0b3 implementing this can be found at
http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff

regards,
Kilian Klimek

___
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/fijall%40gmail.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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.resolverhacks.net/
http://.theotherdelia.co.uk/

___
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] the explicit self

[Maciej Fijalkowski]

You can provide selfless class as a class with special metaclass that
overloads __new__ and changes signature of each method. Not sure how
good is this, but requires no changes to the language and will work as
you want.

Cheers,
fijal

On Wed, Aug 27, 2008 at 8:46 AM, Kilian Klimek
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> i know this has been discusses very much, i'm sorry,
> but i can't help it. In a nutshell, the proposal is as
> follows:
>
> 1. Self remains explicit (like it is now).
> 2. if a class is a subclass of a special class, e.g.
>named 'selfless', the self parameter is not required
>and a special variable, named 'this' is provided.
>
>
> For example:
>
> class Foo (selfless):
> def __init__ (x, y):
> this.x = x
> ...
>
> A patch for 3.0b3 implementing this can be found at
> http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff
>
> regards,
> Kilian Klimek
>
> ___
> 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/fijall%40gmail.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] Things to Know About Super

[Greg Ewing]

Phillip J. Eby wrote:

ISTR pointing out on more than one occasion that a major use case for 
co-operative super() is in the implementation of metaclasses.  The 
__init__ and __new__ signatures are fixed, multiple inheritance is 
possible, and co-operativeness is a must


Do you have a real-life example of this where multiple
inheritance is actually used?

A non-contrived example or two would be a good thing to
have in tutorials etc. where super() is discussed. It
would help to convey the kinds of situations in which
use of super() is and is not appropriate.

--
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] the explicit self

[Georg Brandl]

Kilian Klimek schrieb:
> Hello,
> 
> i know this has been discusses very much, i'm sorry,
> but i can't help it. In a nutshell, the proposal is as
> follows:
> 
> 1. Self remains explicit (like it is now).
> 2. if a class is a subclass of a special class, e.g.
>named 'selfless', the self parameter is not required
>and a special variable, named 'this' is provided.
> 
> 
> For example:
> 
> class Foo (selfless):
> def __init__ (x, y):
> this.x = x
> ...
> 
> A patch for 3.0b3 implementing this can be found at
> http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff

Just a note about the patch: it introduces the implicit "this" by
injecting it into the function's globals. Due to how Python looks
up globals and locals, this will be much slower than having a local
called "self".

Georg

___
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] the explicit self

[Terry Reedy]

Kilian Klimek wrote:


i know this has been discusses very much,


There is a related discussion on python-ideas right now and was a long 
discussion on python-list/c.l.p within the last month.  And the month 
before.   Either would have been the place to post this.



i'm sorry, but i can't help it.


???




___
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] the explicit self

[Gary Herron]

Kilian Klimek wrote:

Hello,

i know this has been discusses very much, i'm sorry,
but i can't help it. In a nutshell, the proposal is as
follows:

1. Self remains explicit (like it is now).
2. if a class is a subclass of a special class, e.g.
   named 'selfless', the self parameter is not required
   and a special variable, named 'this' is provided.


For example:

class Foo (selfless):
def __init__ (x, y):
this.x = x
...

A patch for 3.0b3 implementing this can be found at
http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff 



Why not just do this?


class Foo:
   def __init__ (this, x, y):
   this.x = x


It's fewer characters, it gets rid of the "self" you seem to dread, and 
it requires no patches or changes of any kind to Python.  And most 
importantly, has no need to introduce any "magic" into the language.


Gary Herron




regards,
Kilian Klimek


___
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/gherron%40islandtraining.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] the explicit self

[Cesare Di Mauro]

On 27 agu 2008 at 08:46:15, Kilian Klimek <[EMAIL PROTECTED]> wrote:

> Hello,
>
> i know this has been discusses very much, i'm sorry,
> but i can't help it. In a nutshell, the proposal is as
> follows:
>
> 1. Self remains explicit (like it is now).
> 2. if a class is a subclass of a special class, e.g.
>named 'selfless', the self parameter is not required
>and a special variable, named 'this' is provided.
>
>
> For example:
>
> class Foo (selfless):
> def __init__ (x, y):
> this.x = x
> ...
>
> A patch for 3.0b3 implementing this can be found at
> http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff
>
> regards,
> Kilian Klimek
> 

I disagree. From "The Zen of Python":

Explicit is better than implicit.
Readability counts.
Special cases aren't special enough to break the rules.
There should be one-- and preferably only one --obvious way to do it.

Cheers,
Cesare
___
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