Python component model

[Edward Diener No Spam]

The definition of a component model I use below is a class which allows
properties, methods, and events in a structured way which can be
recognized, usually through some form of introspection outside of that
class. This structured way allows visual tools to host components, and
allows programmers to build applications and libraries visually in a RAD
environment.

The Java language has JavaBeans as its component model which allows Java
applications to be built in a visual RAD way. Microsoft's .Net has a
component model built-in to its .Net class libraries as well as
supported by CLR which allows .Net applications to be built visually
using components created in any .Net supported language.

With Python things are different. There is no single component model
which allows Python developers to build components which will be used
and recognized by the various RAD Python tools on the market. Instead a
developer must create a slightly different set of Python classes for
each RAD Python tool. This is the situation despite Python's having
easily as much functionality, if not much more, as Java or .Net
languages such as C#, VB, or C++/CLI for creating components, and for
allowing visual tools to introspect the properties, methods, and events
of Python classes.

I believe that Python should have a common components model for all RAD
development environments, as that would allow the Python programmer to
create a set of classes representing components which would work in any
environment. I want to immediately point out that components do not
simply mean visual GUI components but what may be even more important,
non-visual components. Having used RAD development environments to
create applications, I have found such environments almost always much
better than coding complex interactions manually, and I believe that
visual development environments are almost a necessity in today's world
of large-scale, multi-tier, and enterprise applications.

Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?

[Kay Schluehr]

fumanchu wrote:

4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

I do think it's just about presenting component properties and their
types / value ranges. I do think this can be easily achieved using
decorators that might also add the right kind of token for
introspection purposes to the function/method attributes. Descriptors
i.e. customized binding semantics might cover one aspect of
componentization but as I understood Edward he asked for uniform
declarative semantics. Components in this sense are just specialized
objects such as TestCase classes in the PyUnit framework. What I still
do not understand is the reference to "many RAD" tools which is
completely hypothetical to me. The portability of components across
different GUI designers for the same underlying toolkit is a quite
speculative future requirement to say the least.

[Fredrik Lundh]

fumanchu wrote:

>4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

that's not that hard on a pure technical level; even a "basic" tool
like IDLE can hook itself into an executing Python process. once you're
hooked up, you can inspect and modify most about everything.

for example, doing remote tweaking of live Tkinter widget trees is
pretty straight-forward.

coming up with a good way to capture the modifications, and use them in
your actual application, is a bit harder. do you really want to replace
plain old source code with some kind of more or less obscure resource
files?

and designing a metadata vocabulary that's powerful enough to be useful
for more than just one or a few target domains might be really hard.

</F>

[Peter Maas]

Diez B. Roggisch wrote:

The amazing flexibility stems from the fact that it is _runtime_. This is
_exactly_ the difference between static and dynamic typing.

Not _exactly_. You can have static typing in an interpreted language (Java)
and dynamic typing in a machine language (Basic with variants).

--
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')

[Edward Diener No Spam]

Paul Boddie wrote:

sk**@pobox.com wrote:

>EdwardMy OP was just to query whether a component model existed for
EdwardPython, like JavaBeans for Java or .Net for C#, C++/CLI
Edwardetc.

For those of us who've never used Java, .Net or C++/CLI, a more concrete
description of what you were after from the beginning would have been
helpful.

>>From vague recollections of the original Java Beans technology, the

primary "innovation" was to have getProperty and setProperty methods,
along with things like isCapability and hasProperty, if I remember
correctly. None of this was really shocking to anyone using Python,
mostly because Python had __getattr__ and __setattr__ even back then
for customising real property/attribute access, and Python's run-time
introspection capabilities were superior to Java's (and probably still
are).

There is no argument on my part that Python's introspection and metadata
capabilities are superior to Java, as well as its potential attribute
as component property model. In the theoretical Python model I proposed,
the designer of the component must have the ability to specify which of
the component's attributes are properties and how this is controlled (
via __getattr__ and __setattr__ ? descriptors as someone else suggested
? other ideas ? ). Merely saying that all of an object's attributes are
component properties for the purposes of a visual RAD designer can not
be correct.

I actually think that Java's notion of preoperties in JavaBeans, which
are just getter and setter functions with a particular naming
convention, determined by Java as a default, or through an associated
BeanInfo class, is rather klutzy and much prefer that of .Net or
Borland's VCL where a particular language construct is used for
properties instead. Of course with Python's superior metadata abilities,
a particular new language construct shouldn't be necessary.

>
The other innovation was the introduction of standard interfaces for
listening to and dispatching events, where you implement some listener
interface and respond to events in order to "care about" those events.
I don't recall any particularly good mechanisms for connecting beans to
each other in order to fire off events, although the beanbox (or
whatever the graphical tool originally promoted was called) and/or the
IDE is supposed to help you with that part of the work.

The beanbox did nothing to help setup events, event sources, or event
listeners. It just presented a graphical example of a visual RAD tool
which could tie event sources to event listeners. It is onerous in
JavaBeans to connect event sources to event listeners, and takes a good
deal of manual coding although doing it is easy to understand.

>
The groovy 1990s API

1997.

Again Borland's VCL or .Net have much better solutions for events but
again require language constructs which Python ought not need given its
strong metadata possibilities to supply a component event model.

is actually viewable in various places; here, for
example:

http://www.doc.ic.ac.uk/~jpc1/linux/...-1.0/apis.html

The BDK is no longer supported in the latest version of Java and
JavaBeans. Instead there is a Bean Builder at
https://bean-builder.dev.java.net/ .

>
Despite the supposedly exciting advances heralded by Java Beans, a
large part of the technology was just codifying existing practices and
techniques, but it could be argued that such techniques have been
superseded by signal/slot mechanisms and more advanced event
architectures (pioneered by frameworks like Qt and since adopted by
Gtk, I believe).

I agree and I would want to have a component event model for Python that
is much superior to the JavaBeans event model in ease of use. A much
better ideal for component properties and component events is presented
by .Net, where there are actual language keywords which perform the
magic. I would guess that Qt and Gtk also follow a better ease of use
path, perhaps with macros in C++. But Python should be able to do as
good or better than any of these environments.

[Edward Diener No Spam]

fumanchu wrote:

Edward Diener No Spam wrote:

>OK, here is my idea of what such a component model envisages as a list
of items. After this, unless I get some intelligent comments from people
who might be interested in what I envision, or something very similar, I
will be off to investigate it myself rather than do battle with the
horde of people who will just tell me that Python, being a great
language, does not need what I have suggested.

[This quote hacked up by me:]

>1) Component property: This is a glorified attribute with a type that
a) can be specified in a "static" manner, or discovered dynamically,
b) has converters between a string and the actual value
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.

