pmxbot IRC Log Viewer

[00:54:31] <cjwelborn> wangofett: Bytes Are Decoded, Text Is Encoded (BADTIE). I made that up all by myself.

[00:56:59] <dash> cjwelborn: win

[03:22:55] <wangofett> Nice, cjwelborn

[04:08:23] <wangofett> cjwelborn: that's pretty fantastic - I'm trying to implement the reactor pattern in Python(3) and BADTIE has been useful already :D

[04:09:00] <wangofett> so what's awesome is that most of the people I follow on twitter are in here, heh

[04:17:34] <cjwelborn> glad i could help :)

[07:37:39] <Theuni2> good

[07:37:40] <Theuni2> morning

[08:01:16] <ztane> itamar: no I didnt know

[08:53:13] <mitsuhiko> jezdez: inconclusive discussions

[08:53:20] <mitsuhiko> jezdez: there are logs in the topic in case you want them

[12:31:48] <jezdez> mitsuhiko: thanks, I really hope we find some way out of the issues, would hate python being not considered due to that

[14:14:08] <VictorLin> +1 on python2.8

[15:22:20] <mitsuhiko> jezdez: what would be your input?

[15:23:27] <jezdez> mitsuhiko: I haven't given it much thought tbh, so I'd rather make a comment at the moment

[15:23:33] <jezdez> err, *not*

[15:23:35] <jezdez> :)

[15:23:43] <mitsuhiko> fair enough :)

[16:14:56] <VictorLin> http://victorlin.me/posts/2014/01/10/slow-down-its-faster-lets-build-python2-8

[17:04:59] <jnoller> VictorLin: Who would build and maintain a python 2.8, 2.9, 2.10 etc? Is your expectation that Python-Core should maintain Python 2.8+ and 3.3+?

[17:06:28] <aspofdestiny> that's a tall order

[17:08:55] <wangofett> And reminds me of the Aesop's Fable involving something about pleasing everyone ;)

[17:09:41] <wangofett> That being said... in order to be a language that's used... well, people need to use it! heh

[17:10:32] <aspofdestiny> is there any adoption of 3.x resulting from Django compatibility?

[17:11:10] <mitsuhiko> aspofdestiny: there probably is a little bit

[17:11:33] <mitsuhiko> but the numbers overall are so low that it would be hard to measure

[17:11:44] <aspofdestiny> true

[17:11:59] <wangofett> Heh... I know if anything the fact that Django is now 3.x compatible that has given me more inclination to try and pick Django up again...

[17:12:17] <aspofdestiny> dumb question perhaps: is Dropbox using much Python3?

[17:12:25] <mitsuhiko> aspofdestiny: doubt it

[17:12:37] <mitsuhiko> the client is python 27

[17:13:17] <mitsuhiko> maybe they are using python 3 on the server but that would mean that they have two different versions of python in use which probably makes code sharing harder

[17:13:22] <wangofett> Flask (mainly Werkzeug, really) Python3 support was actually one of the packages that allowed me to switch

[17:13:25] <aspofdestiny> ah, interesting. and a bit sad!

[17:13:47] <wangofett> That would be really interesting to know

[17:13:56] <aspofdestiny> i run a flask app but need a bunch of other packages including Fabric

[17:14:01] <aspofdestiny> so we have some inertia

[17:20:58] <_Turbo_> would it make sense to emphasize the 2/3 compatibility in PyPI a bit more?

[17:21:21] <_Turbo_> and possibly publish a list of not-yet-3-compatible libs that are downloaded often

[17:22:16] <tomprince> There is such a thing, I think.

[17:22:17] <wangofett> Give priority to Python3 packages? Or would that make it too much like the terrible SourceForge interface?

[17:24:07] <tos9> You can look up packages that don't have the Py3 classifier

[17:24:13] <tos9> And there's the "Wall of Superpowers"

[17:24:40] <tos9> I don't think I see value in doing anything more than that personally, I don't think there's a significant marketing problem

[17:26:09] <_Turbo_> wasn't aware of that wall of superpowers, but it looks like what I meant, thanks

[17:26:46] <wangofett> WoS is pretty awesome

[17:26:54] <wangofett> I remember when it was Wall of Shame ;)

[17:29:13] <dstufft> Remember that usage numbers don't tell the whole story wrt Python3, You're not going to see widespread adoption until a critical mass has been hit wrt libraries supporting python3 (IMO at least)

[17:29:23] <dstufft> Also I have no idea what "Give priority to python3 packages" means

[17:30:21] <wangofett> dstufft: basically deemphasize the downloads/versions that only support Python2

[17:32:29] <dstufft> You're going to have a hard time getting PyPI to do anything that makes python2 a second class citizen

[17:32:48] <aspofdestiny> the question here is whether a 2.8 would solve all of these problems suddenly and magically

[17:33:01] <dstufft> aspofdestiny: my guess is no :)

[17:33:05] <wangofett> I'm doubting that

[17:33:14] <wangofett> there are still places that use Python 1.4 ;)

[17:33:31] <wangofett> Much less common

[17:33:36] <wangofett> but still exist

[17:33:38] <Theuni2> that's probably the ISS, right?

[17:33:59] <aspofdestiny> i tend to agree but in the grand scheme it is in everyone's interest to leave 2.x behind

[17:34:08] <tomprince> Why?

[17:34:32] <wangofett> lol. I'm not sure - someone on either the Python tutor or Python mailing list apparently works somewhere that exists

[17:34:38] <aspofdestiny> it is getting kind of dire- if python core is working on 3.x and the future, but practical users are stuck on 2.x in it's death throes..

[17:34:39] <wangofett> tomprince: same reason to leave 1.x

[17:35:04] <Theuni2> how painful was that?

[17:35:20] <wangofett> Death throes is a bit severe - it still works, and will continue to work

[17:35:26] <tomprince> I wasn't arround for that, but my understanding is that that was mostly a smooth upgrade.

[17:35:28] <wangofett> python 2 isn't ever going to magically stop working

[17:35:37] <Theuni2> i just remember that I joined Python were 2 was just around a corner and I was a kid and didn't mind dropping the few lines of 1 that I coded.

[17:35:39] <wangofett> mainly because of the backwards compatibility

[17:35:43] <tomprince> Similiar to 2.x -> 2.(x+1)

[17:36:01] <wangofett> I don't think they really dropped any/if that much 1->2

