Is Python 3 = Winamp 3? Is 2.7 the best version?

Python 3 is a major improvement and 3.6 is super. Unless you rely on Tensorflow or some other library that only works on certain versions then there is no reason to avoid 3.6..

More elegant code, smarter code and so on and so forth.

Python 3 = C
Python 2 = Cobol

Python 2 is ancient history

Unless you're a scientist there is literally no reason to use python 2.

>>62336610
If you are a scientist there is literally no reason to use Python 2 either unless you deal with ancient legacy code. All science libraries have been updated now

>>62336460
Why is the python 2 meme still going on? No one uses 2.7 anymore outside of the companies that don't want to redo their code, or for the few (select) libraries that haven't been ported over to 3.

3 is better in almost every respect, and it's what's being taught now in Python-based CS classes. If you don't have a very specific reason to use 2.7, there is no reason to use it.

>some things simply don't work.

such as...?

File: op-12.png (284KB, 200x1133px) Image search: [Google]

284KB, 200x1133px

>>62336460
>but it will simply not work
Very descriptive, OP. That will surely let us explain why one or the other is the better choice.

Over here, I've been using Python 3 in production for ~5 years or so, since 3.2.

>>62336685
>>some things simply don't work.
>such as...?
Trying to compile caffe. And it only worked with 2.7.

>>62336685
>No one uses 2.7 anymore outside of the companies that don't want to redo their code
In my case, I still have to maintain some code for Python 2 because of Jython. Can't wait for Jython 3.

>>62336702
>Trying to compile caffe.

apt-get install python3-caffe-{cpu,cuda}

Get with the times, gramps

Python 3 is a superior language. 2.7 needs to die out so that the community can finally be reunited.

>>62336727
>>62336702
Using the build_win.cmd

It only worked when I got the python 2.7

File: lol-18-2.png (64KB, 305x330px) Image search: [Google]

64KB, 305x330px

>>62336774
>trying to program on windows
Haha, yeah, might just have found your real problem, OP.

>>62336774
Which is literally not the fault of Python in any regard.

If you want some serious advice: install a linux distro as a dual-boot on your windows machine. It will make your life a lot easier.

>>62336774
>build_win.cmd
There isn't even such a file in the Caffe distribution. It couldn't possibly be that you're sitting around blaming Python 3 for fault in some malwared install script you found off Stack Overflow, now could it?

>>62336800
>>62336937
What is the problem with windows. It has the best IDE of the market = Visual Studio.

>>62336941
https://github.com/BVLC/caffe/tree/windows/scripts

hurr durr

File: the-blessed-lords-reaction-to-your-faggotry-and-apostasy.jpg (21KB, 371x358px) Image search: [Google]

21KB, 371x358px

>>62336967
>IDE

>>62336630

Ancient legacy code is surprisingly common in science.
t. Physicist.

>>62336990
>developing software
>not using a development environment

>>62336981
>separate unmaintaned windows branch
Yeah, pretty much as good as copy-pasta from SO.

>>62337037
>development environment
>integrated development environment
Spot the difference?

>>62336460
the first few major releases of 3.x sucked ass as they were just renaming everything, but since 3.2 there's been some interesting stuff like asyncio/futures/coroutines where people can actually see some benefits

>>62336967
Nothing. Which is why I suggested a dual boot, so you can choose the option that works best for whatever scenario. VSCode (not really an IDE, but still) is available on linux and there are a number of alternatives like Eclipse or QT that you could use.

Options are always good, and linux plays really well with Python in general.

>>62337053
Integrated is obviously better because the parts work better together.

>>62336999
Depends on how you work. Whenever I have done research I always had to do everything from scratch ever time. It might be different in physics where there are large scale projects than span for years, but other than that there often is new code and then Python 3 is the ideal choice.

t. Engineer that does scientific research

>>62337114
>they were just renaming everything
There's also that little thing with fixing their Unicode mess, and making everything iterator-based. Those were the reason I switched to Python 3.

