Re: [Prothon-user] Re: Random late night ramblings

It seems that my mails to prothon-user don't get through. At least they
are pending for hours (or are deleted silently by the maintainer ? ). I
post them here, please apologize...

1.-----------------------------------------------------------------

> Have to agree to this and some other mails:
> 
> 1. we should only have unicode strings of type 'str'. In python it is
> unclear if u'' means UCS2 or UCS4, we should avoid such
inconsistencies
> and make everything a str, and restrict it only over the encoding
> attribute. A general configuration object could set the default
encoding
> from within a user-defined prothon module. This avoids the header
field:
> 
> # -*- coding: utf-8 -*-
> 
> It should be possible to check for the current encoding of an object
> like it is with type information.

I think there should be two ways of checking for the encoding:

1. if encoding(string) is ascii
2. if string.encoding(ascii)

Dennis
2.-------------------------------------------------------------

The tab/space-problem is mainly a problem related to old-fashioned
products like emacs, vi or pine. some of them solve the problem by
configuration. The rest is just dumb and shouldn't be considered as a
high priority problem.

The web understands tabs, only the web-developers don't know about that.
HTML knows indention, CSS does, and unicode does too. Let your
web-developers know about that instead of producing strange languages to
support bad habbits.

Dennis

3.-------------------------------------------------------------------

You're right, I meant the physical dimension. I just wanted to not
restrict the discussion on timeouts or locks. Counters and steppers
and event driven, switched, counters and so on are useful too. The
object must keep track of the state and provide it for free access and
manipulation by other objects (like event objects).

I specifically have a problem with locking because often I'd like to use
the opposite: running as long as not x happened. There exists a
condition object but it only works with threading support (happy to hear
that prothon pushes this deeper into the core), and the notifying forces
every waiting thread to have a look at possibly not wished information.
This is redundant. A more finegrained model would integrate a more
configurable event handler. I'd say that threading, event handling and
timing should be merged into one philosophy/metaphor/model/as you like
it.

I mentioned the select call as another example. It can block with
timeout, but only on established connections. The process of
establishing the connection is not in focus. The recv and send calls
need extra timing (a while loop, for example) because they are not in
focus of the select call too. So it goes on. The message of all this is
really simple: threading, event handling and timimg/timout/locking
methods are just too restricted and only available in specific
cases/situations.

Think of a function calling another function to establish a connection
and wait for the handshake. It could configure the function call to
break after 15 seconds or so. The called function itself could have an
attribute for timing its lifecycle:

def handshake(x,y):
        .closeAfter(1000)

(Is this correct prothon syntax, I still didn't do much with prothon, I
admit)

This would be fine for every object. Think of a while loop or a
generator with locking/event/timout functionality:

while 1 for 1000sec:
        pass

for n in 1000:
        pass
else myLock: wait(myLock.False)
else myEvent: break
else: raise myError

The wait object should start the for-loop at the same position where the
loop was locked.

Generators that keep state in memory could be restarted at same
position:

for n in x:
        .continue(mySecondEvent.True)
        pass
else myEvent.True: break

This would imply that the x object must be cloned to not be manipulated
in the meantime. Concurring signals must be filtered. In this case,
mySecondEvent is only relevant if the for-loop was halted. Another, more
clean, way is using the same event:

for n in x:
        .continue(myEvent.False)
        pass
else myEvent.True: break


You get it? Maybe my prothon is too sluggish :)

Having such a pool of possibilities, threading can be a fun (and a
compley beast either;).