Using decorators for property, classmethod, etc.
peter ljunglöf
since we are dropping support for 2.4 and 2.5, I suggest we make use of @decorators whenever possible. At least for the "standard" ones such as @property, @classmethod and @staticmethod. A quick search gives that there are at least 50 places where we are using the old notation:
def m(...):
...
m = property(m, doc="docstring")
instead of:
@property
def m(...):
"docstring"
...
My real question is if we should do this conversion on all files in one single commit? Or if we should take one file at the time?
/Peter
Alex Rudnick
feeling up to it, go for it!
(thanks for all the patches recently!)
--
-- alexr
Steven Bird
> I personally think it'd be fine to do it all at once. If you're
> feeling up to it, go for it!
I agree.
Steven Bird
had meant for our NLTK 2.0 release to support 2.5 still. The first
release that drops support for Python 2.5 is planned to be NLTK 3.0.
Therefore I suggest that we consider the default branch to be for NLTK
3.0, and do a back-port for Python 2.5 if there is sufficient demand.
Any objections to this?
-Steven
peter ljunglöf
http://docs.python.org/whatsnew/2.4.html
Class decorators were introduced in 2.6, but I haven't seen any of these in NLTK.
/Peter
> --
> You received this message because you are subscribed to the Google Groups "nltk-dev" group.
> To post to this group, send email to nltk...@googlegroups.com.
> To unsubscribe from this group, send email to nltk-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nltk-dev?hl=en.
>
Morten Minde Neergaard
> Decorators were introduced in Python 2.4:
Indeed. Unless someone has a specific feature from python2.6 that we
want, I suggest we keep python2.5.
What is this @type.setter in nltk/sem/logic.py?
It (and possibly other things) is failing the tests on shining panda.
Smiles,
--
Morten Minde Neergaard
peter ljunglöf
8 feb 2012 kl. 21:39 skrev Morten Minde Neergaard:
> At 09:30, Tue 2012-02-07, peter ljunglöf wrote:
>> Decorators were introduced in Python 2.4:
>
> Indeed. Unless someone has a specific feature from python2.6 that we
> want, I suggest we keep python2.5.
One feature that is really good to have is the with statement. We can still keep 2.5 compatibility, but then we have to remember to
from __future__ import with_statement
My new code in tree.py does not work in 2.5, since ABC's weren't introduced in collections then. Also, collections.namedtuple was introduced in 2.6.
But the main reason to skip 2.5 is that then we can have the same code for Python 2 and 3. See e.g., PEP 3101, 3105, 3110 and 3112. Or:
http://docs.python.org/whatsnew/2.6.html
> What is this @type.setter in nltk/sem/logic.py?
it's a clean way of making a @property mutable, see:
http://docs.python.org/library/functions.html#property
but I see now that .setter and .deleter was introduced in Python 2.6, so maybe that's another reason to drop 2.5?
/Peter
peter ljunglöf
7 feb 2012 kl. 00:02 skrev Steven Bird:
> A consequence of this is that we now no longer support Python 2.5.
Ok, I take back what I said before. @decorators are still supported by 2.5, but there are some other things that are not 2.5:
- @property.setter (and @...getter and @...deleter):
I have used .setter in align.py, downloader.py, tree.py and sem/logic.py
- abstract base classes, in the collections module:
I changed the superclass of Tree from list to MutableSequence
Of course these changes can be reverted, if necessary, but it uglifies the code.
> I had meant for our NLTK 2.0 release to support 2.5 still. The first
> release that drops support for Python 2.5 is planned to be NLTK 3.0.
> Therefore I suggest that we consider the default branch to be for NLTK
> 3.0, and do a back-port for Python 2.5 if there is sufficient demand.
>
> Any objections to this?
So, I'm for.
/Peter