Re: [Twisted-Python] porting twisted.spread to Python3
there now is https://github.com/wrohdewald/twisted.git branch spread-py3-7598 Not all is finished, especially utf-8 wherever Python 3 allows it, pbfailure, and handling of wired exceptions. what should I do next to start getting this into trunk? Maybe - open a ticket for porting banana - create a branch with all commits for that - do a pull request I do not want to create one big patch because I think it is helpful to have more smaller commits. But I probably should wait with all that until ticket 7664 is merged. -- Wolfgang ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
On Nov 3, 2014, at 11:18 AM, Wolfgang Rohdewald wolfgang@rohdewald.de wrote: there now is https://github.com/wrohdewald/twisted.git branch spread-py3-7598 Not all is finished, especially utf-8 wherever Python 3 allows it, pbfailure, and handling of wired exceptions. what should I do next to start getting this into trunk? Maybe - open a ticket for porting banana - create a branch with all commits for that Yep, this is right. Creating a patch and attaching it to the ticket would also be useful. - do a pull request Opening a pull request is not a particularly useful part of this workflow :-). The ticket is sufficient. See https://github.com/twisted/twisted/pull/46 or any pull request closed recently for more information. I do not want to create one big patch because I think it is helpful to have more smaller commits. But I probably should wait with all that until ticket 7664 is merged. I should note that this is already in review. Anyone want to have a look? -g smime.p7s Description: S/MIME cryptographic signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
On Sun, Oct 5, 2014 at 2:58 PM, exar...@twistedmatrix.com wrote: On 04:23 pm, wolfgang@rohdewald.de wrote: BTW what about Ticket 7628, news extension port? I could soon start feeding porting tickets but if this extension is useful, I guess it should be applied first. Looks like Kevin is working on it. I'll review it when it comes up Apologies. I got sidetracked preparing for PyTexas (which was last weekend). I'll try to get back to it ASAP. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
On 3 Oct, 11:09 pm, wolfgang@rohdewald.de wrote: I now have a local git branch with about 70 commits, always rebased onto current trunk. It makes me sad to learn you're carrying so many patches to Twisted. It might be useful to the project if you could share why this development was easier to do outside the tree rather than contributing it to the project as you developed it. Those test suites pass with Python2 and Python3: test_banana, test_jelly, test_pb, test_pbfailure, test_persisted I also have a real app using PB (kajongg, a KDE game). Running the server and the client with any combination of Python 2 and Python 3 works but more testing is needed there. Especially transferring failures with non-ascii test, so I need to inject random errors. For testing? Probably not random - instead, comprehensive. spread.banana is now fully covered by tests (was at 85% before). There is still a lot of code in twisted.spread which has no tests yet. I do not think I want to add missing tests for everything, only for those regions where I do changes or where it is not too difficult. And of course if an application triggers a bug yet uncovered by tests. The coding standard only requires you to add tests for code you're changing. Python 3 mixes things up a bit though - by changing everything. Calling a module Python 3 compatible without changing it at all still changes lots of things how about it works. I think that before the Twisted project wants to call a particular module ported, we want it to have test coverage that can run on Python 3. Can you point me to other PB applications I could use for testing? Preferrably ones that are already mostly compatible with PY3 themselves, I'll let other people volunteer projects they know of - but I strongly suspect there are few or no such applications. but that is not a _must_, I would try porting them unless it turns out to be too much work. And preferrably ones developed by people with a non-ascii native language. I do not yet trust Failures and logging with non-ascii. Below is the current list of commits. Everything you see there is still much in flux. This includes shuffling code between commits, combining and splitting commits, changing order. I want to open one ticket per commit. Simple things hopefully not needing much discussion first. Estimating one week per review/commit to trunk, this process will take more than one year. Often I can only add a new ticket after the previous one has been integrated because they depend on each other. If twisted.spread were completely supported on Python 3 in only another year I'll be very impressed. :) So if it really seems to take that long, at some point I might just decide to put what I have to github and not care anymore. Which of course means I might have to distribute a patched twisted version with my application. I really want to leave Python2 behind, and only twisted is in the way. Latest versions of KDE do not have Python2 bindings anymore (KDE Frameworks 5). That's too bad. This log of course includes things being in tickets up for review. git log --pretty='format:%s' --reverse trunk..pb3 snip Again, it seems unfortunate that you have all of this work ... somewhere. Somewhere only you (as far as I can tell) can see it. Somewhere only you can test it. Somewhere only you can work on it and get it contributed to Twisted. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
Am Sonntag, 5. Oktober 2014, 13:48:12 schrieb exar...@twistedmatrix.com: On 3 Oct, 11:09 pm, wolfgang@rohdewald.de wrote: I now have a local git branch with about 70 commits, always rebased onto current trunk. It makes me sad to learn you're carrying so many patches to Twisted. It might be useful to the project if you could share why this development was easier to do outside the tree rather than contributing it to the project as you developed it. This is just my personal style of development. A bit chaotic. Sometimes trial and error. And really a lot of git rebase -i. Whenever I find some necessary or helpful change that could be done before porting, put that at the top of the patch list and readjust everything. The methodic part comes last: Look at what I changed, rethink why that is really needed, and look for similar places I overlooked. Then generate tickets for things that seem ready. BTW what about Ticket 7628, news extension port? I could soon start feeding porting tickets but if this extension is useful, I guess it should be applied first. I think that before the Twisted project wants to call a particular module ported, we want it to have test coverage that can run on Python 3. I was afraid you'd say that. https://twistedmatrix.com/trac/wiki/Plan/Python3 does not explicitly say so, maybe this should be changed. I can do that, but then I have no write permission for the wiki. I'll let other people volunteer projects they know of - but I strongly suspect there are few or no such applications. That makes me wonder if I really should have used PB at all. But now I do and have no plans to change that. Again, it seems unfortunate that you have all of this work ... somewhere. Somewhere only you (as far as I can tell) can see it. Somewhere only you can test it. Somewhere only you can work on it and get it contributed to Twisted. I believe I saw some mailing list posts where many years ago somebody said he has spread running with PY3 but as it seems nothing of that got into trunk. Be assured that I want to avoid that. What is the preferred place for Twisted public repositories? No svn please, only git. But first I want to do some more cleaning and reshuffling, I cannot really do that anymore with commits already pushed to a public repository. Maybe 2 or 3 weeks. -- Wolfgang ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
On 04:23 pm, wolfgang@rohdewald.de wrote: Am Sonntag, 5. Oktober 2014, 13:48:12 schrieb exar...@twistedmatrix.com: On 3 Oct, 11:09 pm, wolfgang@rohdewald.de wrote: I now have a local git branch with about 70 commits, always rebased onto current trunk. It makes me sad to learn you're carrying so many patches to Twisted. It might be useful to the project if you could share why this development was easier to do outside the tree rather than contributing it to the project as you developed it. This is just my personal style of development. A bit chaotic. Sometimes trial and error. And really a lot of git rebase -i. Whenever I find some necessary or helpful change that could be done before porting, put that at the top of the patch list and readjust everything. The methodic part comes last: Look at what I changed, rethink why that is really needed, and look for similar places I overlooked. Then generate tickets for things that seem ready. BTW what about Ticket 7628, news extension port? I could soon start feeding porting tickets but if this extension is useful, I guess it should be applied first. Looks like Kevin is working on it. I'll review it when it comes up. I think that before the Twisted project wants to call a particular module ported, we want it to have test coverage that can run on Python 3. I was afraid you'd say that. https://twistedmatrix.com/trac/wiki/Plan/Python3 does not explicitly say so, maybe this should be changed. I can do that, but then I have no write permission for the wiki. Ah. I didn't think anyone was paying any attention to the plan anymore (and I've run out of energy to try to get people to stick to it). For example, following the plan, I would have expected to see perhaps two patches to port the banana module: one to add the missing test coverage and one to make any and all changes necessary to get the test suite to pass on Python 3. (Note, I'm just pointing this out for the sake of clarity. I'm not complaining about the tickets/patches you recently contributed. As I said, I'm out of energy for that). As far as wiki access goes, I'm not clear on how those permissions work anymore. Perhaps someone else can chime in. If not, consider asking on #twisted-dev. I'll let other people volunteer projects they know of - but I strongly suspect there are few or no such applications. That makes me wonder if I really should have used PB at all. But now I do and have no plans to change that. Sorry about this. For anyone who's reading and thinking about starting a project, I personally recommend you not use PB. It's almost certainly not the right tool to solve the problem you have (if you think your problem is so unique and challenging it needs a tool like PB, maybe it is! Feel free to start a discussion about the specifics on this list. Maybe you've got one of the rare problems where PB makes sense.) Again, it seems unfortunate that you have all of this work ... somewhere. Somewhere only you (as far as I can tell) can see it. Somewhere only you can test it. Somewhere only you can work on it and get it contributed to Twisted. I believe I saw some mailing list posts where many years ago somebody said he has spread running with PY3 but as it seems nothing of that got into trunk. Be assured that I want to avoid that. What is the preferred place for Twisted public repositories? No svn please, only git. Anywhere public. Collaboration can't take place when things are private. But first I want to do some more cleaning and reshuffling, I cannot really do that anymore with commits already pushed to a public repository. Maybe 2 or 3 weeks. Pushing something isn't a promise not to abandoning, screw it up, rebase it, delete it later, whatever. I think that the notion that before something is shared it has to be carefully arranged and re-arranged to make it look like it was developed by an all-knowing, all-programming super being. Real software doesn't get built one perfect, self-contained step at a time. The construction of real software is messy. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
Am Sonntag, 5. Oktober 2014, 19:58:29 schrieb exar...@twistedmatrix.com: For example, following the plan, I would have expected to see perhaps two patches to port the banana module: one to add the missing test coverage and one to make any and all changes necessary to get the test suite to pass on Python 3. Impossible. test_jelly imports pb, test_pb imports jelly. But I can of course reduce the number of tickets related to porting and put more than one patchfile into them. -- Wolfgang ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] porting twisted.spread to Python3
On 08:28 pm, wolfgang@rohdewald.de wrote: Am Sonntag, 5. Oktober 2014, 19:58:29 schrieb exar...@twistedmatrix.com: For example, following the plan, I would have expected to see perhaps two patches to port the banana module: one to add the missing test coverage and one to make any and all changes necessary to get the test suite to pass on Python 3. Impossible. test_jelly imports pb, test_pb imports jelly. That doesn't mean it's impossible. It just means you may also have to shuffle some files around. But I can of course reduce the number of tickets related to porting and put more than one patchfile into them. Note that my point isn't that we need to reduce the number of tickets related to porting or that there should be more than one patch to resolve any one ticket (there shouldn't be). The point is that the documented porting plan is to port module by module, not Python 3 incompatible change by Python 3 incompatible change. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
