On 10/10/2011 21:21, Giampaolo Rodolà wrote: > Thanks everybody for your feedback. > I created a gcode project here: > http://code.google.com/p/pycompat/ > > 2011/10/8 Antoine Pitrou<solipsis at pitrou.net>: >> There's also some stuff there that is coded in C, or that will rely on >> some functionality of the core interpreter that is not easily >> emulated on previous versions. But I suppose you'll find that out by >> yourself. > Yep, I'm still not sure what to do about this. > I guess I'll just ignore that stuff in all those cases where rewriting > it in python is too much effort. > > Toshio Kuratomi<a.badger at gmail.com> wrote: >> I have a need to support a small amount of code as far back as python-2.3 >> I don't suppose you're interested in that as well? ;-) > I'm still not sure; 2.3 version is way too old (it doesn't even have > decorators). > It might make sense only in case the lib gets widely used, which I doubt. > Personally, at some point I deliberately dropped support for 2.3 from > all of my code/lib, mainly because I couldn't use decorators. so I > don't have a real need to do this. Yes, rewriting code from Python 2.7 to support Python 2.3 (pre-decorators) is a real nuisance. In my projects I'm currently supporting Python 2.4+. I'll probably drop support for Python 2.4 soon which will allow for the use of the with statement. > > 2011/10/9 Éric Araujo<merwok at netwok.org>: >> The issues I foresee with your lib are more technical: First, it looks >> like a big bag of backported modules, classes and functions without >> defined criterion for inclusion (“cool new stuff”?). > I'd say the criterion for inclusion is putting in everything which can > be (re)written in python 2.4, such as any, all, > collections.defaultdict and property setters/deleters (2.6). > Pretty much all the stuff written in C would be left out, maybe with > the exception of functools module which is important (for me at > least), in which case I might try to rewrite it in pure Python. > I'm sharing your same doubts though. > Maybe this isn't worth the effort in the first place. > I'll try to write some more code and see whether this is a good > candidate for a "public module". > If not I'll just get back to use it as an internal "private" module. > > 2011/10/9 Éric Araujo<merwok at netwok.org>: >> keep on lumping new things until Python 3.4? 3.8? Won’t that become >> unmanageable (boring/huge/hard)? > I don't think it makes sense to go over than 3.2 version. > Folks which are forced to use python 2.4 are already avoing to use 2.6 > and 2.7 features, let alone 3.X only features. > Plus, python 3.2 was already the latest 3.X version which still had > something in common with 2.7. However, if you can include Python 3.2+ features then projects that also support Python 3 can still use new features without having to worry about compatibility (it solves the same problem). All the best, Michael Foord > > > --- Giampaolo > http://code.google.com/p/pyftpdlib/ > http://code.google.com/p/psutil/ > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4