Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: RELEASED Python 2.4, alpha 2

Reply
Thread Tools

Re: RELEASED Python 2.4, alpha 2

 
 
Anthony Baxter
Guest
Posts: n/a
 
      08-05-2004
> This is a bad joke after all the strong perplexities showed about its
> decorators solution.
> I vote against the "@decorator before function" solution.


Please feel free to actually provide reasons for not liking @decorators.

Also - if you think you don't like it - please _try_ _it_ _out_ first.

Anthony
 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      08-05-2004
Anthony Baxter wrote:

>>This is a bad joke after all the strong perplexities showed about its
>>decorators solution.
>>I vote against the "@decorator before function" solution.

>
> Please feel free to actually provide reasons for not liking @decorators.
>
> Also - if you think you don't like it - please _try_ _it_ _out_ first.


Actually, I think many people *are* trying it out right now...
by reading the posts in this forum.

Python is not supposed to be a write-only language, as are some
other P languages that tend to use lots of punctuation for arbitrary
purposes (as surely no one has forgotten).

Python is supposed to be an *eminently readable* language. Those
of us objecting on the grounds of things like "ugliness" are actually
*reading* the examples and sample code that are being posted, and
are finding them *highly unreadable*. This is a valid reaction, and
since code is more often read than written (as again I don't need
to remind anyone), the readability of a feature should weigh much
more heavily than how easy it is to use after you try it out for
yourself. IMHO.

Yes, of course after using them for a while they will become more
readable, but there are people who have learned to speak Klingon as
well -- and that doesn't change the fact that Klingon is deliberately
very difficult to learn and awkward.

Furthermore, a number of people seem to be claiming that decorators
will be rarely used, so the @ syntax shouldn't be considered a problem.
They are getting it exactly backwards! If decorators will be rarely
used, then make sure the syntax is more readable than not, and even if
it's a tad more cumbersome to write, who will mind? They aren't going
to be used that often, right?!

-Peter
 
Reply With Quote
 
 
 
 
Anthony Baxter
Guest
Posts: n/a
 
      08-05-2004
On Thu, 05 Aug 2004 12:18:22 -0400, Peter Hansen <(E-Mail Removed)> wrote:
> Actually, I think many people *are* trying it out right now...
> by reading the posts in this forum.


Browsing a few examples in isolation is hardly the same thing as trying it out
with real live coding.

I did this, and found my initial "oh yuck" reaction ended up being "actually,
this isn't too bad".
 
Reply With Quote
 
Christopher T King
Guest
Posts: n/a
 
      08-05-2004
On Fri, 6 Aug 2004, Anthony Baxter wrote:

> Please feel free to actually provide reasons for not liking @decorators.


or [decorators], or what have you:

What does one do if a decorator raises an exception? If it's something
necessary to the functioning of the code (say, classmethod or
staticmethod), then all is as it should be. But what if it's not? What
if you're using a run-time type checking library, or a code optimizer,
that may not be installed? In that case you would most likely want to let
that decoration fail silently. To get around this, you'd either have to
rewrite that decorator and any above it in the chain as just normal
decorations, or use some other weird hack.

Decorators in general are the right solution for the wrong problem (as I
detailed in another thread). They are being introduced much too
prematurely, and have not been given time to be able to have been thought
through well enough. The @ syntax is the result of trying to shoehorn too
many solutions into one fix.

They purport to solve the problems of function type declaration
(class/static), function attributes, runtime type checking, and general
function mangling, when each of these (save general function mangling)
already have distinct solutions in nearly every other language. The first
three problems are currently implemented as hacks in Python that happen to
fall under the category of "general function mangling". Streamlining the
hack is not the answer.

 
Reply With Quote
 
Heiko Wundram
Guest
Posts: n/a
 
      08-05-2004
As all people here seem to be bashing on the new syntax, I thought I might
throw in a little different oppinion... At least for my eye, decorators look
fine the way they are in 2.4a2.

Am Donnerstag, 5. August 2004 18:18 schrieb Peter Hansen:
> Yes, of course after using them for a while they will become more
> readable, but there are people who have learned to speak Klingon as
> well -- and that doesn't change the fact that Klingon is deliberately
> very difficult to learn and awkward.


I don't think comparing the @ syntax to Klingon is fair to the proposed syntax
for decorators. Just think of the following:

class someobject(object):

@synchronized
@classmethod
def x(cls):
pass

If I were to translate this to english, I could read it as follows (note the
order):

Define a _class someobject_ which has a _synchronized_ _classmethod_ x.

