Live data from Hacker News

About Python 3

alexgaynor.net

261–270 of 358 posts

Re: About Python 3

#261
post #205

Earlier quoted context omitted.

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!

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…

Apple wants users to buy new hardware and I guess they figure it's not a big deal because you can buy adapters and/or hardware is usually bought together in generations. Their software APIs have remained quite stable; certainly no Silverlight-esque shenanigans from them.

Re: About Python 3

#262

Earlier 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 2 is the way to go. Otherwise, feel free to use Python 3. This effectively means that only for purely greenfi…

> 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.

Re: About Python 3

#263
post #164

Consider the new programmer, or the programmer new to python, or the corporation/workgroup new to python whose focus is not at all python as python but just GSD. They read this, or you show it to them: Should I use Python 2 or Python 3 for my development activity? https://wiki.python.org/moin/Python2orPython3 It starts off very encouraging: "Short version: Python 2.x is legacy, Python 3.x is the present and future of…

Totally agree. And when one of the suggestions for porting to Py3 is "Decide if the feature is really that important. Maybe you could drop it?", you know something is wrong.

Re: About Python 3

#264
post #247

Earlier quoted context omitted.

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.

Rust appeared publicly as a project to build a language in 2010 (it was a personal, private, project kept under wraps by Graydon a few years before which is irrelevant). 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 th…

I remember Larry also saying(On a youtube video, may be at the O'reilly conference) that he has been working on Perl 6 since 1987. That's how he wishes to describe it.

Even beyond that those are not "features to be". They are already available for use - http://perl6.org/compilers/features

Therefore I'm not sure what you've been reading, or if you are even reading them. Because if you would- you would know, Rakudo covers much of the Perl 6 specification.

By the way. Rust is still not complete. The wikipedia article says, work started in 2006- Which makes it 8 years and still incomplete. And this is for a project which has by far may be even 1000x modest goals. Python 3 was itself 10 years in development, and that is for small modifications to print statement and iterators. And even after 5 years since that date, it doesn't seem to have come any where closer to achieving good production scenario adoption.

And. These are- I said by far extremely modest goals compared to the Perl 6 project.

Re: About Python 3

#265
post #205

Earlier quoted context omitted.

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…

Apple wants users to buy new hardware and I guess they figure it's not a big deal because you can buy adapters and/or hardware is usually bought together in generations. Their software APIs have remained quite stable; certainly no Silverlight-esque shenanigans from them.

Good point. Apple might frequently break compatibility even at hardware level but they do provide adapters if you really need it, making transitioning a no-brainer. The problem with python is that there are no such adapters at all.

Re: About Python 3

#266

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…

>>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.

Re: About Python 3

#267
The arrogance burns. It burns.

Python 3.0 was derailed by arrogance that developers should commit to a one-way transition that would touch every function rather than accept that, in Python 3.0, 'x = u"Hello"' should have been a valid statement. It didn't help that it ran slower, added nothing, and broke tools.

Python 3.3 was the first release that had a prayer, but there are mistakes everywhere. For example, virtualenv was included but broke because pip was not. Libraries like ftfy are required because the encodings break. Explaining the oddities of scoping inside generator expressions creates tricky interview questions. And then, Python 3 didn't fix all the broken.

By broken, I mean actually broken. We know where its broken: lots of standard libraries like collections.namedtuple which has an argument to print a generated class. Strange cruft like calendar.weekheader() that only helps one developer's program. This code is in the standard library. Handy things like cleaning up Unicode, DSL support, local encodings, security restrictions. Those you add from other libraries.

Also, where's the love? The courage? I would love to see Python seriously consider dropping case and underscore sensitivity in order to speed up developers, an_item = anItem +1 would be a warning. I would like to see language translation support in the language, great packaging that just works, incorporation unit tests into the package system, reforming the dunder mess, anything! Instead I see the mediocrity by arrogance.

Just for fun, they moved the US Pycon conference to Canada. Only little people have troubles with international travel. Arrogance.

Re: About Python 3

#268

Earlier quoted context omitted.

In that case (and all of the other GNU stuff) it ships with the final GPLv2 version, since Apple is unwilling to ship GPLv3 code.

Is there a particular reason for that? I can understand not wanting to ship GPLv3 code if it is embedded sufficiently deeply into the hardware, but it shouldn’t be a problem to ship GPLv3 Bash, as the user can change the binary delivered on the harddrive at any time?

Patents and DRM. It always comes down to that.

If Apple ships any OS X devices with DRM, they would have to have a separate build without the gplv3 bash in it. It would double support costs, maintenance and so on.

And patents. Any patents covering bash would loose value from using a GPLv3 bash. This also include any patent agreement Apple has, which include additional legal overhead.

GPLv2 vs GPLv3 is and always will be Patents and DRM.

Re: About Python 3

#269
post #132

Earlier quoted context omitted.

Is there a particular reason for that? I can understand not wanting to ship GPLv3 code if it is embedded sufficiently deeply into the hardware, but it shouldn’t be a problem to ship GPLv3 Bash, as the user can change the binary delivered on the harddrive at any time?

GPL has all kinds of non-corporate friendly clauses. I wouldn't touch GPLv3 code in anything I ship either. Likewise Torvalds refuses to let GPLv3 touch the kernel.

> Likewise Torvalds refuses to let GPLv3 touch the kernel.

Please don't misrepresent other peoples view points out of context.

If you want to read Linux Torvalds opinion, I suggest that you start with either one of the many articles about it (like http://news.cnet.com/Torvalds-No-GPL-3-for-Linux/2100-7344_3...), or any of the many mails on the mailing list. You will notices that Torvalds criticism is mostly directed at the DRM provisions, since he don't think a copyright license should be able to dictate a political matter such as DRM restrictions on devices.

To quote:

  "I also don't necessarily like DRM myself," Torvalds wrote.
  "But...I'm an 'Oppenheimer,' and I refuse to play politics with Linux,
  and I think you can use Linux for whatever you want to--which very much
  includes things I don't necessarily personally approve of."

Re: About Python 3

#270
post #244

Earlier quoted context omitted.

It's not an attack, it's my opinion that more mature hackers eventually converge on Python, and I think the community reflects that. Maybe it's simply that Python has never had a project with the same sex appeal as Rails, and thus has avoided an "Eternal Summer"-esque influx. For the record, the last time I wrote Ruby code was about 4 days ago, and the last time I wrote Python code was yesterday afternoon. I'm a part…

I believe cookiecaper is right for the foreseen future, there is more demand for Python Data-Scientists than Ruby Developers. But we ignore one important thing here and that is the lesson! People need to learn something from the Python story! Moving forward with an evolving concept, requires the (mathematical) coherence of all ideas. You cannot invent a spoken language, then break it and say now we speak a different…

I think the same about old people btw. we branch their value out to an old value that is not compatible with the values in our current system. Oh boi, we do that so wrong, it's laughable and very sad at the same time how our society thinks about old knowledge, old people etc.

I think HN is the community that most loudly would agree with new != better but that's exactly what we do wrong. Holy cow, I can't explain how much value we have at our disposal that we throw away + pay to keep it away comfortably. New businesses don't integrate old people, because they don't really know how to make value out of them. That's a simple equation, if you see it this way. It's not because old people cannot contribute to the development of IT, Startups and the Hacker scene. We just have no business model, not even a concept that considers these elder men and women.

Post reply on HN