Reminds me of Perl 6, which was designed not to meet a user need, but to keep the Perl developers engaged. It has succeeded in this.
About Python 3
291–300 of 358 posts
Re: About Python 3
#292As sad as it may sound, the most annoying thing about Python 3 for me is this: print "Hi" vs print("hi") Other than that, as Alex said there isn't much difference between the two.
I totally agree.
I sat silent at europy in 2006 as guido explained he was breaking the print statement. At europy in 2007, when he gave the same talk, I boo-ed, loudly. He said "well no-one complained when I talked about this last year." My bad.
Being able to instantly pepper my code with print statements is how I (and many others) debug. It really gives me the shits these extra parens.
So I continue to boycott py3.
Re: About Python 3
#293Earlier quoted context omitted.
> Had a discussion at work a few weeks ago about this. Roughly, it came down to this - if you need any backwards compatibility whatsoever (Do you ever expect your code to ever run on machines with operating system releases younger than 2013ish OR do you ever plan to interop with code older than 2013ish) Python 3 runs on operating systems older than 2013 and, while it might not be the OS default, there is no reason a…
Yeah, unfortunately CentOS users don't think this way. It's a serious question whether Py3 will _ever_ become the default in server distributions. I think we'll see more significant adoption once that happens.
Default isn't the concern: it's being packaged at all. That, and the ensuing support, is the important issue.
Re: About Python 3
#294As a development lead, we recently abandoned our plans to migrate to Python 3. Here's a short summary of why: To begin the migration, we needed to move from Python 2.6 (which is the default on our CentOS6 production boxes) to Python 2.7. This transition is actually rather hard. We can't use the packages provided in CentOS base or EPEL, because they are all complied against Python 2.6. To re-produce all of our package…
Did you look at software collections? I don't know what the state of repackaging them from RHEL for CentOS is, but they're Red Hat's supported means for using Python 2.7 or 3.3.
Re: About Python 3
#295Earlier quoted context omitted.
Even Debian is using Pyhon 2.7 for a while already, looks like CentOS is being quite slow.
CentOS keeps the same major version of everything through the entire life of the OS; so, five years plus two more for vital security updates. This is by design, and a completely reasonable choice. Often, you can install additional packages that bring newer versions into the system, but they don't become the "default". So, for PHP in CentOS 5, there was a php53 package (and maybe later ones, too, I dunno), that instal…
For reference, the new way of installing newer language versions is software collections.
Re: About Python 3
#296Earlier quoted context omitted.
> Had a discussion at work a few weeks ago about this. Roughly, it came down to this - if you need any backwards compatibility whatsoever (Do you ever expect your code to ever run on machines with operating system releases younger than 2013ish OR do you ever plan to interop with code older than 2013ish) Python 3 runs on operating systems older than 2013 and, while it might not be the OS default, there is no reason a…
> Python 3 runs on operating systems older than 2013 and, while it might not be the OS default, there is no reason a non-library project can't bundle its own interpreter in the distribution and use that instead of the OS default interpreter. You are absolutely right, but the overall cost of deployment skyrockets at that point. Not to mention pernicious bugs from grabbing the wrong library & whatever other weirdness h…
Surely any new project these days is using virtualenv (with a specified version of the python interpreter) + pip.
Re: About Python 3
#297Earlier quoted context omitted.
Well, if they are programming languages, are still unstable 10 years late, have near zero adoption and are missing half of the promised features, then yes.
Unfortunately languages like Rust perfectly fit your definition. Because Rakudo was started around the same time as Rust and Rust is aiming for may be 1% of the feature set Perl 6 aims to achieve.
If Rust had been hyped as much as Perl6 I'd call it vaporware too. It may yet turn out to be vaporware (in that it's not done), but right now I'm willing to give it the benefit of the doubt that they will actually deliver on their promises.
Re: About Python 3
#298Re: About Python 3
#299Earlier quoted context omitted.
This sounds remarkably like Perl 5/6.
Nobody expects Perl 6 to be widely used yet. The Python community seems to expect Python 3 to be widely used by now.
Bullshit. I was there in 2002 looking at Perl 6 and we expected it to replace Perl 5 within a couple of years.
Re: About Python 3
#300As a development lead, we recently abandoned our plans to migrate to Python 3. Here's a short summary of why: To begin the migration, we needed to move from Python 2.6 (which is the default on our CentOS6 production boxes) to Python 2.7. This transition is actually rather hard. We can't use the packages provided in CentOS base or EPEL, because they are all complied against Python 2.6. To re-produce all of our package…
> Frankly, it's just not worth that effort at this time. Python 2.6 is the default environment, there's solid package support for it, and it just plain works. We'll make that dive when Python 3 becomes the default for CentOS (scheduled for 8 or 9, IIRC), and probably not before.
Which is well and good; there's no point fighting with your operating system. Python3 was always going to be a slow migration; perhaps it's going even slower than planned, but that's not the disaster the OP portrays (in fact it sounds like you'd have just as much trouble migrating to python 2.7 as python 3, so there's no python3-specific problem here). Python3 is now at a place where distributions are adopting it as default; non-bleeding-edge folks will follow their distribution's lead.