>>62337136
Just like how an Integreated Internet Suite like Seamonkey works better than a stand-alone browser and e-mail client, amirite.

>>62336505
> major improvement
No, no it isn't.

>>62337037
next you'll be telling me you don't edit in vim you absolute caveman

>>62337143
There were (select) autists who thought it was a "feature".

>>62337177
Yes it is! If Python 2 is a mud hut then Python 3 is the Castle of Versailles. It's a major improvement.

>>62337177
Yes, yes it is.

>>62337143
but to the average pythonista that's just renaming str to bytes and breaking all my print statements, if you hadn't been bitten by UnicodeDecodeError 1000 times you might not understand

>>62337233
Odd, then, that I wasn't bitten by UnicodeDecodeError 1000 times even though I've converted tens of thousands of lines of code, much of which is deeply entrenched in conversion between Unicode and bytes. Wonder why that might be.

>>62337154
Browsing the internet and reading your email are two quite disparate activities.
Developing software is a cycle that consists of writing code, testing and debugging. It makes sense to integrate those tasks.

>>62337261
>It makes sense to integrate those tasks.
It makes tons of sense if you want a huge bloated program that tries to do 10,000 things and consequently does none of them well.

>>62337253
UnicodeDecodeError was a 2.x problem, obviously once you move to 3.x it's not going to

>>62337297
Why would I want to use a separate program for debugging when I could use the same program I edit the code in?

>>62337324
Right, I see what you were saying now. Nevertheless, it had to be fixed.

>>62337329
Because a dedicated debugger program will be better built for debugging. It's the same reason why mdraid+lvm+traiditionalfs works better than btrfs. Trying to make everything at once makes you care less about the details of every things involved.

Besides, I run gdb from Emacs in gud-mode, so I get those benefits anyway, except I have a better text editor and a better debugger.

What's the best course/tutorial for Python? I want to pick it up

>>62337421
Just decide on a program to write and research what you need to write that program.

>>62337421
The official Python 3 tutorial on their website.

>>62337375
No it's not, mdraid and any other software RAID is AWFUL and has a very high chance of killing your data if your drives are big enough.
Not him, I use vim and gdb on Linux but setting that up is such a hassle on windows when you can just click a breakpoint in VS.

>>62337539
>mdraid and any other software RAID is AWFUL and has a very high chance of killing your data if your drives are big enough
What are you even talking about? I sure hope you have sources backing that up.

>>62337539
>when you can just click a breakpoint in VS.
C-x C-a C-b in Emacs.

>>62337539
>killing your data if your drives are big enough
I sure haven't had a single problem with 15+ disks for just about 10 years, many of which are 3 TB, and anecdotal evidence is better than no evidence at all.

>>62337848
First of all software RAID caches to the hard drive which means unless you have an SSD you are not gaining much speed.
Then RAID itself has rather high chances on failing on rebuild. Mirroring and backing up is gaining more relevance with bigger drives.
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable/

>>62336967
Use gvim kohai

>>62338009
>First of all software RAID caches to the hard drive
mdraid doesn't do any "caching" at all, the only cache involved is the standard block cache. What is "caching to the hard drive" even supposed to mean?
>Then RAID itself has rather high chances on failing on rebuild.
To the extent that is true, it's true of all RAIDs, hardware, software, or btrfs. Such failures, however, are the exact reason why mdraid runs weekly checks through the entire drives.
>Mirroring [...] is gaining more relevance with bigger drives.
Which... is exactly why you use mdraid to begin with.
>http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable/
Your link doesn't even mention mdraid.

>>62338009
>seven pages about why putting 12 hard drives in a single RAID 5 array is a bad idea
Thanks, I really needed help figuring that one out. How about we talk about a realistic scenario now?

>>62338009
>>62338209
There's so much wrong with this article.
>On common SATA drives the rate of URE is 10^14, or once every twelve terabytes of read operations. That means that a six terabyte array being resilvered has a roughly fifty percent chance of hitting a URE and failing.
Here the author gives away that he has zero clue about probability theory. The real chance is 1 - ((1 - 8e14) ^ 6e12), or ~38%
>At six terabytes you can compare a resilver operation to a game of Russian roulette with one bullet and six chambers and you have to pull the trigger three times. With twelve terabytes you have to pull it six times!
Or more like ~62% chance in reality.

