Mangle function name with decorator?

[Adam]

I am using Python 2.5, and I would like to write a decorator (or using
some other elegant, declarative approach) to mangle the name of
function in a class. I would like to be able to have two methods
declared with the same name, but one of them will have a decorator (or
whatever) that will change the name of one of them.

Example:

class A(object):
def __init__(self, method, usebar = False):
self.method = method
self.usebar = usebar

def __call__(self):
if self.usebar == True:
mangled_name = "_bar_" + self.method
if hasattr(self, mangled_name):
return getattr(self, mangled_name)()
else:
return getattr(self, self.method)()
else:
if hasattr(self, self.method):
return getattr(self, self.method)()
else:
raise NotImplementedError

@bar
def foo(self):
print "in _bar_foo"

def foo(self):
print "in foo"

Desired output:in foo

 

[Adam]

Thanks, Andrew. I'm trying to accomplish something with a
metaprogramming flavor, where, for the convenience of the programmer
and the clarity of code, I'd like to have a decorator or some other
mechanism do twiddling behind the scenes to make a class do something
it wouldn't normally do.

Here's a less-obfuscated exmaple: I want to build a framework for
creating MVC web applications in Python (I know, I know, there's
already 2^1bazillion of them) where a controller class can have
methods that respond to the same action but for different HTTP verbs:

class foo_controller(Controller):
@GET
def new(self):
# Display the form to create a new foo

@POST
def new(self):
# Receive a form post with new foo data in it

The Controller class will do all of the work behind the scenes to
makes sure that the correct method is called at run-time, but for the
sake of the programmer, I'd like to supply a clear, friendly syntax
like this. Without a little metaprogramming magic, last-in-wins, and
only the second version of foo will end up in the class, so I'd like
to mangle the names to something that will result in a unique
attribute name and that the Controller class can work with behind the
scenes to do the right thing at run time.

So, Python experts, am I completely barking up the wrong tree here?

 

[Aaron Brady]

Thanks, Andrew.  I'm trying to accomplish something with a
metaprogramming flavor, where, for the convenience of the programmer
and the clarity of code, I'd like to have a decorator or some other
mechanism do twiddling behind the scenes to make a class do something
it wouldn't normally do.

Here's a less-obfuscated exmaple:  I want to build a framework for
creating MVC web applications in Python (I know, I know, there's
already 2^1bazillion of them) where a controller class can have
methods that respond to the same action but for different HTTP verbs:

class foo_controller(Controller):
    @GET
    def new(self):
        # Display the form to create a new foo

    @POST
    def new(self):
        # Receive a form post with new foo data in it

The Controller class will do all of the work behind the scenes to
makes sure that the correct method is called at run-time, but for the
sake of the programmer, I'd like to supply a clear, friendly syntax
like this.  Without a little metaprogramming magic, last-in-wins, and
only the second version of foo will end up in the class, so I'd like
to mangle the names to something that will result in a unique
attribute name and that the Controller class can work with behind the
scenes to do the right thing at run time.

So, Python experts, am I completely barking up the wrong tree here?

Unfortunately, your target is out of range for decorators. Decorators
can only do:

a= foo( a )

You want something like:

a_jam= foo( a )

However, metaclasses, possibly -combined- with decorators, may fit the
bill. When the class is being constructed, and is just a string, a
tuple of bases and a dictionary, you can intercept the call to 'type',
and modify the dictionary.

