"AB" == Anthony Baxter [EMAIL PROTECTED] writes:
AB Now, it's obvious that not all of these are bad - some are
AB probably fine - but there's also many that are _not_ good. The
AB one in MailHost.py does eat exceptions. I'm sure there are
AB others.
I am probably a bit idiosyncratic,
"CW" == Chris Withers [EMAIL PROTECTED] writes:
I am probably a bit idiosyncratic, but I prefer to avoid bare
excepts at all costs. I often use "except Exception:", otherwise
I add a
CW Will that catch string exceptions? eg: raise 'Something bad
CW happened'
No.
CW If not,
AB == Anthony Baxter [EMAIL PROTECTED] writes:
AB Any known gotchas with running ZEO server and ZEO client on
AB boxes of different endianness? e.g. the server running on sun
AB solaris/sparc, while the clients are on x86 linux boxes.
AB I'd expect it to be fine, but am feeling
Since a single Python process has a single global interpreter lock,
you'll never fully utilize a 2-processor machine. The lock is
released whenever a socket call (send, receive, listen, etc.) is made,
so that provides some opportunity for using two CPUs, but not much.
Jeremy
MTK == Matthew T Kromer [EMAIL PROTECTED] writes:
MTK For what its worth, I tracked this down in the sources and
MTK confirmed that in Zope 2.3, we shipped a modified asyncore.py
MTK with Medusa that handled EINTR, but in Zope 2.4 we used stock
MTK Python's asyncore which does NOT
JZ == John Ziniti [EMAIL PROTECTED] writes:
JZ Replace your Python 2.1.1 asyncore.py with the one that is
JZ attached. I've been using it for months now with no problems.
JZ Notice, however, that it doesn't work on WinNT, b/c the author
JZ didn't know what EINTR looked like on NT
The
CM == Chris McDonough [EMAIL PROTECTED] writes:
CM Ah ok... yeah, there were reportedly several leaks in the
CM compiler stuff that have been fixed in CVS. I imagine that's
CM what this is.
Actually, I don't think the leaks haven't been fixed in CVS. It would
be at best painful to try
Could you just undo enough transactions to get back to the old state?
Or do you need to keep some of the changes you made?
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
I don't know if a tool exists either. I think something quick could
be hacked together, but I doubt I'd have time to do it anytime soon.
I don't know if you up for some programming to accomplish this goal or
not.
There are a couple of ideas I have along these lines in case you or
someone else
LR == Lennart Regebro [EMAIL PROTECTED] writes:
LR I found seceral seemingly up to date docuemnts claiming that
LR both PersistentMapping and PersistentList exists and is included
LR with Zope. However, I couldn't find PersistentList, so I
LR thought that it had been added after 2.3.3,
AJ == Andreas Jung [EMAIL PROTECTED] writes:
AJ Does this problem persist when you remove the 3rd-party products
AJ ? Are you running Zope with enabled garbage collector ?
Just a reminder that you *should* be running with the garbage
collector enabled. We are aware of no current bugs in
Python 2.1.2 has some extra safety checks that will immediately detect
the stack overflow bugs that caused problems with PythonScripts before
2.4.4. The fact that you're seeing crashes in the garbage collector
and not assertion failures in Python/ceval.c makes me think the
problem isn't with the
On Mon, 4 Mar 2002 11:01:22 -0500
Andrew Sydelko [EMAIL PROTECTED] wrote:
For some reason, when I try to view the Version
Management screen
under Control Panel, I get a bunch of gibberish for one
of the versions...
And... it won't let me click on the check box and
Discard it... Is there
On Mon, 4 Mar 2002 11:11:55 -0500
Andrew Sydelko [EMAIL PROTECTED] wrote:
On Monday 04 March 2002 11:08, you wrote:
On Mon, 4 Mar 2002 11:01:22 -0500
A low-level way to get a list of versions is to call
the
versions() method on the storage object. Example:
from
I have just released ZEO 1.0 beta 6. It's been almost six months
since the last beta release, so it was surely time. This release
fixes two bugs that Zope Corp. has recently run into in the field.
See http://www.zope.org/Products/ZEO/.
Here are the changes:
- Fixed a bug that could cause
I am happy to announce that ZEO 1.0 final was released today.
Zope Enterprise Objects (ZEO) provides the ability for multiple
processes to use a single Zope Object Database. ZEO turns the Zope
object system in a distributed architecture, allowing multiple
processors, machines, and networks to
CM == Chris McDonough [EMAIL PROTECTED] writes:
Completely agreed. My disagreement is portraying the counter
problem as impossible with the zodb. I think some people, as
evidenced by some of the responses, are willing to live with the
tradeoffs. Other people will find managing a
The documentation for ZEO contains the following note about product
installation. The final sentence suggests that we intend to fix it,
but I don't understand the problem exactly or whether it has been
fixed.
Can anyone tell me if this warning is still relevant?
Jeremy
Zope product
AS == Andrew Sydelko [EMAIL PROTECTED] writes:
AS Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to
AS come up fine, but when trying to start the ZEO client it pretty
AS much sucked.
It looks like you would have had the same problems without ZEO. It
would be helpful if you
AS == Andrew Sydelko [EMAIL PROTECTED] writes:
AS On Tue, 18 Jun 2002 11:20:21 -0400 Jeremy Hylton
AS [EMAIL PROTECTED] wrote:
AS == Andrew Sydelko [EMAIL PROTECTED] writes:
AS Trying Zope 2.6.0a1 and ZEO 2.0a1. The storage server seemed to
AS come up fine, but when trying
AS == Andrew Sydelko [EMAIL PROTECTED] writes:
Failed to import class Splitter from module
Products.PluginIndexes.TextIndex.Splitter.ZopeSplitter
When I import Products...ZopeSplitter, I see a module with a
Splitter attribute bound to a function.
AS I don't understand what
AS == Andrew Sydelko [EMAIL PROTECTED] writes:
AS Can someone tell me exactly how to compile python 2.1.3 with LFS
AS support?
I don't have the URL handy, but it's section 8.1.1 of the manual
IIRC. Look for large file support in the library reference.
Worked for me without problem on a
JW == Joachim Werner [EMAIL PROTECTED] writes:
JW Hi! I have a really large Data.fs file (1.3 GB) that has a
JW number of errors. When I run the fstest.py script, I get this:
JW Problem: 109963117 object serialno 0x034573c4b6a2cb6e does not
JW match transaction id 0x034573c55c8c0dbb
TD == Toby Dickenson [EMAIL PROTECTED] writes:
although we may do one more beta release to add some performance
improvements.
TD Do you have something specific in mind?
I'd like to change this bit of code in handle_write():
if n len(v):
# XXX It's
TD == Toby Dickenson [EMAIL PROTECTED] writes:
TD There is an O(n) option with easy logic... fragment big strings
TD inside message_output.
Sounds like a possibility. It would still be nice to have something
in handle_write() to avoid extra slicing on partial send()s. But your
patch is
LRA == Leonardo Rochael Almeida [EMAIL PROTECTED] writes:
LRA The last two installations belong to the same client, and are
LRA both experiencing a problem that I believe is related to ZEO
LRA latency. Both sites depend heavily on a single ZCatalog for
LRA operation (one ZCatalog hit in
SHH == Stefan H Holek [EMAIL PROTECTED] writes:
SHH Hi All! I am experiencing a lot of 'ZODB conflict error at
SHH ...' that I can reliably reproduce by hitting my browser's
SHH Refresh button at a high rate. The bad news is that the
SHH conflicts happen on pages that are not supposed
I have posted a tenative release plan for ZODB 3.2 in the ZODB Wiki at
http://www.zope.org/Wikis/ZODB/ZODB%203.2%20Release
There are a small set of proposed features centering around better
configuration and management of ZEO and ZODB.
Feedback is welcome.
Jeremy
TD == Toby Dickenson [EMAIL PROTECTED] writes:
TD On Tuesday 05 November 2002 7:04 pm, Jeremy Hylton wrote:
I have posted a tenative release plan for ZODB 3.2 in the ZODB
Wiki at http://www.zope.org/Wikis/ZODB/ZODB%203.2%20Release
There are a small set of proposed features
We recently discovered that ZODB3 applications, like Zope 2.6, can
deadlock when run in a system that uses multiple storages. This was a
fundamental design flaw in ZODB that, happily, has a simple fix.
Brian and I are planning to commit these changes to the ZODB3 3.1 and
Zope 2.6 release
JPS == Jeffrey P Shell Jeffrey writes:
JPS What about ``if callable(aq_base(newKeywords)):`` to remove
JPS potential acquisition wrappers?
callable() returns True for any instance. Since PersistentList is an
instance, you can't use callable() to determine whether it is
callable.
Jeremy
I used distutils sdist to build the releases for ZEO and ZODB. I let
distutils pick the file extension.
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
It must be any instance of an ExtensionClass. I think Python
instances used to be true-for-callable as well, but that must have
been fixed.
Python 2.1.3 (#5, Aug 15 2002, 10:41:31)
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type copyright, credits or license for more information.
from
TD == Toby Dickenson [EMAIL PROTECTED] writes:
TD A bug in the transaction manager would be really bad news. I
TD would have thought it appropriate to resolve these problems and
TD leave at least a few weeks of beta test before release.
I'm looking into the problem, as I reported on
We have made a beta release of ZODB 3.1.1 and ZEO 2.0.1. The primary
change is a fix that allows transactions with multiple databases to
run without deadlock.
These release will correspond exactly to Zope 2.6.1b1, which will also
be released today.
See
SH == Shane Hathaway [EMAIL PROTECTED] writes:
SH On Wed, 11 Dec 2002, Evan Simpson wrote:
I think I've fixed my ZGlobals, but there's definitely a problem
in coptimizations. I made Connections.py use the Python
persistent_id, restarted twice, and ZGlobals was fine on the
second
I'll have to take a look, but may not get to it today. FWIW I thought
I fixed the bug on Friday. I could certainly create ZClasses through
the web without getting any obvious errors.
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
The nice thing about fixing this bug is that the code continues to be
improved. The last round of beautification made the code
substantially more readable. This was a direct result of trying to
track down a reference count problem. The problem proved to be
elsewhere, but it was nearly
CD == Casey Duncan [EMAIL PROTECTED] writes:
CD Yes, except I would argue that such work is best left on the
CD HEAD rather than applied to a maintenance branch until
CD necessitated by bug reports on that branch, or at least the
CD knowledge that such a bug definitely exists and can be
BL == Brian Lloyd [EMAIL PROTECTED] writes:
Here's the status - an engagement that we're doing has been
bringing up some issues regarding ZODB and ZEO in large-scale
environments. I think that the fixes are useful enough that
they should be in 2.6.1, but getting them finalized
Your basic point makes sense, although I'm not entirely clear on how
transaction management is integrated into the Zope application.
Speaking for ZODB alone, I believe we've recommended that people call
get_transaction().abort() if they catch an exception. I can't recall
getting into any nuances
On Tue, 2003-02-11 at 04:13, [EMAIL PROTECTED] wrote:
Chris McDonough wrote:
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and disallowing the
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I added a test to testZODB.py on a new branch
(shane-conflict-handling-branch) that exercises the conflict handling
bug. The test currently fails. It might be simpler to go with Toby's
implementation for now: add a veto object to the
On Wed, 2003-02-12 at 04:23, Toby Dickenson wrote:
On Tuesday 11 February 2003 5:21 pm, Jeremy Hylton wrote:
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I'd like to do the transaction states, because it would keep the code in
zodb3 and zodb4 similar.
There are application-level
On Thu, 2003-02-20 at 13:33, Toby Dickenson wrote:
On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote:
There are application-level reasons to mark a transaction as doomed, and
I would like to keep *that* code looking similar ;-). The transaction
states approach would work
I'm not dismissing it, and I think you need to go back and read what I
wrote again very very carefully without reading anything into it. I'm
not trying to imply that using environment variables to configure the
current codebase will reduce the code footprint. Even if it did,
because of the
[Please followup to zodb-dev.]
Richard,
You made some changes to the mkzeoinst.py script in April. I was busy
then, and I've just had a chance to look at the changes now. I'd like
to discuss some of the changes, and I'm including a wider discussion
list to make sure we include anyone else who
The change was too extensive to call it a patch. It was almost a
rewrite. If you want to dig through the repository, look for all
changes made to ZODB and ZEO between about October 31, 2002 and
January 3, 2003. I imagine it would be less work to upgrade to a
more recent version of Zope.
We have released ZODB 3.1.2b2 available from the usual place:
http://www.zope.org/Products/ZODB3.1
This release includes several critical bug fixes for ZEO. The bugs are
more likely to affect sites that see a lot of read conflicts (resolved
or unresolved). The bugs can cause data loss or
We have released ZODB 3.2b2 available from the usual place:
http://www.zope.org/Products/ZODB3.2
This release includes several critical bug fixes for ZEO. The bugs are
more likely to affect sites that see a lot of read conflicts (resolved
or unresolved). The bugs can cause data loss or
I don't recall that any of the pack bugs that we fixed caused this sort of
error. My first guess would be that the file is a bit damaged, perhaps in a
way that the old pack did not check.
Can you run fsdump.py and see if that output sheds any light. It will give
you a detailed text summary of
Zope 2.6.2, Zeo 2.0.1b1 and python 2.2.3
I'm trying to get this combo working (I know its not officially
supported). It works fine except for when a second client updates zeo
the changes aren't seen from the first client (until its restarted). I
ran the zeo tests with 2.2.3 and they
Has anyone had a chance to test ZODB 3.2b3? We're hoping to do a
release candidate tomorrow, and it would be good to know if anyone has
tried to the beta release. If you've got a current CVS checkout of Zope
2.7, that's got the same code.
Jeremy
On Thu, 2003-10-02 at 13:34, Leonardo Rochael Almeida wrote:
I thought that was easy to miss, so I changed the heading from
Zope Enterprise Objects
to
Zope Enterprise Objects (OBSOLETE)
And I still missed it! Amazing! it must've been the pre-lunch hunger or
I am worried enough about breaking products that I'm inclined to go
with option 3.
Does anybody think we ought to use the new algorithm (option 2)?
I think we should use the new algorithm. However, I don't have any
products that I would be responsible for updating and maintaining. I'd
be
On Fri, 2003-10-31 at 13:52, Sidnei da Silva wrote:
| I personally don't like the new algorithm, but I don't really care
| in the long run. One should avoid inheritence complex enough to show
| a difference.
I hearthly agree here.
Home domestic of you wink.
I do like the new algorithm, but
Dean Goodmanson pointed out that the Zope credits file is a little out
of date:
http://www.pycs.net/sqr/categories/slicesOfPy/2003/10/30.html#a184
Wouldn't it be nice to get it in better shape for the 2.7 release? It
seems like a task that is easy to do in parallel. If credits are too
hard, how
On Mon, 2003-11-24 at 13:22, Sidnei da Silva wrote:
I think it was decided for the non-mro approach, though no one stated
it clearly.
If it was, they sure didn't. A summary of the opinions that lead to the
decision would be nice.
Even if it's decided, it wouldn't hurt to fix the inheritance
On Sun, 2003-12-07 at 08:15, Dieter Maurer wrote:
ATT: replacing the cache without clearing it can lead to huge
memory leaks (everything in the old cache is leaked!).
Without commenting on the rest of the bug report, I should mention that
caches and persistent objects all participate in
On Mon, 2003-12-08 at 13:17, Dieter Maurer wrote:
Jeremy Hylton wrote at 2003-12-7 23:01 -0500:
On Sun, 2003-12-07 at 08:15, Dieter Maurer wrote:
ATT: replacing the cache without clearing it can lead to huge
memory leaks (everything in the old cache is leaked!).
Without commenting
On Mon, 2003-12-08 at 15:36, Dieter Maurer wrote:
Dieter Maurer wrote at 2003-12-7 14:15 +0100:
Playing with Zope Head (as of 2003-12-04) revealed problems with
refresh.
Turns out to be a bug in ZODB.Connection.Connection._setDB:
ConnectionObjectReader used the old cache while
On Mon, 2003-12-08 at 15:56, Yuppie wrote:
Jeremy Hylton wrote:
@@ -158,8 +158,6 @@
-self._reader = ConnectionObjectReader(self, self._cache,
- self._db._classFactory)
@@ -168,6 +166,8 @@
+self._reader = ConnectionObjectReader
On Wed, 2003-12-10 at 14:01, Sidnei da Silva wrote:
| Probably a good next step is to set a breakpoint in
| ZODB/coptimizations.c where this exception is raised and find out what
| object is causing the problem, which jar it's already in, and why it's
| getting added to a different jar. Or
On Wed, 2003-12-10 at 14:18, Sidnei da Silva wrote:
'jar' gives:
object : attribute '_p_jar' of 'persistent.Persistent' objects
type: getset_descriptor
refcount: 2
address : 0x40621e6c
Does that help?
Yes. The code is getting an unexpected raw descriptor. Someone should
be calling
Actually, there are two equally valuable clues from the debugger
session:
object : class 'Products.Formulator.StandardFields.LabelField'
type: ExtensionClass.ExtensionClass
refcount: 7
address : 0x8503bec
If I understand correctly: LabelField is a class that inherits from
Persistence and
On Wed, 2003-12-10 at 15:36, Sidnei da Silva wrote:
| 'jar' gives:
| object : attribute '_p_jar' of 'persistent.Persistent' objects
| type: getset_descriptor
| refcount: 2
| address : 0x40621e6c
|
| Thus, asking for the class's _p_jar gives the descriptor back. In ZODB4
| I hacked
I think there's a fix for this in CVS. Can you try it again?
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
On Thu, 2003-12-11 at 10:24, Sidnei da Silva wrote:
On Thu, Dec 11, 2003 at 10:07:51AM -0500, Jeremy Hylton wrote:
| I think there's a fix for this in CVS. Can you try it again?
Just tried. Seems to have fixed it. Now, for the next step *wink*.
If I try starting Zope with an old existing
On Thu, 2003-12-11 at 15:15, Sidnei da Silva wrote:
Do'h, that's a bit difficult since Jim removed them for good :(
Hmmm... I suppose you could write the script in Zope 2.7 and tell people
they have to use that version of Zope to convert the database before
upgrading.
Now, back to the
On Sun, 2003-12-14 at 16:53, Chris McDonough wrote:
We still use ZODB 3.1 and at least there, the cache verification
protocol seems quite stupid. We will soon switch to ZODB 3.2
and when cache validation still needs minutes, I will need
to look into this...
Apparently, the ZEO in 2.7
On Mon, 2003-12-15 at 07:34, Dieter Maurer wrote:
I don't think it makes a lot of sense to put an __del__ method on a
Persistent object.
I just read in cPersistence.c:ghostify:
/* We remove the reference to the just ghosted object that the ring
* holds. Note that the dictionary
Does the last report mean your problem is fixed? Or do you still need
help tracking something down?
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related
On Sun, 2004-01-04 at 23:28, Jeff Kowalczyk wrote:
I'm not sure whether the collector issue 1164 I posted is simply a
missing configuration step on my part. At any rate, I'm still unable to
start the current checkout of Zope HEAD. The only edit I make to
/var/zope/etc/zope.conf is
Actually, this was a bug in CVS. I removed the old FileStorage.py on a
branch, but didn't remove it on the trunk when I merged the branch. It
should be fixed now.
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
On Thu, 2004-01-08 at 20:31, Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would
be nice to retire 2.1.3.
I'm not aware of any Zope Corp internal projects still using Python
2.1.3. I'm not aware of any serious incompatibilities. I suppose the
only
On Fri, 2004-01-16 at 13:58, Tres Seaver wrote:
This is a result of some funny repository fiddling, which somehow got
both 'ZEO' and 'BDBStorage' onto the 'Zope-2_6-branch'. I would like to
remove the branch tag altogether, as neither module is part of the 2.6
release.
The branch tag is
On Sat, 2004-01-17 at 17:22, Jamie Heilman wrote:
Jeremy Hylton wrote:
I committed a patch with the umask option a few days ago. I thought it
only affected zdaemon and the tests all looked clean afterwards. I'm
not sure how zopectl.py ends up being affected or why there aren't any
tests
On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote:
Its desirable in some circumstances, but not all. Part of the problem
is people tend to blindly follow the traditional approach to daemon
design without bothering to actually do any critical thinking.
I expect you don't intend to sound rude,
On Wed, 2004-01-21 at 10:42, Brian Lloyd wrote:
What I don't like is that it is somewhat magical, and now the
error you would get (probably 'None has no attribute xxx') if
the user doesn't have access to the container doesn't tell you
the real problem.
What if you used a special object
I noticed that Zope 2.7 and Zope 2.8 changed the default zLOG
implementation to use the logging package. There's one subtle
consequence of that change that I wonder if people are aware of.
The zLOG.LOG() call takes an optional error argument that contains a
3-tuple of exception information as
On Fri, 2004-02-13 at 14:38, Evan Simpson wrote:
I'm getting several TypeErrors when I run 'make test' on the HEAD. Each
of them involves a call to cAccessControl's 'validate' with 'roles' set
to a PermissionRole instance, complaining that it's not iterable.
Any ideas?
These tests have
On Tue, 2004-02-17 at 11:45, Jeffrey P Shell wrote:
What should I do next? Should I familiarize myself with gdb and
inspect the core? What are some things I could look for if that's the
next step?
The code dump is an important clue, so it's definitely worth looking at.
It's also pretty
I was doing some branch merging and apparently got mislead by stray .pyc
or .so files being left behind after .py and .c files were removed. So
there's some broken code on the head; I'll fix ASAP.
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
On Thu, 2004-02-19 at 13:48, Jeremy Hylton wrote:
I was doing some branch merging and apparently got mislead by stray .pyc
or .so files being left behind after .py and .c files were removed. So
there's some broken code on the head; I'll fix ASAP.
I think it's all fixed now, though the cause I
Dieter,
Have you seen this behavior with a debug build of Python? Under a debug
build, you're more likely to get complaints about dodgy C code and the
garbage collection will complain about refcount problems it can detect.
Jeffrey,
Any luck with you're core dump?
Jeremy
On Mon, 2004-03-01 at 13:41, Paul Winkler wrote:
However, ZEO is a whole other story.
The time to load a 40 MB file from ZEO and serve it,
is about another 10x slower than plain Zope without ZEO.
This is painfully bad and readily apparent to users.
But if your ZEO cache is large enough to
On Wed, 2004-03-03 at 08:42, Santi Camps wrote:
Hi again,
I've this traceback using Zope 2.7.0 final:
Module ZPublisher.Publish, line 163, in publish_module_standard
* Module ZPublisher.Publish, line 127, in publish
* Module Zope.App.startup, line 203, in
On Wed, 2004-03-03 at 04:55, Chris McDonough wrote:
(boldly crossposting this to zodb-dev, please respond on one list or the
other but not both)
That error *appears* to be caused by reaching a state that is impossible
to reach. The code in question is:
for key in
On Fri, 2004-03-05 at 16:57, Dieter Maurer wrote:
3) is it possible to disable caching of some object?
No, but you can (in most cases) flush it again
by calling its _p_deactivate method.
You can always do it by assigning None to _p_changed, but this
is highly unsafe. You should not do it
On Wed, 2004-03-10 at 13:39, Evan Simpson wrote:
Jeremy Hylton wrote:
Make sure App.Product is imported first, so that test.py can work.
This change does not affect the old utilities/testrunner.py.
This checkin message caused me to notice 'test.py' for the first time.
Can you point me
90 matches
Mail list logo
