# EOL Python 2.7 issues



## Juronski (Dec 15, 2019)

Hi Forum,

With the upcoming EOL of Python 2.7 we realized that for years to come we can not do and we do not want to do without Python 2.7. 

Information about how FreeBSD is dealing with the EOL Python 2.7 is hard to find. Does someone know more about the future plans for Python 2.7 on FreeBSD? Please share. Python 2.6 is also still in the ports collection.

There is Tauthon as fork of Python 2.7, but it is not in the ports collection yet. Tauthon would be able to run most Python 3.x code in addition to running all the 2.7 code. So almost no need for Python 3.0.

Tauthon can reduce the pressure on core-development when it is in the ports collection and made compatible with PIP. 

Tauthon is on the list wanted ports. According to the list wanted ports Tauthon should be as easy to port as simply cloning lang/python27 into lang/tauthon; it will according to the list need additional integration with PYTHON2_DEFAULT to remove requirement that "python" be in the name.

How to support Tauthon becoming a port in the FreeBSD Ports Collection so long-term support for this fork of the Python 2 programming language, with backported features from 3.x , is guaranteed on our preferred BSD? There are some linux-distro’s that are preparing for Tauthon but we want to stick with FreeBSD. We do not want to migrate to Linux to be able to run Python 2.7 software for ever.

Thank you,
J.


----------



## ralphbsz (Dec 15, 2019)

This is really not a FreeBSD question. Core FreeBSD does not even install python, it is a port/package that users are free to install if they want, but they don't have to.

Therefore, your argument "Tauthon can reduce the pressure on core-development ..." seems tenuous: core development has nothing to do with Python.

I find the whole debate silly anyway. Python 2.X will not suddenly vanish, it will just not get any updates (not even security updates) starting in January. If you have Python 2 applications, the will continue to run fine, but you may have to security isolate them. Which is a good idea in the first place: Those security holes that exist today and that will NOT be fixed starting in January already exist today, and can already be exploited, so the absence of security updates in the future doesn't actually make them less secure, it just fails to make them more secure.

Furthermore, in my experience porting Python applications from 2 to 3 is typically very easy. I would guess an hour per 1000-2000 lines of source code (in addition to 2to3 doing the heavy lifting). Given that software is expensive to develop and to maintain, this is not a large factor.

But if in your opinion tauthon is a necessary ingredient, feel free to volunteer for the port. Don't expect other people to volunteer to make your life easier.