The @ signs don't disturb my eye, they only make it clear that this method is
special. All other proposed syntaxes don't have this "shows up right away"
feeling.

I know there are problems with formatting tools (python-mode finds the syntax
as stated difficult to grasp at the moment, listing functions doesn't work
properly anymore), but I don't think a language is made by it's tools, but
the tools are made for the language. And so, if the language evolves, it's
only fair that the tools need to evolve too...

Anyway, I'm +1 for keeping the syntax as is. It's fine for me.

Heiko.
 
Reply With Quote
 
Anthony Baxter
Guest
Posts: n/a
 
      08-05-2004
On Thu, 5 Aug 2004 12:29:51 -0400, Christopher T King <(E-Mail Removed)> wrote:
> What does one do if a decorator raises an exception?


def deco(func):
raise TypeError

@deco
def foo():
print "hello"



> If it's something
> necessary to the functioning of the code (say, classmethod or
> staticmethod), then all is as it should be. But what if it's not? What
> if you're using a run-time type checking library, or a code optimizer,
> that may not be installed? In that case you would most likely want to let
> that decoration fail silently.


Silently failing is completely non-pythonic. If you really wanted to
handle a missing decorator, something like
missingdec = lambda x
would do this for you.

> Decorators in general are the right solution for the wrong problem (as I
> detailed in another thread). They are being introduced much too
> prematurely, and have not been given time to be able to have been thought
> through well enough. The @ syntax is the result of trying to shoehorn too
> many solutions into one fix.


Too prematurely?? staticmethod and classmethod were introduced in 2.2!
PyObjC, ctypes, Jython and IronPython can all do with using them, as can
rather a lot of other chunks of code. Anything that applies metadata to
functions can use this - look at all the various places where people are
putting stuff in docstrings as a current hack.

> They purport to solve the problems of function type declaration
> (class/static), function attributes, runtime type checking, and general
> function mangling, when each of these (save general function mangling)
> already have distinct solutions in nearly every other language. The first
> three problems are currently implemented as hacks in Python that happen to
> fall under the category of "general function mangling". Streamlining the
> hack is not the answer.


Or, alternately, they're another tool in the toolbox, along with
metaclasses and
the like.

Anthony
 
Reply With Quote
 
Anthony Baxter
Guest
Posts: n/a
 
      08-05-2004
On Fri, 6 Aug 2004 02:41:10 +1000, Anthony Baxter
<(E-Mail Removed)> wrote:
> On Thu, 5 Aug 2004 12:29:51 -0400, Christopher T King <(E-Mail Removed)> wrote:
> > What does one do if a decorator raises an exception?

>
> def deco(func):
> raise TypeError
>
> @deco
> def foo():
> print "hello"


Sigh. I missed this bit of cut-n-paste:

Traceback (most recent call last):
File "f.py", line 4, in ?
@deco
File "f.py", line 2, in deco
raise TypeError
TypeError
 
Reply With Quote
 
Heiko Wundram
Guest
Posts: n/a
 
      08-05-2004
Am Donnerstag, 5. August 2004 18:29 schrieb Christopher T King:
> They purport to solve the problems of function type declaration
> (class/static), function attributes, runtime type checking, and general
> function mangling, when each of these (save general function mangling)
> already have distinct solutions in nearly every other language. The first
> three problems are currently implemented as hacks in Python that happen to
> fall under the category of "general function mangling". Streamlining the
> hack is not the answer.


I don't think they try to solve all the things you state. Rather, it's only
about general function mangling at compile time. Whatever you need to do for
function mangling, that's up to you.

And, at least for me, as I stated elsewhere, the syntax is just fine. I've
tried it out yesterday, porting some code to 2.4a2 which used thread locks
extensively, and just writing a little class InstanceSynchronizer() which is
just a Class which defines __call__ (when decorating a function) and gets the
first parameter from the function call to acquire an instance specific lock
is certainly the right way to go.

Think of the following: (old style)

class x(object):
def __init__(self):
self.lock = threading.RLock()

def synchronized_method(self):
self.lock.acquire()
try:
<bla>
finally:
self.lock.release()

That's just plain horrible compared to what @ decorators can do:

class x(object):
synchronized = InstanceSynchronizer()

@synchronized
def synchronized_method(self):
<bla>

Writing the InstanceSynchronizer is pretty easy too:

class InstanceSynchronizer(object):

def __init__(self):
self._locks = {}
self._refs = {}

