python 3

What do you think about it /prog/?
Is there some drawbacks in using it?

I think these threads are by far more obnoxious than homework threads.

There's less library support, and encoding/decoding unicode is a bit slower than treating everything as bytes. That's pretty much it.

Thanks bro. I noticed it's far more filled with generators, and that rocks.

>>3
Encoding/decoding unicode is no slower in Python 3 than it was in Python 2.  The only differences are defaults -- strings literals default to unicode unless you prefix them with 'b', and I/O streams default to unicode unless you open them with 'b'.

And I'm not sure what kind of perverse fascination you have with encoding speed in a language which is usually interpreted as byte code.  If you care about shit like that then you shouldn't be using Python in the first place.

I read through the overview of changes and they've taken out a lot of stuff that shouldn't have ever been in a language in the first place. Although, not being a FIOCista, I'm not sure how much more of that kind of stuff is still left in.

Guido is going to remove

"%s %s"%("my","anus")
We need to stop him.

>>7
And print is becoming an ugly function, and FP sucks harder, ...

>>7
That's arguably the single most useful feature of Pythong.

>>7
Of course, we need more special syntax. Just like Java's lack of operator overloading (oh, except for strings)

OP here.

As long as I can see they removed lots of design errors they put in previous versions. Also I see they've improved threading... are they telling me now we can use smp??

>>11
lol no

click here Global Interpreter Lock

>>12
Ok, can someone explain me why they put that bullshit into the code? This makes it definitely a toy programming language... this sucks monkey balls.

>>11
lol u mena haskal or lisp right

>>14
Does haskal has a GIL?

>>15
no but they are toy languages

>>13
Why don't you fork like god intended you to?

>>17
Go fork and prosper!

Pros:
- Closures work properly, finally
- Unicode everywhere, finally
- Lazier standard library
- More future-proof
- Small language and library improvements, small but worth it

Cons:
- Less library support
- Slightly less GNU/Linux distribution support
- OMG LESS OPTIMIZED (slightly, in an already not fast-as-C language; don't give a shit for this, just use it)

>>19
The D Programm-you know.

Each source file is one Z-layer that is to be executed in parallel with the others; imagine reading a translucent book and interpreting the nth line of each page simultaneously

>>21
The ability to visualize the consequences of the actions under consideration is crucial to becoming an expert programmer, just as it is in any synthetic, creative activity. In becoming an (* x x x) In this chapter we are going to look at more complex data. All the procedures in chapter 1 operate on simple numerical data, and simple data are not sufficient for many of the The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in Figure 2.2:  Box-and-pointer representation of (cons 1 2). [etc]

^{Back to /b/, ``GNAA Faggot''}