Re: [Python-Dev] Proposal: add odict to collections
Armin Ronacher wrote: That's true, but by now there are countless of ordered dict implementations with a mostly-compatible interface and applications and libraries are using them already. Even worse, most of them are slow, i.e. show a wrong algorithmic complexity ... I have an example implementation here that incorporates the ideas from ordereddict, Django's OrderedDict and Babel's odict: http://dev.pocoo.org/hg/sandbox/raw-file/tip/odict.py ... like your implementation. It is not too hard to get the delitem O(log n) compared to your O(n), see here: http://codespeak.net/svn/user/arigo/hack/pyfuse/OrderedDict.py So many people are implementing this kind of data type but do not really care about making as fast as it could be ... IMHO yet another reason to ship a usable implementation with Python. Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sys.last_traceback - annoying pdb.pm behaviour
Hi there, when trying to use pdb, I spotted some kind of annoying behaviour of pdb: for pdb.pm, it still uses sys.last_traceback which is set by code.py This renders the function unusable in non-interactive contexts ... I suggest to change pdb.pm to use sys.exc_traceback instead. Any reasons not to do so? For Py3k, it might make sense to kill it. Besides that, some other places in the stdlib reference this attr as well: idle in 5 places ./lib-tk/Tkinter.py:sys.last_traceback = tb ./traceback.py:sys.last_value, sys.last_traceback, limit, file)'. ./traceback.py:print_exception(sys.last_type, sys.last_value, sys.last_traceback, ./pdb.py:post_mortem(sys.last_traceback) ./code.py:type, value, sys.last_traceback = sys.exc_info() ./code.py:sys.last_traceback = tb ./dis.py:tb = sys.last_traceback Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sys.last_traceback - annoying pdb behaviour
Hi there, when I tried to use pdb, I spotted some kind of annoying behaviour of pdb: for pdb.pm, it still uses sys.last_traceback which is set by code.py This renders the function unusable in non-interactive contexts ... I suggest to change pdb.pm to use sys.exc_traceback instead. Any reasons not to do so? For Py3k, it might make sense to kill it completly. Besides that, some other places in the stdlib reference this attr as well: idle in 5 places ./lib-tk/Tkinter.py: sys.last_traceback = tb ./traceback.py: sys.last_value, sys.last_traceback, limit, file)'. ./traceback.py: print_exception(sys.last_type, sys.last_value, sys.last_traceback, ./pdb.py: post_mortem(sys.last_traceback) ./code.py: type, value, sys.last_traceback = sys.exc_info() ./code.py: sys.last_traceback = tb ./dis.py: tb = sys.last_traceback Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.last_traceback - annoying pdb behaviour
Guido van Rossum wrote: On 8/18/07, Alexander Schremmer [EMAIL PROTECTED] wrote: when I tried to use pdb, I spotted some kind of annoying behaviour of pdb: for pdb.pm, it still uses sys.last_traceback which is set by code.py This renders the function unusable in non-interactive contexts ... I suggest to change pdb.pm to use sys.exc_traceback instead. Any reasons not to do so? sys.last_traceback is the only place where you can reliably find the latest *uncaught* traceback. There is no intention to get rid of it in Py3k or to change this behavior. If you have another traceback you'd like to print, you can use pdb.post_mortem(sys.exc_info()[2]). Indeed, I did not see that it is also set in pythonrun. How do you think about changing pdb.pm to use exc_info if last_exception is not set? Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] git (Was: Encouraging developers)
Hi python-dev, MvL wrote: the on-disk repository is mighty big and it doesn't work very well on non-Linux systems (at least, not last I looked.) Yes, mercurial or Bazaar do its job better on Windows etc. (and are written in Python :-) Not true. The on-disk repository is now one of the more efficient ones. After packing the repository, yes (which has to be done manually). If this still makes git one of the more efficient dvcs systems, I don't want to see the other ones :-( I do not know about speed issues in git, but I think that mercurial is said to be nearly as fast as git - and at least updating repos seems to work for me quickly. Thomas A. Hein has setup a one-shot mirror of the CPython SVN with branch support here: http://hg.intevation.org/tmp/python/python/ And there is a mirror here: http://hg.alexanderweb.de/python-temp/ You can clone it by running `hg clone URL`, and then `hg serve` to see the repo in your web browser. For me that needed less than 5 minutes on a well-connected machine. For beginners, there is a nice explanation about DVCS here: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing 2.5 feature
On Sun, 9 Jul 2006 20:45:05 -0700, Neal Norwitz wrote: There hasn't been much positive response (in the original thread or here). Given you forgot about it for over a year, how important can it be? :-) For me it would be very important because I often wonder where the threads are currently working in my multithreaded apps. As a partial solution, I wrote a thread monitor that tracks all thread's frames using a trace function and generates tracebacks on demand. This slows down program execution of course. With that function, it would be much simpler to see the current state of the program (which is trivial in environments like the JVM for example). Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On Thu, 15 Jun 2006 19:00:09 +0200, Jan Claeys wrote: Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer: Bazaar-NG seems to reach limits already when working on it's own code/repository. Canonical uses bzr to develop launchpad.net, which is a little bit larger dan bzr itself, I suspect...? I don't think so, without having seen the Launchpad code. I assume that Launchpad has less comitters (closed source!) and therefore less change sets and less parallel branches. Once I pulled the bzr changesets (1-3 months ago) and it needed 3 hours on a 900 MHz machine with a high-speed ( 50 MBit) internet connection (and it was CPU bound). Note that bzr has gained a lot of speed since then, though. Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On Mon, 12 Jun 2006 23:31:14 +0200, Thomas Wouters wrote: I did partial imports into Mercurial and Bazaar-NG, but I got interrupted and couldn't draw any conclusions -- although from looking at the implementation, I don't think they'd scale very well at the moment (but that could probably be fixed.) Maybe you benchmarked a Tailor deficiency here, but Mercurial scales very well. People use it for work on the Linux kernel etc. Compared to that, Bazaar-NG seems to reach limits already when working on it's own code/repository. Here is a paper comparing different DVCS for the FreeBSD ports tree (one of the largest CVS repositories that exists ;-)): http://www.keltia.net/BSDCan/slides.pdf Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The i string-prefix: I18n'ed strings
On Thu, 6 Apr 2006 20:35:51 -0400, Martin Blais wrote: This is pretty standard getttext stuff, if you used _() a lot I'm surprised you don't have a need for N_(), I always needed it when I used i18n (or maybe I misunderstood your question?). Have you thought about simply writing _ = lambda x:x instead of N_ ...? By doing that, you just need to care about one function (of course _ doesn't translate in that case and you might need to del _ afterwards). Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The i string-prefix: I18n'ed strings
On Fri, 7 Apr 2006 10:07:26 -0400, Martin Blais wrote: There are cases where you need N_() after initialization, so you need both, really. See the link I sent to Alex earlier (to the GNU manual example). On the page you were referring to, I cannot find a particular use case that does not work with the idea sketched above. Kind regards, Alexader ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Threading idea -- exposing a global thread lock
On Mon, 13 Mar 2006 21:57:59 -0500, Raymond Hettinger wrote: Think of it as non-cooperative multi-threading. While this is a somewhat rough approach, it is dramatically simpler than the alternatives (i.e. wrapping locks around every access to a resource or feeding all resource requests to a separate thread via a Queue). Why is that actually more difficult to write? Consider res_lock = Lock() res = ... with locked(res_lock): do_something(res) It is only about supplying the correct lock at the right time. Or even this could work: res = ... # implements lock()/unlock() with locked(res): do_something(res) Directly exposing the GIL (or some related system) for such matters does not seem to be a good reason for a novice to let him stop all threads. Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] About Coverity Study Ranks LAMP Code Quality
On Tue, 14 Mar 2006 00:55:52 +0100, Martin v. Löwis wrote: I can understand that position. The bugs they find include potential security flaws, for which exploits could be created if the results are freely available. On the other hand, the exploit could be crafted based on reading the SVN check-ins ... Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Translating docs
On Sun, 26 Feb 2006 08:50:57 +0100, Georg Brandl wrote: Martin: There aren't any German docs, are there? There is e.g. http://starship.python.net/~gherman/publications/tut-de/ Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://www.python.org/dev/doc/devel still available
On Wed, 15 Feb 2006 21:13:14 +0100, Georg Brandl wrote: If something like Fredrik's new doc system is adopted, it would be extremely convenient to refer someone to just docs.python.org/os.path.join In fact, PHP does it like php.net/functionname which is even shorter, i.e. they fallback to the documentation if that path does not exist otherwise. Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
On Sun, 15 Jan 2006 20:23:39 +0100, Martin v. Löwis wrote: There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Right - the question would be whether completely breaking W9x support in the process would be acceptable. We use the very same binaries for W9x and NT. How about accessing/calling the wide char versions just if the OS is NT, i.e. compiling both versions into the dll and just using one? Looking at the file object, the open function uses _wfopen which needs Windows NT according to the MSDN lib. So, how is 9x compat ensured here? Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
On Sat, 12 Mar 2005 11:38:50 +0100, Martin v. Löwis wrote: Somebody reported that it failed to update python24.dll in an update installation; not sure why this would be. Because it was in use? Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
