date:20050104

On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote:
Tim Peters <[EMAIL PROTECTED]> wrote:
Guido wrote:
Let's get rid of unbound methods. When class C defines a method
[snip]
Really?  Unbound methods are used most often (IME) to call a
base-class method from a subclass, like my_base.the_method(self, ...).
 It's especially easy to forget to write `self, ` there, and the
exception msg then is quite focused because of that extra bit of type
checking.  Otherwise I expect we'd see a more-mysterious
AttributeError or TypeError when the base method got around to trying
to do something with the bogus `self` passed to it.
Agreed.  While it seems that super() is the 'modern paradigm' for this,
I have been using base.method(self, ...) for years now, and have been
quite happy with it.  After attempting to convert my code to use the
super() paradigm, and having difficulty, I discovered James Knight's
"Python's Super Considered Harmful" (available at
http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I
discovered how super really worked (I should have read the documention
in the first place), and reverted my changes to the base.method 
version.
How does removing the difference between unmount methods and 
base.method(self, ...) break anything at all if it was correct code in 
the first place?  As far as I can tell, all it does is remove any 
restriction on what "self" is allowed to be.

On another note -
I don't agree with the "super considered harmful" rant at all.  Yes, 
when you're using __init__ and __new__ of varying signatures in a 
complex class hierarchy, initialization is going to be one hell of a 
problem -- no matter which syntax you use.  All super is doing is 
taking the responsibility of calculating the MRO away from you, and it 
works awfully well for the general case where a method of a given name 
has the same signature and the class hierarchies are not insane.  If 
you have a class hierarchy where this is a problem, it's probably 
pretty fragile to begin with, and you should think about making it 
simpler.

-bob
___
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] Let's get rid of unbound methods

2005-01-04 Thread Tim Peters

[Tim Peters]
>> ...  Unbound methods are used most often (IME) to call a
>> base-class method from a subclass, like
>> my_base.the_method(self, ...).
>>  It's especially easy to forget to write `self, ` there, and the
>> exception msg then is quite focused because of that extra bit of
>> type checking.  Otherwise I expect we'd see a more-mysterious
>> AttributeError or TypeError when the base method got around to
>> trying to do something with the bogus `self` passed to it.

[Josiah Carlson]
> Agreed.

Well, it's not that easy to agree with.  Guido replied that most such
cases would raise an argument-count-mismatch exception instead.  I
expect that's because he stopped working on Zope code, so actually
thinks it's odd again to see a gazillion methods like:

class Registerer(my_base):
def register(*args, **kws):
my_base.register(*args, **kws)

I bet he even presumes that if you chase such chains long enough,
you'll eventually find a register() method *somewhere* that actually
uses its arguments .

> While it seems that super() is the 'modern pradigm' for this,
> I have been using base.method(self, ...) for years now, and have
> been quite happy with it.  After attempting to convert my code to
> use the super() paradigm, and having difficulty, I discovered James
> Knight's "Python's Super Considered Harmful" (available at
> http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I
> discovered how super really worked (I should have read the
> documention in the first place), and reverted my changes to the
> base.method version.

How did super() get into this discussion?  I don't think I've ever
used it myself, but I avoid fancy inheritance graphs in "my own" code,
so can live with anything.

> I could live with it too, but I would probably use an equivalent of the
> following (with actual type checking):
>
> def mysuper(typ, obj):
>lm = list(o.__class__.__mro__)
>indx = lm.index(typ)
>if indx == 0:
>return obj
>return super(lm[indx-1], obj)
>
> All in all, I'm -0.  I don't desire to replace all of my base.method
> with mysuper(base, obj).method, but if I must sacrifice
> convenience for the sake of making Python 2.5's implementation
> simpler, I guess I'll deal with it. My familiarity with grep's regular
> expressions leaves something to be desired, so I don't know how
> often base.method(self,...) is or is not used in the standard library.

I think there may be a misunderstanding here.  Guido isn't proposing
that base.method(self, ...) would stop working -- it would still work
fine.  The result of base.method would still be a callable object:  it
would no longer be of an "unbound method" type (it would just be a
function), and wouldn't do special checking on the first argument
passed to it anymore, but base.method(self, ...) would still invoke
the base class method.  You wouldn't need to rewrite anything (unless
you're doing heavy-magic introspection, picking callables apart).
___
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] super() harmful?

[Josiah]
> Agreed.  While it seems that super() is the 'modern paradigm' for this,
> I have been using base.method(self, ...) for years now, and have been
> quite happy with it.  After attempting to convert my code to use the
> super() paradigm, and having difficulty, I discovered James Knight's
> "Python's Super Considered Harmful" (available at
> http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I
> discovered how super really worked (I should have read the documention
> in the first place), and reverted my changes to the base.method version.

I think that James Y Knight's page misrepresents the issue. Quoting:

"""
Note that the __init__ method is not special -- the same thing happens
with any method, I just use __init__ because it is the method that most
often needs to be overridden in many classes in the hierarchy.
"""

But __init__ *is* special, in that it is okay for a subclass __init__
(or __new__) to have a different signature than the base class
__init__; this is not true for other methods. If you change a regular
method's signature, you would break Liskov substitutability (i.e.,
your subclass instance wouldn't be acceptable where a base class
instance would be acceptable).

Super is intended for use that are designed with method cooperation in
mind, so I agree with the best practices in James's Conclusion:

"""
* Use it consistently, and document that you use it,
  as it is part of the external interface for your class, like it or not.
* Never call super with anything but the exact arguments you received,
  unless you really know what you're doing.
* When you use it on methods whose acceptable arguments can be
  altered on a subclass via addition of more optional arguments,
  always accept *args, **kw, and call super like
  "super(MyClass, self).currentmethod(alltheargsideclared, *args,
**kwargs)".
  If you don't do this, forbid addition of optional arguments in subclasses.
* Never use positional arguments in __init__ or __new__.
  Always use keyword args, and always call them as keywords,
  and always pass all keywords on to super.
"""

But that's not the same as calling it harmful. :-(

-- 
--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] Let's get rid of unbound methods

2005-01-04 Thread Josiah Carlson

