pmxbot IRC Log Viewer

[02:31:59] <kayhayen> How difficult would it be to have Python2 and Python3 in same process.

[02:32:46] <kayhayen> Many symbols will clash, right. But does anybody think, one can embedd libpython2 and libpython3 at the same time.

[02:33:25] <kayhayen> Cause, if you could, proxy objects could make Python2 objects interoperable with Python3 run time and vice versa.

[02:35:10] <dash> kayhayen: pypy would be a better avenue to explore for that, I think.

[02:35:44] <kayhayen> how come dash

[02:36:52] <dash> won't have the symbol clash issues, has an object-space abstraction that might help

[02:37:29] <kayhayen> isn't CPython2.7 compatible, and how good is it at Python3 already?

[02:38:24] <kayhayen> But honestly, I don't want to consider that route at all. What I care about, is how feasible it will be to plug CPython2.7 based functions and objects into CPython3.x

[02:38:35] <dash> Probably not very feasible

[02:38:42] <kayhayen> And how much changes it will take to the CPython code.

[02:39:02] <kayhayen> I have positive experience with my compiled objects in Nuitka, they integrate very well.

[02:39:52] <kayhayen> To me, it's basically about loading the bytecode interpreter of Python2 into the Python3 process, and having wraping objects that proxy stuff.

[02:40:22] <kayhayen> The different "dict" implementations probably will be giving the hard times there.

[02:41:58] <kayhayen> also shared libraries might hurt a bit, as they will not expect to be loaded more than once, and say both Python2 and Python3 modules use their own lxml, that may collide.

[02:58:32] <dash> the other idea would be to just ignore python 3 as a project entirely

[02:58:39] <dash> and port its useful parts to python 2.

[02:59:21] <kayhayen> you mean like porting yield from syntax and stuff?

[03:02:01] <dash> yes

[03:02:39] <kayhayen> but that's not going to be source compatible and solve the fork issue, so why bother.

[03:04:13] <dash> what do you mean "be source compatible"?

[03:04:26] <dash> what would the incompatibility be

[03:09:06] <kayhayen> unicode, bytes, print statements, dictionary run time behavior, stdlib names

[03:09:52] <kayhayen> i mean, to the people who are on Python2.7, the difficult part is not to change the syntax, but the ability to execute old code unchanged.

[03:10:42] <kayhayen> for new syntax, use new Python, simple as that. What you propose means to abandon Python3, which I don't see a point in.

[03:11:37] <kayhayen> Recently on planet python, people were pressed to name annoyances of python not fixed in Python3. Except for unicode not being done in a sane way, I couldn't name stuff.

[03:12:03] <tos9> depends what annoyances means

[03:12:14] <kayhayen> The only real wrong of Python3 is that it is leaving Python2 behind.

[03:12:19] <tos9> there's plenty to not like about python, and plenty of that wasn't changed in py3

[03:12:32] <tos9> kayhayen: well that's certainly not true :)

[03:12:40] <tos9> py3 has its own other set of annoyances

[03:12:47] <kayhayen> not for everybody of course

[03:13:15] <kayhayen> my Python3 experience is as limited as everybodies here, only toy compatible code

[03:20:17] <dash> kayhayen: python 3 is a waste of time from my perspective

[03:20:33] <dash> kayhayen: it does not fix most of python's problems for the software I want to write

[03:20:51] <dash> kayhayen: I am sure it's useful to someone

[03:21:17] <dash> kayhayen: so yes, I was referring to abandoning python 3

[03:23:44] <kayhayen> So to you this is about finding a community to improve Python2 with new syntax and features, but better than Python3 did.

[03:24:24] <kayhayen> Do I represent that correctly?