[17:36:11] <jnoller> aspofdestiny: practical users will always be stuck on old versions. When JDK 1.7 came out I was still stuck writing JDK 1.5 code

[17:36:13] <wangofett> but 2->3 has been a *huge* housecleaning

[17:36:31] <jnoller> aspofdestiny: Enterprises and working applications gonna just... work

[17:37:07] <wangofett> jnoller: my experience is that the value of 'work' varies across the spectrum

[17:37:13] <Theuni2> What holds me back most is that I need a smooth transition with an existing code base - and the issue of getting a weird intermediate language that is just not very likeable (because it isn't Pythonic by serving two masters) - that just makes everyone who already has full plates sigh.

[17:37:32] <wangofett> honestly, I'm surprised that society functions at all, considering the massive quantity of horrid code that I know exists out there

[17:37:45] <Theuni2> for known values of "functions" :)

[17:38:03] <wangofett> (where horrid means tested only by end users, and randomly blows up for people in weird edge cases)

[17:38:07] <jnoller> Theuni2: Ok, define what a smooth transition would be *for you*

[17:38:17] <dstufft> 2.6+ and 3.3+ compat python isn't that bad

[17:38:37] <dstufft> porting and existing codebase depends largely on how big it is and how it was written

[17:38:44] <dstufft> but greenfield? it's not all that hard

[17:38:45] <Theuni2> jnoller: if i could keep using parts of my toolchain in *both* worlds and not having to create a "from scratch" environment anew that doesn't work with many things i'm used to.

[17:39:02] <wangofett> and who's willing to pay for that improvement

[17:39:19] <Theuni2> jnoller: there are a few examples where the complexity rises because of dealing with the ability of code to run in both worlds (tools and libraries) and then tend to not work in all the cases that one would expect.

[17:39:28] <aspofdestiny> jnoller: certainly true for big/slow enterprises. i'm really referring to more agile cos and startups who are oss contributors and on the bleeding edge

[17:39:31] <Theuni2> jnoller: an example is the unicode thing with open() in setup.pys

[17:40:16] <dstufft> that's mostly because distutils is a giant pile of shit

[17:40:26] <dstufft> and setuptools adds a hat ontop of that shit and calls it a puppy

[17:40:26] <dstufft> :D

[17:40:33] <Theuni2> jnoller: another example is zest.releaser which is a python utility to create releases which tends to run your code, so if i make a Python 3 package, suddenly zest.releaser needs to be able to run all Python versions that I may bake a release of (related distutils shit thing)

[17:40:38] <Theuni2> yup

[17:40:46] <Theuni2> and i helped putting buildout on top of that

[17:40:52] <Theuni2> and called it a pony

[17:41:21] <Theuni2> i do use Python 3 in isolated setups here and there just to get a feeling

[17:41:40] <jnoller> My point is this: rather than say "2.8!" which is a strategy - define specific tactical things that could be done to smooth over your transition. Is it a new setup tools fixing a bug?

[17:41:59] <dstufft> ^^

[17:41:59] <Theuni2> then i stumble over something that worked before (because obviously there will be bugs and that's to expected) like PDB crashing with unicode issues (which is kinda entertaining)

[17:42:09] <aspofdestiny> jnoller: does the PSF have a position on this topic?

[17:42:20] <Theuni2> jnoller: i understand that question and i feel unable to answer it appropriately :(

[17:42:30] <jnoller> aspofdestiny: The PSF does not dictate to python-core what to do

[17:42:44] <Theuni2> jnoller: mainly because i can only find the things that stop me by fixing them one after one (as they tend to hide beneath each other)

[17:42:51] <jnoller> aspofdestiny: We do fund, happily, libraries and frameworks to get dual codebase/python 3 ported though

[17:43:09] <aspofdestiny> jnoller: I mean a collective opinion as community representatives, not a mandate to python core

[17:43:37] <jnoller> aspofdestiny: We've funded or helped fund porting libs to Python 3 quite a bit

[17:43:43] <aspofdestiny> point is: some part (most?) of the community believes this to be a problem of increasing severity

[17:44:05] <aspofdestiny> jnoller: i see. did not know that!

[17:44:26] <jnoller> aspofdestiny: I can only speak to those I know well, not the entire PSF/board

[17:44:34] <jnoller> aspofdestiny: but essentially it's time/money

[17:45:00] <aspofdestiny> understood

[17:45:11] <jnoller> aspofdestiny: and we haven't hit a sudden apocalypse. 2.x continues to work, 3.3/3.4 are amazing improvements - so, fund, support

[17:45:55] <wangofett> I think we have a few people spouting FUD

[17:45:58] <jnoller> This idea we hit a "5 year time bomb" is silly honestly

[17:46:01] <dstufft> ~5 years~

[17:46:28] <wangofett> parobably largely related to personal frustration at the lack of adoption by the larger community

[17:46:35] <jnoller> It takes 5 years for RedHat to make a new RHEL release with anything but Python 1.9 in it /zing

[17:46:43] <Theuni2> jnoller: so maybe my answer to your question would be to foster the help you (and others like Lennart) are doing and provide an easy to approach group/location where to gather all the bombs people encounter so we can either provide "this is how you get around this in a dual code base" or "we need to fix this, don't upgrade your big big codebase yet" … is that something that already exists and I'm oblivious about?

[17:46:45] <wangofett> lol

[17:47:08] <wangofett> And of course Arch uses the newest version of probably everything ;)

[17:47:17] <jnoller> Theuni2: That's a fantastic suggestion actually

[17:47:27] <wangofett> Kind of like a...

[17:47:39] <jnoller> Theuni2: I own a domain, but lost all time to maintain the list of resources and site

[17:47:43] <Theuni2> i found it weirdly obvious while typing it and maybe there isn't much to it than print the label and stick it somewhere

[17:47:53] <wangofett> http://docs.python-guide.org/en/latest/

[17:48:22] <jnoller> yeah, http://getpython3.com/ is about... oh, 1.5 years out of date :|

[17:48:26] <Theuni2> wangofett: can't see much there regarding dual-code-base-migration

[17:48:36] <wangofett> nope - but conceptually, I mean

[17:49:05] <dstufft> jnoller: how dare you not keep it up to date

[17:49:06] <wangofett> or start changing it and send some PRs to kenneth

[17:49:44] <jnoller> wangofett: I would let that one alone and drive down a specific "expansion" to lennarts book and accentuate it with talks, tutorials, etc.

[17:49:50] <Theuni2> jnoller: yeah, kinda like that. i wish all the porting blog posts, guides, cheat-sheets could be integrated into a big thing

[17:50:01] <Theuni2> like, people working together ;)

