Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About Python 3

alexgaynor.net

Post reply on HN
Print view View original

321–330 of 358 posts

Re: About Python 3

#321

Post by agentultra »

keyme wrote: post #311
tungwaiyip wrote: post #309

Earlier quoted context omitted.

Keyme, you and I are the few that have serious concern with the design of Python 3. I started to embrace it in a big way 6 months ago when most libraries I use are available in Python. I wish to say the wait is over and we should all move to Python 3 then everything will be great. Instead I find no compelling advantage. Maybe there will be when I start to use unicode string more. Instead I'm really annoyed by the def…

Yes! Thank you. All the other commenters here that are explaining things like using a list() in order to print out an iterator are missing the point entirely. The issue is "discomfort". Of course you can write code that makes everything work again. This isn't the issue. It's just not "comfortable". This is a major step backwards in a language that is used 50% of the time in an interactive shell (well, at least for so…

The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins. You can't just write:

    >>> t = iter(map(lambda x: x * x, xs))
Because the map() call is eagerly evaluated. It's much easier to exhaust an iterator in the list constructor and leads to a consistent iteration API throughout the language.

If that makes your life hard then I feel sorry for you, son. I've got 99 problems but a list constructor ain't one.

The Python 3 bytes object is not intended to be the same as the Python 2 str object. They're completely separate concepts. Any comparison is moot.

Think of the bytes object as a dynamic char[] and you'll be less inclined to confusion and anger:

    >>> list(b'abc')
    [97, 98, 99]
That's not a list of numbers... that's a list of bytes!

    >>> "".join(map(lambda byte: chr(byte), b'abc'))
    'abc'
And you get a string!

Re: About Python 3

#322

Post by cpks »

The Python community may take this as a wake-up call to realize Python 3 was Python's Vista/ME/Windows 8, rolled up into one.

My proposal: Call it a development version, and ask the community to upgrade when Python 4 fixes GIL, adds support for GPGPU, multicore, adds semantics useful for going fast, true lambdas, tail recursion, and adds all sorts of similar pretty things.

Forcing an upgrade down a community's throat worked for Microsoft when they had a monopoly and could stop releasing security patches for older versions. And even then not well, and giving huge numbers of botnots.

Anything short of that is likely to fail and just hurt the size of the Python community. If I'm switching, there's also Ruby and a few other places to go that aren't Python 3.

I don't like, want, or care about Python 3. It's a regression for me. It's not a popular view, so I'm not vocal about it, but I don't think I'm in the minority here.

Re: About Python 3

#323

Post by itsadok »

agentultra wrote: post #321
keyme wrote: post #311

Earlier quoted context omitted.

Yes! Thank you. All the other commenters here that are explaining things like using a list() in order to print out an iterator are missing the point entirely. The issue is "discomfort". Of course you can write code that makes everything work again. This isn't the issue. It's just not "comfortable". This is a major step backwards in a language that is used 50% of the time in an interactive shell (well, at least for so…

The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins. You can't just write: >>> t = iter(map(lambda x: x * x, xs)) Because the map() call is eagerly evaluated. It's much easier to exhaust an iterator in the list constructor and leads to a consistent iteration API throughout the language. If that makes your life hard then I feel sorry for you, son. I've got 99…

> The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins

Well, in Python 2 you just use imap instead of map. That way you have both options, and you can be explicit rather than implicit.

> That's not a list of numbers... that's a list of bytes!

The point being made here is not that some things are not possible in Python 3, but rather than things that are natural in Python 2 are ugly in 3. I believe you're proving the point here. The idea that b'a'[0] == 97 in such a fundamental way that I might get one when I expected the other may be fine in C, but I hold Python to a higher standard.

Re: About Python 3

#324

Post by userbinator »

gizbot wrote: post #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, virtuale…

I would love to see Python seriously consider dropping case and underscore sensitivity in order to speed up developers

How? By making it harder to find all occurrences of an identifier? Case sensitivity is debatable since editors have the option to ignore case during searches, but ignoring underscores isn't something any text editor I've seen has as a default search feature.

Re: About Python 3

#325

Post by userbinator »

a3n wrote: 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…

Indeed, documentation is another thing that is going to show schisms, not just code. Backwards-incompatibility means that the majority of Python tutorials and books are just going to be broken, and one of the worst experiences I've had is with finding example code/description online for something, only to discover it won't actually work for the latest version.

Re: About Python 3

#326

Post by girvo »

nostrademons wrote: post #277
dekhn wrote: post #125

Earlier quoted context omitted.

Please don;t interpret my comments above as ignorance. I am quite aware of what is available (and was available, when I considered switching to python3 ). I did my research at the time (which was some 5 years ago). It looks like scipy was added about 3-4 years ago... at which point I don't care any more.

If it was valid at the time but your concerns have since been addressed, then your complaints aren't exactly relevant to someone who's reading this now and looking for information on Python 3, right?

It's an anecdote, and goes some way to explaining why so,e programmers have just given up on 3 already.

Re: About Python 3

#327

Post by ekimekim »

Too wrote: post #193
captainmuon wrote: post #182

Python fell into the Winamp trap. If anyone remembers, version 3 was pretty much crap, and many users stayed with 2.95 for ages. Now, I'm not saying Python 3 was bad, not at all, but the benefits don't outweigh the cost of switching for many people. Here's my idea. Make a new "Python 5" (2+3=5, or call it whatever you want), based on Python 3. Put back everything that was deprecated or removed along the way, includin…

Your idea is good but i think it has to be taken one step further. You should be able to import ANY module, third party or not, and specify under which version to run it. What we need is interop between python 2 and 3. Just look at this thread. Everybody who disses python 3 does it for library support, library support and library support. If you could write your own code in python 3 but still use libraries remaining…

Minor gripe: The other reason isn't library support, it's unicode strings, which are a massive pain for unix systems programming.

Re: About Python 3

#328

Post by yxhuvud »

SwellJoe wrote: post #313
yxhuvud wrote: post #280

Earlier quoted context omitted.

It is a reasonable choice until the day when you get hacked because you use a prehistoric version of something that doesn't get security updates anymore. Sure, sometimes that will get backported security fixes, but that is not always possible. Heck, sometimes the installation depends on said security hole.

I still think you don't understand. RHEL (and thus CentOS) backports security fixes. An Apache package downloaded today from the CentOS 5 repository will have the security fixes, and many stability related bugfixes, that the latest tarball from apache.org would have, while still being an old version of Apache (and having the same configuration file syntax and working with whatever code you've deployed and tested on t…

And I think you didn't understand my point. Sometimes these security fixes will not be compatible with the application you are running. It will usually not be an issue if every single line of code you run is from the distro manager, but I've had CentOS security fixes breaking my apps because the security fix forced some other way of doing things, and because they didn't bother backport the subsequent bug fixes to the security fixes.

Yes, it may be less work with a stable system. I'm not arguing that part, but it is an idealized pipe dream to install once and then let the system be. You still have to have the machinery to do maintenance work, and you still need proper testing. Security fixes are NOT exempt from that in any way.

Re: About Python 3

#329

Post by ekimekim »

fdej wrote: post #98
dec0dedab0de wrote: post #69

This is kind of silly, but the main thing keeping me on Python 2 is the print statement.

Same here! So much more convenient in a quick interactive session.

When I'm in an interactive session I just leave out the print statement, since it'll print the repr() of the result anyway. And repr is (generally) what I want.

Re: About Python 3

#330

Post by ekimekim »

3pt14159 wrote: post #105

If Guido had just left division the way it worked in 2.7 we'd all have moved by now. Everything else the community is fine with, but it is enough of a sticking point for some people that they can't be bothered to make the switch.

I think you'll find alot of developers have very different pain points for the switch. For you, it's integer division. For me, it's unicode strings. Some people in this discussion even cite the print function.

Long story short, if you're turning something easy into something hard, don't expect people to switch.

Post reply on HN