Re: [Python-Dev] a quit that actually quits
[EMAIL PROTECTED] wrote: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EOF on Windows, it wouldn't occur to me that I'd also have to hit Return. Without my Python shades I'd never guess to exit via raise SystemExit. While the raise command is one true way, it certainly won't occur to newbies. I have no idea how I'd exit from Pippy or from the interpreter prompt on a Nokia phone without it. In short, I think it makes a lot of sense to support a bare exit and/or quit as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. +1. Reinhold -- Mail address is perfectly valid! ___ 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] a quit that actually quits
[EMAIL PROTECTED] wrote: In short, I think it makes a lot of sense to support a bare exit and/or quit as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. I can readily agree to this part of Fredrik's proposal. What slightly bothers me is the hackish nature of the proposed implementation. 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] Small any/all enhancement
Eric Nieuwland wrote: all(o==0 for o in some_objects) ? all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... And so does the version with generator expressions: Alex' expression will also terminate with the first false statement; it is equivalent to some_objects[0]==0 and some_objects[1]==0 and ... 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] Keep default comparisons - or add a second set?
On 12/27/05, Scott David Daniels [EMAIL PROTECTED] wrote: Tell me: a = [0] * 3 b = [0] * 3 a[0] = b b[0] = a What order should a and b have? More gems: Decimal(3) 4.0 False Decimal(3) == 3.0 False Decimal(3) 4.0 True And the pièce de résistance: l = [2.0, Decimal(3), 3.5, Decimal(4), 5, 3] for i in range(5): random.shuffle(l); print sorted(l) [2.0, Decimal(3), 3, 3.5, Decimal(4), 5] [2.0, 3.5, Decimal(3), 3, Decimal(4), 5] [2.0, Decimal(3), 3, 3.5, Decimal(4), 5] [2.0, 3.5, Decimal(3), 3, Decimal(4), 5] [2.0, 3, 3.5, Decimal(3), Decimal(4), 5] (The positions of 3 and Decimal(3) should be swapping, but the position of 3.5 should not.) -- 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] a quit that actually quits
Martin v. Löwis wrote: In short, I think it makes a lot of sense to support a bare exit and/or quit as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. I can readily agree to this part of Fredrik's proposal. What slightly bothers me is the hackish nature of the proposed implementation. here's my current proposal (see ping's post and my reply for background): if isinstance(exc_value, NameError) and not exc_info.tb_next: text = exc_value[0] name = ... extract name from nameerror string ... if sys.commandline.strip() == name: if name in (exit, quit): raise SystemExit if name == help: help() return ... any suggestions on how to improve this ? /F ___ 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] A few questions about setobject
Noam Raphael wrote:
Is this desirable?
Not sure what this refers to in your message: the text of the C API
documentation certainly is desirable as it stands (although it should
be clearer as to whether struct names should be prefixed).
The setentry typedef clearly violates the principles of the API, so
it should be renamed.
Even if it is, it seems that the second sentence
contradicts the first sentence.
Why does that seem so? To quote, the first sentence is
'All user visible names defined by Python.h (except those defined by
the included standard headers) have one of the prefixes Py or _Py.'
and the second sentence is
'Names beginning with _Py are for internal use by the Python
implementation and should not be used by extension writers.'
I cannot see any contradiction between these.
Perhaps the header file should stick
with writing struct { long hash; PyObject *key; } three times (or
define it in a macro and then undefine it), and the typedef be left to
the .c file?
That would not be conforming to the C language standard (although
accepted by most compilers).
I think it should be ok because it's never used
really as a PyObject. Am I missing something? (Ok, I now thought that
maybe it's because some parts don't treat dummy elements specially.
But it seems to me that most parts do treat them specially, so perhaps
it would be better to make a few changes so that all parts will treat
them specially?)
In principle, you are right. One place that doesn't special-case the
dummy is set_clear_internal (in fact, the Py_DEBUG assertion is
completely useless there, AFAICT).
The tricky question is: can we be certain that we find all places,
in all code paths, where we have to special-case the dummy? Having
PyObject* which don't point to PyObject is error-prone.
Also, what would we gain? If you think it is speed: I doubt it. In
one place, a comment suggests that actually seeing the dummy element
is so much more unlikely than the other cases that, for performance,
the test for the dummy is done last. We would lose additional speed
in the cases where the dummy isn't yet considered.
3) The type of the result of a binary operator applied on a set and a
frozenset is the type of the left set. You are welcomed to ignore
this, but I just wanted to say that it seems to me better to make the
operator symmetric, and to return a frozenset only if both sets are
frozen.
How would you implement this? The result is obtained from copying the
left operand, and then applying the other operand. This is done so
that set subtyping becomes possible:
class myset(set):pass
...
x=myset([2,6])
y=set([2,6])
x.union(y)
myset([2, 6])
So if the result is not obtained by copying the left operand first,
how would you compute the result type, so that this example still
works?
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] a quit that actually quits
Ka-Ping Yee wrote: I'd be happy with having Python exit when the user types just plain 'exit' without parentheses, but only in that case, not others. However, i'm starting to think that may be impossible to implement. I can't think of any way to make 'print exit' not exit, for example. OK, here's one: def quithook(obj, _exit=__builtins__.exit, _displayhook=sys.displayhook): if obj is _exit: raise SystemExit _displayhook(obj) sys.displayhook = quithook It does, however, fall into the whole issue of chaining that Skip brought up earlier. -- Jeremy Kloth Fourthought, Inc. http://fourthought.com/ http://4suite.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] a quit that actually quits
Fredrik Lundh wrote: any suggestions on how to improve this ? Introducing sys.commandline is fine; overriding sys.excepthook still worrisome. What's wrong with triggering this in some __repr__ implementation? If an excepthook must be installed, why couldn't the previous excepthook be preserved, and called in case the exception is not what you are looking for? Of course, even if this excepthook behaves friendly, some other package might overwrite excepthook without preserving yours, in which case people would sometimes get a NameError when they try to exit. 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] a quit that actually quits
Jeremy Kloth wrote: Ka-Ping Yee wrote: I'd be happy with having Python exit when the user types just plain 'exit' without parentheses, but only in that case, not others. However, i'm starting to think that may be impossible to implement. I can't think of any way to make 'print exit' not exit, for example. OK, here's one: def quithook(obj, _exit=__builtins__.exit, _displayhook=sys.displayhook): if obj is _exit: raise SystemExit _displayhook(obj) sys.displayhook = quithook It does, however, fall into the whole issue of chaining that Skip brought up earlier. as well as various introspection-related issues: import foo cb = foo.getcallback() # let's see what it is cb $ (by the way, it's __builtin__, not __builtins__. the former is a module, the latter a CPython implementation detail) /F ___ 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] deque alternative
Tim Peters wrote: You seem to be ignoring possiblities for sharing across lists, and such sharing is natural in many graph algorithms. No doubt cons cells are a useful construct. I think Martin Blais (and others) advocated a plain list container type, only implemented as a linked list, instead of a as a vector. The subject is deque alternative, after all. Typically, you either have sharing, or you have appending, but not both. If sharing is what you want, 2-tuples (pairs) provide an adequate API (IMO). If you want a deque alternative, sharing won't happen. 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] deque alternative
Phillip J. Eby wrote: Since I routinely use 2-item tuples (twoples?) I've been using pairs to describe that datatype. Not sure how common it is in English, but in German, Zweitupel is often called Paar. 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] status of development documentation
Neal Norwitz [EMAIL PROTECTED] writes: On 12/23/05, Tim Peters [EMAIL PROTECTED] wrote: _assumed_ this was known damage everywhere so was waiting for someone else to fix it ;-) (A parenthentical question: is there a reason you don't pass -uall to regrtest.py?) It's calling make test. You could call make testall instead? Cheers, mwh (catching up, so: thanks!) -- I never disputed the Perl hacking skill of the Slashdot creators. My objections are to the editors' taste, the site's ugly visual design, and the Slashdot community's raging stupidity. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq ___ 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] a quit that actually quits
Martin v. Löwis wrote: Introducing sys.commandline is fine; overriding sys.excepthook still worrisome. What's wrong with triggering this in some __repr__ implementation? because simple introspection may exit your program. unexpected exits are a lot more annoying than unexpected non-exits. If an excepthook must be installed, why couldn't the previous excepthook be preserved, and called in case the exception is not what you are looking for? this is done in site.py, before sitecustomize is loaded. I'm not sure how anyone else would be able to squeeze in an excepthook at this point, even if they wanted... Of course, even if this excepthook behaves friendly, some other package might overwrite excepthook without preserving yours, in which case people would sometimes get a NameError when they try to exit. sure, but people may sometimes get another result if they rebind exit (e.g. from sys import *), plug in a broken displayhook, or other- wise mess up their system. as long the documentation mentions how this works, and urges excepthook developers to be careful, I don't really see this as a problem. /F ___ 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] floating point literals don't work in non-US locale in 2.5
someone recently broke floating point literals in a rather spectacular way: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) Type help, copyright, credits or license for more information. 3.14 3.1401 import locale locale.setlocale(locale.LC_ALL, ) 'sv_SE.utf8' 3.14 3.0 more here: http://www.python.org/sf/1391872 /F ___ 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] a quit that actually quits
[EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of if input.rstrip() == 'exit': sys.exit() in the implementation of the interactive interpreter? Cheers, mwh -- My first thought was someone should offer Mr. Bush elocution lessons. But he'd probably say he knew how to work them chairs already.-- Internet Oracularity #1294-01 ___ 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] a quit that actually quits
Michael Hudson wrote: [EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. also worth remarking is that is quite a FAQ at least for Jython, how to convince python to accept bare words (plus args) as function calls. So this magic is confusing and in the wrong direction from that point of view, given that we don't plan to support that at all. In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of if input.rstrip() == 'exit': sys.exit() in the implementation of the interactive interpreter? Cheers, mwh ___ 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] a quit that actually quits
Michael Hudson wrote: In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of if input.rstrip() == 'exit': sys.exit() in the implementation of the interactive interpreter? that would turn exit and quit into reserved keywords. /F ___ 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] A few questions about setobject
On 12/28/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
The setentry typedef clearly violates the principles of the API, so
it should be renamed.
(And so will _setobject, although I think it will be much easier to remove it.)
Perhaps the header file should stick
with writing struct { long hash; PyObject *key; } three times (or
define it in a macro and then undefine it), and the typedef be left to
the .c file?
That would not be conforming to the C language standard (although
accepted by most compilers).
Can you explain why it is not conforming to the standard? Can't a
typedef be used intechangably with the original type?
Not sure what this refers to in your message: the text of the C API
documentation certainly is desirable as it stands (although it should
be clearer as to whether struct names should be prefixed).
Even if it is, it seems that the second sentence
contradicts the first sentence.
Why does that seem so? To quote, the first sentence is
'All user visible names defined by Python.h (except those defined by
the included standard headers) have one of the prefixes Py or _Py.'
and the second sentence is
'Names beginning with _Py are for internal use by the Python
implementation and should not be used by extension writers.'
I cannot see any contradiction between these.
Oops. It's the first and the third:
The first: All user visible names defined by Python.h (except those
defined by the included standard headers) have one of the prefixes
Py or _Py.
The third: Structure member names do not have a reserved prefix.
I think that structure member names refers to things like setentry.
The third sentence contradicts the first since structure member names
are user visible names. Anyway, it seems to me best if the third
sentence will be removed and all names will start with Py or _Py.
I think it should be ok because it's never used
really as a PyObject. Am I missing something? (Ok, I now thought that
maybe it's because some parts don't treat dummy elements specially.
But it seems to me that most parts do treat them specially, so perhaps
it would be better to make a few changes so that all parts will treat
them specially?)
In principle, you are right. One place that doesn't special-case the
dummy is set_clear_internal (in fact, the Py_DEBUG assertion is
completely useless there, AFAICT).
The tricky question is: can we be certain that we find all places,
in all code paths, where we have to special-case the dummy? Having
PyObject* which don't point to PyObject is error-prone.
Also, what would we gain? If you think it is speed: I doubt it. In
one place, a comment suggests that actually seeing the dummy element
is so much more unlikely than the other cases that, for performance,
the test for the dummy is done last. We would lose additional speed
in the cases where the dummy isn't yet considered.
Ok, I tried. It took me 25 minutes to change the code, while going
over every occurence of key and decref in setobject.c. (It seems
to me that the dummy element can only be accessed from entry-key.)
Most of the code isn't bothered by the dummy element, since it uses
the data structure in a more abstract way. I think that it simplifies
the code, while adding a condition in only two places, which I don't
think should make anything noticably slower. The result passes the
complete test suite. In one sentence: I think that it makes the code
slightly better, and the risk is pretty low.
I thought to post it as a patch, but sourceforge didn't work for me,
and it's not that long, so I paste it at the end of this message. Feel
free to do whatever you want with it.
3) The type of the result of a binary operator applied on a set and a
frozenset is the type of the left set. You are welcomed to ignore
this, but I just wanted to say that it seems to me better to make the
operator symmetric, and to return a frozenset only if both sets are
frozen.
How would you implement this? The result is obtained from copying the
left operand, and then applying the other operand. This is done so
that set subtyping becomes possible:
class myset(set):pass
...
x=myset([2,6])
y=set([2,6])
x.union(y)
myset([2, 6])
So if the result is not obtained by copying the left operand first,
how would you compute the result type, so that this example still
works?
The behaviour will change to work like in other types - the returned
value will be of the base type:
class MyInt(int): pass
...
x = MyInt(3)
y = 5
x.__add__(y)
8
I'm not talking about backwards compatibility - I'm just currently
asking if others also feel that the symmetric version is preferable.
Ok, here's the diff:
=== modified file 'Objects/setobject.c'
--- Objects/setobject.c
+++ Objects/setobject.c
@@ -13,8 +13,12 @@
/* This must be = 1. */
#define PERTURB_SHIFT 5
-/* Object used as dummy key to fill deleted entries */
-static PyObject *dummy = NULL; /* Initialized by first call to
make_new_set() */
+/*
Re: [Python-Dev] A few questions about setobject
Noam Raphael wrote: The setentry typedef clearly violates the principles of the API, so it should be renamed. (And so will _setobject, although I think it will be much easier to remove it.) That's not that certain. setentry is a typedef; _setobject is a tag name of a struct. The documentation is silent as to whether tag names also follow the prefixing rules. Many tag names don't, e.g. PyObject is a typedef for struct _object. That would not be conforming to the C language standard (although accepted by most compilers). Can you explain why it is not conforming to the standard? Can't a typedef be used intechangably with the original type? 6.2.7 of ISO C says 6.2.7 Compatible type and composite type [#1] Two types have compatible type if their types are the same. Additional rules for determining whether two types are compatible are described in 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.5 for declarators.46) Moreover, two structure, union, or enumerated types declared in separate translation units ... We are not dealing with separate translation units here, so I cut the paragraph. I'm also ommitting several other exceptions where types are compatible (e.g. enum types are compatible with the underlying integral type). Pointer types are compatible if the underlying types are compatible, and the types have the same qualifiers. So if you mention an equally-layouted struct twice in the same translation unit, you still get incompatible types. As a result, pointers to these structs are also incompatible, so you cannot assign between them. The first: All user visible names defined by Python.h (except those defined by the included standard headers) have one of the prefixes Py or _Py. The third: Structure member names do not have a reserved prefix. I think that structure member names refers to things like setentry. Ah. It doesn't. It means things like hash and key (for setentry), or fill, used, mask, table, ... (for struct _setobject). That they don't use a name prefix means that there could be a collision with macro names (and indeed, that has happened). The third sentence contradicts the first since structure member names are user visible names. Anyway, it seems to me best if the third sentence will be removed and all names will start with Py or _Py. No. Do you really want ob_type to be renamed to Py_ob_type? 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] a quit that actually quits
Fredrik Lundh [EMAIL PROTECTED] writes: Michael Hudson wrote: In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of if input.rstrip() == 'exit': sys.exit() in the implementation of the interactive interpreter? that would turn exit and quit into reserved keywords. In what sense? Not in the sense of things in single quotes in Grammar... Cheers, mwh -- There are two kinds of large software systems: those that evolved from small systems and those that don't work. -- Seen on slashdot.org, then quoted by amk ___ 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
Hello, I run into a problem recently with a reconnectingclientfactory with twisted while write some spare time software, that turned out to be a gc inefficiency. In short the protocol memory wasn't released after the reconnect and the protocol had about 50M attached to it. So with frequent reconnects the rss of the task grown to 1G and it pushed the system into heavy swap. In reality only 50M were allocated, so 950M were wasted by python. A gc.collect() explicit invocation at every retry of the factory fixed it. However this means there is significant room for improvement in the default behaviour of the python gc. In short the real bug is that the python gc isn't working in function of size in any way. It doesn't matter the number of objects, it matters their size! The whole story can be found in this thread: http://twistedmatrix.com/pipermail/twisted-python/2005-December/012233.html My suggestion to fix this problem in autopilot mode (without requiring explicit gc.collect()) is to invoke a gc.collect() (or anyway to go deep down freeing everything possible) at least once every time the amount of anonymous memory allocated by the interpreter doubles. The tunable should be a float = 1. When the tunable is 1 the feature is disabled (so it works like current python today). Default should be 2 (which means to invoke gc.collect() after a 100% increase of the anonymous memory allocated by the interpreter). We could also have yet another threshold that sets a minimum of ram after which this heuristic in function of size kicks in, but it's not very important and it may not be worth it (whem little memory is involved gc.collect() should be fast anyway). To implement this we need two hooks, in the malloc and free that allocate python objects. Then we have to store the minimum of this value (i.e. the last minimum of memory allocated by the interpreter). The algorithm I'd suggest is like this (supposedly readable pseudocode): gc.set_collect_mem_growth(v): assert float(v) = 1 gc.collect_mem_growth = v python_malloc(size): ram_size += size if ram_size min_ram_size * gc.collect_mem_growth: gc.collect() # python_free runs inside it min_ram_size = ram_size # ram size after gc.collect() python_free(size): ram_size -= size min_ram_size = min(min_ram_size, size) The overhead of this should be zero, and it'll fix my testcase just fine. I believe the default should be 2 (equivalent to 100% growth of rss to trigger a full collect) even though it alters the behaviour of the gc, I think it's a bug that so much memory can be leaked when it could be reclaimed istantly. I wouldn't change other parameters, this heuristic in function of size would be completely orthogonal and disconnected by the current heuristics in function of the number of elements. It has taken me a day and precious help from the twisted folks to realize it wasn't a memleak in my twisted spare time application (but well, it was good since I learnt about the fact I created an heisenbug by using __del__ to debug the apparent memleak ;). Thanks. ___ 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] a quit that actually quits
Michael Hudson wrote: that would turn exit and quit into reserved keywords. In what sense? Not in the sense of things in single quotes in Grammar... no, but in the sense of names that can no longer be used in code def exit(): ... print bye # what is it? exit $ oops! the whole nameerror thing is there to avoid problems if you create your own exit variables/functions/classes/modules. /F ___ 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] a quit that actually quits
Fredrik if isinstance(exc_value, NameError) and not exc_info.tb_next: Fredrik text = exc_value[0] Fredrik name = ... extract name from nameerror string ... Fredrik if sys.commandline.strip() == name: Fredrik if name in (exit, quit): Fredrik raise SystemExit Fredrik if name == help: Fredrik help() Fredrik return Fredrik ... Fredrik any suggestions on how to improve this ? I'd make it sys._last_input or something similar to make it clear that a) this is magic, don't mess with it, and that b) this is the last user input, not the raw command line. 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
Re: [Python-Dev] Keep default comparisons - or add a second set?
And another example: a = 1+2j b = 2+1j a b Traceback (most recent call last): File stdin, line 1, in module TypeError: no ordering relation is defined for complex numbers I came to think that, when forgetting backwards compatibility for a while, the best thing for comparison operators to do is to raise a TypeError by default, and work only for types that it makes sense to compare. I think it is more explicit is better than implicit, and I have now two reasons for that: 1. Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that Decimals should not be compared to floats, instead of returning false constantly). 2. It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. Perhaps you can explain to me again why arbitrary objects should be comparable? I don't see why sorting objects according to values should work when the order has no real meaning. I don't see why you need all objects to be comparable for storing them in containers with the behaviour of dict or set. If the reason is that you want containers that work among multiple sessions, and are identity-based (that is, only one object can be used as a key), you can attach to each object an id that isn't session dependent, and use that instead of the default memory address. It may be a reason for dropping the default hash is id: suppose that you want a persistent storage that will work like dicts but will not be associated with one Python session (it may be exactly Zope's BTrees - I don't know). Currently you have a problem with using __hash__ for that purpose, since the hash value of an object can change between sessions - that happens when it's the id of the object. Now suppose that we have a persistent id function - it can be implemented by using weakrefs to associate a unique value with an object on the first time that the function is called, and storing it with the object when serializing it. Also suppose that we drop the default hash method, so where currently hash(x) is id(x), hash(x) will raise a TypeError. Then our persistent storage can use the persistent id instead of the default id, and it will work. (You might not want mutable objects to be used as keys, but that's another problem - the data structure will be consistent anyway.) In fewer words, the built-in id() is just one way to assign identities to objects. __hash__ shouldn't use it implicitly when there's no value-based hash value - if it wouldn't, the rule that x == y - hash(x) == hash(y) will be preserved also between different sessions, so persistent objects would be able to use hash values. Does it make sense to you? Noam ___ 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
On Tue, Dec 27, 2005, Andrea Arcangeli wrote: My suggestion to fix this problem in autopilot mode (without requiring explicit gc.collect()) is to invoke a gc.collect() (or anyway to go deep down freeing everything possible) at least once every time the amount of anonymous memory allocated by the interpreter doubles. The tunable should be a float = 1. When the tunable is 1 the feature is disabled (so it works like current python today). Default should be 2 (which means to invoke gc.collect() after a 100% increase of the anonymous memory allocated by the interpreter). We could also have yet another threshold that sets a minimum of ram after which this heuristic in function of size kicks in, but it's not very important and it may not be worth it (whem little memory is involved gc.collect() should be fast anyway). If you feel comfortable with C code, the best way to get this to happen would be to make the change yourself, then test to find out what effects this has on Python (in terms of speed and memory usage and whether it breaks any of the regression tests). Once you've satisfied yourself that it works, submit a patch, and post here again with the SF number. Note that since your tunable parameter is presumably accessible from Python code, you'll also need to submit doc patches and tests to verify that it's working correctly. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) ___ 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] Keep default comparisons - or add a second set?
On Wednesday, December 28, 2005 Noam Raphael wrote: I came to think that, when forgetting backwards compatibility for a while, the best thing for comparison operators to do is to raise a TypeError by default, and work only for types that it makes sense to compare. I think it is more explicit is better than implicit, and I have now two reasons for that: 1. Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that Decimals should not be compared to floats, instead of returning false constantly). 2. It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. I agree. Here's what happens if you try to compare a string and an int in .NET (it's a compiler error): error CS0019: Operator '' cannot be applied to operands of type 'string' and 'int' error CS0019: Operator '==' cannot be applied to operands of type 'string' and 'int' Of course, C# is not a dynamic language so things are stricter in general. Maybe having == and != work for whatever combination of types is not such a bad thing. After all, 10 != text, but then what about Decimal(3.0) == 3.0? It doesn't make sense to say that a function object is smaller or bigger than a string. And if you sort a list of different objects based on theirs address or something similar, can you really consider that list sorted? If you want to normalize a list, you can sort it by using id(item) as a key and not rely on default comparasions. ___ 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] a quit that actually quits
Fredrik Lundh wrote: this is done in site.py, before sitecustomize is loaded. I'm not sure how anyone else would be able to squeeze in an excepthook at this point, even if they wanted... I see. Still, I think the Python code should give a good example. There *is* an excepthook installed at that point, anyway, so we should use it. Otherwise, I think the approach is fine. 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] a quit that actually quits
Michael Hudson wrote: The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. That would assume that the user knows that exit is a function: apparently, people expect it to be a statement (like print), or they are entirely unaware of the distinctions between statements, expressions, and functions. I often find that my students call them commands collectively (if they want to be more specific, they call the functions methods). 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
Andrea Arcangeli wrote: To implement this we need two hooks, in the malloc and free that allocate python objects. Then we have to store the minimum of this value (i.e. the last minimum of memory allocated by the interpreter). I would like to underline Aahz' comment: it is unlikely that anything will happen about this unless you make it happen. This specific problem is not frequent, and the current strategy (collect if 1000 new objects are allocated) works fine for most people. So if you want a change, you should really consider comming up with a patch yourself. Bonus points if the code integrates with the current strategies, instead of replacing them. 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] Keep default comparisons - or add a second set?
On 12/28/05, Noam Raphael [EMAIL PROTECTED] wrote: And another example: a = 1+2j b = 2+1j a b Traceback (most recent call last): File stdin, line 1, in module TypeError: no ordering relation is defined for complex numbers I came to think that, when forgetting backwards compatibility for a while, the best thing for comparison operators to do is to raise a TypeError by default, and work only for types that it makes sense to compare. I think it is more explicit is better than implicit, and I have now two reasons for that: 1. Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that Decimals should not be compared to floats, instead of returning false constantly). 2. It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. I agree for greaterthan and lessthan operators but I'm not convinced for equality. Consider this in contrast to your example: a = 1+2j b = 1+2j a is b False a == b True Complex numbers can't be sorted but they can be tested for equality. Decimal numbers can't currently be tested for equality against a float but there's no loss-of-accuracy argument to prevent it (just a difficulty of implementation one.) If the comparison is to fail I would prefer an exception rather than an id-based fallback though. Speaking of id, there's no reason why id(a) == id(b) has to fail for mismatched types in the face of persistence so long as the result of id() has the same lifetime as the target object. This could be done using weakrefs or by making an id type with a strong reference to the target object. -- 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] Keep default comparisons - or add a second set?
On 12/28/05, Adam Olsen [EMAIL PROTECTED] wrote: I agree for greaterthan and lessthan operators but I'm not convinced for equality. Consider this in contrast to your example: a = 1+2j b = 1+2j a is b False a == b True Complex numbers can't be sorted but they can be tested for equality. Decimal numbers can't currently be tested for equality against a float but there's no loss-of-accuracy argument to prevent it (just a difficulty of implementation one.) If the comparison is to fail I would prefer an exception rather than an id-based fallback though. I think we agree. I don't think that every type that supports equality comparison should support order comparison. I think that if there's no meaningful comparison (whether equality or order), an exception should be raised. Speaking of id, there's no reason why id(a) == id(b) has to fail for mismatched types in the face of persistence so long as the result of id() has the same lifetime as the target object. This could be done using weakrefs or by making an id type with a strong reference to the target object. I don't mean to change the current behaviour of id() - I just meant that an additional one may be implemented, possible by a specific library (Zope, for instance), so the built-in one shouldn't be used as a fallback default. Noam ___ 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] PyCon TX 2006: Early-bird registration ends Dec. 31!
Early bird registration for PyCon TX 2006 ends on December 31st, so there are only a few days LEFT. To register, please visit: http://us.pycon.org/TX2006/Registration You can still register after Dec. 31st, but the cost will go up by US$65 (US$25 for students). This year PyCon will feature a day of tutorials before the three days of regular presentations. Course outlines for all the tutorials have been posted; see http://wiki.python.org/moin/PyCon2006/Tutorials All of the PyCon tutorials are still open for new registrations, but space is limited, and we suspect they'll all be filled up by the time early-bird registration closes. Don't forget to book your hotel room, too. PyCon TX 2006 is being held at a Dallas/Addison hotel, and we have negotiated a special low rate: http://us.pycon.org/Addison/Hotels We hope to see you in Texas! -- David Goodger (on behalf of A.M. Kuchling, Chair, PyCon 2006) signature.asc Description: OpenPGP digital signature ___ 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] Keep default comparisons - or add a second set?
On 12/28/05, Noam Raphael [EMAIL PROTECTED] wrote: On 12/28/05, Adam Olsen [EMAIL PROTECTED] wrote: Speaking of id, there's no reason why id(a) == id(b) has to fail for mismatched types in the face of persistence so long as the result of id() has the same lifetime as the target object. This could be done using weakrefs or by making an id type with a strong reference to the target object. I don't mean to change the current behaviour of id() - I just meant that an additional one may be implemented, possible by a specific library (Zope, for instance), so the built-in one shouldn't be used as a fallback default. Why aim low when you can aim for the face instead? :) -- 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] Small any/all enhancement
On Dec 27, 2005, at 11:06 PM, Eric Nieuwland wrote: ... def zerop(x): return x==0 all(some_objects, zerop) and why would that be better than all(o==0 for o in some_objects) ? all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes Of course it can -- in both formulations. genexp's are also computed as needed, only one item at a time: you appear to imply they don't, maybe you're confusing them with list comprehensions. What I'm asking is, what are the ADVANTAGES of the pred form, that make it worth paying the conceptual cost of having two obvious ways to do one task. all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... ...and also the equivalent of all(pred(s) for s in seq) -- which is exactly my problem: I don't like redundant good ways of expressing identical tasks. The genexp will often be more compact, whenever the 'pred' requires a def, a lambda, or something like operator.attrgetter, anyway. Alex ___ 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] Automated Python testing (was Re: status of development documentation)
On Sun, Dec 25, 2005 at 12:54:32PM -0500, Tim Peters wrote: This really helps at Zope Corp. One downside is that we seem unable to get an in-house Windows buildbot slave to work reliably, and so far don't even know whether that's because of Windows, the buildbot code, or flakiness in our internal network. It seems quite reliable on Linux, though. At work we build both py2exe'd apps and Visual C++ apps on windows with buildbot with no issues. The only problem we has was when we were first setting it up, it was not clear that you need to explicitly tell twistd to use the win32 reactor. -Chris ___ 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] deque alternative
On Dec 28, 2005, at 2:57 AM, Martin v. Löwis wrote: Phillip J. Eby wrote: Since I routinely use 2-item tuples (twoples?) I've been using pairs to describe that datatype. Not sure how common it is in English, but in German, Zweitupel is often called Paar. I use 'pair', too, admittedly by analogy with C++'s std::pair type. (The Italian closest word paio would imply that the two items are in some sense homogeneous; to avoid that implication one would use coppia, which differently from English a couple ALWAYS, not just sometimes, implies exactly two items; so I can't base myself on analogies with my own mothertongue;-). Alex ___ 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] a quit that actually quits
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote: [EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which just mentioning X means call function Y [with the following arguments], at least at the interactive prompt if not more generally. If /F's idea gets implemented by binding to names 'exit' and 'quit' the result of some factory-call with function to be called set to sys.exit and arguments for it set to () [[as opposed to specialcasing checks of last commandline for equality to 'exit' c]] then the implementation of the generalization would be no harder. I do find myself in sessions in which I want to perform some action repeatedly, and currently the least typing is 4 characters (x()enter) while this would reduce it to two (iPython does allow such handy shortcuts, but I'm often using plain interactive interpreters). If this generalization means a complicated implementation, by all means let's scrap it, but if implementation is roughly as easy, it may be worth considering to avoid making a too-special special case (or maybe not, but brainstorming means never having to say you're sorry;-). Alex ___ 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] Automated Python testing (was Re: status of development documentation)
Tim Peters wrote: Someone sets up a buildbot master That's what I now did: http://www.python.org/dev/buildbot/ I'm not quite sure on a number of concepts: should there be multiple slaves per builder? Should I have multiple factories? How should I pass build-machine specific information (like: what compiler to use) in the master, or is that a slave thing? How should I deal with branches? Anyhow, I created two builders, both with the same slave, on sparc-sun-solaris2.10, 32-bit mode, gcc. The python-full builder does svn export, whereas the python-quick builder does svn update. Each of these is associated with an AnyBranchScheduler, for both 'trunk' and 'tags/release24-maint'. Not sure whether this means that the 2.4 release branch will ever be built (as the SVN steps have a defaultBranch of trunk). If anybody wants to contribute additional builders, or has ideas for organizing this all, please let me know. 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] a quit that actually quits
Alex Martelli wrote: On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote: [EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which just mentioning X means call function Y [with the following arguments], at least at the interactive prompt if not more generally. If /F's idea gets implemented by binding to names 'exit' and 'quit' the result of some factory-call with function to be called set to sys.exit and arguments for it set to () [[as opposed to specialcasing checks of last commandline for equality to 'exit' c]] We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help and it might make implementing alternative shells for Python easier (without having to subclass code.InteractiveConsole). then the implementation of the generalization would be no harder. I do find myself in sessions in which I want to perform some action repeatedly, and currently the least typing is 4 characters (x()enter) while this would reduce it to two What's wrong with cursor up, return? (iPython does allow such handy shortcuts, but I'm often using plain interactive interpreters). If this generalization means a complicated implementation, by all means let's scrap it, but if implementation is roughly as easy, it may be worth considering to avoid making a too-special special case (or maybe not, but brainstorming means never having to say you're sorry;-). Bye, Walter Dörwald ___ 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] a quit that actually quits
[Alex] Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which just mentioning X means call function Y [with the following arguments], at least at the interactive prompt if not more generally. If /F's idea gets implemented by binding to names 'exit' and 'quit' the result of some factory-call with function to be called set to sys.exit and arguments for it set to () [[as opposed to specialcasing checks of last commandline for equality to 'exit' c]] [Walter] We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help and it might make implementing alternative shells for Python easier (without having to subclass code.InteractiveConsole). [Alex] then the implementation of the generalization would be no harder. I do find myself in sessions in which I want to perform some action repeatedly, and currently the least typing is 4 characters (x()enter) while this would reduce it to two Hmm. . . def default_inputhook(statement): try: aliased = sys.aliases[statement] except KeyError: return False else: aliased() return True sys.aliases = dict(exit=sys.exit, quit=sys.exit) sys.inputhook = default_inputhook I think Walter's idea may have merit (although I believe the input hook should be passed whole statements, rather than individual lines). 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] Automated Python testing (was Re: status of development documentation)
On Wed, 28 Dec 2005 17:43:04 +0100, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: Tim Peters wrote: Someone sets up a buildbot master That's what I now did: http://www.python.org/dev/buildbot/ I'm not quite sure on a number of concepts: should there be multiple slaves per builder? Should I have multiple factories? How should I pass build-machine specific information (like: what compiler to use) in the master, or is that a slave thing? How should I deal with branches? A slave is an entity capable of performing tasks. It can be asked to perform any task you like, though it may not be able to perform them all if it lacks some requirements. A builder is a particular job. It can be performed by any slave (so long as its requirements are met), or by multiple slaves. A factory defines the work to be done by a builder. If which compiler is being used is an important part of the purpose of a builder (for example, there might be a builder the purpose of which is to test a Python built with GCC 3.4 and another the purpose of which is to test a Python built with GCC 4.0), then it should be specified in the master configuration. If it is not important, then it should be left as general as possible, to allow for the most slaves to be able to complete the task. I have most often seen branches supported by allowing commits to trunk to automatically trigger a build on trunk, while commits to branches do not automatically trigger any builds. Builds on branches can then be explicitly requested when a developer wants to know the state of their branch on various platforms/configurations (often before merging to trunk to know if they are introducing any regressions, but valuable at other times as well). To support branches in this way, you want to use a PBChangeSource with a prefix of trunk and when creating build steps, specify a a baseURL of svn//svn.python.org/projects/python/, and defaultBranch of trunk. Anyhow, I created two builders, both with the same slave, on sparc-sun-solaris2.10, 32-bit mode, gcc. The python-full builder does svn export, whereas the python-quick builder does svn update. Each of these is associated with an AnyBranchScheduler, for both 'trunk' and 'tags/release24-maint'. Not sure whether this means that the 2.4 release branch will ever be built (as the SVN steps have a defaultBranch of trunk). I think this means tags/release24-maint won't ever be built automatically (I haven't used AnyBranchScheduler, and I don't know much about schedulers in buildbot in general). You should be able to manually request a build, but for some reason I don't see the form for doing so on the master website (http://twistedmatrix.com/buildbot/full-2.3 for an example of what this looks like). I'm not sure if this is a buildbot version problem, or if there is just another piece of configuration that needs to be set. Jean-Paul ___ 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] A few questions about setobject
The setentry typedef clearly violates the principles of the API, so it should be renamed. In my next update, will rename it to match the Py or _Py convention. Raymond ___ 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] a quit that actually quits
On 12/28/05, Walter Dörwald [EMAIL PROTECTED] wrote: ... We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? Sure, particularly with Nick's suggestion for a default input hook it would be fine. sessions in which I want to perform some action repeatedly, and currently the least typing is 4 characters (x()enter) while this would reduce it to two What's wrong with cursor up, return? The fact that there is no upper bound to the number of cursor-up keystrokes needed here -- by perform some action repeatedly I don't mean half a dozen times right after each other with nothing in-between (sorry for the ambiguous phrasing), but numerous times, repeatedly in the course of an interactive interpreter session. Alex ___ 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] A few questions about setobject
I think it should be ok because it's never used really as a PyObject. Am I missing something? (Ok, I now thought that maybe it's because some parts don't treat dummy elements specially. But it seems to me that most parts do treat them specially, so perhaps it would be better to make a few changes so that all parts will treat them specially?) In principle, you are right. One place that doesn't special-case the dummy is set_clear_internal (in fact, the Py_DEBUG assertion is completely useless there, AFAICT). The tricky question is: can we be certain that we find all places, in all code paths, where we have to special-case the dummy? Having PyObject* which don't point to PyObject is error-prone. Also, what would we gain? If you think it is speed: I doubt it. In one place, a comment suggests that actually seeing the dummy element is so much more unlikely than the other cases that, for performance, the test for the dummy is done last. We would lose additional speed in the cases where the dummy isn't yet considered. Ok, I tried. It took me 25 minutes to change the code, while going over every occurence of key and decref in setobject.c. (It seems to me that the dummy element can only be accessed from entry-key.) Most of the code isn't bothered by the dummy element, since it uses the data structure in a more abstract way. I think that it simplifies the code, while adding a condition in only two places, which I don't think should make anything noticably slower. The result passes the complete test suite. In one sentence: I think that it makes the code slightly better, and the risk is pretty low. I thought to post it as a patch, but sourceforge didn't work for me, and it's not that long, so I paste it at the end of this message. Feel free to do whatever you want with it. Feel free to send me your patch (as an attachment, not the body of an email) and I'll take another look at it. We discussed this a few months ago and rejected it. I'll look back to find the reason why (perhaps to keep parallel with dictobject.c or because it was thought to be an error-prone micro-optimization). Raymond ___ 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] Small any/all enhancement
I wrote: all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... then, Martin v. Löwis wrote: And so does the version with generator expressions: Alex' expression will also terminate with the first false statement; it is equivalent to some_objects[0]==0 and some_objects[1]==0 and ... and Alex Martelli wrote: Of course it can -- in both formulations. genexp's are also computed as needed, only one item at a time: you appear to imply they don't, maybe you're confusing them with list comprehensions. What I'm asking is, what are the ADVANTAGES of the pred form, that make it worth paying the conceptual cost of having two obvious ways to do one task. all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... ...and also the equivalent of all(pred(s) for s in seq) -- which is exactly my problem: I don't like redundant good ways of expressing identical tasks. The genexp will often be more compact, whenever the 'pred' requires a def, a lambda, or something like operator.attrgetter, anyway. Oops! Right you are. I was a bit too quick after seeing the use of map() proposed. --eric ___ 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] a quit that actually quits
Walter Dörwald wrote: We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help /.../ so how would such a hook deal with the def exit(): ... pass exit case ? /F ___ 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] a quit that actually quits
Alex Martelli wrote: On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote: The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which just mentioning X means call function Y [with the following arguments], at least at the interactive prompt if not more generally. If /F's idea gets implemented by binding to names 'exit' and 'quit' the result of some factory-call with function to be called set to sys.exit and arguments for it set to () [[as opposed to specialcasing checks of last commandline for equality to 'exit' c]] then the implementation of the generalization would be no harder. I do find myself in sessions in which I want to perform some action repeatedly, and currently the least typing is 4 characters (x()enter) while this would reduce it to two (iPython does allow such handy shortcuts, but I'm often using plain interactive interpreters). If this generalization means a complicated implementation, by all means let's scrap it, but if implementation is roughly as easy, it may be worth considering to avoid making a too-special special case (or maybe not, but brainstorming means never having to say you're sorry;-). Allow me to add a few comments, here: as the ipython author, I happen to have thought an awful lot about all these issues. First, your suggestion of incorporating 'autocalling' ( the automatic 'foo a' - 'foo(a)' transformation) into the core python interpreter may not be a very good idea. The code that does this is precisely the most brittle, delicate part of ipython, a little regexp/eval/introspection dance that tries really, really hard to understand whether 'foo' is a string that will point to a callable once evaluated, but without eating generators, causing side effects, or anything else. I know it sounds silly, and perhaps it's just my limitations, but it has taken several years to flesh out all the corner cases where this code could fail (and in the past, a few really surprising failure cases have been found). In ipython, this functionality can still be turned off (via %autocall) at any time, in case it is not working correctly. You are welcome to look at the code, it's the _prefilter method here: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/iplib.py So while I think that this is extremely useful in a third-party library like ipython, it's probably a little too delicate for the core, official interpreter where reliability is so absolutely critical. In fact, my own standard is that I trust the CPython prompt as a test of 'doing the right thing', so I like that it remains simple and solid. Now, on to the wider discussion started by the quit/exit debate: the problem is that we are here trying to make some particular words 'interactive commands' in a language that doesn't have such a notion to begin with. The tension of how best to implement it, the various low-level tricks proposed, etc, stems (I think) from this underlying fact. In IPyhton, I've convinced myself that this is a problem whose proper solution requires an orthogonal command subsystem, the 'magics' (credit where credit is due: the magic system was already in IPP, Janko Hauser's library which was one of ipython's three original components; Janko understood the issue early on and got it right). This creates a separate namespace, controlled by a disambiguation character (the % prefix in ipython), and therefore allows you to cleanly offer the kind of behavior and semantics which are more convenient for command-line use (whitespace argument separation, --dashed-options) without colliding with the underlying language. By having the 'magic' command system be separate, it is also trivially extensible by the users (see http://ipython.scipy.org/doc/manual/node6.html#SECTION00062000 for details). This means that instead of going into a never-ending rabbit-chase of special cases, you now have a well-defined API (IPython's is primitive but it works, and we're cleaning it up as part of a major rework) where users can add arbitrary command functionality which remains separate from the language itself. The main point here is, I think, that any good interactive environment for a programming language requires at least TWO separate kinds of syntax: 1. the language itself, perhaps with aids to economize typing at the command line (ipython offers many: auto-calling, auto-quoting, readline tricks, input history as a Python list, output caching, macros, and more). 2. a set of control commands, meant to manipulate the environment itself. These can obviously be implemented in the underlying language, but there should be a way to keep them in a separate namespace (so they don't collide with user variables and can be always called).
Re: [Python-Dev] a quit that actually quits
[Alex Martelli] On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote: [EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of Fredric printing a you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which just mentioning X means call function Y [with the following arguments], at least at the interactive prompt if not more generally. Just brainstorming then! :-) The fact that dot notation is used both for accessing globals from a module, and attributes from a class or an instance, does not mean that modules are classes, but surely, they are instances of something, and maybe we could build more on the similarities despite the differences. Through __getattr__ (and also properties and more generally descriptors), it is possible to create instance attributes triggering functional behaviour. Maybe it could be useful creating some (vaguely) similar mechanism for modules' globals. Then, `quit' and `exit' could be mere cases of that mechanism. It is desirable, in my opinion, that interactive behaviour be as identical as possible as script behaviour: the automatic printing of interactive mode is already much magic that newcomers need to sort out. -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] Automated Python testing (was Re: status of development documentation)
Jean-Paul Calderone wrote: A slave is an entity capable of performing tasks. It can be asked to perform any task you like, though it may not be able to perform them all if it lacks some requirements. This is clear in principle. However, what constitutes a task? I see that you can send it shell commands to execute, arbitrary ones, with environment variables. What else? Can you send it Python code? A builder is a particular job. It can be performed by any slave (so long as its requirements are met), or by multiple slaves. That I'm not so sure of. In a builder, I give a single value slavename, and I understand that only that single slave will ever get jobs from the builder - not any slave. I also read that I can give slavenames instead, but that I should do so only if the slaves are sufficiently similar (for some metric which I apparently have to define myself). A factory defines the work to be done by a builder. If which compiler is being used is an important part of the purpose of a builder (for example, there might be a builder the purpose of which is to test a Python built with GCC 3.4 and another the purpose of which is to test a Python built with GCC 4.0), then it should be specified in the master configuration. If it is not important, then it should be left as general as possible, to allow for the most slaves to be able to complete the task. So would the assumption be that I use the same factory for multiple builders? I'm gravitating towards a 1:1:1 relationship between factories, builders, and slaves. For example, on OSX, I think I have to give --with-suffix=.exe to configure. This means I have to create a separate factory, which then only applies to OSX builders (of which I have only one), which has just a single slavename. I have most often seen branches supported by allowing commits to trunk to automatically trigger a build on trunk, while commits to branches do not automatically trigger any builds. I think I want it differently: commits to release24-maint should also trigger builds; commits to other branches should not trigger builds. Does that mean I need twice as many builders? How do I tell them what branch they should build? Builds on branches can then be explicitly requested when a developer wants to know the state of their branch on various platforms/configurations (often before merging to trunk to know if they are introducing any regressions, but valuable at other times as well). Some people advised me that supporting web-initiated builds is not a good idea. So I turned off all manual triggering of builds for now. I would like to give committers permission to trigger builds, but I'm not sure how to do that. I think this means tags/release24-maint won't ever be built automatically (I haven't used AnyBranchScheduler, and I don't know much about schedulers in buildbot in general). You should be able to manually request a build, but for some reason I don't see the form for doing so on the master website (http://twistedmatrix.com/buildbot/full-2.3 for an example of what this looks like). I'm not sure if this is a buildbot version problem, or if there is just another piece of configuration that needs to be set. Ah, no: that's configuration that would need to be removed. Jeff Pitmann suggested that this feature be disabled (Waterfall(allowForce=False)). Before I did that, there was indeed a form to request building of a branch. 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] a quit that actually quits
Fredrik Lundh wrote: Walter Dörwald wrote: We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help /.../ so how would such a hook deal with the def exit(): ... pass exit case ? In the inputhook one would have to check for exit being defined at interpreter level. Reinhold -- Mail address is perfectly valid! ___ 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] NotImplemented reaching top-level
Armin Rigo wrote:
Hi Facundo,
On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
d += 1.2
d
NotImplemented
The situation appears to be a mess. Some combinations of specific
operators fail to convert NotImplemented to a TypeError, depending on
old- or new-style-class-ness, although this is clearly a bug (e.g. in an
example like yours but using -= instead of +=, we get the correct
TypeError.)
Obviously, we need to write some comprehensive tests about this. But
now I just found out that the old, still-pending SF bug #847024 about
A()*5 in new-style classes hasn't been given any attention; my theory is
that nobody fully understands the convoluted code paths of abstract.c
any more :-(
The PEP documenting the coercion logic has complete tables
for what should happen:
http://www.python.org/peps/pep-0208.html
Looking at the code in abstract.c the above problem appears
to be related to the special cases applied to += and *=
in case both operands cannot deal with the type combination.
In such a case, a check is done whether the operation could
be interpreted as sequence operation (concat or repeat) and
then delegated to the appropriate handlers.
But then again, looking in typeobject.c, the following code
could be the cause for leaking a NotImplemented singleton
reference:
#define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \
static PyObject * \
FUNCNAME(PyObject *self, PyObject *other) \
{ \
static PyObject *cache_str, *rcache_str; \
int do_other = self-ob_type != other-ob_type \
other-ob_type-tp_as_number != NULL \
other-ob_type-tp_as_number-SLOTNAME == TESTFUNC; \
if (self-ob_type-tp_as_number != NULL \
self-ob_type-tp_as_number-SLOTNAME == TESTFUNC) { \
PyObject *r; \
if (do_other \
PyType_IsSubtype(other-ob_type, self-ob_type) \
method_is_overloaded(self, other, ROPSTR)) { \
r = call_maybe( \
other, ROPSTR, rcache_str, (O), self); \
if (r != Py_NotImplemented) \
return r; \
Py_DECREF(r); \
do_other = 0; \
} \
r = call_maybe( \
self, OPSTR, cache_str, (O), other); \
if (r != Py_NotImplemented || \
other-ob_type == self-ob_type) \
^
If both types are of the same type, then a NotImplemented returng
value would be returned.
return r; \
Py_DECREF(r); \
} \
if (do_other) { \
return call_maybe( \
other, ROPSTR, rcache_str, (O), self); \
} \
Py_INCREF(Py_NotImplemented); \
return Py_NotImplemented; \
}
Strange enough, the SLOT1BINFULL macro is not used by the
inplace concat or repeat slots...
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Dec 28 2005)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] Automated Python testing (was Re: status of development documentation)
Jean-Paul Calderone wrote: I guess the config for this particular behavior would look something like... You were right that I needed two schedulers for that. Unfortunately, it doesn't work at all, because svn_buildbot.py does not report branches on which a change happened, so if you have multiple schedulers for a subversion source, they either all build when a change occurs, or none of them. If svn_version knew about branches (which I'll have to implement, or incorporate the patch that I saw somewhere), it would probably work - I have now code to create builders and schedulers in a nested loop. Builds can also be forced using the IRC bot, and there may be a commandline tool for doing this as well. I doubt there's any authentication required when using the IRC bot, so it doesn't really help restrict forcing to commits only. Currently, my buildbot isn't connected to IRC at all. If I ever enable that aspect, I'll use allowForce=False again to disable remotely invoking builds. Another possibility might be to place the form (or just the form action) behind HTTP auth. I'm not sure if this is feasible with the authentication mechanism used to restrict access to the svn repository. Not easily, no. We don't have passwords from the committers, and authentication through SSH keys is not supported in the Web. If people really need to be able to force a build, I can activate that, of course - but not with explicit consent of the operators of the build slaves. 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] Keep default comparisons - or add a second set?
Title: RE: [Python-Dev] Keep default comparisons - or add a second set? Noam Raphael wrote: I don't think that every type that supports equality comparison should support order comparison. I think that if there's no meaningful comparison (whether equality or order), an exception should be raised. Just to keep myself sane... def date_range(start=None, end=None): if start == None: start = datetime.date.today() if end == None: end = datetime.date.today() return end - start Are you saying the if statements will raise TypeError if start or end are dates? That would be a sad day for Python. Perhaps you're saying that there is a meaningful comparison between None and anything else, but please clarify if so. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ 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] Keep default comparisons - or add a second set?
On 12/29/05, Robert Brewer [EMAIL PROTECTED] wrote: Just to keep myself sane... def date_range(start=None, end=None): if start == None: start = datetime.date.today() if end == None: end = datetime.date.today() return end - start Are you saying the if statements will raise TypeError if start or end are dates? That would be a sad day for Python. Perhaps you're saying that there is a meaningful comparison between None and anything else, but please clarify if so. Yes, I'm suggesting that they will raise a TypeError. Your example shows that the change is not compatible with a lot of existing Python code, which means that it's a Python 3000 thing. The following code will continue to work: def date_range(start=None, end=None): if start is None: start = datetime.date.today() if end is None: end = datetime.date.today() return end - start Using is None instead of == None is considered a better style even now. Noam ___ 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] Automated Python testing (was Re: status of development documentation)
[Martin v. Löwis] ... Unfortunately, it doesn't work at all, because svn_buildbot.py does not report branches on which a change happened, so if you have multiple schedulers for a subversion source, they either all build when a change occurs, or none of them. If svn_version knew about branches (which I'll have to implement, or incorporate the patch that I saw somewhere), it would probably work - I have now code to create builders and schedulers in a nested loop. Branches are working sensibly on buildbot.zope.org, so maybe Benji York (who did most or all of the heavy buildbot lifting at Zope Corp) could share some clues. I see that Benji is subscribed to python-dev, but many people in this part of the world are on vacation this week. If people really need to be able to force a build, I can activate that, of course - but not with explicit consent of the operators of the build slaves. You can't force a build from: http://buildbot.zope.org either, but there's a different (and secret) URL from which you can force builds. That's been handy for me primarily for experimenting with theories about why our Windows buildbot slaves get wedged after a build or two. The ZC buildbots have also (IMO) been configured to ignore too much, which is a problem Python doesn't have (e.g., ZODB is stitched into Zope via svn externals, and for some time the ZC buildbot didn't think replacing ZODB was a reason to run the Zope tests again). IOW, I doubt there's much need for it here. ___ 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] NotImplemented reaching top-level
Hi Marc,
On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote:
d += 1.2
d
NotImplemented
The PEP documenting the coercion logic has complete tables
for what should happen:
Well, '+=' does not invoke coercion at all, with new-style classes like
Decimal.
Looking at the code in abstract.c the above problem appears
to be related to the special cases applied to += and *=
in case both operands cannot deal with the type combination.
In such a case, a check is done whether the operation could
be interpreted as sequence operation (concat or repeat) and
then delegated to the appropriate handlers.
Indeed. The bug was caused by this delegation, which (prior to my
patch) would also return a Py_NotImplemented that would leak through
abstract.c. My patch is to remove this unnecessary delegation by not
defining sq_concat/sq_repeat for user-defined classes, and restoring the
original expectation that the sq_concat/sq_repeat slots should not
return Py_NotImplemented. How does this relate to coercion?
But then again, looking in typeobject.c, the following code
could be the cause for leaking a NotImplemented singleton
reference:
#define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \
static PyObject * \
FUNCNAME(PyObject *self, PyObject *other) \
{ \
static PyObject *cache_str, *rcache_str; \
int do_other = self-ob_type != other-ob_type \
other-ob_type-tp_as_number != NULL \
other-ob_type-tp_as_number-SLOTNAME == TESTFUNC; \
if (self-ob_type-tp_as_number != NULL \
self-ob_type-tp_as_number-SLOTNAME == TESTFUNC) { \
PyObject *r; \
if (do_other \
PyType_IsSubtype(other-ob_type, self-ob_type) \
method_is_overloaded(self, other, ROPSTR)) { \
r = call_maybe( \
other, ROPSTR, rcache_str, (O), self); \
if (r != Py_NotImplemented) \
return r; \
Py_DECREF(r); \
do_other = 0; \
} \
r = call_maybe( \
self, OPSTR, cache_str, (O), other); \
if (r != Py_NotImplemented || \
other-ob_type == self-ob_type) \
^
If both types are of the same type, then a NotImplemented returng
value would be returned.
Indeed, however:
return r; \
Py_DECREF(r); \
} \
if (do_other) { \
return call_maybe( \
other, ROPSTR, rcache_str, (O), self); \
} \
Py_INCREF(Py_NotImplemented); \
return Py_NotImplemented; \
}
This last statement also returns Py_NotImplemented. So it's expected of
this function to be able to return Py_NotImplemented, isn't it? The
type slots like nb_add can return Py_NotImplemented; the code that
converts it to a TypeError is in the caller, which is abstract.c.
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
[Python-Dev] set.copy documentation string
is currently Return a shallow copy of a set. Perhaps shallow should be removed, since set members are supposed to be immutable so there's no point in a deep copy? Noam ___ 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] Python + Visual C++ 8.0?
--- Martin v. Löwis [EMAIL PROTECTED] wrote: P.P.S. You do know that this configuration (extension compiled with VS2005, Python compiled wit VS.NET2003) is not supported, right? Thanks to Adal's help I got all our C++ extensions (about 50) to work with VC8. I am using Python 2.4.2 compiled with VC7.1. We have more than 150 unit tests which all pass. Our applications also work under Windows 2000 even if the platform has never seen any Visual Studio installation. Also, in over two years I never had problems mixing VC6 Python with VC7.1 extensions; our binary installers worked on any Windows 2000 or XP system I've ever tried. Since we are using Boost.Python, I believe we are heavily exercising the compiler, the C/C++ libraries, and the DLL machinery. However, we don't have any home-grown C++ GUI code. Could it be that problems due to mixing objects from different compiler versions are restricted to certain areas, like GUI libraries? Cheers, Ralf __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
On Wed, Dec 28, 2005 at 03:32:29PM +0100, Martin v. Löwis wrote: you should really consider comming up with a patch yourself. Bonus points if the code integrates with the current strategies, instead of replacing them. As I wrote in the first email, I've no intention to replace anything. The new heuristic would be completely orthogonal to the current strategy. Current strategy is in function of the number, the new heuristic would be in function of size, and they would co-exist perfectly. ___ 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
On Wed, Dec 28, 2005 at 05:52:06AM -0800, Aahz wrote: If you feel comfortable with C code, the best way to get this to happen would be to make the change yourself, then test to find out what effects I'm more confortable with C code than with python code, that's not the problem (infact I think that everyone should be confortable with C ;). The only problem is that my time on this is quite limited, but I will be really be happy to give it a try. this has on Python (in terms of speed and memory usage and whether it breaks any of the regression tests). Once you've satisfied yourself that it works, submit a patch, and post here again with the SF number. Ok. Note that since your tunable parameter is presumably accessible from Python code, you'll also need to submit doc patches and tests to verify that it's working correctly. Ok. If there's anybody willing to suggest the files to hook into (the location where the interpreter allocates all anonymous memory) and how to invoke gc.collect() from C, that would help. thanks! ___ 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] set.copy documentation string
Noam Raphael wrote: is currently Return a shallow copy of a set. Perhaps shallow should be removed, since set members are supposed to be immutable so there's no point in a deep copy? That still doesn't make copy return a deep copy, right? shallow copy is more precise than copy, and correct - what is gained from removing it? 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] Python + Visual C++ 8.0?
Ralf W. Grosse-Kunstleve wrote: However, we don't have any home-grown C++ GUI code. Could it be that problems due to mixing objects from different compiler versions are restricted to certain areas, like GUI libraries? Well, yes: the areas are - memory management - stdio - locales for the C library; for the C++, I'm not so sure, but I think one of the areas is - static members of class templates, in particular in STL containers In all these cases, global variables exist twice if you have two copies of the library defining them in your address space. If you pass objects around from one library to the other, the other library may operate on the wrong global variable. To give some examples: - memory management: if you malloc() with one library, and free() with the other, the memory will be mostly leak (i.e. not be reused by the malloc() of the first library); the consequence is not a crash, but a memory leak, in certain applications - stdio: if you fprintf to a stdout of a different library, the library will crash (GPF) - static members of class templates: I think it is the rb_tree template which will not find its data correctly (but my memory is weak here) 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
[Python-Dev] When do sets shrink?
Hello, If I do something like this: s = set() for i in xrange(100): s.add(i) while s: s.pop() gc.collect() the memory consumption of the process remains the same even after the pops. I checked the code (that's where I started from, really), and there's nothing in set.pop or set.remove that resizes the table. And it turns out that it's the same with dicts. Should something be done about it? Noam ___ 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
Andrea Arcangeli wrote: If there's anybody willing to suggest the files to hook into (the location where the interpreter allocates all anonymous memory) and how to invoke gc.collect() from C, that would help. thanks! It all happens in Modules/gcmodule.c:_PyObject_GC_Malloc. There are per-generation counters; _PyObject_GC_Malloc increments the generation 0 counter, and PyObject_GC_Del decreases it. The counters of the higher generations are incremented when a lower collection occurs. One challenge is that PyObject_GC_Del doesn't know how large the memory block is that is being released. So it is difficult to find out how much memory is being released in the collection. 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] set.copy documentation string
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Noam Raphael wrote: is currently Return a shallow copy of a set. Perhaps shallow should be removed, since set members are supposed to be immutable so there's no point in a deep copy? That still doesn't make copy return a deep copy, right? shallow copy is more precise than copy, and correct - what is gained from removing it? Perhaps it bothers the programmer with something that shouldn't bother him. I mean that I might do help(set.copy), and then think, Oh, it returns a shallow copy. Wait a minute - 'shallow' means that I get a new object, which references the same objects as the old one. Perhaps I should use another function, which does deep copying? Let me think about it - no. All members of a set are immutable, so it doesn't matter. I think that in this case, the fact that the copy is shallow is an implementation detail, since there's no sense in making a deep copy of a set. Implementation details should probably not be a part of the definition of what a method does. I know it's just a word, and that it doesn't matter a lot. But why not make things a tiny bit better? Noam ___ 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] When do sets shrink?
Noam Raphael wrote: Should something be done about it? It's very difficult to do something useful about it. Even if you manage to determine how much memory you want to release, it's nearly impossible to actually release the memory to the operating system, because of the many layers of memory management software that all need to agree that the memory should be reused somewhere else (instead of keeping it on that layer, just in case somebody using that layer wants some memory). 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] set.copy documentation string
Noam Raphael wrote: Perhaps it bothers the programmer with something that shouldn't bother him. I mean that I might do help(set.copy), and then think, Oh, it returns a shallow copy. Wait a minute - 'shallow' means that I get a new object, which references the same objects as the old one. Perhaps I should use another function, which does deep copying? Let me think about it - no. All members of a set are immutable, so it doesn't matter. I think that in this case, the fact that the copy is shallow is an implementation detail, since there's no sense in making a deep copy of a set. If makes no sense means would not make a difference, then you are wrong. Objects in a set are not necessarily unmodifiable; they just have to be hashable. Watch this: class A: ... def __hash__(self):return 0 ... def __cmp__(self, other):return 0 ... a1 = A() import copy a2 = copy.deepcopy(a1) a1.x = 10 a2.x = 20 a1.x 10 s = set([a1]) a2 in s True So even though a1 and a2 are distinct objects with different, modifiable state, they are treated as equal in the set. A deepcopy of the set (if it existed) would do something different than a plain copy. I know it's just a word, and that it doesn't matter a lot. But why not make things a tiny bit better? Things would get worse. The code would become underspecified. 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] When do sets shrink?
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Noam Raphael wrote: Should something be done about it? It's very difficult to do something useful about it. Even if you manage to determine how much memory you want to release, it's nearly impossible to actually release the memory to the operating system, because of the many layers of memory management software that all need to agree that the memory should be reused somewhere else (instead of keeping it on that layer, just in case somebody using that layer wants some memory). I checked - when doing the same thing with lists, all the memory was released for use by other Python objects, and most of it was released for use by the operating system. Noam ___ 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] When do sets shrink?
It's very difficult to do something useful about it. Even if you manage to determine how much memory you want to release, it's nearly impossible to actually release the memory to the operating system, because of the many layers of memory management software that all need to agree that the memory should be reused somewhere else (instead of keeping it on that layer, just in case somebody using that layer wants some memory). I checked - when doing the same thing with lists, all the memory was released for use by other Python objects, and most of it was released for use by the operating system. Put another way, it is difficult to assure that the memory is released back to the operating system. We don't control that part. What could be done is to add a test for excess dummy entries and trigger a periodic resize operation. That would make the memory available for other parts of the currently running script and possibly available for the O/S. The downside is slowing down a fine-grained operation like pop(). For dictionaries, this wasn't considered worth it. For sets, I made the same design decision. It wasn't an accident. I don't plan on changing that decision unless we find a body of real world code that would be better-off with more frequent re-sizing. Raymond ___ 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] set.copy documentation string
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote: If makes no sense means would not make a difference, then you are wrong. Objects in a set are not necessarily unmodifiable; they just have to be hashable. Oh, you are right. I thought so much about dropping default hash=id, or more generally that only frozen objects should be hashable, that I forgot that it's not the case yet... :) (I used the term frozen instead of immutable since I think that immutable is not defined very well, because tuples are considered immutable even though their value can change if they reference mutable objects.) Thanks, Noam ___ 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] When do sets shrink?
Noam Raphael wrote: I checked - when doing the same thing with lists, all the memory was released for use by other Python objects, and most of it was released for use by the operating system. In this specific case, perhaps. malloc will typically return memory to the system only if that memory is at the end of the heap. If there is more memory after block to be released, it can't return the memory block, because it won't punch a whole into the heap. So as soon as you have more than one object, things become interesting. Different systems use different, enhance strategies, of course. For example, Linux glibc malloc will allocate large blocks through mmap (instead of sbrk), such blocks then can be returned individually. 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] When do sets shrink?
On 12/29/05, Raymond Hettinger [EMAIL PROTECTED] wrote: What could be done is to add a test for excess dummy entries and trigger a periodic resize operation. That would make the memory available for other parts of the currently running script and possibly available for the O/S. The downside is slowing down a fine-grained operation like pop(). For dictionaries, this wasn't considered worth it. For sets, I made the same design decision. It wasn't an accident. I don't plan on changing that decision unless we find a body of real world code that would be better-off with more frequent re-sizing. The computer scientist in me prefers O() terms over changes in a constant factor, but that's only me. Perhaps a note about it should be added to the documentation, though? Noam ___ 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] When do sets shrink?
Noam Raphael wrote: The computer scientist in me prefers O() terms over changes in a constant factor, but that's only me. That remark, I don't understand. In a hash table, most simple operations are O(n) as the worst-case time, except for operations that may cause resizing, which are O(n**2) (worst case). So you are proposing that .pop() might trigger a resize, thus changing from O(n) worst case to O(n**2) worst case? Why would a computer scientist prefer that? Perhaps a note about it should be added to the documentation, though? Sure. Patches (to sf.net/projects/python) are welcome. 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] When do sets shrink?
On Thursday, December 29, 2005 Martin v. Löwis wrote: Noam Raphael wrote: In this specific case, perhaps. malloc will typically return memory to the system only if that memory is at the end of the heap. If there is more memory after block to be released, it can't return the memory block, because it won't punch a whole into the heap. So as soon as you have more than one object, things become interesting. Different systems use different, enhance strategies, of course. For example, Linux glibc malloc will allocate large blocks through mmap (instead of sbrk), such blocks then can be returned individually. MSVC 7.1 and 8.0 malloc always uses the Windows heap functions (HeapAlloc friends) if running on Windows 2000 or newer (malloc.c and heapinit.c). So it seems that for both Linux (gcc) and Win (msvc) the memory is released to the operating system. Of course, fragmentation is still an issue, but now it's on the OS side of things. ___ 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] Python + Visual C++ 8.0?
--- Martin v. Löwis [EMAIL PROTECTED] wrote: Well, yes: the areas are - memory management - stdio - locales for the C library; for the C++, I'm not so sure, but I think one of the areas is - static members of class templates, in particular in STL containers Thanks for the insight! For Boost.Python users the situation is actually not bad at all: - there is not a single malloc() in the Boost.Python sources - there is only one free(), which is specific to gcc; i.e. this code is not seen by Visual C++. - there is only one FILE* that is seen by Visual C++. It appears in the signature of a function assigned to the tp_print slot. As far as I can tell this is the only soft spot. I'll lobby for having the print function removed since it is optional and both tp_str and tp_repr are defined anyway. - nobody should be mixing C++ libraries compiled with different compilers on any platform; it doesn't get much more dangerous than this. Since Python is pure C static members of class templates should therefore be a non-issue. This leaves only stdio and locales to be considered. We are strictly avoiding both in C++ to maximize portability. I/O is intrinsically slow and therefore there is no point in coding it in C++, especially since Python's I/O is very fast anyway. I am not sure about locales because this is not very interesting at all for scientific code development. Under the assumption that the one tp_print function in the Boost.Python sources is removed, I am arriving at the conclusion that it is more than pure luck that all our tests work. People writing C++ extensions view the compiled layer as low-level number-crunching back-end. It is quite natural not to find I/O and use of locales in such code. And even if there is I/O, chances are it is done via std::cout rather than a raw FILE* obtained from Python via difficult to memorize incantations (I don't even know how to do it). Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.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
Re: [Python-Dev] When do sets shrink?
I did a little test using MSVC 8.0 on WinXP.
I allocated 128 MB using 128 different buffers of 1 MB each,
freed half of them (alternatively) then freed the remaining half.
I monitored memory usage using the Task Manager and memory is really
freed as indicated by both the Mem Usage and VM Size process
counters and also by the global Commit Charge. After exiting the
process the commit charge remains the same, suggesting that all the
memory was indeed released.
Even if the Windows heap documentation says that once memory is
allocated, it won't be released until the heap is destroyed, this
seems to not be true when allocating large chunks. There probably is a
threshold after which VirtualAlloc is used.
#include windows.h
#include stdio.h
#include malloc.h
#define COUNT 128
void main()
{
char** ptr = malloc(COUNT * sizeof(char*));
int i;
for (i = 0; i COUNT; ++i)
{
ptr[i] = malloc(1024 * 1024);
// Touch memory to really commit it.
SecureZeroMemory(ptr[i], 1024 * 1024);
}
printf(Mem allocated\n);
Sleep(5000);
for (i = 0; i COUNT; i += 2)
free(ptr[i]);
printf(Half memory deallocated\n);
Sleep(1);
for (i = 1; i COUNT; i += 2)
free(ptr[i]);
printf(Full memory deallocated\n);
Sleep(1);
}
___
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] Python + Visual C++ 8.0?
Ralf W. Grosse-Kunstleve wrote: - there is only one FILE* that is seen by Visual C++. It appears in the signature of a function assigned to the tp_print slot. As far as I can tell this is the only soft spot. I'll lobby for having the print function removed since it is optional and both tp_str and tp_repr are defined anyway. Out of curiosity: can you please try invoking this enum_print to stdout with your VS2005-built boost module? I see it uses fprintf, so I would expect it to crash. 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
Martin v. Löwis [EMAIL PROTECTED] wrote: One challenge is that PyObject_GC_Del doesn't know how large the memory block is that is being released. So it is difficult to find out how much memory is being released in the collection. Another idea would be to add accounting to the PyMem_* interfaces. It could be that most memory is used by objects that are not tracked by the GC (e.g. strings). I guess you still have the same problem in that PyMem_Free may not know how large the memory block is. Neil ___ 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] a quit that actually quits
Reinhold Birkenfeld wrote: Fredrik Lundh wrote: Walter Dörwald wrote: We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help /.../ so how would such a hook deal with the def exit(): ... pass exit case ? In the inputhook one would have to check for exit being defined at interpreter level. Which is fairly trivial given a slight change to my proposed default input hook: def default_inputhook(statement): if statement in vars(sys.modules[__main__]): return False try: aliased = sys.alias[statement] except KeyError: return False else: aliased() return True That is, a real variable will always shadow an alias - you need to get rid of the real variable before the alias will start working again (or else change the name of the alias). Or you can give the alias a different name via: sys.alias[exit_] = sys.alias[exit] 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] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
[Martin v. Löwis]
...
One challenge is that PyObject_GC_Del doesn't know how large the
memory block is that is being released. So it is difficult to find out how
much memory is being released in the collection.
Impossible in some cases is accurate. When pymalloc isn't enabled,
all these things call the platform malloc/free directly, and there's
no portable/standard way to find out anything from those. When
pymalloc is enabled, PyObject_GC_Del could be taught whether pymalloc
controls the block being freed, and, when so, how to suck up the
block's size index from the block's pool header; but when pymalloc
doesn't control the memory being freed, it's the same as if pymalloc
were not enabled.
[Neil Schemenauer]
Another idea would be to add accounting to the PyMem_* interfaces.
It could be that most memory is used by objects that are not tracked
by the GC (e.g. strings).
I still expect this old code in pymem.h to go away for Python 2.5:
/* In order to avoid breaking old code mixing PyObject_{New, NEW} with
PyMem_{Del, DEL} and PyMem_{Free, FREE}, the PyMem release memory
functions have to be redirected to the object deallocator. */
#define PyMem_FREE PyObject_FREE
When goes away, PyMem_FREE will resolve directly to the platform
free(), and will no longer have even accidental relationships to any
memory involved in cyclic gc.
I guess you still have the same problem in that PyMem_Free may not know how
large the memory block is.
It will be more the case that we can guarantee it won't know -- but
since direct uses of malloc/free have no useful relationship to cyclic
gc behavior, the OP shouldn't care about that.
In any case, the OP's original the overhead of this should be zero
claim isn't credible (I checked, and there _still_ won't be free
lunches in 2006 -- unless you work at Google ;-)).
___
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] a quit that actually quits
Martin == Martin v Löwis [EMAIL PROTECTED] writes: Martin That would assume that the user knows that exit is a Martin function: apparently, people expect it to be a statement Martin (like print), Oh, the irony of that analogy!wink Martin or they are entirely unaware of the distinctions between Martin statements, expressions, and functions. Then there's little point to giving them access to the interpreter! Of course, Martin also mentioned students. Python is not the only language in the world; we all know that, even if most of us much prefer programming in Python to any other environment. If you're teaching, why not use this as an opportunity to deliver a brief lecture on why Python does things differently, and why one should understand a _formal_ language in its own terms, not in terms of what you (the user/programmer) want it to be for momentary convenience? My feeling is that the current behavior of exit and quit is not you didn't say please but excuse me, I don't speak BASIC; would you say that in Python or signal that the conversation is over (ie, EOF)? For me, that's part of the Zen of Python. Probably I'm just missing something given the amount of support this idea is getting, from really respectable sources, too, but it just seems wrong to change this. What's wrong with having a distinctive personality? I suppose the current value of those variables sounds a bit rude. Why not fix the discourtesy, rather than what's not broken (IMHO)? exit = \ The Python interpreter simply interprets a Python program. It provides no special interactive commands. The line editor is a thin front-end to the standard input stream. To exit your program, use one of the functions or exceptions provided for this purpose, or simply end the file (interactively this is signaled by Ctrl-D). This public service message brought to you by the global variable 'exit'. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ 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] a quit that actually quits
Here's yet a different take on this: why not simply change the startup message? Whether we choose quit or exit, someone will get it wrong unless there's an alias. Changing the message is free. Currently we have Type help, copyright, credits or license for more information. Let's add another line that says Type quit() to exit Defining it as def quit(): raise SystemExit should be fine. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger. --Roy Smith ___ 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] When do sets shrink?
Noam Raphael [EMAIL PROTECTED] wrote: On 12/29/05, Raymond Hettinger [EMAIL PROTECTED] wrote: What could be done is to add a test for excess dummy entries and trigger a periodic resize operation. That would make the memory available for other parts of the currently running script and possibly available for the O/S. The downside is slowing down a fine-grained operation like pop(). For dictionaries, this wasn't considered worth it. For sets, I made the same design decision. It wasn't an accident. I don't plan on changing that decision unless we find a body of real world code that would be better-off with more frequent re-sizing. The computer scientist in me prefers O() terms over changes in a constant factor, but that's only me. Perhaps a note about it should be added to the documentation, though? The computer scientist in me agrees with you, but the practical application developer in me argues that every microsecond adds up. - Josiah ___ 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] a quit that actually quits
On 12/27/05, Fredrik Lundh [EMAIL PROTECTED] wrote: but now we're back to today's situation: quit 'Use Ctrl-Z plus Return to exit.' which violates the basic if you know what I mean, why the /!/!//%¤ don't you do what I say usability rule. What nonsense. Every Python programmer knows that the right way to exit Python is to enter a platform EOF. The quit and exit variables are compromises for non-programmers who have accidentally entered Python and who don't know how to get out of it (this is usually the same category of people who don't know how or don't dare to kill a program using heavy artillery). Rather than improving upon the quit/exit functionality a la /F's patch I'd get rid of the compromise. Now, for Py3K we could try to come up with a more intelligent interactive mode. Probably not implemented in C. Perhaps using ideas from ipython (which I've personally never used). We might provide a quit or exit command using a more sophisticated mechanism. But there are always costs (e.g. the violation of the primciple that typing a name shows its repr()). In the mean time I'm a strong believer in it ain't broke so don't fix it here. -- --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] a quit that actually quits
Guido van Rossum wrote: but now we're back to today's situation: quit 'Use Ctrl-Z plus Return to exit.' which violates the basic if you know what I mean, why the /!/!//%¤ don't you do what I say usability rule. What nonsense. Every Python programmer knows that the right way to exit Python is to enter a platform EOF. The quit and exit variables are compromises for non-programmers who have accidentally entered Python and who don't know how to get out of it why is it that non-pythoneers are always referred to as non-programmers ? is the current user base so large so we no longer need to care about people moving in from other environments ? (for those who follow non-python forums, there's a meme going around out there that says that python developers are arrogant, and will always defend the existing design with we're right, you're wrong or a we're right, you're stupid, and that the current exit non-design is an excellent example of this. my proposal was partially motivated by an urge to prove them wrong, but it seems as I accidentally proved them to be right...) /F ___ 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] a quit that actually quits
Guido van Rossum wrote: On 12/27/05, Fredrik Lundh [EMAIL PROTECTED] wrote: but now we're back to today's situation: quit 'Use Ctrl-Z plus Return to exit.' which violates the basic if you know what I mean, why the /!/!//%¤ don't you do what I say usability rule. What nonsense. Every Python programmer knows that the right way to exit Python is to enter a platform EOF. The quit and exit variables are compromises for non-programmers who have accidentally entered Python and who don't know how to get out of it (this is usually the same category of people who don't know how or don't dare to kill a program using heavy artillery). Except that if you have iPython installed on Windows you *don't* enter the platform EOF any more, you enter CTRL/D (which threw me for a while). Plus the standard Windows build requires a return after the CTRL/Z while the Pythonware versions (last time I looked) only required the CTRL/Z. So the situation is a little less black-and-white than it might be. Rather than improving upon the quit/exit functionality a la /F's patch I'd get rid of the compromise. I *have* been surprised by the amount on brainpower that's been expended on this discussion. Now, for Py3K we could try to come up with a more intelligent interactive mode. Probably not implemented in C. Perhaps using ideas from ipython (which I've personally never used). We might provide a quit or exit command using a more sophisticated mechanism. But there are always costs (e.g. the violation of the primciple that typing a name shows its repr()). In the mean time I'm a strong believer in it ain't broke so don't fix it here. +1, with the proviso that we might add a description of how to exit to the interactive rubric (if anyone can work out exactly what that would be under all circumstances). regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] a quit that actually quits
Steve Holden wrote: Except that if you have iPython installed on Windows you *don't* enter the platform EOF any more, you enter CTRL/D (which threw me for a while). To be fair, that's due to the win32 readline library used by ipython, which modifies console handling. IPython itself doesn't do anything to the EOF conventions, it's pure python code with no direct access to the console. Cheers, f ___ 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