(I have several 10K lines of home-written Python, in addition to way more that I do at work. At work, the move from 2 to 3 started a long time ago, and AFAIK has been finished several months ago. At home, I just ported the next-to-last application during the Thanksgiving weekend. There is one application with 3K lines that I won't port for a few months, it can continue running in Python2.7, since it is completely security isolated on a host that has air gaps.)


----------



## rigoletto@ (Dec 15, 2019)

In short, FreeBSD will not keep Python 2.7 and everything depending on it will leave togheter; however, as far I know, this is still not defined if that will happen when Python 2.7 reach EOL or if it will be kept for while.

I guess if there is something *important* depending on Python 2.7 that will be kept for a while to give time to be ported to 3.x; however I would not expect to that be kept for too long either.


----------



## Juronski (Dec 15, 2019)

ralphbsz said:


> core development has nothing to do with Python.


Core development has to do with users of Python. Because of the EOL of Python 2.7 these users have to invest in 1000-2000 lines per hour for porting to Python 3 to be able to run software (that runs fine on Python 2.7) with security updates from upstream for the base language of this software. Those users need now to learn Python 3 and invest in 2to3. Where for? The EOL of Python 2.7 kills business on the web.


ralphbsz said:


> But if in your opinion tauthon is a necessary ingredient, feel free to volunteer for the port. Don't expect other people to volunteer to make your life easie


Tauthon can make everybody's live easier. With Tauthon there is no need for Python 3. So everybody can always use Python 2.7 with security updates and benefit from the Python 3 features from one and the same python prompt. I do not experience added value from Python 3.


rigoletto@ said:


> if there is something *important* depending on Python 2.7 that will be kept for a while to give time to be ported to 3.x


This also makes a point in favour of Tauthon. Porting to an other language is not needed with Tauthon. In a couple of years this is all gone happen again with Python 4.


----------



## rigoletto@ (Dec 16, 2019)

Juronski said:


> Core development has to do with users of Python. Because of the EOL of Python 2.7 these users have to invest in 1000-2000 lines per hour for porting to Python 3 to be able to run software (that runs fine on Python 2.7) with security updates from upstream for the base language of this software. Those users need now to learn Python 3 and invest in 2to3. Where for? The EOL of Python 2.7 kills business on the web.



To make that simple, FreeBSD is not involved with Python development nor it is in Base then this is a portmgr subject, and they are responsible by the ports system management and not the relation between users and third party software management.

That said, when upstream EOL something, specially when that was noticed with relative advance, that software should leave except if there a very good reason to not, and for the least amount of necessary time.

When that is a minor/irrelevant software that just need a maintainer things may be different because those are minor/irrelevant things. Python involve a ton of effort to maintain and no one is willing to maintain something like that.

Also, Python3 was launched several years ago and then python developers had all the time in the world to learn it and port everything they need to it.

In regards to Tauthon, I had never heard of it but since anyone can maintain a port, you can port it, add to the tree and maintain it.


----------



## ralphbsz (Dec 16, 2019)

Juronski said:


> Core development has to do with users of Python.


Sorry, no. Core development has to do with the base OS. Python is not part of the base OS. FreeBSD, as it ships, does not come with Python.

Users are free to install it, from ports or packages. When they do, they need to evaluate the risk of installing software that will become obsolete.



> Because of the EOL of Python 2.7 these users have to ...


That is true on every OS. If you want to use Python, as shipped by the Python foundation, you will either use a version without security fixes, or port to Python 3.



> The EOL of Python 2.7 kills business on the web.


The EOL of Python 2.X has been known for about 10 years. I think about 2010 or so the Python foundation gave a warning that support for Python 2 would end in 2015. When that got close, they changed the end of support to 2020. You have had somewhere between 5 and 10 years of warning. You failed to deal with it. At that scale, that is not Python's problem, nor FreeBSD's problem. If the Python foundation had given you a week or a month of warning, I could understand that you are upset (and even then you would have had no recourse), but with many years of warning, you are being silly.



> Tauthon can make everybody's live easier.


Then feel free to perform the port. Anyone can do that. 


> In a couple of years this is all gone happen again with Python 4.


I doubt that the transition of 3 -> 4 will be similar to the 2 -> 3 transition, but that is at least a decade in the future.

Most importantly: Remember, this is free software. Can you show us the contract you signed where it says that in exchange for your money, someone will provide support? No you can't. FreeBSD is maintained and developed by volunteers. Become one of them, if you want to have a say in decisions going forward. Or hire someone to do it for you. Or donate.


----------



## Juronski (Dec 16, 2019)

ralphbsz said:


> Most importantly: Remember, this is free software. Can you show us the contract you signed where it says that in exchange for your money, someone will provide support? No you can't.


The EOL of Python 2.7 looks like a way to make people pay for Open Source Software. People are allowed to build there setup with it, but when it is done you need to hire a developer to migration to Python 3. We can not build our setup on Python 3 because everything we need is written in Python 2.7, and is not gone be migrated by upstream. There is no need for the EOL of Python 2.7. Python 2.7 is perfect. Python 2.7 has no known security issues. 


ralphbsz said:


> Then feel free to perform the port. Anyone can do that.


If anyone can do it I am gone look in to it. Thank you.


----------



## Remington (Dec 16, 2019)

I generally stay away from any applications which developers didn't bother to migrate to Python 3.  It clearly shows that developers aren't serious about maintaining their application or abandoned their application especially after 10 years of being warned of approaching EOL.  They had plenty of time to do it and it's not FreeBSD nor port maintainers' fault.  Usually any apps in ports that hasn't been updated or maintained will eventually be removed.


----------



## Juronski (Dec 16, 2019)

Remington said:


> I generally stay away from any applications which developers didn't bother to migrate to Python 3. It clearly shows that developers aren't serious about maintaining their application or abandoned their application especially after 10 years of being warned of approaching EOL


Python is not like PHP with all kind of security issues that need to be fixed. Python 2.7 is perfect. There is no technical and no security reason for Python 3. I get the same site on Python 3 as I have on Python 2.7. It is foolish to rebuild an application that works perfect with no issues because of decisions made upstream. Do you also rebuild your house because there are new tools to build it? That is why I like the idea of Tauthon. Tauthon is Python 2.7 with features from Python 3. So you create your software once with Tauthon and add new features later without the need to port to a new language. Without being forced to invest in migration every couple of years because someone think of something new to add to the language.


----------



## SirDice (Dec 16, 2019)

Juronski said:


> Python is not like PHP with all kind of security issues that need to be fixed.


Right...






						Python Python version 2.7 : Security vulnerabilities
					

Security vulnerabilities of Python Python version 2.7 			List of cve security vulnerabilities related to this exact version. 			You can filter results by cvss scores, years and months. This page provides a sortable list of security vulnerabilities.



					www.cvedetails.com


----------



## Juronski (Dec 16, 2019)

SirDice
The issues you refer to are not the reason for Python 3. There is no need for Python 3 because of those issues. We need security updates for that, no new language. Python 3 shall nothing gone change about that kind of issues.


----------



## Remington (Dec 16, 2019)

Juronski said:


> Python is not like PHP with all kind of security issues that need to be fixed. *Python 2.7 is perfect*. There is no technical and no security reason for Python 3. I get the same site on Python 3 as I have on Python 2.7. It is foolish to rebuild an application that works perfect with no issues because of decisions made upstream. Do you also rebuild your house because there are new tools to build it? That is why I like the idea of Tauthon. Tauthon is Python 2.7 with features from Python 3. So you create your software once with Tauthon and add new features later without the need to port to a new language. Without being forced to invest in migration every couple of years because someone think of something new to add to the language.



That's an absurd statement.  Always assume there are security exploits to be found which hasn't been discovered yet.  If you want perfect security then disconnect your internet.


----------



## SirDice (Dec 16, 2019)

Juronski as several people have already pointed out, it's not FreeBSD's call. Whenever something is EoL'ed upstream we always end up with the same pointless discussions. If you have a problem with the impending EoL of Python 2.7 you're more than welcome to state your case to the Python developers. Good luck with that. 

Simply put, if/when something goes EoL upstream it's EoL for us too. There's nothing to discus here.


----------



## Juronski (Dec 16, 2019)

SirDice said:


> it's not FreeBSD's call.


You are right. It is an users call. The Python developers are not helpful. Not willing to discuss the issue of the EOL. There is a kind of hostility. Almost immediately received insults form the admin of the forum of the Python Community because I started a thread there about this. It is an EOL without added value. It feels like being trolled. I want to draw the attention to the issues because of this EOL, and that there is no need for always the same pointless discussions when something is EoL’ed upstream. Technically and security wise there is no need for the EOL of Python 2.7. 

Python 2.7 is perfect enough to live for ever. It is good enough to even have Python 3 features. The EOL of Python 2.7 is a fact. There is also the problem that PIP en Virtualenv are not compatible with Tauthon. So there is no likewise alternative for the EOL of Python 2.7 on FreeBSD. Some Linux-distro’s already move to Tauthon. To me Tauthon looks like an alternative that can provide all FreeBSD users with best of all worlds (if also the compatibility with PIP and virtualenv is fixed). With Tauthon everybody can have Python 3 features in a Python 2.7 environment. So no need for an EOL discussion what so ever. People who really need all the output of Python 3 are free to use it without forcing all other users in to it.  


SirDice said:


> if/when something goes EoL upstream it's EoL for us too


This is also true. I want an upstream that does not EOL Python 2.7.X. PyPy also does not EOL its 2.7. So maybe I thought more users feel this way so we can make an effort to make all the users happy with an Python 2.7 that does not EOL itself. Because of the EOL of 2.7 I want to promote a Tauthon-port and make awareness for the need. Do not know if I am skilled enough to maintain a Tauthon port, but I am gone look in to it. Contribute if you also want to make an end to always the same pointless discussions whenever something is EoL’ed upstream by the Python Community.


----------



## Remington (Dec 17, 2019)

Juronski...  it's not your call to make and Python is not yours to begin with.  It's the developer's decision to discontinue support so they can focus on making Python 3 better and focus on developing version 4.  It's absurd to waste so much resources and time on something that's outdated.  I'm a Java developer and I would rather work with latest tools to simply my development time and I wouldn't want to get left behind with ancient tools.  If someone have a job interview and employer asked the prospective employee if they worked with Python 3 and he/she said no... do you think the employer will hire someone with Python 2 skills when the company is using Python 3?  Probably not if they don't have the time or money to train the prospective employee to bring him up to Python 3 level.

Also system admins don't like having multiple Python versions on their server since it's add more workload to keep all the software up to date.

Like SirDice said, there's nothing more to discuss so if you want to complain about Python's EOL then you need to go directly to Python website and complain there.  FreeBSD has NOTHING to do with it.


----------



## Crivens (Dec 17, 2019)

Juronski said:


> Contribute if you also want to make an end to always the same pointless discussions whenever something is EoL’ed upstream by the Python Community.


You mean every 10 years? And if this discussion comes around again in 10 years, I'll happily laugh at any fool who fell into this trap twice. And yes, this goes for swift also.


----------



## memreflect (Dec 18, 2019)

Just gonna leave this here for those 2.x'ers who run across this thread and are interested in migrating their code to 3.x1:



> To make your project be single-source Python 2/3 compatible, the basic steps are:
> 
> Only worry about supporting Python 2.7
> Make sure you have good test coverage (coverage.py can help; `pip install coverage`)
> ...



1 I feel Tauthon is useful as a migration tool to Python 3 and should not be regarded as endless life support for Python 2 code that nobody wants to port to Python 3+.


----------



## ralphbsz (Dec 18, 2019)

Juronski said:


> Technically ... there is no need for the EOL of Python 2.7.


I respectfully disagree. The Python developers need to spend more time on things that go forward, and less time on doing trailing maintenance on a version that has been obsolescent for 10 years. It's their decision to make, and in my opinion they are smart and experienced enough to make the right one. It's not like folks didn't get enough warning.



> Python 2.7 is perfect enough to live for ever.


As is IBM 360 assembly and Autocode. All perfectly fine programming languages, capable of writing useful programs, yet abandoned by their creators (in these examples, abandoned about 60 years ago, although one can still write 360 assembly today and run it on a Z, but nobody does any more). Just because something *can* live forever doesn't mean that it is a good investment of the maintainers time to make it live. And software doesn't survive on its own, it needs continuous maintenance in this day and age.



> To me Tauthon looks like an alternative that can provide all FreeBSD users with best of all worlds ...





> So maybe I thought more users feel this way so we can make an effort to make all the users happy with an Python 2.7 that does not EOL itself.


Quite possibly true. There is nothing that prevents a random group of people from building a Py2.7-compatible runtime that they want to maintain. It might be a great idea, or it might be a horrible idea (if they do a bad job). If someone wants to volunteer for porting Tauthon (or an alternative Python runtime) to FreeBSD and put it in ports, great. If lots of people think it's a good thing, it will happen as volunteers are found. My personal opinion (from writing and using LOTS of python code, these days it's my main programming language, and from living in Silicon Valley and talking to technology people over coffee): All the serious users started moving to Py3 years ago, and the porting process is done. I've heard from several friends that they turned their Py2 environments off a few months ago as a test, to make sure everything will be ported, and didn't experience problems. At home I'm less strict, but the transition seems to be a non-issue to most.

