251–260 of 358 posts
At least mod_python already aware of existence of python 3.3.x ,)
Earlier 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.
That's moving the goalposts a bit! What's currently called "Rakudo" is at least the sixth or seventh attempt at an implementation, not counting Pugs, viv, v6, or Niecza.
Earlier quoted context omitted.
Perl 6 is vaporware. Python 3 is here, it's widely supported, it's faster than Python 2.7, and while Guido didn't do us any favors with his migration strategy, I don't see what the big deal is. Python 3.3 makes writing code that is compatible with both almost trivial. People aren't using Python 3 enough because it's not the default in Debian/Ubuntu. That's about to change with Ubuntu 14.04. I expect that to tip the s…
Comparing Perl 6 with Python 3 is a big joke. Even a cursory look at the Perl 6 specification and implementations like rakudo will tell you Perl 6 is attempting to go to a place where Python may like likely go in the next 40 years, with 10 Python 3 like disasters. Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason.
Way back in the early days, the goal was to release a usable 6.0 in a couple of years. The "there's no hurry" line is a post hoc justification from around 2006 or so.
Almost all Autodesk products come bundled with 2.x version of python. Could it be that Python 2.x is the Windows 7 of the Python world :) - just good enough for everyone. (I'm not a python user, had to write few items for Maya/MotionBuilder and few other scripts).
It would be great if Autodesk ever did upgrade python to 3.3, but I suppose A LOT of stuff would break in the process.
But since A LOT of stuff already breaks from each yearly version it wouldn't matter much... :P
I would bet they will only upgrade it when many new features in PySide supports only 3.x and up, or if they ever drop support for 2.6.x.
I'm going to go against the grain here and say that moving slowly is one of my absolute favorite features about python and its libraries. Rails and django were released about the same time, rails is on version 4, django is on 1.6. Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. More importantly, every release requires a perusal: did the API change, what's new, are…
i like fast movement, i like communities that dare to break things every now and then (see semver.org for the widely accepted versioning rules and should be honoured). much do i prefer an increasingly better solution to a stable one. i'm not agueing "perfect" over "good enough"; i'm argueing "awesome" over "good enough" :)
But when I'm writing new code, I'm of course using Python 3.
Earlier quoted context omitted.
The 1.8/1.9 switch was problematic and can be seen in parallel with the python 2.7/3.x switch. Rails 2/Rails 3 was a similar big jump that reengineered the whole framework. Rails 4 was a much tamer release in that regard. But one has to realize that 1.8 was the series of Ruby that was started _before_ Ruby even got popular (I started Ruby using 1.6, which was even more problematic). So being aggressive in breaking st…
1.8/1.9 and 2.x/3.x were handled very differently by the respective communities. That's evident even from the version numbers.
Earlier quoted context omitted.
Comparing Perl 6 with Python 3 is a big joke. Even a cursory look at the Perl 6 specification and implementations like rakudo will tell you Perl 6 is attempting to go to a place where Python may like likely go in the next 40 years, with 10 Python 3 like disasters. Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason.
Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason. Way back in the early days, the goal was to release a usable 6.0 in a couple of years. The "there's no hurry" line is a post hoc justification from around 2006 or so.
But I think the goal has changed from "Let's fix Perl 5" to being a more bigger goal of developing a language what Perl 5 would likely look after say 3 decades of iterations. I can't say if that is good from a purely practical perspective. But it does sound like worthwhile goal to chase.
Lets take a look at Python 3 itself. Yes they finished the project, but 5 years after that- Now what? Users don't seem to a have a valid reason to move away from 2.x series for merely small time incremental improvements, while forced to migrate bulk of the infrastructure and code for nearly ~0% productivity gains.
Perl 6 could have come out by 2005-2006, and if it were to be merely a incremental non-backwards compatible change over p5. We would be having similar posts about p6 as we are having now about Python 3. Imagine a refined, yet not that beneficial p5 breaking CPAN. I am sure you wouldn't like such a situation.
Earlier quoted context omitted.
Matz has also said no breaking changes until ruby 3.0, which is 'ten years away.' I don't expect this to actually be true, but it speaks to an attitude.
i feel ruby's syntax is mostly done. an addition here or there, but breaking shall be rare as it just feels so finished. performance wise i think it can use (and gets) a lot of love. on the python side things are different. python seems quite a bit faster then ruby. same league, but faster. yet its syntax is what needs to be greatly improved upon as it is so full of surprises and dark corners. a language's syntax it'…
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
As 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…
Can you elaborate why you need to use a version shipped with the distro instead of simply using virtualenv+pip to install all third party dependencies?
Earlier 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.
Perl 6 was first started on 2000. I've been reading Larry's apocryphal descriptions of its "features to be" for 4 times more years than Rust exists.
Rakudo is just a particular attempt at Perl 6, not the first and neither it consists of first time the language was announced publicly.