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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
16 matches
Mail list logo
