[Python-Dev] Distutils - changing the pypirc format
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 (this document also contains a change ti PyPI server but this is another point) A patch was built and enhanced in the last bug day, and is available here: http://bugs.python.org/issue1858. Best Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RQST: Master Thesis
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... thx in advance michal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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 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 keeping the docs updated is not trivial There probably would be some value in a wiki page on python.org that provides this information, particularly across versions. You may be able to find volunteers to help on comp.lang.python. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ All problems in computer science can be solved by another level of indirection. --Butler Lampson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RQST: Master Thesis
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 somewhere documented that would be very helpfull... Michal, The best place to start is the implementation of the interpreter itself (Python/ceval.c in the source tree) and the byte code compiler (Python/compile.c). There have, at times, been modest attempts to document what's going on, but I believe the source code is far and away still your best bet. I recommend you get a Subversion checkout of either the trunk: svn co http://svn.python.org/projects/python/trunk or the py3k branch: svn co http://svn.python.org/projects/python/branches/py3k You will find the trunk more stable, but the py3k branch is the future. Also, study the archives of this list and the [EMAIL PROTECTED] list as well as checkin comments for the Python source, especially for the two files I referenced above. Finally, there may well be pending patches in the Python tracker which implement various optimizations: http://bugs.python.org/ Studying them (and trying them out and attaching comments or reviews of their efficacy) would be a good way to help understand the system. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Equality on method objects
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: [].append == [].append True or False? (See the issue tracker for why the answer should probably be False.) The general question is: if x.foo and y.foo resolve to the same method, should x.foo == y.foo delegate to x == y or be based on x is y? The behavior about this has always been purely accidental, with three different results for user-defined methods versus built-in methods versus method wrappers (those who know what the latter are, raise your hand). (Yes, Python 2.5 managed three different behaviors instead of just two: one of the types (don't ask me which) would base its equality on the identity of the 'self', but still compute its hash from the hash of 'self'...) A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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 keeping the docs updated is not trivial Also, given the significance of the constant factors and the fact that these are significantly dependent, especially for containers, on the objects passed in (either to be contained or tested), it's not clear that it often makes sense to worry about at too detailed a level. Common sense, knowledge of the interpreter, and experience are often more valuable the easily-outdated documentation. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD test suite failure - curses
-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 FreeBSD side, I used to be a committer for it. ;) If you want to debug this, run Python in a debugger, and run the test suite from there. core files are often not too helpful. 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 self? I'd figure it would be a memory address, but I do not know the internals well enough for that. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Delirious again, mesmerise my senses, our Souls entwine one more time... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
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 discussion is that, first of all, we need to decide which behavior is correct: [].append == [].append True or False? (See the issue tracker for why the answer should probably be False.) The general question is: if x.foo and y.foo resolve to the same method, should x.foo == y.foo delegate to x == y or be based on x is y? The behavior about this has always been purely accidental, with three different results for user-defined methods versus built-in methods versus method wrappers (those who know what the latter are, raise your hand). (Yes, Python 2.5 managed three different behaviors instead of just two: one of the types (don't ask me which) would base its equality on the identity of the 'self', but still compute its hash from the hash of 'self'...) They should only compare equal if interchangeable. In the case of a mutable container (ie list), a value comparison of self is irrelevant garbage, so it should always be compared (and hashed) based on identity. IOW, x = []; x.append == x.append should be True, and everything else should be False. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD test suite failure - curses
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 self? I'd figure it would be a memory address,
but I do not know the internals well enough for that.
That's fine. It's a module-level function; self is typically NULL for
these.
Another issue is that there should be an additional (ignored) parameter
args in PyCurses_getsyx; you might try adding one.
However, the real culprit should be getsyx(). What does this entire
function expand to when run through a preprocessor, and where does
it crash when you run the expanded code in the debugger?
For reference, on Linux (ncurses) it expands to
do {
if (((newscr)-_leaveok))
(y) = (x) = -1;
else
((y) = ((newscr) ? (newscr)-_cury : (-1)),
(x) = ((newscr) ? (newscr)-_curx : (-1))); }
while(0);
which should be equivalent to
if (newscr-_leaveok)
y = x = -1;
else {
y = newscr ? newscr-_cury : -1;
x = newscr ? newscr-_curx : -1;
}
If it's similar on FreeBSD, the only reason why this
could break is that newscr is NULL.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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 should be able to have of any implementation, e.g. that accessing a list item is roughly O(1), and not O(n) as it would be if they were implemented as linked lists. Dict access should probably be documented as no worse than O(log n) to allow for tree implementations. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD test suite failure - curses
-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)),
(x) = ((newscr) ? (newscr)-_curx : (-1)));
} while(0);
ncurses 5.6
In the same stack frame:
(gdb) print newscr
$1 = (WINDOW *) 0x0
So it seems that the newscr variable is indeed a NULL.
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Let us eat and drink; for tomorrow we shall die...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
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 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: [].append == [].append True or False? (See the issue tracker for why the answer should probably be False.) The general question is: if x.foo and y.foo resolve to the same method, should x.foo == y.foo delegate to x == y or be based on x is y? The behavior about this has always been purely accidental, with three different results for user-defined methods versus built-in methods versus method wrappers (those who know what the latter are, raise your hand). (Yes, Python 2.5 managed three different behaviors instead of just two: one of the types (don't ask me which) would base its equality on the identity of the 'self', but still compute its hash from the hash of 'self'...) They should only compare equal if interchangeable. In the case of a mutable container (ie list), a value comparison of self is irrelevant garbage, so it should always be compared (and hashed) based on identity. IOW, x = []; x.append == x.append should be True, and everything else should be False. Perhaps. I think we should approach this from the perspective of what is the most useful behavior that is straightforward to implement, not what is right (since there is more than one right). Do we have much of a use case for this? If not, I'd be okay with not providing these various forms of bound methods with equality at all, and just fall back on 'is'. While it may be surprising that x.append is not x.append, it should be no more surprising than x+1 is not x+1 under certain circumstances, and both actually provide a useful insight into the implementation. 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__). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
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 of unique callbacks, some of which could be bound methods - the current behaviour is actively harmful to that use case, since some of the later callbacks may fail to register properly (due to their self comparing equal to another instance of the same type that already had its callback method in the list). That same use case is what makes it useful to consider the same method on a single object to be equal - there is little point in having a bound method like x.notify in a callback list twice. So for myself, +1 on acknowledging issue 1617161 as a bug and fixing it as Armin suggests. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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 basically the same thing (this is sometimes called Soft O notation). Big O is technically an upper-bound anyway. When was the last time a new version caused a function to become slower by more than a factor of O(log n)? As is, some operations *are* documented, but in odd places. For example, the documentation for deque describes the complexity of some of the list type's operations. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD test suite failure - curses
(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, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Equality on method objects
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 equality of bound methods to be based on object value equality, just value identity. ...at least until recently, anyway. I do have one library that wants to have equality-based comparison of im_self. What I ended up doing is writing code that tests what the current Python interpreter is doing, and if necessary implements a special method type, just for purposes of working around the absence of im_self equality testing. However, it's a pretty specialized case, and if I didn't have to support older Python versions I'd just use partial() -- assuming that partial() supports hashing and equality comparisons, that is, which I haven't checked. I imagine hashing a partial() might be at least as tricky as getting bound methods right. :) 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__). +1 for making two bound methods m1 and m2 equal if and only if m1.im_self is m2.im_self and m1.im_func==m2.im_func, and making the hash based on im_func and id(im_self). I don't think that the im_func comparison should be identity-based by default, however. (The im_func could be another bound method, for example.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
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 generators, similar to xranges. Lists would accept these slice objects as indexes, and would also accept any other list or generator. Last, slice objects would be able to be added for multiple index ranges of a list. The new slice object would keep a list of ranges. Optionally, the 1:2 syntax would create a slice object outside of list index areas. It would be shorthand for slice, as [] is for list. This would create some confusion in loops and conditionals due to the colon being used for the end of the structure. (see last example) This would be incompatible with classes that define __setitem__ and __getitem__, and would need changes in how slices are handled in CPython. Therefore, this is probably a proposal for Python 3000. Examples: 1:5 1:5 list(1:5) [1, 2, 3, 4] list(1:5:2) [1, 3] s = 1:3 range(5)[s] [1, 2] 1:5 + 15:17 1:5 + 15:17 range(30)[1:5 + 15:17] [1, 2, 3, 4, 15, 16] range(100)[[1,2,3]] [1, 2, 3] range(100)[1,2,5] # maybe [1, 2, 5] for x in :15:3: print x # maybe 0 3 6 9 12 --- Forrest Voight ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
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. Instead of being containers for the start, end, and step numbers, they would be generators, similar to xranges. I am not sure what you are trying to propose here. The slice object isn't special, it's just a regular built-in type. slice(1,4) slice(1, 4, None) [1,2,3,4,5,6][slice(1,4)] [2, 3, 4] I don't see how introducing new syntax would simplify indexing. Lists would accept these slice objects as indexes, and would also accept any other list or generator. Why lists should accept a list or a generator as index? What is the use case you have in mind? Optionally, the 1:2 syntax would create a slice object outside of list index areas. Again, I don't see how this could be useful... list(1:5) [1, 2, 3, 4] list(1:5:2) [1, 3] list(range(1,5,2))? range(30)[1:5 + 15:17] [1, 2, 3, 4, 15, 16] This is confusing, IMHO, and doesn't provide any advantage over: s = list(range(30)) s[1:5] + s[15:17] If you really needed it, you could define a custom class with a fancy __getitem__ class A: def __getitem__(self, x): return x A()[1:3,2:5] (slice(1, 3, None), slice(2, 5, None)) P.S. You should consider using the python-ideas (http://mail.python.org/mailman/listinfo/python-ideas) mailing list, instead of python-dev for posting suggestions. Cheers, -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RQST: Master Thesis
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 announced new investments and high-profile hires to make Jython a top-quality Python implementation. Alex On Sun, Mar 9, 2008 at 7:42 AM, [EMAIL PROTECTED] wrote: 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 somewhere documented that would be very helpfull... Michal, The best place to start is the implementation of the interpreter itself (Python/ceval.c in the source tree) and the byte code compiler (Python/compile.c). There have, at times, been modest attempts to document what's going on, but I believe the source code is far and away still your best bet. I recommend you get a Subversion checkout of either the trunk: svn co http://svn.python.org/projects/python/trunk or the py3k branch: svn co http://svn.python.org/projects/python/branches/py3k You will find the trunk more stable, but the py3k branch is the future. Also, study the archives of this list and the [EMAIL PROTECTED] list as well as checkin comments for the Python source, especially for the two files I referenced above. Finally, there may well be pending patches in the Python tracker which implement various optimizations: http://bugs.python.org/ Studying them (and trying them out and attaching comments or reviews of their efficacy) would be a good way to help understand the system. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
