Skip Montanaro <[EMAIL PROTECTED]> writes: > >> * Quixote > > Paul> Don't know what this is. > > Web app framework.
I think Python should add a web app framework to its core, again since it otherwise can't seriously begin to compete with PHP. However, there are lots of approaches so this is an example of where your suggested process of letting a bunch of different implementations circulate before choosing something is a good idea. > >> * PyInline > > Paul> Not sure what this is. > > A module for inlining C code within a Python module. Also see Weave from > the scipy.org folks. It was inspired by the Perl Inline::C module. Hmm, sounds like it has the same issues as Pyrex. I'm also not sure why you'd want both PyInline and Pyrex. > >> * PyGTK > > Paul> wxPython might be a better choice. > > Doesn't matter. At work they decreed GTK as the GUI platform long before I > came along (they also use gtkmm for C++ apps). Can't wxPython use GTK? > It's still an example of a broadly useful package available outside > the core distribution. I'd say if access to GTK is widely important functionality, then the core should provide it in some way (e.g. through wxPython) and that's enough. If your company wants some different (i.e. nonstandard, if wxPython becomes the standard) form of access, then it can deal with the consequences of not following standards. > Paul> 2. Isn't xmlrpclib written in Python? > Yes. The implementation language is just a detail. I think it's more than a detail. If an external module is written in Python, I can download it from wherever and include it with my own app that I send to an end user. I do the work so the end user doesn't have to. If it's written in C, then the end user has to deal with it. > Paul> See, as Python improved, those things went into the core. > > Sure, than that's what Martin has been trying to tell you about your AES > proposal. Put it out there, refine it, and get it into the core when it's > mature. What kind of refinements are you envisioning? This isn't a web application framework we're talking about. It's more like the sha module. > Paul> Could you use sigalarm instead? > > I suppose. That's not the point though. I'm not married to the concept as > you seem to be that something has to be in the core distribution to be of > use to me. I'm perfectly happy incorporating solutions other people > provide. So aren't you happier when the other person provides you with a solution that installs with one command, instead of a solution that requires you to download N different modules from who knows where, and install them separately, all while hoping that they haven't been tampered with? If I'm trying to provide someone else with a solution, I'd rather use sigalarm than make the end-user download an extra module, because I think they'll be happier that way. > Paul> What happens if you send your Python program to a > Paul> nonprogrammer friend who has just a vanilla Python installation? > > I figure out some other packaging solution. In my world most of the > software I write is for my employer, so this is not a problem I face very > often. People use freeze, py2exe, py2app or other packaging solutions to > solve most/all of these problems. Only those people who think that a cross-platform application is one that works on both XP Home and XP Pro. That does simplify some things. Life in a cult is often indeed simpler than life in the real world <wink>. > Actually, there were at least two fairly mature implementations of > CSV modules out there before the PEP was a twinkle in anyone's eye. > The authors of those modules got together and wrote the current PEP > and module from scratch based upon their collective experience. Yes, CSV is complicated and benefits from that process just like web app frameworks do. Let's pick another example, the hmac module that appeared in Python 2.2. It implements the RFC 2104 HMAC algorithm. Where are the two mature implementations that circulated before the hmac module was added? Where were the authors pooling their collective wisdom? Where was the year of user feedback? The answer is, nothing like that was needed. HMAC is simple enough for a module author to read RFC 2104 and implement what it says, run some tests, and declare the module good to go. > I think the effort of having a couple versions out in the field > followed by joint effort to produce something worthy of inclusion in > the core is an excellent demonstration of what Martin has been > saying all along. Martin is saying the opposite: that he doesn't understand the point of writing a new module that synthesizes from experiences with old modules, instead of just using one of the old modules. I don't think there's a one-size-fits-all answer to any of these questions. You have to have your hands in the details of a specific problem, to arrive at the best way to deal with that problem. -- http://mail.python.org/mailman/listinfo/python-list