By the way, what ever happened to Jython? I used to run it (when it was still called JPython) from ~96 to 99, and was pretty happy with it back then. If it is still actively maintained, it might be a good alternative to Tauthon.


----------



## Juronski (Dec 18, 2019)

Sinking deeper and deeper in this EOL rabbit hole I noticed that things are just not true about the statements on python3statement.org. The statement is that Python 3 is needed “_to simplify our code and take advantage of the many new features_”. First of all: new features can be backported to Python 2.7. And modules improved in Python 3 can also be improved in Python 2.7. The new-features-statement about Python 3 is false. 

Than simplicity. 

The print function is the most widely known change in Python 3. If you look in to the print function the code is not made more simple in Python 3. It is made more complex. In Python 3 you have to code more to get the same output. So where is the EOL of Python 2.7 really about? Who is really taking advantage? IMO the EOL of Python 2.7 is to make admins go bananas so there bosses pay for development. See for your self:

Print in Python 2:
code: print 'Python', python_version()
output: Python 2.7.6

Print in Python 3:
code: print('Python', python_version())
Output: Python 3.4.1

What a fool I must be to believe that live is simpler now with Python 3.


----------



## kpedersen (Dec 18, 2019)

Juronski, I kind of see where you are coming from, I am not a fan of having to ditch a platform because the upstream are effectively deciding to work on another project with the same name (Python 3). However Python2 -> Python3 is not quite like VB6 -> VB.NET; it is an evolution rather than a rewrite. It is very possible to migrate your code. You will probably want to do so before Python 4 comes out and the gap will be larger 

