Re: [Python-Dev] suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2))

[Bob Ippolito]

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

[Walter Dörwald]

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.

>> > sessions in which I want to perform some action repeatedly, and currently 
>> > the least typing is 4 characters (x())
>> > while this   would reduce it to two
>>
>> What's wrong with , ?
>
> 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".

OK, for that I've modified my .inputrc to map  to 
incremental-search-backwards. With this it's:   
(and it even works when the input is x("averylonginputstring")). That's not as 
fast as  , but it's close.
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

[Fredrik Lundh]

> (for those who follow non-python forums

make that "those who don't follow"





___
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?

[Donovan Baarda]

On Wed, 2005-12-28 at 18:57 -0500, Raymond Hettinger 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.

I don't think it will ever be worth it.

Re-allocations that grow are expensive, as they often need to move the
entire contents from the old small allocation to the new larger
allocation. Re-allocations that shrink can also be expensive, or at the
least increase heap fragmentation. So you want to avoid re-allocations
whenever possible.

The ideal size for any container is "as big as it needs to be". The best
heuristic for this is probably "as big as it's ever been, or if it just
got bigger than that, assume it's half way through growing". which is
what Python currently does.

Without some sort of fancy overkill size hinting or history tracking,
that's probably as good a heuristic as you can get.

-- 
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] When do sets shrink?

[Fredrik Lundh]

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).





___
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]

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.

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] file() vs open(), round 7

[Donovan Baarda]

On Sun, 2005-12-25 at 20:38 -0800, Aahz wrote:
> Guido sez in 
> http://mail.python.org/pipermail/python-dev/2004-July/045921.html
> that it is not correct to recommend using ``file()`` instead of
> ``open()``.  However, because ``open()`` currently *is* an alias to
> ``file()``, we end up with the following problem (verified in current
> HEAD) where doing ``help(open)`` brings up the docs for ``file()``:
[...]
> This is confusing.  I suggest that we make ``open()`` a factory function
> right now.  (I'll submit a bug report (and possibly a patch) after I get
> agreement.)

Not totally related but...

way back in 2001-2002, I did some work on writing a Virtual File System
interface for Python. See;

http://minkirri.apana.org.au/~abo/projects/osVFS

The idea was that you could import a module "vfs" as "os", and then any
file operations would go through the virtual file system. I had modules
for things "fakeroot", "mountable", "ftpfs" etc. The vfs module had full
os functionality so it was a "drop in replacement".

The one wart was open(), because it is the only filesystem operation
that wasn't in the os module. At the time I worked around this by adding
a vfs.file() method, and suggesting that people alias open() to
vfs.file(). Note that os.open() already exists as a low-level file open
function, and hence could not be used as a file-object-factory method.

I'm wondering if it wouldn't be a good idea to centralise all filesystem
operations into the os module, including open() or file(). Perhaps the
builtin open() and file() could call os.file()... or P3K could remove
the builtins... I dunno... it just felt ugly at the time that open() was
the one oddity.

-- 
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

[skip]

>> (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

[Martin v. Löwis]

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::

 P

Re: [Python-Dev] a quit that actually quits

[Fredrik Lundh]

[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





___
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]

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

[M.-A. Lemburg]

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

[Guido van Rossum]

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

[Guido van Rossum]

+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

[Collin Winter]

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?

[Guido van Rossum]

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

[Fredrik Lundh]

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 "", 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) <==> x>y
 |
 |  __hash__(...)
 |  x.__hash__() <==> hash(x)
 |
 |  __le__(...)
 |  x.__le__(y) <==> x<=y
 |
 |  __len__(...)
 |  x.__len__() <==> len(x)
 |
 |  __lt__(...)
 |  x.__lt__(y) <==> x 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

[Fernando Perez]

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: 
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?

[Fredrik Lundh]

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")





___
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]

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

[Martin v. Löwis]

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

[Fredrik Lundh]

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'





___
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] Bug in Py_InitModule4

[Martin v. Löwis]

Collin Winter wrote:
> 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.

There is still a way to call the function, though, through

import_ = svn.client.__dict__['import']
import_()

> 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 cannot see a "complete" solution, i.e. one that works for all
types, all methods and attribute names of all types, and so on.
There might not even be a way to determine all identifiers that
some module wants to support, other than by inspecting the source
code.

Also, this is not a frequently-reported problem: if people find they
cannot call a certain method, they just rename the function and
be done. If nobody detects that a function is not callable, then
the function is possible just useless.

If this is a SWIG-generated module, I would see a bug in SWIG here:
SWIG should know what the Python keywords are, and rename all functions
following some pattern (traditionally, suffixing an underscore).

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]

Fredrik Lundh wrote:

> 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".

Then, complain about docstrings:

Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x='hello'
>>> print x.__doc__
str(object) -> string

Return a nice string representation of the object.
If the argument is a string, the return value is the same object.



In ipython, '?' does the best it can to collect information about an object,
making heavy use of python's introspection capabilities.  It provides class and
constructor docstrings, function call signatures (built from the function code
object), and more.  Using ?? gives even more details, including
syntax-highlighted source when available.  For example:

In [5]: pydoc.ErrorDuringImport??
Type:   classobj
String Form:pydoc.ErrorDuringImport
Namespace:  Interactive
File:   /usr/lib/python2.3/pydoc.py
Source:
class ErrorDuringImport(Exception):
"""Errors that occurred while trying to import something to document it."""
def __init__(self, filename, (exc, value, tb)):
self.filename = filename
self.exc = exc
self.value = value
self.tb = tb

def __str__(self):
exc = self.exc
if type(exc) is types.ClassType:
exc = exc.__name__
return 'problem in %s - %s: %s' % (self.filename, exc, self.value)
Constructor information:
Definition: pydoc.ErrorDuringImport(self, filename, (exc, value, tb))


I'm sorry it can't provide the information you'd like to see.  It is still found
to be useful by many people, including myself.  You are welcome to use it, and
patches to improve it will be well received.

Best,

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?

[Donovan Baarda]

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")
> 
> 

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

[Fredrik Lundh]

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.





___
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]

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))

[Andrea Arcangeli]

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))

[Andrea Arcangeli]

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

[Armin Rigo]

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] When do sets shrink?

[Josiah Carlson]

Noam Raphael <[EMAIL PROTECTED]> wrote:
> 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...

This is understood by (I would expect) most people here (hash-tables
are (theoretically and practically) average as you state, but
(theoretically) worst-case as Martin states).

For resizing, a quick-and-dirty rule of thumb is that if you are
overallocating by a factor of f(n), the amount of work you will be
performing per insertion is ~cn/f(n) (1 <= c <= 2).  As per recent
discussions on lists, Python chooses f(n) to be n/8. (at least in the
list case) This says that every insertion is taking around ~8 memory
copies if/when the list is resized up, but practical experience has
shown that it also tends to minimize memory usage as the list grows.

It's all about tradeoffs.  Increasing general memory usage for the sake
of a lower constant or not is a tradeoff.  As is resizing or not
resizing as a list gets smaller.

Would changing the overallocation strategy change Python's performance? 
Likely, but possibly not noticable.  Would it change Python memory usage?
Yes. A vast majority of list use would cause larger allocations than
currently performed by the list allocator.  Want to test it?  Create a
micro benchmark which tests repeated append performance with the two
list allocation strategies and remember to note the memory usage of
Python after each test.

 - 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] floating point literals don't work in non-US locale in 2.5

[Guido van Rossum]

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
>
> 
>
>
>
> ___
> 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

[Fredrik Lundh]

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.





___
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]

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

[Martin v. Löwis]

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

[Samuele Pedroni]

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

[Scott David Daniels]

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

[Tim Peters]

[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

[Brett Cannon]

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

[David Goodger]

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 
___
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]

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.





___
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

[Fredrik Lundh]

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 ?





___
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]

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

[Nick Coghlan]

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

[David Goodger]

[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 



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

[Nick Coghlan]

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)


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

[Ka-Ping Yee]

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

[Stephen J. Turnbull]

> "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 "()".  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] a quit that actually quits

[Fernando Perez]

Nick Coghlan wrote:

> 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).

[sorry if this drifts off-topic for python-dev.  I'll try to provide useful info
on interactive computing in python here, and will gladly answer further
detailed discussion about ipython on the ipython-dev/user lists ]

In my case, I don't think it would have made that much of a difference in the
end, though initially it might have been tempting to use it.  IPython started
as my private collection of sys.ps{1,2} + sys.displayhook hacks in
$PYTHONSTARTUP.  I then discovered LazyPython, which had a great
sys.excepthook, and IPP, which was a full-blown derivative of
code.InteractiveConsole.  I decided to join all three projects, and thus was
ipython born.  Given that IPP was the 'architecture', from the moment we had
what is still today's ipython, it was based on code.InteractiveConsole, and at
that point I doubt that having sys.inputhook would have mattered.

Incidentally, just two days ago I removed the last connection to code.py: at
this point I had overridden so many methods, that there was no point in keeping
the inheritance relationship.  All I had to do was copy _two_ remaining
methods, and the main ipython class became standalone (this frees me for
ongoing redesign work, so it was worth doing it).

So in summary, while sys.inputhook would make it easy to do _lightweight_
interactive customizations, if you really want a more sophisticated and
featureful system, it probably won't matter.

Note that this is not an argument against sys.inputhook: exposing
customizability here may indeed be useful.  This will allow people to write,
with minimal effort, systems which pre-process special syntaxes and ride on top
of the python engine.  IPython exposes the exact same thing as a customizable
hook (called prefilter), and people have made some excellent use of this
capability.  The most notable one is SAGE:

http://modular.ucsd.edu/sage

a system for interactive mathematical computing (NSF funded).  If anyone is in
the San Diego area, the first SAGE meeting is in February:

http://modular.ucsd.edu/sage/days1/

and I'll be giving a talk there about ipython, including some of its design and
my plans for a more ambitious system for interactive computing (including
distributed computing) based on Python.  The prototypes of what we've done so
far are briefly described here (the first was funded by Google as a summer of
code project):

http://ipython.scipy.org/misc/ipython-notebooks-scipy05.pdf
http://ipython.scipy.org/misc/scipy05-parallel.pdf

I hope this is of some use and interest.

Regards,

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] Naming conventions in Py3K

[Brett Cannon]

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

[Robey Pointer]

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

[Fredrik Lundh]

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.).



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?

[Ralf W. Grosse-Kunstleve]

--- "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