Is Python3 the biggest JUST in the history of programming languages?
>>51579490
There is literally nothing wrong with Python 3.
>>51579535
It's fucking slow.
We are in 2015, nobody want slow shit anymore.
>>51579535
>There is literally nothing wrong with Python 3.
>There is literally nothing wrong with Python 3.
>There is literally nothing wrong with Python 3.
>>51579490
perl6
Is Python3 the biggest _____ in the history of programming languages?
>>51580012
joke
>>51579490
>>51579535
>>51579908
>>51579970
>>51579978
>>51580012
>>51580019
there is no excuse to use python 3 over python 2. python 2 is superior to 3 in every single way.
>>51579908
use goLang !
>>51580100
fucking die
>space after !
Yeah die.
>>51580012
fork
i can't blame them for wanting to fix very deep-seated design issues with their programming language honestly
>>51580110
Fuck you too ! Have a great day sir !
>>51580082
no tuple unpacking in function arguments
forced to use parenthesis for print
literally no libraries available
python 2:
print "ass"
python 3:
print("ass")
why?
>>51580850
python 3 uses a more logical and consistent way
here "print" is a function and "ass" is an argument
>>51580850
To play with the big boys.
>>51579978
Yeah he's got you there OP. Don't forget the never-ending saga of Perl 6; so late to the party the building the party was held in has been torn down already.
>>51580899
yes but its so fundamental
why isnt while i now while(i)?
>>51580935
Because while is not a function.
>>51580935
cos "while" is a program flow control element while "print" is not
>start learning python
>start noticing threads shitting on python
>>51581005
Should have been more vigilant, anon. Looks like you fucked up.
>>51580634
wut?
almost all libraries work with python 3, and for the ones that don't - there are equally good replacements available.
>>51581005
you can use multithreading just fine in python if you are doing i/o bound operations.
python 2 will always be used over python 3. there is no reason to use python 3 over 2. python 3 has terrible library support and nobody worth their salt recommends or even uses it.
>>51581152
this is just not true. i have been programming in python for a while now, and if you are starting today you should definitely be using python 3
>>51581152
it may just not be worth upgrading an existing codebase in rare cases - depending on the library compatibility of course
>>51579978
never heard of it
>>51581114
>Python threading
>GIL
>fine
kek
Isn't python3 supposed to be the future ?
>>51580850
Just to fuck with people desu.
>>51581392
it is the present and the future of python.
it has several cool things that make it work upgrading to. but for most python users and most people on /g/, things like better tracebacks, type annotations etc etc is not a useful feature.
>>51580850
Just consistency, it's a function, treat it like it's one.
If you are lazy, just run something like sed -i 's/print\(.*\)/print(\1)/' dumb.py
The print thingy is not the biggest issue in porting python 2 code to python 3.
The byte array/utf string stuff is far more annoying.
It's a mess when you try to maintain your code compatible for python 2 and 3, specially python 3 < 3.3 (yay, I love those ugly _u('my string') instead of u'my string').
Library support is also an issue, specially libraries which are C bindings (python-ldap for example).
>>51581081
https://www.youtube.com/watch?v=MCs5OvhV9S4
(by the way, aside from the presentation, the live coding is really impressive)
>>51581081
>mfw there are pythongays who actually, legitimately believe this
Only the smallest libraries - those that can be replaced - actually support python3. Big libraries - those that have no replacement - either don't support python3 at all, or only support python3 for a subset of their features.
>>51581470
>The print thingy is not the biggest issue in porting python 2 code to python 3.
this. no one should be using print statements in their code anyway.
>The byte array/utf string stuff is far more annoying.
it's going to be a problem for _some_ people, but for the vast vast majority - _especially_ those who don't know the difference - its a much better default. they ( we ) can't even understand the cryptic error messages when something goes wrong.
>>51581470
>Library support is also an issue, specially libraries which are C bindings (python-ldap for example).
are there no replacements?
>>51581540
can you name one of those "big libraries"?
>>51581540
https://python3wos.appspot.com/
>173 of the 200 most popular libraries support python3
>>51580634
>literally no libraries available
http://py3readiness.org/
Git gud, idiot
>>51580100
YAY, 75% of the ecosystem has never heard of semantic versionning, no version, no tags. I particularly like stuff like godep directly referencing fucking git revision hash...
Believing 'static' compilation will solve all problems and avoid having to managing api compatibility is a huge mistake.
The module naming scheme is also kind of crappy, it will be quite fun when github will die.
>>51581675
why the fuck does go pull packages directly from github - it makes no sense
Sup senpaitachi.
I'm a total faggoty noob with regards to programming, but I'm learning python at the moment. Python 2.7 specifically on EDX, supplementing with Enthought online training.
Am I a faggot for thinking that programming my own 2D finite element modeller is achievable? I'd love to be able to put in a beam or beam/column system and pull out the moments and shear forces, along with deflection calculations for frames etc.
>>51581724
>mfw 'f'+'a'+'m'+'s' is filtered to 'senpaitachi'
>>51581724
are you using numpy? if so you should have issues
>>51581754
Yes I will be using numpy.
> if so you should have issues
I hope you meant to type 'no issues' matey.
>>51581754
>should have issues
should have no* issues
>>51581541
In the case of python-ldap, yes, there is one which seems decent enough: ldap 3 (which is python 2 and python compatible).
It seems to have enough momentum around it.
But:
1) it's not package in some distributions like CentOS RHEL
2) when you have a working ldap plugin, you kinda don't want to touch it again ^^
>>51581768
k - just make sure you outsource as many operations as possible to numpy. it does more than basic vector / matrix operations.
for my line (real time analytics) - i have also found pandas to be a nice supplement to numpy as well.
>>51581600
Popular != big.
>>51581568
The LSSP stack.
>>51581724
Use theano and you're all good to go.
>>51581768
one more tip, in the past I have replaced the underlying BLAS library with another more optimized one which gave a nice speed boost.
i don't remember exactly what I did (was a long time ago), so i dont want to point you to a wrong article.
if you are in the mood for optimization ( which most people dont really need ), search google for "faster BLAS numpy <insert-your-platform-here>"
>>51581904
Just use ATLAS like anyone sensible.
>>51581722
Actually pulling from github is not the worst part.
gopkg.in is far more annoying as it's an horrible hack to fix a broken concepts (renaming package names, seriously...).
>>51581939
i think that's what i replaced it with? i remember it used something called liblapack or was it liblaplack
>>51581540
the problem is small libraries too. random shit that you find on github to avoid writing simple things will always be in py2
>>51581470
2to3 should do most of the obvious stuff for you
>>51581005
no one cares what g talks about, half the people here barely leave their houses
just use it and forget what anyone else says
>>51582018
running a script that modifies code on a non-statically compiled language just sounds like a bad idea.
i would never rely on this in production.
>>51582002
ATLAS and LAPACK aren't the same thing. ATLAS is a jitted implementation of BLAS whereas LAPACK is a linear programming library. There is lapacke which combines LAPACK and ATLAS, though.
>>51581904
>>51581802
>>51582002
Thank you friends. As I'm just starting out, I have no idea what the fuck I'm doing.
But I will bookmark this page when I get to the stage of actually putting it all together.
>>51581005
Just don't use Python3.
>>51582018
The problem is that "most of the obvious stuff" is not the issue in porting from 2 to 3.
got it, it's just been a really long time for me.
>>51582060
python2 is shit too, desu senpai. The difference is that it's actually well used and supported, which is a real shame, but a fact nonetheless.
Best Python IDE for creating standalone programs?
anticipating shit flinging.
>>51582107
intellij pycharm
>>51582084
Every Language is shit.
Some are well supported and shit.
Some are poorly supported and shit.
I know which I'd use.
>>51582107
vim
obviously.
>>51582107
>using an IDE
>>51582084
>python2 is shit too,
it's comfy as fuck though
>>51582107
emacs
>>51582121
Some languages are less shit than others.
>>51582132
It's comfy for the first week you use it, then it starts cracking at the seams, then the whole thing just explodes in your face. Not pretty and certainly not comfy.
>>51582107
pycharm
>>51582129
You know, I see a lot of stuff arguing back and forth for IDEs all over the internet. It's the same thing here on /g/. Now while I understand a lot of the reasons for each case, there's one thing I'm not so sure about.
My question to you is, given you don't advocate the use of an IDE; which Autism spectrum disorder were you diagnosed with? I'm asking this because I'd like to understand the general demographic here on /g/.
What's up, senpaitachi?
>>51582219
I'm not autistic at all. I use gedit like a normal person would.
>>51580850
>print("ass")
So you can do things that weren't possible in python2
print("ass", end="\r")
>>51582107
Pycharm. That debugger is glorious, and the integration with unit tests and code coverage is neat.
>>51581740
Hiro is a madman for the senpaitachi.
>>51583060
print "ass" + "\r"
print "ass", "\r"
???????
>>51583669
it's not a function tho
>>51579535
Except its reference interpreter design.