But to be honest, your code isn't the issue; as a Python developer you probably have loads of dependencies on random libraries through PIP? These will all inevitably migrate (if they haven't already done so) to Python 3. So you will either be planning to keep with the older (potentially vulnerable) dependencies or you are hoping that *tauthon* will be providing an adapter between the old and new implementations of Python? In that case your future solutions will be depending on both Python 2.x and 3.x scripts? That isn't very elegant.

When Python 4 comes out, can you garantee that Tauthon will also migrate to that and provide backwards compatibility for 3 and 2?

If you don't like the (almost disposable) nature of Python, you might consider a more stable language like C, C++ or Java.

Note that Perl was in the fairly rare position that the community rejected Perl 6 and kept with Perl 5 so Perl 6 had to fork. You might like to jump ship to Perl (5) for your next project since that community seems to be a little bit more stubborn (which is certainly not a bad thing IMO).


----------



## kpedersen (Dec 18, 2019)

Juronski said:


> Print in Python 2:
> code: print 'Python', python_version()
> output: Python 2.7.6
> 
> ...



As a python newbie, I would assume *print* is a function. Likewise something like *getAge(name)* could be a function that returns a number. You would use it like?:


```
print(getAge "bob" )
```
Or possibly:

```
print getAge "bob"
```

No, it wouldn't work. Even in Python 2 you need parenthesis around the parameter:


```
print getAge("bob")
```

Why do we need a parenthesis around _"bob"_ and not the parameters to print? So there seems to be a rule in Python 2 when you do and do not need a parenthesis around the parameter. Possibly it is if you do not need to use the returned value? Who knows? I imagine most developers just add the parenthesis regardless to play it safe.

This is an example where Python 3 is a little cleaner.
Possibly not "easier" for those used to Python 2 but it is more *consistent*. As you know, consistency and developer sanity are often very much related XD.

But my post is getting off topic. Just because a language version might be better doesn't have any bearing on whether another language should be deprecated. I am also under the opinion that languages that break anything other than the standard library are... crap and backwards compatibility is the least of your worries


----------



## shkhln (Dec 18, 2019)

Juronski said:


> The print function is the most widely known change in Python 3. If you look in to the print function the code is not made more simple in Python 3.



Statement. The Python 2 print is a statement.


----------



## Juronski (Dec 18, 2019)

kpedersen said:


> you probably have loads of dependencies on random libraries through PIP?


A kind of yes. The libraries are chosen not randomly pulled in.


kpedersen said:


> These will all inevitably migrate (if they haven't already done so) to Python 3.


No they will not. 


shkhln said:


> The Python 2 print is a statement.


The Python 3 print is a function.

To enable the print() function in Python 2, you need to add this import statement at the beginning of your source code:

```
from __future__ import print_function
```

Again it proves that there is no reason to EOL 2.7.


----------



## shkhln (Dec 18, 2019)

Juronski said:


> To enable the print() function in Python 2, you need to add this import statement at the beginning of your source code



Thankfully, I don't have any Python code. I can't stand the language to the point I won't even consider software written in Python if there any alternatives.


----------



## kpedersen (Dec 18, 2019)

shkhln said:


> Thankfully, I don't have any Python code. I can't stand the language to the point I won't even consider software written in Python if there any alternatives.



Heh, running a Python program usually turns into a wild goose chase for a whole slew of dependencies. By the time I have managed to capture them all I am too exhausted to execute the actual program XD

I am not a fan of dependency focused languages. NodeJS, Python and (unfortunately) Rust are the worst offenders!


----------



## shkhln (Dec 18, 2019)

kpedersen said:


> Heh, running a Python program usually turns into a wild goose chase for a whole slew of dependencies. By the time I have managed to capture them all I am too exhausted to execute the actual program XD



Yes, that's one very compelling reason to avoid anything Pythonic.


----------



## Crivens (Dec 18, 2019)

The fun starts when you do medical software and can't produce statically linked binaries. The worst is then when you have to deal with code that is loaded from 'somewhere else'. Have fun with certification and/or when something goes wrong.


----------



## 20-100-2fe (Dec 18, 2019)

kpedersen said:


> I am not a fan of dependency focused languages. NodeJS, Python and (unfortunately) Rust are the worst offenders!



I've had the occasion to discover the sado-masochistic delights of NodeJS-based frameworks (Angular and React)...  

The only sensible explanation I found to the advent of such a mess is that IT has reached full maturity and the only way to achieve continued economic growth is through self-destruction and re-creation cycles. :/


----------



## ralphbsz (Dec 18, 2019)

Crivens said:


> The fun starts when you do medical software and can't produce statically linked binaries.


You can produce statically linked binaries of python code. It is not easy, and it is not efficient for small programs, but it is certainly possible.



> The worst is then when you have to deal with code that is loaded from 'somewhere else'.


That problem is the same in any language. If you use code in a certified product that comes from somewhere else, you need to worry about the certification of it. Whether you #include some <foo.h> files in C++ and then link against foo.lib, or whether you import foo.py makes in practice little difference.

One interesting difference is: In C++, you nearly always have a make file, and that make file makes the dependencies very explicit (although it is a bit hard to parse). In Java or Python you typically do not need makefiles, so dependencies need to be inferred from the behavior of the code at run time. And scripting languages where code can be dynamically generated make this non-obvious. The solution to this is either programming discipline (like a coding rule that says: all imports will be at the top of the file, before any executable code), or run the code in a specialized execution environment that requires a makefile-like system.

So I know it is possible to create statically linked python programs with fully explicit dependencies. One could wonder whether this is a good idea, or whether it is antithetical to the design spirit of the language, but that's a question of personal taste.


----------



## ralphbsz (Dec 18, 2019)

Juronski said:


> Sinking deeper and deeper in this EOL rabbit hole I noticed that things are just not true about the statements on python3statement.org. The statement is that Python 3 is needed “_to simplify our code and take advantage of the many new features_”. First of all: new features can be backported to Python 2.7. And modules improved in Python 3 can also be improved in Python 2.7. The new-features-statement about Python 3 is false.



Nonsense. You are looking at the wrong thing. Look at the viewpoint of Python developers: Anytime they backport something into Python2, they have to do extra work, and they end up with roughly twice as much code or code churn: the same feature has to be there twice. This is the exact opposite of simplicity. Keeping Python2 around and updated adds complexity, and it adds extra work. The Python developers have decided that the extra work is not worth it *TO THEM*. Therefore they will stop doing it. And I fully support them, because that decision is not capricious, it is sensible from an engineering point of view, and it had sufficient warning.



> The print function is the most widely known change in Python 3. If you look in to the print function the code is not made more simple in Python 3.


First, you are looking at it again from the wrong point of view. This is mostly about the complexity of the Python infrastructure (the thing the python developers worry about), not the complexity of your code.

Second:


> In Python 3 you have to code more to get the same output.
> ...
> Print in Python 2:
> code: print 'Python', python_version()
> ...


Other than one traililng closing paren, it is the same amount of code. You replaced one space (the one between the keyword "print" and the argument list) with an opening paren, which doesn't change either the complexity nor the amount of code (if measured in characters or lines), and you had to add one closing paren, which is a tiny addition to the amount of code.

But think about what you get: a simpler language, with one fewer keywords. From a developer viewpoint, every keyword adds having to think about the syntax, having to consider special cases (like what does a trailing comma mean, how do line breaks in parameter lists work). From a python implementor viewpoint, one fewer keyword simplifies the parser considerably.

Furthermore: that particular change (of adding parens around the argument list of print) actually causes developers nearly no work, since 2to3 handles it perfectly. The real work of the Python3 transition is elsewhere, for example in the bytes versus strings area (which was a very good change and way overdue, but one that can not be handled automatically).



> What a fool I must be to believe that live is simpler now with Python 3.


You want simple? BASIC still exists. You want productive?


----------



## Juronski (Dec 19, 2019)

ralphbsz said:


> The Python developers have decided that the extra work is not worth it *TO THEM*.


That is why I migrate to Tauthon as much I can. Tauthon does care about its users. Tauthon does more than Python does for more users with different needs.


----------



## 20-100-2fe (Dec 20, 2019)

ralphbsz said:


> In Java or Python you typically do not need makefiles, so dependencies need to be inferred from the behavior of the code at run time.



Maybe you forgot to append 'Script' to Java? 

In Java, you have Maven, Gradle and other similar tools to describe your project structure, including dependencies, and your have a central repository for open source libraries. Furthermore, Java is a strongly typed language, which significantly reduces developer stress factors. 

JavaScript (now ECMAscript) tends to follow the same direction with package.json to describe project structure and dependencies, and has its own central repository but the language remains weakly typed (despite TypeScript, eslint, etc), so no bug can be fixed before run time (provided you test all execution paths - remember JavaScript is used to create user interfaces).

Moreover, JavaScript is a fake object-oriented language (you even sometimes have to set the value of 'this' yourself!!!), frameworks are very unstable and there is no standard class library, so a simple hello-world.js causes the download of 30,000+ small dependencies weighing around 200 MB...
There is a reason for all this, though: guess who steers the ECMAscript standard evolutions?


----------



## takeda (Jan 9, 2020)

Juronski, I found this thread (and others) you created about Python 2.7 EOL, if instead of complaining you would just put that effort into migrating your app, you most likely would be done by now.


----------



## Nicola Mingotti (Jan 9, 2020)

Juronski I kind of undertand you frustration. A few days ago I wanted to install Python on a bit dated OpenBSD box (2-3 years). The fastest way was simply to download and compile the source. Which I did in 30 minutes on a PCEngines Alix2 (a very small box).

So, if you don't need a gazillion packages just getting the Python2.X source and compile it maybe the least effort solution.

Making a port is not too difficult, you may get your first one in a time horizon of 1-3 days, there are several factors that may slow you down. Compliing Python2.X would probably be much much faster.

(extra. for fun). It is well known that most languages die by the cancer of semicolons. They start lean and slim to become fat monsters over time. Python is no exception.
young python: print "hello world"
adult python: print("hello world")

(extra2) Some years ago I red that Tanenbaum favourite language is AWK. I was really surprised. When T. was asked the reason for that choice the first answer was: "AWK is not going to change anymore".


----------



## sidetone (Jan 9, 2020)

Redoing something often makes it more efficient. When something is piled on, because of new features, it has to have a lot to make up for something that can be made simpler. It's like math or a city that was not planned well enough into the future from the beginning.

Python 2.7's license is Python Software Foundation (PSF), which is BSD like, so it could be maintained by another party for security, to be limited to older programs. As others suggest, would that be worth it or how practical is that? Maybe for maintaining older programs only, rather than redoing them. According to the makefile, the port's expiration is at the end of this year.

I like when there are fewer versions of a dependency, so I wouldn't have to have so many. But they'll need a newer one with newer features or improvements, so there will still be a few versions, which isn't so bad.


----------



## kpedersen (Jan 9, 2020)

Nicola Mingotti said:


> Some years ago I red that Tanenbaum favourite language is AWK. I was really surprised. When T. was asked the reason for that choice the first answer was: "AWK is not going to change anymore".



This is so true! And guaranteed to be in base on any POSIX OS. Because of this I do most of my scripting tasks in it these days (i.e mounting USB drives, xrandr output, wifi).

It's biggest bonus is that it is *not* extensible. You will never be suggested "oh, just download this random package from PIP, NPM, CPAN to do that basic task".

It is like a mini scriptable version of C. Stable and as boring as hell . It is very underrated.


----------



## CraigHB (Jan 10, 2020)

I didn't know awk was that powerful, going to have to learn more about it.  I use it here and there for single line stuff in shell scripts, but never looked into it that heavily.


----------



## Deleted member 63539 (Aug 4, 2020)

Build fine for me:

```
$ ./tauthon --version
Python 2.8.2+
```

The problem is contacting ports maintainers to replace python2 with it. Core developers have nothing to do with it as python (any versions) is not even in base.


----------



## SirDice (Aug 4, 2020)

gh_origin said:


> The problem is contacting ports maintainers to replace python2 with it.


It needs to be added to the ports tree first. You cannot use dependencies that aren't in the ports tree.


----------