[17:50:20] <Theuni2> i mean, lennart is the go-to-place probably

[17:50:20] <jnoller> Theuni2: Yeah, so do I. The problem is volunteers to do that work

[17:50:48] <Theuni2> hmm.

[17:50:52] <Theuni2> i mean

[17:50:54] <Theuni2> you know

[17:51:03] <Theuni2> Lennart wrote a whole big book about this porting thing.

[17:51:22] <Theuni2> I think we didnt need someone to write a whole book about porting from 1.5 to 2 ;)

[17:51:44] <Theuni2> this sounds like a big warning sign to me, and i think it supports the argument from those people who say they're re-evaluation python when pondering to move from 2 to 4

[17:51:45] <Theuni2> aeh

[17:51:48] <Theuni2> -1

[17:52:26] <jnoller> Theuni2: Did it require an entire book, or did he do it because he *wanted* to

[17:52:52] <Theuni2> jnoller: good question

[17:53:11] <Theuni2> he managed to get 150 pages out of it :)

[17:53:47] <jnoller> Theuni2: Any good writer can get 150 pages out of a subject. Ask me about managing about Dogecoin.

[17:53:59] <jnoller> -1 about

[17:54:53] <jnoller> Theuni2: just saying: number of pages != a problem, or a benefit, it's like counting LOC for productivity

[17:55:02] <Ivo> Theuni2: you've looked at the http://python-future.org/ ?

[17:55:04] <dstufft> jnoller: I'd buy a book about dogecoin

[17:55:05] <Theuni2> alright.

[17:55:47] <Theuni2> i notice i'm not up to date on my memes

[17:56:05] <Theuni2> jnoller: heard about it

[17:56:18] <Theuni2> jnoller: trying to remember all the small migrations from 2.0 onward

[17:56:29] <Theuni2> can't remember stuff before 2.4

[17:56:50] <Theuni2> after that it was kind of easy to keep compatibility between 2.4-2.7 if paying attention and running tests

[17:56:58] <dstufft> i started using python when 2.5 was new :| It was pretty smooth sailing back then :]

[17:57:04] <Theuni2> ack

[17:57:17] <Theuni2> the last big one i remember was some people who were stuck on 2.4 and libraries started using 2.5 features

[17:57:45] <Theuni2> after that it's merely the question whether library authors pay attention (which is kinda stupid because it makes python "inferior" for libraries versus applications)

[17:57:57] <Theuni2> so basically we all want to be as up to date as possible

[17:58:03] <jnoller> So assuming we haven't hit a 5 year bomb where space time will suddenly warp and explode - and that the sudden explosion of new/interesting languages is a typical cycle - this means we're not in panic-mode-oh-shit-we're-doomed. But we *do* want to identify the specific pain points people have (e.g. python 3 bugs, setup tools, etc) that prevent people from approaching things. For example - a lot of people get burnt by Python 3 using the system locale for

[17:58:03] <jnoller> the default encoding.

[17:58:26] <Theuni2> me me me!

[17:58:31] <dstufft> jnoller: are you on a phone

[17:58:44] <dstufft> setup tools :]

[17:58:45] <Theuni2> I havent' managed to read the thread where this was discussed for 3.3 yet

[17:58:46] <jnoller> And where we can put money (as the PSF)

[17:58:55] <jnoller> dstufft: nah just an APPLE MACINTOSH

[17:58:57] <Theuni2> i've got multiple accounts that accept money

[17:59:04] <Theuni2> they've got plenty of room, too

[17:59:40] <Theuni2> the system locale thing is just the newest. and i think i just might understand why PDB started breaking on me

[17:59:57] <dstufft> jnoller: I'm not sure what it says about me that my iMac understands setuptools on it's own now :[

[18:00:15] <Theuni2> it means it wants a puppy for its birthday

[18:00:40] <jnoller> Theuni2: Ok, so Java and Haskell do the same system locale thing, why was it a bad decision for Python 3? Is it because Python 2 hid that abnormality? (See python-dev latest for discussions on this fwiw)

[18:00:57] <Theuni2> I wasn't too happy with the old setting either.

[18:01:14] <Theuni2> When I heard about the new IO stack years back I was expecting we stop dealing with default encodings.

[18:01:37] <Theuni2> I don't see that we can derive programmer intention when open() is called whether his data has *any* relation with the locale the system runs on

[18:01:46] <dstufft> Theuni2: the problem with that is you have to pick some encoding

[18:01:50] <Theuni2> and its easy to forget an accidentally get wrong

[18:02:14] <Theuni2> dstufft: there's no problem making it open(foo, encoding='locale') or something if that's what you want

[18:02:24] <Theuni2> but if *I* put a file on my computer, package it up and move it somewhere else

[18:02:37] <Theuni2> why should *that* computers locale should have anything to say?

[18:02:38] <dstufft> Theuni2: So what would the behavior be if if you didn't specify an encoding?

[18:02:41] <Theuni2> fail

[18:02:45] <Theuni2> explode

[18:02:52] <Theuni2> make the programmer specify what he means

[18:03:15] <Theuni2> i find this to be the extension of the old unicode rule of "you can't guess the encoding giving some piece of data"

[18:03:28] <dstufft> I'd be ok with that, though I think you'd get more people complaining in that case :[

[18:03:46] <mitsuhiko> dstufft: pick utf-8?

[18:03:53] <mitsuhiko> works for .NET :P

[18:04:12] <Theuni2> picking a *fixed* encoding *everywhere* (no site.py) would be fine with me too. i'd accept mitsuhiko's idea.

[18:04:44] <Theuni2> just make something where moving some python code and a file from one computer to another break. that's just annoying.

[18:04:46] <mitsuhiko> if even microsoft (the guys that came up with the shitty idea of an utf-8 bom) manage to open files by default in utf-8 mode, why not us :)

[18:05:15] <dstufft> mitsuhiko: doesn't that break for the asian folks with like a billion letters that aren't in unicode

[18:05:23] <dstufft> shiftjis and shit

[18:05:24] <mitsuhiko> wat

[18:05:46] <mitsuhiko> that makes no sense at all

[18:05:49] <mitsuhiko> python internalizes into unicode

[18:05:58] <mitsuhiko> so if there is an encoding that is not unicode compatible then it would not work in python

[18:06:12] <Theuni2> dstufft: the asia-discussion, as far as i followed was that they wouldn't be happy with ascii as the default.

[18:06:45] <mitsuhiko> i would have never imagined there would be unicode circlejerks in python

[18:07:13] <mitsuhiko> for years nobody seemed to care and now all the sudden everybody is an expert :D

[18:07:42] <mitsuhiko> dstufft: not talking about you :)

