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 anywh
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
Neal Norwitz writes:
> >> On Wed, Jan 27, 2010 at 2:54 AM, Ben Finney
> >> wrote:
> >> > The book “Beautiful Testing”, published by O'Reilly, might help
> >> > http://oreilly.com/catalog/9780596159825>.
>
> Ben, thanks. Your comment gave me a great laugh and I really
> appreciated it. :-)
>
> T
On Wed, 2010-01-27 at 10:25 -0800, Collin Winter wrote:
> On Wed, Jan 27, 2010 at 7:26 AM, William Dode 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 if you only s
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 thi
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 pr
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'
c
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
>> 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
>> 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
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 there
On Thu, Jan 28, 2010 at 10: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:
This is like the django traceback i
On Thu, Jan 28, 2010 at 2:33 PM, 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:
>
> http://benjamin-schwei
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
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:
>
> http://benjamin-schweizer.de/improve
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.
"Chaos is the score upon which reality is written." --Henry Miller
__
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: http://dpaste
On Thu, Jan 28, 2010 at 5: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:
>
> http://benjamin-schweizer.de/impr
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 adde
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 p
Hi Guido,
On Thu, Jan 28, 2010 at 5:02 PM, Guido van Rossum wrote:
> On Thu, Jan 28, 2010 at 5: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
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:
http://benjamin-schweizer.de/improve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Howell wrote:
> --- On Wed, 1/27/10, Alex Gaynor wrote:
>
>> "Python lists implement a pretty useless data structure"
>>
>> It's very difficult for ideas to gain traction when they
>> contain such
>> useless, and obviously wrong, rhetoric. The
cgitb can also produce text tracebacks:
>>> import cgitb
>>> cgitb.enable(format='text')
>>> import urllib
>>> f=urllib.urlopen('bogus://foo')
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
function calls l
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 by default
I commented on the blog post befor
On Thu, Jan 28, 2010 at 11:01 AM, 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 by
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 loca
On 28 January 2010 12:58, 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 pu
On Thu, Jan 28, 2010 at 1:14 PM, Paul Moore 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 (bdist_wininst/bdist_msi) which w
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 lo
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
B
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
> -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 l
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 would
> 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.
P
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
wrote:
>
> On Jan 27, 2010, at 3:55 PM, M
--- On Thu, 1/28/10, Josiah Carlson 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 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
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 word
41 matches
Mail list logo
