Re: [Twisted-web] Nevow and python 3

Hi Glyph, On Tue, Jan 23, 2018 at 11:51:44PM -0800, Glyph wrote:

...

On Jan 23, 2018, at 2:03 AM, Markus Demleitner wrote: through from twisted.web quite unsatisfying. I've tried to formulate something like a preliminary policy in https://github.com/msdemlei/nevow/blob/master/doc/strings_and_bytes.rst, but I'm deeply unhappy about most of this.

Yeah, IRequest is an unfortunate interface. Work is ongoing to design a more thoughtful one and gradually migrate to it. I think https://github.com/wsanchez/txrequest https://github.com/wsanchez/txrequest is getting pretty complete, and from there the hope is that it will get integrated into Klein and then upstreamed into Twisted.

...which of course looks like a very long migration path, very likely stretching far beyond python2's EOL if my typical deployment is on Debian stable... I wonder if one couldn't arrange for inevow.IRequest to adapt to essentially this (perhaps with a bit more glue code to keep as compatible with existing code as possible).

...

Ideally, I'd like to fairly exclusively expose actual strings to

"actual" meaning text?

Yes: str.

...

(2) Is anyone at all interested in the livepages stuff (I'm not, and dropping it would certainly make porting and maintaining the package a lot easier)?

If you're going to drop livepage, is there any reason you're not just migrating to twisted.web.template? Is there any way t.w.t could be made into an easier migration path?

I have to admit I've not really investigated t.w.t in any detail; one thing that actually does matter -- because templates of my users will silently fail with it -- is the change of the XML namespace for the nevow elements and attributes. I suppose one could work around it on template load, though. Hm -- this might be an interesting alternative to keeping all of nevow. Of course, that still doesn't help against the insiduous breakage when suddenly code needs to deal with byte strings coming out of request.args.keys(), path components, and headers; that's a bit less of a direct concern for me since it's much less deployer-visible for my applications, but if I have to write some compatibility layer, why not have nevow be it?

...

(3) If I went ahead with this and actually tried to get a python3-nevow into Debian (which I'd really, really like to see): How is everyone's feeling about keeping the name nevow even if serious functional changes (such as dropping livepages) were to come about? [What I care about most is keeping the templating system including the render_ and data_ methods].

If you're going to do a fork, please come up with a new name. Using the existing one is confusing, it causes namespace conflicts (what happens when Nevow itself gets some upstream patches that port it to python 3 from someone else?) and it causes import conflicts.

Fair enough (a bit more on this in my response to Werner).

That said, if you are interested in porting Nevow the same way that Twisted is being ported (i.e. there's one set of sources, but `pip install` on python 3 only installs the modules ported thus far)

Ouch -- given my experiences while porting it would seem a major chore to keep python2 compatibity. But then I've not tried, and I may be wrong. If I actually wanted to follow https://twistedmatrix.com/trac/wiki/Plan/Python3 by the letter, that's certainly far beyond what I can reasonably commit in terms of resources.

then that would certainly be a way to invest the effort in just porting the parts that you need, and letting someone else port LivePage later :). I'd be happy to make you a maintainer if you're interested in doing this - not a lot of other activity on Nevow right now!

I'd certainly like to make the effort I invest as worthwhile as possible; but, in particular after the experience of porting, I feel I'm not nearly as familiar with nevow's codebase (and customs in the twisted ecosystem) as I should be to confidently work as maintainer. Before I commit to anything, let me try to work out if I can get nevow to the point where it doesn't cause extra porting pains in the python3 migration of dependent code. Thanks, Markus