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
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 wh
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
>> > TypeErro
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
> >
> >
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
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
___
Pyth
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
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,
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);
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 c
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.)
_
(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)
___
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 ;-
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 t
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
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
>>> "
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
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 som
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 ext
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:
> >
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 whic
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
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 PROTECTE
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 e
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 parame
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
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 require
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
28 matches
Mail list logo