Tim Peters <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > Let's get rid of unbound methods. When class C defines a method
[snip]
> Really?  Unbound methods are used most often (IME) to call a
> base-class method from a subclass, like my_base.the_method(self, ...).
>  It's especially easy to forget to write `self, ` there, and the
> exception msg then is quite focused because of that extra bit of type
> checking.  Otherwise I expect we'd see a more-mysterious
> AttributeError or TypeError when the base method got around to trying
> to do something with the bogus `self` passed to it.

Agreed.  While it seems that super() is the 'modern paradigm' for this,
I have been using base.method(self, ...) for years now, and have been
quite happy with it.  After attempting to convert my code to use the
super() paradigm, and having difficulty, I discovered James Knight's
"Python's Super Considered Harmful" (available at
http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I
discovered how super really worked (I should have read the documention
in the first place), and reverted my changes to the base.method version.

> I could live with that, though.

I could live with it too, but I would probably use an equivalent of the
following (with actual type checking):

def mysuper(typ, obj):
lm = list(o.__class__.__mro__)
indx = lm.index(typ)
if indx == 0:
return obj
return super(lm[indx-1], obj)

All in all, I'm -0.  I don't desire to replace all of my base.method
with mysuper(base, obj).method, but if I must sacrifice convenience for
the sake of making Python 2.5's implementation simpler, I guess I'll
deal with it. My familiarity with grep's regular expressions leaves
something to be desired, so I don't know how often base.method(self,...) is
or is not used in the standard library.

 - 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] Please help complete the AST branch

2005-01-04 Thread Kurt B. Kaiser

Guido van Rossum <[EMAIL PROTECTED]> writes:

> I'd be fine with keeping this on python-dev too.

Maybe tag the Subject: with [AST] when starting a thread?

-- 
KBK
___
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] 2.3.5 schedule, and something I'd like to get in

On Jan 4, 2005, at 6:54 PM, Martin v. Löwis wrote:
Jack Jansen wrote:
First question: what is the Python 2.3.5 release schedule and who is  
responsible?
Last I heard it is going to be released "in January", and Anthony  
Baxter
is the release manager.

Second question: I thought this info was in a PEP somewhere, but I  
could only find PEPs on major releases, should I have found this info  
somewhere?
By following python-dev, or in a python-dev summary, e.g.
http://www.python.org/dev/summary/2004-11-01_2004-11-15.html
The problem we're trying to solve is that due to the way Apple's  
framework architecture works newer versions of frameworks are  
preferred (at link time, and sometimes even at runtime) over older  
ones.
Can you elaborate on that somewhat? According to
http://developer.apple.com/documentation/MacOSX/Conceptual/ 
BPFrameworks/Concepts/VersionInformation.html

there are major and minor versions of frameworks. I would think that
every Python minor (2.x) release should produce a new major framework
version of the Python framework. Then, there would be no problem.
Why does this not work?
It doesn't for reasons I care not to explain in depth, again.  Search  
the pythonmac-sig archives for longer explanations.  The gist is that  
you specifically do not want to link directly to the framework at all  
when building extensions.  These patches are required to do that  
correctly.

I think this is all safe, and these patches shouldn't affect any  
system other than MacOSX, but I'm a bit reluctant to fiddle with the  
build procedure for a micro-release, so that's why I'm asking.
This is ultimately for the release manager to decide. My personal
feeling is that it is ok to fiddle with the build procedure. I'm
more concerned that the approach taken might be "wrong", in the
sense that it uses a stack of hacks and work-arounds for problems
which Apple envisions to be solved differently. That would be bad,
because it might make an implementation of the "proper" solution
more difficult.
This is not the wrong way to do it.
-bob
___
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] 2.3.5 schedule, and something I'd like to get in

2005-01-04 Thread "Martin v. Löwis"

Jack Jansen wrote:
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Last I heard it is going to be released "in January", and Anthony Baxter
is the release manager.
Second question: I thought this info was in a PEP somewhere, but I could
only find PEPs on major releases, should I have found this info somewhere?
By following python-dev, or in a python-dev summary, e.g.
http://www.python.org/dev/summary/2004-11-01_2004-11-15.html
The problem we're trying to solve is that due to the way Apple's
framework architecture works newer versions of frameworks are preferred
(at link time, and sometimes even at runtime) over older ones.
Can you elaborate on that somewhat? According to
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
there are major and minor versions of frameworks. I would think that
every Python minor (2.x) release should produce a new major framework
version of the Python framework. Then, there would be no problem.
Why does this not work?
I think this is all safe, and these patches shouldn't affect any system
other than MacOSX, but I'm a bit reluctant to fiddle with the build
procedure for a micro-release, so that's why I'm asking.
This is ultimately for the release manager to decide. My personal
feeling is that it is ok to fiddle with the build procedure. I'm
more concerned that the approach taken might be "wrong", in the
sense that it uses a stack of hacks and work-arounds for problems
which Apple envisions to be solved differently. That would be bad,
because it might make an implementation of the "proper" solution
more difficult.
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] Let's get rid of unbound methods

On Jan 4, 2005, at 6:01 PM, Jack Jansen wrote:
On 4-jan-05, at 19:28, Guido van Rossum wrote:
 The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple of times. If I remember correctly I was 
calling methods of something that was supposed to be a mixin class but 
I forgot to actually list the mixin as a base. But I don't think 
that's a serious enough issue alone to keep the unbound method type.

But I'm more worried about losing the other information in an unbound 
method, specifically im_class. I would guess that info is useful to 
class browsers and such, or are there other ways to get at that?
For a class browser, presumably, you would start at the class and then 
find the methods.  Starting from some class and walking the mro, you 
can inspect the dicts along the way and you'll find everything and know 
where it came from.

-bob
___
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] 2.3.5 schedule, and something I'd like to get in

First question: what is the Python 2.3.5 release schedule and who is 
responsible?

Second question: I thought this info was in a PEP somewhere, but I 
could only find PEPs on major releases, should I have found this info 
somewhere?

And now the question that matters: there's some stuff I'd really like 
to get into 2.3.5, but it involves changes to configure, the Makefile 
and distutils, so because it's fairly extensive I thought I'd ask 
before just committing it.

