Log file Viewer
#python2.8 logs for Wednesday the 8th of January, 2014
[01:37:34] <estiban> So thank fuck for this, how is the fork going? I'm glad there's an alternative to using 3
[02:04:04] <estiban> I get the impression from that, that this '2.8' isn't a break from the nastiness of 3, but a way of tricking people into 3
[03:16:25] <scombinator> Count my unhappiness with py3 is not the transition. I have no real old code base to port. 2.7 is where I'd like to stay please
[03:16:38] <tos9> although there's some really really angry ones, so it may all be the same angry dude with lots of aliases.
[03:17:51] <scombinator> tos9: I know I'm not going to be able to stay on 2.7 forever, I'm looking for where to jump to, but it won't be python3
[03:18:39] <scombinator> it's the unnecessary breakages. Unicode, fine. The solution isn't fantastic, but I appreciate it'll probably get there eventually
[03:19:43] <scombinator> Solution to division problem, changing print into a function... those are unnecessary. Why not change import into a function? Why not and?
[03:20:29] <scombinator> Those with 2.7 have been given a bit plate of fuck you, port your code, by a bunch of people with nothing better to do
[03:21:01] <tos9> They of course are unnecessary, the mindset around Py3 was a lot of "there are a few major problems to fix, and while we're at it we'll fix some minor warts"
[03:21:35] <tos9> Or are enough, if I was someone coming fresh to Python, for me to say, uh I will look elsewhere
[03:22:16] <scombinator> Ivo: I'm not getting supported. There is no support for those who came to python because it looked like it had nice code, only for that to change
[03:25:57] <Ivo> http://www.python.org/dev/peps/pep-3105/ is the rational for print() and why print is ugly, if you're interested
[03:26:04] <scombinator> Python used to be the language without any horrible warts. Julia + R have 1-based indexing, as does lua which also has no integers (as does javascript). Scheme and common lisp have no community, go requires casting and horrible workarounds for its objects, ruby has no scientific community
[03:27:25] <scombinator> Ivo: print() is ugly. You look at any script with blocks of print statements, you can read the text, and still interpolate so it's understandable. you add parens everywhere - Why?! I thought we hated that shit - that's why if doesn't have them, right? but no, fuck consitency
[03:28:28] <Ivo> if you start with the a priori presumption that print is a statement then of course you will think its weird as a function
[03:28:29] <scombinator> division now has a horrible special case. Why not make it return complex numbers for every division if we want returns to be consistent? No, we don't because that'd be fucked
[03:29:36] <scombinator> Ivo: 5/2 is a hard truth they are going to have to learn. Why bother with integers at all then? Just get rid of them if it's too confusing
[03:32:26] <Ivo> do you have some objective measure by which to say which are the 'hard truths' and which things are 'obvious' and what 'is obviously a statement'?
[03:40:53] <tos9> are you [guys] prepared, beyond just 2.8, to attempt to standardize a set of things that you're going to call 2.8
[03:44:41] <stackless> sure! well -- right now it is not that much but the support for recent windows compilers, tossing BSDDB, adding a few modules that some people need, plus "THE BIG PROMISE": (kidding)
[03:45:26] <stackless> "we will port whatever you need, if it makes sense and is doable in finite time"
[03:47:32] <stackless> There is no limit per se. It just needs to make constructive sense for helping the migration.
[03:49:19] <stackless> there are simple things, there are hard things, and a few things are a re-write. The latter are not so likely to happen.
[03:50:08] <stackless> these are the inner structural changes which are real changes of the concept.
[03:51:54] <stackless> for instance: The change of the exception heirarchy are pretty impossible to port. I think that is something where it goes to the balls of the language.
[03:53:31] <stackless> put it the other was around: the print statement is just fluff. Much hype, little consequences, IMHO.
[03:54:27] <tos9> Have you thought about that? That's a thing that should have gone into 2.7 anyhow :/
[03:54:58] <stackless> tos9: yes. This is a crucial change that involves a lot of the interpreter. We are probably not going to try to patch that. That needs acceptance.
[03:55:56] <stackless> The pip situation is a different story, of course. I have burnt my ears quite a bit on that before.
[03:57:15] <stackless> I accused the supporters for ignoring py3 way too long, because all changes were done for 2.7 in the first place.
[03:58:19] <stackless> I tried to talk them into changing strategy, because the python-dev efforts seemed to be different from the package maintainers view.
[03:59:18] <stackless> Actually I stepped out because that is hard for me to stand for a while, but things seem to work better.
[04:00:54] <stackless> just to tell you guis: I was on 2.6/7 till 2011, then in 2012 I took it on and forced myself to become a Python 3 guy.
[04:02:47] <stackless> and that was no fun. I ported lots and lots of modules, also on different projects, worked on ZODB, Watchdog, tried to enhance Durus, whatnot.
[04:04:38] <stackless> well, the guys did a lot, but I made their zodbpickle very recent, because I wanted to use that, regardless of Python 2 or 3, I think the world needs a good object DB.
[04:05:33] <stackless> So after all the years, I decided to simply go and do things that I want to exist.
[04:07:16] <stackless> Now, after forcefully turning myself into a python 3 developer, I want to force the world to follow. Kidding :-)
[04:08:10] <stackless> Ivo: Yes! I wanted to make stackless the new direction for Python, and I was very pushy on that.
[04:09:00] <Ivo> well i imagine there would always be some resistance to such a large feature but how did it go?
[04:10:00] <stackless> I failed miserably, in the end. But since I never give up, I am back, trying to have some impact, for the good. (NOT kidding)
[04:11:55] <stackless> The light-thread thing -- you are right. That was a thing that I supported 10 years ago, probably at the wrong time.
[04:13:30] <Ivo> man you should've got it in 10 years ago, python could be on the fore-front of eventloop servers right now! :P
[04:13:34] <stackless> well, I believe that I was the reason why we have generators, today. It was implemented by Neil Schemenauer, as a response to my
[04:14:52] <Ivo> you can see from the massive popularity of go and gevent that green threads are a great idea
[04:15:04] <stackless> Actually a good thig, and so I'm rather pleased with that. (Although it would be soo much er=asier... hum)
[04:17:13] <stackless> I do not claim anything. But I would have loved a Guido with his knowledge of today, back in 1998.
[04:18:09] <stackless> asyncio is going to be what I always dreamt of, in a clean, well=designed manner.
[04:18:59] <stackless> that is where Guido is absolutely phantastic, and I cannot do that at all. This was the missing thing.
[04:20:05] <tos9> They're designed by decent developers, occasionally in domains they aren't necessarily the first choices for writing them but whatever, but then they're in the stdlib before any real users have chances to use them, at which point they're now locked in.
[04:20:32] <Ivo> I've talked to a guy also trying to do a non-gil'ed python, he didn't think the windows event loop was designed very well, and actually of the opinion that window's network async design was better than linux's, if you used it properly
[04:22:38] <stackless> I am taking a different route, again. Multiple interpreters, completely disjoint, with the ability to exchange data.
[04:23:42] <stackless> this is orthogonal to the STM thing that Armin Rigo does, and that is good, because this scales together.
[04:25:57] <stackless> Ivo: I talked to Trent at PyCon last year. Interesting. But convinced me that I want it different (hey, sorry)
[04:27:23] <stackless> I am thinking of multiple interpreters with no GIL, but for simplicity just a local one per interpreter: a LIL.
[04:28:18] <stackless> between these local interpreters, which all run in their totally disjoint interpreters, there are communination channels,
[04:29:25] <Ivo> stackless: if you haven't talked to him in a while, i imagine http://vimeo.com/79539317 would be an extremely interesting video to watch
[04:30:10] <stackless> only on a needed communication, these interpreters will interact and incolve some locking scheme.
[04:30:34] <Ivo> i haven't watched it yet either but I just remembered he said he was going to do an updated talk at the end of this year
[04:32:17] <stackless> (just reading with one eye) -- the general fault is the sharing idea. While great for a single process, it is wrong for many parallel cores.
[04:33:35] <stackless> That is what Python has to learn. We can tweak it artificially by extreme tricks like STM, but a language that relies on sharing from the ground needs a re-design, befor it scales.
[04:35:00] <stackless> That's what I'm going to build as a draft implementation: It does no longer fit the world. The world is replicating, copying, rarely
[04:37:15] <stackless> eevee: which i effectively the same, therefore I don't distinguish the layouts. It is about the concept, not the implementation.
[04:37:53] <eevee> you don't think copying and mutating independently is very different from not being able to mutate in the first place?
[04:38:56] <stackless> things need to be as local as possible, however it is done. Things need to join when they need to communicate, no more.
[04:39:47] <dash> historically, the trouble with multiple interpreters in the same process is C extensions
[04:40:08] <stackless> eevee: there is of course a difference that is O(n) vs O(1) of course, but crucial is the concept of sharing vs copying.
[04:41:42] <stackless> the idea of "everybody has to see and obey what I change" vs "I can change what I like and others need to update" is dramatically different.
[04:42:55] <stackless> dash: in my rough concept, I therefore start with a "shared-nothing" concept, which is totally un-pythonic in the first place.
[04:43:58] <stackless> to get that usable will be the hard part. Things need to take actions in order to copy/share/participate in other things.
[04:44:56] <stackless> python by default goes the other war round. Perfect for a single process. Deadly for many cores that need to run as freely as possible.
[04:45:33] <sinistersnare> Im just randomly popping in now, but is there any wat that we dont just 'fork' CPython (if forking is the only option) but instead try to urge another project like PyPy or Stackless to head to a 2.8 or similar?
[04:46:36] <stackless> I want to build a proof of concept. Then I want to convince Guido and make him build the language concept which is right.
[04:49:47] <stackless> sinistersnare: mentally right now, not yet implementing. Guido? Sure, in Montreal the latest.
[04:50:29] <sinistersnare> Cool, i wish i had the money to go to Pycon, but living a highschoolers budget :p
[04:55:56] <stackless> dash: not necessarily multiple OS processes, although pretty close. You can have many threads, almost like processes, but still have a common memory pool. I think that is useful, between controlling processes and a single thread.
[05:05:35] <stackless> well, he is still missing the point, IMHO. I'm not into many small handlers of web servers, this always was the wrong emample.
[05:10:30] <stackless> I agree that he can solve the Kagel 10K propbem, partially, that goes back to http://www.kegel.com/c10k.html
[06:42:13] <dstufft> tos9: FWW asyncio is available on PyPI for 3.3, and haypo has it for 2.7 I think too (although probably slightly different given that nature of 2.7 vs 3.x)
[12:31:51] <itamar> faassen: hello. while you're in same awakeness timezone as I am - Future is cool looking for applications, but not useful for libraries (e.g. Twisted), because it makes things backwards incompatible
[12:53:06] <faassen> itamar: where I speculate it would downconvert back to python 2 unicode/str but instead it upconverts to future bytes/str
[12:54:04] <faassen> itamar: but the effect of bytes .. if they're not a superset of python 2 str, I think you can have a problem.
[13:00:51] <itamar> thus twisted uses native bytes class, so on python 2 you get python 2 behavior and on python 3 you get python 3 behavior
[15:00:02] <faassen> itamar_away: will you be commenting on that issue? I think it'd be really valuable to get your perspective, so please!
[15:40:43] <faassen> I remember after engaging in a comp.lang.python discussion why I stopped arguing with people on mailing lists. I guess I got old, I can't do it so well anymore. :)
[16:07:45] <faassen> well, I find irc direct enough you don't get these drawn out arguments where nobody is really listening to each other.
[17:12:34] <tos9> mitsuhiko: haha. You linking 20 django tickets is way more useful than what I was about to do, which was just describe what would happen. So thanks.
[17:23:44] <tos9> dstufft: Just the unicode_literals stuff from yesterday. https://github.com/PythonCharmers/python-future/issues/22#issuecomment-31854142
[19:32:14] <Spanktar> maybe, rather than a full version (2.8) something more like a shim? A Python Shim for Python 2 code. Include it if you want to ace transitioning code. Discuss.
[22:16:52] <dash> Spanktar: Part of the problem is that Python 3 removes features, it doesn't just add them.