Whenever you say "glorified attribute", your first thought should be
"Python descriptor" (but not your last--it's not a cure-all). They are
able to do all of (a, b, c, d, e) which I marked in your text above.
For example, here's a descriptor for
attributes-you-want-to-persist-in-a-database from my ORM, Dejavu (see
http://projects.amor.org/dejavu/brow...nits.py#l290):
class UnitProperty(object):
"""Data descriptor for Unit data which will persist in storage."""

def __init__(self, type=unicode, index=False, hints=None, key=None,
default=None):
self.type = type
self.index = index
if hints is None: hints = {}
self.hints = hints
self.key = key
self.default = default

def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
return unit._properties[self.key]

def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
unit._properties[self.key] = value

def coerce(self, unit, value):
if value is not None and not isinstance(value, self.type):
# Try to cast the value to self.type.
try:
value = self.type(value)
except Exception, x:
x.args += (value, type(value))
raise
return value

def __delete__(self, unit):
raise AttributeError("Unit Properties may not be deleted.")

>a) can be specified in a "static" manner, or discovered dynamically,

The "component model" can either scan a class for instances of
UnitProperty or keep a registry of them in the class or elsewhere (via
a metaclass + add_property functions).

>b) has converters between a string and the actual value

Note the "coerce" function above. Something similar could be done for
serialization (which I can prove in my case because I use UnitProperty
to help produce SQL ;) but you could just as easily pickle
unit._properties and be done with it.

>c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.

Descriptors that only have __get__ are read-only; if they have __set__
they are read-write.

>e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.

Right. Descriptors allow the creator of a class to use "normal"
attributes (including functions) which don't participate in the
component model.

>2) Component event: This is an type which encapsulates an array, or a
list of callable objects with the same function signature, along with
the functionality to add and remove elements from the array, as well as
cycle through the array calling the callable objects as a particular
event is triggered. A component event is an event source for a
particular event. Component events have to be dicoverable by the Visual
RAD system so that an object's appropriate event handler, an event sink,
can be hooked to the component event itself, an event source, through a
design time interface which propagates the connection at run-time.

This can be accomplished by creating a ComponentEvent descriptor whose
__get__ returns an object with a __call__ method. Here's a base class
for something similar (again, from Dejavu):

class UnitAssociation(object):
"""Non-data descriptor method to retrieve related Units via
attributes."""

to_many = None

def __init__(self, nearKey, farClass, farKey):
# Since the keys will be used as kwarg keys, they must be
strings.
self.nearKey = str(nearKey)
self.farKey = str(farKey)

self.nearClass = None
self.farClass = farClass

def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
m = types.MethodType(self.related, unit, unitclass)
return m

def __delete__(self, unit):
raise AttributeError("Unit Associations may not be deleted.")

def related(self, unit, expr=None, **kwargs):
raise NotImplementedError

Subclasses override the "related" method, but a ComponentEvent class
could just as easily do:

def run(self, *args, **kwargs):
for sink in self.sinks:
sink(*args, **kwargs)

>3: Component serialization: A component which has its properties and
events set by a visual design-time RAD environment needs to be
serialized at design time and deserialized at run-time. This can be a
default serialization of all component properties and events, or the
component itself can participate in the serilization effort either
wholly or partly.

In Dejavu, the UnitProperty class is your "component property" and the
Unit class is the component. The Unit class has a copy method:

def __copy__(self):
newUnit = self.__class__()
for key in self.properties:
if key in self.identifiers:
prop = getattr(self.__class__, key)
newUnit._properties[key] = prop.default
else:
newUnit._properties[key] = self._properties[key]
newUnit.sandbox = None
return newUnit

It wouldn't be hard to replace "newUnit._properties[key] =
self._properties[key]" with "dump(self._properties[key])".

>4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

It's more of a coupling between a type and a tool. Only user-defined
types as component properties need their own property editor, whereas
all other Python types can be coupled with default property editors. Of
course the class designer must have a right to create their own property
editor for a particular type or a particular property of that type in
order to override the default property editors for a particular type.

>

>5) Custom type converters: A component should be able to specify a
custom converter for any property to convert, in both directions or
either direction, between the property's string value as seen by a
property editor and the actual value of the component property's type.

A ComponentProperty descriptor could include a custom pair of methods
to get/set as string. This is often done in web frameworks which need
to coerce incoming string values to the correct type.

Thanks for your information abouit using descriptors. I will look into
it further but I really appreciate your example.

>
All of which is to say: nobody's done this yet because parts 1, 2, 3
and 5 are trivial to do with descriptors, but actually building a
visual RAD environment is too much work. ;)

The idea of course is that with the correct component underpinnings and
perhaps high-level modules which make it easy for a visual RAD
environment to introspect the necessary component properties and
component events, as well as serialize them at design time and create
code to deserialize them at run-time, the work of creating a visual RAD
environment would not be so daunting.

[Fredrik Lundh]

Edward Diener No Spam wrote:

I agree and I would want to have a component event model for Python that
is much superior to the JavaBeans event model in ease of use.

isn't that an old Perlis quote? "I want a component event model in
which I need only say what I wish done"?

</F>

[Georg Brandl]

Bruno Desthuilliers wrote:

Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.

+1 QOTW

Agreed.

Georg

[Edward Diener No Spam]

Kay Schluehr wrote:

fumanchu wrote:

>>4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

I do think it's just about presenting component properties and their
types / value ranges. I do think this can be easily achieved using
decorators that might also add the right kind of token for
introspection purposes to the function/method attributes. Descriptors
i.e. customized binding semantics might cover one aspect of
componentization but as I understood Edward he asked for uniform
declarative semantics.

Uniform in the sense that a visual RAD tool introspecting a Python class
would be able to say that s type X is a component property and type Y is
a component event, and everything is is just normal Python code which
the RAD tool can ignore.

Components in this sense are just specialized
objects such as TestCase classes in the PyUnit framework.

Totally agreed. But the common functionality they add is valuable to
visual RAD tools.

What I still
do not understand is the reference to "many RAD" tools which is
completely hypothetical to me.

You are right that I should not have mentioned this without experience
with the many Python tools, notable Python web page development
environments, which are out there.

The portability of components across
different GUI designers for the same underlying toolkit is a quite
speculative future requirement to say the least.

It's been a success in the Java world with JavaBeans and EJBs within
environments like Eclipse, NetBeans, JBuilder, and others; and its been
a success in the .Net world with .Net components within Visual Studio,
Borland Development Studio, and potentially others, so ideally it could
be a success in the Python world.

I believe the only knock against Python, as opposed to Java or .Net, is
that it does not present enough ease of use environments to creating
large scale applications, whether Linux, Windows, or Web applications. I
believe part of that reason is because Python developers who, whether
they wanted to distribute their classes for free or want to sell them
for a profit, are presented with endless technologies built with Python,
each one demanding a slightly different approach to class reusability,
are reticent to develop their ideas for many different environments.

Wanting a common PME component model is a way of saying that Python
class developers can develop their classes as components and at least at
the base level can expect them to work flawlessly in any Python
environment. I am NOT against a particular environment building further
requirements on top of a common Python component model, and in fact
would expect it in many cases. But given inheritance in OOP, and in
Python of course, this might be as easy for me as deriving a new class
from my particular base class component for a particular visual RAD
development environment, adding the extra function needed onto my
derived class, and away we go.

[Edward Diener No Spam]

Fredrik Lundh wrote:

fumanchu wrote:

>>4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

that's not that hard on a pure technical level; even a "basic" tool
like IDLE can hook itself into an executing Python process. once you're
hooked up, you can inspect and modify most about everything.