[18:07:49] <wangofett> heh. mitsuhiko have you seen the hilarious guy on the python list who is all "Python3.3 is so much worse because specific case of unicode processing"

[18:07:50] <Theuni2> o_O

[18:07:57] <mitsuhiko> general observation about python 3 discussions on reddit and mailinglists

[18:08:10] <Theuni2> good that i stick to twitter and irc ;)

[18:08:32] <dstufft> mitsuhiko: I probably have the details wrong, I jsut recall that the asian places tend to use non utf8

[18:08:41] <Theuni2> jnoller: did we loose you somewhere? i tried answer a question from you, did this help?

[18:09:10] <wangofett> but I certainly prefer what Python at least *tries* to do. I've seen some articles about weirdness with length of unicode strings

[18:09:50] <Theuni2> I think I'll start weekend time now. :)

[18:10:05] <mitsuhiko> dstufft: used to at least

[18:10:20] <mitsuhiko> but shiftjis is a terrible encoding and people migrate off it

[18:12:32] <Ivo> dstufft: it makes files like twice the size for them

[18:13:47] <mitsuhiko> Ivo: that's actually not true at all

[18:14:15] <mitsuhiko> while in theory utf-8 is 30% larger than utf-16 for japanese, that's really only true if you look at actual text files

[18:14:32] <mitsuhiko> HTML, XML or whatever have enough ASCII stuff in there that utf-8 is a lot more efficient

[18:14:57] <wangofett> That makes a surprising amount of sense.

[18:15:03] <mitsuhiko> (in fact, i just checked that a few minutes ago for a blog post i'm writing. japaense wikipedia frontpage is 90KB in UTF-8 and 166KB in UTF-16)

[18:15:17] <Ivo> isn't shiftjis like 50% smaller than utf16

[18:15:21] <wangofett> Nice.

[18:15:35] <mitsuhiko> shiftjis is a terrible encoding and does not synchronize

[18:15:51] <mitsuhiko> and it's the same size as utf-16

[18:16:05] <mitsuhiko> (on average)

[18:16:15] <mitsuhiko> don't quote me on the sizes though

[18:16:24] <Ivo> actually, i didn't read dstufft's message clearly

[18:17:37] <Ivo> dstufft: "like a billion letters in unicode" HAVE YOU SEEN HOW MANY CODE POINTS ARE IN UNICODE

[18:17:39] <mitsuhiko> shift jis is not even ascii compatible :)

[18:17:47] <Ivo> ***aren't in unicode

[18:17:57] <dstufft> Ivo: lol if you think I know what I'm talking about at any point in time

[18:18:38] <Ivo> dstufft: you should read a couple of those 'this is how unicode and universal text works' essays, iz not too hard

[18:19:11] <dstufft> I only have so much room in my head for terrible things, and it's all filled up with setuptools, distutils, and pip

[18:20:46] <Ivo> http://diveintopython3.org oh great =_=

[18:22:59] <mitsuhiko> i wonder how japanese windows will migrate off shift jis

[18:23:06] <mitsuhiko> considering their directory separator is a yen symbol :P

[18:23:24] <Ivo> i wonder how they will migrate of winxp...

[18:23:58] <Ivo> dstufft: http://www.joelonsoftware.com/articles/Unicode.html at least bookmark it to read later! :)

[18:24:25] <Ivo> mitsuhiko: you know why their DS is that? always seemed slightly hilarious

[18:24:40] <wangofett> that would be awesome

[18:24:42] <mitsuhiko> because the designers of shift jis put the yen symbol where the backslash was in ascii

[18:24:57] <mitsuhiko> and the koreans found that so super useful that they took shift jis and put their own currency symbol at the same location

[18:25:13] <dstufft> encodings are so bad

[18:25:13] <mitsuhiko> so on korean or japanese windows the directory separator is til this day a fucking currency symbol

[18:25:27] <wangofett> C:$Users$Wangofett$Desktop>

[18:25:41] <wangofett> Ivo: so true. Turns out we're all crazy

[18:25:51] <jnoller> Theuni2: Sorry, had to lunch

[18:26:05] <dstufft> C:ƉUsersƉdstufftƉDesktop

[18:26:12] <wangofett> lol.

[18:26:12] <mitsuhiko> same reason irc considers {}| to be the lower case equivalents of []\

[18:26:19] <dstufft> Dogecoin best currency

[18:26:31] <wangofett> +1 for that

[18:26:44] <wangofett> Cpu mining is sad, though

[18:27:31] <wangofett> thanks to jnoller's tip on twitter the other day, I'm now up to 2,500 doge. \o/

[18:27:44] <jnoller> :D

[18:28:06] <dstufft> I have whatever doge jnoller gave me becuase i'm lazy and figuring out how to mine is :effort:

[18:28:45] <wangofett> hehe

[18:29:03] <wangofett> it's actually pretty easy. Just get a linux box, download... um

[18:29:24] <mitsuhiko> you guys have way too much time on your hands :P

[18:29:27] <Ivo> dstufft: we should have a python 2.8 so we can include lzma in 2.8 so wheel can use xz and all packages are way smaller. \o/

[18:29:51] <dstufft> xz best z

[18:29:51] <mitsuhiko> Ivo: all i want for christmas is SSL updates

[18:30:08] <dstufft> SSLv2 handshakes got turned off

[18:30:13] <dstufft> I was surprised

[18:30:15] <mitsuhiko> SNI still not in

[18:30:24] <Ivo> got turned off on what?

[18:30:31] <dstufft> Ivo: CPython 2.7

[18:30:36] <mitsuhiko> it got turned off because a naked core developer was dancing around it

[18:30:36] <dstufft> in whatever the next release is

[18:30:48] <Ivo> 2.7.7?

[18:31:00] <dstufft> if I get naked and dance can I convince them to backport more ssl??

