| 1 |
On Thu, 20 Apr 2017 10:49:04 -0700 |
| 2 |
Christopher Head <chead@×××××.ca> wrote: |
| 3 |
> |
| 4 |
> >If your writing new python code against say 3.4 and not 3.6. Not sure |
| 5 |
> >about that... Seems like it would keep things bound to older versions |
| 6 |
> >and never let things move forward. |
| 7 |
> |
| 8 |
> Not true. I will certainly move forward when a newer version becomes |
| 9 |
> stable. |
| 10 |
|
| 11 |
Stable according to whom? Gentoo or Python? |
| 12 |
|
| 13 |
Take Ansible as an example. Any contributions must work in both 2.7 and |
| 14 |
3.x. While I think they require 2.7. Any modifications must also be |
| 15 |
good for 3.x. Its forward looking. |
| 16 |
https://docs.ansible.com/ansible/dev_guide/developing_python3.html |
| 17 |
|
| 18 |
> >Usually when writing new code, you use the latest version of stuff. |
| 19 |
> >Not always but usually best. If anything make code support older |
| 20 |
> >while targeting newer. |
| 21 |
> |
| 22 |
> No, not how I develop. |
| 23 |
|
| 24 |
It is how other projects, some rather large like Ansible are addressing |
| 25 |
the issue. |
| 26 |
|
| 27 |
>I always start by determining my target |
| 28 |
> audience and then develop using a feature set that allows my target |
| 29 |
> audience to use the code as easily as is practical. I wouldn’t use a |
| 30 |
> syscall introduced in kernel 4.9 if I could avoid it, even if it made |
| 31 |
> my code simpler, because most of my colleagues run Ubuntu LTS, they |
| 32 |
> are part of my target audience, and it wouldn’t be available there. |
| 33 |
> To me, responsible development practices mean NOT forcing my target |
| 34 |
> audience to do a manual kernel build. Eventually the syscall will be |
| 35 |
> “generally available” to my target audience, at which point I may go |
| 36 |
> back and change the code. |
| 37 |
|
| 38 |
Interesting you mention Ubuntu LTS, as that is specifically mentioned |
| 39 |
on the Ansible python FAQ. |
| 40 |
|
| 41 |
> I wouldn’t build conditional branches that do it either way if I |
| 42 |
> could possibly avoid it, either, because then I would have to do all |
| 43 |
> the work of doing it the old way plus more, and it would also be more |
| 44 |
> code which means more maintenance. |
| 45 |
|
| 46 |
That is a result of the language of choice. Why I do not bother doing |
| 47 |
anything myself with Python. I am forced to with Ansible till an |
| 48 |
alternative in another language comes about. |
| 49 |
|
| 50 |
> >Because you are not setting or dealing with the targets. You went |
| 51 |
> >with the mindless approach. Like doing a wildcard on USE flags. |
| 52 |
> |
| 53 |
> Yes, exactly. I don’t want to manually choose what version of Python |
| 54 |
> I have installed, even though I sometimes do Python development. |
| 55 |
|
| 56 |
That addresses 2 of the issues right there. You do not care what |
| 57 |
version of Python you have. Most any systems administrator does care |
| 58 |
about what version of things are installed. Not to mention what is |
| 59 |
installed. Like hardended binary systems, tend to not have gcc, etc. |
| 60 |
|
| 61 |
I am doing some python dev for Ansible. But also having to package some |
| 62 |
python stuff, and do not like it from either user, developer, nor |
| 63 |
packager perspectives. |
| 64 |
|
| 65 |
>Just |
| 66 |
> like I do a lot of C/C++ development, but I don’t want to manually |
| 67 |
> choose which version of glibc I have installed. Or libfoo, for some |
| 68 |
> foo. That’s what a depgraph is for, and if I do need some specific |
| 69 |
> thing, then I will ask for it, but not before. |
| 70 |
|
| 71 |
If you were targeting embedded and working with others like ulibc, etc |
| 72 |
then you may care. But that is interesting for anyone to be coding not |
| 73 |
caring about versions etc. |
| 74 |
|
| 75 |
I do Java dev mostly and some C. I do very much care about versions of |
| 76 |
stuff when coding. In C I have to write ifdef, etc for such. In java |
| 77 |
slotting and making sure using the right version. |
| 78 |
|
| 79 |
Only Go language seems to not care about versions, just pulling live |
| 80 |
from major versioned branches. Most everything else is versioned for a |
| 81 |
reason. |
| 82 |
|
| 83 |
> >Your enabling support for all versions across the board for anything |
| 84 |
> >that supports it. That is quite a different experience if you go |
| 85 |
> >trying to use a specific one. |
| 86 |
> |
| 87 |
> I’m not trying to invalidate the pain that some people experience, |
| 88 |
> just pointing out that I think it may be inaccurate to call that the |
| 89 |
> “ordinary user” use case. |
| 90 |
|
| 91 |
That you are on -dev mailing list. Not sure that would put you in the |
| 92 |
normal use category. Though there are normal users who run ~arch. They |
| 93 |
would experience such issues. It is different on stable, as I do not |
| 94 |
believe there is as many. |
| 95 |
|
| 96 |
-- |
| 97 |
William L. Thomson Jr. |
Archives