You don't. The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code.
If you don't write special in your code, Perl doesn't have a "say" method (because it didn't have one in Perl 5.8). If you declare in the code that you're code for Perl 5.10, magically there are all the Perl 5.10 features, including "say". You can also declare you want specific features, rather than declare a specific Perl version.
$ perl -v | head -2 | tail -1
This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-cygwin-threads-multi
$ perl -e 'say 1'
Number found where operator expected at -e line 1, near "say 1"
(Do you need to predeclare say?)
syntax error at -e line 1, near "say 1"
Execution of -e aborted due to compilation errors.
$ perl -e 'use 5.010; say 1'
1
$ perl -e 'use feature "say"; say 1'
1
The best thing about this is you can mix and match libraries from earlier and newer Perl versions. If a library says they want Perl 5.10, they get Perl 5.10, even if you want both Perl 5.30 and that library.
If only Python were as reliable for backwards compatibility.
The Perl community is going through their own Py2->3 moment, and they're doing it with great care. They're going to create Perl 7, which will be Perl 5 where the "defaults" make the language look more like Perl 5.32 rather than Perl 5.8 [1]. Modern Perl scripts don't need so much boilerplate to enable modern features. They know exactly the trouble this will cause; if Perl 7 ever becomes the default Perl interpreter, the only one, it _will not run_ lots of very old Perl scripts untouched, because the defaults will make years worth of language changes suddenly visible to those scripts. Even if the fix is just to slap "use 5.008" on every script, they worry about it. That's a much better attitude than the Python developers.
> The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code
> That's a much better attitude than the Python developers.
You do realize that this comes at a cost, right?
A lot of decisions in Python3 (and further) are based on the desire to keep the interpreter simple.
Python Core Team doesn't have unlimited resources, and even if they did, the cost of complexity grows non-linearly.
py2 -> py3 transition did not go as planned, but that doesn't mean that following Perl route would have had better outcomes.
That means the piece of software will work also in the future.
Personally I only use python for throwaway scripts. Whatever is written in Python likely won’t work in 10 years anymore. So they’re all lost in time. Whereas I can continue some of my C++ eternity projects and they still work perfectly fine.
That's terrible practice.