Il giorno 31/ago/2012, alle ore 10:31, Martin Zibricky <[email protected]> ha scritto:
> Giovanni Bajo píše v Čt 30. 08. 2012 v 23:13 +0200: >> Hi Matysek, >> >> why are you dropping Python 2.3 support? it's not in the way that much, and >> it seems totally gratuitous to me. Why should we remove working >> functionalities just for the sake of it? > > > - continuous integration server is a real help in ensuring stability of > development code, however there is only python 2.4+. I don't see this as a problem. Just run it with 2.4. I can easily run testsuite with 2.3, or somebody else will if necessary. > - I care about stability of development branch. If you want to avoid > situations where the code compatibility for older python releases would > be restored in bugfix releases then it's easier to drop python 2.3. This > situation already happened with some older releases. Bug reports are > mostly windows/osx. If anyone needs some bugfixes he could start > maintain any released version. I don't understand what you mean. My suggestion is simply not wasting your time on removing the 50 total lines of code that makes PyInstaller compatible with 2.3, leave them there, and ignore them. > - subprocess module is used in some test code and without that you would > have to has some compatibility code directly in tests and you would have > to be exposed to command formatting issues for windows command prompt. > Since tests should be standalone and should not use any Then those tests will fail on Python 2.3. I don't see it as a porblem. > - With python 2.4+ we are open to new language features like @decorators > or generators. With generators the PyInstaller performance could be > improved. I disagree there is any performance problem in PyInstaller that could be solved with generators. > - Without 2.3 we can drop more old code - like code using os.system() or > reference counting emulation in bootloader code. I could probably find > something more. That's less than 100 lines in total, probably less than 50. I fail to see what maintenance burden are causing on you. > - I doubt anyone on Windows uses Python 2.3 or I haven't heard about > anyone for really long time. Bug reports are mostly Python 2.6/2.7 on > windows. On osx we never supported Python 2.3 since proper osx support > was added recently - it's python 2.5+. Where it could make sense to > support python 2.3 is Linux. But on Linux PyInstaller is fairly stable > and people could still use any older version there. We discussed this many times. Not every people step up and speak. Your statistics suggest that a majority of users are on 2.6/2.7; hardly a surprise, in fact. My point is that 2.3 compatibility is costing us basically nothing, so you should not waste time remove it. > - Another point are code merge requests. If you are merging new code you > have to ensure it is compatible with Python 2.3. With python 2.4 it is > less work since continuous integration server will tell you next day if > it works with python 2.4 or not. Again, I don't see it as a big problem. Just not test it against 2.3. There will hardly be anything that breaks, and if it does is very easy to fix. > - My thinking is: "Improve code and drop old code as much as you can > before moving to Python 3 support." Some PyInstaller code has not been > touched for ages. > > - My intention is not to drop python 2 support completely. I think we'll > stick with python 2.4+ support for a long time. > - Personally, I would rather spend more time on Python 3 than on > ensuring python 2.3 compatibility. Then don't waste time on it. My point is: * 2.3 support is 100 lines at most. * There's hardly anything in PyInstaller that works in 2.4 that will break in 2.3. * I can easily run the testsuite once under 2.3 before release, and fix a couple of bugs (if any) in a few minutes. That's how I was maintaining compatibility with Python 1.5, and really, it was a fraction of my work. * 2.3 support doesn't get in the way of Python 3. I'm happy to maintain 2.3 compatibility. I'm just asking you not to waste your time by actively removing a few handful lines of code that keeps it alive. The big thing missing for Python 3 is a concrete plan on how to get there, *without* losing Python 2.x compatibility. -- Giovanni Bajo :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