[18:31:17] <Ivo> mitsuhiko: that seriously needs to be the commit message bahaha

[18:31:19] <wangofett> http://sourceforge.net/projects/cpuminer/files/ (cpuminer) then you just run it and point it at whatever pool you're using

[18:32:04] <Ivo> I'm wondering why wheel didn't use bz2. I think it's mostly smaller than zip

[18:32:24] <mitsuhiko> higher cpu requirements

[18:32:48] <mitsuhiko> also it's just compression, it does not have a structure

[18:32:52] <Ivo> mostly for compression though

[18:33:02] <mitsuhiko> so you need to put it in a tar and a tarball is a horrible format

[18:33:10] <Ivo> wheels should be mostly being decompressed

[18:33:24] <mitsuhiko> python code is so small anyways that it does not matter much

[18:33:33] <Ivo> has anyone ever bothered making a better version of a tar format

[18:33:41] <mitsuhiko> it is quite nice that you can import a .egg without having to uncompress it

[18:33:42] <dash> Ivo: yes it's called cpio

[18:33:47] <mitsuhiko> and wheels should be possible to do the same

[18:34:07] <dstufft> mitsuhiko: it is possible, though it's not a promise of the format

[18:34:16] <mitsuhiko> dstufft: unfortunately

[18:34:19] <dstufft> no

[18:34:21] <dstufft> fortunately

[18:34:30] <mitsuhiko> i strongly disagree

[18:34:35] <mitsuhiko> but oh well, not going to start a discussion about that

[18:34:37] <jnoller> of course you do

[18:34:42] <jnoller> ;)

[18:34:47] <Ivo> mitsuhiko: Werkzeug goes from like 1.1mb sdist to 38*kb wheel, so I find that quite exciting

[18:34:53] <dstufft> mixing install time and runtime is one of the problems of egg :]

[18:35:02] <mitsuhiko> Ivo: but that's for other reasons than zip vs bz2 :)

[18:35:06] <Ivo> shhhhhhh

[18:35:54] <wangofett> wow. That's pretty nice, Ivo

[18:35:56] <jnoller> dstufft: can I get compressed/encrypted runtime into wheel that uses an in memory key to decompress the tarbahl because shipping .pyc files by themselves no longer lets me hide my code?

[18:36:11] <dash> jnoller: #python gets asked this about twice a month

[18:36:24] <wangofett> should be an SO cannonical question

[18:36:24] <dstufft> jnoller: only if you use bcrypt

[18:36:26] <dash> (or something like it :)

[18:37:07] <jnoller> SCRYPT IS BASED OF BCRYPT AND DOGECOIN USES SCRYPT SO DOGECOIN IS SECURE

[18:37:10] <wangofett> I wonder if there exists any Pyfuscators

[18:37:20] <mitsuhiko> CAN WHEELS GET RID OF MY FREAKING PYCACHE FOLDERS

[18:37:23] <dstufft> wangofett: pretty sure yea

[18:37:31] <dstufft> mitsuhiko: what's wrong with __pycache__

[18:37:35] <mitsuhiko> it's visible

[18:37:38] <mitsuhiko> and it exists always

[18:37:46] <mitsuhiko> no way to disable it from what i've seen

[18:37:51] <mitsuhiko> PYTHONDONTWRITEBYTECODE does not work

[18:38:02] <dstufft> it' not visible for me :D

[18:38:06] <mitsuhiko> dstufft: hao?

[18:38:15] <wangofett> mitsuhiko: stop importing things. Just write the it all in one file ;)

[18:39:42] <Ivo> dash: https://en.wikipedia.org/wiki/DAR_(Disk_Archiver) looks good..

[18:39:59] <dstufft> mitsuhiko: because I never cd into directories that have them, and I use my editor to look at my filesystem which has __pycache__ set to hidden

[18:41:27] <mitsuhiko> dstufft: vim flask/_<tab>_i<tab><enter> :P

[18:41:55] <dstufft> mitsuhiko: :D

[18:42:04] <dstufft> I don't often have files that start with _

[18:42:13] <dstufft> because I hate the way it looks

[18:42:14] <mitsuhiko> seriously though. pycache is one of the many frustrations i have with python 3. and yes, it's small, but super annoying

[18:42:33] <dstufft> mitsuhiko: feels like something that could be easily patched

[18:42:41] <dstufft> like make it so PYTHONDONTWRITEBYTECODE works

[18:42:44] <dstufft> or whatever

[18:44:23] <wangofett> I agree that it looks wonky, but I also like that they used the dunder convention for it - basically a nice way of saying "nobody else should be using this, it's Python only, mmkay?"

[18:44:41] <mitsuhiko> .__pycache__ then :P

[18:44:51] <wangofett> yep

[18:44:54] <mitsuhiko> but apparently that would confuse windows users

[18:44:56] <mitsuhiko> which is why it was not picked

[18:45:04] <Ivo> i was about to note that

[18:45:05] <dstufft> Are Windows users ever not confused

[18:45:11] <wangofett> natch. Because Windows.

[18:45:15] <dstufft> .__pycache__.

[18:45:19] <Ivo> dstufft: you have to give them a gui

[18:45:20] <dstufft> we can be emo

[18:45:33] <dstufft> .xox__pycache__xox.

[18:45:33] <wangofett> dstufft: that would be even worse, lol.

[18:45:37] <jnoller> (:__pycache__:)

[18:45:50] <wangofett> I think it would actually break Windows

[18:45:55] <mitsuhiko> the correct thing woudl have been to have .par files

[18:46:00] <mitsuhiko> that includes the bytecode + the code

[18:46:03] <mitsuhiko> and setup.py makes them

[18:46:03] <jnoller> armin__pycache__armin

[18:46:07] <mitsuhiko> simple zip archives, end of store

[18:46:10] <mitsuhiko> :)

[18:46:30] <dstufft> not gonna lie, that sounds horrible

[18:46:35] <mitsuhiko> but the shitty .egg implementation scared people so much that .zip files is now the devil

[18:46:40] <wangofett> I think they've fixed it in the newer versions of windows, but the old ones you could put some unicode nonprinting char in the filename and nobody could get in them

[18:46:58] <dstufft> don't break my subl ~/.virtualenvs/lib/python2.7/site-packages/wahtever/whatever.py bro

[18:47:03] <Ivo> whl snuck zips in

[18:47:08] <wangofett> heh