The problem we're trying to solve is that due to the way Apple's 
framework architecture works newer versions of frameworks are preferred 
(at link time, and sometimes even at runtime) over older ones. That's 
fine for most uses of frameworks, but not when linking a Python 
extension against the Python framework: if you build an extension with 
Python 2.3 to later load it into 2.3 you don't want that framework to 
be linked against 2.4.

Now there's a way around this, from MacOSX 10.3 onwards, and that is 
not to link against the framework at all, but link with "-undefined 
dynamic_lookup". This will link the extension in a way similar to what 
other Unix systems do: any undefined externals are looked up when the 
extension is dynamically loaded. But because this feature only works 
with the dynamic loader from 10.3 or later you must have the 
environment variable MACOSX_DEPLOYMENT_TARGET set to 10.3 or higher 
when you build the extension, otherwise the linker will complain.

We've solved this issue for the trunk and we can solve it for 2.4.1: if 
MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to 
10.3. Moreover, when it is 10.3 or higher (possibly after being forced) 
we use the dynamic_lookup way of linking extensions. We also record the 
value of MACOSX_DEPLOYMENT_TARGET in the Makefile, and distutils picks 
it up later and sets the environment variable again.

We even have a hack to fix Apple-installed Python 2.3 in place by 
mucking with lib/config/Makefile, which we can do because 
Apple-installed Python 2.3 will obviously only be run on 10.3. And we 
check whether this hack is needed when you install a later Python 
version on 10.3.

That leaves Python 2.3.5 itself. The best fix here would be to backport 
the 2.4.1 solution: configure.in 1.456 and 1.478, 
distutils/sysconfig.py 1.59 and 1.62, Makefile.pre.in 1.144. Note that 
though the build procedure for extensions will change it doesn't affect 
binary compatibility: both types of extensions are loadable by both 
types of interpreters.

I think this is all safe, and these patches shouldn't affect any system 
other than MacOSX, but I'm a bit reluctant to fiddle with the build 
procedure for a micro-release, so that's why I'm asking.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

First question: what is the Python 2.3.5 release schedule and who is 
responsible?

Second question: I thought this info was in a PEP somewhere, but I 
could only find PEPs on major releases, should I have found this info 
somewhere?

And now the question that matters: there's some stuff I'd really like 
to get into 2.3.5, but it involves changes to configure, the Makefile 
and distutils, so because it's fairly extensive I thought I'd ask 
before just committing it.

The problem we're trying to solve is that due to the way Apple's 
framework architecture works newer versions of frameworks are preferred 
(at link time, and sometimes even at runtime) over older ones. That's 
fine for most uses of frameworks, but not when linking a Python 
extension against the Python framework: if you build an extension with 
Python 2.3 to later load it into 2.3 you don't want that framework to 
be linked against 2.4.

Now there's a way around this, from MacOSX 10.3 onwards, and that is 
not to link against the framework at all, but link with "-undefined 
dynamic_lookup". This will link the extension in a way similar to what 
other Unix systems do: any undefined externals are looked up when the 
extension is dynamically loaded. But because this feature only works 
with the dynamic loader from 10.3 or later you must have the 
environment variable MACOSX_DEPLOYMENT_TARGET set to 10.3 or higher 
when you build the extension, otherwise the linker will complain.

We've solved this issue for the trunk and we can solve it for 2.4.1: if 
MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to 
10.3. Moreover, when it is 10.3 or higher (possibly after being forced) 
we use the dynamic_lookup way of linking extensions. We also record the 
value of MACOSX_DEPLOYMENT_TARGET in the Makefile, and distutils picks 
it up later and sets the environment variable again.

We even have a hack to fix Apple-installed Python 2.3 in place by 
mucking with lib/config/Makefile, which we can do because 
Apple-installed Python 2.3 will obviously only be run on 10.3. And we 
check whether this hack is needed when you install a later Python 
version on 10.3.

That leaves Python 2.3.5 itself. The best fix here would be to backport 
the 2.4.1 solution: configure.in 1.456 and 1.478, 
distutils/sysconfig.py 1.59 and 1.62, Makefile.pre.in 1.144. Note that 
though the build procedure for extensions will change it doesn't affect 
binary compatibility: both types of extensions are loadable by both 
types of interpreters.

I think this is all safe, and these patches shouldn't affect any system 
other than MacOSX, but I'm a bit reluctant to fiddle with the build 
procedure for a micro-release, so that's why I'm asking.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Let's get rid of unbound methods

On 4-jan-05, at 19:28, Guido van Rossum wrote:
 The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple of times. If I remember correctly I was 
calling methods of something that was supposed to be a mixin class but 
I forgot to actually list the mixin as a base. But I don't think that's 
a serious enough issue alone to keep the unbound method type.

But I'm more worried about losing the other information in an unbound 
method, specifically im_class. I would guess that info is useful to 
class browsers and such, or are there other ways to get at that?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Please help complete the AST branch

2005-01-04 Thread Jeremy Hylton

Does anyone want to volunteer to integrate the current head to the
branch?  I think that's a pretty important near-term step.

Jeremy
___
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] Please help complete the AST branch

2005-01-04 Thread Brett C.

Jeff Epler wrote:
On Mon, Jan 03, 2005 at 06:02:52PM -0800, Brett C. wrote:
Although if someone can start sooner than by all means, go for it!
And obviously help would be great since it isn't a puny codebase
(4,000 lines so far for the CST->AST and AST->bytecode code).

And obviously knowing a little more about the AST branch would be
helpful for those considering helping.
Is there any relatively up-to-date document about ast-branch?  googling
about it turned up some pypy stuff from 2003, and I didn't look much
further.
Beyond the text file Python/compile.txt in CVS, nope.  I have tried to flesh 
that doc out as well as I could to explain how it all works.

If it doesn't answer all your questions then just ask here on python-dev (as 
the rest of this thread has seemed to agreed upon).  I will do my best to make 
sure any info that needs to work its way back into the doc gets checked in.

