I tried a few times to commit a patch (for issue #1530) to the trunk,
but I always get this error:
alex:python% svn commit Lib/doctest.py --file svn-commit.tmp
svn: Commit failed (details follow):
svn: MKACTIVITY of
I first thought that was related to the Py3k freeze. However, I tried
again a few minutes ago and I still got this error. Is possible that
my commit rights are limited to the py3k branches? Or this is a
Good afternoon everybody!
The new C API documentation contains some large files:
The concrete.html takes noticeable time to render on my computer (P4 2.4
with 1GB RAM, Firefox 2.0 and Ubuntu Linux). I estimate the load and
rendering time is about 4-5 seconds! It also takes long to search for a
string and scrolling isn't smooth, too.
Can we split the files in smaller chunks, please?
I'm planning to freeze the py3k branch in 2-3 hours, some time
after/around 8pm PST (midnight UTC).
If someone wants to do another svnmerge from the trunk please do it
before then -- though we're nearly current so I don't mind not having
the last few changes merged into this release (it's only Raymond's
refactoring of __length_hint__ implementations).
If there's anything you think really should be in this release, please
speak up ASAP. Filing a high priority bug and assigning it to me would
be a great way to get my attention.
--Guido van Rossum (home page: http://www.python.org/~guido/)
So Jim and PJE finally convinced me to do it the right way. :) Thanks
guys - it turned out very nice.
It caches type/metatype attribute lookups, including missing attributes.
Summary of the bug tracker issue:
- Successful attribute lookups are 20% faster, even for classes with
short MROs and (probably most) builtins - haven't tested unsuccessful
- Successful hasattr is 5-10% faster, unsuccessful is 5% faster (less
impressive than above, and likely due to overhead - internally, all
lookups are the same)
- list.__init__ and list().__init__ are slower, and I can't figure out
why (creating instances of subclasses of list will be a little slower,
and this may show up in other builtin types)
- I haven't benchmarked type attribute sets (how much do we care?) - it
should be quite a bit faster than updating a slot, though
- Caching missing attributes is crucial for good performance
- The CreateNewInstances benchmark uncovered an issue that needs fixing;
please see the tracker for details
All kinds of commentary and feedback is most welcome.
Has anyone else ever encountered a situation where a python process gets
stuck in an infinite loop within Python/pystate.c tstate_delete_current()
called from PyThreadState_DeleteCurrent() when a thread is
exiting? (revealed by attaching to the looping process with a debugger)
I'm seeing this (very rarely, reproducing it is difficult). In this case
its python 2.4.3 but that code does not appear to have changed since then.
Guido van Rossum wrote:
> The asyncore and asynchat modules are in a difficult position when it
> comes to Python 3000. None of the core developers use it or
> particularly care about it (AFAIK), and the API has problems because
> it wasn't written to deal with bytes vs. unicode. E.g. in
> http://bugs.python.org/issue1067, Thomas suggests that these modules
> need to be rewritten to use bytes internally and have separate APIs to
> handle (unicode) text as desired, similar to the way file I/O was
> redesigned. Another alternative would be to make these modules deal
> strictly in bytes, but that would probably vastly reduce their
> usefulness (though I don't know -- as I said, I don't use them).
I guess that would be me, if you'll have me. I think asyncore and
asynchat are valuable, and I'm willing to do what needs to be done to
ensure that they remain in Py3k.
> Hm... rhettinger(a)ewtllc.com bounced. I wonder what's going on there..
I'm now in an EWT spin-off company. The new email address is rhettinger(a)fattoc.com. Also, I frequently check the python(a)rcn.com account too.