headers
tjreedy | 1 Jun 2008 01:29
Picon
Favicon

Re: [Python-Dev] Finishing up PEP 3108


"Georg Brandl" <g.brandl <at> gmx.net> wrote in message 
news:g1rr4o$956$1 <at> ger.gmane.org...
> Of course, it would also be nice for ``help("if")`` to work effortlessly,
> which it currently only does if the generated HTML documentation is
> available somewhere, which it typically isn't -- on Unix most 
> distributions
> put it in a separate package (from which pydoc won't always find it
> of its own), on Windows only the CHM file is distributed and must be
> decompiled to get single HTML files.

For 3.0a5, it does not work even after decompiling (and setting the ENV var) 
as given in the instructions (which are inadequate for many users anyway).
Permalink | Reply | 0 comments |
headers
Nick Coghlan | 1 Jun 2008 03:26
Picon
Gravatar

Re: Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

Raymond Hettinger wrote:
> If we don't do this, then String won't be the last request.  People will 
> want Datetime for example.  Pretty much any concrete type could have a 
> look-a-like that wanted its own ABC and for all client code to switch 
> from testing concrete types.

If I remember rightly, the machinery in the ABC's to support 
registration slows down some other operations with the types - do we 
want to pay that price all the time?

If we do, then it may be a matter of moving some of the registration 
machinery from ABCMeta up into type itself.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Raymond Hettinger | 1 Jun 2008 03:41
Favicon

Re: Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

From: "Guido van Rossum" <guido <at> python.org>
> I'm willing to meet you halfway. I really don't want isinstance(x,
> str) to return True for something that doesn't inherit from the
> concrete str type; this is bound to lead to too  much confusion and
> breakage.  

Probably true.  It was an attractive idea though.  Unless all client
code converts all its isinstance() tests from concrete to abstract,
life is going to be tough for people writing look-alike classes
which will have limited applicability.

> But I'm fine with a String ABC (or any other ABC, e.g.
> Atomic?) that doesn't define any methods but can be used for type
> testing. How about that?

That's progress!  It makes abstract substitution possible while
still saving us a lot of code and avoiding over-specification.  

I propose the following empty abstract classes:  
    String, Datetime, Deque, and Socket.

-1 on Atomic though.  Earlier in the thread it was made clear that
that atomicity is not an intrinsic property of a type; instead it varies
across applications (when flattening email folders, a multi-part mime 
message is atomic, but when flattening individual messages, a
multi-part mime message is just another nested container, part
of the tree, not one of the leaves).

Are you open to considering numbers.Integral to be one of the
new empty abstract classes?  That would make it much easier
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Hammond | 1 Jun 2008 03:28
Picon
Favicon
Gravatar

Re: PEP 371 Discussion (pyProcessing Module)

> 2008/5/30 Farshid Lashkari <flashk <at> gmail.com>:
> > I'm not sure if there will be any side affects to modifying
> > sys.executable though. Should this be the official way of supporting
> > embedded interpreters or should there be a
> > multiprocessing.setExecutable() method?
> 
> +1 for setExecutable (I'd prefer set_executable, to be PEP 8
> compliant). Make it explicit, rather than fiddling with stuff in sys
> manually.

sys.executable typically means the "current" executable, and py2exe etc
already fiddles with that.  The question in such a context seems to be "what
executable should I use for this processing functionality?".  In a py2exe
like environment, it might not be unreasonable to assume that if a custom
executable is to be used, that custom executable may have a different
command-line or other special requirements.  Further, I could imagine a
system that uses an alternative way of starting processes (eg, 'distributed
COM') where the concept of 'executable' (or even 'command-line') don't make
much sense.

So it seems that maybe simply "setExecutable()" isn't the correct
abstraction here, but maybe a "factory" approach, so the entire process
creation mechanism can be replaced rather than just the name of the
executable to spawn?

Cheers,

Mark

_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guido van Rossum | 1 Jun 2008 04:10
Favicon

Re: Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

On Sat, May 31, 2008 at 6:41 PM, Raymond Hettinger <python <at> rcn.com> wrote:
> From: "Guido van Rossum" <guido <at> python.org>
>> I'm willing to meet you halfway. I really don't want isinstance(x,
>> str) to return True for something that doesn't inherit from the
>> concrete str type; this is bound to lead to too  much confusion and
>> breakage.
>
> Probably true.  It was an attractive idea though.  Unless all client
> code converts all its isinstance() tests from concrete to abstract,
> life is going to be tough for people writing look-alike classes
> which will have limited applicability.

I'd rather require that people rewrite their code to benefit from some
new piece of functionality than foisting it upon them regardless,
breaking some perfectly fine working in the process. This is how we've
always done it.

>> But I'm fine with a String ABC (or any other ABC, e.g.
>> Atomic?) that doesn't define any methods but can be used for type
>> testing. How about that?
>
> That's progress!  It makes abstract substitution possible while
> still saving us a lot of code and avoiding over-specification.
> I propose the following empty abstract classes:     String, Datetime, Deque,
> and Socket.

Sounds like a mini-PEP is in place. It should focus on the code to
actually define these and the intended ways to use them.

> -1 on Atomic though.  Earlier in the thread it was made clear that
(Continue reading)

Permalink | Reply | 4 comments |
headers
Raymond Hettinger | 1 Jun 2008 05:09
Favicon

Re: Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

[Raymond]
>> I propose the following empty abstract classes:     String, Datetime, Deque,
>> and Socket.