Of course, the obviously high numbers just goes to show why the statistics he relies on are bullshit to begin with. My 18 TB array rechecks itself every week, so it reads 936 TB every year just for that, and in more than 5 years of doing that it has had zero UREs rather than the 75 that his bogus statistics would predict.

>>62338402
>75
And when I say 75, I meant 75 per year.

>>62338009
>>62338209
>>62338402
>When it does the resilver operation halts and the array is left in a useless state
This is also such bullshit. I actually did have a rebuild error at one time for my mdraid mirror, due to a loose S-ATA cable while rebuilding, and while that drained the blood from my head, all I had to do was just restart the rebuild. Nothing went wrong the second time and the array is running again.

>>62336460

2.7 is the best vesrion, yes.

Forget about the Python3 shills ("hurr, deprecated!!"). Python 3 got it all wrong.

>>62336967
>What is the problem with windows
No POSIX compat.
>It has the best IDE of the market
VS isn't the best IDE for Python.

Single killer feature for python3:
shit="poo poo"
f"ohhh {shit}"

>>62338915
>Python 3 got it all wrong
Do name just one thing. Protip: You can't. Python 3 is better in literally every way.

>>62336460
I can't wait for Python 4 when they finally get rid of the GIL and rework the entire fucking standard library to allow true concurrency

>>62337177
It very much is

>>62339262
>get rid of the GIL
Hahaha. Better get ready for waiting, Anon.

In the meantime, Jython has no GIL.

>>62339284
it's only been in the language since 1998, there's still time to remove it before everyone depends on it

>>62339284
jython is also dead, only pypy can save us

>>62339332
To be fair, the reason it's not getting removed is not so much because people depend on it (I don't actually think anyone does), but because it really is a whole lot of work to rewrite the all the built-in types (dict, list, and such things that are written in C) and stuff to use finer-grained locking.

>>62339426
>jython is also dead
Not really. it's pretty slow-moving, but it's not actually dead. As far as I know, work on Jython 3 is progressing, just not particularly fast.

Python 3 use where they fixed a lot of brain damage in Python. Up until 3 came out, the fact that python worked and was comprehensible was a happy accident. Python want really designed, it just happened. Three fixed that, made it coherent, and consistent.

>>62336999
And in biology. I support a bunch of biologists at work. I swear they don't update to python 3 because they don't remember how to program , and what they wrote as a grad student is, "good enough," as far as they're concerned.

>>62339451
PyPy is seeing if there's interest in removing it's GIL, which should be easier than removing it in CPython

>>62339566
why rewrite if it works, worst case you can still interop between different versions/interpreters with multiprocessing

My Linux installation had installed both Python 2.7 and Python 3.
I normally use Python 3 because that's how I learnt to use Python
But recently i have wanted to do a lot of networking stuff, so i installed "requests" conveniently through a package manager.
Turned out it didn't have it available for Python 3, only Python 2.
So then i switched to Python2.
Other than the unicode bullshit (can't write äöüß into my source code), it works pretty much just like python 3. So who cares

>>62336610
scripting to other softwares requires python 2.7 most of the time

>>62339735
requests has support 3 since 2012, user error or blame your maintainers

>>62339719
>why rewrite if it works
Bitrot isn't caused by a program in itself, but by its interface with the rest of the system. Python evolving is just an example. As long you as you want to keep using a program, you have to be prepared to maintain it. The alternative is to have something as disgusting as Win32.

>worst case you can still interop between different versions/interpreters with multiprocessing
It really sounds easier to port the program to Python3 then. It's not that big a deal.

>>62339735
>Other than the unicode bullshit, it works pretty much just like python 3.
That is until you discover that your for i in range(1000000000) now uses jiggabytes of RAM.