Re: [Python-Dev] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))
On Dec 27, 2005, at 9:05 AM, Andrea Arcangeli wrote: 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. In this particular case, you might be better off just writing some Twisted code that periodically checks the size of the current process and does a gc.collect() when necessary. Of course, it requires some platform specific code, but presumably you only care about one, maybe two, platforms anyway. -bob ___ 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
(for those who follow non-python forums make that those who don't follow /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] When do sets shrink?
Martin v. Löwis wrote: Adal Chiriliuc wrote: 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. How so? HeapFree does not return the memory to the system. From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/heap_functions.asp Once the pages are committed, they are not decommitted until the process is terminated or until the heap is destroyed by calling the HeapDestroy function. http://www.python.org/sf/1389051 agrees with the microsoft documentation. (where imaplib runs out of memory after read- ing 2 megabytes of a 14 megabyte message). /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
(for those who follow non-python forums Fredrik make that those who don't follow What might some of those non-python forums be? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New PEP: Using ssize_t as the index type
Please let me know what you think. Regards, Martin PEP: XXX Title: Using ssize_t as the index type Version: $Revision$ Last-Modified: $Date$ Author: Martin v. Löwis [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 18-Dec-2005 Post-History: Abstract In Python 2.4, indices of sequences are restricted to the C type int. On 64-bit machines, sequences therefore cannot use the full address space, and are restricted to 2**31 elements. This PEP proposes to change this, introducing a platform-specific index type Py_ssize_t. An implementation of the proposed change is in http://svn.python.org/projects/python/branches/ssize_t. Rationale = 64-bit machines are becoming more popular, and the size of main memory increases beyond 4GiB. On such machines, Python currently is limited, in that sequences (strings, unicode objects, tuples, lists, array.arrays, ...) cannot contain more than 2GiElements. Today, very few machines have memory to represent larger lists: as each pointer is 8B (in a 64-bit machine), one needs 16GiB to just hold the pointers of such a list; with data in the list, the memory consumption grows even more. However, there are three container types for which users request improvements today: * strings (currently restricted to 2GiB) * mmap objects (likewise; plus the system typically won't keep the whole object in memory concurrently) * Numarray objects (from Numerical Python) As the proposed change will cause incompatibilities on 64-bit machines, it should be carried out while such machines are not in wide use (IOW, as early as possible). Specification = A new type Py_ssize_t is introduced, which has the same size as the compiler's size_t type, but is signed. It will be a typedef for ssize_t where available. The internal representation of the length fields of all container types is changed from int to ssize_t, for all types included in the standard distribution. In particular, PyObject_VAR_HEAD is changed to use Py_ssize_t, affecting all extension modules that use that macro. All occurrences of index and length parameters and results are changed to use Py_ssize_t, including the sequence slots in type objects. New conversion functions PyInt_FromSsize_t, PyInt_AsSsize_t, PyLong_AsSsize_t are introduced. PyInt_FromSsize_t will transparently return a long int object if the value exceeds the MAX_INT. New function pointer typedefs ssizeargfunc, ssizessizeargfunc, ssizeobjargproc, and ssizessizeobjargproc are introduced. A new conversion code 'n' is introduced for PyArg_ParseTuple and Py_BuildValue, which operates on Py_ssize_t. The conversion codes 's#' and 't#' will output Py_ssize_t if the macro PY_SIZE_T_CLEAN is defined before Python.h is included, and continue to output int if that macro isn't defined. At places where a conversion from size_t/Py_ssize_t to int is necessary, the strategy for conversion is chosen on a case-by-case basis (see next section). Conversion guidelines = Module authors have the choice whether they support this PEP in their code or not; if they support it, they have the choice of different levels of compatibility. If a module is not converted to support this PEP, it will continue to work unmodified on a 32-bit system. On a 64-bit system, compile-time errors and warnings might be issued, and the module might crash the interpreter if the warnings are ignored. Conversion of a module can either attempt to continue using int indices, or use Py_ssize_t indices throughout. If the module should continue to use int indices, care must be taken when calling functions that return Py_ssize_t or size_t, in particular, for functions that return the length of an object (this includes the strlen function and the sizeof operator). A good compiler will warn when a Py_ssize_t/size_t value is truncated into an int. In these cases, three strategies are available: * statically determine that the size can never exceed an int (e.g. when taking the sizeof a struct, or the strlen of a file pathname). In this case, add a debug assert() that the value is indeed smaller than INT_MAX, and cast the value to int. * statically determine that the value shouldn't overflow an int unless there is a bug in the C code somewhere. Test whether the value is smaller than INT_MAX, and raise an InternalError if it isn't. * otherwise, check whether the value fits an int, and raise a ValueError if it doesn't. The same care must be taking for tp_as_sequence slots, in addition, the signatures of these slots change, and the slots must be explicitly recast (e.g. from intargfunc to ssizeargfunc). Compatibility with previous Python versions can be achieved with the test:: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #endif and then using Py_ssize_t in the rest of the code. For the tp_as_sequence slots, additional typedefs might be necessary; alternatively, by replacing::
Re: [Python-Dev] a quit that actually quits
[EMAIL PROTECTED] wrote: Fredrik make that those who don't follow What might some of those non-python forums be? assorted corners of the blogosphere, mostly. no time to dig up any explicit references, since I'm preparing for a 650 km trip through a major snowstorm, but searching backwards from bruce eckel's recent The departure of the hyper-enthusiasts might help you find some: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 /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
On Wed, Dec 28, 2005, Guido van Rossum wrote: In the mean time I'm a strong believer in it ain't broke so don't fix it here. Does that also include my suggestion about improving the startup message? -- 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] NotImplemented reaching top-level
Hi Armin,
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.
True, it doesn't invoke coercion in the sense that a coercion
method is called, but the mechanism described in the PEP is
still used via PyNumber_InPlaceAdd().
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?
The Py_NotImplemented singleton was introduced in the coercion
proposal to mean there is no implementation to execute the requested
operation on the given combination of types.
At the time we also considered using an exception for this, but
it turned out that this caused too much of a slow-down. Hence the use
of a special singleton which could be tested for by a simple
pointer comparison.
Originally, the singleton was only needed for mixed-type operations.
It seems that its use has spread to other areas as well and
can now also refer to missing same-type operator implementations.
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.
You're right - silly me.
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Dec 29 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] a quit that actually quits
On 12/29/05, Aahz [EMAIL PROTECTED] wrote: On Wed, Dec 28, 2005, Guido van Rossum wrote: In the mean time I'm a strong believer in it ain't broke so don't fix it here. Does that also include my suggestion about improving the startup message? Nobody reads that; plus it looks like it's excruciatingly complex to get it right at all times; and getting it wrong is worse that not mentioning it at all. Regarding the meme floating about the arrogance of Pythoneers: bloggers (pretty much by definition) are actually the most arrogant species; don't confuse bloggers say with most people think. -- --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] New PEP: Using ssize_t as the index type
+1. I think this is long overdue. While I can't judge the amount of code breakage, 2.5 is as good an opportunity as any. --Guido On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Please let me know what you think. Regards, Martin PEP: XXX Title: Using ssize_t as the index type Version: $Revision$ Last-Modified: $Date$ Author: Martin v. Löwis [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 18-Dec-2005 Post-History: Abstract In Python 2.4, indices of sequences are restricted to the C type int. On 64-bit machines, sequences therefore cannot use the full address space, and are restricted to 2**31 elements. This PEP proposes to change this, introducing a platform-specific index type Py_ssize_t. An implementation of the proposed change is in http://svn.python.org/projects/python/branches/ssize_t. -- --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
[Python-Dev] Bug in Py_InitModule4
Hello all, While working with Subversion's python API bindings this morning, I discovered a function in one of their modules illegally named import (svn.client.import, for the curious). Because the extension module in question is written in C, the interpreter doesn't flag the otherwise-illegal identifier import at compile-time; if you try to call the function at runtime, however, the interpreter raises a SyntaxError, since svn.client.import is an illegal name. My question is this: is there any interest in preventing situations like this by including checks in Python/modsupport.c:Py_InitModule4 to make sure that the PyMethodDef contains only valid identifiers, or is this a case of if it hurts when you do that, don't do that? I can see a case for both sides: on the one hand, it would be nice to prevent people from accidentally creating inaccessible objects. On the other hand, perhaps this is a job that should be given to tools like SWIG, since they're the ones actually generating the bindings (in the case of SVN). I've already reported this to the SVN people, but if there's any interest in a CPython-side solution, I'm more than willing to work up a patch to modsupport.c. Thanks, Collin Winter ___ 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, Noam Raphael [EMAIL PROTECTED] wrote: On 12/29/05, Donovan Baarda [EMAIL PROTECTED] wrote: Without some sort of fancy overkill size hinting or history tracking, that's probably as good a heuristic as you can get. I'm sorry, but it's not correct. There's a simple resize scheduling algorithm that is proven to take, when you sum things up, O(1) per each simple operation, and that keeps the amount of used memory always proportional to the number of elements in the set. I'm not saying that practically it must be used - I'm just saying that it can't be called a heuristic, and that it doesn't involve any fancy overkill size hinting or history tracking. It actually means something like this: 1. If you want to insert and the table is full, resize the table to twice the current size. 2. If you delete and the number of elements turns out to be less than a quarter of the size of the table, resize the table to half of the current size. I'm neutral on doing this. I'd like to point out that if we decide not to do this, there's an easy way to shrink dicts and sets under user control, which means that you only have to pay attention in the rare cases where it matters: create a new dct or set from the old one automatically creates one of the right size. E.g. s = set(s) replaces the set s (which may once have had 1M items and now has nearly 1M empty slots) by one with the optimal number of slots. Ditto for dicts: d = dict(d) -- --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
Aahz wrote:
Does that also include my suggestion about improving the startup message?
when newbies get to the point that they want to quit, chances are
that the message have scrolled out of sight. and if they only skim
the instructions, they'll probably get confused anyway... e.g.
Python version gobbledidok gobbledidok gobbledidok gobbledidok
Type help, copyright, credits or license for more information.
help
Type help() for interactive help, or help(object) for help about object.
help()
Welcome to Python 2.4! This is the online help utility.
If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://www.python.org/doc/tut/.
Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules. To quit this help utility and
return to the interpreter, just type quit.
To get a list of available modules, keywords, or topics, type modules,
keywords, or topics. Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as spam, type modules spam.
help quit()
no Python documentation found for 'quit()'
help quit
You are now leaving help and returning to the Python interpreter.
If you want to ask for help on a particular object directly from the
interpreter, you can type help(object). Executing help('string')
has the same effect as typing a particular string at the help prompt.
quit
'Use Ctrl-Z plus Return to exit.'
quit()
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: 'str' object is not callable
help(quit)
no Python documentation found for 'Use Ctrl-Z plus Return to exit.'
help(quit)
Help on str object:
quit = class str(basestring)
| str(object) - string
|
| Return a nice string representation of the object.
| If the argument is a string, the return value is the same object.
|
| Method resolution order:
| str
| basestring
| object
|
| Methods defined here:
|
| __add__(...)
| x.__add__(y) == x+y
|
| __contains__(...)
| x.__contains__(y) == y in x
|
| __eq__(...)
| x.__eq__(y) == x==y
|
| __ge__(...)
| x.__ge__(y) == x=y
|
| __getattribute__(...)
| x.__getattribute__('name') == x.name
|
| __getitem__(...)
| x.__getitem__(y) == x[y]
|
| __getnewargs__(...)
|
| __getslice__(...)
| x.__getslice__(i, j) == x[i:j]
|
| Use of negative indices is not supported.
|
| __gt__(...)
| x.__gt__(y) == xy
|
| __hash__(...)
| x.__hash__() == hash(x)
|
| __le__(...)
| x.__le__(y) == x=y
|
| __len__(...)
| x.__len__() == len(x)
|
| __lt__(...)
| x.__lt__(y) == xy
|
| __mod__(...)
| x.__mod__(y) == x%y
|
| __mul__(...)
| x.__mul__(n) == x*n
|
| __ne__(...)
| x.__ne__(y) == x!=y
|
| __repr__(...)
| x.__repr__() == repr(x)
|
| __rmod__(...)
| x.__rmod__(y) == y%x
|
| __rmul__(...)
| x.__rmul__(n) == n*x
|
| __str__(...)
-- More --
(and so on)
___
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: Alex Martelli wrote: 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. I'd like the inputhook to be able to define the prompt. I'm not sure how this could be accomplished. Another API would be that the inputhook returns what line or command should be executed instead, e.g. def default_inputhook(statement): if statement.endswith(?): return help(%s) % statement[:-1] etc. And you're on your way to re-writing ipython: In [1]: x='hello' In [2]: x? Type: str Base Class: type 'str' String Form:hello Namespace: Interactive Length: 5 Docstring: str(object) - string Return a nice string representation of the object. If the argument is a string, the return value is the same object. I also started it with let's add a cool hack to sys.ps1 and sys.displayhook in 10 minutes. Now we're at 18000 lines of python, a 70 page manual, and growing suport for remote distributed interactive computing, a new scientific computing GUI, and more :) If you like this kind of thing, by all means join in: I can use all the helping hands I can get. 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
Re: [Python-Dev] When do sets shrink?
Noam Raphael wrote: I'm not saying that practically it must be used - I'm just saying that it can't be called a heuristic, and that it doesn't involve any fancy overkill size hinting or history tracking. It actually means something like this: 1. If you want to insert and the table is full, resize the table to twice the current size. 2. If you delete and the number of elements turns out to be less than a quarter of the size of the table, resize the table to half of the current size. sure sounds like a heuristic algorithm to me... (as in not guaranteed to be optimal under all circumstances, even if it's probably quite good in all practical cases) /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] New PEP: Using ssize_t as the index type
Not sure what I think of the proposal (though I guess I'm overall +0 -- needs to be done sometime and no time like the present). However, I think this PEP should be held up as an example of how to write a good PEP. Aside from my inability to follow some of the arcane points due to lack of C programming skill, this PEP was extremely readable and well-organized. Nice job! -- 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] New PEP: Using ssize_t as the index type
Aahz wrote: However, I think this PEP should be held up as an example of how to write a good PEP. Aside from my inability to follow some of the arcane points due to lack of C programming skill, this PEP was extremely readable and well-organized. Nice job! Thanks! Part of it probably stems from thinking about this stuff a lot. 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
Fernando Perez wrote: In [1]: x='hello' In [2]: x? /.../ Docstring: str(object) - string Return a nice string representation of the object. If the argument is a string, the return value is the same object. I'm not sure what I find more confusing: a help system that claims that the variable x returns a nice string representation of an object, or that there's no help to be found for hello. x = hello help(x) no Python documentation found for 'hello' /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] When do sets shrink?
On Thu, 2005-12-29 at 17:17 +0100, Fredrik Lundh wrote: Noam Raphael wrote: I'm not saying that practically it must be used - I'm just saying that it can't be called a heuristic, and that it doesn't involve any fancy overkill size hinting or history tracking. It actually means something like this: 1. If you want to insert and the table is full, resize the table to twice the current size. 2. If you delete and the number of elements turns out to be less than a quarter of the size of the table, resize the table to half of the current size. sure sounds like a heuristic algorithm to me... (as in not guaranteed to be optimal under all circumstances, even if it's probably quite good in all practical cases) /F My problem with this heuristic is it doesn't work well for the probably-fairly-common use-case of; fill it, empty it, fill it, empty it, fill it...etc. As Guido pointed out, if you do have a use-case where a container gets very big, then shrinks and doesn't grow again, you can manually cleanup by creating a new container and del'ing the old one. If the implementation is changed to use this heuristic, there is no simple way to avoid the re-allocs for this use-case... (don't empty, but fill with None... ugh!). My gut feeling is this heuristic will cause more pain than it would gain... -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ 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: Regarding the meme floating about the arrogance of Pythoneers: bloggers (pretty much by definition) are actually the most arrogant species; don't confuse bloggers say with most people think. Sure, but I'm not only talking about the mindless ranters here; it's also people that back their opinions with at least a few examples -- including exit (and its it's good for you that you have to learn more than you want at a time when you're not interested defenders), replies to what's wrong with Python's floating point type along the lines of that you don't under- stand how floating point works, and so on. (fwiw, this meme has also appeared on comp.lang.python quite a few times lately -- and no, I'm not confusing comp.lang.python with most people either) I do think it's a problem that Python advocates suffer from a everything's perfect all the time attitude. it ain't broke because we say so. I think it's a larger problem that Python developers suffer from the same attitude; in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. /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] When do sets shrink?
On 12/29/05, Fredrik Lundh [EMAIL PROTECTED] wrote: Noam Raphael wrote: I'm not saying that practically it must be used - I'm just saying that it can't be called a heuristic, and that it doesn't involve any fancy overkill size hinting or history tracking. It actually means something like this: 1. If you want to insert and the table is full, resize the table to twice the current size. 2. If you delete and the number of elements turns out to be less than a quarter of the size of the table, resize the table to half of the current size. sure sounds like a heuristic algorithm to me... (as in not guaranteed to be optimal under all circumstances, even if it's probably quite good in all practical cases) I'm not saying it's optimal, but it is really amortized O(1) per insert/delete. I looked up in Introduction to Algorithms for this, and it has a complicated explanation. A simple explanation is that after every resize the table is exactly half-full. Let's say it has n elements and the table size is 2*n. To get to the next resize, you have to do at least n/2 removals of elements, or n insertion of elements. After that, you do a resize operation. In either case, you do an O(n) resize operation after at least O(n) insertions/removals which are O(1) operations. This means that the toal cost remains O(n) per n simple operations, which you can say is O(1) per simple operation. I hope that if you read this slowly it makes sense... 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 Thu, Dec 29, 2005 at 04:22:35AM -0500, Bob Ippolito wrote: In this particular case, you might be better off just writing some Twisted code that periodically checks the size of the current process and does a gc.collect() when necessary. Of course, it requires some platform specific code, but presumably you only care about one, maybe two, platforms anyway. In function of time != in function of size. The timer may trigger too late. And anyway the point was to do it in autopilot mode, I already fixed my app with a gc.collect() after releasing the huge piece of memory. I'll try to write a testcase for it, that if python would be doing what I suggest, wouldn't push a system into heavy swap. ___ 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 07:14:32PM -0700, Neil Schemenauer wrote: [This message has also been posted.] 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. In ram_size (per my pseudocode) we have to account everything that can be possibly released by the gc by an inovcation of a deep gc.collect(). So if strings can't be freed by the gc (as a side effect of releasing other objects), then we don't necessairly need to account for them in the algorithm, otherwise we have to. I guess some strings can be freed by the gc too so it sounds like PyMem_ may be a more correct hooking point. We definitely must know the size of the free operation. The sad thing is that glibc knows it. size_t free_size(void * ptr) /* free and return size of freed object */ An API like the above would be able to answer our question at very little cost, but it requires changing glibc, and we'd need to make sure it's really the more efficient way of doing it before considering it, because I've some doubt at the moment (otherwise I wonder why something like the above doesn't already exist in glibc?!?). OTOH I guess not many apps are doing their own garbage collection, and the ones that do it, may be using their own allocators instead of the glibc ones. This reminds me about the pymalloc thing I heard about over time. That should be able to provide a pymalloc_free_size kind of thing returning the size of the object freed, we could start with that assuming it's more efficient than doing the accounting in the upper layer. PS. your mail client looks broken the way it handles CC ;) ___ 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] New PEP: Using ssize_t as the index type
Hi Martin, On Thu, Dec 29, 2005 at 03:04:30PM +0100, Martin v. L?wis wrote: New conversion functions PyInt_FromSsize_t, PyInt_AsSsize_t, PyLong_AsSsize_t are introduced. PyInt_FromSsize_t will transparently return a long int object if the value exceeds the MAX_INT. I guess you mean LONG_MAX instead of MAX_INT, in the event that ssize_t is larger than a long. Also, distinguishing between PyInt_AsSsize_t() and PyLong_AsSsize_t() doesn't seem to be useful (a quick look in your branch makes me guess that they both accept an int or a long object anyway). The conversion codes 's#' and 't#' will output Py_ssize_t if the macro PY_SIZE_T_CLEAN is defined before Python.h is included, and continue to output int if that macro isn't defined. Hum. It would be much cleaner to introduce a new format character to replace '#' and deprecate '#'... Compatibility with previous Python versions can be achieved with the test:: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #endif and then using Py_ssize_t in the rest of the code. Nice trick :-) As far as I can tell you have done as much as possible to ensure compatibility, short of adding new slots duplicating the existing ones with the new signature -- which would make abstract.c/typeobject.c a complete nightmare. I'm +1 on doing this in 2.5. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] floating point literals don't work in non-US locale in 2.5
Not the first time this happened. :-( Could someone add a unit test for this please? --Guido On 12/28/05, Fredrik Lundh [EMAIL PROTECTED] wrote: 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/guido%40python.org -- --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] floating point literals don't work in non-USlocale in 2.5
Guido wrote: Not the first time this happened. :-( Could someone add a unit test for this please? Hye-Shik Chang just added the necessary tests to his bugfix patch. I'll check this in later tonight. /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
The F-bot writes: in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. +1 QOTF. Seriously... I've seen this behavior also, but I haven't ever thought about it as clearly as Fredrik does here. When we go to answer questions we ought to pause briefly first and decide which of these categories applies to a given piece of behavior. I think users will be understanding if we're honest about what are the accidents -- every language or software package has some, and just because it's an accident does NOT mean we should fix it. -- Michael Chermside ___ 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 Chermside wrote: Seriously... I've seen this behavior also, but I haven't ever thought about it as clearly as Fredrik does here. When we go to answer questions we ought to pause briefly first and decide which of these categories applies to a given piece of behavior. I think users will be understanding if we're honest about what are the accidents -- every language or software package has some, and just because it's an accident does NOT mean we should fix it. But we do that (atleast I do): when I believe something is wrong, I don't argue it is right; instead, I ask for a contribution of fixes. I do argue it is right when I believe it is right. 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 Chermside wrote: The F-bot writes: in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. +1 QOTF. Seriously... I've seen this behavior also, but I haven't ever thought about it as clearly as Fredrik does here. When we go to answer questions we ought to pause briefly first and decide which of these categories applies to a given piece of behavior. I think users will be understanding if we're honest about what are the accidents -- every language or software package has some, and just because it's an accident does NOT mean we should fix it. it's indeed a matter of trade-offs. Converting NameErrors into commands doesn't look like a good trade off in terms of expectations management and understandable behavior. Ka-Ping Yee ExitHatch still seem a reasonable improvement. Fernando Perez considerations about Python vs. commands and prefixing and extra-linguistic extensions seem also on spot. It's not a matter of defending the status quo, more about what kind of price is reasonable for DWIM. ___ 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
Aahz wrote:
On Wed, Dec 28, 2005, Brett Cannon wrote:
On 12/28/05, Aahz [EMAIL PROTECTED] wrote:
Here's yet a different take on this: .. change the startup message...
Type help, copyright, credits or license for more information.
Let's add another line that says
Type quit() to exit
...
Or, perhaps:
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to exit')
exit = _Quitter('The exit command. Type exit() to exit')
--Scott David Daniels
[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] New PEP: Using ssize_t as the index type
[Martin v. Löwis] ... PEP: XXX Title: Using ssize_t as the index type +1, and for Python 2.5, and the sooner done the less painful for all. Same concerns as Armin, where this is especially unattractive: The conversion codes 's#' and 't#' will output Py_ssize_t if the macro PY_SIZE_T_CLEAN is defined before Python.h is included, and continue to output int if that macro isn't defined. Better to use a new gibberish character and deprecate the old one? Otherwise I'm afraid we'll be stuck supporting PY_SIZE_T_CLEAN forever, and it's not good to have the meaning of a format string depend on the presence or absence of a #define far away in the file. A suggestion: ... In these cases, three strategies are available: * statically determine that the size can never exceed an int (e.g. when taking the sizeof a struct, or the strlen of a file pathname). In this case, add a debug assert() that the value is indeed smaller than INT_MAX, and cast the value to int. That can be done in one gulp via: some_int = Py_SAFE_DOWNCAST(some_value, Py_ssize_t, int); In a debug build that will assert-fail if some_value loses info when cast from Py_ssize_t to int. If people had been careful, this would already be in use when casting from size_t to int; there's even one place in unicodeobject.c that does so ;-). ___ 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] New PEP: Using ssize_t as the index type
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Please let me know what you think. Regards, Martin PEP: XXX Title: Using ssize_t as the index type [SNIP] +1 from me. As everyone else is saying, this has to happen at some point and 2.5 is as good as any. -Brett ___ 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] [Doc-SIG] that library reference, again
On 12/29/05, Fredrik Lundh [EMAIL PROTECTED] wrote: however, given that the discussion that led up to this has been dead for almost a week, You mean since Christmas? I'm beginning to fear that I've wasted my time on a project that nobody's interested in. Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. Yes, I'm biased. So are you. are we stuck with latex for the foreseeable future? Until we have something clearly and significantly better, yes. -- David Goodger http://python.net/~goodger ___ 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] [Doc-SIG] that library reference, again
David Goodger wrote: however, given that the discussion that led up to this has been dead for almost a week, You mean since Christmas? I'm beginning to fear that I've wasted my time on a project that nobody's interested in. Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. Really? Have you read my list of goals? Does LaTeX address all of them? Does ReST? If not, can you explain why they're not important. Yes, I'm biased. So are you. I don't think you understand the problem, so your bias is irrelevant. This is all about semantics, not presentation markup. All I've seen from the ReST camp is handwaving, there's nothing in the documentation that indicates that semantic markup has ever been a design goal in ReST, and nobody I've talked to who've tried using ReST for rich semantic markup considers it to be an alternative. This isn't about bias, this is about technical suitability. If you think otherwise, I suggest you put pick a couple of typical document pages and show how they would look in ReST, how the corresponding semantic model will look (and when I say semantic, I mean in Python terms, not in ReST presentation terms), and how to get from LaTeX to ReST+semantics and HTML+ semantics without having to rewrite everything from scratch. We know that you have big hats over in ReST-land; now show us some cattle. /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] New PEP: Using ssize_t as the index type
Martin v. Löwis wrote:
Please let me know what you think.
+1. in honor of the Bike Shed Effect, I'm going to assume that you've
thought of everything.
:::
well, one thing seems to missing from your PEP: in several modules, you've
changed the cast used in the type table. e.g.
--- python/branches/ssize_t/Modules/_elementtree.c (original)
+++ python/branches/ssize_t/Modules/_elementtree.c Tue Dec 20 09:52:16 2005
@@ -1228,7 +1228,7 @@
}
static int
-element_setitem(ElementObject* self, size_t index, PyObject* item)
+element_setitem(ElementObject* self, Py_ssize_t index, PyObject* item)
{
int i;
PyObject* old;
@@ -1373,7 +1373,7 @@
0, /* sq_repeat */
(ssizeargfunc) element_getitem,
(ssizessizeargfunc) element_getslice,
-(sizeobjargproc) element_setitem,
+(ssizeobjargproc) element_setitem,
(ssizessizeobjargproc) element_setslice,
};
is this change backwards compatible ?
/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
Scott David Daniels [EMAIL PROTECTED] wrote:
Or, perhaps:
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to exit')
exit = _Quitter('The exit command. Type exit() to exit')
FWIW, I like this kind of solution best. Something magical would be
a mistake. I don't like the status quo because there is no
cross-plaform way to indicate EOF (or more pedantically push
current line). Maybe we can make everyone happy by making the
'quit' and 'exit' objects callable and changing the message to
something like:
Use quit() or Ctrl-D (i.e. EOF) to exit.
Cheers,
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
Neil Schemenauer wrote:
Scott David Daniels [EMAIL PROTECTED] wrote:
Or, perhaps:
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to exit')
exit = _Quitter('The exit command. Type exit() to exit')
FWIW, I like this kind of solution best. Something magical would be
a mistake. I don't like the status quo because there is no
cross-plaform way to indicate EOF (or more pedantically push
current line). Maybe we can make everyone happy by making the
'quit' and 'exit' objects callable and changing the message to
something like:
Use quit() or Ctrl-D (i.e. EOF) to exit.
Cheers,
This sounds pretty good actually (especially combined with the modifed startup
banner which tells you how to exit).
As Fernando pointed out, anything else means we'd be well on our way to
re-inventing IPython (although I'd be interested to know if sys.inputhook
would have made IPython easier to write).
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] [Doc-SIG] that library reference, again
[Fredrik Lundh] I'm beginning to fear that I've wasted my time on a project that nobody's interested in. [David Goodger] Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. [Fredrik Lundh] Really? Yes, really. Have you read my list of goals? Yes, and I mostly agree with most of them. One is worded in a very slanted way: * Build on existing non-Python-specific documentation standards and tools, where possible (basic html, javadoc, xhtml modules, etc). It seems that this goal is specifically written to exclude ReST. Javadoc is only a standard in the Java world. LaTeX *is* an existing language-independent standard, and has a much longer history than javadoc. I'd re-write the above goal as: * Build on existing documentation standards and tools, where possible. Another goal is highly biased toward XML-style markup: * Make it trivial to do basic rendering to HTML (a few re.sub calls should suffice), to enable simple tools (CGI scripts, etc) to be able to render reference documentation. This is the tail wagging the dog. This item is under-specified: * Make is easy to do advanced rendering to HTML, XHTML or XML models (e.g. typographic issues, navigation, dynamic styling, etc.). No more -- dashes and silly ``quotes''. The second sentence lacks a rationale. What's wrong with -- dashes? What's silly about ``quotes''? Your list is missing an important goal: * Easy to read. The final paragraph of the Project Goals section lacks context and contains a false statement: The semantic model should be simple, python-oriented, and more detailed than today. For example, while a ReST-based solution knows that open in a given context should be rendered in bold, and a LaTeX-based solution knows that the given open is a function, the PythonDoc model also knows that it refers to the os.open function, rather than the built-in open function. The reference to ReST is wrong here; ReST certainly can know the semantics of a given identifier. I'd like to see an example of how the HTML+PythonDoc markup indicates that a particular open is os.open and not __builtins__.open. Does LaTeX address all of them? Perhaps not. So? It works well enough. Does ReST? Not currently, but so what? I didn't propose ReST as an alternative to LaTeX for Python's documentation. All I'm saying is that the proposed HTML+PythonDoc markup is not significantly better than the status quo. I don't think there's enough benefit to make leaving LaTeX worthwhile. IOW: -1 on replacing LaTeX with HTML+PythonDoc. If not, can you explain why they're not important. Yes, I'm biased. So are you. I don't think you understand the problem, so your bias is irrelevant. This is all about semantics, not presentation markup. I don't think you understand ReST except superficially. In any case, ReST is irrelevant to this discussion. I do not consider ReST a suitable replacement for LaTeX in Python's docs at present. My bias is simple: I am against wasting the time and effort required to replace one form of verbose markup with a different but equivalent form. The proposed solution is no better than the status quo. I agree with the people who have stated that they find the direct writing of HTML painful. IMO, the markup itself is almost irrelevant. As others have stated, writing good documentation is hard. People will latch on to any excuse to avoid it, and markup is convenient. But even if the docs had no markup whatsoever, if they were written in plain text like RFCs, I doubt there would be significantly more patch contributions. Plain text patches are already accepted; perhaps this fact needs more emphasis, but that's all. We know that you have big hats over in ReST-land; now show us some cattle. Moo. Or would you prefer the Buddhist mu? What *are* you talking about? -- David Goodger http://python.net/~goodger 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] a quit that actually quits
Samuele Pedroni wrote: Michael Chermside wrote: The F-bot writes: in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. +1 QOTF. Seriously... I've seen this behavior also, but I haven't ever thought about it as clearly as Fredrik does here. When we go to answer questions we ought to pause briefly first and decide which of these categories applies to a given piece of behavior. I think users will be understanding if we're honest about what are the accidents -- every language or software package has some, and just because it's an accident does NOT mean we should fix it. Most of the times I've asked questions along these lines I've gotten well-considered answers (usually because something I thought was a deliberate design decision on Guido's part turned out to simply be an accident of the way it happened to be implemented in CPython). it's indeed a matter of trade-offs. Converting NameErrors into commands doesn't look like a good trade off in terms of expectations management and understandable behavior. Ka-Ping Yee ExitHatch still seem a reasonable improvement. Fernando Perez considerations about Python vs. commands and prefixing and extra-linguistic extensions seem also on spot. It's not a matter of defending the status quo, more about what kind of price is reasonable for DWIM. I think Fredrik has made an excellent case for promoting the quit exit interpreter-only builtins to be proper callables. Hell, we even have that capability for the callable that displays the *license* text. . . surely quitting the interpreter is far more important than being able to display the license text, but the support for the latter is significantly better: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. Py exit 'Use Ctrl-Z plus Return to exit.' Py quit 'Use Ctrl-Z plus Return to exit.' Py license Type license() to see the full license text Py type(license) class 'site._Printer' Counting blank lines, 60 lines of site.py are devoted to getting copyright, credit and license to work right, 16 to getting help to work, and only 12 to setting quit and exit to the 'right' strings - and due to modules like readline for Windows and differences in the way interpreters buffer the line input, the exit string for Windows is not always correct. 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
[Python-Dev] Naming conventions in Py3K
In a fair number of cases, Python doesn't follow its own recommended naming conventions. Changing these things would break backward compatibility, so they are out of the question for Python 2.*, but it would be nice to keep these in mind for Python 3K. Constants in all caps: NONE, TRUE, FALSE, ELLIPSIS Classes in initial-caps: Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict, and lots of classes in the standard library, e.g. anydbm.error, csv.excel, imaplib.error, mutex.mutex... I know these probably look a little funny now to most of us, as we're used to looking at today's Python (they even look a little funny to me) but i'm pretty convinced that consistency will be better in the long run. -- ?!ng ___ 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
Nick == Nick Coghlan [EMAIL PROTECTED] writes: Nick Samuele Pedroni wrote: It's not a matter of defending the status quo, more about what kind of price is reasonable for DWIM. IMHO, +N*10^6 for simplicity, regularity, and discoverability, -1 for DWIM in the interpreter. DWIM is for wrappers, interactive tutorials, and IDEs. Nick I think Fredrik has made an excellent case for promoting the Nick quit exit interpreter-only builtins to be proper Nick callables. No, Fredrik has made a good (but not good enough!) case for making them syntax (or for adding the concept of interpreter command to the specification), but your own example of license works against you for callables: Nick Hell, we even have that capability for the callable that Nick displays the *license* text. . . surely quitting the Nick interpreter is far more important than being able to display Nick the license text, but the support for the latter is Nick significantly better: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. Py license Type license() to see the full license text Py Now, unlike the case of quit, where the user did something undocumented (albeit natural) that really is rude (and its semantics are no better than the support for quit). (Example edited to enhance the effect.) I do think it's reasonable that those callables be somewhat python-newbie-friendly. What I would want to see is papa% python Python 2.4.2 (#1, Dec 23 2005, 01:55:50) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type help(), copyright(), credits() or license() for more information. Type EOF (Ctrl-D) to end the interpreter session. help Type help(). In Python, work is done by function calls, not statements or commands. This message is the printable representation of the help object. help() You may exit the interpreter with an EOF (Ctrl-D), or by calling a system function or raising an appropriate exception. [ ... etc, etc, ... ] copyright, credits, license, quit, and exit would be treated similarly (except maybe they should not be quite so educational, just the brief reminder 'Type callable(). Type help() for help.' should be enough). I definitely don't think help() should advertise exit(), as it is too similar to sys.exit(). I'm -1 on quit() being advertised because I'm -1 on DWIM in principle, but if DWIM is accepted for this purpose, I don't see practical harm in advertising it. IMO, in the end making quit callable really isn't responsive to Fredrik's point. Which is AIUI that most interactive shells do have a quit command, and newbies are going to expect Python to have one, too. -- 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] Naming conventions in Py3K
On 12/29/05, Ka-Ping Yee [EMAIL PROTECTED] wrote: In a fair number of cases, Python doesn't follow its own recommended naming conventions. Changing these things would break backward compatibility, so they are out of the question for Python 2.*, but it would be nice to keep these in mind for Python 3K. Constants in all caps: NONE, TRUE, FALSE, ELLIPSIS Classes in initial-caps: Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict, and lots of classes in the standard library, e.g. anydbm.error, csv.excel, imaplib.error, mutex.mutex... I know these probably look a little funny now to most of us, Oh yeah. =) as we're used to looking at today's Python (they even look a little funny to me) but i'm pretty convinced that consistency will be better in the long run. Well, the problem is obviously requiring existing Python coders to have to re-educate themselves and the amount of code breakage. Luckily stuff like this should be changeable by some script that can try to convert 2.x code to 3.0 code. I am fine with changing the built-in types, but changing the built-in singletons just looks *really* odd to me. So odd that I just don't want to see them changed. I mean when I think of constants, I think of a variable that references an object and that reference never changes. The built-ins you are referencing, though, are singletons: named objects that are not variables. So keeping their naming scheme as-is does not feel like a breaking of the rules to me since they are not treated the same (especially at the C level). -Brett ___ 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] [Doc-SIG] that library reference, again
On 29 Dec 2005, at 18:58, David Goodger wrote: [Fredrik Lundh] I'm beginning to fear that I've wasted my time on a project that nobody's interested in. [David Goodger] Could be. I don't see HTML+PythonDoc as a significant improvement over LaTeX. [Fredrik Lundh] Really? Yes, really. Just out of curiosity (really -- not trying to jump into the flames) why not just use epydoc? If it's good enough for 3rd-party python libraries, isn't that just a small step from being good enough for the builtin libraries? robey ___ 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] [Doc-SIG] that library reference, again
Robey Pointer wrote: [Fredrik Lundh] Really? Yes, really. Just out of curiosity (really -- not trying to jump into the flames) why not just use epydoc? If it's good enough for 3rd-party python libraries, isn't that just a small step from being good enough for the builtin libraries? but epydoc is a docstring-based format, right? I'm trying to put together a light-weight alternative to the markup used for, primarily, the current library reference. moving all of (or parts of) the reference documentation in to the library source code would be an alternative, of course [1], but that would basically mean starting over from scratch. (but tighter integration is on my list; with a better semantic markup, you can import reference documentation into a module's docstrings at runtime, the builtin help can point you directly to the documentation for a given class, etc.). /F 1) I'm using a mix of wiki-based introductions and machine generated markup for e.g. the Tkinter manual; an example: http://effbot.org/tkinterbook/listbox.htm ___ 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: 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. After beating on this for half an hour I am coming to the conclusion that there is no way the enum_print function is invoked. No matter what I try, Python always calls enum_str if available. If I set the enum_str slot to 0, it calls enum_repr. If I set that slot to 0 as well it calls the tp_str method of PyInt_Type, since the Boost.Python enum type inherits from it. I have no clue how I can crash the VC7/VC8 mix doing normal things. 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