[03:25:04] <tos9> [I[I[I/n

[03:25:06] <dash> yes.

[03:25:28] <dash> most of the problems I see in python can't be fixed

[03:25:52] <dash> without making a rather different language

[03:26:14] <dash> so there's no value in making an incompatible language that keeps those problems; might as well keep compatibility

[03:27:15] <eriknw> dash, can you be more specific? what problems?

[03:29:07] <eriknw> the target isn't necessarily a path to Python 3.4. If python2 is improved incrementally in a way that python3 should also be improved, then the trajectory of nearest convergence between python 2 and 3 will be a later python 3 version

[03:30:45] <dash> eriknw: lack of encapsulation, mutable module objects, bad concurrency story, stdlib full of tools that should be avoided

[03:30:51] <kayhayen> to me, it would be OK if I could say "from python3 import python3_module_name" and "from python2 import python2_module_name"

[03:31:24] <dash> eriknw: presence of inheritance and classes, and poor support for message forwarding, are kind of minuses to me as well

[03:32:11] <eriknw> thanks dash

[03:32:13] <dash> oh right, no support for creating data/immutable objects

[03:32:15] <tos9> message forwarding is a PITA without like, actual interface support

[03:32:17] <dash> is a big one

[03:32:23] <tos9> but I hate it too.

[03:32:32] <dash> tos9: well it's a result of making functions primary and methods secondary

[03:32:40] <kayhayen> you can easily wrap a module in an object, that you make non-writable.

[03:32:54] <dash> kayhayen: What do you mean "make non-writable"?

[03:33:09] <eriknw> what's wrong with mutable module objects? don't like all the crazy monkey-patching that's gong on?

[03:33:12] <dash> other _really_ big one is global namespace for modules

[03:33:13] <kayhayen> you just have __setattr__ refuse to write

[03:33:17] <dash> eriknw: yes, that is the problem

[03:33:30] <dash> kayhayen: haha

[03:34:10] <kayhayen> Mercurial provides an __import__ that wraps every loaded module, just a bit of code.

[03:34:19] <eriknw> regarding mutable objects, Python is a language for "consenting adults". Just because it's probably not a good idea, it's up to the user (or library developer) to decide

[03:34:23] <dash> tos9: but yeah if you had a ruby/smalltalk style doesNotUnderstand method forwarding would be convenient

[03:34:28] <kayhayen> And it's fairly easy to make these wrappers disallow writes.

[03:34:29] <dash> eriknw: that is a stupid belief

[03:34:36] <eriknw> why?

[03:34:39] <dash> eriknw: what you mean is "python is for small programs"

[03:34:45] <eriknw> many modules have used mutability responsibly

[03:34:48] <tos9> dash: where you marked who did understand how?

[03:35:21] <dash> eriknw: I want to work on large programs, and I do

[03:35:25] <eriknw> dash, not at all. I've created large applications taht get deployed in the field. If the hardware breaks, it's hella-expensive to send a technician out there

[03:35:48] <dash> eriknw: and it's completely poisonous to maintainability to allow modification of modules

[03:36:03] <eriknw> yeah, dash, and I also used the ABC module to ensure specific interfaces for classes are adhered to

[03:36:10] <dash> eriknw: you don't

[03:36:15] <dash> eriknw: abcs don't ensure anything

[03:36:44] <dash> anyway abcs/interfaces/etc aren't a big deal

[03:36:53] <dash> that's small change relative to the other stuf

[03:36:54] <dash> f

[03:36:57] <kayhayen> All large C++ programs I ever saw were full of tricks to write stuff they were not supposed to do.

[03:37:10] <dash> yes. and who thinks C++ is a good idea now? :)

[03:37:21] <kayhayen> constant string, lets remove that, and change it, so we don't redesign the whole program.

[03:37:28] <eriknw> dash, what did you mean by lack of encapsulation? regarding what?

[03:38:03] <dash> eriknw: i am complaining about the existence of object attributes, essentially.

[03:38:38] <kayhayen> so you just use __slots__ and be done_

[03:38:49] <dash> nope, slots are the same

[03:39:12] <eriknw> interesting

[03:39:29] <dash> can be seen and modified by everything

[03:39:53] <kayhayen> so, I suppose, you have no reason to use Python, do you. This is honestly confused. But why use Python when we want it to be like say Ada.

[03:40:13] <dash> kayhayen: i use python because there's tons of useful libraries written in python

[03:40:20] <dash> i don't have to like python to benefit from it :)

[03:40:32] <kayhayen> lol... yes

[03:40:33] <dash> i don't want python to be like ada

[03:40:43] <dash> i don't really want python to be different than it is, even

[03:40:57] <dash> i want to be using a language somehwere between python, scheme, and smalltalk

[03:41:15] <dash> maybe with a little js flavor sprinkled on top (not much)

[03:42:25] <eriknw> I hear you, dash. Check this out: https://bitbucket.org/prologic/mio-lang

[03:44:07] <kayhayen> "Written in an easy to understand language"

[03:45:58] <dash> eriknw: glad to see people having fun. :)

[03:46:07] <dash> eriknw: looks like it's an interpreter

[03:46:13] <dash> eriknw: you work on this project?

[03:46:34] <eriknw> I've been meaning to. Need to add more functional programming aspects to it

[03:47:05] <dash> cool. well that's definitely a fun road to travel

[03:47:17] <dash> eriknw: here's mine, it has even less docs. :) http://launchpad.net/monte

[03:47:31] <eriknw> aye. don't know if it'll be useful, but, like you said, should be fun :)

