From: "Daniel Stutzbach" <[EMAIL PROTECTED]>
> Many years ago I implemented a deque type in C (for use in C programs)
> using a single dynamically sized array as the underling type,
The approach was not used so we could avoid data movement
associated with re-sizing.
> I see the
> advantages as f
On Nov 15, 2007 12:57 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, my development time is now somewhat limited
> and I prefer to spend it on a todo list that has been around
> for some time. I dread throwing that time away and
> spending it on reviewing your patch, timing tons of test
Many years ago I implemented a deque type in C (for use in C programs)
using a single dynamically sized array as the underling type, along
with an extra integer to designate where the "start" of the list is.
Somehow, I had always imagined that Python's implementation worked the
same way, but was ju
> In my opinion __replace__ should be able to replace multiple fields.
This suggestion is accepted and checked-in. See revision 58975.
Surprisingly, the required signature change results in improved
clarity. This was an all around win.
Raymond
___
P
> I have some scripts where this module is used - asyncore, xmlrpc, sgmlop.
> Some errors are arriving - memory errors reported by msvc2005 malloc/free.
>
> Where I should report bugs ?
>
> my env: py-2.5- partial cvs, sgmlop either from Frideric-s site or pyxml
> - same effect.
sgmlop is not pa
On Nov 14, 2007 1:52 PM, Grzegorz Makarewicz <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have some scripts where this module is used - asyncore, xmlrpc, sgmlop.
> Some errors are arriving - memory errors reported by msvc2005 malloc/free.
>
> Where I should report bugs ?
http://bugs.python.org/
-Brett
_
> crucial stuff like __fields__ ... fully
> read-write.
On further thought, I think this is a good idea. Nothing good can come from
writing to this class variable.
Suggestion is checked-in in rev 58971. Curiously, it was already documented as
read-only (I took the time machine out for a spin
> for efficiency I would prefer to avoid using * to break
> up the sequences generated directly by the database interface.
There are some use cases that would be better served by an alternate design and
others that are better served by the current design. For example, it would
really suck to ha
Hi
I have some scripts where this module is used - asyncore, xmlrpc, sgmlop.
Some errors are arriving - memory errors reported by msvc2005 malloc/free.
Where I should report bugs ?
my env: py-2.5- partial cvs, sgmlop either from Frideric-s site or pyxml
- same effect.
tia,
mak
On Nov 14, 2007 10:30 AM, Isaac Morland <[EMAIL PROTECTED]> wrote:
> For another project (see my previous email on named tuples), I needed to
> represent procedure signatures, and use them to expand arguments into the
> dictionary of values that exists when execution of a procedure starts. To my
>
I take back the first "Yes" answer. Alas, the % operator is a mess,
especially for %d/%o/%x. For subclassed longs, it *is* attempting to
call the overridden __oct__, and this is causing the SystemError. It
looks like this code wasn't really revisited when subclassing int and
long was introduced. :-
On Nov 13, 2007 6:15 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Hello Pythonistas and fellow core developers!
>
> After Amaury introduced himself I've decided that I *have* to take some
> time to introduce myself, too.
Obviously welcome, but you have been in the thick of things already,
so
Yes, and yes. There may be time still to fix the SystemError in 2.5.2!
On Nov 14, 2007 11:16 AM, Mike Stall <[EMAIL PROTECTED]> wrote:
>
>
>
>
> This is my first post, so here's a quick intro: I've recently joined the
> IronPython team at Microsoft, after about 6 years as a developer on the the
>
Mike Stall wrote:
> Traceback (most recent call last):
> File "", line 1, in
> SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to
> internal function
> Note that if c derives from 'int' instead of 'long', everything works as
> expected.
I'm able to reproduce the error
This is my first post, so here's a quick intro: I've recently joined the
IronPython team at Microsoft, after about 6 years as a developer on the the
.NET runtime (CLR).
I'm currently trying to make IronPython match CPython's behavior regarding some
% format string to a level of detail not docum
On Nov 14, 2007 10:30 AM, Isaac Morland <[EMAIL PROTECTED]> wrote:
> For another project (see my previous email on named tuples), I needed to
> represent procedure signatures, and use them to expand arguments into the
> dictionary of values that exists when execution of a procedure starts. To my
>
For another project (see my previous email on named tuples), I needed to
represent procedure signatures, and use them to expand arguments into the
dictionary of values that exists when execution of a procedure starts. To my
surprise, this capability didn't seem to be provided by the Python libr
I was working on something very similar to namedtuple for a project of my own,
when it occurred to me that it's generally useful idea and maybe somebody else
was working on it too. So I searched, and found Raymond Hettinger's addition
to collections.py, and it does pretty much what I want. I h
ACTIVITY SUMMARY (11/07/07 - 11/14/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1325 open (+18) / 11600 closed (+25) / 12925 total (+43)
Open issues with patches: 421
Average durati
2007/11/14, Christian Heimes <[EMAIL PROTECTED]>:
> After Amaury introduced himself I've decided that I *have* to take some
> time to introduce myself, too.
Welcome you both to this journey.
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
__
20 matches
Mail list logo