I just built the ast-branch for fun, and "make test" mostly worked.
8 tests failed:
test_builtin test_dis test_generators test_inspect test_pep263
test_scope test_symtable test_trace
6 skips unexpected on linux2:
test_csv test_hotshot test_bsddb test_parser test_logging
test_email
I haven't looked at any of the failures in detail, but at least
test_bsddb is due to missing development libs on this system
One more thing:  The software I work on by day has python scripting.
One part of that functionality is a tree display of a script.  I'm not
actively involved with this part of the software (yet).  Any comments on
whether ast-branch could be construed as helping make this kind of
functionality work better, faster, or easier?  The code we use currently
is based on a modified version of the parser which includes comment
information, so we need to be aware of changes in this area anyhow.
If by tree you mean execution paths, then yes, eventually.  When the back-end 
is finished the hope is to be able to export the AST to Python objects and thus 
have it usable in Python.  You could use the AST representation to display your 
tree.

-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

Re: [Python-Dev] Please help complete the AST branch

2005-01-04 Thread Brett C.

Alex Martelli wrote:
On 2005 Jan 04, at 17:17, Jeremy Hylton wrote:
That's fine with me.  We had taken it to the compiler-sig when it
wasn't clear there was interest in the ast branch :-).

Speaking for myself, I have a burning interest in the AST branch (though 
I can't seem to get it correctly downloaded so far, I guess it's just my 
usual CVS-clumsiness and I'll soon find out what I'm doing wrong & fix 
it)
See http://www.python.org/dev/devfaq.html#how-can-i-check-out-a-tagged-branch 
on how to do a checkout of a tagged branch.

-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

Re: [Python-Dev] Let's get rid of unbound methods

2005-01-04 Thread Phillip J. Eby

At 11:40 AM 1/4/05 -0800, Guido van Rossum wrote:
[Jim]
> We'll still need unbound builtin methods, so the concept won't
> go away. In fact, the change would mean that the behavior between
> builtin methods and python methods would become more inconsistent.
Actually, unbound builtin methods are a different type than bound
builtin methods:
>>> type(list.append)

>>> type([].append)

>>>
Compare this to the same thing for a method on a user-defined class:
>>> type(C.foo)

>>> type(C().foo)

(The 'instancemethod' type knows whether it is a bound or unbound
method by checking whether im_self is set.)
[Phillip]
> Code that currently does 'aClass.aMethod.im_func' in order to access the
> function object would break, as would code that inspects 'im_self' to
> determine whether a method is a class or instance method.  (Although code
> of the latter sort would already break with static methods, I suppose.)
Right. (But I think you're using the terminology in a cunfused way --
im_self distinguishes between bould and unbound methods. Class methods
are a different beast.)
IIUC, when you do 'SomeClass.aMethod', if 'aMethod' is a classmethod, then 
you will receive a bound method with an im_self of 'SomeClass'.  So, if you 
are introspecting items listed in 'dir(SomeClass)', this will be your only 
clue that 'aMethod' is a class method.  Similarly, the fact that you get an 
unbound method object if 'aMethod' is an instance method, allows you to 
distinguish it from a static method (if the object is a function).

That is, I'm saying that code that looks at the type and attributes of 
'aMethod' as retrieved from 'SomeClass' will now not be able to distinguish 
between a static method and an instance method, because both will return a 
function instance.

However, the 'inspect' module uses __dict__ rather than getattr to get at 
least some attributes, so it doesn't rely on this property.


I guess for backwards compatibility, function objects could implement
dummy im_func and im_self attributes (im_func returning itself and
im_self returning None), while issuing a warning that this is a
deprecated feature.
+1 on this part if the proposal goes through.
On the proposal as a whole, I'm -0, as I'm not quite clear on what this is 
going to simplify enough to justify the various semantic impacts such as 
upcalls, pickling, etc.  Method objects will still have to exist, so ISTM 
that this is only going to streamline the "__get__(None,type)" branch of 
functions' descriptor code, and the check for "im_self is None" in the 
__call__ of method objects.  (And maybe some eval loop shortcuts for 
calling methods?)

___
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] Let's get rid of unbound methods

2005-01-04 Thread Jp Calderone

On Tue, 4 Jan 2005 12:18:15 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>[me]
> > > Actually, unbound builtin methods are a different type than bound
> > > builtin methods:
> 
> [Jim]
> > Of course, but conceptually they are similar.  You would still
> > encounter the concept if you got an unbound builtin method.
> 
> Well, these are all just implementation details. They really are all
> just callables.
> 
> [Jp]
> >   This would make pickling (or any serialization mechanism) of
> > `Class.method' based on name next to impossible.  Right now, with
> > the appropriate support, this works:
> > 
> > >>> import pickle
> > >>> class Foo:
> > ... def bar(self): pass
> > ...
> > >>> pickle.loads(pickle.dumps(Foo.bar))
> > 
> > >>>
> > 
> >   I don't see how it could if Foo.bar were just a function object.
> 
> Is this a purely theoretical objection or are you actually aware of
> anyone doing this? Anyway, that approach is pretty limited -- how
> would you do it for static and class methods, or methods wrapped by
> other decorators?

  It's not a feature I often depend on, however I have made use of 
it on occassion.  Twisted's supports serializing unbound methods 
this way, primarily to enhance the useability of tap files (a feature 
whereby an application is configured by constructing a Python object 
graph and then pickled to a file to later be loaded and run).

  "Objection" may be too strong a word for my stance here, I just 
wanted to point out another potentially incompatible behavior change.
I can't think of any software which I cam currently developing or 
maintaining which benefits from this feature, it just seems 
unfortunate to further complicate the already unpleasant business 
of serialization.

  Jp
___
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] Let's get rid of unbound methods

[me]
> > Actually, unbound builtin methods are a different type than bound
> > builtin methods:

[Jim]
> Of course, but conceptually they are similar.  You would still
> encounter the concept if you got an unbound builtin method.

Well, these are all just implementation details. They really are all
just callables.

[Jp]
>   This would make pickling (or any serialization mechanism) of
> `Class.method' based on name next to impossible.  Right now, with
> the appropriate support, this works:
> 
> >>> import pickle
> >>> class Foo:
> ... def bar(self): pass
> ...
> >>> pickle.loads(pickle.dumps(Foo.bar))
> 
> >>>
> 
>   I don't see how it could if Foo.bar were just a function object.

