6 ms·

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

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 there breaking changes I need to be aware of? I didn't appreciate how nice a slow but consistent and deliberate release cycle was until I started using Ember which seems to release a new version monthly. Its generally acceptable to be one or two x.x versions back, but much more than that and the cost of maintaining libraries skyrockets, so you start losing bug fixes and library compatibility. With python there's not really a question of if I can run my code for a year between non-security upgrades, even with a few dozen third party libraries. That stability is immensely valuable.

cies 13y ago
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" :)
- xradionut 13y ago
  You might be a great Microsoft developer. Use this API, no this one, nope now this one, you almost caught up, so we released a newer, more better one! Please buy Awesome Studio and RDMS 2015 or you are a loser. Here's a free version that can't do shit, the Pro version is only $2000, plus lots of your time adjusting to a newer mono/flat chrome development environment. Hot keys only for touch screen users!
  - pjmlp 13y ago
    I can give such examples for any commercial vendor and in terms of breaking compatibility, there are a few examples in FOSS land as well.
    - shadowfox 13y ago
      > I can give such examples for any commercial vendor and in terms of breaking compatibility, there are a few examples in FOSS land as well But that wouldn't have the same emotional appeal as MS ;)
    - rmc 13y ago
      Microsoft are a massive tech company though.
  - danso 13y ago
    Correct me if my history is a little fuzzy, but isn't it Apple that plays the part of "move fast, worry later" so well? After all, Apple has been the front-runner when it comes to things like, "f--k your floppy/CD drive/FireWire/display-adapter, we're moving on", and that's just in hardware. Microsoft has actually done a pretty good job maintaining backwards compatibility, considering the size of their user base and variety of software to accommodate. Though perhaps that makes it a better metaphor for PHP development than Python.
    - dangayle 13y ago
      It's not like you still couldn't plug in an old CD drive into your Mac. It will still work just fine. You can't plug in an old Python 2.x plugin into Python 3.x.
      - tripzilch 13y ago
        Why not. Are you familiar with SciPy's `weave` module? It's basically a plugin for plugging C++ code into your Python. In a variety of extremely cool compile-on-the-fly ways. It's really quite sweet :) No reason you can't do that with Python 2.7. Should be easier in fact because the interface will be much thinner. I am NOT saying this is a good idea however! Haha
        dangayle 13y ago
        That's interesting. I'll look it up.
    - jodrellblank 13y ago
      Microsoft maintains good backward compatibility, but has a habit of releasing a new way of doing things every five minutes. Particularly look at http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_DepMDAC_WDACComps http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_D... and windows current / deprecated/obsoleted ones. Just to connect your Windows program to a Microsoft database.
      - 13y ago
  - cies 13y ago
    Thanks for the advice; only 2000 for "pro"? Wow! Where can I pay?
  - Pxtl 13y ago
    No, Microsoft never breaks anything. They deprecate relentlessly and push out new libs to replace old ones, but they never have the balls to actually fix anything. It's immensely frustrating that no lib ever reaches better than 80% good. It goes "1.0broken -> 1.1usable -> 2.0baroque -> 2.1deprecated -> Replacement lib 1.0broken".
  - pmelendez 13y ago
    >"Here's a free version that can't do shit" Depends what you are doing. I worked in a multinational mobile game studio and developers were using Visual C++ express, which was actually pretty capable for what we were doing.
- Sami_Lehtinen 13y ago
  You clearly aren't running extensive production systems with little administrative resources. Code is written 15 years ago, and it's still running. Any changes that break something are major headache, usually leading rolling things back to working version. Nobody knows or cares to fix those things to achieve compatibility with new version. This leads to situation where nothing at all is ever updated. And even known bugs and exploits aren't getting fixed. Oh well, that's business as usual. But when I'm writing new code, I'm of course using Python 3.
  - dded 13y ago
    > But when I'm writing new code, I'm of course using Python 3. There's no "of course" about it, which is the point of the article. It is interesting that you're using Python3. It means that you're not blocked by library availability (public or company-internal). It means that you are permitted by management to use it. It probably means that you prefer it. My situation is different on the last two points, but I am also not blocked by library availability.