[GvR]
> Sounds like a mini-PEP is in place. It should focus on the code to
> actually define these and the intended ways to use them.

Okay, will run a Google code search to see if real code exists that
runs isinstance tests on the concrete types.   Since the new classes 
are very lightweight (completely empty), these probably only need
minimal justification.  

The case for String has already been made.  And the concept of a 
Socket is already fully abstract. Not sure I really care about Deque.  

The Datetime.class is tricky.  The existence of many implementations
of date/time routines indicates that there is a need; however, they
don't share the API so they likely won't fit under a common umbrella.

>> Are you open to considering numbers.Integral to be one of the
>> new empty abstract classes?  That would make it much easier
>> for objects wanting to pass themselves as integers.  As it stands
>> now, an aspiring Integral class is required to implement a number
>> of  arcana including:  __rxor__, __rrshift__, __pow__, __invert__,
>> __index__, and __long__.
> 
> I don't think Integer should be completely abstract (what good is an
> int you can't add 1 to?) but I could be amenable to reducing the set
> of required operations (which could then resurface as a separate ABC).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Guido van Rossum | 1 Jun 2008 05:46
Favicon

Re: Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

On Sat, May 31, 2008 at 8:09 PM, Raymond Hettinger <python <at> rcn.com> wrote:
> [Raymond]
>>>
>>> I propose the following empty abstract classes:     String, Datetime,
>>> Deque,
>>> and Socket.
>
> [GvR]
>>
>> Sounds like a mini-PEP is in place. It should focus on the code to
>> actually define these and the intended ways to use them.
>
> Okay, will run a Google code search to see if real code exists that
> runs isinstance tests on the concrete types.

I wasn't asking for existing code -- I was asking for the code you
propose to add to abc.py (or wherever).

> Since the new classes are
> very lightweight (completely empty), these probably only need
> minimal justification.

Again, in a mini-PEP I'm not so much looking for justification but for
a precise spec.

> The case for String has already been made.

Actually I'm not sure. One you know that isinstance(x, String) is
true, what can you assume you can do with x?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexandre Vassalotti | 1 Jun 2008 06:11
Favicon
Gravatar

C API for gc.enable() and gc.disable()

Would anyone mind if I did add a public C API for gc.disable() and
gc.enable()? I would like to use it as an optimization for the pickle
module (I found out that I get a good 2x speedup just by disabling the
GC while loading large pickles). Of course, I could simply import the
gc module and call the functions there, but that seems overkill to me.
I included the patch below for review.

-- Alexandre

Index: Include/objimpl.h
===================================================================
--- Include/objimpl.h   (revision 63766)
+++ Include/objimpl.h   (working copy)
 <at>  <at>  -221,8 +221,10  <at>  <at> 
  * ==========================
  */

-/* C equivalent of gc.collect(). */
+/* C equivalent of gc.collect(), gc.enable() and gc.disable(). */
 PyAPI_FUNC(Py_ssize_t) PyGC_Collect(void);
+PyAPI_FUNC(void) PyGC_Enable(void);
+PyAPI_FUNC(void) PyGC_Disable(void);

 /* Test if a type has a GC head */
 #define PyType_IS_GC(t) PyType_HasFeature((t), Py_TPFLAGS_HAVE_GC)
Index: Modules/gcmodule.c
===================================================================
--- Modules/gcmodule.c  (revision 63766)
+++ Modules/gcmodule.c  (working copy)
 <at>  <at>  -1252,6 +1252,18  <at>  <at>
(Continue reading)

Permalink | Reply | 41 comments |
headers
Adam Olsen | 1 Jun 2008 06:28
Picon

Re: C API for gc.enable() and gc.disable()

On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti
<alexandre <at> peadrop.com> wrote:
> Would anyone mind if I did add a public C API for gc.disable() and
> gc.enable()? I would like to use it as an optimization for the pickle
> module (I found out that I get a good 2x speedup just by disabling the
> GC while loading large pickles). Of course, I could simply import the
> gc module and call the functions there, but that seems overkill to me.
> I included the patch below for review.

I'd rather see it fixed.  It behaves quadratically if you load enough
to trigger full collection a few times.

--

-- 
Adam Olsen, aka Rhamphoryncus
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 40 comments |
headers
Raymond Hettinger | 1 Jun 2008 08:15
Favicon

Mini-Pep: Simplifying the Integral ABC

Target:  Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008

Motivation
----------
The principal purpose of an abstract base class is to support multiple
implementations of an API; thereby allowing one concrete class to be
substitutable for another. This purpose is defeated when useful substitutions
are precluded because the ABC is too aggressive in its behavioral requirements
-- mandating too many methods, mandating methods that are difficult to
implement, or too closely following the full API of a single concrete type.

The Integral ABC is somewhat extensive and requires essentially every behavior
exhibited by the int concrete class.  Usefully, it provides for basic integer
behaviors like simple arithmetic and ordering relations.  However, the current
ABC goes beyond that and requires bit-flipping and other operations that are
not fundamental to the notion of being an integer.  That makes it challenging
to define a new Integral class that isn't already an int.

Proposal
--------
Remove non-essential abstract methods like __index__, three argument __pow__,
__lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__, __xor__,
__rxor__, __or__, __ror__, and __invert__, numerator, and denominator.

Discussion
----------
The only known use cases for variants of int are types that limit the range of
values to those that fit in a fixed storage width.
(Continue reading)

Permalink | Reply | 27 comments |

Gmane