Python IRC dictatorship

Timothy Rue threeseas at earthlink.net
Sat Nov 23 16:28:11 EST 2002


On 23-Nov-02 11:11:30 John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:
>>>>>> "Timothy" == Timothy Rue <threeseas at earthlink.net> writes:

>    Timothy> they exist here too.

>They are everywhere <wink>

>    Timothy> so what the fuck don't you understand about a named
>    Timothy> container that can hold changable information? Like a
>    Timothy> variable or a file.

>If you say named container, to a python coder, they will think list,
>tuple, dict and maybe string.  They definitely would not initially
>think about a 'variable or file'.

>"variables" in python are a little different than in other programming
>languages.  python has "names" for objects.  This example illustrates
>one of the initially surprising ways names work

[snip - see thread]

John, thank you for your effort to describe some of the differences.
Correction to your example, by another, noted.

In summary what you are saying is that there is a tower of babel between
not only client and coder but between languages as well. The result of
this is that anyone in the position of a client really needs to learn the
details of whatever specific language, including any other specifics of
the use of a language, such as platform dependant issues, before they
consider hiring a coder to produce, what the client designs. Otherwise how
the hell is the client to communicate to the coder what the fuck they
want?

This to me is a clear indication of what can only be described as a
serious failure of the software industry to properly take into
consideration client perspective and client communication vocabulary and
dictionary set. It further opens the door up for deception of the coders
side, as they can always play vocabulary trip up games to drag things out
and cost up.

Currently the only notable effort there is to improve this failing is the
ECMA-335 document on Common Language Infrastructure done unfortunately by
Microsoft, as they are criminal regardless of getting off the hook. It is
however a task anyone could have done, as it is more a matter of man hours
rather than genius, to collect it all up, sort it all out and then
integrate it into a non-conflicting manner.

What the CLI is, is a sum total of programming concepts and datatypes,
integrated in a non-conflicting manner. This of course having it's own
Common Intermediate Language.... and run time engine.

With this why would anyone continue to need language specific complexity,
not to mention other dependant issues, when all they really need to do is
speak concepts and datatypes to a translator that generates bytecode?

But the problem is that we are no there yet and Microsoft has every
intention of using such "common" to corner the next step or stage of
software industry development.... autocoding.

Now if I have a choice to go and use MS coders using CLI to speak with me
in, that I can use that as a vocabulary set of concepts to communicate
what I want.... or play the tower of babeling BS and drain of my bank
account due it... which way do you think I or anyone being given that
choice, would go?

The real problem is the tower of babel. OBVIOUSLY!

I believe you understand that.Unfortunately there are those who also
understand that but use it dishonestly.


The apex of the problem I seek a solution to is one of providing sharable
resources of the type known in the language of shell speak.... Variables.

Variable_name ; tag ; value
variable_name ; tag ; value
etc...


placed in a file, so that the resource is available to any number of
possible read and write accesses, as well as stored for later use, even
after the system is turned off. Not to mention being in a directly human
readable and editable format (i.e. the above)

All is fine untill you have concurrent accesses that include at least one
write. Unfortunately in python there is no platform independant way to
apply locks and unlocks.

There are a number of ways to handle the data, dictionary, dbm, Shelves,
pickle, etc..

But these still don't handle the concurrent access problem in a platform
independant manner.

Now it is possible that concurrent access problems would be rare, and
there is a way to intentionall force sequence of accesses when it is known
in advance but I hate lose strings that when pulled causes alot to come
undone.

Interesting enough the Hurd servers comes to mind, as in a custom
filehandeling server that handles concurrent accesses to prevent such
problems. But the Hurd is a platform yet to have a production release, and
such a solution is dependant upon the platform being used and such a
custom filehandler being written.

any suggestions?

---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
   *~ ~ ~      Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue      What's *DONE* in all we do?  *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:timrue at mindspring.com      >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/  ^<--------<----9----<--------<




More information about the Python-list mailing list