On Tuesday 26 January 2010, Steve Howell wrote:
Here are the benefits of an O(1) implementation.
[...]
Did I leave anything out?
Good summary, Steve, thanks!
Anyway, you left two out:
* Inserting at the front gets the same complexity as inserting at the back.
* Inserting and erasing
Neal Norwitz, 28.01.2010 08:31:
One of my points to Victor and everyone else like him is that even
though it may seem no one is listening to you or cares, you might be
surprised to find out how many people really are paying attention and
do care. If you have something you want to do, make it
Neal Norwitz nnorw...@gmail.com writes:
On Wed, Jan 27, 2010 at 2:54 AM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
The book “Beautiful Testing”, published by O'Reilly, might help
URL:http://oreilly.com/catalog/9780596159825.
Ben, thanks. Your comment gave me a great laugh and I
On Wed, 2010-01-27 at 10:25 -0800, Collin Winter wrote:
On Wed, Jan 27, 2010 at 7:26 AM, William Dode w...@flibuste.net wrote:
I imagine that startup time and memory was also critical for V8.
Startup time and memory usage are arguably *more* critical for a
Javascript implementation, since
Le jeudi 28 janvier 2010 08:31:50, Neal Norwitz a écrit :
Ben, thanks. Your comment gave me a great laugh and I really
appreciated it. :-)
The chapter is about the general Python development process, including
testing, static analysis, dynamic analysis, including Fusil among
other things.
Tim I think the performance/memory tradeoffs being discussed are fine
Tim for the long-running / server apps (20mb on a 8Gb machine is
Tim negligable)
At work our apps' memory footprints are dominated by the Boost-wrapped C++
libraries we use. 100MB VM usage at run-time is
A question from someone writing C extension modules for python but not
involved in python-dev:
It has been said that compiling python with --without-llvm would not
include unladen swallow and would bypass llvm together with all C++.
Basically, as I understand it, --without-llvm gives the 'usual'
Daniel Fetchinson wrote:
If this is the case then I, as a C extension author, will have no
choice than working with a python installation that includes llvm/US.
Which, as far as I undestand it, means dealing with C++ issues. Is
this correct? Or the same pure C extension module compiled with
Daniel Fetchinson, 28.01.2010 13:19:
A question from someone writing C extension modules for python
I doubt that this will have any impact on C extension developers.
If this is correct, I still have one worry: since I wouldn't want to
touch the python install most linux distributions ship or
If this is the case then I, as a C extension author, will have no
choice than working with a python installation that includes llvm/US.
Which, as far as I undestand it, means dealing with C++ issues. Is
this correct? Or the same pure C extension module compiled with C-only
compilers would
A question from someone writing C extension modules for python
I doubt that this will have any impact on C extension developers.
If this is correct, I still have one worry: since I wouldn't want to
touch the python install most linux distributions ship or most
windows/mac users install (or
Hello,
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
http://benjamin-schweizer.de/improved-python-traceback-module.html
and the source code
On Thu, Jan 28, 2010 at 10:33 AM, Benjamin Schweizer
we...@benjamin-schweizer.de wrote:
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
This is
On Thu, Jan 28, 2010 at 2:33 PM, Benjamin Schweizer
we...@benjamin-schweizer.de wrote:
Hello,
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
Le Thu, 28 Jan 2010 14:33:11 +0100, Benjamin Schweizer a écrit :
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
As Facundo said it shouldn't
On Jan 28, 2010, at 8:33 AM, Benjamin Schweizer wrote:
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
The traceback support from the zc.twist package might be interesting
as well; not sure how well that's isolated from the rest of the
package though:
http://pypi.python.org/pypi/zc.twist/
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written.
As it happens, a few months ago we did the same here.
I have a traceback2.py module with the same api as traceback. Displaying local
variables is optional through keyword arguments.
I was also able to refactor the original significantly, making it much clearer.
I've pasted it here:
On Thu, Jan 28, 2010 at 5:33 AM, Benjamin Schweizer
we...@benjamin-schweizer.de wrote:
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
Hello Facuno,
I would love to get tracebacks with all variables in all levels of the
stack.
However, this may be too much information for standard tracebacks, so
what do you think to enable it on demand? Like setting a flag or
importing a module at the beginning of the file?
I've added an
Hi Kristján,
I have a traceback2.py module with the same api as traceback. Displaying
local variables is optional through keyword arguments.
I was also able to refactor the original significantly, making it much
clearer.
traceback2.py was my first attempt; but I finally came out with a
Hi Guido,
On Thu, Jan 28, 2010 at 5:02 PM, Guido van Rossum gu...@python.org wrote:
On Thu, Jan 28, 2010 at 5:33 AM, Benjamin Schweizer
we...@benjamin-schweizer.de wrote:
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in
At 02:33 PM 1/28/2010 +0100, Benjamin Schweizer wrote:
Hello,
I've updated the traceback.py module; my improved version dumps all
local variabes from the stack trace, which helps in debugging rare
problems. You can find details in my latest blog post here:
cgitb can also produce text tracebacks:
import cgitb
cgitb.enable(format='text')
import urllib
f=urllib.urlopen('bogus://foo')
type 'exceptions.IOError'
Python 2.7a1+: /home/amk/source/p/python/python
Thu Jan 28 11:35:04 2010
A problem occurred in a Python script. Here is the sequence of
On Thu, Jan 28, 2010 at 11:01 AM, s...@pobox.com wrote:
pje If you look for a local variable in each frame containing a format
pje string, let's say __trace__, you could apply that format string to
pje a locals+globals dictionary for the frame, in place of dumping all
pje the
At 11:01 AM 1/28/2010 -0600, s...@pobox.com wrote:
pje If you look for a local variable in each frame containing a format
pje string, let's say __trace__, you could apply that format string to
pje a locals+globals dictionary for the frame, in place of dumping all
pje the locals
On 28 January 2010 12:58, Daniel Fetchinson fetchin...@googlemail.com wrote:
If this is the case then I, as a C extension author, will have no
choice than working with a python installation that includes llvm/US.
Which, as far as I undestand it, means dealing with C++ issues. Is
this correct?
On Thu, Jan 28, 2010 at 1:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
So, just to extend the question a little (or reiterate, it may be that
this is already covered and I didn't fully understand):
On Windows, would a C extension author be able to distribute a single
binary
Hello pje,
On Thu, Jan 28, 2010 at 12:43:13PM -0500, P.J. Eby wrote:
At 11:01 AM 1/28/2010 -0600, s...@pobox.com wrote:
pje If you look for a local variable in each frame containing a format
pje string, let's say __trace__, you could apply that format string to
pje a
We have
import traceback2 as traceback all over the place.
I found that there is no need for the redundancy. There really are no special
cases.
I‘ve added traceback2.py at google code, in case anyone is interested.
K
From: benjamin.schwei...@gmail.com [mailto:benjamin.schwei...@gmail.com] On
At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote:
Hello pje,
On Thu, Jan 28, 2010 at 12:43:13PM -0500, P.J. Eby wrote:
At 11:01 AM 1/28/2010 -0600, s...@pobox.com wrote:
pje If you look for a local variable in each frame
containing a format
pje string, let's say __trace__, you
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
Of Guido van Rossum
This is a nice idea, but to be 100% robust is very hard. I assume
you've already added something to clip large
Having read the entirety of the thread (which is a rare case these
days, I need more spare time), and being that I'm feeling particularly
snarky today, I'm going to agree 100% with everything that Raymond has
said in this message and his few subsequent messages. Snarky comments
to follow.
I
Eric Smith wrote:
This discussion probably belongs on the distutils list.
Yes, the discussion should be.
Except that distutils doesn't have very much support for doing
applets or applications. So it's logical to see why most posts which
ask the same question, often go unanswered there.
If one doesn't care about slicing, the obvious implementation using a
dictionary and two counters works great for a deque with random
indexing. Well... except for the doubling in memory usage.
- Josiah
On Wed, Jan 27, 2010 at 4:15 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On
--- On Thu, 1/28/10, Josiah Carlson josiah.carl...@gmail.com wrote:
[...] in the decade+ that I've been using
Python and
needed an ordered sequence; lists were the right solution
99% of the
time [...]
What do you think of LISP, and car in particular (apart from the stupidly
cryptic name)?
On 1/28/2010 6:30 PM, Josiah Carlson wrote:
I would also point out that the way these things are typically done is
that programmers/engineers have use-cases that are not satisfied by
existing structures, they explain the issues they have with existing
structures, and they propose modifications.
On 1/28/2010 11:57 PM, Steve Howell wrote:
--- On Thu, 1/28/10, Josiah Carlson josiah.carl...@gmail.com wrote:
[...] in the decade+ that I've been using
Python and
needed an ordered sequence; lists were the right solution
99% of the
time [...]
What do you think of LISP, and car in
Hi Collin,
Thanks for the useful links.
I think that superinstructions require a bit more work, because they aren't
just opcode arguments rearrangement. For example, in wpython 1.1 (that I'll
release next month) I've introduced a CALL_SUB opcode to handle all kind of
function types, so the 2
39 matches
Mail list logo