Argorak 13y ago
This is where the Ruby and Python communities fundamentally disagree. The Ruby community is great at moving fast and replacing bad things, while the Python community takes a much slower approach to the whole thing. I wouldn't say any approach is better or worse, it has to fit your personal style. I like the Ruby approach, others love the Python approach. This means that Ruby breeds a lot of interesting stuff, but with less stability guarantees. At the same time, Rails still builds on the ideas of Rails 1, which is an achievement in itself. So Rubyists is not totally not caring about backwards compatibility - they just tend to throw out bad ideas quickly again. On the other hand, the quick pace allows the MRI team to build improved interpreters with a reasonable chance of quick adoption. This is a much more fundamental difference than any snickering about the garbage collector of the main interpreter, from a users perspective.
- cookiecaper 13y ago
  There's plenty of rapid iteration in the Python world, and as far as I know, there is no fundamental disagreement with the concepts behind rapid iteration. Development still occurs in the open, but releases are well-planned and well-versioned such that backward incompatibilities are clearly billed and rarely introduced if not necessary. Pyramid is an exemplary Python project that has very rapid development but still respects compatibility concerns. My opinion is that Python projects are simply more likely to have more mature release processes because Python is more likely to be used by mature engineers than Ruby.
  - thatthatis 13y ago
    I think this is well said. It seems to me that python iteration happens in the space ahead of current (x.x.dev). I can't really say how ruby does it because I haven't use ruby much.
  - Argorak 13y ago
    I didn't talk about release processes. There are lots of projects with mature release processes in the Ruby world. What I meant is that agressively replacing parts that became obsolete or turned out problematic is much more accepted. > Python is more likely to be used by mature engineers than Ruby. It is very sad that you waste a good post for such an ungrounded attack.
kamaal 13y ago
>>Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. That also means people who want to start new projects are going to do them in some other tools that are designed with the current problem trends in view. Yes you still have bulk of legacy projects to work on. But that's the whole point.
skywhopper 13y ago
There's plenty of value to the going-slow approach and Python should embrace that identity and the value that comes with it. However, having two incompatible versions of the language itself--and all of the confusion that comes along with that--is a major barrier to adoption and improvement of the language. The mistake here was breaking backwards compatibility to begin with. But since that's long past us now, the problem that needs to be solved is how to reconcile the two versions. It's unrealistic to keep both 2.7 and 3.3+ around forever. How do we get to a single version of Python to keep the language and its community healthy?
steven_yue 13y ago
Apparently you didn't use Rails, or at least on real project.

cies 13y ago

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" :)

xradionut 13y ago
You might be a great Microsoft developer. Use this API, no this one, nope now this one, you almost caught up, so we released a newer, more better one! Please buy Awesome Studio and RDMS 2015 or you are a loser. Here's a free version that can't do shit, the Pro version is only $2000, plus lots of your time adjusting to a newer mono/flat chrome development environment. Hot keys only for touch screen users!
- pjmlp 13y ago
  I can give such examples for any commercial vendor and in terms of breaking compatibility, there are a few examples in FOSS land as well.
  - shadowfox 13y ago
    > I can give such examples for any commercial vendor and in terms of breaking compatibility, there are a few examples in FOSS land as well But that wouldn't have the same emotional appeal as MS ;)
  - rmc 13y ago
    Microsoft are a massive tech company though.
- danso 13y ago
  Correct me if my history is a little fuzzy, but isn't it Apple that plays the part of "move fast, worry later" so well? After all, Apple has been the front-runner when it comes to things like, "f--k your floppy/CD drive/FireWire/display-adapter, we're moving on", and that's just in hardware. Microsoft has actually done a pretty good job maintaining backwards compatibility, considering the size of their user base and variety of software to accommodate. Though perhaps that makes it a better metaphor for PHP development than Python.
  - dangayle 13y ago
    It's not like you still couldn't plug in an old CD drive into your Mac. It will still work just fine. You can't plug in an old Python 2.x plugin into Python 3.x.
    - tripzilch 13y ago
      Why not. Are you familiar with SciPy's `weave` module? It's basically a plugin for plugging C++ code into your Python. In a variety of extremely cool compile-on-the-fly ways. It's really quite sweet :) No reason you can't do that with Python 2.7. Should be easier in fact because the interface will be much thinner. I am NOT saying this is a good idea however! Haha
      - dangayle 13y ago
        That's interesting. I'll look it up.
  - jodrellblank 13y ago
    Microsoft maintains good backward compatibility, but has a habit of releasing a new way of doing things every five minutes. Particularly look at http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_DepMDAC_WDACComps http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_D... and windows current / deprecated/obsoleted ones. Just to connect your Windows program to a Microsoft database.
    - 13y ago