for example, doing remote tweaking of live Tkinter widget trees is
pretty straight-forward.

coming up with a good way to capture the modifications, and use them in
your actual application, is a bit harder. do you really want to replace
plain old source code with some kind of more or less obscure resource
files?

The Visual Studio RAD IDE environment actually modifies source code
constructors, via an InitializeComponent() function called from it, in
order to set properties and events in components. It does mark the
function as such with comments in the source code. OTOH Borland's VCL
uses the resource file technique you scorn above, linking in the code
via resources and automatically updating a component's properties and
events from base class components constructors. I believe Java's JVM
automatically deserializes .ser files at run-time saved by a RAD
designer in order to set properties and events on an object of a class.

There are obviously numerous techniques, so one should theoretically
work well with Python.

>
and designing a metadata vocabulary that's powerful enough to be useful
for more than just one or a few target domains might be really hard.

That's the are I am most interested in.

[Peter Maas]

Bruno Desthuilliers schrieb:

Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.

+1 QOTW

No, please stop self-assuring, self-pleasing QOTWs! This afternoon
I was in the local book warehouse and went to the computer book
department. They had banned 2-3 Python books together with some
Perl- and C/C++ stuff into the last row. At the regular place I found
a huge pile of Java books and - in comparison to Java - a small but
growing number of books about Ruby in general, Ruby on Rails and -
new to me - JRuby.

Now I don't think that Ruby is a bad language. But I think Python is
better and it started earlier. I don't know whether Ruby on Rails was
a fluke or the result of clever analysis. Since a large part of
programming is web programming it is not bad to have a good and visible
tool in place to attract programmers. It is also a good idea to hook on
Java's success but while Jython 2.2 is in alpha state since 3 years I
see an increasing number of books/articles telling how to migrate from
Java to (J)Ruby. Since I started using Python 4 years ago I hear Ruby
people announce with an amazing audacitiy that Ruby is bound to be number
one and will for sure leave Python behind.

To prevent this to happen parts of the Python community should have a
more critical attitude to the language. Too often I hear the same
mantras being repeated over and over again (GIL, self, IDE etc.). I
don't say these mantras are all wrong but perhaps it would be good to
remove the GIL just to stop people talking about Python's lack of
multi-threading or polish Python's class syntax to stop people talking
about Python's OO being bolted on etc. Programmers often choose their
languages by very silly reasoning (silliest being the indentation issue)
and maybe we should take the silliness into account instead of laughing
about those silly folks.

I for my part would be happy to see a Delphi-like RAD tool for Python,
a reference implementation for web programming as part of the standard
library, Jython 2.5, Python for PHP or whatever attracts new programmers.

Peter Maas, Aachen

[Ilias Lazaridis]

Peter Maas wrote:

Bruno Desthuilliers schrieb:

Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.
>
+1 QOTW

No, please stop self-assuring, self-pleasing QOTWs! This afternoon
I was in the local book warehouse and went to the computer book
department. They had banned 2-3 Python books together with some
Perl- and C/C++ stuff into the last row. At the regular place I found
a huge pile of Java books and - in comparison to Java - a small but
growing number of books about Ruby in general, Ruby on Rails and -
new to me - JRuby.

Now I don't think that Ruby is a bad language. But I think Python is
better and it started earlier. I don't know whether Ruby on Rails was
a fluke or the result of clever analysis. Since a large part of
programming is web programming it is not bad to have a good and visible
tool in place to attract programmers. It is also a good idea to hook on
Java's success but while Jython 2.2 is in alpha state since 3 years I
see an increasing number of books/articles telling how to migrate from
Java to (J)Ruby. Since I started using Python 4 years ago I hear Ruby
people announce with an amazing audacitiy that Ruby is bound to be number
one and will for sure leave Python behind.

To prevent this to happen parts of the Python community should have a
more critical attitude to the language. Too often I hear the same
mantras being repeated over and over again (GIL, self, IDE etc.). I
don't say these mantras are all wrong but perhaps it would be good to
remove the GIL just to stop people talking about Python's lack of
multi-threading or polish Python's class syntax to stop people talking
about Python's OO being bolted on etc. Programmers often choose their
languages by very silly reasoning (silliest being the indentation issue)
and maybe we should take the silliness into account instead of laughing
about those silly folks.

I for my part would be happy to see a Delphi-like RAD tool for Python,
a reference implementation for web programming as part of the standard
library, Jython 2.5, Python for PHP or whatever attracts new programmers.

Peter Maas, Aachen

well said.

Based on a comment in this thread, I've just detected this one:

http://code.enthought.com/ets/

http://code.enthought.com/envisage/

BSD2 licensed, so it's very attractive as a foundation for a
joint-community-effort.

_very_ interesting stuff, i've placed in on the list for a later
review:

http://case.lazaridis.com/wiki/Stack

..

[Ilias Lazaridis]

Robert Kern wrote:

Edward Diener No Spam wrote:

....

You'll definitely want to take a look at Enthought's Traits (disclaimer:
I work for Enthought). I'm supposed to be on vacation now, so I'm not
going to give you the full rundown of Traits and Traits UI, so I'm
simply going to point you to the page we have about it:

http://code.enthought.com/traits/

It looks as if traits is an attempt to create a "property" in the
component terminology which I originally specified. I will take a look
at it.

It also provides an event model and a declarative UI layer as well as several
other things besides.

looks interesting.

what about persistency?

..

[Hendrik van Rooyen]

"Fredrik Lundh" <fr*****@pythonware.comwrote:

Nick Vatamaniuc wrote:

At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model.

8<----------------------------------------------------------------------------

implementing this using existing mechanisms is trivial (as the endless
stream of interface/component/adapter/trait implementations have shown
us); coming up with a good-enough-to-be-useful-for-enough-people
vocabulary is a lot harder.

not sure if its trivial - but agree about the generality - my meat is your
poison effect operating here -
and also - standards are not per se a *Good Thing* - they stifle both
inventiveness and diversity...

- Hendrik

[Kay Schluehr]

Hendrik van Rooyen wrote:

"Fredrik Lundh" <fr*****@pythonware.comwrote:

Nick Vatamaniuc wrote:

At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model.

8<----------------------------------------------------------------------------

implementing this using existing mechanisms is trivial (as the endless
stream of interface/component/adapter/trait implementations have shown
us); coming up with a good-enough-to-be-useful-for-enough-people
vocabulary is a lot harder.

not sure if its trivial - but agree about the generality - my meat is your
poison effect operating here -
and also - standards are not per se a *Good Thing* - they stifle both
inventiveness and diversity...

- Hendrik

Culture matters. Some things exist below a certain level of visibility
and are quite evident for their practitioners but hardly recognized by
anyone else.

http://bitworking.org/news/Why_so_ma...web_frameworks

There is not even a name for this kind of "coherent diversity" and at
least Python doesn't brand it in any way. Maybe Pythons "obvious one
way to do it" credo is more harmfull to the community as a whole than
not having invented RoR. Python is ironically not proofed by hype which
always favours a cyclopic universe of a single true solution.

[Bruno Desthuilliers]

Peter Maas wrote:

Bruno Desthuilliers schrieb:

>Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.

+1 QOTW