[18:47:12] <dstufft> Ivo: don't tell anyone

[18:47:24] <Ivo> ok

[18:47:44] <dstufft> http://pythonwheels.com/ so much red, such sad

[18:47:59] <Ivo> mitsuhiko could make it a lot greener ;)

[18:48:03] <wangofett> hehe

[18:48:08] <mitsuhiko> i will :P

[18:48:21] <Ivo> I got Fabric on board today :D

[18:48:52] <wangofett> except that you can run them like eggs?

[18:48:52] <mitsuhiko> .eggs v2

[18:48:58] <dstufft> wangofett: they are the output of ``setup.py build``

[18:48:59] <dstufft> basically

[18:49:00] <Ivo> that actually work n stuff

[18:49:05] <mitsuhiko> eggs worked

[18:49:11] <dstufft> for some defintiion of worked

[18:49:12] <wangofett> e.g. py(thon) foo.whl

[18:49:14] <mitsuhiko> until pip broke them

[18:49:18] <Ivo> yeah but they were called 'eggs'

[18:49:24] <mitsuhiko> and they were annoying to build because bytecode was not stable

[18:49:37] <dstufft> including bytecode was a bad idea

[18:49:37] <mitsuhiko> and python's unicode builds fucked with binary packages

[18:49:45] <wangofett> Which was awesome, because snakes lay eggs, ya know?

[18:49:50] <mitsuhiko> having non stable bytecode was a bad idea and still is :P

[18:49:55] <jnoller> mitsuhiko: so how well did they work?

[18:50:12] <Ivo> mitsuhiko: tell that to .class'es yo

[18:50:15] <mitsuhiko> in regards of naming: is wheel really better than egg? :)

[18:50:19] <dstufft> No

[18:50:29] <dstufft> But Newegg was already taken :D

[18:50:33] <mitsuhiko> :D

[18:50:34] <Ivo> maybe i just have a learned aversion to them

[18:51:07] <dstufft> realtalk: Egg, like most of setuptools has some good ideas, but a terrible implementation

[18:51:10] <mitsuhiko> I'm a huge fan of single file libraries you just put into a location and that's it

[18:51:16] <mitsuhiko> c# is awesome for that

[18:51:22] <mitsuhiko> just download a .dll, put it next to your code, done

[18:51:34] <dstufft> mitsuhiko: I would totally be OK with something like that tbh

[18:51:42] <dstufft> just don't tie it into the package format :]

[18:51:59] <Ivo> im trying to get gevent to get wheels for windows, which will be awesome, cus everyone and his snake loves using gevent stuff these days to be all asyncronously cool

[18:52:17] <mitsuhiko> gevent does not run on windows

[18:52:25] <mitsuhiko> unless you call select() running

[18:52:25] <dstufft> Ivo: twisted has wheels

[18:52:25] <Ivo> sure it does

[18:52:29] <dstufft> :]

[18:52:46] <Ivo> well at least you can play with it

[18:52:55] <dash> Ivo: i have to wonder what you mean by "asynchronous" in that sentence

[18:53:42] <dstufft> dash: it's how you make things fast

[18:53:50] <Ivo> dash: non-blocking in its own green thread

[18:54:19] <dstufft> dash: you just sprinkle asynchronous all over the place and boom fast

[18:54:35] <wangofett> what's the difference between a thread and a green thread? The grass? ;)

[18:54:52] <dash> Ivo: I was pretty sure I know what those words meant, and they didn't go together like that

[18:55:02] <dash> Ivo: "non-blocking" means "an API that does not stop and wait"

[18:55:19] <dash> wangofett: some internal behaviors

[18:55:23] <dash> wangofett: the API is mostly the same

[18:55:33] <Ivo> ya, so it switches into the event loop which loads up the next ready green thread

[18:55:52] <dash> Ivo: right, so the API is the mostly the same as threads

[18:55:57] <dash> Ivo: i.e., a blocking API

[18:57:29] <Ivo> i put 'non blocking' and 'green thread' in the same sentence because the IO call doesn't block other green threads. That's the main idea (so joe layman can write non-blocking code without knowing it)

[18:58:19] <mitsuhiko> dash: not in tulip :)

[18:58:30] <mitsuhiko> tulip uses c# style explicit waits

[18:58:33] <dash> mitsuhiko: right

[18:58:41] <dash> we were talking about gevent though

[18:58:49] <dash> Ivo: he's not writing non-blocking code

[18:59:11] <dash> Ivo: the "non blocking" part you're talking about is a mostly-irrelevant implementation detail

[18:59:15] <dstufft> let's backport asyncio to 2.7 and 2.6 so I can use it in pip

[18:59:19] <dash> the API is a blocking API