[03:47:34] <dash> compiles to python currently, a friend is working on a custom vm in rpython...

[03:48:01] <eriknw> ha, nice. mio relies some on rpython, with hopes of using it more

[03:49:14] <eriknw> dash, I definitely agree with some of your points above, and I respect our differences ;)

[03:49:56] <eriknw> the python standard library does have too much crud remaining. It is very rare for a library to get deprecated then removed

[03:50:27] <dash> well python had some excellent ideas, in 1990

[03:50:46] <dash> today python is limited by its strengths, not its weaknesses

[03:53:55] <kayhayen> the feature that made python big, was readability, open source, and long term stability

[03:54:48] <dash> sure

[03:55:36] <dash> python has many behaviors that discourage readability though and those are what most of my complaints are about. so I am hoping for a better language in that regard someday...

[03:56:34] <dash> meanwhile, python 3 addresses none of them, so people who say python 3 is "inevitable" or "the future" are telling me that my concerns aren't real and that the code I've written isn't valuable to them

[03:56:39] <kayhayen> no, that duck typing, monkey patching, meta classes, and all, is part of the deal.

[03:56:53] <dash> duck typing is just fine

[03:57:09] <dash> monkey patching is, of course, the worst thing

[03:57:31] <dash> metaclasses aren't bad if you accept that classes aren't bad (I'm undecided right now)

[03:58:28] <kayhayen> do you know what coding rules are?

[03:58:37] <dash> Hmm?

[03:58:53] <kayhayen> i mean, there is always the language, and then how you use it.

[03:58:56] <dash> not familiar with that phrase

[03:59:18] <kayhayen> With C++ you could do so horribly evil stuff, you had rules to define the allowed subset.

[03:59:43] <kayhayen> Otherwise C++ was basically unusable. Same for Python. We have rules to program "safe" programs.

[03:59:46] <dash> yes

[03:59:54] <dash> and this is why people are developing new languages to replace C++ :)

[04:00:14] <kayhayen> We review our code for adherence to it, and so the ability comes in handy, occasionally, but you don't do monkey patching for the final solution.

[04:00:19] <dash> kayhayen: what this means is that you need very disciplined programmers on your projects

[04:00:31] <dash> kayhayen: and that training becomes expensive

[04:00:48] <dash> kayhayen: because you have to teach your new programmers how to ignore most of the code examples they find on the internet

[04:01:30] <dash> If you have a facility or a library in your language that's always bad, why keep it?

[04:01:36] <kayhayen> these rules are really that much of a deal to programmers, are they.

[04:01:50] <dash> (the reason you keep it, of course, is because you have old bad code you need to run)

[04:02:09] <dash> If you're designing a new language, why not forbid as much bad style as possible?

[04:02:26] <dash> (and make it easy to build tools to forbid more bad style)

[04:02:40] <kayhayen> Because the bad things are frequently useful.

[04:03:07] <eriknw> I recently assigned to `sys.stdout` :)