No, please stop self-assuring, self-pleasing QOTWs!

Certainly not !-)

(snip)

I for my part would be happy to see a Delphi-like RAD tool for Python,

Look for boa-constructor then.

a reference implementation for web programming as part of the standard
library,

wsgiref is part of the 2.5 stdlib.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Paul Boddie]

Peter Maas wrote:

Bruno Desthuilliers schrieb:

Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.
>
+1 QOTW

No, please stop self-assuring, self-pleasing QOTWs!

+1 QOTW! ;-)

[Java, Ruby, JRuby, the hype]

To prevent this to happen parts of the Python community should have a
more critical attitude to the language. Too often I hear the same
mantras being repeated over and over again (GIL, self, IDE etc.).

People who bring up stuff about self and indentation are just showing
their ignorance, in my opinion, since Python isn't the first language
to use self in such a way, and many C++ and Java programs use this
pervasively in order to make attribute scope explicit, whereas the
indentation matter is only troublesome with bad editing practices. I
don't think the community should spend any more time on these
criticisms.

However, the GIL and issues of tools and IDEs should be considered in a
more sophisticated way. I'm not advocating the removal of the GIL, but
there needs to be a better story for people wanting to use more than
one core or CPU within a single program on a multicore/multiprocessor
system. My contribution in that field has been the pprocess module [1]
which lets you play in a sort of multithreaded environment, although
you're actually using multiple processes whose globals are only shared
in a read-only sense, and the way forward may be to make this available
to Windows users by adding an os.fork implementation for them to the
standard library, as I suggested previously [2]. Meanwhile, whilst not
an IDE advocate myself, there really does need to be further
improvements in the analysis of Python source code so that people can
build improved tools to check Python programs for obvious
"compile-time" errors and to inspect the behaviour of large amounts of
code. One reads occasionally on the python-dev or python-3000 mailing
lists that some proposed change or other may or may not have an impact
on "real world" systems such as the standard library, but that no-one
can really say: we need to move beyond the "Python is just so dynamic"
meme and develop tools like PyLint and PyChecker much further.

I don't say these mantras are all wrong but perhaps it would be good to
remove the GIL just to stop people talking about Python's lack of
multi-threading or polish Python's class syntax to stop people talking
about Python's OO being bolted on etc. Programmers often choose their
languages by very silly reasoning (silliest being the indentation issue)
and maybe we should take the silliness into account instead of laughing
about those silly folks.

This kind of stuff can be tackled by providing better introductory,
educational or promotional material, with the latter especially
important to stop the uninformed "rubbishing" that advocates of certain
other languages seem particularly inclined to indulge in.

I for my part would be happy to see a Delphi-like RAD tool for Python,
a reference implementation for web programming as part of the standard
library, Jython 2.5, Python for PHP or whatever attracts new programmers.

As I noted in the "Python component model" thread [3], tools like Qt
Designer seem to go a long way towards providing RAD-like solutions,
even though they aren't "pure Python". Meanwhile, the Web programming
standardisation scene remains stagnant. Sure, you can pretend that WSGI
middleware is the future, and even I can see that layering components
is an acceptable way of building Web applications, but I'm not using
WSGI to do that because the whole exercise requires multiple trips to
the Web technology supermarket (once for a server, again for a server
adapter, again for stuff to make the WSGI API bearable, and so on,
repeat when you find one or more components to be immature) and I doubt
that people shopping around for an easy way to write applications are
especially convinced either.

But I largely agree with what you've written, and the cause of the
symptoms is the excessive focus on changing the language rather than
improving the libraries, the tools and the peripheral elements of the
development experience. If you think the standard library is
incoherent, jump into the proposal I've been writing [4] to suggest
improvements and to help out, because this kind of work isn't going to
happen otherwise, unfortunately. Returning to the lack of Python books,
it's rather telling that a review of "Python in a Nutshell" that just
caught my eye says the following:

"Considering that the Zen of Python is barely being followed as the
core language has feature upon feature heaped upon it, a book like this
helps poor programmers simply wanting to use the language keep up with
the changes."

I know that certain other languages aren't exactly unchanging (and may
possibly undergo further upheaval), and that publishers like having
more books to sell on the very same topic, but after a while both
authors and readers become tired of having to respectively write/update
or buy new books because of relentless and seemingly frivolous changes
to a language or technology.

Paul

[1] http://www.python.org/pypi/parallel
[2]
http://groups.google.com/group/comp....d8f8aa2cfb8562
[3]
http://groups.google.com/group/comp....78b500493a38f1
[4]
http://wiki.python.org/moin/CodingPr...tandardLibrary

[Fredrik Lundh]

Paul Boddie wrote:

Meanwhile, the Web programming standardisation scene remains
stagnant.

Aw, come on. The Python web programming standardisation wars are over, for now.
There's Django, and there's TurboGears, and there's Zope 2/3, all with slightly different
approaches, and slightly different target audiences. Unless you're doing really odd things,
one of these will be more than good enough for your application.

(as for WSGI, it's plumbing. You can of course build fun things from spare parts and
plumbing, and there are really interesting things going on in certain research labs, as usual,
but if you want turn-key stuff, pick one of the big three.)

</F>

[Paul Boddie]

Fredrik Lundh wrote:

Paul Boddie wrote:

Meanwhile, the Web programming standardisation scene remains
stagnant.

Aw, come on. The Python web programming standardisation wars are over, for now.

Well, that's just another way of saying that the scene remains
stagnant, because I don't see any winners.

There's Django, and there's TurboGears, and there's Zope 2/3, all with slightly different
approaches, and slightly different target audiences. Unless you're doing really odd things,
one of these will be more than good enough for your application.

