Georg Brandl wrote:
Vertical spacing is IMHO pretty bad on this page. Everything
has the same distance from everything else. This makes under-
standing the structure of the page pretty hard.
The main content is the original zipfile.html from
http://www.effbot.org/lib/zipfile.html.
Only
(this is the main motivator behind my documentation and site efforts; we
should learn not to press control-enter when we mean enter.
anyway, what I intended to say was that we should work harder on lowering the
threshold for drive-by contributions; it should be possible for anyone to
notice a
Guido van Rossum wrote:
On this page, 8 of 30 entries have a 'new in' comment. For anyone with no
interest in the past, these constitute noise. I wonder if for 3.0, the
timer can be reset and the docs start clean again. To keep them backwards
compatible, they would also have to be
Bob Ippolito wrote:
I want binary all the time when I'm dealing with bitflags and such.
Of course, I'm trained to be able to read bits in hex format, but it
would be nicer to see the flags as-is. Even worse when you have to
deal with some kind of file format where fields are N bits long,
Alex Martelli wrote:
As you already suspected, I think a PEP is needed. The intent of
I'll be happy to write it, if it stands any chance.
basestring was to *only* be used as the base class for *built-in*
string types. Clearly what you're proposing is different (Decimal is
not built-in
Tony Meyer wrote:
Fredrik Lundh kicked off a surprisingly long thread when he proposed
that typing quit or exit in the interactive prompt actually exit
(i.e. raises SystemError)
SystemExit
def exit():
... print bye
# what is it?
exit
$ oops!
(However, one
M.-A. Lemburg wrote:
AFAIK, this is a first in the Python repository. Not
sure if it's such a good idea. Branching and tagging
doesn't work with external resources in Subversion,
so things can become inconsistent.
Also, what if you break the code in the berlios repo
or the server is not
Martin v. Löwis wrote:
My initial thought was that we could ask alpha testers to run this script on
their alpha builds, and report back, but it just struck me that the
buildbot
already builds stuff on a couple of interesting platforms.
Can buildbot deal with custom test/validation
Tim Peters wrote:
Yes. please. svn:externals should always pin to a specific revision
(or at least to a frozen tag). Updating to a new revision then is
just a propedit away (to change the revision number); ditto for
backing off to an older revision if the newer one has problems.
wasn't the
Neal Norwitz wrote:
Does that make sense? We would just need /f's script in SVN.
in python/Tools/something or sandbox/something ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
time to synchronize your activities a bit ?
Author: neal.norwitz
Date: Tue Jan 10 08:49:41 2006
New Revision: 42000
Added:
python/trunk/Lib/test/crashers/
python/trunk/Lib/test/crashers/README
python/trunk/Lib/test/crashers/coerce.py
I've been playing with automatic module discovery in an attempt to figure
out how complete the library reference really is.
I've created a simple script that tweaks the path to get rid of site-package
stuff, and then scans the path for python modules and extensions, and writes
the result to a
Neal Norwitz wrote:
I feel I'm lacking some link here: why do you think we should do that?
[EMAIL PROTECTED] ~/build/python/svn/clean-ish $ LC_ALL=de_DE ./python
import locale
locale.setlocale(locale.LC_ALL)
'C'
locale.setlocale(locale.LC_ALL, 'de_DE')
'de_DE'
I would have expected
Donovan Baarda wrote:
No, it's a fundamental goal: to support light-weight generation of rendered
markup directly from source code, to enable simple tools (CGI scripts, etc)
to be able to render reference documentation.
Python is run-time interpreted, but I don't think we need its
Thomas Wouters wrote:
Only in the most severe cases does it make sense to create a PEP
specifically to be rejected.
Yet if it isn't recorded, people will keep bringing it up. How about a
'rejected ideas' PEP for ideas that are right out no matter how people
argue? A single PEP, with
Ralf W. Grosse-Kunstleve wrote:
***Please*** make Python more selfish. Note that this is also an obvious
avenue
for significant performance increases. If self is implicit you don't have to
do
the dictionary lookup for self all the time as is the case now.
what dictionary lookup ?
/F
Neal Norwitz wrote:
In the past, we haven't checked in tests which are known to be broken.
There are several good reasons for this. I would prefer you, 1) also
fix the code so the test doesn't fail, 2) revert the change (there's
still a bug report open, right?), or 3) generalize tests for
Ralf W. Grosse-Kunstleve wrote:
what dictionary lookup ?
IIUC, self is first looked up in the local dictionary.
no, self is a local variable. self.x means that x is looked up in the in-
stance dictionary, though.
Please try the code below to see the performance impact.
oh, please. do
anyone knows anything about support for semantic markup ?
http://meta.wikimedia.org/wiki/Semantic_MediaWiki
not sure a full-blown RDF-in-wiki-syntax is really that optimal,
though ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
Neal Norwitz wrote:
No. %-formatting should always use the C locale. One should use
locale.format to get locale-aware formatting.
I know very little about locale's. /f assigned me a bug
http://python.org/sf/1391872 which suggests I run all the tests in a
different locale than C. I think
M.-A. Lemburg wrote:
I haven't followed the thread, so many I'm repeating things.
Has anyone considered using e.g. MediaWiki (the wiki used for
Wikipedia) for Python documentation ?
I'm asking because this wiki has proven to be ideally suited
for creating complex documentation tasks and
[David Goodger]
Could be. I don't see HTML+PythonDoc as a significant improvement
over LaTeX.
[Fredrik Lundh]
Really?
Yes, really.
Your reply makes it obvious that you don't understand the issues involved
here, nor how the goals address them.
(Snipping heavily below due to lack
(for those who follow non-python forums
make that those who don't follow
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis wrote:
Adal Chiriliuc wrote:
MSVC 7.1 and 8.0 malloc always uses the Windows heap functions
(HeapAlloc friends) if running on Windows 2000 or newer
(malloc.c and heapinit.c).
So it seems that for both Linux (gcc) and Win (msvc) the memory is
released to the operating
[EMAIL PROTECTED] wrote:
Fredrik make that those who don't follow
What might some of those non-python forums be?
assorted corners of the blogosphere, mostly. no time to dig up any explicit
references, since I'm preparing for a 650 km trip through a major snowstorm,
but searching
Aahz wrote:
Does that also include my suggestion about improving the startup message?
when newbies get to the point that they want to quit, chances are
that the message have scrolled out of sight. and if they only skim
the instructions, they'll probably get confused anyway... e.g.
Python
Noam Raphael wrote:
I'm not saying that practically it must be used - I'm just saying that
it can't be called a heuristic, and that it doesn't involve any fancy
overkill size hinting or history tracking. It actually means
something like this:
1. If you want to insert and the table is full,
Fernando Perez wrote:
In [1]: x='hello'
In [2]: x?
/.../
Docstring:
str(object) - string
Return a nice string representation of the object.
If the argument is a string, the return value is the same object.
I'm not sure what I find more confusing: a help system that claims
Guido van Rossum wrote:
Regarding the meme floating about the arrogance of Pythoneers:
bloggers (pretty much by definition) are actually the most arrogant
species; don't confuse bloggers say with most people think.
Sure, but I'm not only talking about the mindless ranters here; it's also
Guido wrote:
Not the first time this happened. :-(
Could someone add a unit test for this please?
Hye-Shik Chang just added the necessary tests to his bugfix patch. I'll
check this in later tonight.
/F
___
Python-Dev mailing list
David Goodger wrote:
however, given that the discussion that led up to this has been dead for
almost a week,
You mean since Christmas?
I'm beginning to fear that I've wasted my time on a project
that nobody's interested in.
Could be. I don't see HTML+PythonDoc as a significant
Martin v. Löwis wrote:
Please let me know what you think.
+1. in honor of the Bike Shed Effect, I'm going to assume that you've
thought of everything.
:::
well, one thing seems to missing from your PEP: in several modules, you've
changed the cast used in the type table. e.g.
---
Robey Pointer wrote:
[Fredrik Lundh]
Really?
Yes, really.
Just out of curiosity (really -- not trying to jump into the flames)
why not just use epydoc? If it's good enough for 3rd-party python
libraries, isn't that just a small step from being good enough for
the builtin libraries
Martin v. Löwis wrote:
In short, I think it makes a lot of sense to support a bare exit and/or
quit as a completely intuitive platform-independent newbie-friendly way to
exit the interpreter.
I can readily agree to this part of Fredrik's proposal. What slightly
bothers me is the hackish
Jeremy Kloth wrote:
Ka-Ping Yee wrote:
I'd be happy with having Python exit when the user types just plain
'exit' without parentheses, but only in that case, not others.
However, i'm starting to think that may be impossible to implement.
I can't think of any way to make 'print exit' not
Martin v. Löwis wrote:
Introducing sys.commandline is fine; overriding sys.excepthook
still worrisome.
What's wrong with triggering this in some __repr__ implementation?
because simple introspection may exit your program. unexpected
exits are a lot more annoying than unexpected non-exits.
someone recently broke floating point literals in a rather spectacular
way:
$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
Type help, copyright, credits or license for more information.
3.14
3.1401
import locale
locale.setlocale(locale.LC_ALL, )
Michael Hudson wrote:
In other news, clever hacks with tb_next and so on also seem
excessive. Why not have the equivalent of if input.rstrip() ==
'exit': sys.exit() in the implementation of the interactive
interpreter?
that would turn exit and quit into reserved keywords.
/F
Michael Hudson wrote:
that would turn exit and quit into reserved keywords.
In what sense? Not in the sense of things in single quotes in
Grammar...
no, but in the sense of names that can no longer be used in code
def exit():
... print bye
# what is it?
exit
Walter Dörwald wrote:
We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
sys.inputhook gets passed each line entered and may return True if it has
processed the line inself and False if normal handling of the input should be
done. This allows special treatment of quit,
Guido van Rossum wrote:
but now we're back to today's situation:
quit
'Use Ctrl-Z plus Return to exit.'
which violates the basic if you know what I mean, why the /!/!//%¤
don't you do what I say usability rule.
What nonsense. Every Python programmer knows that the right
sourceforge just went off the air, so I'm posting this patch here, in order
to distract you all from Christian's deque thread.
this silly little patch changes the behaviour of the interpreter so that quit
and exit actually exits the interpreter. it does this by installing a custom
excepthook
Aahz wrote:
class file(object)
| file(name[, mode[, buffering]]) - file object
|
| Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
[...]
| Note: open() is an alias for file().
This is confusing. I suggest that we make ``open()`` a factory function
right now.
Neal Norwitz wrote:
And hopefully of interest to many here:
http://docs.python.org/dev/results/
These are the results of svn update, configure, build, test, install
and the doc run.
the trunk link on
http://www.python.org/dev/doc/
still points to the old
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at it ?
Why a new factory function ? Can't we just redirect to codecs.open()
in case an encoding keyword argument is passed to open() ?!
I think open is overloaded enough as it is. Using separate functions
Reinhold Birkenfeld wrote:
What is wrong with something like this:
class Quitter:
... def __repr__(self): raise SystemExit
...
exit = quit = Quitter()
vars() # oops!
/F
___
Python-Dev mailing list
Python-Dev@python.org
Phillip J. Eby wrote:
Here's a rough draft:
def textopen(name, mode=r, encoding=None):
if U not in mode:
mode += U
if encoding:
return codecs.open(name, mode, encoding)
return file(name, mode)
Nice. It should probably also check
Ronald Oussoren wrote:
Why must quit and exit be so special in the first place? They could
be plain functions, or even something like::
class _QuitOrExit:
def __init__(self, name):
self.name = name
def __repr__(self):
return Use %(name)s() to exit.%(self.__dict__)
def __call__(self):
Phillip J. Eby wrote:
but that was made at a time when it wasn't clear if open or file would
be the preferred way to open a file. now that we've settled on the verb
form, I think textopen or opentext would be slightly more consistent.
Sorry, I'm confused. Who settled on the verb form? Are
[EMAIL PROTECTED] wrote:
Fredrik whaddya think?
We're going to wind up with the same problem that spawned the atexit module:
multiple code sources wanting to fiddle with sys.excepthook step on one
another's toes.
in this case, I'm not sure it matters that much. if you add your own
Hans Nowak wrote:
My point is that there is currently no acceptable, universal way to exit
the interpreter. Again, it's not that big of a deal... but it seems
silly that something apparently trivial like that cannot be done right.
it's the usual problem: getting enough developers to agree
Adal Chiriliuc wrote:
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type help, copyright, credits or license for more information.
exit
'Use Ctrl-Z plus Return to exit.'
I've just tried Ctrl+Z (plus Return) and some variations on Win XP and
it doesn't
Ka-Ping Yee wrote
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin.
no, what's being proposed is what the subject says: a quit/exit command
that actually quits, instead of printing a you didn't say please! message.
/F
Ka-Ping Yee wrote:
Fredrik's NameError-based proposal (exit when there's an exception
with no tb_next that says name 'exit' is not defined) causes the
interpreter to quit when you enter any expression involving 'exit'.
print exit # seems surprising
[3, 4, 5, exit]
as seen on the doc-sig:
javadoc's
[EMAIL PROTECTED] os.popen}
is even shorter.
hmm. maybe a combination of rest/html/whatever and pythondoc markup
would be the ultimate tool for the library reference...
* heavy clapping sound of my footsteps while running away
Martin Blais wrote:
So, definitions of functions, classes, and other structured stuff would
just use fields under a directive, and references to those definitions
would just be reST links.
So you end up with a document with a bunch of custom directives, like::
.. python-class:: MyClass
Reinhold Birkenfeld wrote:
I can only speak for my own experience, but maybe it will help. I
once tried to help fix a piece of the python docs. The description
of Py_UNICODE on http://docs.python.org/api/unicodeObjects.html was
-- and still is -- incorrect.
The current docs were
Ian Bicking wrote:
This is somewhat tangential to this discussion, but I did have the
Python documentation in mind as a potential future target for
Commentary: http://pythonpaste.org/comment/commentary/ -- which would
allow more casual contributions that seem to work well for other projects.
Michael Chermside wrote:¨
Me too. Specifically, I think if you make it really easy to write notes
on the docs you will get some helpful documentation content. You will
also get lots of things that are too lengthy or exhaustive, to specific
to one person's problem, helpdesk style questions,
Martin v. Löwis wrote:
If you just want to know what your changes look like: type make html
in the Doc directory, and wait a moment for it to complete. I get
xml.etree as section 13.13.
provided you have all the right stuff on your machine, that is:
$ make html
TEXINPUTS=...
+++
Josiah Carlson wrote:
-1 for choosing something not ReST or latex.
yeah, because using something that everyone else uses would of course
not be the python way.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Phillip J. Eby wrote:
(as I hinted, I'd prefer HTML with microformat annotations as the main
format;
with roundtripping to markdown or rest (etc) for people who prefer to
author in that, and tidy-xhtml-python tools for the HTML generation)
I don't see how HTML is any lighter than LaTeX -
Fred L. Drake, Jr. wrote:
LaTeX, for all the tool requirements, is a fairly light-weight markup
language. Yes, it has too many special characters. But someone else
invented it, and I'm not keen on inventing any more than we have to.
someone else invented it is of course why I'm advocating
Josiah Carlson wrote:
yeah, because using something that everyone else uses would of course
not be the python way.
No, because ReST is significantly easier to learn and use than basically
every other markup language I've gotten my hands on.
I'm not really interested in optimizing for you,
Barry Warsaw wrote:
Sorry, but HTML and (even more so) XML are not human-writable. :) Yeah,
we can all do the simple stuff, but I absolutely hate authoring in HTML,
and it would be a nightmare if the documentation production system
didn't handle lots and lots of magic for you (like weaving
Barry Warsaw wrote:
Sure, and some people hate using whitespace for block structure.
A more proper analogy would be people who hate braces and parentheses.
You have to type so many more and characters (not to mention s
and ;s) to make happy-joy html than you have to type \s and {s and }s
Phillip J. Eby wrote:
And where characters like '' and '' occur frequently as part of the text,
especially in showing Python interactions like this:
print hello world
hello world
I can't imagine trying to author the above in an HTML/XML based format,
it's spelled
print
Steve Holden wrote:
That's embarrassing, by the way. You're obviously having a bad
spelling day :-)
I'd say that any spelling with more than 500,000 google hits is perfectly
valid...
/F
___
Python-Dev mailing list
Python-Dev@python.org
the Documentation Development page at
http://www.python.org/dev/doc/
contains a link to a SVN trunk version which was last updated nearly
four months ago. what would it take to automatically update the trunk
docs, say, once a day or so ?
or is it time to move away from the current
Steve Holden wrote:
I'd say that any spelling with more than 500,000 google hits is perfectly
valid...
Anything you say, Frederick ...
thirteen-million-google-hits-can't-possibly-be-wrong-ly y'rs - steve
oh, frederick is a perfectly valid english spelling of the germanic name
Friedrich,
Neal Norwitz wrote:
I'm not sure where the problem is, but this code leaks a reference:
parser = ET.XMLParser() ; parser.feed('xtext/x')
You need this to set it up:
from xmlcore.etree import cElementTree as ET
This isn't a memory leak according to valgrind.
looks like it's stealing
$ svn up
At revision 41759.
$ make
...
Python/compile.c: In function `PyNode_Compile':
Python/compile.c:301: parse error before `mod'
Python/compile.c:302: `mod' undeclared (first use in this function)
Python/compile.c:302: (Each undeclared identifier is reported only once
Martin v. Löwis wrote:
I have now installed this hook to allow editing svn:log; please try
again.
$ svn propedit --revprop -r 41759 svn:log
Set new value for property 'svn:log' on revision 41759
thanks! /F
___
Python-Dev mailing list
Armin Rigo wrote:
What about having instead:
sys.build_info = (CPython, svn rev, trunk)
This would make it clear that it's the CPython svn rev number, and it
could possibly be used to distinguish between branches, too, which the
revision number alone cannot do. (trunk is the last part
Phillip J. Eby wrote:
I have not found any way to establish a stable revision number for a
directory tree in Subversion except by using -R and Last Changed Rev (or
the equivalent scanning of .svn/entries files). Through my experience
working on setuptools in the sandbox, it is clearly
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone have a better idea ?
I was under the impression that simply
Fred L. Drake, Jr. wrote:
On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote:
+1; it's what should have been done in the first place.
If only I'd understood that when I added the xml/PyXML hack to the stdlib
years ago. :-(
Fixed now. I'll deal with the documentation in a few days;
you also broke my subversion:
$ svn up
svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt ||
cstr' failed.
Aborted
(but that's probably not your fault).
has anyone seen this error? any ideas on how to fix it?
google indicated that people had seen this when
Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought the answer to that was always no.
I thought so too, but
I wrote:
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
I've implemented this, for now.
can anyone with a working windows setup look at building the
M.-A. Lemburg wrote:
Some questions:
* Are you going to contribute cElementTree as well ?
yes, but there are some build issues we need to sort out first (both pyexpat
and cET link to their own copies of expat)
we also need to figure out how to import the bundled version; should it be
BTW, what's the policy wrt. Jython-specific modules in the standard library?
Expat isn't available under Jython, but I have a Java/Jython-driver for
ElementTree
on my disk. Can / should this go into the CPython standard library ?
/F
___
I wrote:
1. add an Include/pyexpat.h header file which contains a structure
similar to the following:
2. during pyexpat initialization, initialize all members of this structure,
and
make it available as a PyCObject:
3. in cElementTree (or _elementtree, or whatever the python version will
Michael McLay wrote:
Avoiding imaginaary name collisions and putting cElementTree into the xml
package
there's nothing imaginary here -- cElementTree is an existing and quite popular
module, and will remain available as a separate distribution.
it would be nice if people could install that
looks like you need to have a recent Python version installed
to be able to build the current trunk:
./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl
./Parser/asdl_c.py:150: SyntaxWarning: local name 'self' in
'sum_with_constructors' shadows use of 'self' as global in nested
Jeremy Hylton wrote:
The C files are checked into subversion. Perhaps there is some
problem with the timestamps that causes the Makefile to try to rebuild
them anyway? I have a modern Python and I've been doing a fair amount
of development on these files; as a result, I haven't noticed a
the xml/__init__.py file contains a cute little hack that overrides
the *entire* xml subtree with stuff from PyXML, if available.
the code basically does
import _xmlplus
sys.modules[__name__] = _xmlplus
(exception handling and version checks not shown).
however, this means that as
Brett Cannon wrote:
maybe the right thing here would be to change this to
#!./python
Generate C code from an ASDL description.
and only run the script if ./python has been built ?
What if you build with a different suffix for the executable? Or do
different versions of
[EMAIL PROTECTED] wrote:
BTW, there is one project I'm theoretically familiar with that attempts to
handle the dual source situation: XEmacs. I'm still trying to come to terms
with the practical issues involved. I'm supposed to be updating the
python-mode code, and am only taking baby steps
Martin v. Löwis wrote:
That's primarily for the author of the software to decide, at this
point. Fredrik Lundh would have to offer it for contribution first.
I've already done that, as others have noted. Everything I release
under a Python-compatible license is available for bundling
Martin v. Löwis wrote
And maybe PEP 291 could be updated to cover both compatibility with older
Python versions and other compatibility issues.
So what would be the minimum Python version you keep compatibility with?
as Brett pointed out, the procedure to use for externally developed and
Delaney, Timothy (Tim) wrote:
Nick Coghlan wrote:
As Fredrik pointed out a while back, the PyObject approach doesn't
*have* to involve manual decref operations - PyObject's come with a
ready made arena structure, in the form of PyList.
That doesn't really work: PyList_Append (which
Nir Soffer wrote:
However, I found this alarming note in the docs:
normpath(path)
...
It should be understood that this may change the meaning of the path
if it contains symbolic links!
The function docstring does not contain this note:
Normalize path, eliminating double slashes, etc.
Martin v. Löwis wrote:
One way (I think the only way) this could happen if:
- the objects being allocated are all smaller than 256 bytes
- when allocating new objects, the requested size was different
from any other size previously deallocated.
So if you first allocate 1,000,000 objects
Donovan Baarda wrote:
I don't know if this will help, but in my experience compiling re's
often takes longer than matching them... are you sure that it's the
match and not a compile that is taking a long time? Are you using
pre-compiled re's or are you dynamically generating strings and using
Neal Norwitz wrote:
I think a bigger bang for the buck would be to buy a Windows box with
Purify. Rational was a real pain to deal with, maybe it's better now
that IBM bought them. Parasoft (Insure++) was even worse to deal
with. There would be many other benefits for someone to do more
Martin v. Löwis wrote:
The same could be said about hotshot, which was originally contributed
by Fred Drake, and hacked by Tim Peters, yourself, and others. Yet, now
people want to remove it again.
I'm really concerned that the same fate will happen to any new
profiling library: anybody but
Travis Oliphant wrote:
Bingo. Yes, definitely allocating new _types_ (an awful lot of them...)
--- that's what the array scalars are: new types created in C.
are you allocating PyTypeObject structures dynamically?
why are you creating an awful lot of new type objects to represent the
Travis Oliphant wrote:
The fact that it did happen is what I'm reporting on. If nothing will
be done about it (which I can understand), at least this thread might
help somebody else in a similar situation track down why their Python
process consumes all of their memory even though their
Michiel Jan Laurens de Hoon wrote:
Did you read my reply? ipython, based on code.py, implements a few simple
threading tricks (they _are_ simple, since I know next to nothing about
threading) and gives you interactive use of PyGTK, WXPython and PyQt
applications in a manner similar to
401 - 500 of 622 matches
Mail list logo