- cies 13y ago
  Thanks for the advice; only 2000 for "pro"? Wow! Where can I pay?
- Pxtl 13y ago
  No, Microsoft never breaks anything. They deprecate relentlessly and push out new libs to replace old ones, but they never have the balls to actually fix anything. It's immensely frustrating that no lib ever reaches better than 80% good. It goes "1.0broken -> 1.1usable -> 2.0baroque -> 2.1deprecated -> Replacement lib 1.0broken".
- pmelendez 13y ago
  >"Here's a free version that can't do shit" Depends what you are doing. I worked in a multinational mobile game studio and developers were using Visual C++ express, which was actually pretty capable for what we were doing.
Sami_Lehtinen 13y ago
You clearly aren't running extensive production systems with little administrative resources. Code is written 15 years ago, and it's still running. Any changes that break something are major headache, usually leading rolling things back to working version. Nobody knows or cares to fix those things to achieve compatibility with new version. This leads to situation where nothing at all is ever updated. And even known bugs and exploits aren't getting fixed. Oh well, that's business as usual. But when I'm writing new code, I'm of course using Python 3.
- dded 13y ago
  > But when I'm writing new code, I'm of course using Python 3. There's no "of course" about it, which is the point of the article. It is interesting that you're using Python3. It means that you're not blocked by library availability (public or company-internal). It means that you are permitted by management to use it. It probably means that you prefer it. My situation is different on the last two points, but I am also not blocked by library availability.

Argorak 13y ago

This is where the Ruby and Python communities fundamentally disagree. The Ruby community is great at moving fast and replacing bad things, while the Python community takes a much slower approach to the whole thing. I wouldn't say any approach is better or worse, it has to fit your personal style. I like the Ruby approach, others love the Python approach. This means that Ruby breeds a lot of interesting stuff, but with less stability guarantees. At the same time, Rails still builds on the ideas of Rails 1, which is an achievement in itself. So Rubyists is not totally not caring about backwards compatibility - they just tend to throw out bad ideas quickly again. On the other hand, the quick pace allows the MRI team to build improved interpreters with a reasonable chance of quick adoption. This is a much more fundamental difference than any snickering about the garbage collector of the main interpreter, from a users perspective.

cookiecaper 13y ago
There's plenty of rapid iteration in the Python world, and as far as I know, there is no fundamental disagreement with the concepts behind rapid iteration. Development still occurs in the open, but releases are well-planned and well-versioned such that backward incompatibilities are clearly billed and rarely introduced if not necessary. Pyramid is an exemplary Python project that has very rapid development but still respects compatibility concerns. My opinion is that Python projects are simply more likely to have more mature release processes because Python is more likely to be used by mature engineers than Ruby.
- thatthatis 13y ago
  I think this is well said. It seems to me that python iteration happens in the space ahead of current (x.x.dev). I can't really say how ruby does it because I haven't use ruby much.
- Argorak 13y ago
  I didn't talk about release processes. There are lots of projects with mature release processes in the Ruby world. What I meant is that agressively replacing parts that became obsolete or turned out problematic is much more accepted. > Python is more likely to be used by mature engineers than Ruby. It is very sad that you waste a good post for such an ungrounded attack.

kamaal 13y ago

>>Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. That also means people who want to start new projects are going to do them in some other tools that are designed with the current problem trends in view. Yes you still have bulk of legacy projects to work on. But that's the whole point.

skywhopper 13y ago

There's plenty of value to the going-slow approach and Python should embrace that identity and the value that comes with it. However, having two incompatible versions of the language itself--and all of the confusion that comes along with that--is a major barrier to adoption and improvement of the language. The mistake here was breaking backwards compatibility to begin with. But since that's long past us now, the problem that needs to be solved is how to reconcile the two versions. It's unrealistic to keep both 2.7 and 3.3+ around forever. How do we get to a single version of Python to keep the language and its community healthy?

steven_yue 13y ago

Apparently you didn't use Rails, or at least on real project.