[issue5819] Add PYTHONPREFIXES environment variable
Ian Bicking i...@colorstudy.com added the comment: This has a similar purpose to virtualenv, but using an environmental variable. An earlier package, workingenv, also used an environmental variable, and this led to a set of problems. The biggest problem is that the environmental variable is inherited by subprocesses. This means if you install hg globally, then do subprocess.call(['hg', ...]), then hg will have picked up your local environment. Sometimes this is what you want (e.g., when using ipython) and sometimes not (probably not when using hg). Another problem is that scripts aren't really sticky with respect to the environment. When you install a script using this, it may only work when that same environmental variable is set. But the script remains present and callable regardless. Also, it's hard to mix and match environments in this system. These are real-world problems I encountered with workingenv, and virtualenv has resolved them very reliably by instead using sys.executable to select the environment. This requires some infrastructure in each environment which is unfortunate, but the result is more consistent behavior. -- nosy: +ianb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Ian Bicking i...@colorstudy.com added the comment: Also with respect to the patch, for consistency there needs to be changes to distutils to make use of this variable. PYTHONUSERBASE included changes so that you can install based on that variable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
Ian Bicking [EMAIL PROTECTED] added the comment: cgi started using this argument due to the potential of a DoS attack without the length limit. So undoing this in cgi (even as an option) would be a regression. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
New submission from Ian Bicking [EMAIL PROTECTED]: The method wsgiref.validate:InputWrapper.readline doesn't take any arguments. It should take an optional size argument. Though this isn't part of the WSGI specification, the cgi module uses this argument when parsing the body, and in practice no applications that use cgi.FieldStorage (which is most applications) are compatible with wsgiref.validate as a result. Simply adding a *args that is passed to the underlying file fixes this. -- components: Library (Lib) messages: 75920 nosy: ianb severity: normal status: open title: wsgiref.validate doesn't accept arguments to readline versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
Ian Bicking [EMAIL PROTECTED] added the comment: This renders wsgiref.validate.validator completely useless, because it cannot be used with any existing code. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
Ian Bicking [EMAIL PROTECTED] added the comment: Yes, and I've wanted to deprecate paste.lint, but I can't because people use it over wsgiref.validate because it had this change applied. Yes, cgi.FieldStorage changed, but now that it's changed wsgiref needs to be compatible with it to be viable. Mostly the WSGI spec has been wrong on this for some time, but we've never gone through the process of updating it (though it has been brought up several times on Web-SIG). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4056] :Class: causes exception
New submission from Ian Bicking [EMAIL PROTECTED]:
I used a reference like :Class:`something` (note the capitalization) and
got this exception:
Traceback (most recent call last):
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/__init__.py,
line 135, in main
app.builder.build_update()
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py, line
201, in build_update
summary='targets for %d source files that are '
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py, line
241, in build
self.write(docnames, updated_docnames, method)
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/builder.py, line
276, in write
doctree = self.env.get_and_resolve_doctree(docname, self)
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/environment.py,
line 779, in get_and_resolve_doctree
self.resolve_references(doctree, docname, builder)
File
/home/ianb/src/env/lib/python2.4/site-packages/sphinx/environment.py,
line 998, in resolve_references
raise RuntimeError('unknown xfileref node encountered: %s' % node)
RuntimeError: unknown xfileref node encountered: pending_xref classname
modname refcaption=False reftarget=deliverance.rules.Drop
reftype=Classliteral
classes=xrefdeliverance.rules.Drop/literal/pending_xref
--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 74385
nosy: georg.brandl, ianb
severity: normal
status: open
title: :Class: causes exception
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4056
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to kill a thread?
On Jun 7, 6:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Here is an attempt at a killable thread http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496960 and http://sebulba.wikispaces.com/recipe+thread2 I use this recipe in paste.httpserver to kill wedged threads, and it works okay. It seems to kill threads that are genuinely wedged, e.g., if you try to read past the end of a socket. It takes surprisingly long, up to a minute to actually send the exception to a thread. But it's just a normal exception and seems to act reasonably. Obviously this is not a great system, but it's better than having a background process hang because of problem code elsewhere in the system. It also isn't any worse than kill -9, which is ultimately what a multiprocess system has to do to misbehaving worker processes. Still, to try to mitigate problems with this I set up a supervisor process and if there is a lot of problems with worker threads I'll have the entire process self-destruct so it can be restarted by the supervisor. The code is rather... organic in its development. But you can see it in the ThreadPool here: http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py Ian -- http://mail.python.org/mailman/listinfo/python-list
[issue3037] generator in output
Ian Bicking [EMAIL PROTECTED] added the comment: You can see the source that produces this in http://svn.pythonpaste.org/Paste/trunk at revision 7387 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3037] generator in output
Ian Bicking [EMAIL PROTECTED] added the comment: Armin says this is a bug that has now been resolved in Jinja ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python web frameworks
On Nov 20, 7:55 am, Joe Riopel [EMAIL PROTECTED] wrote: On Nov 20, 2007 8:46 AM, BartlebyScrivener [EMAIL PROTECTED] wrote: Django comes with its own little server so that you don't have to set up Apache on your desktop to play with it. Pylons too, it's good for development but using the bundled web server is not recommended for production. It's actually fine to use it for production. There's two servers that are used commonly with Pylons, the one in Paste and the CherryPy server (it's a one-line configuration change to switch). The generally recommended production deployment is using one of these, with another HTTP server in front proxying requests back. There's lots of side-benefits to that particular setup, like hosting the Pylons app alongside static files, PHP, etc. But there's quite a few people who serve directly from Python (probably more often using the CherryPy server, though I don't really know the differences in a production situation). Anyway, mostly an aside for choosing a framework. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python web frameworks
On Nov 22, 11:00 am, Istvan Albert [EMAIL PROTECTED] wrote: On Nov 21, 12:15 am, Graham Dumpleton [EMAIL PROTECTED] wrote: I would say that that is now debatable. Overall mod_wsgi is probably a better package in terms of what it has to offer. Only thing against mod_wsgi at this point is peoples willingness to accept something that is new in conjunction with Linux distributions and web hosting companies being slow to adopt new packages. Yes that is to be expected, many people want someone else to pay the early adopter's costs. Nonetheless mod_wsgi seems like the right direction to move the python world. One confounding factor that may slow its adoption could be the need of running plain old CGI in an efficient way. I'm not sure how that fits into the WSGI picture. Practically running CGI quickly is hard. All of the modern batch of frameworks contain too much code to do this; the startup cost of loading all that code for each request is just too much. For commodity servers that only support CGI scripts, and periodically kill long-running requests, I had an idea for making WSGI applications look like CGI scripts: http://blog.ianbicking.org/2007/08/03/fast-cgi-that-isnt-fastcgi/ -- basically using the CGI script as a pipe to the application, with some process management built in. Of course, it still would need to be implemented. I suspect it would be a fairly simple task for someone familiar with C. This isn't really a big deal for most professional web developers, who can control their server environment, but lack of this style of deployment does make it a lot harder for web application users to use Python applications. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Paste and WSGI 2.0 [WAS: Yet another comparison of Python Web Frameworks]
On Oct 14, 3:46 am, Michele Simionato [EMAIL PROTECTED] wrote: I think we do agree entirely, it is just that the application we have in mind is more a collection of web services than a traditional Web application. Now, since you are here, there is an unrelated question that I want to ask you, concerning the future of Paste with respect to WSGI 2.0. I do realize that at this stage WSGI 2.0, is only a draft, still I would like to know: 1. if you think that WSGI 2.0 is good idea (I expect you will say yes) Yeah. WebOb's functions have made me feel less of a need for that change, and it normalizes some of the parts of WSGI that WSGI 2 removes. But I think it would generally help. 2. if you plan to support it in Paste and if yes when (I mean, in a month, in a year, in three years?) 3. if you already have thought of a migration plan and, in that case, what your strategy would likely be. This I'm really not sure about. A middleware could wrap any WSGI application to make it support both WSGI 1 and 2. However, on the server side it's unclear how to do the transition (including middleware that calls WSGI applications). If WSGI 2 included some marker that I could look for, then it would be relatively easy too -- I'd always just call applications with a library function that knew how to deal with both kinds of applications. Without that... well, maybe I'll just have to be sure that there's a clear upgrade path for the spec in general. Of course, as Graham says, WSGI 2 is just talk at this point; there's not a ton of momentum toward actually delivering a new spec. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:29 am, Michele Simionato [EMAIL PROTECTED] wrote: Do you (or something else) have something to say about Beaker? I looked at the source code and it seems fine to me, but I have not used it directly, not stressed it. I need a production-level WSGI session middleware and I wonder what the players are (for instance how Beaker does compare with flup?) Beaker is the only seriously maintained WSGI session at the moment -- flup isn't, AFAIK, very actively maintained or improved. paste.session is a particularly naive implementation of sessions. So as a result, Beaker is kind of the only game in town. Incidentally, it's not really related to SQLAlchemy; it came out of Myghty. Same author, of course, but fairly different domains. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:13 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Well... Last year, I had a look at Pylons, then played a bit with wsgi and building my own framework over it. I finally dropped that code and went back to Pylons, which I felt could become far better than my own efforts. Now since then I had way too much to do at work (using other technos) and didn't find the time to work on my own projects, so I still don't know how well Pylons will pass the real world test, but it seems to me that it's rapidly progressing and mostly in the right direction. I still wait for an opportunity to check this out !-) This would be my general suggestion too. It's fine to write your own, and not that hard, but you'll be missing out on the momentum and help from the community. You'll be maintaining your own code instead of having other people work on maintenance -- which actually isn't that much more work, except that you'll be doing it alone and without that collective experience at hand. That said, going without a framework (which at least in his article is what Michele seems to be comparing Pylons against) isn't always so bad. I started writing an Atompub server in Pylons, but felt like I was spending too much time navigating around what the framework setup and not enough time just paying attention to what Atompub really is. So I ended up writing it (as FlatAtomPub), effectively without a framework (though developing it at the same time as WebOb, so I leaned on that quite a bit). The development went quite well, and for a web service like Atompub that's probably what I'd recommend (at least to experienced developers -- you might find yourself left to drift otherwise without a clear idea of where to start). But for writing a traditional web application, I'd still use Pylons. The choices Pylons have made are with that in mind, and it doesn't at all exclude other forms of development in the process. You could actually drop a FlatAtomPub instance right into a Pylons app, for instance. Pylons is a small enough framework that it really is quite reasonable to pick and choose and use a very minimal style with it. Ian -- http://mail.python.org/mailman/listinfo/python-list
ANN: Paste 1.2
Paste 1.2 - I'm happy to release Paste 1.2. This release contains a mix of small features and bug fixes. This is only a release of core Paste (not Paste Script or Deploy), which contains the WSGI tools. What Is Paste? -- URL: http://pythonpaste.org Install: easy_install -U Paste News: http://pythonpaste.org/news.html Paste is a set of WSGI components, each of which can be used in isolation. But mixing them together leads to powerful chemical reactions which can be harnessed for good. These components let you do things like create applications that proxy to other websites, mount multiple applications under different prefixes, catch exceptions and interactively inspect the environment, and much more. Paste Deploy is a configuration system for these components. Paste Script is a jack of all trades that builds new project file layouts, runs WSGI server stacks, and does application deployment. Interesting News See http://pythonpaste.org/news.html for details * Backward incompatible change in paste.fileapp.FileApp to make it support GET and HEAD properly. If you subclassed FileApp or DataApp you may need to change your code. * Parsing of Accept and Accept-Language * paste.wsgiwrappers.WSGIRequest can optionally decode unicode values in form submissions. * paste.httpserver supports all request methods (e.g., MKCOL), no longer blocks if you read past the end of wsgi.input, and includes code to control the thread pool and kill threads that are wedged. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Paste 1.1
Paste 1.1 - This release includes a security fix, fixing a situation where you could escape the root when serving static files and running the Paste HTTP server publicly. If you used other WSGI servers or used the Paste HTTP server behind Apache this does not effect you. For an update of Paste 1.0 that includes *only* the security fix, use easy_install Paste==1.0.1 What Is Paste? -- URL: http://pythonpaste.org Install: easy_install Paste PasteScript PasteDeploy News: http://pythonpaste.org/news.html http://pythonpaste.org/script/news.html http://pythonpaste.org/deploy/news.html Paste is a set of WSGI components, each of which can be used in isolation. But used together they form an unstoppable force. Team WSGI, unite! These components let you do things like create applications that proxy to other websites, mount multiple applications under different prefixes, catch exceptions and interactively inspect the environment, and much more. Paste Deploy is a configuration system for these components. Paste Script is a jack of all trades that builds new project file layouts, runs WSGI server stacks, and does application deployment. Interesting News Paste ~ * Security fix for paste.urlparser.StaticURLParser. The problem allowed escaping the root (and reading files) when used with paste.httpserver (this does not effect other servers, and does not apply when proxying requests from Apache to paste.httpserver). * paste.httpserver and paste.fixture.TestApp url-unquote SCRIPT_NAME and PATH_INFO, as specified in the CGI spec. Thanks to Jon Nelson for pointing out both these issues. * paste.registry now works within the EvalException interactive debugger. * Added a __traceback_decorator__ magic local variable, to allow arbitrary manipulation of the output of paste.exceptions.collector before formatting. * Added unicorn power to paste.pony (from Chad Whitacre) * For paste.httpserver SSL support: add support loading an explicit certificate context, and using ssl_pem='*' create an unsigned SSL certificate (from Jason Kirtland). Paste Script * Allow variable assignments at the end of paster serve, like paster serve http_port=80; then you can use %(http_port)s in your config files (requires up-to-date Paste Deploy). Paste Deploy * Really nothing interesting. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: WSGI - How Does It Affect Me?
Gregory Piñero wrote: What I'm most confused about is how it affects me. I've been writing small CGI programs in Python for a while now whenever I have a need for a web program. Is CGI now considered Bad? I've just always found it easier to write something quickly with the CGI library than to learn a framework and fool with installing it and making sure my web host supports it. There's two aspects to CGI. As a method of deploying a web application, it is fine (though slow). You can still deploy your applications as CGI if you write them with WSGI. (This is covered some in PEP 333) There are some bad parts of CGI too, which won't work with WSGI. An example is using print for output. WSGI is neutral about how your application will run -- maybe it'll be a CGI script, maybe it'll be a threaded server with long-running processes, maybe a forking server. Also, you can't have statements at the module level, like you would with a CGI script. All your code needs to be in functions. I think these are all good ideas anyway. One advantage of WSGI is that in addition to CGI you can easily set up an HTTP server (there's one in wsgiref, for example). Then you can develop and test your application locally. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Paul Boddie wrote: Perhaps, although I imagine that Trac would have a lot more uptake if it handled more than just Subversion repositories. It handles some other kinds of repositories now (bzr, I think?). From what I understand fully abstracting out the repository format seems to still be a work in progress, but it is in progress and you can write repository plugins right now. [...] I did briefly look at Trac to see whether I could hack in a WebStack backend, and I'd do the same for ViewVC if I had the time, mostly because such projects already duplicate a lot of effort just to permit the deployment of the software on incompatible server solutions. There's certainly a lot these solutions could learn from each other and from lesser known solutions. Trac now includes a WSGI backend, and someone has written a WSGI backend for ViewVC (though I don't know if it is included with the project). Clearly you need to get on the WSGI bandwagon ;) Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: code is data
Ravi Teja wrote: Or... maybe to be more specific, the hard work later on goes into *code*. If you are enhancing your model, you do so with methods on the model classes, and those methods don't effect the DSL, they are just code. You create some raw XML in the beginning, but quickly it's just a matter of gluing those pieces together, using functions instead of DSLs, and that's just code. That doesn't look that much better. How do you create it programmatically? I know how to pass a variable to CharField(maxlength=200); can I pass a variable to char length 200 just as easily? Can I use **kw? Can I read it from a CSV file and construct the class that way? Maybe, but only by recreating all the native patterns that I can infer easily looking at the Django class. I am looking at it from the cognitive perspective. You are looking at it from the compiler perspective. I don't think that distinction is very meaningful. As a programmer I have to understand both. I have to be able to synthesize correct expressions. I need to understand the compiler. I understand the Python compiler well, and it gives me reasonably good feedback when I get things wrong, and it has a lot of flexibility along several orthogonal lines. We're talking about programming languages, so it's useless to consider a cognitive perspective without considering the compiler perspective. I think you are talking about full blown DSLs like SQL which try to be self contained for a given domain. The ones I am referring are only thin layers on Python. I understand you, but it's very unclear to me how you can make a thin layer that's not horribly leaky or stunted. In my experience one or both are likely in DSLs, and the result is horrible and only useful as a toy. If you are really serious about the implementation, sure. But DSL almost screams out that it lacks seriousness, and a long-term commitment to debuggability, generality, and documentation. However I think that you are seeing my sample differently than I meant it. I did not mean to create a special syntax file that would be parsed as a text file such that it would loose all the benefits of Python. It is just a thin layer over Python code for specific representational benefits. Kay Schluehr does a good job of identifying it as such in his reply. I understood the distinction you were making. But you were also speaking generally about generally programmable syntax, and I don't think that's a good idea, and it's very unclear how that mixes with Python. You can always do: model = make_model( my funny syntax ) And you actually get something that can be a close peer to normal Python code. But if you are talking about Python and some novel syntax interleaved, then the details seem to matter a lot, because the implementation is substantial and potentially invasive. There are also very *specific* things that can be discussed that are more conventional, and driven as much by the ease of implementation as expressiveness. I think that is much more productive, because I think the general case is a bad idea. The 'make' syntax is an example of this. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: code is data
Ravi Teja wrote:
Fredrik Lundh wrote:
Ravi Teja wrote:
Web frameworks, which seem to be the rage now in Python community could
have benefited tremendously from Macro capabilities since they have a
lot of boiler plate.
they do? methinks you haven't done much web programming lately...
/F
You blogged on Django. Let's use that. Don't you think model creation
in Django can be represented better, given that it is done often
enough?
Actually, no, it's not done that much. Creating and managing tables
isn't something done lightly. It's essential to building a new
application, but (at least in my experience, in similar systems) the
database models stabalize early and you don't spend that much time with
them. Especially not with the DSL aspects. I add and remove methods
often, but I am loathe to add and remove columns.
Now, this might seem like I'm being pedantic, but in my experience lots
of seemingly obvious DSLs end up not being that obvious. XML
generation, for instance. It's nice to have a good syntax -- and you
can get a pretty good syntax in Python (e.g., HTMLGen, stan, etc). But
efforts that go further are generally misplaced, because it's actually
not a very hard or common thing to do, even when you are slinging
around lots of XML.
Or... maybe to be more specific, the hard work later on goes into
*code*. If you are enhancing your model, you do so with methods on the
model classes, and those methods don't effect the DSL, they are just
code. You create some raw XML in the beginning, but quickly it's
just a matter of gluing those pieces together, using functions instead
of DSLs, and that's just code.
Let's take an example from the official tutorial
from
http://www.djangoproject.com/documentation/tutorial1/#creating-models
class Poll(models.Model):
question = models.CharField(maxlength=200)
pub_date = models.DateTimeField('date published')
class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(maxlength=200)
votes = models.IntegerField()
I don't use Django and I made this up quickly, so please don't pick on
subtleties.
@Poll:
question: char length 200
pub_date('date published'): date
@Choice:
poll - Poll
choice: char length 200
votes: int
That doesn't look that much better. How do you create it
programmatically? I know how to pass a variable to
CharField(maxlength=200); can I pass a variable to char length 200
just as easily? Can I use **kw? Can I read it from a CSV file and
construct the class that way? Maybe, but only by recreating all the
native patterns that I can infer easily looking at the Django class.
The following is my rationale. Annoted variables, symbols and code
layout visually cue more efficiently to the object nature than do
explicit text definitions. Of course, this is only sensible when there
aren't too many of any of those. In that case, the cognitive cost of
notation outweighs the representational cost of text.
Words are great. Python is light on symbols, and that is good. Python
is not perfect when it comes to expressing data structures (the more I
think about it, the more PEP 359 grows on me), but real DSLs are
questionable to me.
Even the Lisps stick to an incredibly homogenous syntax (far more
homogeneous than Python) to make macros feel familiar.
Representational minimalism is troublesome in general code (ala Perl),
but not so in a DSL where the context is constrained.
Constrained context is a step backward! How do you add methods? How
do you do looping? How do you write *code*? If you aren't going to
allow those things, then just make a parser and build the structure
from the file, and make it a DSL implemented entirely external to
Python. That's completely okay, though in my experience it's not very
satisfying for something like a model definition (see MiddleKit for an
example of an ORM that doesn't use Python code).
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote: i I would like to extend python so that you could create hiercical tree structures (XML, HTML etc) easier and that resulting code would be more readable than how you write today with packages like elementtree and xist. I dont want to replace the packages but the packages could be used with the new operators and the resulting IMHO is much more readable. You might want to look at PEP 359 for ideas: http://www.python.org/dev/peps/pep-0359/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Editing a function in-memory and in-place
Thanks for the answers, very helpful. I think I'm going to give Peter's hack a try, as it's actually quite close to what I'm trying to do -- I get the source for the new function, then that lets me make the old function become the new one. But I'll probably also use Michael's solution for class editing. Now I just have to figure out how to take in-memory structures and turn them into Python source code. Hmm... that actually leads me back to Michael's solution more, since in that model you are always dealing with source, and if you faithfully reproduce the source then you should more-or-less reproduce the same structures. Hmm... challenging. I guess this is one motivation for languages like Smalltalk to use an image, because they don't have to serialize code as source. Of course, I could use one of those pickle alternatives that knows how to pickle live objects; but that takes the project much further from normal Python. -- http://mail.python.org/mailman/listinfo/python-list
Editing a function in-memory and in-place
I got a puzzler for y'all. I want to allow the editing of functions in-place. I won't go into the reason (it's for HTConsole -- http://blog.ianbicking.org/introducing-htconsole.html), except that I really want to edit it all in-process and in-memory. So I want the identity of the function to remain the same, even as I edit the body and hopefully the signature too. Well, the reason is that I want to edit any function object, without having to know who has a reference to the function. This way editing a function or a method or a property.fget can all be done in the same way. The func_code attributes of functions is writable, but I don't know how to create the proper code object. Just compiling a new body isn't good enough. -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between CPython, Python for .NET and IronPython?
Claudio Grondi wrote: I have asked similar 'question' some weeks ago in the German Python newsgroup. It seems, that that Pythonistas have generally not much interest in IronPython waiting for at least release 2.0 of it which is _perhaps_ expected to support Mono. My understanding is that Mono developers are trying to make each release of Mono support whatever the last release of IronPython was. So there might be a lag, or you have to run a version behind, to use Mono. But it is supported. At least, I think I read something to that effect in the IronPython archives; I haven't tried it. My more vague impression is that most Python people are happy enough with CPython (because they better be happy, because that's what we've had), and at least people like myself dread nothing more than trying to install software or platforms. I suppose there's also a group who are interested in these interpreter/runtime level issues, but are working away on PyPy. PyPy has stolen away at least one major developer from Jython (though in all fairness I think he'd mostly left anyway). That said, I think concrete instructions on exactly how to get IronPython up and working -- for someone with no .NET experience or familiarity with that toolset -- would be an excellent way to bring more attention to IronPython from the existing Python community. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Being unjust
Kay Schluehr wrote: I'd be interested in what people think about bundling one of the diverse Python webframeworks with the Python distribution which will be just there as like Tcl/Tk+Tkinter for GUI-programming. Its not that I don't trust people to make qualified decisions on their own or that I actually believe in one single best solution. It's more a symbolic action of bundling forces and attention. I'm coming in a little late here, but I'll say that I don't think this makes any sense at this time. The Python web framework world this year looks totally different from what it looked like last year. It might be another year before Python 2.5 comes out. And who knows how long after that for the next release. That development timeframe doesn't match up at all. Not just kind of doesn't match up, but isn't even vaguely close. WSGI is stable, and perhaps some things directly related to that could go in. A WSGI HTTP server (probably based on SimpleHTTPServer) could go in. Maybe also a CGI version, maybe a forking version, maybe even FastCGI and SCGI. That wouldn't be bad, but it won't be a great benefit either. Normal people don't program directly to WSGI. So the person has to install other libraries to get by, at which point they might as well install the HTTP and other servers too. easy_install helps make it viable to install lots of things, and the benefits from that model extend well beyond web frameworks, and lets people work on their own timescale instead of relying on the understandably slow release schedule of Python itself. I think the standard library is only appropriate for solved problems, where the area is well understood. Just look at how much time it took to get decimal and datetime in, both of which cover *very* well understood areas. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: The builtins section should be moved to the language reference manual. The material it documents is part of the language definition, not part of an add-on library. the standard library is not an add-on. you're confused. I think the point is that there is the core language, and from a user's perspective builtins and statements and syntax are all the same thing. When you import a module, it's more-or-less obvious where you find information about the module (the module index, of course). But print, sorted, and list are all equally built in in the mind of a new user. And frankly, though with experience I understand the categorization, I don't find it particularly compelling. A new and improved language reference document should deal with all of these together, I think. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
A.M. Kuchling wrote: Here are some thoughts on reorganizing Python's documentation, with one big suggestion. Thanks for bringing this up... There are endless minor bugs in the library reference, but that seems unavoidable. It documents many different and shifting modules, and what to document is itself a contentious issue, so I don't think the stream of small problems will ever cease. Since the topic of php.net-style comments comes up often, I thought I'd note I've been working on a comment system: http://pythonpaste.org/comment/commentary/ -- this might be useful for collecting and managing small updates and fixes to the documentation. There's another struggle within the LibRef: is it a reference or a tutorial? Does it list methods in alphabetical order so you can look them up, or does it list them in a pedagogically useful order? I think it has to be a reference; if each section were to be a tutorial, the manual would be huge. Here I think the solution is to encourage separate tutorials and HOWTOs, and link to them from the LibRef. We don't have a clear place to put that material. People's personal pages leave the potential for material disappearing, and since that stuff usually doesn't have a clear license we can't necessarily be sure we can move it elsewhere if the original disappears or becomes out of date. The Wiki would probably work, and maybe we should just say that contributions on the Wiki are the preferred form for tutorials and howtos. Then, of course, we have to link to them. With a commenting system that can happen more organically. The library reference has so many modules that the table of contents is very large. Again, not really a problem that we can fix; splitting it up into separate manuals doesn't seem like it would help. There's a lot of dumb modules in there. I'd love if there was a module index that excluded modules that were not useful. Like, say, MimeWriter or flp. I think alphabetical or categorized doesn't matter that much, compared to just a shorter list. Or maybe categorized, but layed out so that it still all fits on one screen; the main library ToC is simply too long because it doesn't fit on a screen, but the categories can still be useful. I suspect the Achilles' heel of the docs is the Language Reference. Put aside the fact that it's not up to date with new-style classes and other stuff; that would be fixable with some effort. To some degree, the guide is trying to be very formal; it's written like a specification for an implementor, not a document that people would read through. But there's no other way for people to learn about all the special object methods like __add__; the tutorial can't cover them all, and the LibRef doesn't describe them. So the newbie is stuck. Definitely; there's a problem for a newcomer, where the language is documented one place (and hard to find), and the standard library someplace else. As a newcomer it can be hard to know which is which. Also, things like the functions in builtins are particularly hard to find IMHO. I usually use pydoc for these things now, but not because I particularly want to. Perhaps we need a friendlier counterpart to the RefGuide, something like the 20-page introduction to Python at the beginning of Beazley's Essential Reference: * go over the statements one-by-one * go over the basic types and their methods * go over object semantics * cover some of the lexical material in chapter 2 of the RefGuide * overarching principles: go into a fair bit of detail, but not every corner case; make the text readable, not meticulously precise. I think that an example-based reference could be more useful than the current layout. The corner cases *are* important, and it's valuable to be able to read documentation to fully understand one particular feature. Like, say, exceptions (which are undercovered right now). But it can be easier to understand those with a series of examples meant to demonstrate the behavior, than with a formal description. One problem with such a friendly document: it might make the Ref Guide even more irrelevant, if we always updated the friendly document (which is easy) and left the RefGuide to drift even further out of date (because it's hard to update). I don't know if this is an argument for not having a friendly guide, or for dumping the RefGuide entirely. Dumping the RefGuide means there isn't a more formal-style description of Python's semantics. I don't know if this matters. In theory, the implementors of Jython or IronPython could be using the RefGuide to know what they need to implement, but in practice I suspect implementors use the test suite and existing library as checks. Maybe we don't really need a tediously precise description of Python. A test suite seems far more useful to implementors than any guide, especially where the accuracy of that guide is
Re: Documentation suggestions
Fredrik Lundh wrote: I've proposed adding support for semi-automatic linking to external documents, based on a simple tagging model, a couple of times, e.g. http://mail.python.org/pipermail/python-list/2005-May/280751.html http://mail.python.org/pipermail/python-list/2005-May/280755.html http://effbot.org/zone/idea-seealso.htm I'm unclear what the workflow is that you are proposing. Given a seealso chunk, how does it get into the documentation? Do you submit it via the bug tracker, and a committer puts it in the repository, and the build process puts it into the HTML? Does it get submitted like a trackback, and the website automatically displays it without human intervention? Incidentally, I was noticing on microformats.org that they were talking about a rev attribute (http://www.microformats.org/blog/2005/12/01/rel-vs-rev/) which might work like: a href=http://python.org/doc/current/lib/module-atexit.html; rev=example And would be embedded in your page on that module. Then you might simply notify python.org that the page exists, and it would parse out the relation to the documentation based on this. Anyway, I was just reading about rev yesterday, so it came to mind, but it's otherwise an aside. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
Fredrik Lundh wrote: There's another struggle within the LibRef: is it a reference or a tutorial? Does it list methods in alphabetical order so you can look them up, or does it list them in a pedagogically useful order? I think it has to be a reference; if each section were to be a tutorial, the manual would be huge. Here I think the solution is to encourage separate tutorials and HOWTOs, and link to them from the LibRef. We don't have a clear place to put that material. People's personal pages leave the potential for material disappearing so ? this if we don't own it, we won't even pretend it exists attitude of the PSF is beginning to get a bit boring. Well, I ain't the PSF, so my comment here doesn't really indicate anything with respect to that. There are already links in the reference document to external documents. But if we start getting a half dozen links for each page (which is not an unreasonable number) the maintenance of trimming dead links and pages that are out of date becomes more significant. And there's no particular coordination, or any simple feedback process that can be applied to all content. I don't think there should be any policy discouraging external links; there's a lot of sources like the Python Cookbook, some free online books (e.g., Dive Into Python, or Think Like A Computer Scientist), and stable personal pages that should be linked in . But I do think that we should encourage some specific process for new or revised tutorial/howto contributions, like encouraging people put such material in the wiki. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
Aahz wrote: Here's a question that kind of gets to the heart of a lot of the problem: where does ``print`` get documented? If we can come up with a good process for answering that question, we can probably fix a lot of other problems. (Note emphasis on the word process.) Good point; the language reference and the tutorial is the only place we currently keep this kind of documentation, and neither provides the kind of reference that new users need. I'd also note that the distinction between builtins and syntax isn't meaningful to a new user. So, for instance, that exec and eval are documented in very different places is confusing. And that the print statement and the write method are also differently placed. I think it would be very useful if there was reference (not just tutorial) documentation for all the syntax, special semantics like magic methods, and all the functions and objects in builtins. To a new user these are all the same thing. Even to an experienced users these are all about the same thing. I don't think such a document would be all that long or hard to write. On a usability note, I'd want every name a user might encounter to show up in an index or table of contents. Basically all the keywords, magic methods, exceptions, builtin functions, builtin types, and at least somewhere the methods of builtin types should also be available. -- http://mail.python.org/mailman/listinfo/python-list
ANN: FormEncode 0.3
I'm pleased to announce FormEncode 0.3. What is it? --- FormEncode is a package for form validation and conversion. It also includes modules for parsing, filling, and extracting metadata from HTML forms. It features robust conversion both of incoming and outgoing data, attention paid to helpful error messages, and a wide variety of pre-build validators. It also supports composition of validators, and validating structured data, including nested and repeating form elements. FormEncode is being used in several projects, including Subway, TurboGears, and SQLObject. Where is it? Website and docs: http://formencode.org Download: http://cheeseshop.python.org/pypi/FormEncode What has changed? - From the news file: * Allow errors to be inserted automatically into a form when using ``formencode.htmlfill``, when a ``form:error`` tag isn't found for an error. * Added ``if_key_missing`` attribute to ``schema.Schema``, which will fill in any keys that are missing and pass them to the validator. * ``FancyValidator`` has changed, adding ``if_invalid_python`` and ``validate_python`` options (which also apply to all subclasses). Also ``if_empty`` only applies to ``to_python`` conversions. * ``FancyValidator`` now has a ``strip`` option, which if true and if input is a string, will strip whitespace from the string. * Allow chained validators to validate otherwise-invalid forms, if they define a ``validate_partial`` method. The credit card validator does this. * Handle ``FieldStorage`` input (from file uploads); added a ``formencode.fieldstorage`` module to wrap those instances in something a bit nicer. Added ``validators.FieldStorageUploadConverter`` to make this conversion. * Added ``StringBoolean`` converter, which converts strings like ``true`` to Python booleans. Bugfixes * A couple fixes to ``DateConverter``, ``FieldsMatch``, ``StringBoolean``, ``CreditCardValidator``. * Added missing ``Validator.assert_string`` method. * ``formencode.htmlfill_schemabuilder`` handles checkboxes better. * Be a little more careful about how ``Invalid`` exceptions are created (catch some errors sooner). * Improved handling of non-string input in ``htmlfill``. Experiments ~~~ * Some experimental work in ``formencode.formgen``. Experimental, I say! * Added an experimental ``formencode.context`` module for dynamically-scoped variables. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Chicago Python Users Group, Thurs Nov 10
November topics are Remote, Generic and Random, just like us. We'll have presentations on PyRO (Python Remote Objects) by Fawad Halim, generic functions (as implemented in RuleDispatch) by Ian Bicking, and the standard library random module by Robert Ramsdell. There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. We'll be meeting at 7 PM, Thursday November 10, in downtown Chicago at Performics 180 N. Lasalle 12th floor. RSVP is necessary for building security, email [EMAIL PROTECTED] with a subject of RSVP for ChiPy to be added to the list. If you aren't sure if you can come, email just in case. About ChiPy (http://chipy.org): ChiPy meets on the second Thursday of each month, at different locations around Chicagoland. If you are interested in goings-on, please subscribe to our mailing list: http://mail.python.org/mailman/listinfo/chicago -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Django Vs Rails
Diez B. Roggisch wrote: - rails/subway reflect over a existing table. They create OR-mappings based on that. You only specify exceptional attributes for these mappings. - django specifies the whole meta-model in python - and _generates_ the SQL/DDL to populate the DB. So obviously you have to be more verbose - otherwiese you won't have the fields you need. Subway is built on SQLObject, and SQLObject can both create tables and read schemas from an existing database. I don't know what style is preferred at the moment in Subway, but personally I always create my tables with SQLObject because I always end up enumerating all the features of the tables eventually anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: Django and SQLObject. Why not working together?
Bruno Desthuilliers wrote: Also, there's something like darwinism at play here. Yes, there are a lot of concurrent ORM/Templating/Web Publishing/GUI/Whatnot projects around, but I guess only the best of them will survive - eventually 'absorbing' what's good in the others. No, they will all survive. There's no pressure or reason why a software library won't keep surviving; some people -- if only the original author -- will write software using the library, and they'll be reluctant to abandon it, and not very motivated to change their software. The listings will live on in PyPI and on Wikis for a long time to come, well after active development has stopped. And, indeed, real development could start up at any time. For instance, both PyDO and MiddleKit were dormant for a long time before more recent activity. All software can go into periods of dormancy, because the individuals that write it have other things going on in their lives. It isn't necessarily death to the project. Which makes it all the more ambiguous what survival means. Ultimately I'm pessimistic -- while good features can be absorbed, bad features and dead libraries never go away, they just fade away very very slowly. It isn't natural selection. -- http://mail.python.org/mailman/listinfo/python-list
Chicago Python Users Group, Thurs Aug 11, 7pm
The Chicago Python User Group, ChiPy, will have its next meeting on Thursday August 11th, starting at 7pm. For more information on ChiPy see http://chipy.org Presentations - * Aaron Lav will talk about Unicode and middleproxy, a proxying web application that adds links to definitions of Chinese characters. * Ian Bicking will talk about distutils and setuptools -- how to use Python packages and how to make your own. * If time permits, Michael Tobis will talk on the pdb module, probably along with a symbolic debuggers, who needs 'em? discussion. There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. Location This month we will be meeting at Imaginary Landscape at 5121 N Ravenswood, on Chicago's North Side. Parking is available. See the website for more transportation information. About ChiPy --- This will be ChiPy's (cardinal number) meeting. We meet once a month, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Topic - Tutorial: Web programming in Python with Paste
Topic - Tutorial: Web programming in Python with Paste -- This month Ian Bicking will be presenting a tutorial Python web programming, using several different systems: Python Paste, Webware/WebKit, Zope Page Templates (not just for Zope!), and SQLObject. The technology covered will be similar to those presented in the To-Do tutorial. Except it will be live and in person. I (Ian) plan to develop a small application from scratch in front of everyone without preparation (or even forethought) -- you will get to gasp in disappointment or awe as I no doubt both embarrass and redeam myself. Hopefully this will present a realistic picture of what development is like with the stack, mistakes included. There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. Location This month Dave Rock and Acxiom will be hosting ChiPy in Downer's Grove: Acxiom Finley Road Downers Grove Near the intersection of I-355 and Buttefield Road. Convenient to Fry's! There's ample parking! Carpooling from the city? Check the mailing list. Links - ChiPy: http://chipy.org Mailing List: http://lonelylion.com/mailman/listinfo/chipy Python Paste: http://pythonpaste.org Webware: http://webwareforpython.org Zope Page Templates: http://www.zope.org/Documentation/Articles/ZPT1 SQLObject: http://sqlobject.org To-Do tutorial: http://pythonpaste.org/docs/TodoTutorial.html ChiPy meets once a month on the second Thursday. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Chicago Python Users Group, April 14
The Chicago Python User Group, ChiPy, will have its next meeting on Thursday, April 14th, starting at 7pm. For more information on ChiPy see http://chipy.org Michael Tobis, who is organizing this meeting, needs to give the building a list of names. If you think it's possible you will come, send email to [EMAIL PROTECTED] so he can put you on the list, and bring an ID. Presentation Topic: Subversion and Making Apples from Applesauce The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. Brian Fitzpatrick will tell us about how to use Subversion, the Python bindings, and about cvs2svn, which he was one of the leads on-- Fitz says that 'cvs2svn is the most difficult piece of code I've ever written--I'm going to write a paper for CodeCon next year about it called Making Apples from Applesauce. ' There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. Location This month we will be meeting again at the historic Monadnock Building in Downtown Chicago, at 53 W Jackson St. (in the loop at Jackson Dearborn). It is convenient to all CTA lines. Parking lots are available nearby, but expect to pay about $9. About ChiPy --- ChiPy meets once a month, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Chicago Python Group, Thurs March 10
The Chicago Python User Group, ChiPy, will have its next meeting on Thursday, March 10, starting at 7pm. For more information on ChiPy see http://chipy.org Presentations - This week we will have two presentations. Robert Ramsdell will talk about SimPy. SimPy (Simulation in Python) is an object-oriented, process-based discrete-event simulation language based on standard Python. It provides the modeler with components of a simulation model including processes, for active components like customers, messages, and vehicles, and resources, for passive components that form limited capacity congestion points like servers, checkout counters, and tunnels. It also provides monitor variables to aid in gathering statistics. Ian Bicking will be presenting on WSGI, WSGIKit, and Python web programming. WSGI is a new Python standard for interfacing between web servers (like Apache or Twisted) and web applications. WSGIKit is a reimplementation of Webware for Python using a series of WSGI components. He will be talking about its design and utilization of WSGI to create cross-framework libraries. Location This month we will be having our first suburban meeting, in Downer's Grove: Acxiom Finley Road Downer's Grove Near the intersection of I-355 and Buttefield Road. Convenient to Fry's! Parking is plentiful. Some people are carpooling from the city -- contact the mailing list if you are [EMAIL PROTECTED] About ChiPy --- We meet once amonth, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Prepending to traceback
Stefan Behnel wrote:
I want them to look like this:
Traceback (most recent call last):
...
File /usr/lib/python2.4/site-packages/pyparsing.py, line 456, in parse
loc,tokens = self.parseImpl( instring, loc, doActions )
File /usr/lib/python2.4/site-packages/pyparsing.py, line 727, in
parseImpl
raise exc
PyParsing, line 5, in SomeStatement
PARSER TEST FOR TESTING MISSING TERM
ParseException: Expected SOMEOTHERTERM (146), (5,9)
This query's a little old now, but I found this through the Weekly URL.
Anyway, Zope's ExceptionFormatter has one answer to this; you put a
local variable like:
__traceback_info__ = ('PyParsing, line %i, in %s\n %s'
% (line, statement, message))
And then that will show up in the traceback, much like you want. The
formatter looks through all the frames for this local variable and
prints it out when found. It's used in Zope for showing line numbers
and other information when its interpreting scripts like Zope Page
Templates or Python Scripts -- so that instead of just seeing the
traceback from the interpreter, you also see information about what the
interpreter is doing. This sounds similar to what you want.
It's pretty simple to use and it doesn't depend on the rest of Zope:
http://cvs.zope.org/Products/ErrorReporter/ExceptionFormatter.py?rev=HEADcontent-type=text/vnd.viewcvs-markup
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] SQLObject 0.6.1
SQLObject 0.6.1 --- Version 0.6.1 is a bug fix release for 0.6. Most of the work on this release has been thanks to the contributions of Oleg Broytmann. Thanks Oleg! A brief list of changes: * All class methods take a connection argument. * DISTINCT option for select results. * Connection objects have a new module attribute, to get access to the connection's exceptions. * New UnicodeCol() for encoding and decoding values from the database. * Added Indexing (patch from Jeremy Fitzhardinge). * Database connections explicitly closed, instead of just letting them be garbage collected. * selectBy can take be called with instances instead of only IDs for foreign key columns. * DBMConnection was removed (it's been broken a long time). What Is SQLObject? -- SQLObject is an Object-Relational Mapper. Basically it makes your database rows feel like (relatively) normal Python objects: Tables are classes, rows are instances, columns are attributes. SQLObject both allows you to define your classes in Python, and SQLObject will create the tables on your behalf, or SQLObject may use database reflection to dynamically create a class given a table name. SQLObject portably supports a variety of database backends: MySQL, PostgreSQL, SQLite, Firebird, MaxDB/SAPDB, and SyBase. SQLObject is being used in a variety of external projects: ezSQLObject, sqlo for Zope 3, and Subway (a Ruby on Rails clone), among others. Where Is SQLObject? --- Website: http://sqlobject.org News: http://sqlobject.org/docs/News.html#sqlobject-0-6-1 Documentation: http://sqlobject.org/docs/SQLObject.html Subversion repository: http://svn.colorstudy.com/trunk/SQLObject Mailing list: http://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://dir.gmane.org/gmane.comp.python.sqlobject Download: http://prdownloads.sourceforge.net/sqlobject/SQLObject-0.6.1.tar.gz?download -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: The best way to do web apps with Python?
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: You can read about it in Philip Eby's excellent PEP at http://www.python.org/peps/pep-0333.html I looked at this and I have the impression that it tries to do something worthwhile, but I can't tell precisely what. The rationale and goals section explains good reasons why it doesn't do various certain things. What's not explained is what DOES it do. The only thing I can tell is that it connects to an abstracted web server, and builds up what looks like traditional CGI variables from the incoming requests. It's really meant for web framework developers (as opposed to web application developers, who use web frameworks). Of course it's a fuzzy line, and people cross back and forth, especially since most all of it is open source. So basically it is what you were thinking -- it's a way to connect a web server to a web application, for any server or application, including current servers and applications (not just ones that are developed in the future). It can be a bit more interesting when you delve into middleware, which are programs that modify the request before handing it off to another application. But while that opens up interesting possibilities (I've used that technique a fair amount in WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/ ), but it's not incredibly magical. Mostly, it's the first forward movement we've had in a very long time, even if the movement isn't huge. It provides a foundation for further standardization. WSGI compliance also has some other potential benefits, like encouraging environment decoupling, and making mock requests easier to produce and responses easier to consume. But those are somewhat vague side effects. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: MoinMoin and Mediawiki?
Paul Rubin wrote:
Paul Rubin http://[EMAIL PROTECTED] writes:
How does it do that? It has to scan every page in the entire wiki?!
That's totally impractical for a large wiki.
So you want to say that c2 is not a large wiki? :-)
I don't know how big c2 is. My idea of a large wiki is Wikipedia.
My guess is that c2 is smaller than that.
I just looked at c2; it has about 30k pages (I'd call this medium
sized) and finds incoming links pretty fast. Is it using MoinMoin?
It doesn't look like other MoinMoin wikis that I know of. I'd like to
think it's not finding those incoming links by scanning 30k separate
files in the file system.
c2 is the Original Wiki, i.e., the first one ever, and the system that
coined the term. It's written in Perl. It's a definitely not an
advanced Wiki, and it's generally relied on social rather than technical
solutions to problems. Which might be a Wiki principle in itself.
While I believe it used full text searches for things like backlinks in
the past, I believe it uses some kind of index now.
Sometimes I think a wiki could get by with just a few large files.
Have one file containing all the wiki pages. When someone adds or
updates a page, append the page contents to the end of the big file.
That might also be a good time to pre-render it, and put the rendered
version in the big file as well. Also, take note of the byte position
in the big file (e.g. with ftell()) where the page starts. Remember
that location in an in-memory structure (Python dict) indexed on the
page name. Also, append the info to a second file. Find the location
of that entry and store it in the in-memory structure as well. Also,
if there was already a dict entry for that page, record a link to the
old offset in the 2nd file. That means the previous revisions of a
file can be found by following the links backwards through the 2nd
file. Finally, on restart, scan the 2nd file to rebuild the in-memory
structure.
That sounds like you'd be implementing your own filesystem ;)
If you are just trying to avoid too many files in a directory, another
option is to put files in subdirectories like:
base = struct.pack('i', hash(page_name))
base = base.encode('base64').strip().strip('=')
filename = os.path.join(base, page_name)
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: OT: MoinMoin and Mediawiki?
Paul Rubin wrote:
If you are just trying to avoid too many files in a directory, another
option is to put files in subdirectories like:
base = struct.pack('i', hash(page_name))
base = base.encode('base64').strip().strip('=')
filename = os.path.join(base, page_name)
Using subdirectories certainly keeps directory size down, and it's a
good idea for MoinMoin given the way MoinMoin uses the file system.
But for really big wikis, I think using the file system like that
isn't workable even with subdirectories. Plus, there's the issue of
how to find backlinks and how to do full text search.
If the data has to be somewhere, and you have to have relatively random
access to it (i.e., access any page; not necessarily a chunk of a page),
then the filesystem does that pretty well, with lots of good features
like caching and whatnot. I can't see a reason not to use the
filesystem, really.
For backlink indexing, that's a relatively easy index to maintain
manually, simply by scanning pages whenever they are modified. The
result of that indexing can be efficiently put in yet another file
(well, maybe one file per page).
For full text search, you'll want already-existing code to do it for
you. MySQL contains such code. But there's also lots of that software
that works well on the filesystem to do the same thing.
A database would be important if you wanted to do arbitrary queries
combining several sources of data. And that's certainly possible in a
wiki, but that's not so much a scaling issue as a
flexibility-in-reporting issue.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: The best way to do web apps with Python?
Steve Holden wrote: More ways than you can shake a stick at, but nowadays you should consider using WSGI if you want your code to be portable across many frameworks. The Web SIG worked very hard last year on defining this gateway interface, with the intention that it should become widely available, and implementations are available now on environments as diverse as mod_python and CherryPy. You can read about it in Philip Eby's excellent PEP at http://www.python.org/peps/pep-0333.html WSGI isn't really something an application programmer can use; or at least it's not likely to be a very satisfying experience if they do. I'm optimistic that at some point most of the actively developed Python web frameworks we have now will be ported to WSGI. Ultimately, I think WSGI should be something a more casual Python web programmer wouldn't even realize exists. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Exception report library
I've been using one of several systems to catch unexpected exceptions and log them (e.g., write to a file, display on web page, email me, etc). But many are built into a particular system, or have an interesting but incomplete set of features. E.g., many web frameworks have exception reporters (and the stdlib includes cgitb), but I want to handle non-web exceptions in the same way as exceptions from web requests, and that's not generally easy. So, I'm figuring there should be some generic library that does this. Does anyone have experience with one they could recommend? PyCrash comes to mind: http://pycrash.sourceforge.net/, though the XML output doesn't excite me (but the post-mortem debugging data is nice). py.test makes nice tracebacks with extra data as well, and cgitb is another option, though I've found the code to be poorly factored for reusability when I've looked at it in the past. Zope includes an otherwise-Zope-neutral ExceptionFormatter, which isn't terribly exciting, except that it does look for __traceback_info__ local variables and create reports with those inlined. Maybe there's something better that's packaged as part of a larger framework? Does anyone have good or bad experience with PyCrash? Localized application extensibility is really useful to me as well; for instance, in a web application I like to know who the logged-in user is, and all sorts of environment information, and there's no way to do that that is common to all the environments I'd like this to work in. On the reporting end configuration and hooks are also really useful; e.g., there's no general way to display an exception report on a web page, so a web framework would have to hook into it in some way as well. I feel like there must be something out there, since every Python programmer has to deal with this sort of thing to some degree...? -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Exception report library
Robert Brewer wrote: I've been using one of several systems to catch unexpected exceptions and log them (e.g., write to a file, display on web page, email me, etc). But many are built into a particular system, or have an interesting but incomplete set of features. E.g., many web frameworks have exception reporters (and the stdlib includes cgitb), but I want to handle non-web exceptions in the same way as exceptions from web requests, and that's not generally easy. ... I feel like there must be something out there, since every Python programmer has to deal with this sort of thing to some degree...? I feel that way, too, but haven't found it. I broke my webapp framework out of my ORM late last year, and quickly realized how small the core framework really is (22k, versus 250k for the web bits). Features like the logging handler could be provided as separate modules, rather than built into the Application object, and I've been meaning to get around to that. If we could put our many heads together, I think this would be doable for the stdlib. I'm not optimistic about a good exception handler in the standard library; development slows down a lot at that point, and it's not a reasonable candidate until it is designed and used (in part because of that slowdown -- if it's not mature, it is a diservice to the project to calcify the interface with such strong backward compatibility requirements). But anyway, hopefully multiple people/frameworks/projects could use such a library, done well, as a start. Here are the pieces of the framework, by the way, which might also benefit from some standardization (I was thinking about them all at once): 1. Thread-safe application state 2. Logging (+ exception handling) 3. Configuration data (reading from various sources) 4. Registry of Workers for getting things done on a schedule, possibly recurring 5. Registry of startup/shutdown functions 6. Registry of active user interfaces I think the first three are all good candidates for a standard. If we had a standard, thread-safe Application object, the rest could be registerable plugins for that. You'd basically register callbacks for app.startup and .shutdown methods to iterate over. Hmm... I'm confused by these bits. Are you talking about libraries for other parts of a web framework, besides exception handling? If so, you might want to look into WSGI and then discuss these things on the web-sig list (WSGI as a starting point; it doesn't specifically relate to many of these ideas, but provides a context in which to develop them). Some of these have been discussed there, like logging, configuration, and perhaps aspects of the registration you are thinking about. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Roman Suzi wrote: The term generic programming is too... er... generic. :) Nope. It is not generic. It has it's definition made by the co-author of STL - A.Stepanov. And the Boost C++ library (many of us know it as Boost Python) standardise on the approach, AFAIK. As you know, Python already includes a _lot_ of support for generic programming (a function that iterates over a sequence can easily process a list, or a string, or a tuple as input; a function that takes a file-like object can often work just as will with a true file object or a cStringIO object; etc.). So when you bring up generic programming, it's too easy to dismiss the comment because (1) it's too vague and (2) Python already does a lot of it. So, what is your term for the type of generic programming that Python doesn't yet support? Interfaces? Protocols? Adapters? Metatype hierarchies? Python could have honest support of concepts. Everything else will be available with them. Umm... this isn't helpful. Generic and concept are not terms that belong to Boost or STL or whatever. They are just words. Coining the term doesn't mean anyone else knows what it means, nor that anyone *should* know what they mean -- personally I get very suspicious of ideas that are based on redefined words, that tends to be a way of hiding complexity or fuzziness. But anyway, if you use these terms, you really must provide references, otherwise no one will know what you mean. Python could have honest support of concepts is simply an incomplete sentence. Python could have honest support of Concepts (url) would be more reasonable. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Ann: CherryPy-2.0-beta released
[EMAIL PROTECTED] wrote: Well, you can easily run CherryPy behind Apache (see http://trac.cherrypy.org/cgi-bin/trac.cgi/wiki/BehindApache). Since CherryPy provides a WSGI interface (although it's still experimental), you can also run your CherryPy app with any WSGI-compatible HTTP server (although I don't really see any advantage to doing this). In the future when more WSGI environments are deployed, I think the benefits will be nice. For instance, under WSGIKit (http://svn.colorstudy.com/trunk/WSGIKit) you should be able to create a file: # cherry_app.py: from cherrypy import cpg, wsgiapp from my_cherry_app import root_instance cpg.root = root_instance wsgiapp.init() # This variable name is automatically picked up: application = wsgiapp.wsgiApp Then your application would be available under cherry_app/ (wherever you happened to put that file in the URL space). Note that WSGIKit isn't a server itself, just a set of middleware that delegates to different applications. It occurs to me that it would be considerably cleaner if it looked more like this: from cherrypy import wsgiapp from my_cherry_app import root_instance application = wsgiapp.Application(my_cheery_app) Otherwise you can only run one CherryPy application in a process...? That would be very limiting. Anyway, the idea is you can deploy a CherryPy-based application fairly easily alongside other WSGI Python web applications. The particulars still need some work -- I don't like the little Python file used to put the pieces together -- but I think it's a good direction. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Continuations Based Web Framework - Seaside.
Steve Holden wrote: I did actually do some sort-of-related work in this area, which I presented at PyCon DC 2004 - you can access the paper at http://www.python.org/pycon/dc2004/papers/18/Setting_A_Context.pdf An audience member mentioned the Smalltalk and Scheme-based work on web continuation frameworks, and I was sorry my answer at the time seemed unduly dismissive. There are some interesting similarities, and though my own implementation is decidedly clunky I like to think the paper explains some of the advantages of maintaining state and why the back button is an obnoxious anachronism :-) I think the technique you talked about is an easier way to achieve a similar goal as the continuation-based frameworks. While using continuations for web applications is an interesting idea, I don't think it's been shown to be successful. It's certainly not something I'd want to implement on Python (even given the actual features to make it possible), and from what I've read of the Ruby projects that use it (Borges and Wee?), they aren't ready to implement production applications either. The technique you present could be implemented on any framework, right now, with the expectation that it would work in a production situation. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Continuations Based Web Framework - Seaside.
Kendall Clark wrote: Between this pressure (which isn't new, since as Steve points out, I was talking about this in Python community last year, and I wasn't nearly the first) and the growing popularity of Ruby on Rails, there's some small hint that Ruby is gaining on Python re: non-Java web app mind share. I think that's a v. important niche for Python and would like to see us remain strong there (though I've not *done* much about this, alas). I think that's probably true -- at least in terms of mindshare, even though that might not reflect on actual work done. But, Rails is really not a very experimental framework, and the existance of continuation-based frameworks for Ruby is an aside. If such frameworks happen at all for Python, I think they will be an aside as well. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 288 ponderings
Steven Bethard wrote: PEP 288 was mentioned in one of the lambda threads and so I ended up reading it for the first time recently. I definitely don't like the idea of a magical __self__ variable that isn't declared anywhere. It also seemed to me like generator attributes don't really solve the problem very cleanly. An example from the PEP[1]: def mygen(): while True: print __self__.data yield None g = mygen() g.data = 1 g.next()# prints 1 g.data = 2 g.next()# prints 2 I don't get why this isn't good enough: def mygen(data): while True: print data[0] yield None data = [None] g = mygen(data) data[0] = 1 g.next() data[0] = 1 g.next() Using a one-element list is kind of annoying, because it isn't clear out of context that it's just a way of creating shared state. But it's okay, work right now, and provides the exact same functionality. The exception part of PEP 288 still seems interesting. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks for Non-Content Oriented Web Apps
[EMAIL PROTECTED] wrote: There are great Python Web Application Framework. But most of them are meant for content oriented web apps. Is there something that can ease the development of application that are not content oriented(I call them NON CONTENT-ORIENTED WEB APPLICATIONS because I don't know what else to call them). Maybe you mean interactive web applications, as opposed to document-centric applications? But then, that's what most frameworks are really designed for. I mean the applications like, accounting, high volume data entry apps, where normally GUI clients have ruled. I know very high quality ERP and similar packages have been implemented in a web based environment. But problem is that they have been developed with the tools that were actually meant for content oriented apps like Zope, PHP, etc. Zope I'd say is content-oriented, though with a bit of imagination you can phrase these applications in terms of content. PHP and many other Python frameworks are process-oriented, meaning that each request just plain executes some code. Which is true of Zope too, but the basic metaphors in Zope are that a request displays the view of some object, which is a little more abstract way of looking at it. But is there some sort of framework or something that is actually meant for such web apps,application that make heavy use of forms, have very high amount of user interaction etc. Do you mean non-traditional web applications, ala gmail? Probably not, I think you are talking about certain framework concerns that most frameworks aspire to in some fashion, but actually achieve to differing degrees. PEAK addresses some of these, but in a UI-neutral way, and it's quite experimental (at least in the perspective of a whole application; as robust as the individual pieces may be, there's no real model for how to use it for a full application). There's other form processing libraries, but they all are experimental in a way. I developed FormEncode, which relates to some of this. Zope 3 has Schemas, which can be used for form generation and validation, and Plone has Archetypes. I don't think there's anything that's a Whole Package, but Zope 3 and Plone/Archetypes might be the closest (depending on what your vision is). What I am asking here may sound off beat, but I think, in todays world where web based solutions offers such a flexibility, we really need it. I also know that I am to ambiguous, but as is the characteristic of this wonderful community, talks that start as most abigous, transform in crystal clear. PS: I am a web developer, using PHP for living. I have been playing with python for a while. I found python is really a cool language(do I need to say that ;-)) with a really, really impressive collection of modules and frameworks. While developing a school information system, I felt the need of such a framework that makes developing of Non-Content Oriented Web-Apps easy. Eh, it just needs some clear direction for *any* kind of web apps, IMHO. But with what you are specifically asking for, I think it's just a Hard Problem that Is Not Yet Solved, though there is work being done and people are attacking it from different directions. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
John Roth wrote: I appreciate some of the motivation, but merely avoiding giving something a name doesn't seem like a laudible goal. Actually, it is a laudable goal. It's always easier to understand something when it's right in front of your face than if it's off somewhere else. Naming the function doesn't move it far away. It changes the order (you have to define it before you use it), and it introduces a name. The one motivation I can see for function expressions is callback-oriented programming ... Well, that's true, but that's a very global statement: when you pass a function into another routine, it's essentially a callback. Sure, technically. But I'm thinking of real use cases. One I'm familiar with is things like map and filter. These are generally better handled with list expressions (and MUCH more readable as such, IMHO). Another is control structures, ala Ruby or Smalltalk. IMHO, we have all the control structures we need -- while, for, if. Most novel control structures in Ruby or Smalltalk are just another take on iterators. The exception being callbacks, and perhaps some other lazy evaluation situations (though outside of what I think of as callbacks, I can't think of any lazy evaluation situations off the top of my head). So that's why I think callbacks are important; callbacks in the style of Twisted Deferred, GUI events, etc. Function expressions could get really out of hand, IMHO, and could easily lead to twenty-line expressions. That's aesthetically incompatible with Python source, IMHO. Anything can get out of hand; there's no way of legislating good style without restricting the language so much that it becomes unusable for anything really interesting. Even then it doesn't work: see COBOL as a really good example of good intentions gone seriously wrong. OK, I should go further -- even a two-line expression (i.e., an expression that contains meaningful vertical whitespace) is aesthetically incompatible with Python source. Which covers any anonymous function that is more powerful than lambda. I'm not arguing that it can be abused, but more that it isn't any good even when it's not being abused. Have you ever programmed in a language that does use anonymous functions extensively like Smalltalk? Yep, I've done a fair amount of Smalltalk and Scheme programming. I don't expect Python to act like them. I appreciate the motivation, but I don't think their solution is the right one for Python. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
David Bolen wrote:
Ian Bicking [EMAIL PROTECTED] writes:
The one motivation I can see for function expressions is
callback-oriented programming, like:
get_web_page(url,
when_retrieved={page |
give_page_to_other_object(munge_page(page))})
This is my primary use case for lambda's nowadays as well - typically
just to provide a way to convert the input to a callback into a call
to some other routine. I do a lot of Twisted stuff, whose deferred
objects make heavy use of single parameter callbacks, and often you
just want to call the next method in sequence, with some minor change
(or to ignore) the last result.
So for example, an asynchronous sequence of operations might be like:
d = some_deferred_function()
d.addCallback(lambda x: next_function())
d.addCallback(lambda blah: third_function(otherargs, blah))
d.addCallback(lambda x: last_function())
Steven proposed an ignoreargs function, and the partial function offers
the other side (http://www.python.org/peps/pep-0309.html). So this
would become:
d = some_deferred_function()
d.addCallback(ignoreargs(next_function, 1))
d.addCallback(partial(third_function, otherargs))
d.addCallback(ignoreargs(last_function, 1))
I'm not sure this is better than it is with lambda. It's actually
considerably less readable to me. Hmm... well, that makes me less
excited about those...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
John Roth wrote:
The syntax I prefer (and I don't know if it's actually been
suggested before) is to use braces, that is { and }.
In other words, an anonymous function looks like:
{p1, p2, p3 |
stmt1
stmt2
}
What's the advantage of something like that over the non-anonymous
equivalent:
def some_func(p1, p2, p3):
stmt1
stmt2
I appreciate some of the motivation, but merely avoiding giving
something a name doesn't seem like a laudible goal.
The one motivation I can see for function expressions is
callback-oriented programming, like:
get_web_page(url,
when_retrieved={page |
give_page_to_other_object(munge_page(page))})
The problem with the normal function in this case is the order of
statements is reversed:
def when_retrieved_callback(page):
give_page_to_other_object(munge_page(page))
get_web_page(url, when_retrieved=when_retrieved_callback)
Oh, and you have to type the name twice, which is annoying. For most
other functional programming constructs, list (and not generator)
comprehensions work well enough, and the overhead of naming functions
just isn't that big a deal.
I think this specific use case -- defining callbacks -- should be
addressed, rather than proposing a solution to something that isn't
necessary. Which is to say, no one *needs* anonymous functions; people
may need things which anonymous functions provide, but maybe there's
other ways to provide the same thing. Decorator abuse, for instance ;)
def get_web_page_decorator(url):
def decorator(func):
return get_web_page(url, when_retrieved=func)
return decorator
@get_web_page_decorator(url)
def when_retrieved(page):
give_page_to_other_object(munge_page(page))
Or even (given a partial function as defined in some PEP, the number of
which I don't remember):
@partial(get_web_page, url)
def when_retrieved(page):
give_page_to_other_object(munge_page(page))
It's okay not to like this proposal, I don't think I'm really serious.
But I do think there's other ways to approach this. Function
expressions could get really out of hand, IMHO, and could easily lead to
twenty-line expressions. That's aesthetically incompatible with
Python source, IMHO.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list
Chicago Python Users Group Meeting, Thurs Dec 9
The Chicago Python User Group, ChiPy, will have its next meeting on Thursday, December 9th, starting at 7pm. For more information on ChiPy see http://chipy.org Topic - This month's topic is testing and profiling strategies in Python. Chris McAvoy will talk about doctest. Brian Ray will talk about the hotspot profiler. Ian Bicking will be talking about py.test, a unittest alternative. Maybe John Roth will be able to talk about Fitnesse, a Wiki-based acceptance test system. There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. We also want to hold a post-meeting chat to talk about Python advocacy in the Chicago area, and ChiPy promotion. Location This month we will be meeting at Imaginary Landscape: 5121 N. Ravenswood Ave, Chicago It's close to the Ravenswood stop on the North Shore Metra line, and a modest hike from the CTA brown line (Damen stop) and red line (Argyle stop). Parking is available out front. See the website for a map. Buzz to come up. We're looking to do a meeting in the suburbs in February. If you have a venue we could use (in the suburbs or elsewhere, February or another month), please email the mailing list. We want to move the meeting around to make it possible for the people from the entire Chicagoland area to participate. About ChiPy --- Each month we try to pick a general topic, and people who can do presentations around that topic. The tentative topic for January is Jython. Presentations can be short, and need not be authoritative; have you done something in Jython you'd like to share? Tell us a little about it on the mailing list. This will be ChiPy's 7th meeting, give or take a few. We meet once a month, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy -- http://mail.python.org/mailman/listinfo/python-list
Re: Help With Hiring Python Developers
Yet Another Mike wrote: Ed Leafe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Allow offsite workers and you'll have all the candidates you want. Exactly. I'm 5 hours away in Rochester, NY, and might be interested And, if they are willing to go offsite, why not go to India and save lots of bucks? Trust issues? In general, Python requires you trust your programmers. People give Java grief about its restricted environment and static typing, but if you don't trust the programmer to do a good job, at least with Java they (maybe) can't mess things up as badly for everyone else working on a project. You can mess things up royally with Python. I like working with a language that respects my intelligence, but that's not without its costs. In general, Python rewards highly-skilled programmers with a considerably increased productivity. We talk about how Python is also easy to learn and maintain, and that's still true, but it doesn't mean that it evens out the differences in productivity between programmers. In fact, quite the opposite -- that it's easy to learn and maintain means that there's less risk in using a highly skilled, highly productive programmer; in other languages you risk being left with a program that only another highly skilled programmer can maintain. Also, Python encourages agile methodologies, even if you aren't explicitly trying to use agile methodologies. They just work well. They also work well when you can have a more intimate relationship between developer and project manager or customer. Hiring in India or elsewhere makes that intimate relationship harder to create. And frankly, Python is not the language for companies who expect mediocrity in their programmers, and I think that outsourcing is for companies that expect mediocrity. I don't mean to insult Indian programmers -- certainly there are Indian programmers who are just as good as a good programmer in the US, able to communicate well, able to work independently, able to judge tradeoffs, etc. But those aren't the cheap ones. This isn't just about nation of origin. Outsourcing is about turning programmers into a commodity, and you can only make a commodity out of something where quality isn't an issue. In the case of programming, that means you must expect the lowest common denominator of quality given the constraints. I think that's a stupid way to look at programming in general, but it's *way* more stupid with Python. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
Steven Bethard wrote: Ian Bicking wrote: class bunch(object): def __init__(self, **kw): for name, value in kw.items(): # IMPORTANT! This is subclass friendly: updating __dict__ # is not! setattr(self, name, value) Good point about being subclass friendly... I wonder if there's an easy way of doing what update does though... Update (and therefore __init__) allows you to pass in a Bunch, dict, (key, value) sequence or keyword arguments by taking advantage of dict's update method. Is there a clean way of supporting all these variants using setattr? class bunch(object): def __init__(self, __seq=None, **kw): if __seq is not None: if hasattr(__seq, 'keys'): for key in __seq: setattr(self, key, __seq[key]) else: for name, value in __seq: setattr(self, name, value) for name, value in kw.items(): setattr(self, name, value) That should match dict.update, at least from the 2.4 help(dict.update). I'm not sure that will work for updating from a bunch object; also, bunch objects could have a 'keys' attribute without being dictionaries. Do you get attributes from non-iterables through their __dict__? I don't care for that at all. Are bunch objects iterable? -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
Istvan Albert wrote: Steven Bethard wrote: The question is not how easy it is to write, but how many times it's going to get written. but with that logic we could create a standard looping construct called loop(x) that would stand in for for i in range(x): IMHO, that example is quite the opposite of what you are advocating. range() is a simple function, and one which could be written by anyone with little chance of flaw. Why not do: i = 0 while i x ... i += 1 ? The three arguments to range are all present (how valuable are a few defaults). It's more general. You can extend it and modify it easily. These are all the same properties of bunch. Easy things have value; maybe that applies here, but saying that it is easy is not the same as saying it isn't valuable. For instance, we now have the sorted function, equivalent to: def sorted(lst, *args, **kw): lst = list(list) lst.sort(*args, **kw) return lst People have been writing this function over and over. Only there are a few subtlely different ways you can implement it, and you'll never know which from the function name alone. dict's keyword argument constructor is similar. And maybe bunch is similar; at least, I'd argue for or against it based on that, not merely on how easy it is to reimplement. If the implementation is easy to explain, it may be a good idea. (import this) If it existed, I'd probably use it some where I'm currently using dictionaries (but where I don't want to give the data behavior), and I'd probably subclass it. Now, when it doesn't exist, I frequently implement the behavior in classes that have other logic as well, and I almost never use it without logic; I use dict() with its keyword argument constructor, and just suffer the quotation marks when I'm retrieving members. BTW, in class that look like bunch, I usually implement it like: class bunch(object): def __init__(self, **kw): for name, value in kw.items(): # IMPORTANT! This is subclass friendly: updating __dict__ # is not! setattr(self, name, value) def __call__(self, **kw): # I'm not entirely happy with this: new_values = self.__dict__.copy() new_values.update(kw) return self.__class__(**new_values) -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 and Python Regrets
[EMAIL PROTECTED] wrote: I just came across the slides for Guido van Rossum's Python Regrets talk, given in 2002. It worries me that much of my Python code would be broken if all of his ideas were implemented. He doesn't even like 'print'. Of course, I am not qualified to argue with Van Rossum about the direction of Python. When is Python 3000 expected to appear? Is there a list of expected incompatibilities with Python 2.3? Are serious Python programmers already taking care to avoid using Python features that may disappear in Python 3000? Python 3000 is kind of imaginary. It's a what-if: what if Guido could do whatever he wanted without worrying about backward compatibility? At one point Python 3000 and Python 3.0 were kind of the same thing (or the same plan -- neither are implemented or even thoroughly planned). Now they are separate ideas -- if you see references to Python 3.0, it also includes some backward incompatible changes and cleanup, like maybe input() will disappear, and integer division will go away, and things like range() will return iterators (and xrange goes away). But it's much more conservative, and presented as a more realistic plan. print will still be around. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