Is this a purely theoretical objection or are you actually aware of
anyone doing this? Anyway, that approach is pretty limited -- how
would you do it for static and class methods, or methods wrapped by
other decorators?

-- 
--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] Let's get rid of unbound methods

2005-01-04 Thread Jp Calderone

On Tue, 04 Jan 2005 20:02:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote:
>On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >In my blog I wrote:
> > 
> > Let's get rid of unbound methods. When class C defines a method f, C.f
> > should just return the function object, not an unbound method that
> > behaves almost, but not quite, the same as that function object. The
> > extra type checking on the first argument that unbound methods are
> > supposed to provide is not useful in practice (I can't remember that
> > it ever caught a bug in my code) and sometimes you have to work around
> > it; it complicates function attribute access; and the overloading of
> > unbound and bound methods on the same object type is confusing. Also,
> > the type checking offered is wrong, because it checks for subclassing
> > rather than for duck typing.
> > 
> 
>   This would make pickling (or any serialization mechanism) of 
> `Class.method' based on name next to impossible.  Right now, with
> the appropriate support, this works:

  It occurs to me that perhaps I was not clear enough here.  

  What I mean is that it is possible to serialize unbound methods 
currently, because they refer to both their own name, the name of 
their class object, and thus indirectly to the module in which they 
are defined.

  If looking up a method on a class object instead returns a function, 
then the class is no longer knowable, and most likely the function will
not have a unique name which can be used to allow a reference to it to 
be serialized.

  In particular, I don't see how one will be able to write something 
equivalent to this:

import new, copy_reg, types

def pickleMethod(method):
return unpickleMethod, (method.im_func.__name__,
method.im_self,
method.im_class)

def unpickleMethod(im_name, im_self, im_class):
unbound = getattr(im_class, im_name)
if im_self is None:
return unbound
return new.instancemethod(unbound.im_func,
  im_self,
  im_class)

copy_reg.pickle(types.MethodType, 
pickleMethod, 
unpickleMethod)

  But perhaps I am just overlooking the obvious.

  Jp
___
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] Let's get rid of unbound methods

2005-01-04 Thread Jp Calderone

On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>In my blog I wrote:
> 
> Let's get rid of unbound methods. When class C defines a method f, C.f
> should just return the function object, not an unbound method that
> behaves almost, but not quite, the same as that function object. The
> extra type checking on the first argument that unbound methods are
> supposed to provide is not useful in practice (I can't remember that
> it ever caught a bug in my code) and sometimes you have to work around
> it; it complicates function attribute access; and the overloading of
> unbound and bound methods on the same object type is confusing. Also,
> the type checking offered is wrong, because it checks for subclassing
> rather than for duck typing.
> 

  This would make pickling (or any serialization mechanism) of 
`Class.method' based on name next to impossible.  Right now, with
the appropriate support, this works:

>>> import pickle
>>> class Foo:
... def bar(self): pass
... 
>>> pickle.loads(pickle.dumps(Foo.bar))

>>> 

  I don't see how it could if Foo.bar were just a function object.

  Jp
___
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] Let's get rid of unbound methods

2005-01-04 Thread Jim Fulton

Guido van Rossum wrote:
[Jim]
We'll still need unbound builtin methods, so the concept won't
go away. In fact, the change would mean that the behavior between
builtin methods and python methods would become more inconsistent.

Actually, unbound builtin methods are a different type than bound
builtin methods:
Of course, but conceptually they are similar.  You would still
encounter the concept if you got an unbound builtin method.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Let's get rid of unbound methods

2005-01-04 Thread Raymond Hettinger

[Guido van Rossum]
> > Let's get rid of unbound methods. 

+1



[Jim Fulton]
> duck typing?

Requiring a specific interface instead of a specific type.



[Guido]
> > Does anyone think this is a bad idea?
[Jim]
> It *feels* very disruptive to me, but I'm probably wrong.
> We'll still need unbound builtin methods, so the concept won't
> go away. In fact, the change would mean that the behavior between
> builtin methods and python methods would become more inconsistent.

The type change would be disruptive and guaranteed to break some code.
Also, it would partially breakdown the distinction between functions and
methods.

The behavior, on the other hand, would remain essentially the same (sans
type checking).



Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get rid of unbound methods

[Jim]
> We'll still need unbound builtin methods, so the concept won't
> go away. In fact, the change would mean that the behavior between
> builtin methods and python methods would become more inconsistent.

Actually, unbound builtin methods are a different type than bound
builtin methods:

>>> type(list.append)

>>> type([].append)

>>> 

Compare this to the same thing for a method on a user-defined class:

>>> type(C.foo)

>>> type(C().foo)


(The 'instancemethod' type knows whether it is a bound or unbound
method by checking whether im_self is set.)

[Phillip]
> Code that currently does 'aClass.aMethod.im_func' in order to access the
> function object would break, as would code that inspects 'im_self' to
> determine whether a method is a class or instance method.  (Although code
> of the latter sort would already break with static methods, I suppose.)

Right. (But I think you're using the terminology in a cunfused way --
im_self distinguishes between bould and unbound methods. Class methods
are a different beast.)

I guess for backwards compatibility, function objects could implement
dummy im_func and im_self attributes (im_func returning itself and
im_self returning None), while issuing a warning that this is a
deprecated feature.

[Tim]
> Really?  Unbound methods are used most often (IME) to call a
> base-class method from a subclass, like my_base.the_method(self, ...).
>  It's especially easy to forget to write `self, ` there, and the
> exception msg then is quite focused because of that extra bit of type
> checking.  Otherwise I expect we'd see a more-mysterious
> AttributeError or TypeError when the base method got around to trying
> to do something with the bogus `self` passed to it.

Hm, I hadn't thought ot this.

> I could live with that, though.

Most cases would be complaints about argument counts (it gets harier
when there are default args so the arg count is variable). Ironically,
I get those all the time these days due to the reverse error: using
super() but forgetting *not* to pass self!

> Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType
> is defined once and used once (believe it or not, in unittest.py).

But that might be because BoundMethodType is the same type object...

-- 
--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] Let's get rid of unbound methods

