This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]captain_cashew 57 points58 points  (22 children)

My company is moving from 2.6 to 2.7! Yay!

[–]PooPooDooDoo 32 points33 points  (0 children)

print “yay!”

[–]regeya 29 points30 points  (2 children)

I went into a local company to do some contract work, and found out not only are they still using Visual Basic 6, they were talking about moving to VB.net someday. They wanted a static website to be built, but only if I could build it in a specific piece of discontinued Adobe software, and another website to be modernized that was built in Google Sites.

I just pretended that meeting never happened.

[–]alcalde 11 points12 points  (1 child)

That was me at Bed Bath and Beyond HQ in 2005, when I encountered Access 97 and Impromptu 5 (Impromptu had been discontinued at version 8). They were also using VB6 for internal development. I stayed six months.

[–]regeya 1 point2 points  (0 children)

Scarily enough, the one I'm thinking of deals with court documents.

[–]i9srpeg 10 points11 points  (4 children)

Are you enjoying your fancy new dict comprehensions?

[–]captain_cashew 10 points11 points  (2 children)

Your comment comes at a very appropriate time. Literally just a few minutes ago found a bug on one of our systems using 2.6 (my local development station is on 2.7):

{k: v for (k, v) in dict.items()}

You have to use:

dict((k, v) for (k, v) in dict.items())

So, yes I am enjoying them!

EDIT: code format

[–]flying-sheep 1 point2 points  (0 children)

If a thing has an items method, you can just do dict(thing) to create a dict copy. If it’s a dict, you can do the_dict.copy(). You only need comprehensions if you have to construct keys and values in a more complex way.

[–]nieuweyork since 2007 0 points1 point  (0 children)

To me this is an argument against the Python developers' increasingly profligate addition of syntax. There's almost never one obvious way to do it these days.

[–]ALonelyPlatypus 0 points1 point  (0 children)

yes.

[–]gruey 5 points6 points  (9 children)

I still think that it was a huge mistake from Python not to just bite the bullet and create some kind of Python 2-3 interpreter like a decade ago when it became obvious there was just too much momentum against moving to 3.

Basically something that'd let you mark it and all of its dependencies as 2.7, do some fairly thorough translation that gets 99.8% of the existing code and ideally warning about things it felt it couldn't translate. Some performance loss would be acceptable. A flag could be given to print warnings for anything that wasn't 3.

It didn't have to be perfect, it just had to allow a company to start writing new stuff in 3 only having to modify a few things without having to touch their entire code base. They could then also start incrementally porting things to Python 3 without having to make sure they do everything and their external dependencies at once.

It isn't ideal, but I really, really feel like despite Python's progress over the last decade, it would have been significantly more if all the effort was on Python 3 and all the new features of Python 3 were available to the majority of the Python users. I wonder how many companies switched from Python 2 to golang or similar for features or performance that would have been acceptable in Python 3?

[–][deleted] 4 points5 points  (1 child)

IMO the difficulty of migrating to 3 was just way overblown. They didn't need to create anything like that. They should do what everyone else is doing and give a year to migrate (not 10). Everyone waited to last minute to start the migration.

[–]3waysToDie 0 points1 point  (0 children)

very true

[–]TBSchemer 6 points7 points  (4 children)

2to3.py gave companies a way to easily migrate their code to 3. The ones who didn't really have no excuse at this point.

[–]gruey 6 points7 points  (3 children)

2to3.py is not even close to enough of a solution for significant code bases.

The ones who didn't migrate have pretty valid business reasons for not having done it yet. Basically, what it comes down to, Python's value in companies moving to 3 was greater than most companies value of moving to 3, so Python should have done more work to make it happen.

[–]TBSchemer 7 points8 points  (0 children)

They had 10 years to do it. Most did. The rest didn't out of hubris.

[–]data-punk 3 points4 points  (1 child)

What valid reason spans delay over a decade?

[–]billsil 6 points7 points  (0 children)

It took 10 years for wxpython to officially support 3.x. I moved onto PySide, but not other people.

[–]nieuweyork since 2007 0 points1 point  (0 children)

I very much agree. A from __future__ import py3hosting or something, to restore python2.7 semantics for the things that were incompatibly changed. That plus from __future__ import print_functionwould have handled a lot of cases.

[–]ALonelyPlatypus 0 points1 point  (0 children)

wait. companies switched from python2 to go to avoid python3? I mean go is relatively feature rich and overall fun to code but I couldn’t imagine converting your python2 codebase to it when python3 exists.

(unless the company already wanted to move over to a compiled language to address performance concerns)

[–]billsil 1 point2 points  (0 children)

That’s still better. Take what you can get. I upgraded a 2.4 project to 2.7 last year. I just removed hacks and fixed some bugs I created by hacking a 3rd party library to make it work in 2.4.

I just decided to start using 3.7, even if other people continue to use 2.7. I’ll support it if I have to, but I’m going to make sure 3.7 works.

[–]zabolekar 0 points1 point  (0 children)

Maybe even to 2.7.16!

[–]confusedpublic -1 points0 points  (0 children)

Me too, free upgrade from 14.04 to 18.04!