Log file Viewer
#python2.8 logs for Monday the 6th of January, 2014
[20:46:25] <marcini> I haven't worked it all out, I believe the problem happens to revolve around str/unicode/bytes types
[20:46:30] <mitsuhiko> at least every time ncoglan adds more defends to his book based on my feedback it's about protecting innocent programmers and about how it subjectively feels better :)
[20:47:01] <aclark> marcini: it could be political in a lot of ways… the whole "2 communities 2 languages" makes is political for starters
[20:47:14] <marcini> is there any consensus that most of the community that has NOT moved over tends to be from the scientific computing side?
[20:47:41] <mitsuhiko> also just for the record: in case a 2.8 happens, that's political in a second
[20:48:06] <marcini> in other words, is there a correlation of py3vs.py2 between nonscientificVs. scientific?
[20:48:37] <mitsuhiko> scientific and people not using python themselves (editors, 3d applications etc.)
[20:48:49] <stevezzz> stackless python was told it could not use the words python and 2.8 in combination, because it would be a pr nightmare
[20:49:19] <mitsuhiko> stevezzz: christian told me today to change my article not to mention "stackless" "python" and "2.8" in a sentence
[20:50:09] <marcini> i have to admit, i don't follow too closely, but I'm just voicing from my corner of the world
[20:51:57] <faassen> there's the whole trademark things, but a small change should avoid confusion already, given the precedents we have of PyPy and IronPython and Cython such.
[20:53:00] <Spanktar> so if there were to be such a thing, what would be its goal? Why would 2.8 be considered?
[20:53:36] <faassen> but anyway, Nick Coghlan in his python notes said: https://ncoghlan_devs-python-notes.readthedocs.org/en/latest/python3/questions_and_answers.html#what-would-it-take-to-make-you-change-your-minds-about-the-current-plan
[20:53:58] <faassen> where he says since there's no effort to make a Python 2.7+ from the community, there doesn't seem to be much to convince them that they should change their mind.
[20:55:13] <faassen> I make the argument making it official is exactly what is needed to get the high gravity users moving.
[20:56:01] <marcini> drinking the koolaid, sounds like my language, but what do you mean by it @stevezzz?
[20:56:09] <faassen> yeah, a fork under a different name, if it got traction, would be really serious rifts.
[20:56:39] <stevezzz> marcini: Who believe it when they get told that they have to move to 3.x, and have done so. Or felt the move compelling enough already.
[20:57:07] <faassen> you could point at examples like the EGCS fork energizing gcc development, but you have to be very lucky it goes that way.
[20:59:12] <mitsuhiko> so i'm not going to be politically correct right now: but python3's largest community is i think newbies
[20:59:35] <mitsuhiko> from everything i have seen so far, the fewer 2.x code people have, the higher the chance that they are using python 3
[20:59:50] <cwillu_borken> faassen, just fyi: maybe /topic This channel may be publicly logged; in accordance with freenode policy
[21:00:18] <stevezzz> marcini: Inevitably, we're all the community for py3, unless someone maintains a 2.7+ with backported features, because at some time the amount of compelling features is going to hit a tipping point.
[21:00:36] <marcini> newbies though is the problem tho isn't it, because the community, by defintion, is not "newbie", and that is what is forking everything
[21:01:30] <marcini> @stevezzz I'm not so sure, this fracturing of the community may be at a tipping point, such that amt of compelling new features is near zero.
[21:02:19] <faassen> the question is whether we consider the "escape velocity" scenario tolerable.. is it okay that python 2 projects will be left behind?
[21:02:32] <faassen> or is this not okay and do we want them on board, as it'd be for the good of the community if no other reason.
[21:03:38] <stevezzz> faassen: But what does it mean to expect them not to be? Who is to do all the work not to leave them behind?
[21:03:53] <sinistersnare> mitsuhiko, in your opinion, is there anything that Python3 can do to fix the encoding problems? Most of what i read from you is just saying its bad (not complaining)
[21:04:24] <mitsuhiko> sinistersnare: the problem is that there is a disagreement on if this is an issue
[21:05:01] <stevezzz> cwillu_borken: I expect fending for themselves will be just making do with what they have
[21:05:31] <faassen> cwillu_borken: well, do we want the in house projects to remain on Python 2.7 forever and pay python developers to continue to create Python 2.x code? because that is the escape velocity scenario.
[21:05:34] <cwillu_borken> ..because anything else has the threat of legal action re: trademark hanging over it?
[21:06:06] <sinistersnare> I just wish they would have made the str type its on new type (same API as 2.x) and made unicode the default str, is that what other people here agree on, or is it something else?
[21:06:08] <faassen> I think the trademark issue is resolvable if you can get a team of responsible volunteers to do the work.
[21:06:44] <faassen> the question is whether you can get enough volunteers that agree about goals and directions to go anywhere at all.
[21:07:24] <faassen> there's of course also the pypy scenario, where pypy becomes a more popular 2.x interpreter, and it might backport language features, say.
[21:07:53] <faassen> cwillu_borken: yeah, that might make sense on Python 2.8 (and a no-op on Python 3.x)
[21:08:15] <faassen> cwillu_borken: i.e. features that were from future are disabled in python 2.8, and instead if you want them back, you go from __past__
[21:08:27] <faassen> cwillu_borken: and then in the next version, say, they're gone. that's going to make it really obvious.
[21:09:01] <faassen> cwillu_borken: hm, well, I guess that would be possible, if the 3.x series can get enough compatibility with 2.x to make it worthwhile. i.e. you can take a python 2.x project, add a lot of from past (or 'mode python 2').. that gest close to a dual-mode python interpreter.
[21:09:01] <cwillu_borken> i.e., add it, add enough of them that existing 2.7 code actually can work (as well as 2.x-1 has ever worked in 2.x), and then deprecate it, and then re-remove it
[21:09:13] <cwillu_borken> i.e., make it the same migration that's been used in every. other. python. release.
[21:09:31] <stevezzz> I don't think from __past__ really works. There's a direction that __future__ has, and to go the other way defeats the point.
[21:09:40] <faassen> cwillu_borken: yeah, that's another conceivable path that may in fact the be one of the least resistance. still requires serious contributions to Python 3.x.
[21:10:15] <mitsuhiko> though i think the scientific community has a whole bunch of header files helping with the transition
[21:10:27] <faassen> mitsuhiko: except if theyre in Cython, evidently. single codebase that works with py2, py3, and even PyPy somewhat. :)
[21:12:17] <mitsuhiko> jnoller: depends. things like numpy would not really work through CFFI on cpython i think
[21:13:13] <faassen> a concerted effort to add from __past__ to Python 3 so that python 2 modules will start working, mostly?
[21:13:53] <Alex_Gaynor> mitsuhiko: I think you could actually do numpy with cffi, just write each of the core loops as a kernel in C and invoke them from Python
[21:13:58] <faassen> yeah. you'd almost wish it could be implemented as an extension to Python 3, the deprecation cycle. you could get *some* of it going with some ideas taken from python-future.org.
[21:14:53] <mitsuhiko> i wonder how much code actually relies on keys() being a dict_keys instead of being a generator
[21:15:16] <sinistersnare> also, are there any other big 'problems' that a lot of people have with python3 except for the str/unicode debacle?
[21:16:30] <cwillu_borken> and the pervasive use of generators as mentioned before is annoying in some situations
[21:16:43] <faassen> there are issues with Python 3, i.e. mitsuhiko's bytes operations discussion, etc.
[21:17:06] <faassen> and there's the issue of how to get the community to get onto Python 3 smoothly, without losing big chunks, without all the disruption and confusion.
[21:17:28] <cwillu_borken> (does dict.keys() return an object with an actual useful __repr__ in sufficiently new python3?)
[21:17:29] <marcini> f@faassen i think that's a terrible idea (unless you're trending back to old dicts by default). There's are solid philosophical reasons for enforcing the generator view of things.
[21:18:13] <cwillu_borken> marcini, the point is to return to pick up the stragglers, and then move forward again
[21:18:24] <faassen> marcini: I'm talking about a __past__ for compatibility reasons. that terrible idea is how Python 2.x works. :)
[21:18:34] <mitsuhiko> cwillu_borken: depends on which dict. dict: kinda, but no support for pprint, collections.ChainMap or others: no repr
[21:18:37] <Spanktar> my approach to these problems has always been to give options. Migrate to a new manner, but give the option to the user to specifically request the old way while they adapt
[21:19:39] <marcini> @cwillu the problem is that if that's how you're picking up stragglers, your grafting one species onto another
[21:20:03] <cwillu_borken> the difference being that you should be able to retain whatever internal cleanups you've gained
[21:20:37] <cwillu_borken> and again, this only imo makes sense if there's a clear deprecation schedule for the __past__ module
[21:21:03] <cwillu_borken> i.e., one release of no warnings, one release of deprecation warnings, and then removal after that
[21:21:29] <cwillu_borken> what we actually got was effectively an immediate removal without _any_ deprecation cycle
[21:21:58] <mitsuhiko> i think that python 3.3 looks so much different than python 3.0 and that we're porting libraries very differently now is a good sign
[21:22:00] <cwillu_borken> (and oddly enough, people using the things that were removed have been slow to update :p)
[21:22:43] <mitsuhiko> my hope with that article was something else entirely btw. i was hoping python people would get a bit more humble and consider that people that don't upgrade don't just do that because they are lazy
[21:22:47] <faassen> cwillu_borken: they're doing this out of contrariness, they Hate the Future! :)
[21:23:18] <stevezzz> I think a 2.x evolved to the point where switching to 3.x is a straightforward update, would convert move than a 3.x with a from __past__ import
[21:24:30] <faassen> mitsuhiko: well, okay, we don't agree on the problem. does the python community need a python 2.8 version.
[21:24:36] <mitsuhiko> there are "wish i could have that", like nonlocal, but that would have the opposite effect and keep people on 2.x
[21:24:42] <faassen> or perhpas am ore politically feasible 3.x which adds a from __past__ to help stragglers?
[21:24:56] <faassen> mitsuhiko: you're talking about what you need today.. but where do you want the python community to be in 5 years?
[21:25:07] <mitsuhiko> faassen: i can tell you what i want: encode/decode on strings and bytes back, updates to the interactive shell to debug print generators, removal of dictkeys etc.
[21:25:12] <faassen> mitsuhiko: I mean, I realize we don't have to care. we're not responsible. but sincew e're talking.
[21:25:16] <cwillu_borken> mitsuhiko, well, the point is to bring 2.x closer to 3.x; ideally close enough that an actual migration becomes as easy (not "as trivial") as a migration from 2.6 to 2.7, sauy
[21:26:19] <faassen> mitsuhiko: you have a kind of interesting position in that you actually *prefer* python 2.x features. I haven't got enough experience with python 3 to have developed much of an opinion yet (though the generator keys always struck me as a bit tricky)
[21:26:37] <tos9> "debugging" print generators seems like a thing that probably is solvable with a displayhook
[21:26:59] <cwillu_borken> debug aids that don't work as easily with logging messages are not worth talking about
[21:27:10] <faassen> sinistersnare: I think there were, though as far as I understand it seems to be okay now, performance wise. I haven't done any measurements myself. :)
[21:27:40] <tos9> what I want from py3 is someone actually having given sincere looks at all of the APIs and properly decided what types of input each thing takes
[21:27:47] <mitsuhiko> performance vise python 3 is just vastly different than python 2. hard to compare
[21:27:54] <tos9> because everytime I use some stdlib thing in py3, I run into things with questionable input types
[21:28:16] <tos9> which are now likely locked in due to "backwards compat" for things people aren't using really yet.
[21:28:30] <mitsuhiko> the whole using of os environ variables to get charsets and fs encoding defaults has bitten me so many times
[21:28:37] <tos9> so what's going to end up happening is people writing broader APIs for things to fix these mistakes
[21:28:51] <tos9> (Also the docs are beyond horrible at telling you which types things take in some places)
[21:28:52] <faassen> mitsuhiko: yeah, getting the os information to decide default encodings sounds scarily non portable to me..
[21:29:33] <mitsuhiko> to reproduce that: have a mac set to de_DE and ssh into a server that only has en_US
[21:29:43] <faassen> mitsuhiko: tos9 do you think the issues you talk about are resolvable enough to make Python 3.x tolerable enough to switch?
[21:29:47] <mitsuhiko> your negotiated locale is "C" after which python thinks everything is ascii only
[21:31:03] <tos9> faassen: I don't think it's inconceivable for me to get to a point where I can switch -- I guess that's the most conservative thing I can say
[21:31:14] <faassen> mitsuhiko: yeah. :) I mean, I think all this would be valuable feedback for the python 3 devs. they're not going to agree on everything but hopefully something will improve.
[21:31:49] <mitsuhiko> i'm assuming that my experience is the exception and most people are fine with python 3 and not as picky
[21:32:09] <faassen> what I'm concerned about is getting projects that are largely invisible to the community as they're not open source, often in-house, often massive, to move somewhere.
[21:32:26] <faassen> there's a much larger distance between those projects and what's going on in Python interpreter land than for the typical folks here.
[21:32:27] <tos9> stevezzz: The parts of the stdlib in py3 that I dislike will probably end up being replaced by better third party libraries
[21:32:49] <tos9> But those don't exist yet, because developers I "trust" don't really use py3 much yet.
[21:33:16] <faassen> tos9: I can see how putting functionality in the stdlib can help with idioms, but it's nicer when it's been battletested *before* it's put in.
[21:33:18] <mitsuhiko> just that the python 3 stdlib is in a considerably worse state because people ported the libraries that did not write it originally :(
[21:33:48] <faassen> mitsuhiko: many of those libs had likely "died" in the python 2 library already, it's just they worked there. :)
[21:34:13] <faassen> yeah, of course, as the language kept compatibility with when they were written. :_)
[21:35:13] <faassen> Alex_Gaynor: what are your thoughts about moving things forward? you were the one who set things off this time with your blog entry. :)
[21:36:04] <Alex_Gaynor> I don't really have opinions about python 3 the software, my only concern is for the community side, I don't think having two python languages is a healthy thing.
[21:37:09] <faassen> Alex_Gaynor: I'm trying to get mitsuhiko and tos9 to talk about it, but I need help. :)
[21:37:54] <tos9> I'm just here to see if anyone's got better solutions than I do, since I don't really have any good ones at the moment :)
[21:38:29] <cwillu_borken> I don't think it has to be entirely effortless, but certainly it needs to be easier than it currently is
[21:39:36] <cwillu_borken> I hate to think what it would look like if you have a project using old-style classes and crap
[21:40:03] <faassen> cwillu_borken: it'd be interesting to make a list of what that might mean. might not cover 100% of everything (I found 'type' takes str but not unicode in python 2 and only unicode str in python 3.. fix that? probably not)
[21:40:16] <faassen> cwillu_borken: but get it enough to support 99.9% percent of code might be possible.
[21:40:57] <mitsuhiko> faassen: that's actually a good point. for instance unicode_literals breaks pydoc because docstrings become unicode
[21:41:17] <cwillu_borken> if it got some cleanup, then adding some carefully contained hacks triggered by the import wouldn't seem too terrible
[21:42:02] <cwillu_borken> (especially if they're known to only be sticking around for 2 or 3 releases before removal)
[21:43:20] <tos9> mitsuhiko: I don't know what this is -- I mean I see, but I've never heard of it. Should I have?
[21:43:39] <mitsuhiko> it's this thing which is making the rounds as replacement for six currently: http://python-future.org/
[21:53:46] <faassen> tos9: the interesting thing it does it bring the bytes and str type into python 2, optionally. and it only supports 2.7 and 3.3 making porting cleaner.
[21:54:02] <faassen> tos9: I think it's an interesting model of what python 2.8 might look like. or even what __past__ features in a python 3.x might look like.
[22:09:24] <faassen> cwillu_borken: care to think about a feature list of what could be in __past__ in a hypothetical Python 3+PAST?
[22:13:49] <faassen> ionelmc: some of them weren't mistakes, I doubt Guido was thinking a lot about generators back in the early 90s. :)
[22:16:53] <cwillu_borken> faassen, "and what if the antigravity fails?" 'I thought about that.' "...and?" 'And we'll all pluuuunge to our deaths! See? I thought about it!'
[22:31:23] <zzzeek> hey I'm sitting pressing "reload" on the web log and nothings happening, out of gas already ?
[22:32:54] <faassen> pjenvey: well, that's also point of this channel. If there was a channel and people could talk about Python 2.8 and then nothing happened.
[22:33:19] <mitsuhiko> zzzeek: not to warm up this discussion again: but what exactly do you want me to do?
[22:34:20] <zzzeek> mitsuhiko: i just have trouble reading through those really long posts of yours so i thought maybe if i just saw basic code that breaks on py3k that would just be a more succinct place to look for the issue, and also would be more suggestive of potential solutions
[22:35:04] <mitsuhiko> zzzeek: i have all my stuff i care about working on python 3 but i don't enjoy using python 3
[22:35:42] <mitsuhiko> and considering that the adoption numbers are really low i doubt that i'm the only one feeling that way
[22:35:56] <mitsuhiko> i talked to quite a few people the last month and the general attitude is very similar
[22:36:15] <pjenvey> are you actually using it, besides for maintaining a 2.x and 3.x compat lib? because that's definitely not an enjoyable experience
[22:36:28] <zzzeek> faassen: see, scombinator seems like another example of what I'm talking about :)
[22:37:59] <mitsuhiko> and i use the interactive shell a lot and tried switching that over to python 3 for my daily tasks
[22:39:40] <faassen> pjenvey: saves you enormous amounts of wear on the period key over the years. :)
[22:42:30] <mitsuhiko> while i would love to take credit for python 3 not being adopted, i don't think i have that much influence on people
[22:42:31] <pmxbot> !8ball (8) !acronym (ac) !anchorman !annoy (a, bother) !bender (bend) !bitchingisuseless (qbiu) !blame !bless !boo !bottom10 (bottom) !calc !chain !cheer (c) !c
[22:42:31] <pmxbot> ompliment (surreal) !config !ctlaltdel (controlaltdelete, controlaltdelete, cad, restart, quit) !curse !dance (d) !deal !define (def) !demotivate (dm) !disembow
[22:42:32] <pmxbot> el (dis, eviscerate) !duck (ducky) !embowel (reembowel) !emergencycompliment (ec, emercomp) !excuse (e) !featurecreep (fc) !fight !flip !fml !gettowork (gtw) !g
[22:42:32] <pmxbot> olfclap (clap) !google (g) !grail !haiku !hal (2001) !hangover !help (h) !hire !imotivate (im, ironicmotivate) !insult !job (card) !karma (k) !keelhaul (kh) !kl
[22:42:32] <pmxbot> ingon (klingonism) !log !logo !logs !lunch (lunchpick, lunchpicker) !meaculpa (apology, apologize) !motivate (m, appreciate, thanks, thank, gracias) !murphy (la
[22:42:33] <pmxbot> w) !nailedit (nail, n) !nastygram (nerf, passive, bcc) !norris () !notify !oregontrail (otrail) !panic (pc) !password (pw, passwd) !paste !pick (p, p:, pick:) !
[22:42:33] <pmxbot> progress !quote (q) !r (r) !resolv !roll !rubberstamp (approve) !saysomething !send_text !simpsons (simp) !stab (shank, shiv) !storytime (story) !strategy !stri
[22:42:33] <pmxbot> ke !tgif !therethere (poor, comfort) !ticker (t) !time !tinytear (tt, tear, cry) !top10 (top) !troutslap (slap, ts) !urbandict (urb, ud, urbandictionary, urband
[22:42:33] <pmxbot> efine, urbandef, urbdef) !version (v, e, r) !weather (w) !where (last, seen, lastseen) !wolframalpha (wa) !zinger (zing) !zoidberg (zoid)
[22:42:48] <faassen> I think we should start from the position that Python 3 is here and there to say, and Python 2 is still very present.
[22:43:20] <zzzeek> mitsuhiko: PSF makes a big announcement, "we fucked up", all the features are going into 2.8
[22:44:19] <mitsuhiko> but to be honest: i don't think i have seriously said to anyone to kill python 3
[22:44:23] <zzzeek> stevezzz: he just said, "it has not been until fairly recently", "it" being, "kill python 3, forget it"
[22:45:00] <mitsuhiko> zzzeek: my actual position is that the roof is on fire and we need to do something
[22:45:28] <zzzeek> mitsuhiko: i don't know anyone pretending everything is alright but i don't read python-dev lists all day
[22:45:42] <mitsuhiko> we all have a significant part of our life invested into python and having the community commit harakiri or splitting into two is not good
[22:45:44] <faassen> yeah, I share that position with mitsuhiko, though I express myself differently. a bit of pushback is valuable in any case.
[22:46:33] <faassen> zzzeek: when python 3 was 5 years old I heard a lot of "everything is going exactly according to plan which we made 5 years ago", which at the very least ignored the reality of the plan already having changed.
[22:46:40] <zzzeek> stevezzz: those using 2.6 and those using 2.7, also a split, those using unix and those using windows
[22:46:46] <mitsuhiko> tos9: i don't think i could do it. i would be too extreme about what i would want to do :)
[22:46:48] <tos9> mitsuhiko: Or, to be a bit more leading, "do you tend to stay away from making contributions from CPython for any reasons"
[22:46:50] <faassen> zzzeek: now we're getting a bit of pushback. I think both positions don't quite reflect reality.
[22:47:12] <mitsuhiko> i enjoy development and i would love to work on cpython. i am not a person that can discuss on mailinglists
[22:48:17] <zzzeek> faassen: everyone has problems with how things were done. i have major issues with how the porting story was described, and then i said as much at the py3k roundtable like 2 or 3 years ago and guido was like, "no, i disagree, there should be many different ways to port to python 3"
[22:48:54] <zzzeek> and i thought, hey well i sure like to be able to be unilateral with sqlalchemy, so ill let the BDFL have that one :)
[22:50:48] <faassen> zzzeek: yeah, people tend to reinterpret the past according to the narratives that work best today.
[22:52:01] <Vq> I've never actually tried to target 2 and 3 simultaneously, would syntactical compatibility modes in 2 _and_ 3 make things less painful for library devs?
[22:52:35] <tos9> mitsuhiko: I want to see *some* people in "this" camp become more active with CPython
[22:52:51] <zzzeek> mitsuhiko: id like to identify specific programming patterns that you don't like, and fix them
[22:52:54] <tos9> mitsuhiko: Unfortunately given the pains I think people seem to have occasionally with CPython, that is difficult.
[22:53:02] <eevee> i don't think adding metaclass kwarg syntax to 2.x would lure people to stick with 2.x, but it would sure make cross-version code easier
[22:53:53] <mitsuhiko> eevee: well, the lack of syntax does not make it impossible to write metaclasses that work for both
[22:54:03] <tos9> mitsuhiko: Sure, I don't think anything useful can happen in the very near future unfortunately
[22:54:29] <mitsuhiko> faassen: it's an ungodly hack though. they used the version i wrote for jinja2
[22:54:39] <scombinator> I'd prefer not to have to go in to carefully written maths and figure out how to change it to 3.x, and hope that some corner case didn't get missed
[22:54:50] <mitsuhiko> just for the record: i think an improved python 3 is probably a much better idea than a python 2.8
[22:54:53] <faassen> mitsuhiko: heh, I'm stunned ungodly hacks are needed in the metaclass context. :)
[22:55:14] <faassen> mitsuhiko: do you think it could be improved to help portability for those on a python 2 codebase, i.e. the community split issue?
[22:55:46] <mitsuhiko> eevee: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ <- code is on there
[22:57:10] <zzzeek> mitsuhiko: i heard that someone said he was abandoning py3k due to your post but i can't find any evidence for such a post
[22:57:34] <mitsuhiko> zzzeek: if someone really abandons python 3 because of a post i wrote then that person was already doing it before
[22:57:45] <faassen> well, if people are going to be swayed by a few blog posts, then I think those bloggers should just pat themselves on the back for their amazing power to convince and move on. :)
[22:58:18] <cwillu_borken> I think the "threat" of a 2.8 might be needed to actually get significant changes to 3 though. As long as the mindset is "3 is so great, even with its warts why would you want to use 2?", it's hard to see anyone bending over backwards to reintegrate the community :/
[22:58:22] <mitsuhiko> zzzeek: i agree, and i'm not particularly happy with some of the language in that post
[22:59:47] <faassen> cwillu_borken: a bit of pushback is good, but if it's just people on an irc channel ranting it's very easy for people to say, see, those people are just full of hot air, and they'd be right.
[23:00:20] <faassen> we need to identify what we think should happen first, and then get as concrete about it was we can with the resources we have.
[23:01:08] <faassen> maybe this is just ranting and hot air and there is no problem and everything is going according to plan. :)
[23:01:17] <scombinator> faassen: I'm fairly certain the people wanting a 2.8 won't have the energy to devote to actually developing a fork, because those are the people who almost by definition have other things to do (i.e. their 2.7 code bases) It'd be easier to shift to a more palatable language (should it exist)
[23:02:25] <faassen> iElectric: I take a more systemic position towards these problems than many, I think.
[23:02:42] <tos9> scombinator: 2.8 to me means "there are some quite useful things that we want to apply to the py2.7 branch" -- the stupid SSL thing that was posted to HN is a good example (of a dumb HN post but of a thing people would probably want to backport)
[23:03:01] <faassen> but what if your problem is that your code is on Python 2.7? and you need to convince your boss to port, and your arguments: well the language is better, there are less warts!
[23:03:26] <tos9> scombinator: It's lots of small things that probably don't take too much effort individually. The actual effort isn't in the coding most likely, it's in inertia.
[23:04:29] <mitsuhiko> from that i gather the general opinion is that python 3 is not adopted because it's inertia?
[23:04:35] <scombinator> faassen: Does anyone in the scientific community actually need to convince their boss to use python 3? or themselves?
[23:05:13] <zzzeek> e.g. inertia, as well as yes what if we hit a lib that's not ported. i have that anxiety about crufty old libs i need like m2crypto and suds
[23:05:16] <mitsuhiko> The reason we're not using python 3 at the company is pretty much exactly what Alex_Gaynor said btw
[23:05:49] <_habnabit> i can certainly imagine companies with large enough codebases that they wouldn't want to audit all of their code ever
[23:07:06] <Alex_Gaynor> my last company had a few houndred thousand lines of code, and maybe 20 developers working on the backend (estimate), there was no way I was going to spend more than a day or two on porting
[23:07:46] <faassen> Alex_Gaynor: there was no way.. because you didn't want to, or because your bosses won't let you?
[23:08:08] <Alex_Gaynor> faassen: Because I would never ask my boss about it, I had real work to do.
[23:08:47] <cwillu_borken> maybe part of the answer is for all of us to go to our bosses and gets some funding together to hack this
[23:08:48] <tos9> I promised to send performance data, but you know how it goes... Work to do instead.
[23:09:05] <faassen> Alex_Gaynor: what do you think about a from __past__ on Python 3, where you can bring Python 3 up to 99+% compatibility on a per-module level?
[23:09:17] <faassen> Alex_Gaynor: i.e. an incremental upgrade progress, whether it be 2.8 or the 3.PAST described just now.
[23:09:39] <scombinator> huh, python 3 interpreter doesn't seem to have history... what would cause that?
[23:09:41] <faassen> cwillu_borken: yeah, I think there might be a business case for a Python 2.8. but I don't have a boss. :)
[23:09:52] <iElectric> is there in history of CS (limited to open source communities) been such a case? bbb broken in core language?
[23:09:57] <faassen> cwillu_borken: and I don't have the time to hack this. I already feel crazy for spending my time on creating the irc channel.
[23:10:10] <faassen> cwillu_borken: but I figure I'd contribute something a trifle more constructive if I could.
[23:13:20] <mitsuhiko> which might be good, because we might actually see people writing good stdlib replacements that work on both
[23:13:27] <faassen> anyway, okay, there seems to be at least some consensus that people are stuck on python 2 and find it hard to motivate porting code.
[23:13:57] <tos9> The problem is that the former has pretty much 0 contributors, and the latter has very few
[23:14:13] <faassen> would it be hard to motivate porting code if we lived in a magical world where all dependencies were ported to Python 3?
[23:14:28] <scombinator> I was wondering if it was possible to donate to pypy to prevent py3 development
[23:14:31] <faassen> I mean, Alex_Gaynor describes a scenario where that would still be difficult to motivate, right?
[23:14:56] <tos9> faassen: I certainly don't think everyone would switch immediately -- but people certainly aren't switching otherwise.
[23:14:58] <eevee> i suspect most of our problems are just with our own codebase, since it's ancient and we invented a lot of our own wheels
[23:14:58] <scombinator> mitsuhiko: I don't *want* to help, because I'm not going to get what I want out of python3
[23:15:38] <faassen> tos9: I'm trying to identify what we could suggest could be done to make things easier, *besides* the dependency situation.
[23:15:59] <eevee> _habnabit: good news, we have embedded placeholders all over the place so oursql isn't drop-in :(
[23:16:02] <mitsuhiko> i still think that for lots of people the unicode changs are just frustrating
[23:16:32] <faassen> mitsuhiko: I think many people have done less with Python 3 than you have. you've used it in anger, clearly. :)
[23:16:43] <_habnabit> mitsuhiko, the most frustrating part seems to be that the stdlib is wildly inconsistent about which type it wants or emits
[23:16:50] <eevee> mitsuhiko: actually we're kinda frustrated about the unicode problems we keep bumping into that 2 has made invisible
[23:17:25] <faassen> so is there something that could be done to the Python 2.x line of Python or the Python 3.x line of Python to help make things better?
[23:17:52] <mitsuhiko> iElectric: i filed a bug against it so that they stop using unicode_literals :P
[23:18:28] <faassen> iElectric: I played with it a bit today, in a library which had almost no dependencies of my own (Reg, reg.readthedocs.org)
[23:19:06] <faassen> anyway, that was one of my ideas, take python-future as a source of ideas, and add them to a Python 2.8 that helps with incremental porting of the unicode issue.
[23:19:54] <eevee> but yeah if the 2.x stdlib were more unicode-consistent so it were actually possible to have 'undefined' as the default codec...
[23:19:54] <faassen> the idea cwillu_borken brought up is kind of the inverse.. add from __past__ to Python 3 that brings back some python 2 behaviors, again so it's easier to port python 2.x codebases incrementally to Python 3 (as you can slap in from __past__ import * and then fix things incrementally, say)
[23:20:40] <faassen> eevee: okay, that's an idea for a Python 2.x, then, modify lib to be more unicode inconsistent. risks divergence with py 3 lib, though?
[23:21:09] <faassen> politically changing python 3 might be easier to accomplish. but practically python 2.8 would be easier to accomplish.
[23:21:16] <cwillu_borken> mitsuhiko, I suspect that it would involve re-implementing some old behaviours, but ideally in a manner that's a bit more isolated than just copy/pasting some old code into the interpreter
[23:21:38] <mitsuhiko> cwillu_borken: some of them are almost impossible to implement. like a string type that emulates the old one
[23:21:52] <tos9> Encouraging the use of a good path library implementation that's cross-version compatible seems like a decent minor thing to me.
[23:22:00] <faassen> mitsuhiko: you could do from __past__ import dict and get the old dict. I imagine *some* code that expects keys generators might break, but that'd be pretty rare.
[23:22:19] <eevee> also so far __future__ has been syntactic changes. __past__ sounds like it would change *values*, which does not jive with the stated goal of "port one module at a time"
[23:22:25] <mitsuhiko> faassen: so the dict implementation should look at the current frame to see if it has the old or new behavior?
[23:22:33] <eevee> what if you have a module with `from __past__ import dict` but then other code passes in a new dict
[23:22:39] <faassen> mitsuhiko: why would a string type that emulates the old one be hard to implement? because of compatibility with new code or other reasons?
[23:22:58] <mitsuhiko> faassen: you're not proposing a new (old) type but a type that changes behavior in a different module
[23:22:58] <faassen> mitsuhiko: no, I'd say it would just pass as an old style dict into new code. new code will get lists, but those are generators.
[23:23:23] <cwillu_borken> keep in mind though that the point isn't to add something permanently to py3
[23:23:24] <faassen> mitsuhiko: what sounds like a bad idea? magic type or passing back into old code? :)
[23:23:39] <cwillu_borken> __past__ would be added for 3.5 (say), deprecated in 3.6, and removed again in 3.7
[23:23:40] <eevee> both old and new code would have to handle both old and new values which is... exactly where we are now
[23:23:58] <faassen> mitsuhiko: well, for dict it would be doable, as old dict is compatible with new dict interface. for other things it might not work.
[23:24:04] <scombinator> iElectric: Suppose your new projects might need to interoperate, or even use code from your old ones
[23:24:15] <cwillu_borken> iElectric, I have projects that have migrated from 2.3 through the years up to 2.7
[23:24:33] <tos9> Except that for new code, you can't *just* support Py3, there isn't enough users and you yourself are probably using py2, so it's just "for new code make it py2/3"
[23:25:00] <cwillu_borken> changes to match best practices and common idioms happened _after_ the migration, not as a prerequisite to the migration
[23:25:13] <iElectric> I understand that porting is a blocker - maybe some freelancers would do that work as smaller payment
[23:25:16] <faassen> yeah, even a very mild migration path multiplied by a LOT of code down the gravity well creates a lot of inertia.
[23:25:57] <eevee> there is no problem in computer science that cannot be solved by an army of interns
[23:26:20] <_habnabit> 23:21:47 < _habnabit> iElectric, also python 3 doesn't have an async HTTP client worth using
[23:26:41] <faassen> iElectric: do we want two communities? would we have two communities? are we stuck with polyglot forever? such questions are interesting.
[23:27:21] <faassen> iElectric: heh. polyglot was considered total bullshit will never happen when py3 started.
[23:27:34] <faassen> iElectric: do we want two communities. Answer: no, handwave that we won't get any.
[23:28:07] <cwillu_borken> faassen, well, beat dissenters over the head with trademark law to ensure that a second community doesn't form :p
[23:28:08] <eevee> scombinator: it's notable because it still hasn't quite stabilized (though it's close)
[23:29:11] <cwillu_borken> eevee, re: dict, I feel like that might be one of the less necessary changes, but... that's based on my own codebase which obviously isn't a great sample
[23:29:39] <faassen> cwillu_borken: forget about trademarks. right now I don't detect much in the way of consensus about ways forward at all.
[23:29:44] <cwillu_borken> eevee, i.e., my needs re: dicts would be largely satisfied if .keys() had a useful repr
[23:30:47] <faassen> anyway, I'm going to bail out of this channel for today. thanks for the chat, I'll be back tomorrow I imagine. :)
[23:30:59] <faassen> if people can come up with some useful ideas, I'd be curious to hear about them!
[23:31:06] <cwillu_borken> marcini, in an interpreter shell, it's just random noise characters I have to type
[23:31:30] <tos9> cwillu_borken: 16:24:21 <tos9> "debugging" print generators seems like a thing that probably is solvable with a displayhook
[23:31:59] <tos9> cwillu_borken: It's a shell thing, sorry, thought that's where you were bothered by them.
[23:32:09] <faassen> iElectric: I think he knows I got them, but I didn't show him. Anyway, morepath's directive thing is totally different than pyramids.
[23:33:01] <tos9> Pretty much, yeah :). My point I guess is "that doesn't really bother me that much", so I guess I'm not solving your problem really./
[23:34:21] <stevezzz> stackless 2.8 is a 2.7+ which is already in progress. idea: help out with that.
[23:34:48] <marcini> mitshuhiko, some concrete ideas can be seen on the wikiwikiweb, page PythonThreeThousand
[23:35:42] <cwillu_borken> (as mentioned previously: from __past__ import print_statement is a _political_ solution, that is clearly the more difficult practical solution)
[23:35:59] <tos9> cwillu_borken: I don't take anyone seriously who says that the print statement is a thing they miss.
[23:36:19] <stevezzz> faassen: impractical to just go to 3.x like some people magically think people should
[23:36:32] <stevezzz> faassen: or a lack of interest in 3.x at this time for lack of compelling reason
[23:36:57] <faassen> stevezzz: so it's primarily motived by the 2.8 nature more than the stackless nature, or both?
[23:37:02] <scombinator> It's easier to revaluate alternative languages, since no porting is going to happen anyway
[23:37:03] <tos9> cwillu_borken: Do you really :/ -- will you kill me if I say that I think that really should be a feature of your interpreter?
[23:37:27] <faassen> stevezzz: I'd be curious to hear more how to help with stackless 2.8. given that it's in a private repo.
[23:37:43] <faassen> stevezzz: is there interest in putting some stuff like the 'future' module in it?
[23:38:06] <cwillu_borken> tos9, for the most part, I feel that anything typed into a shell window should also work typed into a file and piped into the same interpreter as provided the shell
[23:38:43] <scombinator> tos9: what's helpful for one is helpful for the other, print() is just fugly
[23:38:46] <faassen> stevezzz: i.e. not just backporting yield from, but also being able to import new str and bytes like in the future module?
[23:38:51] <cwillu_borken> that said, I don't consider this to be the biggest point of contention :p
[23:39:01] <stevezzz> stevezzz: at this stage, if i backported nonlocal to it, it would be "from __future__ import nonlocal" in stackless 2.8, and put in properly in stackkless 2.9
[23:39:17] <scombinator> cwillu_borken: The biggest point of contention is all the little points of contention
[23:39:56] <faassen> mitsuhiko: we could smile sweetly at the Python 3 developers and ask for a nonlocal?
[23:40:15] <scombinator> I'm not sure unicode is the problem, it's the now shitty support for binary byte arrays
[23:40:44] <mitsuhiko> the removal of encode/decode on strings and bytes fulfills no practical problem
[23:40:45] <stevezzz> you're asking questions i can't answer. the 3.x incorporations happen according to there being people with an interest and a need
[23:41:06] <marcini> mitsuhiko, yes, like "everything is an object", yet i think those dreams were misguided
[23:41:07] <dash> seems to me that a python 2.8 that contained all the non-breaking changes of python 3 (nonlocal, chained exceptions, etc) would be a good first step
[23:41:17] <faassen> stevezzz: could you get back to those people and ask about mitsuhiko's __future__ question? and my bytes/text question? :)
[23:41:55] <faassen> stevezzz: well, if anything this channel has managed to give stackless 2.8 a tiny bit of useful feedback.
[23:42:25] <stevezzz> faassen: the answer is that it's up to people with a vested interst, and no-one on the stackless mailing list has expressed personal interest in supporting these specific things
[23:42:29] <scombinator> 1/1 = 1.0 is a horrible wart, not abstract theoretical dreams. 1/1 = 1 fits the numerical tower. You don't see 1/1 = 1j, just because that's the most general. The only argument for it is that y/float(x) seems to happen a lot, because people misuse integers as floats, or they need the conversion, but would like it done implicitly.