2005-01-04 Thread Jim Fulton

Phillip J. Eby wrote:
At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote:
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?

Code that currently does 'aClass.aMethod.im_func' in order to access the 
function object would break, as would code that inspects 'im_self' to 
determine whether a method is a class or instance method.  (Although 
code of the latter sort would already break with static methods, I 
suppose.)
Code of the latter sort wouldn't break with the change. We'd still
have bound methods.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Will ASTbranch compile on windows yet?

2005-01-04 Thread Tim Peters

[EMAIL PROTECTED]
> I submitted patch "[ 742621 ] ast-branch: msvc project sync" in
> the VC6.0 days.  There were some required changes to headers
> as well as the project files.  It had discouraged me in the past
> when Jeremy made calls for help on the astbranch and I wasn't
> even sure if the source was in a compilable state when I checked
> it out.  I'm sure it has discouraged other windows programmers
> as well.

I'd be surprised if it compiled on Windows now, as I don't think any
Windows users have been working on that branch.

At the last (2004) PyCon, I was going to participate in the annual AST
sprint again, but it was so far from working on Windows then I gave up
(and joined the close-bugs/patches sprint instead).

I don't have time to join the current crusade.  If there's pent-up
interest among Windows users, it would be good to say which
compiler(s) you can use, since I expect not everyone can deal with VC
7.1 (e.g., I think Raymond Hettinger is limited to VC 6; and you said
you worked up a VC 6 patch, but didn't say whether you could use 7.1
now).
___
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] Let's get rid of unbound methods

2005-01-04 Thread Tim Peters

[Guido]
> In my blog I wrote:
> 
> Let's get rid of unbound methods. When class C defines a method
> f, C.f should just return the function object, not an unbound
> method that behaves almost, but not quite, the same as that
> function object. The extra type checking on the first argument that
> unbound methods are supposed to provide is not useful in practice
> (I can't remember that it ever caught a bug in my code)

Really?  Unbound methods are used most often (IME) to call a
base-class method from a subclass, like my_base.the_method(self, ...).
 It's especially easy to forget to write `self, ` there, and the
exception msg then is quite focused because of that extra bit of type
checking.  Otherwise I expect we'd see a more-mysterious
AttributeError or TypeError when the base method got around to trying
to do something with the bogus `self` passed to it.

I could live with that, though.

> and sometimes you have to work around it;

For me, 0 times in ... what? ... about 14 years .

> it complicates function attribute access; and the overloading of
> unbound and bound methods on the same object type is
> confusing.

Yup, it is a complication, without a compelling use case I know of. 
Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType
is defined once and used once (believe it or not, in unittest.py).
___
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] Will ASTbranch compile on windows yet?

2005-01-04 Thread olsongt

I submitted patch "[ 742621 ] ast-branch: msvc project sync" in the VC6.0 days. 
 There were some required changes to headers as well as the project files.  It 
had discouraged me in the past when Jeremy made calls for help on the astbranch 
and I wasn't even sure if the source was in a compilable state when I checked 
it out.  I'm sure it has discouraged other windows programmers as well.

-Grant

___
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] Let's get rid of unbound methods

2005-01-04 Thread Phillip J. Eby

At 01:36 PM 1/4/05 -0500, Jim Fulton wrote:
duck typing?
AKA latent typing or, "if it walks like a duck and quacks like a duck, it 
must be a duck."  Or, more pythonically:

   if hasattr(ob,"quack") and hasattr(ob,"duckwalk"):
# it's a duck
This is as distinct from both 'if isinstance(ob,Duck)' and 'if 
implements(ob,IDuck)'.  That is, "duck typing" is determining an object's 
type by inspection of its method/attribute signature rather than by 
explicit relationship to some type object.

___
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] Please help complete the AST branch

2005-01-04 Thread Alex Martelli

On 2005 Jan 04, at 17:17, Jeremy Hylton wrote:
That's fine with me.  We had taken it to the compiler-sig when it
wasn't clear there was interest in the ast branch :-).
Speaking for myself, I have a burning interest in the AST branch 
(though I can't seem to get it correctly downloaded so far, I guess 
it's just my usual CVS-clumsiness and I'll soon find out what I'm doing 
wrong & fix it), and if I could follow the discussion right here on 
python-dev that would sure be convenient (now that I've finally put the 
2nd ed of the Cookbook to bed and am finally reading python-dev again 
after all these months -- almost caught up with recent traffic 
too;-)...

Alex
___
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] Let's get rid of unbound methods

2005-01-04 Thread Phillip J. Eby

At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote:
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?
Code that currently does 'aClass.aMethod.im_func' in order to access the 
function object would break, as would code that inspects 'im_self' to 
determine whether a method is a class or instance method.  (Although code 
of the latter sort would already break with static methods, I suppose.)

Cursory skimming of the first 100 Google hits for 'im_func' seems to show 
at least half a dozen instances of the first type of code, though.  Such 
code would also be in the difficult position of having to do things two 
ways in order to be both forward and backward compatible.

Also, I seem to recall once having relied on the behavior of a 
dynamically-created unbound method (via new.instancemethod) in order to 
create a descriptor of some sort.  But I don't remember where or when I did 
it or whether I still care.  :)

___
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] Let's get rid of unbound methods

2005-01-04 Thread Aahz

On Tue, Jan 04, 2005, Jim Fulton wrote:
> Guido van Rossum wrote:
>>
>> and the overloading of
>>unbound and bound methods on the same object type is confusing. Also,
>>the type checking offered is wrong, because it checks for subclassing
>>rather than for duck typing.
> 
> duck typing?

"If it looks like a duck and quacks like a duck, it must be a duck."

Python is often referred to as having duck typing because even without
formal interface declarations, good practice mostly depends on
conformant interfaces rather than subclassing to determine an object's
type.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
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] Let's get rid of unbound methods

2005-01-04 Thread Jack Diederich

