What's the current etiquette on answers to questions not specifying the exact version?

I'm thinking of few options in order of my personal preference:

  1. Always add a disclaimer "oh yeah, this works only in v X.Y or newer"
  2. Assume at least 2.6 (no one in their right mind can be running a version older than that, can they?)
  3. Assume at least 2.7 (no one should be running older than that, am I right?)
  4. Go straight for 3.x (that's how Guido would like it, right)
  • 9
    If you don't want to assume, include the version you are talking about in your answer. Better yet - give an answer that includes each major version that you think is relevant.
    – Oded
    Apr 10, 2013 at 18:40
  • 4
    @Oded I find that to be overly verbose in practice, unless you're using something dependent on the release from this past week or something like that. If you are using too new of a version the code won't compile for the OP and they'll indicate so in a comment. The world doesn't end.
    – Servy
    Apr 10, 2013 at 18:43
  • 1
    @Servy - It certainly could be overly verbose, but definitely, if your code will work on a specific version you should mention that.
    – Oded
    Apr 10, 2013 at 18:44
  • when you AssUMe, you make an Ass out of U and Me Apr 10, 2013 at 20:00

5 Answers 5


If no version is specified use whatever version you want.

If the OP is in fact using an older version and your code ends up not working they'll end up commenting stating that it doesn't work because they're still on version X.Y. You can then either delete your answer, or edit it to support X.Y-.

If you find that you're frequently being asked to provide an older version then your first guess is clearly too optimistic, consider "defaulting" to an older version for a while.

  • 1
    +1 for your last paragraph.
    – mgilson
    Apr 10, 2013 at 19:40

Actually - this is one of the things that some of us in the Python community are trying to work out, and are hoping to actually produce a "HowToAsk" section for the Wiki (not that anyone will probably read it, but still...)

Rule of thumb: if in doubt - clarify by commenting

Other than that:

I would personally "assume" that 2.5 (unless otherwise stated) is the least version that's running (and for most distros and installs, it's probably 2.7 then 2.6) - some web hosts/variations of certain *nix distro's are somewhat out of date (or are on LTS)).

There's some subtle hints that can be used to identify a minimum version that's in use... (Of course this does rely on the OP supplying code -- in no particular order and by no means exhaustive - some of these are):

  • The use of str.format implies 2.6+. The use of {} {} (without positions) implies 2.7+
  • collections.Counter / collections.OrderedDict implies 2.7
  • Use of izip, ifilter, imap etc... imply some 2.x version
  • While use of zip_longest implies a 3.x version
  • Use of print as a function probably implies 3.x, unless it's 2.6+ with a from __future__ import print_function
  • Use of itertools.combinations or itertools.permutations implies 2.6+, while compress and combinations_with_replacement implies 2.7+
  • The with a as fst, b as snd: syntax implies 2.7+
  • The use of file as a synonym for open implies a 2.x series
  • Importing reduce from functools most likely implies 3.x (although nothing to stop one doing that in 2.6+ to be forward compatible)
  • Use of xrange is 2.x
  • Forcing materialisation such as list(map(whatever, some_seq)) implies either 3.x or the possibility of a from future_builtin map, filter etc... in 2.6+
  • References to basestring / unicode / long suggests 2.x
  • Number literals with an L suffix are 2.x as no longer valid in 3.x
  • defaultdict is 2.5+
  • The use of abc or numbers modules are 2.6+
  • The use of dict.viewkeys (or dict.viewitems ...) implies 2.7. Using set operators with dict.keys implies 3.x
  • actually print(whatever) is perfectly valid syntax without future imports, but true, it still implies that the OP is at least aware of 3.x
    – Kimvais
    Apr 10, 2013 at 20:13
  • and counterindications, dict.has_key() implies < 2.6
    – Kimvais
    Apr 10, 2013 at 20:16
  • @Kimvais print(a, b, sep='|') requires future imports - but yes - print(a, b, c) will work in the 2.x series - but is rarely used as such... Apr 10, 2013 at 20:17
  • Yes. And whenever you do print(1) instead of print 1, you probably should always do the future import nevertheless, because in any case you will be writing that print(foobar, file=sys.stderr) eventually on your 2.x code...
    – Kimvais
    Apr 10, 2013 at 20:20
  • @Kimvais errr dict.has_key is valid in the 2.x series, and either implies code written before 2.3 (when the key in dict syntax became available) - or someone not aware of using the in syntax.... But does imply it's definitely not the 3.x series where it was removed... Apr 10, 2013 at 20:20
  • Wow, you figured out what I meant even when my comment was incoherent and actually incorrect :D
    – Kimvais
    Apr 10, 2013 at 20:21
  • 4
    @Kimvais: we get to practice that skill a lot when answering questions on Stack Overflow :-P Apr 10, 2013 at 23:25

Always add a disclaimer "oh yeah, this works only in v X.Y or newer"

Unless the version is already specified, doing this causes no harm.

Assume at least 2.6 (no one in their right mind can be running a version older than that, can they?)

Um, yes (and this one).

Assume at least 2.7 (no one should be running older than that, am I right?)

Yes, this this one to.

Go straight for 3.x (that's how Guido would like it, right) Not yet.

You cannot assume that anyone's running version 3.x. It's simply not going to be true. If you're going to assume something assume someone's running 2.7 and then use the fact that there are a lot of features that are compatible between 2.7 and 3.x.

My company runs every version between 2.4 and 2.7; no one has the time or the capacity to re-write tens of thousands of lines of code that have worked for years. There's no need. There'll be plenty of others who've done the same, but where some new requirement suddenly causes them a problem. Consider try ... except ... as error in Python 2.5 - Python 3.x, for example.

If what you would answer is version dependent, you essentially have three options. In order of descending usefulness:

  1. Ask. Comment saying "There are certain features that could be used in version 3 to solve your problem. Which version are you using?". I understand that in the cut-throat world of answering this isn't always an option (Here's looking at you Martijn).

  2. Write up an answer for 2.7 and 3.x These are the most likely versions that the OP will be using anyway. Be sure to label them and make the 2.7 answer 3.x compatible so that you may only need to write it once.

  3. Your point 1. Add your disclaimer and be wary of downvotes when someone else does point 1 or 2.

  • 1
    Hey, I ask for a version clarification often enough :-) Apr 10, 2013 at 23:29

I don't like making a habit of assuming the version that a person is asking questions around. I can certainly infer what version they're using, but even then that's not entirely concerete.

If you're uncertain, ask for clarification. If you're fairly confident in your inference, give an answer. Don't just blindly assume.


If your answer depends on a specific feature that only applies to X.Y version, say so. (For instance, namespace in PHP is only available from 5.3+).

If you can afford not using a feature to help with backwards compatibility, go for it (Use array(1,2,3) and not [1,2,3])

  • 1
    While I find that there's nothing wrong with doing this; in practice I find most people don't when a feature has been out for quite some time, and I don't think that's a bad thing. If for some reason running the provided code on an older version would result in hard to diagnose problems (i.e. rely on a more silent bugfix, rather than using a module that didn't exist before version X) then saying so is more important.
    – Servy
    Apr 10, 2013 at 18:44

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