Depending on which implementation[s] you want to target, Michal, you
should also check out PyPy at http://codespeak.net/pypy/, IronPython
at http://www.codeplex.com/IronPython, and Jython at
http://www.jython.org/ -- Jython's currently a tad behind the other
three, but Sun Microsystems has just ann
On Sun, Mar 9, 2008 at 7:21 PM, Forrest Voight <[EMAIL PROTECTED]> wrote:
> This would simplify the handling of list slices.
>
> Slice objects that are produced in a list index area would be different,
> and optionally the syntax for slices in list indexes would be expanded
> to work everywhere.
This would simplify the handling of list slices.
Slice objects that are produced in a list index area would be different,
and optionally the syntax for slices in list indexes would be expanded
to work everywhere. Instead of being containers for the start, end,
and step numbers, they would be gener
At 01:59 PM 3/9/2008 -0800, Guido van Rossum wrote:
>Do we have much of a use case for this?
I've often had APIs that take a callback that promise to only invoke
the callback once, even if it's added more than once. And I've used
dicts, lists, and sets for same.
I did not, however, need the eq
> Dict access should probably be documented as no worse
> than O(log n) to allow for tree implementations.
That should not be documented. The current dict implementation
may use O(n) for lookup operations, where n is the number of
keys in the dictionary, and counting comparison operations.
Regard
> (gdb) print newscr
> $1 = (WINDOW *) 0x0
>
> So it seems that the newscr variable is indeed a NULL.
So this now *is* a FreeBSD/ncurses expert's question.
I don't think this is supposed to happen; newscr should
become non-NULL when initscr is called, and should remain
that way throughout.
Regar
On Sun, Mar 9, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Well, there you have hit the nail on the head -- should we document
> the actual or the guaranteed O() expression?
Either. Both. Put a note at the bottom saying that factors of O(log
n) have been dropped and they're
Guido van Rossum wrote:
> That said, if there's a use case, I agree that it would be okay with
> basing the equality of x.foo and y.foo on whether x and y are the same
> object, not on whether x==y (consider 0 .__add__ == 0.0 .__add__).
The use case in the issue tracker was maintaining a collectio
On Sun, Mar 9, 2008 at 9:51 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 9, 2008 at 9:02 AM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > In Python 2.5, I made an attempt to make equality consistent for the
> > various built-in and user-defined method types. I failed,
On Sun, Mar 9, 2008 at 11:50 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Aahz wrote:
> > * Other Python implementations (Jython, PyPy, IronPython) may not be
> > able to provide the same type implementations
> >
> > * Algorithmic information does sometimes change between versions, and
> > keep
-On [20080309 20:23], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote:
>If it's similar on FreeBSD, the only reason why this
>could break is that newscr is NULL.
This is what I get:
do {
if(newscr->_leaveok)
(y) = (x) = -1;
else
((y) = ((n
Aahz wrote:
> * Other Python implementations (Jython, PyPy, IronPython) may not be
> able to provide the same type implementations
>
> * Algorithmic information does sometimes change between versions, and
> keeping the docs updated is not trivial
Still, I think there are some general expectations
> One result I get is this:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x8173000 (LWP 100121)]
> 0x28ac4102 in PyCurses_getsyx (self=0x0)
> at /usr/home/asmodai/projects/python/Modules/_cursesmodule.c:1770
> 1770 getsyx(y, x);
>
> Is a value of 0x0 va
On Sun, Mar 9, 2008 at 9:02 AM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> In Python 2.5, I made an attempt to make equality consistent for the
> various built-in and user-defined method types. I failed, though, as
> explained in http://bugs.python.org/issue1617161. The outcome of thi
-On [20080308 12:08], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote:
>If you want to ask for help, that's probably something for the FreeBSD
>lists. Unfortunately, the FreeBSD threads library is notorious for
>crashing, hanging, and doing other unpleasant things to Python.
I think I can manage the F
On Mar 9, 2008, at 10:22 AM, Aahz wrote:
> This has been discussed before and rejected for two reasons:
>
> * Other Python implementations (Jython, PyPy, IronPython) may not be
> able to provide the same type implementations
>
> * Algorithmic information does sometimes change between versions, and
Hi all,
In Python 2.5, I made an attempt to make equality consistent for the
various built-in and user-defined method types. I failed, though, as
explained in http://bugs.python.org/issue1617161. The outcome of this
discussion is that, first of all, we need to decide which behavior is
"correct":
Michal> I'm about to start my master thesis: "optimizing python
Michal> interpreter" therefore i would require your help plz ;)
Michal> first of all i need to find out, how the python interpreter is
Michal> implemented, and which are the related sources, if this stuff is
Micha
On Sun, Mar 09, 2008, Dimitrios Apostolou wrote:
>
> Is it possible to include algorithm complexity information for the various
> built-in types (strings, sets, lists, dictionaries...)? This would ease
> the decision for choosing the correct type.
This has been discussed before and rejected fo
hi,
I'm about to start my master thesis: "optimizing python interpreter" therefore i
would require your help plz ;)
first of all i need to find out, how the python interpreter is implemented, and
which are the related sources, if this stuff is somewhere documented that
would be very helpfull...
Hello,
I would like to suggest changing the .pypirc file format to a format that
can deal with several servers.
This has been discussed here :
http://mail.python.org/pipermail/catalog-sig/2008-January/001607.html
And a summary document is available here:
http://wiki.python.org/moin/EnhancedPyPI
21 matches
Mail list logo