[18:59:21] <dstufft> :[

[18:59:29] <dash> dstufft: https://pypi.python.org/pypi/trollius/

[18:59:41] <Ivo> not sure how that works without the yield from

[18:59:48] <Ivo> should find out some time

[18:59:52] <dstufft> dash: oh boy

[18:59:59] <dstufft> dash: I might actually try to do a thing

[19:00:32] <dstufft> or I could go make Twisted work more on Python3 and then convince whoever to make it possible to make it importable from pip._vendor.twisted

[19:01:33] <Ivo> dstufft: what thing are you trying to do exactly

[19:02:21] <dstufft> Ivo: i'm not actually trying to do a thing, but it'd be cool if pip didn't do everything serially :] But realstically that's probably going to be the case for a long time

[19:02:55] <Ivo> dstufft: so, grab dependencies in parallel?

[19:03:02] <dstufft> yea

[19:03:10] <dstufft> and do awesome stuff, like build wheels in parallel

[19:03:14] <dstufft> and then cache them

[19:03:17] <dstufft> and install from wheels

[19:03:19] <dstufft> :D

[19:03:32] <mitsuhiko> dstufft: threads?

[19:03:40] <mitsuhiko> it's not like you have massive concurrency in pip

[19:03:43] <dstufft> mitsuhiko: oh man that'll require me to learn how threads work

[19:03:57] <Ivo> they're not that hard

[19:03:59] <mitsuhiko> i'm going to ignore that comment

[19:04:12] <Ivo> tornado is fairly pure python isn't it? and 2/3

[19:04:23] <mitsuhiko> i found threads massively easier than coperative concurrency

[19:04:34] <tos9> mitsuhiko: heh, as if pip isn't broken enough as is that it needs concurrency bugs too

[19:04:46] <dstufft> mitsuhiko: real talk is it'll probably use threads because reasons and the only reason it isn't is because there's like a billion other things to do first

[19:04:53] <dstufft> pip used to use threads, I deleted them

[19:04:57] <dstufft> it was awesome

[19:05:05] <dstufft> it serially created a thread pool for each dependency

[19:05:16] <dstufft> and used a threadpool to scan /simple/ for that one dependency

[19:05:28] <dstufft> then closed the thread pool and moved onto the next one

[19:05:42] <Ivo> so it was so close, but so far, from a sane design?

[19:05:51] <dstufft> (granted this probably made more sense when scanning /simple/ for a single dependency could hit a hundred urls)

[19:05:57] <_Turbo_> sounds like someone knew what he was doing... ^^

[19:06:49] <mitsuhiko> pip is what happens if someone decides to rewrite someone elses code without understanding why it was designed in a certain way

[19:07:01] <mitsuhiko> not that anyone would have known what pje was thinking

[19:07:11] <mitsuhiko> but after a few years it became clear that ian and pje had different ideas in mind

[19:07:14] <dstufft> I'm not even sure pje knows what pje was thinking

[19:07:52] <mitsuhiko> i found it quite funny when people were saying that pip is the new hotness when pip was just another layer of hacks on top of setuptools

[19:08:02] <dstufft> mitsuhiko: not anymore!

[19:08:06] <dstufft> sort of

[19:08:22] <dstufft> pip 1.5.1 will make it entirely possible to never have setuptools installed

[19:08:36] <dstufft> (as long as you only install Wheels)

[19:10:15] <tomprince> dstufft: Couldn't you do vendoring by mounting wheels?

[19:11:20] <dstufft> tomprince: yes, though we decided not to do that because some people import pip and modifying sys.path modifies it for everyone whereas sticking it in pip._vendor.* only makes it available for pip itself (or whoever else does the whole import)

[19:11:41] <Ivo> dstufft: have you seen what distros want to do

[19:11:53] <dstufft> they want to pip out the vendored libraries

[19:11:58] <dstufft> which is fine idc

[19:12:01] <Ivo> goddamn distros

[19:12:21] <Ivo> not a single line of code can be duplicated

[19:12:28] <Ivo> or we will all burn in hell

[19:12:34] <dstufft> they have decent reasons for it tbh

[19:12:39] <tomprince> Seperate pip into a library and a frontend, and make the library depend on things rather than vendor them?

[19:12:51] <tomprince> Or, only mount the wheels in the frontend bits?

[19:12:56] <dstufft> tomprince: ~someday~

[19:13:02] <mitsuhiko> dstufft: isn't it ironic that the python packaging tools has problems with packaging libraries?

[19:13:21] <cwillu_borken> ironic maybe, but not terribly surprising

[19:13:22] <_habnabit> what do you mean by 'mount' a wheel?

[19:13:24] <dstufft> mitsuhiko: kinda :) though a large reason we vendor instead of depend is becuase it's a chicken and egg problem

[19:13:25] <cwillu_borken> meta stuff is hard

[19:13:34] <mitsuhiko> dstufft: vendoring should just be a special case of depending

[19:13:36] <mitsuhiko> see npm

[19:13:42] <dstufft> mitsuhiko: yea I agree

[19:13:46] <dstufft> ~someday~

[19:13:50] <cwillu_borken> "I have a tool for making gui's. It's kinda crap for making gui-making gui's though"

[19:14:05] <dstufft> _habnabit: you can add a whl to sys.path and import stuff from it

[19:14:06] <mitsuhiko> dstufft: … right after we killed sys.modules?

[19:14:12] <mitsuhiko> (that would have been a thing to fix in python 30

[19:14:14] <dstufft> mitsuhiko: I have ideas

[19:14:16] <_habnabit> dstufft, aha

[19:14:21] <tomprince> monte

[19:14:39] <dstufft> _habnabit: it's not an officially supported thing in the format, but it's unlikely to go away

[19:14:55] <dash> tomprince: not yet ;)

[19:15:14] <tomprince> Well, dstufft did say someday.

[19:15:35] <tomprince> dstufft: Does just putting it in sys.path work for non pure-python wheels?

[19:15:46] <dstufft> tomprince: probably not

[19:15:48] <Ivo> dstufft: http://pythonhosted.org/futures/#threadpoolexecutor-example

[19:15:53] <dstufft> Id on't think the zip importer works in that case

[19:16:20] <dstufft> I think egg makes that work by extracting it to a temporary location in that case

[19:16:30] <dstufft> (see another reason why importing eggs is problematic)

[19:20:10] <mitsuhiko> well, that workaround could have been fixed

[19:20:27] <mitsuhiko> there is no reason you could not just set some pages to executable and map the .so's in at runtime

[19:21:52] <dstufft> mitsuhiko: why don't you make a PEP to make zip importer work for compiled stuff? that'd be pretty cool tbh :D

[19:22:53] <mitsuhiko> i could just implement the importer :)

[19:23:34] <tomprince> Should it specifically be wheels? Since the platform specific stuff is in a sub-folder.

[19:37:29] <Ivo> dstufft: https://github.com/ross/requests-futures could be relatively easy to integrate

[19:51:29] <mitsuhiko> the new unicode repr in python 3 sucks balls

[19:51:34] <mitsuhiko> :-/

[19:51:36] <mitsuhiko> sorry

[19:52:10] <mitsuhiko> libedit does not support unicode so copy/paste is broken

[19:52:23] <mitsuhiko> and if you deal with unicode normalization you can't see the differences in strings

[19:52:29] <mitsuhiko> the small things ;-/

[19:53:41] <kayhayen> evening, wow, that's quite a bit more people than I expected to find.

[19:55:00] <tomprince> Well, there are people from both and multiple positions here.

[19:55:52] <kayhayen> The second position being that there shall be no Python2.8 be created?

[19:57:44] <Ivo> mitsuhiko: x can't handle unicode, so *y* is broken?

[19:59:50] <kayhayen> So is this about discussing, who is at fault, why not to do it, and that kind of stuff? Because I would rather take Python3 and Python2 for what they are and devise a plan to bridge the gap in a way that e.g. CCP could migrate to Python3 long term.

[20:00:29] <Ivo> CCP can't migrate anything long term until they write some goddamn tests for their code to fail against

