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

311–320 of 358 posts

Re: About Python 3

#311

Post by keyme »

tungwaiyip wrote: post #309
keyme wrote: post #147

Earlier quoted context omitted.

I don't like Python 3. Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results. Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "h…

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 some of us).

Re: About Python 3

#312

Post by dded »

paskakapu wrote: post #288

python3 destroyed it's ability work as simple calculator. Try this on python3: >>> answer = 1 + 1 >>> print answer

I don't have Python3 handy, but in Python2 I do this:

  >>> answer = 1 + 1
  >>> answer
  2
Doesn't Python3 work the same way?

In any case, my PYTHONSTARTUP has this line:

  from pprint import pprint as pp
and I find pp() very nice for printing various structures.

Re: About Python 3

#313

Post by SwellJoe »

yxhuvud wrote: post #280
SwellJoe wrote: post #162

Earlier quoted context omitted.

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…

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 that version).

That's what companies are paying Red Hat for: A stable platform on which to build their business. It really is a good thing with quite a lot of value.

If you want bleeding edge versions of software, RHEL or CentOS might not be the right OS for you. But, I happen to love it for servers; I know that what I deployed three years ago is still gonna work after upgrading packages provided by the vendor. That's not something you can count on with faster moving distros, and it's why I always use CentOS (or RHEL or Scientific Linux) on my servers...while I generally use Fedora or Ubuntu on desktops.

Security is a hard thing to quantify, but I really think that a slower moving, but more carefully vetted, platform is going to be more secure. I believe this is why OpenBSD is so solid...moves very slow, but is very carefully constructed and maintained. RHEL/CentOS is somewhere in between OpenBSD and Ubuntu on that continuum, and I strongly suspect CentOS is going to have a better security record than Ubuntu.

Re: About Python 3

#314

Post by _delirium »

cossatot wrote: post #306
_delirium wrote: post #238

Earlier quoted context omitted.

Differences in userbases could be part of it. Scientific computing is an increasingly important part of the Python community, for example, and they tend to be averse to backwards-incompatible changes. In part that's because you have many good but very lightly maintained libraries that stick around forever, so people prefer if they stay working when nobody touches them, rather than bitrotting and needing constant upda…

Furthermore, with scientific computing, it's important that code you publish in a journal (fossilizing it) can still be at least near-usable to others over time horizons of years to decades.

That's definitely one important aspect. And even stuff not formally fossilized often becomes de-facto fossilized due to the way funding for development works. Things are often very bursty: a large library or piece of software may be written over a period of 2-5 years of concentrated effort either by a PhD student, or by programmers/research-scientists/post-docs hired on an NSF/DARPA/EU-funded research project. But then the PhD student graduates, or the project ends (and therefore its funding for programmers), and the software goes into much lower-staffing maintenance mode. In that mode there aren't resources available for anything but minor fixes. There are some very high-profile projects that are an exception to that pattern, because they're seen as important enough that they manage to string together continuous development for years or decades, either through a series of PhD students or a series of grants. But lots are more or less write-and-then-maintain. Despite being lightly maintained, if the initial work was solid and produced a reasonably "complete" output, it might still be useful to other researchers for years into the future, if it doesn't bitrot. Some of the R packages are a good example: plenty of stuff hasn't been touched in 10+ years but is still in daily use.

Re: About Python 3

#315

Post by q845712 »

userbinator wrote: post #249
_delirium wrote: post #238

Earlier quoted context omitted.

Differences in userbases could be part of it. Scientific computing is an increasingly important part of the Python community, for example, and they tend to be averse to backwards-incompatible changes. In part that's because you have many good but very lightly maintained libraries that stick around forever, so people prefer if they stay working when nobody touches them, rather than bitrotting and needing constant upda…

It seems that communities that mainly use programming languages for reasons of "getting stuff done" value backwards compatibility the most; they are the ones who would rather not have to spend the time "upgrading" things that used to work perfectly fine, and would rather use that time to do something more useful and related to their ultimate goals. Personally I think backwards compatibility is getting less attention…

"Imagine if [...] plugs changed every few months, with appliancemakers all adopting the newest backwards-incompatible version"

like apple?

Re: About Python 3

#316

Post by gkya »

dded wrote: post #307
agentultra wrote: post #302

Earlier quoted context omitted.

ASCII by default is only an accident of history. It's going to be a slow, painful process but all human-readable text is going to be Unicode at some point. For historical reasons you'll still have to encode a vector of bytes full of character information to send it down the pipe but there's no reason why we shouldn't be explicit about it. The pain is painful [in Python 3] primarily for library authors and only at the…

I was careful to say "Unix strings", not "ASCII". A Unix string contains no nul byte, but that's about the only rule. It's certainly not necessarily human-readable. I don't think a programming language can take the position that an OS needs to "adopt better encodings". Python must live in the environment that the OS actually provides. It's probably a vain hope that Unix strings will vanish in anything less than decad…