I didn't deny that various frameworks would be good enough for various
things (indeed, I didn't even mention them), and I personally think
that Django seems like a decent enough solution, even though it (or its
documentation) focuses on ORM+RDBMS-based applications - a focus that
wouldn't suit a number of applications I've worked on.

The thing is that people want a coherent message about Python and Web
programming. It doesn't have to be "use only this and nothing else" but
it should help them make a good but quick decision. For a long time
people expected to get this coherent message by looking for solutions
provided with the Python distribution itself - after all, the standard
library has provided other useful "batteries" over the years - but all
we had was the cgi module and some barely maintained servers. Indeed,
the standard library looks pretty incoherent itself these days.

But there's a huge gap between what's on offer via the standard library
and the most popular full-stack frameworks, and the choice of starting
with WSGI middleware or swallowing Zope development whole, for example,
must be something of a demotivator for newcomers - why else do people
still ask CGI-related questions on comp.lang.python? What's interesting
is that one of the Django pioneers advocated better standards way back
in 2003 [1], possibly indicating a preference for the "rising tide
floats more boats" philosophy that would help Python itself become a
more popular tool for Web development, rather than some framework doing
a Zope and, in a few years, having its community members argue amongst
themselves about why Python developers don't like them any more. It'd
be interesting to hear whether the same attitude still holds sway after
Django's more recent success.

(as for WSGI, it's plumbing. You can of course build fun things from spare parts and
plumbing, and there are really interesting things going on in certain research labs, as
usual, but if you want turn-key stuff, pick one of the big three.)

After seeing WSGI being elevated to non-plumbing (since plumbing is
just stuff that helps other stuff to work, not something you mess with
on a daily basis), I think the current strategy with respect to
"floating more boats" is to pretend that WSGI is all you need. In which
case, we might as well start looking at documentation like this
instead...

http://www.erlang.org/doc/doc-5.5.1/...l/mod_esi.html

Paul

[1] http://mail.python.org/pipermail/web...er/000003.html

[Fredrik Lundh]

Paul Boddie wrote:

>Aw, come on. The Python web programming standardisation wars are over, for now.

Well, that's just another way of saying that the scene remains
stagnant, because I don't see any winners.

one, two, overflow ? or are you saying that the lack of a monopoly means
market stagnation, no matter how innovative the three big ones are ?

For a long time people expected to get this coherent message by looking for
solutions provided with the Python distribution itself - after all, the standard
library has provided other useful "batteries" over the years - but all
we had was the cgi module and some barely maintained servers. Indeed,
the standard library looks pretty incoherent itself these days.

the standard library has never included non-trivial applications (and the three big
ones are configurable applications, not libraries). I'm not sure anyone has ever
looked to the standard library for domain-specific applications or toolkits.

The thing is that people want a coherent message about Python and Web
programming.

the message is out there, for anyone who wants to listen. and they are listening.

why else do people still ask CGI-related questions on comp.lang.python?

because CGI works well for simple applications where you don't want to waste
any time whatsoever on hosting and deployment issues ? heck, I spent parts of
last weekend hacking on a light-weight CGI-based publishing system for portions
of the effbot.org site, using Python 2.2 on Solaris. loads of fun.

>(as for WSGI, it's plumbing. You can of course build fun things from spare parts and
plumbing, and there are really interesting things going on in certain research labs, as
usual, but if you want turn-key stuff, pick one of the big three.)

After seeing WSGI being elevated to non-plumbing (since plumbing is
just stuff that helps other stuff to work, not something you mess with
on a daily basis), I think the current strategy with respect to
"floating more boats" is to pretend that WSGI is all you need.

I've never seen anyone besides Ian Bicking make that argument (and he's using
WSGI plus a zillion ready-made building blocks when doing that).

</F>

[Paul Rubin]

"Fredrik Lundh" <fr*****@pythonware.comwrites:

one, two, overflow ? or are you saying that the lack of a monopoly means
market stagnation, no matter how innovative the three big ones are ?

It worked for Ruby on Rails...

[Paul Boddie]

Fredrik Lundh wrote:

Paul Boddie wrote:

Well, that's just another way of saying that the scene remains
stagnant, because I don't see any winners.

one, two, overflow ? or are you saying that the lack of a monopoly means
market stagnation, no matter how innovative the three big ones are ?

I've never maintained that a monopoly on how Web programming is done
would be a good thing. All I've ever tried to understand is why people
haven't tried to improve the generic support for Web programming (and a
whole load of other things) even to the level of something like the
DB-API. Take another area: all the time you get people asking how they
can conveniently access some Web site using a Python-based client, and
loads of people are coming up against issues with urllib, urllib2,
other libraries. Wouldn't it be good if the functionality were just
there in the standard library in a sane form? Or is the standard
library just a "grab bag" of demos these days?

[...]

the standard library has never included non-trivial applications (and the three big
ones are configurable applications, not libraries). I'm not sure anyone has ever
looked to the standard library for domain-specific applications or toolkits.

These non-trivial applications are just libraries with icing on. My
critique of the Web standardisation scene is that no-one is that
interested in cooperating on the libraries. Of course, that isn't a bad
thing if you choose your framework and find the facilities you need,
but when this is happening at such a low level in the "framework
stack", you needlessly fragment the scene. TurboGears and Django have
slightly different approaches, so if you're the sort of person who will
buy the shiny new TurboGears book (the one with the snake holding a
lightsabre, or something), you'll probably want to get the Django one
as well: great news for publishers, an own-goal for the common cause.

The thing is that people want a coherent message about Python and Web
programming.

the message is out there, for anyone who wants to listen. and they are listening.

And that message is...? All I see is the JPF, the PFJ and the JPPF.

why else do people still ask CGI-related questions on comp.lang.python?

because CGI works well for simple applications where you don't want to waste
any time whatsoever on hosting and deployment issues ? heck, I spent parts of
last weekend hacking on a light-weight CGI-based publishing system for portions
of the effbot.org site, using Python 2.2 on Solaris. loads of fun.

Quite. But I'd also suggest that people use the cgi module and
BaseHTTPServer because the former is a well-understood technology and
the latter is something you can read about in a couple of pages in the
library reference. Indeed, there are lots of BaseHTTPServer-related
projects out there, which is not particularly good news for deployment,
but then there's that big gap between the standard library and the
megaprojects that I mentioned.

(as for WSGI, it's plumbing. You can of course build fun things from spare parts and
plumbing, and there are really interesting things going on in certain research labs, as
usual, but if you want turn-key stuff, pick one of the big three.)

After seeing WSGI being elevated to non-plumbing (since plumbing is
just stuff that helps other stuff to work, not something you mess with
on a daily basis), I think the current strategy with respect to
"floating more boats" is to pretend that WSGI is all you need.

I've never seen anyone besides Ian Bicking make that argument (and he's using
WSGI plus a zillion ready-made building blocks when doing that).

You should read some of the articles linked to from wsgi.org, then.

Paul

[Kay Schluehr]

Paul Boddie wrote:

I've never maintained that a monopoly on how Web programming is done
would be a good thing. All I've ever tried to understand is why people
haven't tried to improve the generic support for Web programming (and a
whole load of other things) even to the level of something like the
DB-API. Take another area: all the time you get people asking how they
can conveniently access some Web site using a Python-based client, and
loads of people are coming up against issues with urllib, urllib2,
other libraries. Wouldn't it be good if the functionality were just
there in the standard library in a sane form? Or is the standard
library just a "grab bag" of demos these days?

Paul, I do think the focus on the stdlib as it is right now is a bit
misleading. The stdlib is basically the product of python-dev and the
runtime developers also have maintenance responsibility. This shall and
even must be splitted and shared as it is done successfully with
application domains like Scientific Python. If an enterprise grows no
one expects that one department is responsible for everything but here
in the Python community Guido shall play Fidel Castro who cares for
each module of each application developer ever written and its
suitability for the stdlib and its alignment with the Python ideology.
In my opinion Python shall grow up and organize the visibility of its
products, its "portfolio", differently with Py3K. I agree with Fredrik
that any decision towards a BDFL blessed webframework is premature and
Guido already showed himself not much interest in making any decision.
Even if all kinds of components are available in the stdlib people are
still looking for a RoR for Python and they do so not only for
technical reasons but because they need a brand that can be justifed
towards their team mates and project leaders.

Kay

[Paul Boddie]

Kay Schluehr wrote:

Paul Boddie wrote:

I've never maintained that a monopoly on how Web programming is done
would be a good thing. All I've ever tried to understand is why people
haven't tried to improve the generic support for Web programming (and a
whole load of other things) even to the level of something like the
DB-API. Take another area: all the time you get people asking how they
can conveniently access some Web site using a Python-based client, and
loads of people are coming up against issues with urllib, urllib2,
other libraries. Wouldn't it be good if the functionality were just
there in the standard library in a sane form? Or is the standard
library just a "grab bag" of demos these days?

Paul, I do think the focus on the stdlib as it is right now is a bit
misleading. The stdlib is basically the product of python-dev and the
runtime developers also have maintenance responsibility. This shall and
even must be splitted and shared as it is done successfully with
application domains like Scientific Python.

Quite. But we're talking about supposedly well-established and widely
understood technologies here: the cgi module first appeared in 1994
(1995 in the library); that relative newcomer the Cookie module
appeared in 2000; BaseHTTPServer appeared in 1995; asyncore was added
to the library in 1999. And unlike various scientific computing
interest groups, those who use Web technologies are so broadly
dispersed across all kinds of other domains that I doubt that even if
GvR told everyone to take their Web modules elsewhere, there'd be
enough cohesion to have such an umbrella WebPython distribution.

If an enterprise grows no
one expects that one department is responsible for everything but here
in the Python community Guido shall play Fidel Castro who cares for
each module of each application developer ever written and its
suitability for the stdlib and its alignment with the Python ideology.

Well, I don't want everyone's modules in the standard library, but I
think it makes sense for people to work on integrating modules into the
library that make it easier for them and others to then focus on other
stuff. What if the cgi, BaseHTTPServer and Cookie modules hadn't been
in the standard library? Whilst some people might regard the resulting
dearth of Web frameworks as a benefit, I think you'd see less activity
in that part of the community as a consequence.

In my opinion Python shall grow up and organize the visibility of its
products, its "portfolio", differently with Py3K. I agree with Fredrik
that any decision towards a BDFL blessed webframework is premature and
Guido already showed himself not much interest in making any decision.

But I don't want GvR to bless a framework. Consider his misunderstood
near-blessing of Django: it's almost nonsensical. Sure, Django
innovates somewhat in terms of describing the URL space, but there are
numerous people who don't like the templating or the ORM, so they
wonder if they just couldn't strip that stuff off and replace it, but
what are you left with? The bare platform, of course, which isn't worth
continually redeveloping for each megaframework, but that's what has
been happening over the last five years.

Even if all kinds of components are available in the stdlib people are
still looking for a RoR for Python and they do so not only for
technical reasons but because they need a brand that can be justifed
towards their team mates and project leaders.

True, and this is where a lot of the marketing Python discussion missed
the point, dwelling on the corporate acceptability of Python (ie. the
nod from the PHB) and ignoring the peer marketing effect (ie. some
colleague you get along with shows you something with a "cool" label
stuck to it). The Django and TurboGears projects have noticed this
phenomenon, in contrast to that other supposed "winner" of the
frameworks war (Zope), but I await the day when some other loudly
advocated technology emerges to expose Python's library weaknesses and
causes a similar reactive scramble amongst the interested parties of
that particular domain.

Paul

[Peter Maas]

Bruno Desthuilliers wrote:

Peter Maas wrote:

[...]

>a reference implementation for web programming as part of the standard
library,

wsgiref is part of the 2.5 stdlib.

Yes, but it's not an implementation. Think of something like Tomcat for
the Java Servlet Specification.

--
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')

[Peter Maas]

Paul Boddie wrote:

People who bring up stuff about self and indentation are just showing
their ignorance, in my opinion, since Python isn't the first language
to use self in such a way, and many C++ and Java programs use this
pervasively in order to make attribute scope explicit, whereas the
indentation matter is only troublesome with bad editing practices. I
don't think the community should spend any more time on these
criticisms.

How many programmers don't use Python because of the self issue?
I'm not for changing the semantics here but when I wrote a method with
lots of selfs recently I tried how it would look like if it would be
allowed not to write down 'self', i.e. from

def deposit(self, amount):
self.balance = self.balance + amount

to

def deposit( , amount):
.balance = .balance + amount

I see an advantage in not mentioning 'self': using shorter alternatives
like 'my' is possible but considered bad style. I find it unsatisfactory
to provide a degree of freedom and not wanting it to be used. Leaving
out 'self' is like leaving out block markers. You leave out something
that's a matter of taste (self, me, my, block marker positions) and
bring the code in minimal form. Explicit use of self could of course
still be allowed. And a favorite argument against Python would become
pointless.

However, the GIL and issues of tools and IDEs should be considered in a
more sophisticated way.

If I wouldn't read discussions about it I wouldn't probably know that it
exists. But as far as I have understood removing the GIL means a lot of
work and breaking existing code. Perhaps the GIL will die naturally with
the advent of a production ready PyPy. And the Twisted people keep telling
"Repeat with me: there are no threads" :)

Meanwhile, whilst not an IDE advocate myself, there really does need to
be further improvements in the analysis of Python source code so that
people can build improved tools to check Python programs for obvious
"compile-time" errors and to inspect the behaviour of large amounts of
code.

I agree.

One reads occasionally on the python-dev or python-3000 mailing

lists that some proposed change or other may or may not have an impact
on "real world" systems such as the standard library, but that no-one
can really say: we need to move beyond the "Python is just so dynamic"
meme and develop tools like PyLint and PyChecker much further.

I find it important that Python allows dynamic coding but I agree that it
should allow more compile time checks which would probably also help to
produce faster code.

This kind of stuff can be tackled by providing better introductory,
educational or promotional material, with the latter especially
important to stop the uninformed "rubbishing" that advocates of certain
other languages seem particularly inclined to indulge in.

I don't think so because advocates tend to use arguments just because they
are handy, not because they don't know better.

--
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')

[Ilias Lazaridis]

Peter Maas wrote:

Paul Boddie wrote:

People who bring up stuff about self and indentation are just showing
their ignorance, in my opinion, since Python isn't the first language
to use self in such a way, and many C++ and Java programs use this
pervasively in order to make attribute scope explicit, whereas the
indentation matter is only troublesome with bad editing practices. I
don't think the community should spend any more time on these
criticisms.

How many programmers don't use Python because of the self issue?
I'm not for changing the semantics here but when I wrote a method with
lots of selfs recently I tried how it would look like if it would be
allowed not to write down 'self', i.e. from

def deposit(self, amount):
self.balance = self.balance + amount

to

def deposit( , amount):
.balance = .balance + amount

would like this.

I finally liked pythons 'forced-indentation' thing, but 'self' is just
terrible.

def deposit(amount)
.balance = .balance + amount # a little thin this dot
@balance = @balance + amount # why not similar to ruby?

self = <do this and that# self remains available

but this will have most possibly major implications (design,
compatibility etc.)

possibly the simplest way would be to agree on 's' (typing is very
fast, faster than SHIFT-2 for @)

def deposit(s, amount)
s.balance = s.balance + amount

so, python 2.6 = introduces agreement on 's' ?

this will never happen, but everyone is of course free to use 's'
instead of 'self' immedeately.

There's no problem (except possibly the tiny annoyancy when reading
through libraries which use 'self').

..

--
http://lazaridis.com

[Peter Decker]

On 10/10/06, Peter Maas <pe********@utilog.dewrote:

I for my part would be happy to see a Delphi-like RAD tool for Python,
a reference implementation for web programming as part of the standard
library, Jython 2.5, Python for PHP or whatever attracts new programmers.

I think you should take a good look at Dabo and the visual tools they
are creating. While I would be the first one to admit that they are
not polished to the level of Delphi, they are pretty amazing for a
couple of guys working in their spare time! If we could get more of
the community to contribute to this project, I don't think that there
would be any other RAD tool that would come close.
--

# p.d.

[Ilias Lazaridis]

Peter Decker wrote:

On 10/10/06, Peter Maas <pe********@utilog.dewrote:

I for my part would be happy to see a Delphi-like RAD tool for Python,
a reference implementation for web programming as part of the standard
library, Jython 2.5, Python for PHP or whatever attracts new programmers.

I think you should take a good look at Dabo and the visual tools they
are creating. While I would be the first one to admit that they are
not polished to the level of Delphi, they are pretty amazing for a
couple of guys working in their spare time! If we could get more of
the community to contribute to this project, I don't think that there
would be any other RAD tool that would come close.
--

# p.d.

yes, an interesting tool.

But to get more attention and developers, the project needs to be
polished.

really unattractive resources:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

[Peter Decker]

On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

yes, an interesting tool.

But to get more attention and developers, the project needs to be
polished.

really unattractive resources:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

It really grinds my gears when people take something that involves
hundreds if not thousands of hours of time that is offered to them for
free, and then nitpicks on something completely tangential. If you
want a polished website, then offer to contribute one! Don't whine
about a couple of developers who are doing amazing things in their
spare time while you're contributing absolutely nothing to the
community.

--

# p.d.

[Ed Leafe]

On Oct 10, 2006, at 1:47 PM, fumanchu wrote:

>4) Custom property and component editors: A component editor can
present
a property editor or an editor for an entire component which the
visual
design-time RAD environment can use to allow the programmer end-
user of
the component to set or get component property values. Normally a
design
time environment will present default property editors for each
component property type, but a component can override this.

This is the hard part. I believe Dabo has done some work in this
space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.

FWIW, the Dabo design tools store the design in a basic XML file,
and are completely transparent to outside editing. There is nothing
that prevents you from modifying a design in the editor of your
choice; the Dabo visual editing tools simply give you WYSIWYG
feedback as you edit.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

[Ed Leafe]

On Oct 10, 2006, at 9:59 PM, Edward Diener No Spam wrote:

The Visual Studio RAD IDE environment actually modifies source code
constructors, via an InitializeComponent() function called from it, in
order to set properties and events in components. It does mark the
function as such with comments in the source code. OTOH Borland's VCL
uses the resource file technique you scorn above, linking in the code
via resources and automatically updating a component's properties and
events from base class components constructors. I believe Java's JVM
automatically deserializes .ser files at run-time saved by a RAD
designer in order to set properties and events on an object of a
class.

There are obviously numerous techniques, so one should theoretically
work well with Python.

With Dabo, we've taken what we feel is a 'best of breed' approach.
The constructors for the various objects are defined in XML-formatted
files, making them accessible by any editor. The code behind these
objects is stored in regular .py files, with special comment lines
that provide the linkage back to the original object definition. So
you can edit your code in your favorite Python editor, and it all
just works.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

[Robert Kern]

Peter Decker wrote:

On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

>yes, an interesting tool.

But to get more attention and developers, the project needs to be
polished.

really unattractive resources:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Ilias Lazaridis]

Peter Decker wrote:

On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

yes, an interesting tool.

But to get more attention and developers, the project needs to be
polished.

really unattractive resources:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

I've contributed already (my contructive criticism).

It's up to the team to react.

It really grinds my gears when people take something that involves
hundreds if not thousands of hours of time that is offered to them for
free, and then nitpicks on something completely tangential. If you

project infrastructure is not tangential.

It's essential

want a polished website, then offer to contribute one!

Terrible this open source folks.

One cannot say one word without beeing asked to contribute.

Don't whine
about a couple of developers who are doing amazing things in their

doing amazing things is not enouth to bring a language-community
forward (or to create a python component model, which is the topic of
this thread)

spare time while you're contributing absolutely nothing to the
community.

I share the infrastructure which I use:

http://dev.lazaridis.com/base

..

[Ilias Lazaridis]

Robert Kern wrote:

Peter Decker wrote:

On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

yes, an interesting tool.

But to get more attention and developers, the project needs to be
polished.

really unattractive resources:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.

Mr. Kern! Seeing you working on such a seemingly excellent product, I
am really wondering about your tenor.

can you please inform me (and the interested readers) about the
persistency mechanism within traits:

http://groups.google.com/group/comp....89ed163b978fe2

..

[Ben Finney]

"Ilias Lazaridis" <il***@lazaridis.comwrites:

Terrible this open source folks.
One cannot say one word without beeing asked to contribute.

+1 QOTW, in a new category for kooks.

