backward compatible to allow pyside1 code to work with pyside2 about qt.py HOT 4 OPEN

Thanks for this, @artbycrunk. It's an interesting idea!

1. Change to using qtWidgets as and when updates to the software are in progress, while still allowing the dev the freedom to keep part of the codebase in the old qtGUI style.

You mean that your code is using e.g. both QtGui.QWidget and QtWidgets.QWidget?
Don't you think we'll create more of a mess than what we already have (Qt4 -> Qt5) with that approach?
I'm actually not sure if we could even make this possible within the same project (Qt.py).

QT_COMPATIBILITY_MODE

Isn't it going to be hard to control this for certain software and then unset it for other software within the same environment?
I must say this sounds messy to me and I just wonder if this is a good mechanism to decide how Qt.py would function. It also sounds like you're going to build code around Qt.py to handle how to choose a mode for your softwares. I think instead a separate module would be better.

there might be legacy software that doesn't need an update to pyside2 module structure but still needs to be able to run in a pyside2 environment.
...
but it also will give the devs the ability to make a choice for backwards compatibility as much as possible, until the codebase is no longer able to sustain it.
...

1. Keep the software as is, without needing to change to qtWidgets, for the reason that the tool can gracefully reach its end of life.

I really appreciate this scenario and I'm in that boat too. I'm just not sure what you ask for will really be the quick fix we're all looking for here.

Qt.py solves more than one problem. We're adding convenience functionality to Qt.py which is supposed to help with compatibility between multiple bindings and let you write less code. This will become harder to do if we are to also support a "compatibility mode". It's even possible that down the line, we decide to add convenience functions which are limited to Qt5-bindings (not saying this is happening, but there's a a chance this might happen). I'm afraid we might end up with having Qt.py too fragmented in terms of what it can and can't do if we also add this "compatibility mode" into the mix. Another reason why I see it would be good to separate such a mode from the current Qt.py.

I'm actually writing new code for Python 3 and PyQt5/PySide2 but I wish to offer backwards compatibility as far as possible (including Python 2). For all the legacy code, it's showing to be really easy (and quick!) to porting that into using Qt.py. So speaking on behalf of my studio and myself personally, there's no real incentive to want this other behaviour or mode.

I'm not opposed creating a prototype for this though. And in that case I'd suggest a QtLegacy.py file is created for this purpose so that you'd use import QtLegacy rather than the existing import Qt. Perhaps then your software could be updated progressively with some parts importing Qt and some parts would import QtLegacy.

Only with a working prototype can you judge whether the development of such a "QtLegacy" and all the work verifying that it works in PySide2 is worth your time instead of using Qt.py the way it is intended today.

from qt.py.

Thanks for bringing this up, it is one of the two routes to take in a compatibility layer such as this.

We can either:

1. Bring the past to the future, or
2. Bring the future to the past

Qt.py is about (1); enabling future software to coexist with an old platform as we transition away from an old ways of doing things.

It's important we have an open discussion about it I think. Spontaneously, I think I would rather see the kind of project you have in mind as a separate project, as it would likely come with its own conflicting requirements.

The benefit with what you are looking for is, as you say, a direct mapping for old software to run on a new platform. But there is a limit to how far we can take this. At some point, there will be new technology that will be unable to faithfully replicate old behaviour.

What that means for an organisation is that you can continue to run your legacy software on new technology, such as Maya 2017. But at some point you will be back to where you are today and will again have to refactor. Only this time you are in even deeper trouble due to hoop jumping through compatibility layers.

As such, my stand on the topic is that this feature would not solve as many problems as it would create. That it would postpone the inevitable. As a compatibility layer it is this project's responsibility to ensure a long-lasting, maintainable and future-proof product.

That said, I am open to letting the conversation that follows determine which route to go.

from qt.py.

Well, the perspective I was talking in is that currently there might be legacy software that doesn't need an update to pyside2 module structure but still needs to be able to run in a pyside2 environment. A case of this could be time investment in the software is not really feasible, and can just run it as in till its end of life with the features it provides. Like you said there is obviously a limit on how far we can take this, as expecting things to remain the same all the time, not the right mentality to have in any context.

I agree with you when you say that this feature will postpone the inevitable, but it also will give the devs the ability to make a choice for backwards compatibility as much as possible, until the codebase is no longer able to sustain it.

So to sum it up, one can actively choose the direction required in the software,

1. Keep the software as is, without needing to change to qtWidgets, for the reason that the tool can gracefully reach its end of life.
2. Change to using qtWidgets as and when updates to the software are in progress, while still allowing the dev the freedom to keep part of the codebase in the old qtGUI style.
3. Create all new software using qtWidgets, with backwards compatibility to pyside1. This criterion is already fulfilled with Qt.py

I am also no to clear if this should be a separate tool on not, therefore this discussion.

I feel that this functionality should be optional so that we don't remap things when someone doesn't really need it. The first thing that comes to mind would be something along the lines of QT_PREFERRED_BINDING where another EV can be used QT_COMPATIBILITY_MODE.

from qt.py.

@artbycrunk I think this is a good idea, and is as correct to how we've done things already. Like Fredrik, I'm a bit unsure of how it can work alongside what we have currently however and think it might be better suited for a fork of the project.

If you then manage to implement it in such a way that it is mergable back into this project (and if that's what you'd prefe), then we could continue from there.

Alternatively, the second most promising way forward at this point is a pull-request so we can have a look at how it can work and point at specifics. Maybe it's all very possible after all. Less theory, more practice.

How does that sound?

from qt.py.