The release of QGIS 3 has brought many updates, one significant change is its Python bindings or as it's more commonly known as PyQGIS. I have noticed the recent introduction of the tag, here is a quick comparison with the number of posts with the original tag as of today:

I was wondering whether these two tags should be merged so that it is the equivalent to where the version of the main software makes no difference?

  • did the python version in any arc product change? if not I think this would be a bad example as pointed out by @tinlyx – LaughU Jul 4 at 6:56
  • 2
    @LaughU yes - Desktop=>Pro (10.x=>"11.x") went Python 2.x=>3.x in exactly the same way as QGIS 2.x=>3.x seems to have gone Python 2.x=>3.x – PolyGeo Jul 4 at 8:12
  • 1
    @PolyGeo thanks for pointing this out. In that case, josephs example is correct although I disagree that they should be merged and instead think, there should be an arcpy3 tag – LaughU Jul 4 at 8:34
  • @LaughU Why? ArcPy for Pro has one extra module (arcpy.mp) but otherwise ArcPy runs near identically in Python 3.x as it does in Python 2.x. In general I think the community favours fewer rather than more version tags. – PolyGeo Jul 4 at 8:45
  • @PolyGeo If this is the case for arcpy then I have to agree with the fever the better but for pyqgis this is not the case due to the new bindings which will break the code – LaughU Jul 4 at 9:08
  • Is it technically possible to change the pyqgis tag to the pyqgis2 tag and the pyqgis3 to the pyqgis tag? That would be option too... – Orienteerix Jul 13 at 5:42
  • 1
    @Orienteerix Yes - technically that is very easy to do using the moderator tools. – PolyGeo Jul 13 at 5:54
  • should this maybe be treated synonymous to this thread concerning the qgis[-x.x] tags? I'd generally prefer a (strict) separation and possibly no version-less tags at all; the road to confusion is too tempting and API changes (specifically for QGIS*/*pyqgis) too breaking IMO. – ThingumaBob Sep 18 at 20:31

I would argue that should not be a synonym of because with QGIS 3, pyqgis uses python3 and Qt5 (as compared to Python2 and Qt4).

The difference is significant, and there are many breaking API changes so that answers to the two tags may not be compatible. If only one tag is used, there will be confusion.

In a similar situation for openlayers, and coexist. Maybe something similar is applicable here..

  • Thanks for your answer, this was something I also considered but was interested to see what the community thought :) – Joseph Jul 6 at 10:47
  • A common practice with software is semantic versioning where a major version number change - e.g. 2.x to 3.x - allows for API changes which are backwards-incompatible. As such, older answers which worked in 2.0 may no longer work. That's certainly the case with QGIS where the API underwent a major refactoring. (I seem to remember there were similar breaking changes from 1.x to 2.x) – Steven Kay Jul 8 at 15:19

I'd agree that should be a synonym of , and you should suggest it (I don't have enough pyqgis rep to do so myself). but we'll need a mod to create it since SE thinks it's a version specific tag.

After that, it could be merged like the other synonyms we have, although possibly at a later date.

  • 1
    Thanks for your answer. I tried to suggest it but received the following message: Version specific synonyms can only be created by moderators. Guess it can only be done by higher-ups :) – Joseph Jul 3 at 14:50
  • 1
    Ah, apparently SE explicitly filters out tag synonyms with numbers in them. I could see that being an issue on larger sites, especially SO. – Evil Genius Jul 3 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .