I've been taking a close look at the API for multiprocessing and
threading, and have discovered a somewhat strange pattern that occurs
multiple times in both interfaces: factory functions with names that
start with a capital letter so they look like they're actually a class.
At first I thought it was a quirk of the multiprocessing implementation,
but then I discovered that the threading module also does it for all of
the synchronisation objects as well as threading.Timer, with examples like:
def Event(*args, **kwds):
return _Event(*args, **kwds)
Is this just intended to discourage subclassing? If so, why give the
misleading impression that these things can be subclassed by naming them
as if they were classes?
How should this be handled when it comes to the addition of PEP 8
compliant aliases? Add aliases for the factory functions that start with
a lower case letter, but otherwise leave the structure of the modules
unchanged? Or should the trivial functions like the one above be dropped
and made direct aliases for the classes they are currently wrapping?
Option 1 has the virtue of being perfectly backwards compatible in the
threading case, while option 2 is a little riskier, so I'm inclined to
go with option 1 (keeping the factory functions, but giving them
non-class like names in the case of multiprocessing, or aliases in the
case of threading).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Since Python 2.4 (maybe 2.2 or older), fileobj.read(4.2) displays an error and
works as fileobj.read(4).
__main__:1: DeprecationWarning: integer argument expected, got float
It should raises an error instead of a warning, it has no sense to read a
partial byte :-) But that should breaks some applications?
Well, the real problem is os.urandom(4.2) which goes to an unlimited loop:
while len(bytes) < n:
bytes += read(_urandomfd, n - len(bytes))
because read(0.2) works as read(0) :-/
One of these days, I'm actually going to remember that I need to click
"Reply All" when posting to this list... . Sorry for the duplicate,
On Tue, Sep 2, 2008 at 6:45 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote:
> A better way would be to start a command process with
> the Python directory added to PATH just for that
This is similar to what Visual Studio or the Windows SDK do to give
you a command prompt with the PATH and other environmental variables
setup "correctly" -- they add a shortcut to a batch file that's set to
keep the command prompt open after the batch file runs.
> How easy would that be to do on Windows? Do environment
> variables get inherited by child processes the way
> they do on Unix?
Generally, yes. I think there's a catch in that there are ways to
start processes that don't make them children of your process, but I
don't remember why I think that.
One other reason not to mess with the PATH -- at least by default --
is that the user may have multiple copies of Python installed. I know
I have at least one machine with 2.4.5, 2.5.2, 2.6b2 and 3.0b2
installed -- and I don't want *any* of them in my path.
The download page doesn't list any Windows installer for 2.6b3:
I suppose this is due to Martin building the installers and him not
be available at the moment.
Since Python on Windows will likely only get very few beta testers
without a Windows installer build, I'd suggest to postpone the
RC1 release that's planned for tomorrow to get more feedback for the
Professional Python Services directly from the Source (#1, Sep 02 2008)
>>> 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,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
It seems that the frustration with super revolves around how Python
currently conflates (as well as many users) two very different types
of inheritance, both "is-a" and "has-a" (or compositional)
inheritance. Unfortunately, Python assists this confusion because the
language doesn't provide a distinct enough way to differentiate
For the former (i.e. is-a inheritance), users should not have to
explicitly make a call to the super class (via super() or
otherwise)--this should be automatic for every method held in common
so as to guarantee the invariants of the simpler class. For this type
of inheritance it makes more sense to be explicit about *bypassing* a
call to the parent class--IF necessary (perhaps to take advantage of
an optimization available only in the subclass)--rather than explicit
about *making* one. This would remove many of the bugs, misuses, and
frustrations with super(). No more ambiguity and confusion because
the language now guarantees certain behavior. Super() would then be
limited to cooperative mixin classes; for all others, explicit naming
of the class would be required. But perhaps that there is some
language abstraction that has yet to be fully invented that would tie
it all together nicely.
By the way, regarding your trait implementation, it may be worthwhile
revisiting the discussion surrounding the Prothon language discussed a
few years ago on comp.lang.python which got rid of classes and
metaclasses and replaced them with prototypes.
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface which leads to weird bugs, also the performance
of a Python implementation is not that great.
To fight that problem I want to proposed a new class in "collections"
called odict which is a dict that keeps the items sorted, similar to
a PHP array.
The interface would be fully compatible with dict and implemented as
dict subclass. Updates to existing keys does not change the order of
a key but new keys are inserted at the end.
Additionally it would support slicing where a list of key, value tuples
is returned and sort/reverse/index methods that work like their list
equivalents. Index based lookup could work via odict.byindex().
An implementation of that exists as part of the ordereddict implementation
which however goes beyond that and is pretty much a fork of the python
Some reasons why ordered dicts are a useful feature:
- in XML/HTML processing it's often desired to keep the attributes of
an tag ordered during processing. So that input ordering is the
same as the output ordering.
- Form data transmitted via HTTP is usually ordered by the position
of the input/textarea/select field in the HTML document. That
information is currently lost in most Python web applications /
- Eaiser transition of code from Ruby/PHP which have sorted
associative arrays / hashmaps.
- Having an ordered dict in the standard library would allow other
libraries support them. For example a PHP serializer could return
odicts rather then dicts which drops the ordering information.
XML libraries such as etree could add support for it when creating
elements or return attribute dicts.