> I was careful to say "Unix strings"

This is the first time I encounter the idiom Unix strings. I'll map it to array of bytes in my table of idioms.

> I don't think a programming language can take the position that an OS needs to "adopt better encodings".

I do think that programming languages should take a position on things, including but not limited to how data is represented and interpreted in itself. A language is expected to provide some abstractions, and whether a string is an array of bytes or an array of characters is a consideration of a language designer, who will end up designing a language takes one or another of the sides available.

Python has taken the side of language user: enabled Unicode names, defaulted to Unicode strings, defaulted to classes being subclasses of the 'object' class... Unix has taken the side of machine (which was the side at the time of Unix's inception.

> [...] probably a vain hope that Unix strings will vanish [...]

If only we wait for them to vanish, doing nothing to improve.

> Python must live in the environment that the OS actually provides.

Yes, Python must indeed live in the OS' environment. Regardless, one need not be a farmer because they live among all farmers, need they?

Re: About Python 3

#317

Post by mitchty »

Too wrote: post #265
cookiecaper wrote: post #261

Earlier quoted context omitted.

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 .

I find this hardware compatibility thing a bit of a non issue. I have a usb dvd drive and floppy drive for that matter. Don't use em much to be honest. Will be using the dvd a lot in a bit while I migrate my dvd collection entirely to my nas box. (aka dd if=/dev/whatever of=/some/file) but thats mostly an exception and desire to get rid of stupid physical stuff.

As for Apple not being backward compatible, going to have to disagree a bit. Rosetta for example kept ppc code running on intel for a long time (10.6). Apple generally will give you a couple OS release notice that xyz is on its way out, start fixing it now or planning your path. To be honest I prefer that approach. Its measured, but still decent enough to handle moving on. Now with being able to run OSX in vmware fusion i'm pretty much of the opinion the backward compatibility canard in general is kinda a non issue overall. But just my opinion really.

I will say compared to things like systemd/ubuntu I've had a lot less breaking annoyances on OSX than any other unix/os including windows. By and large it works fine. Now mind you all I do is run chrome/firefox/safari/emacs/vmware on osx mostly so not like my needs are complex. But I guess all the rapid change in apple land really kinda goes by me using it. All I do is wait for vmware to work on the new os and then its game on.

I'm rambling but basically I think there is room for both types of iteration, or even a combination.

Re: About Python 3

#318

Post by msie »

zackmorris wrote: post #148
w1ntermute wrote: post #51

Earlier quoted context omitted.

> You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running XP No, you couldn't. The difference in upgrade rates between Windows and OS X is primarily due to their differing customer bases. Windows is very popular in enterprise, which avoids unnecessary upgrades in order to ensure compatibility with in-house software. OS X, however, has almost no presence in enterprise, and cons…

I just want to chime in and say that Apple has done an abysmal job with backward compatibility, and it's not just due to the enterprise vs consumer market. I would wager that if you looked at the total list of apps ever released for Mac OS, the majority of them would not run today. That's because Apple's primary strategies are 1) innovate and 2) put the user first. Putting the developer first is not part of their pro…

I'm glad they didn't try too hard in porting MacOS to iOS. The touch/mobile platform is significantly different than the desktop platform. It required a huge rethink in design of the API and the UI. Is the Windows Desktop API similar to the Windows Phone API?

Re: About Python 3

#319

Post by dded »

gkya wrote: post #316
dded wrote: post #307

Earlier quoted context omitted.

I was careful to say "Unix strings", not "ASCII". A Unix string contains no nul byte, but that's about the only rule. It's certainly not necessarily human-readable. I don't think a programming language can take the position that an OS needs to "adopt better encodings". Python must live in the environment that the OS actually provides. It's probably a vain hope that Unix strings will vanish in anything less than decad…

> I was careful to say "Unix strings" This is the first time I encounter the idiom Unix strings . I'll map it to array of bytes in my table of idioms. > I don't think a programming language can take the position that an OS needs to "adopt better encodings". I do think that programming languages should take a position on things, including but not limited to how data is represented and interpreted in itself. A language…

> This is the first time I encounter the idiom Unix strings

The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C.

>> [...] probably a vain hope that Unix strings will vanish [...] >If only we wait for them to vanish, doing nothing to improve.

The article is about the lack of Python3 adoption. In my case, Python3's poor handling of Unix/C strings is friction. It sounds like you believe that Unix/C strings can be made to go away in the near future. I do not believe this. (I'm not even certain that it's a good idea.)

Re: About Python 3

#320

Post by LammyL »

jodrellblank wrote: post #220
danso wrote: 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…

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_D... and windows current / deprecated/obsoleted ones. Just to connect your Windows program to a Microsoft database.

To be fair, most of those deprecated technologies are 10 to 20 years old and use paradigms that wouldn't cut it with how we build software today.
Post reply on HN