[20:00:56] <kayhayen> Nobody is going to write these tests just to migrate to Python3, is he?

[20:01:20] <Ivo> I'm sure they'd invariably help with their normal development as well

[20:01:33] <kayhayen> CCP has millions of hours of CPU time to prove that certain code works. Why would they write tests for it suddenly.

[20:01:50] <Ivo> so it can be improved without regressing

[20:02:01] <Ivo> you know, the major write you write tests anyway?

[20:02:04] <Ivo> *reason

[20:02:25] <kayhayen> For most people I know, it's because it's part of the contract.

[20:02:57] <kayhayen> For some people I know, it's because it makes it cheaper to develop the software.

[20:04:42] <dstufft> not writing tests is fine if you never change your code ever

[20:04:52] <dstufft> as soon as you change your code ever you need tests

[20:05:47] <dstufft> anyways, gonna go get some bbq

[20:05:48] <kayhayen> It' also pointless to tell people to suddenly write tests for everything they are not changing, just so that the Python semantics can change.

[20:06:04] <dstufft> they cans tay on py2 then, that's fine it's not going anywhere

[20:06:11] <Ivo> kayhayen: sometimes its the not changing parts that break

[20:06:14] <kayhayen> Not going to happen. If people were proactively doing things, we wouldn't have this discussion.

[20:06:52] <mitsuhiko> Ivo: not really, but it's very annoying

[20:07:17] <kayhayen> Ivo, I do agree absolutely with you, it's not good. What gives? It's what people do. They don't write tests. They are not going to revisit all their codes.

[20:07:20] <mitsuhiko> print(ascii(x)) quickly became my favorite nested call

[20:07:41] <mitsuhiko> writing tests for computer games sucks

[20:08:06] <kayhayen> Real time systems are hard in any case.

[20:09:01] <kayhayen> For me (being the compiler guy), Python2.8 is about keeping old code running along new code in a compatible way.

[20:09:02] <Ivo> kayhayen: my argument is that it would indeed cost too much money for CCP to port to python 3 and not make good business sense, especially without a solid test suite. Them trying to python 3 would be silly

[20:09:39] <kayhayen> Ivo, which is why there needs to be a compatibility layer, at least so I started to think.

[20:09:50] <mitsuhiko> in case someone wants to read more unicode stuff: http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ :)

[20:09:58] <kayhayen> Python3 dicts and Python2 dicts, behaving as they always did, in the same process.

[20:10:19] <mitsuhiko> Ivo: s/CCP/any company

[20:10:47] <Ivo> ya, with a large enough codebase

[20:10:51] <kayhayen> CCP has recently formulated their position in an understandable form. I agree, any company, but I won't refer to any that I am involved with.

[20:11:09] <Ivo> kayhayen: http://python-future.org/

[20:11:47] <kayhayen> Wow, that looks great already. New stuff?

[20:11:58] <Ivo> it's been around for quite a while..

[20:12:33] <kayhayen> Ah, these are source level tools only.

[20:12:55] <mitsuhiko> i played with it, it's not really better than a hand written compat library :(

[20:12:59] <mitsuhiko> it has too much magic in there

[20:13:03] <mitsuhiko> including a custom isinstance

[20:13:22] <Ivo> from my own point of view, all the incompatibilities py3 introduced... were introduced for good reason. A 2.8 won't help with those incompatibilities. It would only help with re-adding features

[20:14:07] <Ivo> mitsuhiko: I like six better, but it's a good place to start for actually telling ppl how to write 2/3 compat. code and what the differences are

[20:14:44] <Ivo> (that website)

[20:15:44] <mitsuhiko> how many of you write code that runs in 2 and 3?

[20:15:46] <kayhayen> As it involves rewriting existing code and changing the run time behavior, it's basically not anything 2.8 in my mind.

[20:16:06] <kayhayen> I do, Nuitka runs a polyglot codebase.

[20:16:56] <tomprince> I'm concious of some of the differences with 3, and write code with that in mind, but I don't actually run it on py3.

[20:18:09] <Ivo> mitsuhiko: btw, ever thought about making a new standard to ursurp wsgi? on py3 it seems like it devolved into a horrible mess

[20:18:16] <kayhayen> To me the solution is to take Python3 and re-integrate Python2 via extension types, merging the two bytecode loops and event loops into one.

[20:19:02] <mitsuhiko> Ivo: i'm on the side of broken in theory but works in practice

[20:19:25] <mitsuhiko> new wsgi would mean backwards incompatibility

[20:19:34] <mitsuhiko> we can see how well that works at the example of python 3

[20:20:15] <Ivo> true, but wsgi was ultimately written with req-resp model in mind, much of which the web is not based on any more. I don't see how you get around that these days

[20:21:00] <Ivo> ok, not 'much of', but a lot of the new interesting stuff

[20:21:40] <pjenvey> py3 could have made open() require an explicit encoding, 2to3 could have changed everything to open(..., encoding='locale') or whatever, but changing it now is too late

[20:23:54] <kayhayen> pjenvey, in Nikola code, I saw "codecs.open" which is that, seems Python2 stuff.

[20:26:07] <pjenvey> codecs.open is somewhat similar to py3's open

[20:27:04] <pjenvey> it just doesn't do any decoding if you don't specify an encoding

[20:37:11] <Ivo> i wish bytes or bytearray had bitwise operations defined for it in python 3 :/

[21:10:57] <wangofett> Ivo: for example?

[21:11:18] <Ivo> a ^ b where a and b are bytes objects

[21:12:12] <wangofett> Could you do...

[21:12:24] <wangofett> hmmm, hang on lol

[21:12:50] <Ivo> you can do it in a loop but i wonder how much slower that becomes than it would be if it were just implemented in c under the bare type

[21:22:20] <wangofett> Yeah. That does seem a bit strange

[21:22:30] <wangofett> Maybe in Python 3.5? ;)

[21:26:44] <Ivo> wangofett: http://ideone.com/6bmvEw it's just... why is it that complicated

[21:30:01] <wangofett> Yeah, that's a bit silly

[23:42:49] <ngrilly> mitsuhiko: just read your new post about UTF-8. it is excellent. one of the best summary i've read on the subject. it would be fantastic for python to rely on UTF-8 more.

[23:59:01] <eevee> yes the single emoji in a response is a good point, ouch

Log file Viewer

Help | Karma | Search:

#python2.8 logs for Friday the 10th of January, 2014