def _delete_ref(self,ref):
del self._locks[self._refs[id(ref)][1]]
del self._refs[id(ref)]

def __call__(self,f):
def fsyn(fself,*args,**kwargs):
try:
lock = self._locks[id(fself)]
except KeyError:
lock = threading.RLock()
fselfref = weakref.ref(fself,self._delete_ref)
self._locks[id(fself)] = lock
self._refs[id(fselfref)] = (fselfref,id(fself))
lock.acquire()
try:
return f(fself,*args,**kwargs)
finally:
lock.release()
return fsyn

This little class takes care of everything needed for instance locks. Writing
a class that takes care of class locks for functions (in case you need to
update class data) is easy as pie too.

class ClassSynchronizer(object):

def __init__(self):
self._lock = threading.RLock()

def __call__(self,f):
def fsyn(*args,**kwargs):
self._lock.acquire()
try:
return f(*args,**kwargs)
finally:
self._lock.release()
return fsyn

Now, if you have these two utility classes at your disposal, you can do the
following:

class someobject(object):
__instances__ = {}
isynchronized = InstanceSynchronizer()
csynchronized = ClassSynchronizer()

@csynchronized
def __init__(self):
<work on self.__instances__>

@isynchronized
@csynchronized
def do_something(self):
<work on self.__instances__ and on self>

@isynchronized
def do_somethingelse(self):
<work only on self>

Now tell me that using decorators to do synchronization isn't a lot easier to
read than the first (old) example is, and also less error-prone (resp.
acquiring/releasing locks properly and without deadlocks).

Heiko.
 
Reply With Quote
 
Christopher T King
Guest
Posts: n/a
 
      08-05-2004
On Fri, 6 Aug 2004, Anthony Baxter wrote:

> On Thu, 5 Aug 2004 12:29:51 -0400, Christopher T King <(E-Mail Removed)> wrote:
> > What does one do if a decorator raises an exception?

>
> def deco(func):
> raise TypeError
>
> @deco
> def foo():
> print "hello"


Yes yes yes, I /know/ they are /able/ to raise exceptions. My point was
about handling them in a clean, concise way.

> Silently failing is completely non-pythonic.


Then let's say you want to print a warning, "Warning, type checking not
installed!"

> If you really wanted to handle a missing decorator, something like
> missingdec = lambda x would do this for you.


Ick. That doesn't fix the general case (though I admit it wouldn't come
up too often).

> > Decorators in general are the right solution for the wrong problem (as I
> > detailed in another thread). They are being introduced much too
> > prematurely, and have not been given time to be able to have been thought
> > through well enough. The @ syntax is the result of trying to shoehorn too
> > many solutions into one fix.

>
> Too prematurely?? staticmethod and classmethod were introduced in 2.2!


I'm referring to the syntax, not the decorators themselves.

> PyObjC, ctypes, Jython and IronPython can all do with using them, as can
> rather a lot of other chunks of code. Anything that applies metadata to
> functions can use this - look at all the various places where people are
> putting stuff in docstrings as a current hack.


Anything that applies metadata to functions can use function attributes
much more effictively. They're cleaner, more to the point, and are likely
to have much less backlash than @. Example of a previous function
attribute proposal:

def foo(a,b,c):
.accepts = (int,int,int)
.returns = str
pass

> Or, alternately, they're another tool in the toolbox, along with
> metaclasses and the like.


It just so happens I'm not a big fan of metaclasses, either

 
Reply With Quote
 
Christopher T King
Guest
Posts: n/a
 
      08-05-2004
On Thu, 5 Aug 2004, Heiko Wundram wrote:

> Now tell me that using decorators to do synchronization isn't a lot easier to
> read than the first (old) example is, and also less error-prone (resp.
> acquiring/releasing locks properly and without deadlocks).


I'll admit synchronization is a strong use case (since I don't believe it
justifies language support, like it has in Java), but I just think there's
a better way to go about things that no-one's thought of yet.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RELEASED Python 2.4, alpha 3 Anthony Baxter Python 0 09-03-2004 08:36 AM
Re: [Python-Dev] RELEASED Python 2.4, alpha 2 =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Python 9 08-10-2004 04:33 PM
RELEASED Python 2.4, alpha 2 Anthony Baxter Python 0 08-05-2004 01:10 PM
RELEASED Python 2.4, alpha 1 Anthony Baxter Python 22 07-16-2004 07:29 PM
Re: RELEASED Python 2.4, alpha 1 Mike C. Fletcher Python 16 07-12-2004 10:50 PM



Advertisments