On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> In my blog I wrote:
> 
> Let's get rid of unbound methods. When class C defines a method f, C.f
> should just return the function object, not an unbound method that
> behaves almost, but not quite, the same as that function object. The
> extra type checking on the first argument that unbound methods are
> supposed to provide is not useful in practice (I can't remember that
> it ever caught a bug in my code) and sometimes you have to work around
> it; it complicates function attribute access; and the overloading of
> unbound and bound methods on the same object type is confusing. Also,
> the type checking offered is wrong, because it checks for subclassing
> rather than for duck typing.
> 
> Does anyone think this is a bad idea? Anyone want to run with it?
> 
I like the idea, it means I can get rid of this[1]

func = getattr(cls, 'do_command', None)
setattr(cls, 'do_command', staticmethod(func.im_func)) # don't let anyone on 
c.l.py see this

.. or at least change the comment *grin*,

-Jack

[1] 
http://cvs.sourceforge.net/viewcvs.py/lyntin/lyntin40/sandbox/leantin/mudcommands.py?view=auto
___
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] Let's get rid of unbound methods

On Jan 4, 2005, at 1:28 PM, Guido van Rossum wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access; and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.
+1
I like this idea.  It may have some effect on current versions of 
PyObjC though, because we really do care about what self is in order to 
prevent crashes.  This is not a discouragement; we are already using 
custom descriptors and a metaclass, so it won't be a problem to do this 
ourselves if we are not doing it already.  I'll try and find some time 
later in the week to play with this patch to see if it does break 
PyObjC or not.  If it breaks PyObjC, I can sure that PyObjC 1.3 will be 
compatible with such a runtime change, as we're due for a refactoring 
in that area anyway.

-bob
___
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] Let's get rid of unbound methods

2005-01-04 Thread Jim Fulton

Guido van Rossum wrote:
In my blog I wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access;
I think this is probably a good thing as it potentially avoids
some unintential aliasing.
> and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.
duck typing?
This is a really simple change to begin with:
*** funcobject.c	28 Oct 2004 16:32:00 -	2.67
--- funcobject.c	4 Jan 2005 18:23:42 -
***
*** 564,571 
  static PyObject *
  func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
  {
! 	if (obj == Py_None)
! 		obj = NULL;
  	return PyMethod_New(func, obj, type);
  }
  
--- 564,573 
  static PyObject *
  func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
  {
! 	if (obj == NULL || obj == Py_None) {
! 		Py_INCREF(func);
! 		return func;
! 	}
  	return PyMethod_New(func, obj, type);
  }
  
There are some test suite failures but I suspect they all have to do
with checking this behavior.

Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?
It *feels* very disruptive to me, but I'm probably wrong.
We'll still need unbound builtin methods, so the concept won't
go away. In fact, the change would mean that the behavior between
builtin methods and python methods would become more inconsistent.
Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Let's get rid of unbound methods

In my blog I wrote:

Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access; and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.

This is a really simple change to begin with:

*** funcobject.c28 Oct 2004 16:32:00 -  2.67
--- funcobject.c4 Jan 2005 18:23:42 -
***
*** 564,571 
  static PyObject *
  func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
  {
!   if (obj == Py_None)
!   obj = NULL;
return PyMethod_New(func, obj, type);
  }
  
--- 564,573 
  static PyObject *
  func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
  {
!   if (obj == NULL || obj == Py_None) {
!   Py_INCREF(func);
!   return func;
!   }
return PyMethod_New(func, obj, type);
  }
  
There are some test suite failures but I suspect they all have to do
with checking this behavior.

Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.

Does anyone think this is a bad idea? Anyone want to run with 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] Please help complete the AST branch

On Jan 4, 2005, at 1:23 PM, Skip Montanaro wrote:

I was suggesting that there is an ongoing discussion that should
continue on the compiler-sig.
Guido> I'd be fine with keeping this on python-dev too.
+1 for a number of reasons:
* It's more visible and would potentially get more people 
interested in
  what's happening (and maybe participate)

* The python-dev list archives are searched regularly by a number 
of
  people not on the list (more external visibility/involvement)

* Brett would probably include progress reports in his python-dev
  summary (again, more external visibility/involvement)
* Who really feels the need to subscribe to yet another mailing 
list?
+1 for the same reasons
-bob
___
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] Please help complete the AST branch

2005-01-04 Thread Skip Montanaro


>> I was suggesting that there is an ongoing discussion that should
>> continue on the compiler-sig.

Guido> I'd be fine with keeping this on python-dev too.

+1 for a number of reasons:

* It's more visible and would potentially get more people interested in
  what's happening (and maybe participate)

* The python-dev list archives are searched regularly by a number of
  people not on the list (more external visibility/involvement)

* Brett would probably include progress reports in his python-dev
  summary (again, more external visibility/involvement)

* Who really feels the need to subscribe to yet another mailing list?

Skip
___
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] Fwd: Thank You! :)

This really goes to all python-dev folks!

-- Forwarded message --
From: Erik Johnson <[EMAIL PROTECTED]>
Date: Tue, 4 Jan 2005 11:19:15 -0700
Subject: Thank You! :)
To: [EMAIL PROTECTED]

You probably get a number of messages like this, but here is mine... 

My name is Erik Johnson, and I work in Albuquerque, NM for a small
company called WellKeeper, Inc. We do remote oil & gas well
monitoring, and I am using Python as a replacement for Perl & PHP,
both for supporting dynamic web pages as well as driving a number of
non-web-based servers and data processors.

I just wanted to take a moment and say "Thank you!" to you, Guido,
and your team for developing Python and then so generously sharing it
with the world. I know it must be a pretty thankless job sometimes. I
am still a neophyte Python hacker (Pythonista?), but I have been
pretty impressed with Python so far, and am looking forward to
learning Python better and accomplishing more with it in near near and
not too distant future.

So... thanks again, Happy New Year, and best wishes to you, your
family, and your Python team for 2005!  (I hope you will pass these
good wishes along to your team.)

Sincerely, 
Erik Johnson 

-- 
--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] Please help complete the AST branch

2005-01-04 Thread Barry Warsaw

On Tue, 2005-01-04 at 11:17, Jeremy Hylton wrote:
> That's fine with me.  We had taken it to the compiler-sig when it
> wasn't clear there was interest in the ast branch :-).

Ok, then I'll leave compiler-sig where it is.
-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Please help complete the AST branch

2005-01-04 Thread Jeremy Hylton