--
\ "Say what you will about the Ten Commandments, you must always |
`\ come back to the pleasant fact that there are only ten of |
_o__) them." -- Henry L. Mencken |
Ben Finney

[Peter Decker]

On 11 Oct 2006 20:08:12 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

I've contributed already (my contructive criticism).

It's up to the team to react.

Wow! What a contribution! Amazing that Dabo hasn't taken over the
world with that sort of help pouring in!

Anybody can criticize. It's easy to find fault; it's much harder to
create something valuable.

I saw the references to your being a troll, and thought I'd give you
the benefit of the doubt. Guess I'm still too optimistic.

--

# p.d.

[Robert Kern]

Ilias Lazaridis wrote:

Robert Kern wrote:

>No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.

Mr. Kern! Seeing you working on such a seemingly excellent product, I
am really wondering about your tenor.

I am confident that it is accurately aimed. Furthermore, I am confident that the
record and the rest of this community will back me up on it. I've told you
before that this community will not tolerate your bad behavior. How many times
does this have to be demonstrated before you will leave?

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Ilias Lazaridis]

Robert Kern wrote:

Ilias Lazaridis wrote:

Robert Kern wrote:

No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.

Mr. Kern! Seeing you working on such a seemingly excellent product, I
am really wondering about your tenor.

I am confident that it is accurately aimed. Furthermore, I am confident that the
record and the rest of this community will back me up on it. I've told you
before that this community will not tolerate your bad behavior. How many times
does this have to be demonstrated before you will leave?

Please stay in-topic

"
can you please inform me (and the interested readers) about the
persistency mechanism within traits:

http://groups.google.com/group/comp....89ed163b978fe2
"

[Ilias Lazaridis]

Peter Decker wrote:

On 11 Oct 2006 20:08:12 -0700, Ilias Lazaridis <il***@lazaridis.comwrote:

Well, then, why not contribute? Or are you waiting for everyone else
to do it for you?

I've contributed already (my contructive criticism).

It's up to the team to react.

Wow! What a contribution! Amazing that Dabo hasn't taken over the
world with that sort of help pouring in!

Anybody can criticize. It's easy to find fault; it's much harder to
create something valuable.

[REQUOTE]
I share the infrastructure which I use:

http://dev.lazaridis.com/base
[/REQUOTE]

I saw the references to your being a troll, and thought I'd give you
the benefit of the doubt. Guess I'm still too optimistic.

No.

You're just ignoring given facts in a controlled manner.

Like many other people of this community.

And that's the main reason why python does not move forward in the
speed it could.

..

[Robert Kern]

Ilias Lazaridis wrote:

Robert Kern wrote:

>Ilias Lazaridis wrote:

>>Robert Kern wrote:
No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.
Mr. Kern! Seeing you working on such a seemingly excellent product, I
am really wondering about your tenor.

I am confident that it is accurately aimed. Furthermore, I am confident that the
record and the rest of this community will back me up on it. I've told you
before that this community will not tolerate your bad behavior. How many times
does this have to be demonstrated before you will leave?

Please stay in-topic

Asking disruptive individuals to leave is always on-topic. Now, please go away.

I will happily and pleasantly converse with anyone who has questions about
Traits or any of Enthought's other tools if they ask in good faith. I believe
that the record shows that you do not do so. Really, I'm quite nice and helpful
to other people.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Ilias Lazaridis]

Robert Kern wrote:

Ilias Lazaridis wrote:

Robert Kern wrote:

Ilias Lazaridis wrote:
Robert Kern wrote:
No, he's just a troll that enjoys telling everyone what to do. Don't try to get
him to contribute anything useful; it won't work.
Mr. Kern! Seeing you working on such a seemingly excellent product, I
am really wondering about your tenor.
I am confident that it is accurately aimed. Furthermore, I am confident that the
record and the rest of this community will back me up on it. I've told you
before that this community will not tolerate your bad behavior. How many times
does this have to be demonstrated before you will leave?

Please stay in-topic

Asking disruptive individuals to leave is always on-topic.

please realize: the only disruptive individual at this point is you.

Now, please go away.

of course I stay.

I will happily and pleasantly converse with anyone who has questions about
Traits or any of Enthought's other tools if they ask in good faith. I believe
that the record shows that you do not do so. Really, I'm quite nice and helpful
to other people.

Sorry to say, but your behaviour is very ungentle.

I've place a simple question. If you are really helpful to other
people, then pleas just answer.

Many other people follow this discussion, and many will see the
question within the archives... unsanswered.

"
looks interesting.

what about persistency?

http://groups.google.com/group/comp....89ed163b978fe2
"

As far as I can see, there's no persistency binding available.

Is one planned?

..

[Erik Max Francis]

Ilias Lazaridis wrote:

http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Who. Cares. What. You. Think?

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
Love is, above all, the gift of oneself.
-- Jean Anouilh

[Kay Schluehr]

Peter Maas wrote:

Paul Boddie wrote:

People who bring up stuff about self and indentation are just showing
their ignorance, in my opinion, since Python isn't the first language
to use self in such a way, and many C++ and Java programs use this
pervasively in order to make attribute scope explicit, whereas the
indentation matter is only troublesome with bad editing practices. I
don't think the community should spend any more time on these
criticisms.

How many programmers don't use Python because of the self issue?

The only reason I know why self shall not be inforced is reducing the
number of troll postings.

[Fredrik Lundh]

Erik Max Francis wrote:

>http://dabodev.com
http://case.lazaridis.com/wiki/DaboAudit

Who. Cares. What. You. Think?

his mom?

</F>

[Terry Reedy]

"Ilias Lazaridis" <il***@lazaridis.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

I share the infrastructure which I use:

http://dev.lazaridis.com/base

But not quite yet, it appears. "A public release is planned shortly"

[Peter Maas]

Kay Schluehr wrote:

Peter Maas wrote:

>How many programmers don't use Python because of the self issue?

The only reason I know why self shall not be inforced is reducing the
number of troll postings.

The only method that works to reduce the number of troll postings is:
spot them, then ignore them.

But some lengthy threads in c.l.p suggest that quite a few c.l.p
participants enjoy conversation with trolls or are slow at spotting :)

--
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')

[Peter Maas]

Peter Decker wrote:

I think you should take a good look at Dabo and the visual tools they
are creating.

Thanks for the hint, Peter. I've heard of Dabo and it's on my list of
things to be inspected. Perhaps my postings have been misunderstood. I don't
feel uneasy with Python. I'm using it since 4 years and know how to find
the tools I need. But I feel uneasy with an excessive readiness of some
c.l.p participants to accept Python as it is and even to react defiantly
on friendly suggestions how to make Python a more obvious choice for
newcomers. I think this is important for Python's survival.

--
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')

[Ed Jensen]

Paul Boddie <pa**@boddie.org.ukwrote:

People who bring up stuff about self and indentation are just showing
their ignorance

Ouch. That stings.

Python's "indentation determines scope" makes it hard for me to discuss
Python via mediums like IRC and instant messengers.

It also makes it hard to quickly jump to the top and/or bottom of
code blocks in most editors I use on a day to day basis.

I guess I'm just ignorant. :(

[Paul Boddie]

Ed Jensen wrote:

Paul Boddie <pa**@boddie.org.ukwrote:

People who bring up stuff about self and indentation are just showing
their ignorance

Ouch. That stings.

Python's "indentation determines scope" makes it hard for me to discuss
Python via mediums like IRC and instant messengers.

True, especially with the helpful first line indentation in some
messengers.

It also makes it hard to quickly jump to the top and/or bottom of
code blocks in most editors I use on a day to day basis.

I'm not at the cutting edge here: 20j and 20k are the commands (replace
20 with another suitable amount) which help me jump around in my editor
of choice. The other commands which may be more effective just aren't
in my "working set".

I guess I'm just ignorant. :(

Don't be too hard on yourself, Ed! I was really referring to people who
make a big advocacy issue out of self (eg. "Python isn't
object-oriented - it has self parameters!") and indentation (eg.
"Python's just like Fortran!"). You're just pointing out the issues
that regrettably make communication of Python programs difficult.

Paul

[Peter Wang]

Edward Diener wrote:

It looks as if traits is an attempt to create a "property" in the
component terminology which I originally specified. I will take a look
at it.

Traits is frighteningly similar to the requirements that you laid out
in your post (the example for Skip), including delegates! I would like
to point out, however, that traits is a *general* component framework
for python that facilitates implementing the observer pattern and a
higher level of introspection. It can be used to build applications
that have no visual interfaces at all, but wish to benefit from the
"reactive programming" style that componentized, event-based
programming encourages. (induces?)

Traits UI, which Robert only alluded to, is actually very much the sort
of RAD environment you have described. It builds upon the component
model, and uses introspection to automagically create nice widgets for
your model, but adds mechanisms for specifying controllers, customizing
behavior, and generically composing complicated forms from simpler
ones. There is even a visual "builder" tool for it called VET that
closely resembles Delphi/C++ Builder. (The VET itself is, of course,
written using Traits UI.)

Envisage, the plugin application framework, can use the traits
component models and the TraitsUI interfaces to roll out very dynamic
applications, whose underlying models are all live components that can
be scripted, twiddled with from an embedded Python shell, etc.

Already subscribed. Thanks !

Please contribute ideas or ask conceptual questions!

Oh, and disclaimer: I also work at enthought. :)
-peter