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
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...
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 for
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
Michal
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:
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
-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
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 this
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 valid for
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
-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) = ((newscr) ? (newscr)-_cury : (-1
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, though, as
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 collection
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
(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.
Regards,
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.
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
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
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.
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
20 matches
Mail list logo