That's fine with me.  We had taken it to the compiler-sig when it
wasn't clear there was interest in the ast branch :-).

Jeremy


On Tue, 4 Jan 2005 07:31:30 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> >I was suggesting that there
> > is an ongoing discussion that should continue on the compiler-sig.
> 
> I'd be fine with keeping this on python-dev too.
> 
> --
> --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] Please help complete the AST branch

>I was suggesting that there
> is an ongoing discussion that should continue on the compiler-sig.

I'd be fine with keeping this on python-dev too.

-- 
--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] Please help complete the AST branch

2005-01-04 Thread Jeremy Hylton

The list archives look like they are mostly full of spam, but it's
also the only list we've used to discuss the ast work.  I haven't
really worried whether the sig was "active," as long as the list was
around.  I don't mind if you want to resurrect it.  Is there some way
to delete the spam from the archives?

By "discussion on" I meant a discussion of the remaining work.  I'm
not sure why you quoted just that part.  I was suggesting that there
is an ongoing discussion that should continue on the compiler-sig.

Jeremy

On Tue, 04 Jan 2005 07:43:28 -0500, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-03 at 23:17, Tony Meyer wrote:
> > > Perhaps interested parties should take up the discussion on
> > > the compiler-sig.
> >
> > This isn't listed in the 'currently active' SIGs list on
> >  - is it still active, or will it now be?  If so,
> > perhaps it should be added to the list?
> >
> > By 'discussion on', do you mean via the wiki at
> > ?
> 
> If compiler-sig is where ASTers want to hang out, I'd be happy to
> resurrect it.
> 
> -Barry
> 
> 
>
___
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] Mac questions

On Jan 4, 2005, at 7:42 AM, Jack Jansen wrote:
On 4 Jan 2005, at 11:41, Bob Ippolito wrote:
And finally: Is there any other way to find the true spelling of a 
file
except than a linear search with opendir()/readdir()/closedir() ?
Yes, definitely.  I'm positive you can do this with CoreServices, but 
I'm not sure it's portable to Darwin (not Mac OS X).  I'm sure there 
is some Darwin-compatible way of doing it, but I don't know it off 
the top of my head.  I'll try to remember to look into it if nobody 
else finds it first.
I haven't used pure darwin, but I assume it has support for FSRefs, 
right? Then you could use FSPathMakeRef() to turn the filename into an 
FSRef, and then FSGetCatalogInfo() to get the true filename.
I believe your assumption is wrong.  CoreServices is not open source, 
and this looks like it confirms my suspicion:

(from )
#if !defined(DARWIN)
struct FSRef;
CF_EXPORT
CFURLRef CFURLCreateFromFSRef(CFAllocatorRef allocator, const struct 
FSRef *fsRef);

CF_EXPORT
Boolean CFURLGetFSRef(CFURLRef url, struct FSRef *fsRef);
#endif /* !DARWIN */
-bob
___
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] Please help complete the AST branch

2005-01-04 Thread Barry Warsaw

On Mon, 2005-01-03 at 23:17, Tony Meyer wrote:
> > Perhaps interested parties should take up the discussion on 
> > the compiler-sig.
> 
> This isn't listed in the 'currently active' SIGs list on
>  - is it still active, or will it now be?  If so,
> perhaps it should be added to the list?
> 
> By 'discussion on', do you mean via the wiki at
> ?

If compiler-sig is where ASTers want to hang out, I'd be happy to
resurrect it.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Mac questions

On 4 Jan 2005, at 11:41, Bob Ippolito wrote:
And finally: Is there any other way to find the true spelling of a 
file
except than a linear search with opendir()/readdir()/closedir() ?
Yes, definitely.  I'm positive you can do this with CoreServices, but 
I'm not sure it's portable to Darwin (not Mac OS X).  I'm sure there 
is some Darwin-compatible way of doing it, but I don't know it off the 
top of my head.  I'll try to remember to look into it if nobody else 
finds it first.
I haven't used pure darwin, but I assume it has support for FSRefs, 
right? Then you could use FSPathMakeRef() to turn the filename into an 
FSRef, and then FSGetCatalogInfo() to get the true filename.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 4, 2005, at 5:56 AM, Jack Jansen wrote:
On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally 
does a good job about swapping in and out without causing much of a 
problem, so I'm personally not very surprised that it could go 
unnoticed this long.
*Except* when you're low on free disk space. 10.2 and before were 
really bad with this, usually hanging the machine, 10.3 is better but 
it's still pretty bad when compared to other unixen. It probably has 
something to do with the way OSX overcommits memory and swapspace, for 
which it apparently uses a different algorithm than FreeBSD or Linux.

I wouldn't be surprised if the bittorrent problem report in this 
thread was due to being low on diskspace. And that could also be true 
for the original error report that sparked this discussion.
I was able to trigger this bug with a considerable amount of free disk 
space using a laptop that has 1GB of RAM, although I did have to 
increase the buffer size from the given example quite a bit to get it 
to fail.  After all, a 32-bit process can't have more than 4 GB of 
addressable memory.  I am pretty sure that OS X is never supposed to 
overcommit memory.  The disk thrashing probably has a lot to do with 
the fact that Mac OS X will grow and shrink its swap based on demand, 
rather than having a fixed size swap partition as is common on other 
unixen.  I've never seen the problem myself, though.

From what I remember about Linux, its malloc implementation merely 
increases the address space of a process.  The actual allocation will 
happen when you try and access the memory, and if it's overcommitted 
things will fail in a bad way.

-bob
___
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] Darwin's realloc(...) implementation never shrinks allocations

On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally 
does a good job about swapping in and out without causing much of a 
problem, so I'm personally not very surprised that it could go 
unnoticed this long.
*Except* when you're low on free disk space. 10.2 and before were 
really bad with this, usually hanging the machine, 10.3 is better but 
it's still pretty bad when compared to other unixen. It probably has 
something to do with the way OSX overcommits memory and swapspace, for 
which it apparently uses a different algorithm than FreeBSD or Linux.

I wouldn't be surprised if the bittorrent problem report in this thread 
was due to being low on diskspace. And that could also be true for the 
original error report that sparked this discussion.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Mac questions