[04:03:12] <kayhayen> With monkey patching it's fairly easy to e.g. trace the writes to a module, and prove things about it in tests.

[04:03:15] <dash> It's possible to keep the usefulness without the badness in all the cases I've mentioned, I believe.

[04:03:44] <kayhayen> I don't see why the language should impose style limitations.

[04:04:22] <dash> kayhayen: python already does impose style limitations

[04:04:38] <dash> kayhayen: the value of a language is as much in what it forbids as in what it allows

[04:04:58] <dash> kayhayen: the reason a language should impose limitations is to support readability

[04:05:23] <dash> kayhayen: do you know the story of smalltalk-76?

[04:05:28] <kayhayen> Python does impose no limits on flexibility

[04:05:46] <dash> sure it does.

[04:05:57] <eriknw> Python2 doesn't support anonymous functions

[04:05:58] <dash> you can't access the locals of a function from outside the function

[04:06:06] <dash> there's no goto or call/cc

[04:06:24] <eriknw> you can access the locals iirc, but you can't write to them

[04:06:25] <dash> builtin types can't have methods added to them

[04:06:25] <dash> etc

[04:06:42] <kayhayen> of course you have locals writable.

[04:06:43] <dash> flexibility always has a cost

[04:06:54] <eriknw> kayhayen, not from outside the scope of locals

[04:07:08] <dash> sometimes that cost is worth it

[04:07:14] <kayhayen> nonlocal does not count in this channel, does it.

[04:07:14] <dash> sometimes you can get the benefits in a cheaper way

[04:08:00] <eriknw> nonlocal is python3, right?

[04:08:06] <kayhayen> it is

[04:08:33] <kayhayen> writable closure variables are one of the improvements in my eyes.

[04:08:56] <eriknw> dash, what's the story of smalltalk-76?

[04:09:09] <dash> eriknw: smalltalk-76 was a language much more flexible than python

[04:09:19] <dash> it allowed defining objects, methods, custom syntax

[04:09:19] <kayhayen> i don't know it.

[04:09:29] <kayhayen> 80 is the first thing i ever heard of

[04:09:36] <eriknw> agreed, kayhayen, and anonymous functions (even though that can result in some poor quality code)

[04:09:41] <dash> yes, that was the first public release

[04:09:48] <dash> eriknw: python has anonymous functions

[04:10:03] <eriknw> python3 does

[04:10:03] <kayhayen> ok, i think I know that part, and it's great art.

[04:10:06] <dash> here's an anonymous function: http://paste.pound-python.org/show/chatserver/

[04:10:37] <kayhayen> now that's what I call readable ;-)

[04:10:38] <eriknw> heh, I'll pass on that version

[04:10:59] <dash> sorry I meant Smalltalk-72

[04:11:28] <kayhayen> so yeah, Smalltalk was brilliantly designed, and it still failed at some point, what gives

[04:13:55] <kayhayen> And if you find Python too allowing, how come you like Smalltalk, e.g. http://en.wikipedia.org/wiki/Smalltalk#Level_of_access

[04:14:00] <dash> anyway the issue was that smalltalk-72 allowed every object to create new syntax

[04:14:12] <kayhayen> (or change existing one)

[04:14:19] <dash> the result was that you could not understand any of the program until you understood all of the program

[04:14:28] <dash> so they removed that in later versions

[04:14:55] <kayhayen> the cool thing about Smalltalk was that it was self-hosting.

[04:15:54] <kayhayen> it clearly is a clue that PyPy is not run with PyPy, and CPython not with CPython.

[04:35:10] <dash> eh, smalltalk was as self hosting as pypy is.

[04:35:15] <dash> squeak in particular

[04:37:04] <kayhayen> With Smalltalk, very very little was part of the core, and everything was extension.

[04:37:45] <kayhayen> With PyPy, I don't see Python bytecode being used any much more than it is in CPython.

[04:38:20] <kayhayen> It's not any http://c2.com/cgi/wiki?HomoiconicLanguages is it

[04:39:13] <kayhayen> but i find Python to be a fair compromise, anyway gotta run... cu another day or night

Log file Viewer

Help | Karma | Search:

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