You would need a unique attribute to look for on values in the
dictionary, which means you'd need to detect what functions you are
renaming; possibly by using a decorator to mark them. (Untested

class X( metaclass= M ):
@mark( 'A' )
def foo( ... ).

class M( type ):
def __new__( cls, name, bases, namespace ):
for k, v in namespace.items():
if v.tag== 'mark-A':
namespace[ k ]= modification( v )
or in your case:
del namespace[ k ]
namespace[ k_mod ]= v.original

possibly also setting func_name as well.
return type( name, bases, namespace )

 

[Aaron Brady]

at bottom

ah, ok.  then yes, you can do that with decorators.  you'd need hash
tables or something similar in a metaclass.  then the decorator would take
the given function, stick it in the appropriate hash table, and return a
function that does the dispatch (ie at run time does the lookup from the
hash table) (you'd only want to set the function once once, so it would
need to check the function wasn't already defined).  also, the decorator
would have one name and get/post etc would be an argument.

this is all documented in the docs and peps, although it's very spread
around.  you might look at the code for the property decorator - it's not
doing what you want, but it's an interesting non-trivial example that's
public.

http://docs.python.org/library/functions.html#property

andrew

snip

I didn't study the OP post very well.

It almost sounds like you want two separate classes, one with methods
for one 'state' the other with methods for another state. You can
assign to 'self.__class__' to transition between them.

Otherwise, if you're using a hash table, the keys could be
( method_name, flag_value ) pairs, so that looking up a method with a
flag is 'meth= self._dispatch[ ( method_name, flag_value ) ]'.
However, without metaclasses or a global variable, there's no way to
remember a prior definition when you redefine a name.

class X:
@stateA
def M.
@stateB
def M.

When 'stateB( M )' is called, the result is assigned to 'M'. There's
no way to access previous definitions of M, since there is no way to
reference the namespace that is under construction.

However, if you're willing to tolerate a little redundancy, you can
chain prior definitions of a variable onto later ones.
.... def inner( fun ):
.... fun.prior= var
.... return fun
.... return inner
........ def M( self ): pass
.... @dec( M )
.... def M( self ): pass
....
So, you still have the earlier definition of M. You just had to
mention it when you redefined the variable.

(Perhaps someday, we will be able to write:
def dec( namespace ):
def outer( fun ):
if fun.__name__ in namespace:
namespace[ dup_var ]= namespace[ fun.__name__ ]
return fun
return outer
It allows us to see if there's a prior entry in the current namespace,
and save it to a different name.)

 

[Michele Simionato]

(Perhaps someday, we will be able to write:
def dec( namespace ):
  def outer( fun ):
    if fun.__name__ in namespace:
      namespace[ dup_var ]= namespace[ fun.__name__ ]
    return fun
  return outer
It allows us to see if there's a prior entry in the current namespace,
and save it to a different name.)

Not in the future, but right now, with Python 3.0:

class noclashdict(dict):
"""
A dictionary where overriding a name actually generates a new
entry
with suffix '_new':

>>> d = noclashdict()
>>> d['a'] = 1
>>> d['a'] = 2
>>> sorted(d)

['a', 'a_new']
"""
def __setitem__(self, name, value):
setitem = super().__setitem__
if name in self:
setitem(name + "_new", value)
else:
setitem(name, value)

class Meta(type):
"A metaclass replacing the class dictionary with a noclashdict in
its instances"
@classmethod
def __prepare__(cls, name, bases):
return noclashdict()

class C(metaclass=Meta):
def foo(self):
return 1
def foo(self):
return 2

print(sorted(n for n in vars(C) if not n.startswith('__')))
# prints ['foo', 'foo_new']

if __name__ == '__main__':
import doctest; doctest.testmod()

It seems Guido's time machine is ticking again

Michele Simionato

 

[Michele Simionato]

I forgot; people interested in metaclasses in Python 3.0
will want to read this paper:
http://www.artima.com/weblogs/viewpost.jsp?thread=236234

 

[J. Cliff Dyer]

You might be interested in redefining __getattribute__(self, attr) on
your class. This could operate in conjunction with the hash tables
(dictionaries) mentioned by andrew cooke. i.e. (untested code):

class C(object):
def __init__(self):
self._get_table = {}
self._post_table = {}

def __getattribute__(self, x):
if self.method=='GET':
return object.__getattribute__(self, _get_table)[x]
elif self.method=='POST':
return object.__getattribute__(self, _post_table)[x]
else:
raise AttributeError
@GET
def foo(x):
return "Got", x
@POST
def foo(x)
return "Posted to", x

This is definitely not functional code, but might get you in the right
direction on __getattribute__. __getattr__ might also work for you. I
haven't worked too much with these corners of python.

Cheers,
Cliff

 

[Adam]

You might be interested in redefining __getattribute__(self, attr) on
your class.  This could operate in conjunction with the hash tables
(dictionaries) mentioned by andrew cooke.  i.e. (untested code):

class C(object):
    def __init__(self):
        self._get_table = {}
        self._post_table = {}

    def __getattribute__(self, x):
        if self.method=='GET':
            return object.__getattribute__(self, _get_table)[x]
        elif self.method=='POST':
            return object.__getattribute__(self, _post_table)[x]
        else:
            raise AttributeError
    @GET
    def foo(x):
        return "Got", x
    @POST
    def foo(x)
        return "Posted to", x

This is definitely not functional code, but might get you in the right
direction on __getattribute__.  __getattr__ might also work for you.  I
haven't worked too much with these corners of python.

Cheers,
Cliff

Hey, Cliff. Thanks for sharing this idea. Unfortunately, providing a
way to actually call the method with the mangled name is relatively
easy, and there are options there. The real issue, to me, seems to be
finding a way to prevent Python from eating all but the last version
of a function definition in a class. While decorators are a elegant
and unintrusive approach, I don't believe that there is any way for a
decorator to collection information in a data structure and then
provide that data back to the class instance or the class's metaclass.

I'm beginning to think that I am trying to get the square peg of
Python to fit into the round hole of a .NET idiom. I am trying to
borrow what I think is a really elegant and useful idiom from ASP.NET
MVC. Specifically, in an ASP.NET MVC Controller class, I can have two
methods with the same name that are called for different HTTP Verbs by
applying an Attribute:

public ActionResult Payment() {
ViewData["Title"] = "Payment Information";
ViewData["submit_text"] = "Next >";

return View();
}

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Payment(FormCollection form) {

return RedirectToAction("Legal");
}

Right? The first Payment method is called when the Payment page is
rendered. The second is called when the form that it contains is
submitted. I find it to be readable, elegant and it does not intrude
into the actual logic of the method itself. The alternatives that I
can readily identify are less-than-optimal. For instance, if could
just have an if statement inside the body of the method that branches
on the HTTP verb:

def Payment(self):
if self.request.verb == 'GET':
# Do stuff for GET
elif self.request.verb == 'POST':
# So stuff for POST

Yes, it would work, but it is ugly and requires me to mix in the same
function the behaviors for two very separate things.

Or, I could do something like this:

def GET_Payment(self):
# Do stuff for GET

def POST_Payment(self):
# Do stuff for POST

This is trivially-easy to implement (in this case, a metaclass can
very easily manipulate the namespace), but it makes the source code
less appealing and just feels crufty and hacky. It also makes it
difficult to deal elegantly with having one method respond to more
than verb like I could if I could write:

@GET
@POST
def foo(self):
# Do stuff for page foo, if it is GET or POST; PUT and DELETE not
allowed!

 

[Michele Simionato]

Hey, Cliff.  Thanks for sharing this idea.  Unfortunately, providing a
way to actually call the method with the mangled name is relatively
easy, and there are options there.  The real issue, to me, seems to be
finding a way to prevent Python from eating all but the last version
of a function definition in a class.

As I said in my other post in this thread, this can only be done in
Python 3.X.

 

[J. Cliff Dyer]

You might be interested in redefining __getattribute__(self, attr) on
your class. This could operate in conjunction with the hash tables
(dictionaries) mentioned by andrew cooke. i.e. (untested code):

class C(object):
def __init__(self):
self._get_table = {}
self._post_table = {}

def __getattribute__(self, x):
if self.method=='GET':
return object.__getattribute__(self, _get_table)[x]
elif self.method=='POST':
return object.__getattribute__(self, _post_table)[x]
else:
raise AttributeError
@GET
def foo(x):
return "Got", x
@POST
def foo(x)
return "Posted to", x

This is definitely not functional code, but might get you in the right
direction on __getattribute__. __getattr__ might also work for you. I
haven't worked too much with these corners of python.

Cheers,
Cliff

Hey, Cliff. Thanks for sharing this idea. Unfortunately, providing a
way to actually call the method with the mangled name is relatively
easy, and there are options there. The real issue, to me, seems to be
finding a way to prevent Python from eating all but the last version
of a function definition in a class. While decorators are a elegant
and unintrusive approach, I don't believe that there is any way for a
decorator to collection information in a data structure and then
provide that data back to the class instance or the class's metaclass.

If your __getattribute__ dispatches method calls from a dictionary, it
shouldn't matter if the original name of the method has been blown away.
The actual method object lives on, and is accessed normally from the
user's standpoint.

I'm just thinking out loud now on ideas I haven't tested myself, but
what if your decorator were itself a method of the same class, so you
had something like this:

class BarBar(object):
def decorate_get(self, func):
pass
def decorate_post(self, func):
pass

@self.decorate_get
def foo(self):
pass
@self.decorate_post
def foo(self):
pass

Then the decorator has access to self, and can pass around whatever
information it needs. Maybe the decoration methods should live on a
base class somewhere.

class Decoratable(object):
def get(self, func):
pass
def post(self, func):
pass

class BarBar(Decoratable):
@self.get
def foo(self):
pass
@self.post
def foo(self)
pass

I'm beginning to think that I am trying to get the square peg of
Python to fit into the round hole of a .NET idiom.

Well, square is just one abstraction layer away from round anyway,
right?

I am trying to
borrow what I think is a really elegant and useful idiom from ASP.NET
MVC. Specifically, in an ASP.NET MVC Controller class, I can have two
methods with the same name that are called for different HTTP Verbs by
applying an Attribute:

public ActionResult Payment() {
ViewData["Title"] = "Payment Information";
ViewData["submit_text"] = "Next >";

return View();
}

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Payment(FormCollection form) {

return RedirectToAction("Legal");
}

Right? The first Payment method is called when the Payment page is
rendered. The second is called when the form that it contains is
submitted. I find it to be readable, elegant and it does not intrude
into the actual logic of the method itself. The alternatives that I
can readily identify are less-than-optimal. For instance, if could
just have an if statement inside the body of the method that branches
on the HTTP verb:

def Payment(self):
if self.request.verb == 'GET':
# Do stuff for GET
elif self.request.verb == 'POST':
# So stuff for POST

Yes, it would work, but it is ugly and requires me to mix in the same
function the behaviors for two very separate things.

Or, I could do something like this:

def GET_Payment(self):
# Do stuff for GET

def POST_Payment(self):
# Do stuff for POST

This is trivially-easy to implement (in this case, a metaclass can
very easily manipulate the namespace), but it makes the source code
less appealing and just feels crufty and hacky. It also makes it
difficult to deal elegantly with having one method respond to more
than verb like I could if I could write:

@GET
@POST
def foo(self):
# Do stuff for page foo, if it is GET or POST; PUT and DELETE not
allowed!

 

[Aahz]

you are trying to do very "deep" things that most people do not do with
python. that does not mean that there are no solutions, just that you
have to find them yourself (especially with the decline of this
newsgroup).

Excuse me? What decline of this newsgroup?
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. "
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22

 

[Aahz]

Hmmm. It's hard to respond to this without implicitly criticising others
here, which wasn't my point at all. But my personal impression is that
over the years various people who used to post here now stay pretty firmly
in the dev group, while others seem to have disappeared more or less
completely <wink>.

Well, yes, but that's simply the nature of online fora (I originally
wrote "nature of Usenet", but I think it's more general than that). From
my POV, if you're going to call it a "decline", you need to provide more
evidence than some people leaving and others arriving. I think that the
sheer volume and quality of posts to c.l.py is evidence that c.l.py is
not declining.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. "
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22

 

[Tim Chase]

Excuse me? What decline of this newsgroup?

Must be a by-product of Schluehr's Law[1]...every thread degrades
into an argument about the GIL.

-tkc


[1]
http://mail.python.org/pipermail/python-list/2009-January/697412.html

 

[skip]

Aahz> Excuse me? What decline of this newsgroup?

Andrew> .... But my personal impression is that over the years various
Andrew> people who used to post here now stay pretty firmly in the dev
Andrew> group, while others seem to have disappeared more or less
Andrew> completely <wink>.

People come and go, that's true. That's to be expected though. I certainly
find many of the "newer" folks more than capable replacements for people you
don't see around here (much) anymore. Maybe you just aren't as familiar
with some of the new names. I think if you intersect the set of frequent
posters here and with the frequent posters in python-dev (say, those who
post more than a few times a month) you'll find a fairly large intersection,
and that intersection will include some of the most active Python core
developers.

Skip

 

[Albert Hopkins]

Well, yes, but that's simply the nature of online fora (I originally
wrote "nature of Usenet", but I think it's more general than that). From
my POV, if you're going to call it a "decline", you need to provide more
evidence than some people leaving and others arriving. I think that the
sheer volume and quality of posts to c.l.py is evidence that c.l.py is
not declining.

I agree. If the argument is simply that some devs no longer hang here
but do on -dev than that's not declining to me, especially as the amount
of traffic on -dev increases. That's ordinary. Same for people coming
and going.

For me declining means the rate of (non-spam) posts is steadily dropping
over time.

If you look at http://mail.python.org/pipermail/python-list/ it doesn't
make it clear that there is any sort of decline.

1999-04: 1708
1999-05: 2204
1999-06: 2390
1999-07: 2387
1999-08: 2149
1999-09: 2014
1999-10: 2060
1999-11: 1911
1999-12: 2304
2000-01: 2678
2000-02: 4000
2000-03: 3782
2000-04: 3236
2000-05: 4283
2000-06: 4628
2000-07: 4189
2000-08: 4275
2000-09: 3961
2000-10: 3834
2000-11: 2360
2000-12: 3116
2001-01: 4212
2001-02: 3892
2001-03: 4494
2001-04: 4731
2001-05: 5498
2001-06: 4936
2001-07: 6518
2001-08: 5247
2001-09: 3728
2001-10: 3687
2001-11: 4575
2001-12: 4472
2002-01: 5602
2002-02: 5272
2002-03: 5309
2002-04: 5984
2002-05: 5331
2002-06: 4229
2002-07: 4840
2002-08: 4948
2002-09: 4205
2002-10: 3327
2002-11: 4355
2002-12: 4108
2003-01: 6225
2003-02: 7758
2003-03: 5041
2003-04: 5025
2003-05: 5012
2003-06: 4976
2003-07: 4937
2003-08: 5703
2003-09: 4320
2003-10: 6396
2003-11: 5059
2003-12: 3930
2004-01: 4059
2004-02: 4316
2004-03: 5178
2004-04: 4358
2004-05: 3926
2004-06: 4255
2004-07: 4291
2004-08: 6275
2004-09: 5619
2004-10: 5251
2004-11: 4064
2004-12: 5295
2005-01: 5394
2005-02: 5278
2005-03: 5117
2005-04: 5098
2005-05: 4383
2005-06: 4635
2005-07: 4533
2005-08: 4546
2005-09: 4591
2005-10: 5580
2005-11: 5789
2005-12: 5119
2006-01: 15174
2006-02: 9838
2006-03: 11660
2006-04: 9776
2006-05: 10740
2006-06: 10156
2006-07: 9564
2006-08: 9806
2006-09: 10752
2006-10: 11348
2006-11: 9887
2006-12: 9186
2007-01: 7850
2007-02: 8184
2007-03: 8986
2007-04: 9965
2007-05: 10138
2007-06: 8444
2007-07: 7776
2007-08: 8544
2007-09: 8852
2007-10: 8548
2007-11: 6940
2007-12: 7454
2008-01: 8490
2008-02: 8572
2008-03: 8393
2008-04: 9508
2008-05: 10030
2008-06: 7500
2008-07: 8496
2008-08: 8198
2008-09: 7632
2008-10: 8332
2008-11: 7656
2008-12: 8694
2009-01: 9792
2009-02: 8033
2009-03: 3801

 

[skip]

Albert> For me declining means the rate of (non-spam) posts is steadily
Albert> dropping over time.

I know this wasn't the main point of your post, but if you subscribe to
(e-mail address removed) or read it via a mail-to-news gateway like Gmane I
think you will find the ratio of spam to ham much smaller than if you read
comp.lang.python via a vanilla Usenet newsfeed.

 

[Aahz]

c.l.py is my favourite usenet group and has been for some time. I've
been doing usenet for 16 years now!

Newbie. ;-)
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. "
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22

 

[Aaron Brady]

Erik Max Francis wrote:

[...]

And made all purdy-like:

   http://www.alcyone.com/tmp/python-list traffic.pdf

That's very pretty, but neither the volume of posts, nor the quality of
the people posting here is really what I was talking about.  I don't think
I explained very well, but seeing the posts here helped clarify things a
little.

c.l.python used to be the core of a community built around a language.  It
no longer is.  It is a very useful place, where some very helpful and
knowledgeable people hang out and give advice, but instead of representing
the full interests of the Python community it is now very much a resource
for helping new users.

At least, that's how it seems to me.  And I don't think this is
necessarily "natural" or "normal" - I think it may be a failure on the
part of someone (who?  I don't quite know, perhaps all of us) in managing
a community.  Now there is an obvious argument against that - that the
language was becoming so popular that a single meeting place was no longer
practical - but without a crystal ball it is hard to know how true that
is, or what alternatives might have been.

I feel quite strongly about this.  I thought that c.l.python was almost
exceptional in the range (the perl group was another, similar community
back then).  I do worry that someone might have screwed up in a quite
major way, and that Python will suffer seriously, in the longer term, as a
result.

Another reason might be that the action has moved on to Haskell.  I get
the impression that it is undergoing the same kind of surge in popularity
from the "smart early adopters" that Python might have benefited from back
in the day

Hi, andrew.

(for some perverse reason I am actually moving back to Python
from more strongly typed functional languages).

I don't want to criticize you for this comment. In fact, it
illustrates a good point and a potential source of confusion: the
language and the newsgroup are two different things. Someone could
like the language and dislike the newsgroup; dislike the language and
like the newsgroup; or like or dislike both. Likes and dislikes can
each be passive or active by the way.

It is a shame that you are so prohibited from getting a foot in the
door of the dev newsgroup. From what you say, much of the Python-
focused, seasoned-dev discussion that you like takes place there; and
no one asks about references to parameters. I can't attest to the
intensity, formality, or tolerance there, however. It could be they
have goals, and you need more familiarity with Usenet protocol to be
understood, and not merely excluded. I am not saying that c-l-py vets
don't have goals; just that they're not the same as the dev vets'.

I see how c-l-py doesn't represent the full interests of Python,
although I can't attest to whether it used to. Naturally, among any
person or people, conflicts arise, dilemmas arise, and c-l-py vets
don't solve them in the same manner, or with the same results, that
dev vets do. The long term direction of this is dissent, struggle,
and mutiny. Logically, one of the c-l-py posters, not necessarily the
vets, will fork the source, it will become popular, and Pythoneers
will no longer be able to cut-and-paste source to share. It is a sad
destiny, but with all the authorities, veterans, and movers and
shakers cloistered away in an entrance-restricted, exclusive-
membership corner, the newbies won't see the long-term consequences.
We get our direction from the adults, and they aren't here. And, with
the community split in two, newbies will not get the answers they
need, and we'll wither away.

The motive for the fork could be anything. It could be a coup
d'elite, a lunge for power, or an honest but shallow improvement
attempt, from someone who doesn't know it will divide the community,
or doesn't know to care.

You have proposed that the precaution is greater control: it won't
happen if it can't happen; and if it can happen, it will. I don't
think either of those premises need proof, so the conclusion is
imminent. If two parties want two different things, they'll both get
them.

There are many people to control. They include the newbies, who have
taken your word for many characteristics of the language and the
group. They include the vets who already know them. Do you appoint
yourself sheriff?

 

[Albert Hopkins]

]

c.l.python used to be the core of a community built around a language. It
no longer is. It is a very useful place, where some very helpful and
knowledgeable people hang out and give advice, but instead of representing
the full interests of the Python community it is now very much a resource
for helping new users.

At least, that's how it seems to me. And I don't think this is
necessarily "natural" or "normal" - I think it may be a failure on the
part of someone (who? I don't quite know, perhaps all of us) in managing
a community. Now there is an obvious argument against that - that the
language was becoming so popular that a single meeting place was no longer
practical - but without a crystal ball it is hard to know how true that
is, or what alternatives might have been.

I feel quite strongly about this. I thought that c.l.python was almost
exceptional in the range (the perl group was another, similar community
back then). I do worry that someone might have screwed up in a quite
major way, and that Python will suffer seriously, in the longer term, as a
result.

Another reason might be that the action has moved on to Haskell. I get
the impression that it is undergoing the same kind of surge in popularity
from the "smart early adopters" that Python might have benefited from back
in the day (for some perverse reason I am actually moving back to Python
from more strongly typed functional languages).

Sentimental... yet comical. It's still, to me, a natural event. The
same things happens to nearly every new, upcoming, grassroots
technology. Linux was the same way. So was KDE (and probably GNOME as
well). This is just a natural evolution of the connection between
community and technology.

Simply put, Python isn't a baby anymore. I remember being on c.l.python
back in like '97 or '98. Back then it was pretty much the only place to
come to share info/interest Python. There was the newsgroup,
python.org, and Starship. That's it. Nowadays Python is everywhere.
There are forums, blogs, magazines, books, local user groups, PyCon,
PyPi. etc. And Python is so big that there are sub-communities such as
CherryPy and Django, SQLAlchemy, Jython and IronPython, etc. There are
so many sub-groups with their own visions and plans and momentum, and
that's a good thing! c.l.python is no longer the big fish in a small
pond.

So I'm sorry but c.l.python can no longer be the sole place to represent
the "full interests of the Python community" because the community is
much too big for it. It can't be "managed" by a central source. It's
bigger than that. And, let's face it, a smaller fraction of people get
their information from Usenet and mailing lists today compared to 1996.

Looking back at some postings from '95 [1] I don't see that much
different from then and now, except there was a lot more off-topic
stuff, there was a periodic FAQ, GvR, and I didn't see any GIL
flamewars. Some similarities include newbie-type questions, style
questions, questions regarding the C API, architecture- and
module-specific questions, posts from some of the same people I still
see today and, of course, regular expressions. But maybe your nostalgia
predates 1995 (I didn't start using Python until 1997).

Anyway, I'm bored with this discussion. It seems to be a natural part of
technology communities as well. I'm on another mailing list where,
almost every month, a different person independently comes to the
conclusion that the technology is dying. And it's been that way ever
since I joined the mailing list 6 years ago. If these things are dying
why can't they do so quickly (and quietly)?

-a


1.
http://groups.google.com/group/comp.lang.python/topics?hl=en&start=109792&sa=N

 

[skip]

Andrew> c.l.python used to be the core of a community built around a
Andrew> language. It no longer is. It is a very useful place, where
Andrew> some very helpful and knowledgeable people hang out and give
Andrew> advice, but instead of representing the full interests of the
Andrew> Python community it is now very much a resource for helping new
Andrew> users.

Two observations:

* The Python community has grown significantly, especially in the past
couple years. It's quite understandable that the bulk of
comp.lang.python participants now are new users. Also, as the most
readily visible "hangout", it's the natural place where most new users
will come to get help. The help and tutor mailing lists, IRC, various
other forums and subject-specific mailing lists are all much less
visible.

* As the community grows it's difficult for there to be one place where
everybody congregates. The needs of different elements of the Python
"family" differ. You will find lots of scientific users more involved
with scipy, matplotlib and ipython mailing lists, for example. I'm
sure Blender has some sort of online community for its users. The
people doing GUI programming with PyGtk probably tend to gravitate
there. The core developers spend much of their time at python-dev.
In the end, it winds up being more efficient for those subsections of
the overall Python user base to participate where they can either get
the most help, offer the most assistance, or contribute the most to
Python development or advocacy. It's too big for one size fits all.

An anecdote. I started using Sun workstations back about the time the sales
reps were delivering them out of the back of their cars. Heck, I remember
the first one at Lawrence Livermore Lab sat idle for quite awhile because
there was no software at all. No OS. Nothing. Probably just a boot
loader. Back then if you had a problem with, say, dbx, vi or cc, you called
Sun and after a couple transfers you were talking to the software engineer
who directly developed or maintained the recalcitrant program or library.
Fast forward about 25 years. I haven't spoken directly to a Sun employee in
years. I don't even think the company I work for buys its Sun computers
directly from Sun (we buy a lot of them). It's disappointing in some ways,
but I doubt it would be very efficient if all people who had problems with
Sun's C compiler were patched directly through to the head of the compiler
group at Sun. They've grown. (Well, up until relatively recently.) Their
user base has grown. There's no way they could manage their customer
interactions today the same way they managed them 25 years ago.