Re: Python for WEB-page !?

[Eric S. Johansson]

On 1/5/2017 7:48 PM, Michael Torrie wrote:
> While Python can do that, using a web framework to process HTTP requests
> and generate HTML to display in the browser, I don't believe Python is
> the appropriate language for the task at hand.  Most web sites that do
> interactive formula calculations like you describe do it all in the
> browser using Javascript.  No need to have a web server do all that
> heavy lifting at all.  A simple html file would contain everything you need.
>
> Even if you want to use Python to generate the web page and process
> events, you'll still have to master Javascript at some point to make the
> webpages more interactive.

There are a few implementations of Python that generate code that can
run the browser. I'm currently using brython and its significantly
easier than struggling with JavaScript. It's not perfect by any means,
it has its own quirks and bugs but the developer is very responsive, the
product is getting better every month and I like to see the Python
community give it a bit more love

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: JavaScrypthon 0.5, now with embedded evaluation of transpiled code

[Eric S. Johansson]

On 11/28/2016 2:02 PM, Amirouche Boubekki wrote:
> Also, FWIW users are looking for a Javascript replacement that is real
> Python, not another coffeescript.
does this count? http://brython.info/

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Promoting your own library

[Eric S. Johansson]

On 11/11/2016 6:59 PM, Ben Finney wrote:
> mirko bonasorte  writes:
>
>> what is the most appropriate way for a developer to promote his own
>> Python library?
> The general answer is: Publish it with full metadata on PyPI. That's
> where the Python community looks to find third-party modules, so that's
> the place to put it.
>
> Beyond that? You'll need to know whom you want to promote *to*. Find out
> where they get their information, and participate respectfully in those
> forums.
>
I could also use some of this information. I want to publish a couple of
things that I found useful. My creations tend to be single file modules
or commands and what I hope to understand from your guidance is how to
bundle that single file module or standalone program for publication.

--- eric



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Eric S. Johansson]

On 11/2/2016 2:40 PM, Chris Warrick wrote:
> Because, as the old saying goes, any sufficiently complicated Bottle
> or Flask app contains an ad hoc, informally-specified, bug-ridden,
> slow implementation of half of Django. (In the form of various plugins
> to do databases, accounts, admin panels etc.)

That's not a special attribute of bottle, flask or Django. Ad hoc,
informally specified, bug ridden slow implementations abound.  We focus
too much on scaling up and not enough on scaling down. We (designers) 
also have not properly addressed configuration complexity issues.

If I'm going do something once, if it cost me more than a couple of
hours to figure it out, it's too expensive in general but definitely if
I forget what I learned. That's why bottle/flask systems meet and need.
They're not too expensive to forget what you learned.

Django makes the cost of forgetting extremely expensive. I think of
using Django as career  rather than a toolbox.

So this brings me back to my question. What is missing in
SimpleHTTPServer to keep it from being secure enough?


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Eric S. Johansson]

On 11/2/2016 12:15 PM, Chris Warrick wrote:
> SimpleHTTPServer is meant to be used for development and testing. It
> should not be used for anything remotely serious for security and
> speed reasons. 

Given that many people are trying to use SimpleHTTPServer for
"production" should teach us that the existing http servers are overly
complex or at the least, not meeting needs when folks are scaling down
services.  for example, I've written any number of "small" webapps with
a user base of 5-10. do I need apache+cgi/uwsgi+bottle? no.  I need
something like SimpleHTTPServer only more production ready.

serious Q: what would it take to make SimpleHTTPServer more secure.  It
is currently fast enough.  when I run bottle with it's derivative of 
SimpleHTTPServer, it is as fast as apache+uwsgi+bottle for 1-10 users
and much much easier to set up.

> Instead, you should use a real web server, such as nginx or apache.
> Those will do the first two properly, and the last one could be
> handled by a simple-ish PHP script. Or a full-fledged app in Django or
> Flask if you feel like it.
or bottle.  why does everyone seem to forget bottle? simple to set up,
easy to learn and useful for small to medium projects. 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Inconsistencies

[Eric S. Johansson]

On 9/11/2016 10:26 PM, Chris Angelico wrote:
> No, God isn't part of the universe, any more than an author is part of
> his novel.
>
as any fiction writer will tell you, the author is found in one or more
of their characters.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is duck-typing misnamed?

[Eric S. Johansson]

On 8/27/2016 7:28 PM, ROGER GRAYDON CHRISTMAN wrote:
> Your response is appreciated.   I just thought I'd comment a little more on 
> the
> script:
>
> Woman:  I'm not a witch! I'm not a witch!
>
> V:  ehh... but you are dressed like one.
>
> W:  They dressed me up like this!
>
> All: naah  no we didn't... no.
>
> W:  And this isn't my nose, it's a false one.
>
> (V lifts up carrot)
>
> V: Well?
>
> P1:  Well we did do the nose
>
> V: The nose?
>
> P1:  ...And the hat, but she is a witch!
>
>
> They took a woman who originally, I think we might agree, was not a witch,
> and they added features that were understood to be part of the protocol
> for witchiness.

not a witch??

https://www.youtube.com/watch?v=zrzMhU_4m-g

start at 3:30

listen to what she says after they discover she weights as much as a duck.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Windows with linux environment

[Eric S. Johansson]

On 6/3/2016 12:02 AM, Muhammad Ali wrote:
> On Friday, June 3, 2016 at 6:27:50 AM UTC+8, Eric S. Johansson wrote:
>> On 6/2/2016 2:03 PM, Joel Goldstick wrote:
>>> Although the OP is using Windows 7, according to recent articles,
>>> Ubuntu is teaming with MS for Windows 10 to include a bash shell,
>>> presumably with the package management of Ubuntu (debian), with pip
>>> goodness and virtualenv and virtualenvwrapper.  That route should make
>>> W10 and linux (ubuntu) nearly identical environments to deal with
>> had forgotten about that.  it should be released end of july and I am
>> looking forward to the update! in the meantime, I'm suffering with
>> cygwin :-)
>
> Please send me the link through which I can get regular updates about this 
> new release.

switch to windows 10 and wait.  MS will cram an update into your machine :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Windows with linux environment

[Eric S. Johansson]

On 6/2/2016 2:03 PM, Joel Goldstick wrote:
> Although the OP is using Windows 7, according to recent articles,
> Ubuntu is teaming with MS for Windows 10 to include a bash shell,
> presumably with the package management of Ubuntu (debian), with pip
> goodness and virtualenv and virtualenvwrapper.  That route should make
> W10 and linux (ubuntu) nearly identical environments to deal with

had forgotten about that.  it should be released end of july and I am
looking forward to the update! in the meantime, I'm suffering with
cygwin :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Windows with linux environment

[Eric S. Johansson]

On 6/2/2016 12:38 PM, Wildman via Python-list wrote:
> On Thu, 02 Jun 2016 04:22:45 -0700, Muhammad Ali wrote:
>
>> Hi,
>>
>> I use windows regularly, however, I use linux for only my research work at 
>> supercomputer. In my research field (materials science) most of the scripts 
>> are being written in python with linux based system. Could I installed such 
>> linux based python on my window 7? So that I can use those linux based 
>> scripts written in python and I can also write my own scripts/code without 
>> entirely changing my operating system from windows to linux.
>>
>> Looking for your valuable suggestions.
>>
>> Thank you.
> There is coLinux and andLinux.

those are both mostly dead (it seems).  I went the cygwin route.  still
sucks but a bit less than straight windows.

-- 
https://mail.python.org/mailman/listinfo/python-list

Best practices for single file modules Inspired by: Best Practices for Internal Package Structure

[Eric S. Johansson]

I was inspired by the thread on packaging practices discussion with 
bidict to ask a related question which is what are the best practices 
with packaging/releasing a single file Python module ?


Back story: I'm always creating little bits of useful code that I want 
to reuse (for example, recursive expansion template module). It seems 
like the overhead of setting up a module is a bit high for a single file 
module but maybe this modern nation I'm not aware of or template based 
techniques that would lower the setup overhead.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python (or Haskell) makes you a worse programmer

[Eric S. Johansson]

On 3/30/2016 9:09 AM, Chris Angelico wrote:

On Thu, Mar 31, 2016 at 12:06 AM, Eric S. Johansson <e...@harvee.org> wrote:

I need a co-conspirator with better hands than mine to get through the next
stage which is some form of an AST smart editor that operates on larger
chunks such as idioms or snippets in a speech friendly way. Ideally I'd like
to see a bidirectional transform between the spoken form and a code form so
that you can edit the spoken form and regenerate the code.

Sounds to me like what you want is a variant language, a
speech-friendly programming language that compiles to Python. You
effectively store the spoken version, and translate it (one way) to
Python for execution.


That would be ideal but the problem comes with working with the team. I 
can't expect the other members the team to learn the system. I need to 
be able to work according to the teams rules (coding style etc.) for 
proper integration into an effort. Maybe I should be looking at machine 
learning for identifying patterns in the code and translation back to a 
spoken form.


It be interesting to see what people could come up with though for a 
speech friendly Python model. I've been wrestling with the problem so 
long, I probably have tons of blind spots.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python (or Haskell) makes you a worse programmer

[Eric S. Johansson]

On 3/30/2016 6:21 AM, BartC wrote:

On 30/03/2016 11:07, Sven R. Kunze wrote:

On 30.03.2016 01:29, Eric S. Johansson wrote:



On 3/29/2016 6:05 AM, Sven R. Kunze wrote:


Python = English


As someone who writes English text and code using speech recognition,
I can assure you that Python is not English. :-)


:D Interesting. Never thought of how Python sounds when spoken.


Among other things, it becomes case insensitive...


Which makes complying with Pep 8 quite the bitch. Fortunately, I have a 
workaround (togglename) which lets me dictate what I need to say and 
preserve the spoken to code for mapping for later translation. (I.e. 
this thing is that thing mapping).


I need a co-conspirator with better hands than mine to get through the 
next stage which is some form of an AST smart editor that operates on 
larger chunks such as idioms or snippets in a speech friendly way. 
Ideally I'd like to see a bidirectional transform between the spoken 
form and a code form so that you can edit the spoken form and regenerate 
the code.


Just one example of what I am thinking of is when you say the string 
name of a previously defined class instance, you get a dialogue of all 
available methods and string names. When you are at the point of 
speaking the argument list, it gives you an abstract form of the 
argument list that is filled in with a minimal set of speech commands. 
I'm too lazy to create the full description right now what if anybody 
wants to know more, ask and I'll fill in the blanks.


It's important to remember though that using simple or accelerated 
methods for creating code is the easy part of the problem. It's editing 
existing code that is hard because you've lost a lot of the information 
necessary for speech user interface. This is where I think an AST based 
editor will come in quite handy. So far, I haven't found any.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python (or Haskell) makes you a worse programmer

[Eric S. Johansson]

On 3/29/2016 6:05 AM, Sven R. Kunze wrote:


Python = English

As someone who writes English text and code using speech recognition, I 
can assure you that Python is not English. :-)

--
https://mail.python.org/mailman/listinfo/python-list

Re: need help with an accessibility prototype

[Eric S. Johansson]

On 05/22/2015 03:50 PM, Laura Creighton wrote:

In a message of Fri, 22 May 2015 12:29:20 -0400, Eric S. Johansson writes:

2 needs.  first is determining if NaturallySpeaking injects keycodes or
ascii char into the windows input queue.  second is building a test
widget to capture and display text.

I think I can solve both of these by building a simple text widget
(tkinter? qt? ??) to capture keycodes.  problem, is in mumblemumble
yrs of programming, I've never written a GUI interface so I have no idea
where to start.  help, tutor, pointers to samples would be most welcome.

--- eric

The best online manual I know of for Tkinter is here:
http://effbot.org/tkinterbook/ despite being 10 years old.  But then I
haven't looked for one for about that long, either.

For tkinter key events are a  bit odd, given that Tkinter tries to
help you and considers special keys, punctuation and non-ascii printing
characters as separate things should you want to bind to them.

It's actually easier to write the code and say 'play with this' rather
than to explain when you would need to use event.char and when event.keysym
(Plus the code will tell you what Tkinter uses, I might remember wrong.)

Save this in a file and run it.


Wow. What a gift. It told me what I needed to know which is the key syms 
are generated in a way that makes sense to me as far as I understand them.


A bit of background. I have some Linux resident code that translates 
standard input characters into key codes and then feeds them into 
uinput.   the problem is, the character sequences generated by 
NaturallySpeaking plus Windows doesn't always work right or as expected. 
In theory, I should now be able to push the individual events over to 
the Linux side  as key sym/ key codes, maybe do some translation, and 
ta-da,  I  now can dictate from the Windows virtual machine into Linux.


I now have, within reach, a fair amount of accessibility added by simple 
open-loop keystroke macros. The RPC mechanism tied into the Python 
extension to NaturallySpeaking, it's possible to execute even more 
sophisticated speech user interfaces.


thank you so much for the help.  future trick will be synchronizing 
tkinter window on windows with one on linux


--- eric
--
https://mail.python.org/mailman/listinfo/python-list

need help with an accessibility prototype

[Eric S. Johansson]

2 needs.  first is determining if NaturallySpeaking injects keycodes or 
ascii char into the windows input queue.  second is building a test 
widget to capture and display text.


I think I can solve both of these by building a simple text widget 
(tkinter? qt? ??) to capture keycodes.  problem, is in mumblemumble 
yrs of programming, I've never written a GUI interface so I have no idea 
where to start.  help, tutor, pointers to samples would be most welcome.


--- eric
--
https://mail.python.org/mailman/listinfo/python-list

Re: 'Lite' Databases (Re: sqlite3 and dates)

[Eric S. Johansson]

On 02/21/2015 01:22 AM, Ned Deily wrote:
SQLite is one of the most widely-used, best-documented, best-tested, 
and well-respected software packages in the world. 
yes but is still sql.  there are a couple of small scale not-sql 
databases that look interesting.  problem with them is that the creator 
seem to subscribe to the build-and-toss-into-the-wild school of development.


http://buzhug.sourceforge.net/
http://www.pydblite.net/en/index.html

both are useful, both could use multi-writer support, and both need some 
love from the python world.


--- eric
--
https://mail.python.org/mailman/listinfo/python-list

Re: Accessible tools

[Eric S. Johansson]

On 2/19/2015 10:33 AM, Bryan Duarte wrote:

Thank you jwi, and Jacob,

I took a look at that posting and it seems pretty unique. I am not much 
interested in the speech driven development, but I am very interested in 
developing an accessible IDE.


Well you should be because it looks like an aural interface (uses speech 
instead of keyboards) uses the same kinds of data to present to either a 
text to speech or speech recognition driven environment.

A professor and I have been throwing around the idea of developing a completely 
text based IDE. There are a lot of reasons this could be beneficial to a blind 
developer and maybe even some sighted developers who are comfortable in the 
terminal. The idea would be really just to provide a way of easily navigating 
blocks of code using some kind of tabular formatting, and being able to 
collapse blocks of code and hearing from a high level information about the 
code within. All tools and features would obviously be spoken or output in some 
kind of audio manor.
I've been working with another professor working on some of these issues 
as well. His focus has been mostly blind young adults in India.  come up 
with some pretty cool concepts that looks very usable. The challenge now 
is to make them work and, quite frankly monetize the effort to pay for 
the development.


Again, this shows the similarities in functionality used by both speech 
recognition and text-to-speech. All I care about is text and what I can 
say. We're now working with constructs such as with-open, argument by 
number, plaintext symbol names (with bidirectional transform to and from 
code form), guided construct generation for things like classes, 
methods, comprehensions etc.


All of these things would be useful to handed programmers as well as a 
way of accelerating co-creation and editing. Unfortunately, like with 
disabled people stove piping text-to-speech versus speech recognition, 
handed developers stovepipe keyboard interfaces and don't really think 
about what they are trying to do, only how they are doing it.


Yes yes, it's a broadbrush that you can probably slap me with. :-)


Oh and before I forget does anyone know how to contact Eric who was developing 
that accessible speech driven IDE? Thanks


Well, you could try looking in a mirror and speaking my name three times 
at midnight But you would get better results if you used my non-mailing 
list email address. e...@eggo.org.


--- eric
--
https://mail.python.org/mailman/listinfo/python-list

Re: need some guidance on Python syntax smart editor for use with speech recognition

[Eric S. Johansson]

On 1/5/2015 3:12 AM, Chris Angelico wrote:

On Mon, Jan 5, 2015 at 6:43 PM, Eric S. Johansson e...@harvee.org wrote:

The obvious answer is saving that meta-information in conjunction with the
code but when working in a team environment, that information is going to
drive you handies up the wall because it's going to visually overwhelm the
actual code. Serving the meta-information separately will mean it's even
harder to recover a speech friendly version of the code after it's been
touched.


This, I think, is going to be your hardest problem to solve. Once
someone edits your code using a conventional set of tools, any saved
meta-information will be out of date, and that's a critical failure;
ergo you can't save anything, and have to deduce it all from the code.


Exactly. That's one of the reasons why I was heading down the path of 
embedded meta-metadata. It might be acceptable if I could devise rules 
for hiding the metadata but even with that, the reversal is still a bit 
of a challenge..

So your only option, as I see it, is to devise some kind of 100%
reversible transliteration format.
With the right metadata, you have that reversibility. I think what makes 
it easier and harder is that when you write code using speech, you tend 
to use idioms (a.k.a. templates). My gut sense tells me that I should be 
able to recognize the structure of an idiom for going back from the code 
form to the speakable form. the metadata should help this process.


In the example I gave of class, the actual template generating code has 
a bunch of conditionals to add or delete subcomponents of the template. 
the template tool I use is something I developed myself which is a 
speakable template form, can do recursive expansion but has no 
conditionals in it (doing so reduces speak ability).


I think a form of pattern matching or shape recognition would be core to 
creating the code to speakable form translation but I'm feeling a bit 
stumped because I don't know where to find how other people have solved 
this kind of problem.


I should clarify that by shape recognition, I don't mean a geometric or 
image-based shape. it's more of an abstraction I used in my own mental 
models of how code is constructed.  for what it's worth, what I just 
described is one of the things that makes programming by speech so 
difficult. We all have different mental models of how code works. I see 
code in three dimensions  varying in time. I know not everybody does. :-)


One of the side effects of this visualization of code is that it lets me 
identify potential idioms. Some idioms are task transient, others are 
more general. If there's some way to recognize the pattern of code that 
is in an idiom and be able to preserve the variations within the idiom 
then I think we are on the right path.




Interestingly, this is sometimes needed between human languages.
Romanization of (say) Korean text involves representing the sounds of
the syllables in some kind of Latin script. If those transliterations
are perfectly reversible, you can manipulate the Korean text using a
US-English keyboard [1], while still producing correct Korean output.

It ought, in theory at least, to be possible to craft a reversible
transliteration between Python code and a more efficient speakable
form. You might have to place some restrictions on the Python code
(for instance, strict formatting rules, to avoid having spurious edits
when you use speech mode), and maybe you'd need a fall-back spoken
form that spells out the exact code, in case someone's done something
weird. But this would be something where you'd be better able to judge
than I am.


it'll never be 100% speech driven. There will always be a time when you 
have to use your hands. The goal is to minimize that time.


I should also point out that going from A - B - A' is not going to 
result in A = A' at least not at a character for character level.  
however, given a set of inputs, you will get identical results on 
outputs when using A and A'.  Yes, this will make differences in 
revision control hard to track unless the check in process performs a A 
- B - A' transformation and only checks in A'


So maybe now the question has changed to how does one specify an idiom 
such that one can extract the arguments defining that idiom instance 
from existing source code.


--- eric

--
https://mail.python.org/mailman/listinfo/python-list

Re: need some guidance on Python syntax smart editor for use with speech recognition

[Eric S. Johansson]

On 1/5/2015 7:24 AM, Chris Angelico wrote:

On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki jo...@wielicki.name wrote:

As a first iteration, I would try with any editor written in Python.
Are you familiar with the ast[1] module? It could be worth trying to
use this module and perform some kind of pattern matching on the
results to recover the information.

An AST parse throws away a lot of information. You can't easily
reconstruct the original code from that; at best, you can decompile
the AST back into functionally-equivalent source code, but it's not
something you want to do as part of editing code.


Chris is right. I looked at this and came up with the same conclusion. 
Here's a use case that I haven't talked about yet but is part of the 
problem of speech driven programming. I have a chunk of code that I 
created that is exactly right but it's in the wrong place or wrong 
method or even just the wrong environment. I need to capture it and then 
move it to the right place.


At first glance, this would look like a simple cut-and-paste and, 
sometimes it is but more often it's not. Let's take the example of a 
simple file generator. Opening the file, iterating over the input until 
the input data transformation process runs out of data.


This is a real common pattern and what changes are certain elements of 
the code, variables, strings whatever but also the indentation. So 
putting the old chunk of code into the new place requires transformation 
that most of you guys do by hand without thinking twice. Me it's, 
#()@!#$, and I use a whole bunch of kill words to strip out the old 
data and put in the new.


Imagine being able to rip out a piece of code, identify the substitution 
points and the indentation adjustment levels and then being able to put 
in that piece of code in other places and just fill in the blanks as a 
part of the insertion dialogue.  Now this gets us to the same point I 
was first talking about which is the ability to identify the idiom and 
code to operate on it as an idiom. some of the stuff I've seen with 
snippets is partly there, again it is a one-way transform.


It seems to me that those of us with hands and those of us with broken 
hands could use this same functionality given the right supportive user 
interface.


Now I've been living with this kind of idea for a while and I realize 
that may not make sense in this abstract written description. What do I 
need to fill in?



However, back when I was doing my PEP 463 research, someone suggested
looking into the 2to3 parser. I regretfully admit that I have yet to
actually do so, but it ought in theory allow source-level
transformations with a measure of intelligence. It's not a ready-made
solution by any means, but it could be a useful tool. [2]


Good idea.

Hope this helps. I find that topic pretty interesting. Is there
anything I can follow to see progress on this?

Likewise!

ChrisA


Is there any problem with keeping the conversation going here or would 
you prefer some other way of talking about it? I've been hesitant to put 
my work up on github because it's flailing about with also the bloody 
loose ends because I'm trying to solve up number of problems all at the 
same time.   The problem first being a framework where I can add speech 
driven UI elements to an editor so I can start experimenting with a 
bunch of these pieces.


Another way you can help is be my hands. sometimes I just run out of 
hand time and it takes a while for me build up enough energy so I can 
spend the day working for money and a day working on this.


--- eric

--
https://mail.python.org/mailman/listinfo/python-list

need some guidance on Python syntax smart editor for use with speech recognition

[Eric S. Johansson]

Some of you will recognize me as someone who pops up occasionally asking 
questions as I grope my way to a usable speech driven programming 
environment. My last set of experiments with a technique called 
togglename and speech driven template notation hit a pretty nasty wall 
of usability because of a fundamental incompatibility between GUIs and 
speech recognition and the lack of support Nuance gives to disabled 
users in general.


Before anybody suggests it, yes I know about that guy who gave a talk at 
a python convention and uses what we call the burp, belch, and fart 
school of speech recognition engine abuse. yes that is actually an 
affectionate description. :-) what he did is impressive but it's not 
where I'm going


I think the techniques I was experimenting with are good ones because 
they do make it easier to speak code. the problem comes about because of 
the irreversibility of the transformation making editing code as 
difficult as it was before.


A little background. Today, Python is an amazingly speech recognition 
friendly programming language (especially if you ignore pep-8). Using 
simple macros, you can pretty much noodle along and write code 
relatively easily. A few more specialized pieces and it's almost easy to 
rip, shred, and tear code into new shapes as you realize you went down 
the wrong path but still have lots of good idioms.


However, as easy as it is to noodle along, creating code I find myself 
somewhere around 0.8 as effective as I was with my hands and in editing 
code, I'm around 0.5 or less. My goal is to make speech driven 
programming at least on a parity with someone who has useful hands and 
hopefully 3 to 5 times faster.


a few years ago, a disabled friend of mine pointed out that the hard 
problem was not the creation of code but the editing of code. I took his 
observations to heart and have been working on trying to create a speech 
friendly environment that that can transform from the speech notation to 
the code notation and back again and still remain functionally 
identical. I have some ideas but I need some outside perspective from 
people who know Python better than I do.


The core of the idea is an editor which can present code in two forms. 
The first form is what you guys all know in love but is horrible to 
speak. The second form is something that is easy to speak, and as I said 
above, functionally identical to the code form. An ideal solution would 
give me the ability to toggle back and forth between these two 
representations. An experiment would be to play with is displaying both 
representations at the same time so you can see what you speak in near 
real-time.


The speech environment lends itself to speaking the broad intent and 
then answering questions to fill in the detail to create something 
concrete. For example, in one of my prototypes (shown below), I state 
that I want a class. Then I fill a detail like an initialization 
function, inheriting from a parent, copying in all the arguments etc. 
and I end up with a full class definition much more quickly than I could 
even type it with good hands. This is what I meant above by 3 to 5 times 
faster than hand generated code.


But with every experimental success, there is usually more than one 
problem. In this case is that I lose all the meta-information when I 
create the instance of the intent plus detail. I can't go back to that 
abstract form.


The obvious answer is saving that meta-information in conjunction with 
the code but when working in a team environment, that information is 
going to drive you handies up the wall because it's going to visually 
overwhelm the actual code. Serving the meta-information separately will 
mean it's even harder to recover a speech friendly version of the code 
after it's been touched.


Another thought experiment has been with always generating syntactically 
correct code and basing various code generation and navigation 
constructs around that.


So the questions I have right now are, or

what's a good open editor ( preferably multiplatform) that actually 
decomposes Python code into fundamental components such as class, 
expression, etc. and, lets you operate on those components? this is in 
contrast to editors such as Emacs which give you some fundamental pieces 
you can operate on but it's really character oriented and all of the 
syntax smartness not really available for coupling to speech recognition 
environment. it would be great if it was in Python so I don't have to 
learn yet another fricking language.


What would be the best way to store meta-information necessary to 
re-create the speech friendly presentation of code? I don't know if this 
is possible but I would like to be able to let handy programmers make 
changes that will be propagated automatically into the speech friendly 
code presentation without forcing them to learn the new notation.


An example of this is the definition of the class. In my world, a class 
definition 

Re: Captcha identify

[Eric S. Johansson]

On 8/14/2014 7:19 PM, Denis McMahon wrote:

On Wed, 13 Aug 2014 07:39:20 -0400, Eric S. Johansson wrote:


you are clear but also missing a really good reason to break captchas.
handicapped accessibility.  Captchas are a huge barrier to access and in
many cases push disabled users away from using a service  with captchas.

That's as may be, but bozo is not trying to improve handicapped
accessibility, he's trying to write a spambot.


not necessary.  you are probably right but he never described the 
application.


Please don't use the accessibility concerns surrounding captcha to
justify writing spambot software. It doesn't help the accessibility
argument to be seen to be pro spambot, in fact if anything it may damage
it. I agree that there are more reasons not to use captcha these days
than there are to use them, however I still don't advocate helping spambot
bastards defeat them.

not what I said or advocated.  pointing out that breaking captchas is 
good for accessibility issues it not the same as being pro spambot. it 
may have that effect but it is not the same thing. fwiw, making software 
accessible means making it possible to make your own interface via an 
application api.  the current scrape-a-gui model fails the 
-what-the-user-needs test.  at the same time, notice the huge security 
risk an D(ability)A(ccessibility) api opens up. does not mean we 
shouldn't use the DA api model, just that we also need to fix the 
security problem at the same time.



--
https://mail.python.org/mailman/listinfo/python-list

Re: Captcha identify

[Eric S. Johansson]

On 8/14/2014 2:37 PM, Peter Pearson wrote:

On Wed, 13 Aug 2014 14:16:02 -0600, Ian Kelly ian.g.ke...@gmail.com wrote:

. . . and as computers get more powerful the intersection
of {problems machines can't solve} and {problems humans can reliably
solve} grows ever smaller.

Which of the following eight sentences are sarcastic in tone?


and responses on this list alone show problems with detecting sarcasm 
(or snark).


--
https://mail.python.org/mailman/listinfo/python-list

Re: Captcha identify

[Eric S. Johansson]

On 8/12/2014 9:46 PM, Chris Angelico wrote:

On Wed, Aug 13, 2014 at 11:36 AM, Wesley nisp...@gmail.com wrote:

If my questions make you guys not so happy, I am sorry and please just ignore.
I just wanna a general suggestion here in the beginning.
Why I need to write such program is just having such requirements, and has 
nothing to do with the coding work itself. Don't say something to prove you're 
so noble.

The general suggestion you're getting is: Do not do this. Many of us
here use CAPTCHAs and spend time keeping one step ahead of those who
try to break them with software. By writing something to solve
CAPTCHAs, you would be stealing time from those people. Don't do it.

Am I sufficiently clear?

you are clear but also missing a really good reason to break captchas.  
handicapped accessibility.  Captchas are a huge barrier to access and in 
many cases push disabled users away from using a service  with 
captchas.  For me (very acute vision, crap hands) it take me 2-5 tries 
before I get an image I think I can read reliably, then it take 2-3 
tries to type the letters in (slowly and with hand pain) correctly. My 
mom (80yr and going strong) sees a captcha and gives up on using the 
site unless I tell her what to type.


one major tests for accessibility is can I automate common user tasks 
including tasks with context based decisions.  Captchas fail that test 
as do many authentication system user interactions and, if one is 
entirely truthful, entire applications.  Automating captcha solving 
would be a boon for the disabled or aging user.


try taking this moment as a challenge.  build an authentication 
system+ui that works for the disabled/aged and you will have an 
authentication system that will work better for everybody.  for example, 
use an equivalent of ssh-agent to supply credentials to sites needing 
them.  I can automate ssh-agent and we can make the process+UI easy 
enough for my mom to use it or automate it for her too.


eliminate captchas, 35+million disabled people would thank you as would 
many more millions of the not-yet-disabled like your future self.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Captcha identify

[Eric S. Johansson]

On 8/13/2014 3:27 PM, Chris Angelico wrote:

I agree with you, and I don't use CAPTCHAs on any of my services,
anywhere, and never have. (Partly because they *are* broken by people
writing scripts, and/or by just grinding them with human solvers; but
also because of the problems they cause for legit users, even those
with perfect eyesight.) However, the accessibility argument is one for
the removal of the captcha, *not* for its automated solving. I will
not support a scripted captcha solver for any reason. If you move away
from a site because you can't use it, so be it. If you get a chance,
tell the owner that there are alternatives to barely-readable images;
tricks involving page layouts are almost always safe, and there's
infinite room to play around in them.


your suggestion reminds me of the time I asked front range for help with 
accessibility because I had to use Goldmine on the job. Immediately 
after I asked for accessibility information, they told me they don't 
have any accessibility information because they don't have any disabled 
users.


Yes, they really did

your suggestion will probably generate a similar response.




There is no valid reason for automating something that's specifically
to prevent automation. The admin needs to provide an alternative,
instead.


There is only one valid reason based in the fact that we don't own or 
control many of the sites we depend on. Therefore, if I need to use a 
site be it government or commercial and it has a Captcha, I need to pay 
some form of cripple tax by either incurring pain or find/pay somebody 
to type for me. In this situation I thing it is perfectly acceptable to 
automate bypassing Captcha's.


--
https://mail.python.org/mailman/listinfo/python-list

Re: parsley parsing question, how to make a variable grammar

[Eric S. Johansson]

On 6/14/2014 8:10 PM, Michael Torrie wrote:

On 06/13/2014 03:05 PM, Eric S. Johansson wrote:

I appreciate any insight before I go too far off track.
--- eric

Perhaps this is off-topic, and doesn't answer your question, but is
Parsley a natural language parsing tool?  If not, and if it is natural
language that you're trying to parse, maybe you should see if the
natural language toolkit would be more appropriate to your needs.


Natural language is a rathole that many people go down when trying to 
build the speech user interface. In reality, all you need is something 
vaguely resembling normal language use. Something close enough to 
natural language that it's easy to remember but succinct enough that you 
don't burn out your speech capabilities. An example of this is my task 
log. It looks like this


16-Jun-2014 11:46 esj: start
I did something today. No really. I started work on time and I finished 
on time

16-Jun-2014 15:46 esj: end
day: 4 hours
...
week: ...

The speech grammar is job stamp (start| end). Job stamp start simply 
puts in the timestamp as seen above. Job stamp end adds the ending 
time stamp plus the day hours calculation. When I produce a report, the 
day and week numbers are recalculated in case I changed something 
manually. The calculation is then displayed so I can build an invoice.


This model is speech friendly on two levels. Grammar is simple and 
automates is much as it can. Second, if I didn't have the grammar and 
macro capability, I could still speak the magic keywords without too 
much stress. There's another level of speech friendliness. I also have 
time  stamp11:57, date stamp Jun 16, 2014, and log stamp 
16-Jun-2014 esj: since they are all related and similar in construction, 
it's easier to remember.


There's another aspect to natural language that is a bit of rathole. In 
my opinion, a good speech interface uses a combination of visual and 
speech elements. For example you should be of the see something on the 
screen and speak to it. This implies that the speech application can 
read the contents of the visual application so it can make the right 
decisions regarding grammar.


This usually isn't possible because visual applications don't reveal 
appropriate content at the right level. The best we can do now is a bit 
of screen and menu scraping of highly decimated information that has 
lost all context.  grumble


--
https://mail.python.org/mailman/listinfo/python-list

parsley parsing question, how to make a variable grammar

[Eric S. Johansson]

In my quest for making speech friendly applications, I've developed a 
very simple domain specific language/notation that works well. I'm using 
parsley which is a great tool for writing parsers especially simple ones 
like the one I need. However, I've come across a problem that I don't 
know how to solve.


Below is my grammar. The problem is the last element which aggregates 
all individual grammar elements. In my domain specific notation, it's 
possible for a user to create extensions and I'm trying to figure out 
how to make the grammar accommodate those extensions.


The first Issue is adding more statements. I can handle that easy enough 
by splitting the existing grammar into a prefix, statements, and 
postfix. I could append more statements to the end of the statement 
section. When I'm done, I can then join all of the pieces together into 
a single grammar.


The second issue is adding more elements between parentheses of bot so 
the additional statements can be included in the grammar. Seems to me, I 
should be able to create a Python expression which returns the OR list 
and it is interpreted as part of the grammar. Failing that, I'm just 
going to do a %s expansion when I create the grammar.


I appreciate any insight before I go too far off track.
--- eric

TF_grammar = r
kwToken = (letter|digit|'_')+
uses_statement = 'uses' ws kwToken:kwT ':' anything*:roL - do_uses 
(.join(kwT), .join(roL))

returns_statement = 'returns' ws kwToken:kwT - do_returns(.join(kwT))
template_statement = 'template' ws kwToken:kwT - do_template(.join(kwT))
remembers_statement = 'remembers' ws kwToken:kwT - 
do_remembers(.join(kwT))
everything_else = anything*:roL '\n'{0,1} - do_everything_else 
(.join(roL))
bot = (uses_statement | returns_statement | template_statement | 
everything_else)


--
https://mail.python.org/mailman/listinfo/python-list

Re: OT: This Swift thing

[Eric S. Johansson]

On 6/3/2014 5:49 PM, Mark H Harris wrote:


I have been engaged in a minor flame debate (locally) over block 
delimiters (or lack thereof) which I'm loosing. Locally, people hate 
python's indentation block delimiting, and wish python would adopt 
curly braces. I do not agree, of course; however, I am noticing when 
new languages come out they either use END (as in Julia) or they 
propagate the curly braces paradigm as in C.   The issue locally is 
trying to pass code snippets around the net informally is a problem 
with indentation. My reply is, well, don't do that. For what I see as 
a freedom issue, folks want to format their white space (style) their 
way and don't want to be forced into an indentation paradigm that is 
rigid (or no so much!).


the only problem I have with indentation defining blocks is that it's 
hard to cut and paste code and make it fit the right block level 
automatically. Too many times of made the mistake of one or two lines 
off by one or two levels of indentation and somehow the code doesn't 
work as I thought it would :-) It's also making it difficult to generate 
code automatically.


On the other hand, curly braces are royal pain to dictate or navigate 
around when programming with speech recognition.


--- eric

--
https://mail.python.org/mailman/listinfo/python-list

Re: OT: This Swift thing

[Eric S. Johansson]

On 6/3/2014 7:29 PM, Chris Angelico wrote:

On Wed, Jun 4, 2014 at 9:22 AM, Eric S. Johansson e...@harvee.org wrote:

On the other hand, curly braces are royal pain to dictate or navigate around
when programming with speech recognition.

I've never done that, in any language, but if I had to guess, I'd say
that both braces and indentation are harder to work with than a REXX
style where *everything* is words. :)


The model I am working with now, and it requires a very smart editor, is 
the jump down - jump up approach or the combination of mouse and voice 
where you move the cursor to where you want to go and say go here. 
Yes, sometimes it's easier to move a mouse that is to click it and both 
are easier than dragging.

--
https://mail.python.org/mailman/listinfo/python-list

parsley parsing question

[Eric S. Johansson]

how do you parse multi line text with parsley?  here is a work in 
progress and I'm trying to figure out why I need to split the text and 
process per line vrs all at one go.


thanks for any help.
--- eric

Here's the whole body of code ---

import parsley
#
# grammar to parse
#
# useswskeywordargumenteol
# templatewstemplate name
# returnsws(stdout|file: filename|storage name)
# rememberswsstorage name

# alt form
# templatewstemplate name[:storage name]

# test targets

def do_uses(a,b):
print do_uses %s - %s -% (a,b)
def do_returns(a):
print do_returns %s% (a)
def do_template(a):
print do_templates %s% (a)

# parsleyfied grammar
TF_grammar = r
kwToken = (letter|digit|'_')*
uses_statement = 'uses' ws kwToken:kwT ':' anything*:roL '\n'{0,1} - 
do_uses (.join(kwT), .join(roL))
returns_statement = 'returns' ws kwToken:kwT '\n'{0,1} - 
do_returns(.join(kwT))
template_statement = 'template' ws kwToken:kwT '\n'{0,1} - 
do_template(.join(kwT))

bow = (uses_statement | returns_statement | template_statement) ws

#
action_table = {
do_uses: do_uses,
do_returns: do_returns,
do_template: do_template,
}

# alt path: split lines and parse them one at time

def run_bot(body_of_text):
break up the body of text
for i in body_of_text.split(\n):
if len(i) != 0:  # why is this test needed?
x = parsley.makeGrammar(TF_grammar,action_table)
x(i).bow()

xxx=uses foo: this is some text
returns xyzzy
template templatename

# multi-line solution
x = parsley.makeGrammar(TF_grammar,action_table)
x(xxx).bow()

test line-at-a-time solution
run_bot(xxx)

--  bad result (multi-line) is ---

$ python parsleytest.py
do_uses foo -  this is some text
returns xyzzy
template templatename
 -

 good result should be ---

$ python parsleytest.py
do_uses foo  this is some text
do_returns xyzzy
do_template template templatename


--
https://mail.python.org/mailman/listinfo/python-list

converting old project to Python 3 was: Re: Why Python 3?

[Eric S. Johansson]

On 4/19/2014 12:04 AM, Ryan Hiebert wrote:
If you are starting a new project, I'd highly encourage you to use 
Python 3. It is a stable, well supported, and beautiful language, and 
gives you the full power of the innovation that is current in the 
Python world. Python 2 is still well supported (for a while to come), 
but you won't have the same access to new features and ideas that you 
would on Python 3.


The only reason that I'd still be on Python 2 is if I absolutely had 
to use a library that for some reason is not yet working on Python 3. 
Even then, I'd work hard to try and write it in Python 3 style Python 
2, because I'd want to be on Python 3 as soon as possible.


The Python extensions to NaturallySpeaking are combination of C++ for a 
COM interface and Python for grammar management. 
http://qh.antenna.nl/unimacro/implementation_and_acceptance_of_natlink.pdf


How hard is it to convert from C++ extensions for 2.x to 3.x? are there 
any tools to help with the process?


Thanks for any insights.

--- eric

--
https://mail.python.org/mailman/listinfo/python-list

Re: meta language to define forms

[Eric S. Johansson]

On 3/27/2014 4:56 PM, Sells, Fred wrote:

I'm trying to use python classes and members to define complex data entry forms 
as a meta language

The idea is to use a nice clean syntax like Python to define form content, then 
render it as HTML but only as a review tool for users,  The actual rendering 
would go into a database to let a vendor's tool generate the form in a totally 
non-standard syntax that's really clunky.


I've run into a similar problem when building a framework for 
programming by speech and web application development. Although, my 
goals were different. I want to something you can create with speech 
recognition without too much of a vocal load or requiring 
extensive/specialized editor changes. One could say I was trying to make 
it possible to develop web apps in Microsoft Word. :-)


The first attempt was a bracketed notation that was in effect a very 
high level domain specific notation. The next attempt is trying to 
eliminate the use of bracketing notation to specify scope and said use 
indentation.


Like you, the environment consists of little bits of Python that takes 
what you want in the form/user interface and generates the HTML and 
JavaScript for presentation in action.


To use your example, my notation would look something like this

: Form
  uses section_title; Enter Patient Vital Signs
  uses number_question; 3, Enter pulse rate
  : drop_down_list
uses title; Enter current status
uses choices; 1, alive and kicking
uses choices; 2, comatose
uses choices; 3, there's another dead Bishop on the landing

The: names refer to the methods that generate the code using the 
arguments provided by the statements within the: name definition. as 
refine what is your trying to do, you can make the: names more and more 
meta-and less and less implementation details. For example, one of the 
experiences that told me the bracketed notation was not going to fly was 
when I created a storefront for telescope shop. I created notation that 
expressed the work of the store not the display of the store 
information. Obviously the output of the notation was the display data 
but it operated in a way that the storekeeper understood and could take 
care of himself which was impossible with ordinary HTML and completely 
impossible if you added something like bootstrap.


And before somebody kicks up a fuss About the notation, let me say that 
this was aimed at disabled developers who cannot type anymore or who 
want to listen because they cannot see. What I have created is far more 
productive and speakable than any of the other systems out there.


--- eric

--
https://mail.python.org/mailman/listinfo/python-list

Re: What is the most pythonic way to build up large strings?

[Eric S. Johansson]

On 2/8/2014 3:35 AM, Rustom Mody wrote:

On Saturday, February 8, 2014 1:11:53 PM UTC+5:30, cstru...@gmail.com wrote:

I am writing a couple of class methods to build up several lines of html.  Some 
of the lines are conditional and most need variables inserted in them.  
Searching the web has given me a few ideas.  Each has its pro's and cons.

For creating html the method of choice is a template engine -- cheetah, mako
and a dozen others

You can of course roll your own (poor mans version) template engine
For that look up
1. triple quoted strings
2. format operator
as so happens, I'm traveling down a similar path myself. My goal is to 
use it to generate code for disabled, speech recognition using 
programmers (like myself). I believe my best route is using a modified 
version of string.Template but I wonder if my biases keep me from seeing 
a good alternative. I believe the following characteristics are essential:


Easy to speak
output generated with the right indentation
recursive expansion
can list substitution names


Here's an example of use. The current model for visual output is a split 
screen simulated as text between two long lines of 
:


Saying: add method

--- in the GUI/editor 
-

method_name??undefined
-
def method_name():
-

Saying: add three arguments
--- in the GUI/editor 
-

method_name??undefined
argument_1??undefined
argument_2??undefined
argument_3??undefined
-
def method_name(argument_1, argument_2, argument_3):
-

Saying: fix undefined
--- in the GUI/editor 
-

method_name??^
argument_1??undefined
argument_2??undefined
argument_3??undefined
-
def method_name(argument_1, argument_2, argument_3):
-

Saying some method name
--- in the GUI/editor 
-

method_name??some method name
argument_1??undefined
argument_2??undefined
argument_3??undefined
-
def some method name(argument_1, argument_2, argument_3):
-

You repeat the process saying fix undefineduntil all of the 
substitution names were filled in and the expanded template in the lower 
window was correct. The conversion from string names such as some 
method argument to codenames (SmMnm) happens in a different part of the 
process.


The problem am working on now is if I change something in the list of 
substitution names (upper window) how does that affect the code 
generated and shown in the lower window? The vast majority of the time, 
deleting a substitution name resets it to undefined. But deleting 
argument is special. At the moment, I'm going with explicit alteration 
of an argument list rather than inferring the argument list from the 
arguments in the substitution name window.


I'm reasonably sure that templates, some sort, are the way to go for 
reducing vocal load. What I'm still wrestling with is the kind of 
overhead I impose on the programmer and that, in turn, defines the kind 
of templates I need for programming by speech.


Solving this problem has made me curse one feature of Python which is 
it's type system. Something, more static, would make things much easier 
because the type information could be used to predict what will be said 
next thereby reducing the number of hacks, such as templates, necessary 
to write code. However, given that one can write Python reasonably well 
using ordinary speech recognition, I can almost live with its type 
system. :-) but, if somebody knows a way to make an empirical 
determination of type, I wouldn't turn away the help

--
https://mail.python.org/mailman/listinfo/python-list

Re: extracting string.Template substitution placeholders

[Eric S. Johansson]

On 1/13/2014 2:24 AM, Steven D'Aprano wrote:

On Sun, 12 Jan 2014 10:08:31 -0500, Eric S. Johansson wrote:


Now just walk the template for $ signs. Watch out for $$ which escapes
the dollar sign. Here's a baby parser:

found a different way

import string
cmplxstr=a simple $string a longer $string a $last line
nst=string.Template(cmplxstr)

identifiers = {}

while True:
try:
result = nst.substitute(identifiers)
except KeyError, error:
print error
identifiers[error[0]] = x
else:
break
print loop done

 --
at the end I only care about the keys in identifier which I fill in 
after user interaction.


--
https://mail.python.org/mailman/listinfo/python-list

extracting string.Template substitution placeholders

[Eric S. Johansson]

As part of speech recognition accessibility tools that I'm building, I'm 
using string.Template. In order to construct on-the-fly grammar, I need 
to know all of the identifiers before the template is filled in. what is 
the best way to do this?


can string.Template handle recursive expansion i.e. an identifier 
contains a template.


Thanks
--- eric
--
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging decorator

[Eric S. Johansson]

On 10/25/2013 7:55 PM, Yaşar Arabacı wrote:

Hi people,

I wrote this decorator: https://gist.github.com/yasar11732/7163528


wow, this looks really powerful. I would like to add the ability to 
associate a tag or set of tags with the decorator so that the debug 
output only happens when there is a matching tag in some global or 
environmental variable.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie: static typing?

[Eric S. Johansson]

On Tue, 06 Aug 2013 09:27:10 -0400, Burak Arslan  
burak.ars...@arskom.com.tr wrote:



First, let's get over the fact that, with dynamic typing, code fails at
runtime. Irrespective of language, you just shouldn't ship untested
code, so I say that's not an argument against dynamic typing.


It's not so much shipping untested code as not having or unable to test  
all the pathways in the code shipped. I ran into this problem with a  
server I built. I ended up solving the problem by building a testing  
scaffolding that let me control all inputs. It would've been much easier  
with static typing to make sure all the pieces lined up.


The other technique I've used is a properly set up exception handling  
environment. Do it right and you can log all of the errors so that you  
have useful information. Part of doing it right includes a system that  
tells you when exceptions happened right away so the server doesn't run  
for days or more failing at random but nobody notices because your  
exceptions keep the system for failing completely.


I guess this is a long way of saying instrument your software so that it  
can be tested and or give you enough information about the internal state.  
This is sort of like building a specialized integrated circuit. You need  
to design it so it can be tested/observed after it's been embedded in  
epoxy and not just count on being able to probe the wafer in the lab.

--
http://mail.python.org/mailman/listinfo/python-list

Re: [Savoynet] GS Opera Co: Pirates of Penzance

[Eric S. Johansson]

On Sun, 28 Jul 2013 19:49:07 -0400, Ethan Furman et...@stoneleaf.us  
wrote:



On 07/28/2013 10:57 AM, Chris Angelico wrote:
.
.
.

Okay, how did you get confused that this was a Python List question?  ;)


got_a_little_list[victim must be found] =  
http://www.youtube.com/watch?v=1NLV24qTnlg

--
http://mail.python.org/mailman/listinfo/python-list

Re: Simple Python script as SMTP server for outgoing e-mails?

[Eric S. Johansson]

On Mon, 22 Jul 2013 08:11:25 -0400, Gilles nos...@nospam.com wrote:


On Sun, 21 Jul 2013 18:28:27 -0600, Michael Torrie torr...@gmail.com
wrote:

The Sendmail MTA has been ported to many platforms including windows.
But...


Thanks for the tip. Since I couldn't find a good, basic, native
Windows app, I was indeed about to look at eg. Exim + Cygwin, and
resort to a Linux appliance if none footed the bill.




try http://emailrelay.sourceforge.net/
--
http://mail.python.org/mailman/listinfo/python-list

Re: What does it take to implement a chat system in Python (Not asking for code just advice before I start my little project)

[Eric S. Johansson]

On Thu, 18 Jul 2013 00:36:17 -0400, Aseem Bansal asmbans...@gmail.com  
wrote:


I wanted to do a little project for learning Python. I thought a chat  
system will be good as it isn't something that I have ever done.


I wanted to know what will I need? I think that would require me these
1 learn network/socket programming
2 find a free server to host my chat server
3 GUI development for clients



Not discourage you but this is a been there, done that kind of project.  
You could learn more from reading somebody else is code. What hasn't been  
done, and this would be very cool, is a chat program that works  
peer-to-peer with no central server. To do this, you would probably need  
to know about distributed hash tables and methods of piercing address  
translation firewalls (think UDP).


First however, I would suggest taking a look at https://jitsi.org/ and see  
how they do things. You can learn a lot from these people. They are very  
smart.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding other people's code

[Eric S. Johansson]

On Fri, 12 Jul 2013 10:22:59 -0400, L O'Shea lo0...@my.bristol.ac.uk  
wrote:


Literally any idea will help, pen and paper, printing off all the code  
and doing some sort of highlighting session - anything! I keep reading  
bits of code and thinking well where the hell has that been defined and  
what does it mean to find it was inherited from 3 modules up the chain.  
I really need to get a handle on how exactly all this slots together!  
Any techniques,tricks or methodologies that people find useful would be  
much appreciated.


glad to hear you're having a WTF moment (what's that function). Suggestion  
would be index cards, each containing notes on a class. truly understand  
what each parent class is in which methods are to be overloaded. Then look  
at one child and understand how it. Work your way breadth first down the  
inheritance tree.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Editor Ergonomics [was: Important features for editors]

[Eric S. Johansson]

On Fri, 12 Jul 2013 18:34:30 -0400, Dennis Lee Bieber  
wlfr...@ix.netcom.com wrote:




Sounds like you might have liked an accessory I had on my Amiga.
Basically a proportional joystick feeding an interface box which  
converted

the position value into a sequence of mouse movements --


sounds very cool. Although after I wrote my little screed, I found myself  
fiddling with my smartphone and I realized I was subconsciously putting it  
through the motions if it was a positioning device.


The gross motion is detected by the accelerometer's in the phone. The fine  
positioning by fingers on the screen.


Just thinking out loud.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Editor Ergonomics [was: Important features for editors]

[Eric S. Johansson]

On Fri, 12 Jul 2013 00:24:26 -0400, Steven D'Aprano  
steve+comp.lang.pyt...@pearwood.info wrote:



Frankly, nothing comes even close to a real mouse for feedback and ease
of use. Maybe a stylus. But that's it.


before tremors, I would agree with you. Stylus is amazingly good tool for  
user interaction in a GUI. After tremors, not so much. For example, when  
you sweep across the pad, you keep your mouse tip up, over and use  
feedback from your mouse pointer to tell you when to touch down. My  
tremors caused mouse clicks on tablet at about a 2 Hz rate. You can just  
imagine it, hearing me move the stylus across the pad going: Tap tap tap  
tap tap tap tap. Yeah, sucks to be me. A high-resolution mouse is  
similarly problematic because I can make a gross motion to another part of  
the screen. hitting a small target on a high-resolution screen is not easy  
in the least and usually takes longer than the gross positioning across  
the screen. What I would love is a mouse interface that uses a mouse  
motion for a small range but a force vector like Mr. eraser head for  
longer-range movement. Not exactly sure how the mouse would behave but  
that's a very rough idea what would work well with my hands.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Important features for editors

[Eric S. Johansson]

On Fri, 05 Jul 2013 23:13:24 -0400, Rustom Mody rustompm...@gmail.com wrote:Yes...The fact that rms has crippling RSI should indicate that emacs' ergonomics is not right.
As someone crippled by Emacs ( actual cause not known), I should also point out that RMS, instead of doing the responsible thing and using speech recognition software, burns the hands of other human beings by using them as biological speech recognition units.Now for me, an important feature for editor is the ability to command it, not by keystrokes but by function/method invocation. This is be the first step to reducing the disasters caused by misrecognition events injecting unintentional commands into an editor.  For example, bring up a file in VI in close your eyes and type some string like "save file" or "end of line". What kind of damage do you get?  With an editor RPC, you can bypass all this damage. You turn off keystroke input at the start of a recognition event and all keyboard queue data is injected as characters. All commands are injected by the API.There's a few other things, I need in a very tiny editor to help a part of my accessibility problem. One of the ways I deal with speech recognition user interfaces by creating tiny domain specific languages to solve a problem. You can say them, they are resilient in the face of misrecognition, edit them and you can replay them. Bunch of wins.  The tiny editor needs to use the right Windows edit control to work with NaturallySpeaking, save data so that I never have to think about it. It's always on disk, always safe. If I invoke a file by name, I get exactly one instance. And last, I want the ability to filter the contents of the editor through a bit of Python code so I can do transformations on opening the file or writing the file.Further down the road, instead of the classic syntax highlighting, I need dynamic naming of features so that I can say things like "replace third argument", "modify index" for format local times using pattern.I will admit the last one is a bit of a cheat because that's a subset of the domain specific notation I think that earlier. Not a solved problem :-)So important feature editor change depending on your perspective, or should I say, state of impending disability. We all become disabled with age, just some of us age much faster than the rest of the population-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: accessibility (was Re: simplified Python parsing question)

[Eric S. Johansson]

On 7/30/2012 10:54 PM, Tim Chase wrote:

On 07/30/12 21:11, Eric S. Johansson wrote:

the ability for multiple people to work on the same document at
the same time is really important. Can't do that with Word or
Libre office.  revision tracking in traditional word processors
are unpleasant to work with especially if your hands are broken.

If you're developing, I might recommend using text-based storage and
actual revision-control software.  Hosting HTML (or Restructured
Text, or plain-text, or LaTeX) documents on a shared repository such
as GitHub or Bitbucket provides nicely for accessible documentation
as well as much more powerful revision control.


But then you hit a second layer of doesn't really work nice with speech 
recognition. Using a markup language  can actually be more difficult than using 
a WYSIWYG editor. For example, with a soft word, I can do most of the basics 
using speech commands and I have what's called Select-and-Say editing 
capability in the buffer. Can't do that with any other editor. They are not 
integrated with NaturallySpeaking.


A few years ago I created a small scale framework for speech recognition users 
(akasha). You use the domain specific market notation to be able to construct 
Web applications. Instead of using classic HTML models, it used things that were 
more appropriate to speech driven environment. unlike with HTML, which you 
cannot write using speech recognition and a boatload of effort, akasha was 95% 
speakable using out-of-the-box speech recognition.


This also brings me to the concept of how the design for speech recognition use. 
Modifying an existing user interface or creating a new one either through a 
speakable data format and minimal application changes or by the application and 
grammar to a recognition engine and manipulating something that isn't speakable.


From experience, outside of the first model works well if you are looking for 
relatively easy and very high marks accessibility, the second is required if you 
are operating within a team and need to integrate with everybody else. 
Unfortunately,  the second technique points out just how badly designed most 
software is and that led me to the concept of no-UI (not unlike no SQL) which is 
more controversial than I want to get into right now.






It would please me greatly if you would be willing to try an
experiment. live my life for a while. Sit in a chair and tell
somebody what to type and where to move the mouse without moving
your hands. keep your hands gripping the arms or the sides of
the chair. The rule is you can't touch the keyboard you can't
touch the mice, you can't point at the screen. I suspect you
would have a hard time surviving half a day with these
limitations. no embarrassment in that, most people wouldn't make
it as far as a half a day.

I've tried a similar experiment and am curious on your input device.
  Eye-tracking/dwell-clicking?  A sip/puff joystick?  Of the various
input methods I tried, I found that Dasher[1] was the most
intuitive, had a fairly high input rate and accuracy (both
initially, and in terms of correcting mistakes I'd made).  It also
had the ability to generate dictionaries/vocabularies that made more
appropriate/weighted suggestions which might help in certain
contexts (e.g. pre-load a Python grammar allowing for choosing full
atoms in a given context).


Just ordinary speech recognition. NaturallySpeaking. Part of my hand problem is 
that I no longer have good fine motor control which sucks because I used to 
enjoy drawing with pencils and juggling. I've tried dasher and I don't have find 
enough motor control to make it work very well. Sometimes I play games with my 
girlfriend at fly or die and the user interfaces for the various game 
controllers is simple enough that my hands only get in the way some of the time. 
Or at least that's what say when she is beating me soundly at billiards. :-)


Some of the ideas you've mentioned have been thought in another contexts. The 
problem is that when it comes to working with code, you have two problems. 
Creation of code and editing code. Which do you do more? If you're like most of 
us, it is editing. That's why I made the toggle words feature something that 
would toggle both from a string name to a codename and vice versa.the future 
version of this and, this is where I'm going to need a lot of help from the 
Python community, would translate the statement in a buffer to a particular 
two-dimensional form and place it into a special window that NaturallySpeaking 
can operate on. The reason for covering it from the one-dimensional string of a 
statement to a two-dimensional form is to make it easier to disambiguate 
different features using speech. The idea isn't fully fleshed out because I want 
to get through this one first and actually be able to start writing code again.




--
http://mail.python.org/mailman/listinfo/python-list

Re: simplified Python parsing question

[Eric S. Johansson]

On 7/29/2012 11:33 PM, Steven D'Aprano wrote:

On Sun, 29 Jul 2012 19:21:49 -0400, Eric S. Johansson wrote:


When you are sitting on or in a name, you look to the left or look to
the right what would you see that would tell you that you have gone past
the end of that name. For example

Have you read the docs? It gives full details of the Python syntax.


Yes I have. I was hoping for a different perspective because what I'm trying to 
do is middle out parsing. Top-down when the scanner focus moves from left to 
right and bottom up when the scanner focus moves from right to left.


sounds kind of odd when I describe it that way but both the cursor is on the 
middle of a name string and I need to look to either end of that name string 
before can do a conversion to a symbol string, I have to look at both ends in 
different ways. If you've read the documentation I've provided, would it be a 
better example to use for describing some of the issues. Here's a very rough 
draft of a storyboard


https://docs.google.com/presentation/d/1fuKyo9AE6i9ZdX2lucwK0v_W5Kx9M3Mezavm40wzCo8/edit

the first 13-14 slides are the working content for the storyboard. the rest is 
mostly memory of things I was thinking about so if it doesn't make sense or 
seems wrong, don't give me grief. :-)



Here's a Python parser using the pyparsing library. It's a bit old
(written for Python 2.4) but it shouldn't be hard to update it to new
syntax:

http://pyparsing.wikispaces.com/file/view/pythonGrammarParser.py



thanks for the reference. I'll take a look at it as well.
--
http://mail.python.org/mailman/listinfo/python-list

Re: simplified Python parsing question

[Eric S. Johansson]

On 7/30/2012 5:25 AM, Laszlo Nagy wrote:


Did you try to use pygments?

http://pygments.org/docs/api/



thanks, I'll take a look.



I would first tokenize the code, then divide it by statement keywords. 
Finally, you just need to find expression/assignment statements in the 
remaining sections. (Maybe there is a better way to do it.)






yeah the problem is also little more complicated than simple parsing of Python 
code. For example, one example (from the white paper)


*meat space blowback = Friends and family [well-meaning attempt]

*could that be parsed by the tools you mention? I suspect not but this is what I 
need to generate using speech recognition because it's easily spoken. A more 
complex example might be something like


new base = OS path-base name (old path)

or

if OS base exists (current path): new base name = OS path base name(current 
path)

What's particularly cute here is that using the translation technique I can 
actually describe the full object method path with a minimum of speaking 
overhead. Python is great. :-)


But the questions remain, will these tools are stuff like this?


--
http://mail.python.org/mailman/listinfo/python-list

Re: simplified Python parsing question

[Eric S. Johansson]

On 7/30/2012 10:59 AM, Laszlo Nagy wrote:




yeah the problem is also little more complicated than simple parsing of 
Python code. For example, one example (from the white paper)


*meat space blowback = Friends and family [well-meaning attempt]

*could that be parsed by the tools you mention?


It is not valid Python code. Pygments is able to tokenize code that is not 
valid Python code. Because it is not parsing, it is just tokenizing. But if 
you put a bunch of random tokens into a file, then of course you will never be 
able to split that into statements.


If you have been reading the papers, you would understand what I'm doing. I'm 
trying to take Python code with speech recognition friendly symbols and 
translate the symbols into a code friendly form. My conjecture is that you can 
change your perspective on the code and look for the edge that would normally be 
used to define start of a symbol, you should be able to define the name string. 
Another possibility is looking at the region which just contains letters numbers 
and spaces and outside and use that as your definition of a name string. It 
would probably help to verify that each word is found in a dictionary although 
that adds extra complexity if you are trying to increase the dictionary at the 
same time as the translation table.


I'm beginning to think for the first generation I should just use regular 
expressions looking forwards and backwards and try to enumerate the possible cases.


Probably, you will need to process ident/dedent tokens, identify the level 
of the satement. And then you can tell what file, class, inner class, method 
you are staying in. Inside one level or code block, you could try to divide 
the code into statements.


I was starting in that direction so that is good confirmation



Otherwise, I have no idea how a blind person could navigate in a Python 
source. In fact I have no idea how they use regular programs. So I'm affraid I 
cannot help too much with this. :-(


I'm sorry, I am, and I'm trying to help, hand disabled programmers. There are 
more disability than blindness and after almost 20 years of encountering this 
shortsightedness, I do get a little cranky at times. :-)





--
http://mail.python.org/mailman/listinfo/python-list

Re: simplified Python parsing question

[Eric S. Johansson]

On 7/30/2012 9:54 PM, Steven D'Aprano wrote:

On Mon, 30 Jul 2012 11:40:50 -0400, Eric S. Johansson wrote:


If you have been reading the papers, you would understand what I'm
doing.

That is the second time, at least, that you have made a comment like that.


Actually, it's probably more like the forth hundred time. :-) I apologize, I was 
wrong and I would back up and start over again if I could


Understand that most people are not going to follow links to find out
whether or not they are interested in what you have to say. If you can't
give a brief explanation of what you are doing in your email or news
post, many people aren't going to read on. Perhaps they intend to but are
too busy, or they have email access but web access is restricted, or
they've already got 200 tabs open in their browser and don't want any
more (I'm not exaggerating, I know people like that).


accept criticism. I'm still working on an elevator pitch for this concept. I've 
been living with the technology and all its variations for about 10 years and 
it's not easy to explain to someone who is not disabled. People with working 
hands don't understand how isolating and, sometimes humiliating software can be. 
advocates like myself sometimes get a little tired of saying the same thing over 
and over and over again and people who are disabled just don't care. So you find 
yourself using shorthand because you going to be ignored anyway


People use email because it is a push technology -- you don't have to
go out and look for information, it gets pushed into your inbox. Clicking
on links is a pull technology -- you have to make the explicit decision
to click the link, open a browser, go out to the Internet and read who
knows what. That requires a different frame of mind. Expect to lose some
of your audience every time you require them to follow a link.


Okay, this implies the need to really work on more of an elevator/summary 
speech. Thank you for your input. I appreciate it


And *especially* so if that it a link to Google Docs, instead of an
normal web page. Google Docs is, in my opinion, a nasty piece of rubbish
that doesn't run on any of my browsers. As far as I'm concerned, I'd
rather download a Word doc, because at least I can open that in
OpenOffice or Abiword and read it. Something in Google Docs might as well
be locked in a safe as far as I'm concerned.


the ability for multiple people to work on the same document at the same time is 
really important. Can't do that with Word or Libre office.  revision tracking  
in traditional word processors are unpleasant to work with especially if your 
hands are broken.


It would please me greatly if you would be willing to try an experiment. live my 
life for a while. Sit in a chair and tell somebody what to type and where to 
move the mouse without moving your hands. keep your hands gripping the arms or 
the sides of the chair. The rule is you can't touch the keyboard you can't touch 
the mice, you can't point at the screen. I suspect you would have a hard time 
surviving half a day with these limitations. no embarrassment in that, most 
people wouldn't make it as far as a half a day.  I've had to live with it since 
1994. Not trying to brag, just pointing out the facts.


I'm going to try again from a different angle in a different thread. I will take 
your advice to heart and I would appreciate some feedback on how well I do 
satisfying the issues you have described


--
http://mail.python.org/mailman/listinfo/python-list

toggle name, With explanations

[Eric S. Johansson]

the wonderful responses I received from people like Lazlo, Paul, and Stephen has 
given me some ideas about a different approach. First, here's explanation of 
what I'm doing


I'm developing a method which will enable hand disabled developers such as 
myself to create and manipulate symbols identical to those created by 
non-disabled developers. the input mechanism will be speech recognition 
maximizing the use of ordinary continuous English dictation and a minimal set of 
commands to activate this method. Subsequent work will produce a speech user 
interface for navigation code and tools such as debuggers bypassing the 
interference and constraints created by GUIs.


The core concept is any string of a natural language words can be transformed 
into a symbol by storing the matchup between the natural language word string 
and the symbol string in a database.  in other words, a dictionary which has 
paired keys and one key can return the other.


in my original request I was thinking about parsing the environment and looking 
for the transition between code and symbol or natural language word string but 
unfortunately, that technique breaks because the characters around the region of 
interest may not be complete or correct code. So I thought about trying to look 
at the other way. If you find a string of characters that you don't look like a 
symbol or look like a string of natural in words, when the characters stop 
looking like that, then that defines the limits of the region of interest.


example:

s.pack(side=Tkinter.R^IGHT, fill=Tkinter.Y)

the carrot marks the current position. If I was to say this point, toggle 
word, I would first look to the left and the right and look forward the 
character string stopped looking like a symbol or a natural language word 
string.in this example, I would find the string RIGHT. If I didn't find 
anything, I would look one more character to the left and see if there was a . 
present, do the same search again this time solely to the left and I would have 
the string TKinter.RIGHT. The database would have the in tree and replace it 
with TK interpreter right so I could edit the string with speech recognition.


s.pack(side=TK interpreter^ right, fill=Tkinter.Y)

Then using the same basic technique as I described above, I looked left and 
right for a series of symbols, in this case they are actually words, until I 
reach something that is not a symbol. The end result is used a key for the 
database which would return Tkinter.RIGHT


It looks like if I'm correct, this is a much simpler way of doing what I wanted 
to do (extract symbols and natural language word strings).


1) can you see any holes in this logic?
2) what would you recommend for regular expressions. The reason I ask is that if 
you have spaces in the string, you only want want alphanumeric sequences,
if you have alphanumeric plus symbol special characters, you don't want spaces. 
I'm not sure how strict that precondition should be. I'm going to

need to think about it more. Opinions would be welcome.

I think this works for almost any language too which is really important in the 
disabled programmer community.


I appreciate your patience. Sometimes the overhead of communicating using speech 
recognition with tools don't work well with speech recognition such as
Thunderbird makes the whole process of writing almost more difficult than it's 
worth. Working on tools like this is incremental progress I need to make
in order to be able to bring speech recognition-based accessibility to the 
Python world.


--- eric



--
http://mail.python.org/mailman/listinfo/python-list

simplified Python parsing question

[Eric S. Johansson]

as some folks may remember, I have been working on making Python and its tool 
base more accessible to disabled programmers. I've finally come up with a really 
simple technique which should solve 80% of the problem. What I need to figure 
out is how to find a spot in the code where a symbol exists and potentially, 
it's rough type (class name, instance, etc.). This is really a much bigger 
question that I want to get into right now but I'm looking just to build a demo 
to back up a storyboard plus video.


When you are sitting on or in a name, you look to the left or look to the right 
what would you see that would tell you that you have gone past the end of that 
name. For example


a = b + c

if you are sitting on a, the boundaries are beginning of line and =, if you are 
sitting on b, the boundaries are = and +, if you are sitting on c, the 
boundaries are + and end of line.  a call the region between those boundaries 
the symbol region.


if this example is clear to you, what you suggest for a method of finding a 
whole statement, or a whole symbol region? note, doesn't have to be perfect or 
complete solution, just good enough to let me do a moderately complex demo and 
seek funding accessibility world to build a complete environment.


I appreciate the help because I believe that once this is working, it'll make a 
significant difference in the ability for disabled programmers to write code 
again as well as be able to integrate within existing development team and their 
naming conventions.


Looking forward to responses.

--- eric

first draft write up of technique
https://docs.google.com/document/d/1In11apApKozw_UOPAhVz0ePqns72_6652Dra34xWp4E/edit
--
http://mail.python.org/mailman/listinfo/python-list

need python+windows edit control help

[Eric S. Johansson]

I'm back with yet another attempt at adding accessibility features using Python 
and NaturallySpeaking. I've simplified the concepts again and I really need some 
help from someone who knows Microsoft Windows and Python. My goal is developing 
a template for what I'm trying to do, then I can take over and generate some 
useful accessibility tools.


The core idea is an accessibility adjunct program receiving focus at 
start-of-utterance and returns focus to the original application at 
end-of-utterance. The window associated with the program contains a grid. Within 
the grid is an active cell which can accept input. Any cell could be made active 
depending on the state of the program but only one cell accepts input at any one 
time.


How would this be used? For example, the Skype IM window is atrocious for its 
disabled users. If one associated at two cell window accessibility adjunct 
program with Skype, the user could dictate, edit, retrain, etc. within the 
adjunct program and on command, return the data to Skype. One could also contain 
a small history so that like Skype, you could go back and edit a previously sent 
message.


a second use case is found on my blog http://blog.esjworks.com which is the tool 
to create mangled codenames from speech. I think the grid model works better 
than individual text fields that I originally wrote because it allows me to make 
better use of a cache of previously generated symbols.


Anyway, if anybody can help, I would really appreciate some assistance.

--- eric
--
http://mail.python.org/mailman/listinfo/python-list

Re: need python+windows edit control help

[Eric S. Johansson]

On 10/21/2011 10:03 PM, Mark Hammond wrote:

On 22/10/2011 10:30 AM, Eric S. Johansson wrote:

I'm back with yet another attempt at adding accessibility features using
Python and NaturallySpeaking. I've simplified the concepts again and I
really need some help from someone who knows Microsoft Windows and
Python. My goal is developing a template for what I'm trying to do, then
I can take over and generate some useful accessibility tools.


The python-wi...@python.org mailing list might be the best place to look for 
help - although you will probably need to provide much more information before 
anyone can help.  MSDN documents most of what you can do with edit control 
(look for windows messages starting with EM_), but without checking, I 
expect you will find programs like Skype don't use a Windows edit control at all.


Mark
thanks for the pointer. When I talk about speech user interfaces in general and 
accessibility specifically, I find it's better to give a short overview (yes, 
this was short) before going into the details.  I'll be clearer about what kind 
of help I need.


--- eric
--
http://mail.python.org/mailman/listinfo/python-list

Re: Static typing, Python, D, DbC

[Eric S. Johansson]

 On 9/12/2010 4:28 PM, Paul Rubin wrote:

Bearophilebearophileh...@lycos.com  writes:

I see DbC for Python as a way to avoid or fix some of the bugs of the
program, and not to perform proof of correctness of the code. Even if
you can't be certain, you are able reduce the probabilities of some
bugs to happen.

I think DbC as envisioned by the Eiffel guy who coined (and trademarked)
the term is that it's a static verification technique, marketing-speak
annotating subroutines with pre- and post- conditions that can be
checked with Hoare logic.  Runtime checks wouldn't qualify as that.
Programming by contract as popularized by Bertrand Meyer (that Eiffel guy) was 
designed for run-time checks because that's when errors show. Programming by 
contract is based on Dijkstra's weakest precondition work.  
http://www.scss.tcd.ie/Edsko.de.Vries/talks/weakest_precondition.pdf


During the last five years before my hands went bad, I spent  significant amount 
of time working with formal methods  and simpler concepts such as design by 
contract. Design by contract made the last five years of my programming career 
the most rewarding it had ever been. It was nice to finally write code that was 
significantly, and measurably better than those coded using Brown 25  (another 
fine product from Uranus)[1].


one of the common mistakes have seen about programming by contract or design by 
contract is that people assume it's a proof of correctness. It's not, it's an 
experiential proof that the code is executing correctly to the extent that 
you've characterized the pre-and post-conditions. Formal proofs are considered a 
dead-end as far as I can tell but it's been a good number of years since I've 
really investigated that particular domain.


If my opinion is worth anything to anyone, I would highly recommend adopting 
some form of programming by contract in everything you write.  use the 
properties that Dijkstra taught us with the weakest precondition to test only 
what you need to test. If you are careless, assertions can build up to a 
significant percentage of the code base and Slow execution. the argument for 
dealing with this, last time I looked, was that you turn off assertions when 
your code is running. This logic is flawed because bugs exist and will assert 
themselves at the worst possible time which usually means after you turned off 
the assertions. Personally, I see assertions as another form of defensive 
programming. If you can define preconditions as excluding bad data, then your 
mainline body becomes faster/smaller.


Anyway, this debate was going on circa 1990 and possibly even earlier when 
Dykstra wrote his first papers. Consider me a double plus vote for strong 
programming by contract capability in Python. If I can ever get programming by 
voice working in a reasonable way, I might even be able to use it. :-)


PS, to explain Brown 25 in case you weren't watching those damn kids comedy 
movies in the 1970s with a bunch of very stoned friends.  Thank God for campus 
buses keeping us out of cars.

[1] http://www.youtube.com/watch?v=008BPUdQ1XA
--
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Horace Blegg wrote:
 I've been kinda following this. I have a cousin who is permanently wheel
 chair bound and doesn't have perfect control of her hands, but still
 manages to use a computer and interact with society. However, the
 idea/thought of disabled programmers was new to me/hadn't ever occurred
 to me.
 
 You say that using your hands is painful, but what about your feet?
 Wouldn't it be possible to rig up some kind of foot peddle for
 shift/caps lock? Kinda like the power peddle used with sowing machines,
 so the hands are free to hold fabric.
 
 I don't mean this in a condescending manor, and I apologize if you take
 it as such. I'm genuinely curious if you think something like this could
 work.
 
 The way I was envisioning it working last night (and I haven't the
 faintest clue how SR works, nor have I ever used SR) was that you would
 hit the foot peddle, which would tell the SR program to capitalize the
 first letter of the next word (a smart shift, basically, so you don't
 end up doing something like ... WONderland -or- stocks are up 1,0))%
 TOday.)
 
 Possible? Stupid?
 
it's not stupid.

People have used foot pedals for decades for a variety of controls. I don't
think foot pedals would work for me because when I am dictating, I pace.
Standing, sitting, I pace. With a cord headset, I'm forced to stay within about
4 feet of the computer. But what I'm using a Bluetooth headset, I will sometimes
ramble as far as 10 or 15 feet from the computer. It helps if I make the font
larger so I can glance over and see what kind of errors I've gotten.

I really love a Bluetooth headset with speech recognition. It's so liberating.

Your question about foot pedals makes me think of alternative. would it make
sense to have a handheld keyboard which would be used for command-and-control
functionality or as an adjunct to speech recognition use? It would have to be
designed in such a way that it doesn't aggravate a hand injury which may not be
possible. Anyway, just thinking out loud.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Steven D'Aprano wrote:
 That assumes that every word is all caps. In practice, for real-life 
 Python code, I've tripled the vocal load of perhaps one percent of your 
 utterances, which cuts your productivity by 2%.
 
 If you have 1 words in you per day, and one percent get wrapped with 
 a leading and trailing capslock, you have:
 
 9900 regular words plus 100 constants
 
 versus
 
 9700 regular words plus 100 constants plus 200 by capslock.
 
 Your productivity goes down by 200 words out of 10,000, or two percent.

oh I wish it was so simple. I would absolutely you if it was that simple the
real world. Somehow, I fear that you wouldn't understand unless you sat next to
me and watch me try to write code to  a variety of standards.

In practice, my experience says that with a really good  speech driven
environment for programming, IT, vocal load probably by a quarter to a half and
be more compliant with current fashion for naming.
 
 
 Heck, have you ever noticed how most Python smart editors can't even
 indent properly according to local contexts. Emacs is the only one and
 even that one sometimes fails
 I use kwrite for editing, and I can't say I've ever noticed a failure.
 okay, it fails from a speech recognition user perspective. Put the
 cursor on the line and hit the tab key. Insert spaces/tabs in the line
 of text. Not good for speech recognition. If  mess of indentation and
 hit the tab key, it doesn't automatically indent to the right location.
 I'll be damned if I'm in the sit there speaking
 tabkeytabkeytabkeytabkeytabkey because the error should take care of
 it for me and save my voice. Like I said, Emacs does it correctly and
 nobody else does as far as I can tell.
 
 I don't understand what you're describing.
 
 If you set kwrite to use Python style indent mode, then starting a new 
 line will automatically indent to either the current indent level, or one 
 extra indent level if the line ends with a colon. You shouldn't need to 
 indent forward more than one level at a time when writing Python code, 
 although you will need to dedent multiple levels on occasion.

I recognize your confusion. It's very common when describing this problem. If I
had some way of making a movie of what  and describing, obviously be more clear.
I'll see if I can make a movie with my camera that demonstrates the problem.  It
probably won't happen fast but, what I tried your editor, it failed   with a
trivial effort.  I think I just hit the tab key multiple times in different
places on the line. In all cases it did the wrong thing. For me, the right thing
is to force the line to the right indentation based on the previous line to
matter how may times you get the tab key or where you are on that line when you
hit the tab key. I could be in the middle of the line, the end of line, start a
line, the start of the string and if I hit a tab key, that line should go to
exactly the right place stayed there no matter how me more times I typed a tab 
key.

But this might be what you're getting confused. What I'm really asking for is
the ability to say force indent and have the line indent exactly correctly
based on context. It doesn't have to be the tab key. The tab key is the method
of convenience.

 
 You're looking at it from the classical anti-accommodation perspective.
 Don't change the convention, give us the tools so we can comply with
 what the rest of you do. 
 
 Just a minute. You're the one who started this discussion rejecting the 
 convention. Your first post started off:
 
 I reject this convention...
 
 and then finished with
 
 so I reject pep 8 because I have no voice safe alternative
 
 Do you blame us for reading this as a protest against uppercase 
 identifiers?

it's a protest against  identifiers that increase vocal or hand load.  It's also
protest against decisions people make without awareness of the implications, in
this case, increasing the barriers against disabled programmers.

 
 Now you're saying you're happy for us to keep the all-uppercase 
 convention and just want better tools. Okay, you want better tools. 
 Great. If you're attempting to raise the profile of disabled programmers, 
 you've done so, but what exactly are you expecting?

I waffle back and forth on that. I recognize my opinion  matters as much as a
piss hole in the snow. But the unintentional discrimination really gets to me.
In case you're wondering, I feel this way about many forms of bad
design/exclusionary practices. Some I can even do something about.

my expectations are evolving. I wanted to raise awareness, like you said, I've
done that. But now, I'd like to turn it into action. As I said in another post,
the editor that would let me get back to writing Python relatively easily again
doesn't exist. It's not the flashy wonderful no keystrokes whatsoever condition
but it's significantly better than the current Emacs/VI/Python editor du jour.
it would be able to operate open loop with relation to speech recognition but 

Re: pep 8 constants

[Eric S. Johansson]

Tim Chase wrote:
 I've tried it least two dozen editors and they all fail miserably
 because they're focused on keyboard use (but understandable)
 [...snip...]
 I've tried a whole bunch, like I said at least a dozen. They
 all fail for first reasons such as inability to access all
 functionality through keystrokes (easiest interface method
 from speech recognition)
 
 I'm not sure I follow which you want...you kvetch that
 they're too focused on keyboard use, but then that you can't
 access all functionality through the keyboard.

sorry. I've been living in this world for so long that I sometimes forget to
explain what's obvious inside my head. I apologize for the confusion.

The apparent conflict arises because the same term (keyboard access) is used to
describe two different problems. In the first case, the user interface model
(how you access taxes, manipulate light which (language) constructs are designed
to be efficient for your hands.  speech recognition users need an editor that
supports constructs that are efficient for the voice. One such construct is the
ability to navigate or operate on language elements by name. I've used some of
them before such as predicate, index, first method etc.

The second problem is that editors are designed to be driven by keystroke. If I
had a cross  process boundary APIPaula I can simply call the editor function to
perform to give operation. Unfortunately, today my speech recognition
environment needs to generate keystrokes to access functionality. for example,
in Emacs, when I say delete word, the macro and marmot emits M-d

 
 [warning, blatant vim fanaticism follows]
 
 I use vim and can't remember the last time I used the mouse
 with it (save for occasionally lazily scrolling with the
 mouse-wheel, but you can scroll with the keyboard too), so
 it meets your must be fully accessible through the
 keyboard constraint.  It also has single keystroke commands
 for indenting/exdenting the current line as you mention:

you are forgiven. :-) try this experiment. Bring up the buffer full Python code
code you value them, starting in command mode, close your eyes and type a random
word. While your eyes are closed, undo that word. Every time I've tried it the
results have been mildly disastrous. If you been paying attention, I've tried to
leave speech recognition errors in place whatever didn't impede understanding
(too much) but, remember I'm getting one error in 20 errors is on average. That
means, I'll be correcting the IE errors, potentially much more dangerous errors
are regular basis. Any energy use by speech recognition must be able to cope
with a random dictation errors and let the user recover gracefully. Again, until
I started using speech recognition, I would never would've thought of this as a
failure case.

 
I know this is also counter to the Python way but having
something marking and outdent would be really useful so
that a vocal driven command to indent or outdent a block
would be practical.
 
 which can be done in insert-mode with control+D, control+T,
 and if you want to clear all indentation (all the way back
 to the first column), you can use 0 followed by control+D.
 Vim also allows for fairly detailed control over
 auto-indentation settings so you can match them to your
 preferences.  I suspect Emacs may be configurable to offer
 similar functionality but I'd have to defer to the emacsen
 on the list.

Yes, Emacs will, a single tab key, tab view to the indentation level specified
by the previous line unless it's already there and then it will start inventing
further. This really sucks. Sometimes, you just weary and then to  (you just
want to) go to the right place and stay there
 
 That said, I'll be the first to admit that the vi/vim
 learning curve is more like a brick wall than a curve.
 However, I find the efficiency gains abundantly than repaid
 the time I invested to learn it well.

Yeah, I first encountered the eye in 1985. Or maybe I should say VI (Roman
numeral six).
 
 Dasher[1]

 I've tried it, it's quite promising but my hands term are sufficiently
 that I can't target accurately.
 
 Last I tried it, it scaled the target sizes based on
 probability.  You might also try unconventional pointing
 devices for better precision.  I've seen web-cam
 eye-tracking tools which might make it a bit easier.  Or try
 a tablet input (where the motion corresponds linearly, as
 opposed to accelerated mouse motion).  Such input options
 are listed on the Dasher website, at least for those they
 tested.
 

I like tablets. I need to buy a new one. We only problem is that most pens for
tablets are a little bit too small and hard for my hands (although they are much
better than mice). The major downfall is the buttons on the pen shaft. Damn
that's awkward to reach. I think it would need a separate tab of three buttons
that I can click and double-click independent of the pen controls.

 Oh, another failure point. Have you ever tried to selected 

Re: pep 8 constants

[Eric S. Johansson]

Rhodri James wrote:
 
 Gah.  Ignore me.  I hit 'send' instead of 'cancel', after my musings 
 concluded that yes, an editor could be smart enough, but it would have to
 embed a hell of a lot of semantic knowledge of Python and it still wouldn't
 eliminate the need to speak the keyboard at times.

imagine having the same problem except that happens at random while you're
speaking and watching something else other than a screen. :-)

Yeah, it would take a lot of semantic knowledge about Python. Is it possible to
leverage compiler internals? Is it possible to gather as much information as you
can and when the system says I don't know you tell what you know it remembers
that for future reference?

And you're right, they're always corner cases where you'll need to speak the
keyboard or type. I've mostly resigned to accept on days when I have an absolute
hissy hissy fit because my hands hurt so bad I can't get enough painkillers
drop the pain and let me function.

In the real short term what I really want. More than anything right now is to
get back to the point where I can  pick away at writing Python again. I'm in
this really weird confluence of virtual machine hell,  the evolution of
naturally speaking under wine and the problems of telling an editor how to do
the right thing.

There's a gap between the fragile crappy way I and others operate today and the
really ideal completely voice driven  environment that exists between my ears. I
would like to move into that gap but it's sufficiently far away from what my
hands can do that I'm dependent on others and that makes me  really crazy 
sometimes.

From my perspective, what I consider a reasonable intermediate step would be an
editor that has the following features:

The ability to select regions either by NaturallySpeaking Select-and-Say and
Emacs mark and point semantics.
Very deterministic indentation control. (I.e. indent x tabs or indent to right
level.)
ability to navigate/operate on generic language features
it would be nice if one could edit language features in a separate window again,
using Select-and-Say type interface.
another it would be nice would be the ability to look up type signatures
(classes, methods etc. and inject the appropriate template when using a
particular method. (Doesn't have to be by voice)


this level of functionality, would also make it possible to comply with PEP-8
:-) given proper easy and automatic name generation and dumpling.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Rhodri James wrote:
 [Trimming for length, sorry if that impacts too much on intelligibility]

no problem, one of the hazards of speech recognition uses you become very 
verbose.

 This goes a long way, but it doesn't eliminate the need for some forms
 of escape coming up on a moderately frequent basis.  Consider Coffee
 strength equals five for example: this could mean either
 
   coffee_strength = 5
 
 or
 
   COFFEE_STRENGTH = 5
 
 depending on whether we will later be using it as a constant or not.
 Python doesn't have syntactic constants, which is precisely why PEP-8
 is useful.  You might have enough smarts in your system for it to
 remember after the first time you use coffee strength, and it might
 be unambiguous, but at the very least you need to be able to say
 Constant coffee strength equals five first time round.

right. The initial state of a symbol is always a chatty moment. It sets the
context and background information for subsequent use. My initial reaction is
that when you do coffee strength equals five, it would pop up a simple dialog
asking variable or constant? You would say variable and it would format
everything the right way. This is a form of interactive dialogue that would  be
used consistently throughout the rest of the environment.
 
 This isn't the only occasion when you simply don't have the context
 to avoid verbal disambiguation.  Are you accessing attributes of the
 class MyClass or its instance my_class, for instance?  In your initial
 post you seemed to be claiming that having to do this disambiguation
 textually was bad, and PEP-8 should therefore be rejected.  Given
 that I'm not prepared to lose the productivity increase that comes
 with being able to disambiguate visually at a glance, I don't see
 that it's avoidable.

I don't mind   verbal disambiguation if it's infrequent. What I object to is
being forced to disambiguate every time I use a symbol. The reason being is one
is a minor increase in vocal load and can be  made a dumb template (maybe) where
is the other is just doing a bunch of makework over and over again.

As for your my class example, you never ever use my_class unless it's prefaced
by an instance of the class MyClass. And if you say something like

My class yields fall class
or
fall class is my class
or
fall class = my class

You have sufficient information to know that my class is a class name.and that
you have some number of arguments and the system can run you through a dialogue
to fill in the arguments.

I wish I had the tools to create a simulation of what the editing sequence with
the dialog box pop-ups in nice little animated movie. Heck, if I could just
capture time lapse I could do it with paper and pencil and a voiceover. It would
remind you of Gumby  meets South Park but... I digress

 
 Incidentally, since what you're proposing is essentially templating,
 wouldn't it be better to do it as post-processing on the speech
 recognition rather than building it directly into an editor?
 to resolve

if my template in, you mean a system that can receive type information from
somewhere about every single symbol in the system and then load up a grammar,
handle the dialogs for disambiguation at the same time as providing an editing
environment that lets you refer to symbols by their verbose name instead of
their codename and still operate on. For example, replace an argument should pop
up a dialog box with the second argument of the first method on the line. You
then can change things by their names like  second string  or array index.
Then sure, maybe a templating system would work. But I don't think it will

thank you for continuing in this dialogue.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Tim Chase wrote:
 Eric S. Johansson wrote:


np. I get this confusion often.
 
 While I have used SR in some testing, I've found that while it's
 passable for prose (and even that, proclamations of 95% accuracy sound
 good until you realize how many words comprise 5%  of your daily typing
 :), it's not so good for code unless you have a very specific
 programming-language+SR designed editing environment...as you've been
 griping.  However, the problem seems not to be PEP-8, but rather the
 inabilities of your SR combined with the failings of your editor.

I've been working with speech recognition for 15 years. I've written something
on the order of 10,000 lines of Python code both as open source and private
projects. I've tried it least two dozen editors and they all fail miserably
because they're focused on keyboard use (but understandable) I get good
recognition accuracy because I train the system and then I let it train me.
 
 For coding, you might want to investigate a tool like Dasher[1] which
 offers an alternate form of input.  It allows for custom
 vocabularies/keymaps if you need, as well as more precise specification
 of a full keyboard (caps vs. mixed-case, specific punctuation
 characters, etc).  The predictive entry should be smart enough to pick
 up previously entered constants/terms saving you entry speed.  It can
 also be driven by a wide variety of pointing devices (mouse, trackball,
 touchpad, head-tracker, gyro-input, etc).

I've tried it, it's quite promising but my hands term are sufficiently that I
can't target accurately. This is a problem for me with mice as well. Maybe these
tiny little spit dot icons and webpages drive me insane because it takes me two
or three tries to put the right spot.

 but still, you would have the basic problem of getting the information about
the code into language model of dasher so it could predict what might be chosen
based on the previous context. It' 80% the same work and, doesn't help those of
us with really bad hands.
 
 You might also experiment with other editors that allow for more
 efficient editing.

I've tried a whole bunch, like I said at least a dozen. They all fail for first
reasons such as inability to access all functionality through keystrokes
(easiest interface method from speech recognition) to virtually no
autoformatting or worse yet, inconsistent autoformatting. The classic example is
auto indentation based on previous lines. Emacs does a relatively right.

I know this is also counter to the Python way but having something marking and
outdent would be really useful so that a vocal driven command to indent or
outdent a block would be practical. Oh, another failure point. Have you ever
tried to selected beach and by voice. I mean I should say have you ever tried to
select a region by voice. Doesn't work very well. Nuance has something called
selective  and say but it only works in very special Windows edit controls. Or,
if you're doing toolkit supports the right signals/events. Nobody does in the
the linux world and it doesn't look like they support them in the Windows world
either.
 
 Hope these give you another option to consider, if SR plus your current
 editor aren't cutting it for you,

maybe we should have a conversation off list about different editors if you
don't mind. I'm certainly open to alternatives but, I do have fairly high
standards and one of them is that ^X^S doesn't crash the editor. :-) I have been
using Emacs for too many years and it is such a reflex.

Another alternative would be to help fix the NaturallySpeaking Emacs gateway
vr-mode.  While it doesn't truly improve the problem, it makes it a little more
manageable.

thank you for your time
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Peter Otten wrote:
 Eric S. Johansson wrote:
 
 MultiWordName  capmulitno-spacecapwordnospacecapname
 very high error rate.  many retries or hand hurting typing.
 
 Can you define macros in your speech recognition software?
 
 capmulticamelwordcamelname
 
 might slightly lower the error rate.
 

Yes it would. I think it would be possible to specify a better grammar however.
In the context of speech engine, if you know how the word is going to be used,
(i.e. it's a method, it's a class, etc.) you can automatically do the
transformation as part of the editors function. You need to know where you are
in the syntax tree and that gives you enough knowledge to do the name
transformation.

When you stop thinking of speech recognition interactions as discrete macros or
magic tricks, you can do a lot to accelerate coding.

Fruit equals pear tree sub branch plus 5

The translator should know that the name on the lval is a variable (type
signature determined later) and is terminated by the word equals (or =). The
system would then apply the appropriate the name transformation. Continue on,
equals would be transformed =, pear tree would be considered a complete name and
based on whether it is a class definition or instance, would be transformed as a
single name. Sub means there's an index here and would put the appropriate
brackets between the expression branch (symbol terminated by plus) and 5 (symbol
terminated by the end of line,

fruit = pear_tree[branch+5]

The next challenge comes in editing. It's fairly simple I would like to say
edit line [1*digits] and put that line in an isolated buffer where I can
edit the English form using all of the Select-and-Say controls.

That should close the cycle from creation through editing.  a small port of the
development cycle.

fyiw, the symbol trandformation code exists and has existed for almost 10 years.
 we need smart editing environments to make use of it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

alex23 wrote:
 Eric S. Johansson e...@harvee.org wrote:
 no, I know the value if convention when editors can't tell you anything about
 the name in question.  I would like to see more support for disabled 
 programmers
 like myself and the thousands of programmers injured every year and forced to
 leave the field.  seriously, there is no money in disability access 
 especially
 for programmers.
 
 Well, if we can't use conventions like uppercasing, camelcasing and
 underscoring, what are you recommending we do instead?

help build a smart editing environment please.
 
 You seem to be asking us to change our behaviour to benefit only
 others, but without offering any guidance on to how that is possible.
 More importantly, shouldn't these modifications to common conventions
 be coming _from_ the community of disabled programmers? I have a hard
 time ensuring that I've gotten accurate requirements from co-workers
 with whom I can actually see and speak, trying to determine how I
 could write my code with accessibility in mind without any established
 means of gauging success just seems impossible.

Extremely valid point. The behavior I'm asking you to change is to consider the
impact choices you make have on people with disabilities. I can only advocate
for disabled programmer since I am one. Have been so for over 15 years. Have
tried to maintain my position as architectural expert only to receive from
venture capitalists and the likes what good are you, you can't know enough to
design our systems because you can't code (yes, real quote). This is not always
the case but enough that it really hurts my economics as well as the economics
of other disabled programmers.

Back in early 2000, I ran a series of workshops on the very issue of programming
by voice. Back then we recognized the necessity for very smart editing
environments which can tell us enough about what each symbol means so that we
can direct the appropriate transformations from a higher-level grammar. I've
introduce concepts such as command disambiguation through reduction of scope.
Other people have added very good ideas with regards to usability and user
interfaces for speech driven environment. Unfortunately, they all are gluons to
an editor and they don't really integrate well because the editor isn't smart
enough.

Heck, have you ever noticed how most Python smart editors can't even indent
properly according to local contexts. Emacs is the only one and even that one
sometimes fails

I can give you guidance as to what needs to be done. Other people can give
guidance but I'm shooting for what may seem unachievable. Work with me a while
and I will guide you as to how it's achievable. Maybe not by you but by someone
we can find. I have lived way too many years with circus tricks. I don't want to
end my life realizing I wasted my time in IT and regretting that I didn't take
up the offer by mass rehab to go in restaurant or hotel management.

one thing you can do to get a feel for out life is to get a copy of Naturally
Speaking standard (100$ staples) and remove/cover keyboard.  write email etc at
first (10h) then try to write pep8 code.  note to anyone who tries this,  I'll
support you in getting DNS running and help figure out any problems.  only cost
is if I tell you to do something like get a new mic, *do it*.

I've lived this works and probably have put more deep thought and 8kloc into it
because I do not accept circures tricks as a way of life.  I want it to work
right and I know how to do it.  I just don't have the hands and hte money to pay
me to do it.

 
 and forgive me if this comes off sounding like a jerk but if
 the collective you don't give a sh** about your fellow programmers, who will?
 
 This isn't intended to be callous, as I feel that the collective
 doesn't care as a whole about _any_ programmers, but isn't the answer
 the very same disabled programmers for whom accessibility is an issue?
 Programming tends to be needs driven (which, admittedly, can be simply
 to pay the bills), and those who have a need tend to be better at
 working out how to address it.

yup  how long will i be before you become disablesd?  maybe not as badly as I am
but you should start feeling some hand problems in your later 40's to early 50's
and it goes down hill from there.  self preservation/interest comes to mind as a
possible motive for action.  I thought 15 years would be enough for somebody
else to push the isssue but no.  if it is going to be, it has to be me.
 
 One possibility may be to approach a group for whom accessibility is
 already a consideration, such as the Gnome Accessibility Project:
 http://live.gnome.org/GAP

not right focus for this project.  tis one needs **deep** python knowledge (gvr
level) and embedding it into an editor.  heck, maybe we need a python
interpreter in the editor to resolve some of the symbol stuff  if we can get
useful data  from incomplete code.

and I'll leave you an editor feature that may be usefull for all

Re: pep 8 constants

[Eric S. Johansson]

Tim Chase wrote:
 It sounds like the issue should be one of making your screen-reader
 smarter, not dumbing down Python conventions.  I don't know what SR
 you're using (Jaws?  Window Eyes?  yasr? screeder?  speakup? 

Naturally speaking is speech recognition (speech in text out)  it is not text to
speech although it does have a pluging for that
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Ethan Furman wrote:
 Eric S. Johansson wrote:

 yup  how long will i[t] be before you become disablesd?  maybe not as
 badly as I am
 but you should start feeling some hand problems in your later 40's to
 early 50's
 and it goes down hill from there.  self preservation/interest comes to
 mind as a
 possible motive for action.  I thought 15 years would be enough for
 somebody
 else to push the isssue but no.  if it is going to be, it has to be me.
 
 For anyone who is still able to use their hands for typing, especially
 if you're beginning to encounter the painful wrists, consider switching
 to a Dvorak layout.  It was a system I was curious about even before I
 needed it, and when I did need it I was able to create the layout in
 assembler (now, of course, it's widely available as a standard keyboard
 layout).  I started noticing the pain in my late twenties (aggravated,
 I'm sure, by arthritis), but with switching to Dvorak the pain left and
 has only very rarely been noticable again.  It will mostly likely be a
 challenge to switch, but well worth it.

a good suggestion but not really addressing the point I'm trying to make of
building a system that would help people more profoundly injured.  for example,
I've tried Dvorak and the act of typing was so painful that I couldn't learn it
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Rhodri James wrote:

 
 Could you elucidate a bit?  I'm not seeing how you're intending to keep
 PEP-8 conventions in this, and I'm not entirely convinced that without
 them the smart editor approach doesn't in fact reduce your productivity.
 

thank you for asking for an elaboration.

Programming by voice has  one goal. enable a disabled person such as myself to
create code by voice with a minimum of vocal or hand damage.

let's use an example. Admittedly, this is a very simple example but hopefully it
illustrates my point

What I dictate is:

from pots is class telephone

What should generate is:

class Telephone (pots):

as you can see, taken from the simplistic expression, we generate the right
pep-8 convention. (I think). This is not the only grammar one can use but, it's
one that comes to mind that doesn't have a lot of dead ends.

So if I was dictating code, it would look something like:

From pots is new class telephone
new constructor
first argument last mile =  between quotes copper

Second argument  fiber delivery date = between quotes when hell freezes over

jump to body
first argument to self
second argument to self

new method construction crew

.
.
.

Telephone fieldwork = telephone second argument fiber delivery date = between
quotes hell froze over

recycled coffee = telephone fieldwork construction crew


-

This is the rough example of what I think should be spoken and what can be
translated to code. What isn't shown is disambiguation techniques. For example,
when a name is said, if it is not unique to the context, then a small pop-up
shows the ambiguities and lets the user choose. Yes your focus shifts rapidly
but you're in the groove of writing code and it's just making your choices
explicit. For example, if telephone wasn't unique because we had telephone pole
and telephone truck as classes elsewhere in the namespace, you would see a
pop-up with each name with a number next to it. You could either click on the
item or say a digit to reinforce the choice. If the class had more methods, when
I say telephone fieldwork that gets translated into knowledge of what class
it's an instance of and all the choices are displayed but at the same time, the
natural language form are shoved into the grammar so you can continue speaking.
If you speak quickly enough, you will see no choice but the grammar will still
be loaded up so that you will get the right thing.

at each stage of the way, names get transformed into the pep-8 form without me
having to say anything special. The environment knows what form it wants and
does the transformation automatically.  I'm surprised people aren't doing this
already for their handcrafted code. It's one less bit of detail you need to pay
attention to.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Steven D'Aprano wrote:

 Why do you think a smart editing environment is in opposition to coding 
 conventions? Surely an editor smart enough to know a variable name spoken 
 as pear tree is an instance and therefore spelled as pear_tree (to use 
 your own example) would be smart enough to know a variable name spoken as 
 red is a constant and therefore spelled RED?

no. I think a smart editing environment should support a coding convention. If
an editor is smart enough to track type and instance information, yes. It should
be able to generate the right strings for symbols. The question is, how do we
get such a smart editor.  as far as I know, none exist and the smart ones so far
seem to be oriented towards hand use and are almost inaccessible to speech.
 
 Sounds to me that your speech environment needs a command to turn 
 capslock on and off, and your problem with PEP 8 is solved:

you haven't used recognition, have you?
 
 x equals caps on red caps off plus three

it also means red is a single utterance. RED is three utterances. You've
just tripled vocal load for single word which means vat you just cut my ability
to work by two thirds. My voice is not as robust as my hands used to be. It's a
coarse tools not designed for engraving fine detail but instead painting
broadbrush strokes. for more you expect a person to say, the less time they can
spend on work effort. This is why I'm advocating a very smart at her with very
high level grammar structure using visual disambiguation techniques.

 Heck, have you ever noticed how most Python smart editors can't even
 indent properly according to local contexts. Emacs is the only one and
 even that one sometimes fails
 
 I use kwrite for editing, and I can't say I've ever noticed a failure.

okay, it fails from a speech recognition user perspective. Put the cursor on the
line and hit the tab key. Insert spaces/tabs in the line of text. Not good for
speech recognition. If  mess of indentation and hit the tab key, it doesn't
automatically indent to the right location. I'll be damned if I'm in the sit
there speaking tabkeytabkeytabkeytabkeytabkey because the error should take
care of it for me and save my voice. Like I said, Emacs does it correctly and
nobody else does as far as I can tell.

 I've lived this works and probably have put more deep thought and 8kloc
 into it because I do not accept circures tricks as a way of life.  I
 want it to work right and I know how to do it.  I just don't have the
 hands and hte money to pay me to do it.
 
 You're using a speech interface, right? You've written about putting a 
 gun to your wrists, said you can't follow PEP 8 because it's not voice 
 safe, and generally given the impression that you can't use a keyboard.
 
 So... just how do you get hte from saying the?

joys of speech recognition.  it was probably either due to a persistent
misrecognition that didn't have the right word and the correction dialog or, I
found the speech recognition error and could not corrected by voice.

and note, there are two errors above that lie would have had to correct by hand.

 If you are using a keyboard to type this post, then surely it's not such 
 a huge imposition to type a couple of words in all caps here and there 
 while you speak the rest of the code?

 if I had typed this post, there would be two orders of magnitude more errors
because of intentional tremors and reduction of targeting accuracy. to give you
Monday an example. Sometimes my hands shake so badly, I cannot eat soup or even
Chile.  I'm unable to use an iPhone except with a great deal of effort.  am the
iPhone with a user with tremors, you activate more than one key about a third of
the time.

 speak x equals /speak type caplock R E D /type speak plus 
 three /speak

I only have about 1000 keystrokes equivalents today in my hands. Where am I
going to use them? Try adding (driving), preparing food, personal hygiene, or
typing PEP-8 compliant code?  What I usually do is I do something like
constant_read = RED at the beginning of my code and well I think you know I'm
getting at. I generate something only I can read which does nobody any good.

 I know that doesn't resolve the issue for those people who truly can't 
 use a keyboard at all, even for a single character, but it's unfair to 
 insist that the only permitted coding conventions are the ones suitable 
 for the tiny minority who, frankly, are going to have problems no matter 
 what coding conventions we have.

You're looking at it from the classical anti-accommodation perspective. Don't
change the convention, give us the tools so we can comply with what the rest of
you do. It's like instead of putting a cut out every street corner, every
powered scooter/wheelchair comes with a antigravity boost that will lift them
over the curbstone. Accessibility belongs with the individual through tools that
take the standard and change it to their needs. While we don't have
anti-gravitational devices, we can make smart matters 

Re: pep 8 constants

[Eric S. Johansson]

Bruno Desthuilliers wrote:
 Brendan Miller a écrit :
 PEP 8 doesn't mention anything about using all caps to indicate a
 constant.

 Is all caps meaning don't reassign this var a strong enough
 convention to not be considered violating good python style? I see a
 lot of people using it, but I also see a lot of people writing
 non-pythonic code... so I thought I'd see what the consensus is.
 
 Most - if not all - of the python code I've seen so far used this
 convention, and I always used (and respected) it myself.

I reject this convention because any form of caps significantly increases vocal
load for disabled programmers using speech recognition through extra utterances,
and degraded recognition.

In my experience, language conventions like this come about because most geeks
generally don't think about disabled programmers and the effect that language
changes will have on them.  I deal by trying to build my accessibility tools as
best I can but handling stuff like pep 8 is hard because it requires a smart
environment that know the meanings of every class, method. or variable so it can
lead the grammar in the right direction. ThenWenUHve names like this.  Cr** in a
stick.  you might as well take a gun to my wrists because that is how much pain
I will be in typing them.  again need *good* editor support for English to name
translation.

so I reject pep 8 because I have no voice safe alternative
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pep 8 constants

[Eric S. Johansson]

Rhodri James wrote:

 Reject away, but I'm afraid you've still got some work to do to
 convince me that PEP 8 is more work for an SR system than any other
 convention.  

Name  capname
higher than normal recognition error rate. can require multiple tries 
or hand
correction

MultiWordName  capmulitno-spacecapwordnospacecapname
very high error rate.  many retries or hand hurting typing.

multi_word_name multiunderscorewordunderscorename
normal error rate (low), can need multiple tries or hand correction

StdlYCps  capsierra tango delta lima capyankee capcharley papa sierra

*** very high error rate *** search and replace for all instances with 
a x_y_z
form name is recommended

If, on the other hand you're trying to convince me that
 *no* convention is preferable, I'm going to laugh hollowly.

no, I know the value if convention when editors can't tell you anything about
the name in question.  I would like to see more support for disabled programmers
like myself and the thousands of programmers injured every year and forced to
leave the field.  seriously, there is no money in disability access especially
for programmers.  and forgive me if this comes off sounding like a jerk but if
the collective you don't give a sh** about your fellow programmers, who will?
should all disabled programmers be dumped on the shelf even their brains are
still good and they have guts to try to work in a field that gave them a life
rearranging injury?

please help.  the disability access you help build may save your own job
someday.  Or, what I need to edit code may make your world better as well.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Andreas Roehler wrote:
 
 with python-mode.el from
 
 http://sourceforge.net/projects/python-mode/

I think there's something wrong with the site because it tells me it's version
1.0 from year 2005.

 Meanwhile I'll reflect a draft addressing your needs.

 there is a rather sizable set of things that could be added to assist speech
during programming.  I'm mostly concerned about the editing aspect of speech
driven programming.

 
 BTW, what about this stuff?:
 
 http://www.cb1.com/~john/computing/emacs/handsfree/index.html

it's interesting but most of it is very low level user interface orientation.
Lo level stuff is relatively easy to implement.  High-level stuff is much more
difficult than the equivalent GUI abstraction.

a narrow channel interface stuff is very interesting  especially if you take
full advantage of the concept.  With regards to programming, a narrow channel
interface would let you choose a relatively low number of big items in the
field of vision and then let you continue to narrow until you can easily operate
on the item of interest.

--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Andreas Roehler wrote:

 IMO Jeremiah Dodds is right. With all the time spent on this discussion, you
 could write the needed function in elisp probably. BTW your request seems
 reasonable. Other python programmers may use it too.

I tried learning lisp about 15 years ago.  even bought a copy of the little
lisper.  after a few days, I gave up because there was just too much learning
curve for the reward.  I know that sounds a touch arrogant but in truth, I'd
prefer to put my energy into building a better bridge between NaturallySpeaking
and linux apps.  bigger pay off helping more people.  with reguard to emacs
changes I hope for and would appreciate it if someone would partner up with me
and help build these (and other) changes into python mode.  I will also point
out that if another IDE is better suited, I'm open to that too.

 Anyway you should tell, which python-mode and which Emacs you use if any.


This is GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-09-08 on LENNART-69DE564 (patched)

and I'm using the python mode that came with emacs.  no version number but...

;;; python.el --- silly walks for Python  -*- coding: iso-8859-1 -*-

;; Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008  Free Software Foundation, 
Inc.

;; Author: Dave Love [EMAIL PROTECTED]
;; Maintainer: FSF
;; Created: Nov 2003
;; Keywords: languages

 
 Andreas Röhler

--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Jeremiah Dodds wrote:

 Eric, I don't have a good readily available solution to what you're
 trying to do, but it seems to me that it would be worth your time to get
 comfortable with elisp, and how it's used in emacs. The emacs
 documentation is pretty good, even if you don't know lisp, and I think
 it would be one of the easiest languages to integrate well with voice
 recognition. I don't think you would need to touch what is commonly
 referred to as emacs internals to do what you want. There's a good
 chance that you'd be able to greatly improve emacs voice-recognition
 support pretty easily in a month or twos time.

for reasons too long to go into, trying to modify Emacs extensively is not a
long-term win.  My requests here were trying to make Emacs somewhat better as a
speech recognition driven editor to get to my final goal, namely building a
bridge between Windows and Linux for speech recognition.  The time or take
modify Emacs to do what I want would be better spent burning my hands and going
directly for the end goal because I believe it would take me less time to get to
where I want.  what I have to learn by myself is how to make a Windows edit
control work from Python, verify speech recognition works with that
configuration, then create a mirror window on linux so what ever is placed into
one window via speech recognition, cut and paste, or even typing shows up in the
other window.  Then, I need to layer a grammar on top of that to enable the
linux side to do application specific cut and paste.  this tool would allow us
to use anything for an editor and not just the one we have just tweaked.

simple  heh.  I may just be better off trying to make enough money so I can pay
somebody to do that.

As I was writing this, it just occurred to me one way to implement the
indentation control.   it would be something like moved to beginning of line,
leave mark, move to end of line, kill region, insert  action specific number of
spaces.

I still think it would be a better solution to determine the indentation of the
previous item that should art hold the right indentation and reuse that amount
but, I will settle for with brute force, bloody ignorance

Yes, that probably will work
--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

John Yeung wrote:
 On Nov 15, 8:50 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
 well, therein lies the rub.  I don't know lisp,
 I don't know Emacs internals let alone python mode.
 
 Unfortunately, neither do I.  Actually, I haven't touched Emacs since
 my college days, and barely remember any of it.  I figured from your
 preference for Emacs that you already did some customization for
 yourself.

Like the vast majority of Emacs users, I cut, paste, and swear.
 
 Is vr-mode a major mode?  If so, I suppose it can't be active at the
 same time as python-mode, which is also a major mode.  I grabbed a
 copy of the code for python-mode (revision 4.75) and while I frankly
 don't understand it, it looks like it has provisions for things like
 finding the beginning of a class or def, which might be usable in
 building the types of commands you want.
 
 Perhaps you should try asking for help from the Emacs community.  To
 someone versed in Emacs Lisp, what you want might be fairly easy.
 
 Another possibility, that I mention mainly because I find it
 interesting, and not so much because I expect it to be the best path
 for you, is Pymacs.  It purports to let you customize Emacs using
 Python instead of Emacs Lisp.
 
 Good luck!  I'm sorry I can't be of more help.

no biggie.  Maybe the real answer is changing the conversation to look for
editors that can run on Windows but edit remotely  like emacs + tramp.

Anyway, here's the speech macros I've worked out so far.

# minimal python and commands

New class= '{ctrl+a}class
[EMAIL 
PROTECTED](object):{ctrl+j}{tab}{ctrl+j}{tab}{enter}{ctrl+x}{ctrl+x}';

new method   = '{ctrl+a}def
[EMAIL PROTECTED](self):{ctrl+j}{ctrl+j}{ctrl+j}{ctrl+x}{ctrl+x}';

new constructor = '{ctrl+a}def 
__init__(self):{ctrl+j}{ctrl+j}{ctrl+j}';

end colon = '{ctrl+e}:';

between single quotes = ''{ctrl+b};
between double quotes = ''{ctrl+b};
between triple quotes = ''{ctrl+b}{ctrl+b}{ctrl+b};
between hex quotes= ''{ctrl+b}{ctrl+b}{ctrl+b};

(ad|add) index   = '[]{ctrl+b}';
next index   = '{ctrl+s}[{ctrl+f}';
last index   = '{ctrl+r}]{ctrl+b}{ctrl+r}[{ctrl+f}';
delete index = '{ctrl+r}[{ctrl+f}{ctrl+s}]{ctrl+b}{ctrl+w}';

go to Line [Number] digit = {esc}xgoto-line{enter}$1{Enter};
go to Line [Number] digit digit = {esc}xgoto-line{enter}$1$2{Enter};
go to Line [Number] digit digit digit = 
{esc}xgoto-line{enter}$1$2$3{Enter};
go to Line [Number] digit digit digit digit =
{esc}xgoto-line{enter}$1$2$3$4{Enter};

go to (end={ctrl+e} | beginning={ctrl+a} | start={esc}m) of line = $1;


--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Aaron Brady wrote:
 You see examples here from time to time that don't follow the rigid C+
 + formatting.  Some examples:
 
 def classmaker( ):
   class X:
 something
   return X
 
 class X:
   class Y:
 something
 
 if something:
   class X:
 pass
 else:
   def X( ):
 pass
 
 Some of these are tricky not dirty; some are both, but you don't want
 to tie your hands prematurely, which is one of my favorite features of
 Python.  Long story short, it can get hairy.

somebody should be called a sick bastard.  :-)

I have never seen these forms and I can see how they are syntactically correct,
possibly useful, and mind bogglingly confusing.  gack,  having said that
though, my gut reaction would be to try to satisfy the usual case first and
suggest that these forms are a sucks to be you moment, use your hands because
we saved them from damage elsewhere. case.  Given enough time I think I could
come up with a fairly regular grammar to express both the ordinary and
exceptional cases.  I'd probably use something somewhat more verbose for the
sick and twisted examples you've given me.

 
 Why aren't you favoring, 'dedent once/twice', 'dedent' repeated,
 'close class, close function, close if, close for'?  I don't imagine
 that saying 'close' three times in a row would be a strain.
 
 If the program is clever, it can learn that 'function' and 'method'
 are synonyms, and you can start to think in terms of both.
 
 You don't need to write 'start method, start class', except as a
 shortcut for spelling the statements out by hand; what type of block
 statement (suite) you are starting is determined by syntax.

I was hoping to avoid this but this is a brain dump on speech or the user
interfaces.  It's evolved over some 15 years of living with speech recognition
and having to take time off because my voice hurts too much to speak in my hands
hurt too much to type.

Hands are robust.  It takes decades of use to make them go bad.  Vocal systems
are fragile.  It takes only one bad day to make them break for weeks.  Once
damaged, neither one fully recovers.

The major problem with using speech recognition with programming is that
keyboards are great at doing fine grained small detail work and lousy at doing
coarse-grained work.  Speech recognition is lousy at doing fine grain detail
work and really good at doing coarse-grained work such as creating large blocks
of text.  This difference in usability is only visible once you have lived in
both worlds.

rule number one: never try to speak the keyboard.

don't ever force a user to control capitalization, concatenation, spelling by
speaking one letter at a time.  Even simple things like Alpha (cap alpha) can
get rather tiring if used a lot.  One of the cruelest things from software
development is mixed case, fractured spelling words such as mixInCntr which I'm
not even going to try to pronounce or spell out.

a more positive way of expressing rule one is allow the user to get what they
want by speaking words in their native language.

Rule number two: never speak small stuff   or why use two or more utterances
when a single one can do

one step up from speaking the keyboard is forcing the user to say the same
command multiple times to achieve a single effect.  For example, if you want to
move to the beginning of the line for the end of the line, you can say move
word left as many times as it takes to get to where you want to be or you can
just say move to start of line.  In the context of the indent outdent control,
I don't really want moving to the right level of indentation for class, method,
function etc..  I want a component to put in the method new class which would
put a class definition at the right place with the right indentation in all the
right components so that I don't have to speak the object hierarchy or triple
quotes (in pairs).  It's all done for me.  But a macro like that won't work
right unless I can put the cursor at the right level of indentation.

another reason for this rule is that you want to really minimize load on the
voice.  Remember, the voice is fragile.  If I can say a small sentence and get a
big effect or something that saves me a lot of work, then that's a win.
Otherwise I might as well burn some hand time and hit the backspace key twice,
speak my macro to do whatever I want, and then clean up the macro from its wrong
indentation.  Yes, it saves my throat and my hands but not as much for either as
a good speech macro would.

Rule number three: be careful with your grammar

Speech user interfaces are broad shallow hierarchies.  GUI interfaces are narrow
and deep.  Speech user interfaces do not readily lend themselves to discovery in
the same way that GUI interfaces do.

Be aware of grammar traps such as similar starting points and homonym arguments.
 Usually it's not too bad but, some words just won't be recognized correctly so
there should be an alternative.  For example, Lennox is how NaturallySpeaking
recognizes linux.  I've been 

Re: special editor support for indentation needed.

[Eric S. Johansson]

John Yeung wrote:
 This is such a fascinating and compelling thread that it has pulled me
 out of lurker mode.
 
 Eric, I would like to say I also admire your initiative, but even more
 so your patience.  You seem to handle comments of all types
 gracefully.

Should have seen me 20 years ago.  lets just say there are few posts I deeply
regret.

 Perhaps it comes from working with speech recognition so much.  I
 imagine that if you are using a speech-based programming environment
 and get frustrated with how stupid it is, and tell it off, you only
 manage to create more of a mess for yourself to clean up.  I think
 most of us who rely on our vision and typing lose our cool more
 easily, partly because the penalty for us is not as great.

Well, if I lose my temper and yell, I lose the ability to work for a day or two.
 Being self-employed, I can't afford that.  This is not to say I don't get
extremely frustrated.  I just rant off keyboard much to my wife's dismay.
Fortunately, my clients mostly see the calm, cool, only slightly rattled at
times consultant that I am.

 Anyway, sorry for being a bit off-topic.  I'm afraid I don't have a
 lot to offer on the topic.  My thoughts as I was reading the earlier
 comments is that Python, by its nature, is extremely flexible and thus
 inherently tough to map to a speech-only interface.  Flatter
 languages would seem better suited, but then they tend to be lower-
 level, thus more verbose, thus what you gain in lack of ambiguity
 might be lost in having to produce more code.

You have hit one of the challenges directly square on the head.   for Chile, one
of the benefits of an extremely flexible language like Python is you can use a
regimented form full of consistent idioms and get your job done.  obviously
these idioms would be the result of whatever tools you use to create code.
 
 If it is to be Python after all, it seems the strategy you have in
 mind is to make the typical patterns as easy as possible, and either
 not allow for the more exotic ones or settle for making them much more
 complicated to achieve.  You also seem to have a pretty clear idea of
 the behaviors you want already.

Yes.  That was one of the rules I should've put into another post.  Make the
common path simple let the unusual path be complex.


 
 I think your best bet is to stick with Emacs.  It's the only editor I
 know of which is almost fully programmable without recompiling, and
 it's available for Windows.  (I am not clear on whether you already
 use Emacs for Windows, or whether you remotely use Emacs on Linux,
 from Windows.)
 
 It does sound like you have to do a bit of Emacs Lisp programming to
 get what you want, but I'd guess that's easier than modifying some
 other editor to do what you want, or modifying the way you issue
 instructions to fit a more visually oriented style.

well, therein lies the rub.  I don't know lisp, I don't know Emacs internals let
alone python mode.  solving the user interface problem by itself is pretty
difficult.  If the universe was granting the wishes, I would hope for a
development partner helping me build these interfaces and integrating them with
vr-mode (Emacs speech recognition mode that has some challenges)


--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

[EMAIL PROTECTED] wrote:

 I still don't understand. 

I elaborated on some of these points in a post to Aaron Brady.  If you missed it
on the list, let me know and I will forward you a copy.

It seems that you want to be able to do:
 END_CLASS  to end the current class.
 
 END_DEF to end the current function
 
 END_BLOCK to end anything else.
 
 This is possible with some emacs lisp but I don't see what this gains
 you over
 BACK BACK BACK
   where BACK sends a backspace to emacs.
   (Actually I'd define an END command which you could give at the
 end of the last line of a block. That would relieve you of the need to
 enter the newline and tab.)
   Yes, it requires a few extra utterances on occasion, but you don't
 have to worry about three new (multi-syllabic) verbs to recognize.
 
  Am I understanding your requirement correctly?

no but it's not your fault.  I have a bad habit of asking for the component that
I need (i.e. gimme a six-inch 8-32 screw) without telling you what I need it for
because  it is extremely clear in my mind what I need the screw for (i.e. barn
door mount for astrophotography).

All of this navigation stuff was driven by the need to embedded inside of a
larger  command invoked through speech recognition.  I have no conditionals
about the environment so I can't tell whether I need to indent once or twice or
three times to make it go to the right place.  Remember, this is a component in
a blind macro (i.e. one that is not aware of its environment) and therefore must
operate correctly with no knowledge of its environment.

Many of the features speech recognition users need from editors are these smart
navigation commands so that one can perform more complex operations without
worrying about indentation or position or things of that nature.

my voice is wearing out.  More later


---eric
--
http://mail.python.org/mailman/listinfo/python-list

special editor support for indentation needed.

[Eric S. Johansson]

in trying to make programming in Python more accessible to disabled programmers
(specifically mobility impaired speech recognition users), and hitting a bit of
a wall.  The wall (for today) is indentation.  I need a method of getting the
right indentation without having to speak a bunch of unnecessary commands.
For example, depth specified by the previous line.  But, frequently you need to
go to a more arbitrary indentation for example the right level of indentation
for a method definition or class definition.  This indentation should be
something you could get by typing/speaking the right command with your eyes 
closed.

For example if I was to give the command new method, I should be able to spit
out a template (contained within the speech recognition environment) and through
a command embedded in the template, force indentation to the right level for
def and then the editor would control indentation for the rest of the text
injection.

I prefer are working in Emacs because that's where I have a lot of my speech
grammars set up but I'm not averse to trying another editor.  The only condition
is that the editor must run a Windows and have remote editing mode (like tramp)
so I can edit on remote machines.

ideas?
--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Almar Klein wrote:
 Hi Eric,
 
 First of all, I like your initiative.

there's nothing like self interest to drive one's initiative.  :-) 14 years with
speech recognition and counting.  I'm so looking to my 15th anniversary of being
injured next year

another initiative is exporting the speech recognition environment to the Linux
context.  In a nutshell, he dictated to application on Windows, it tunnels over
the network to a Linux machine, and will allow you to cut and paste to and from
that Linux application.  I could definitely use some high quality volunteer
talent for this effort.   it would make a huge quality of life difference to
disabled developers.This work would also be usable by the folks in the wine
project who are supporting  NaturallySpeaking.

 I'm not sure if I undestand you correctly, but can't you just
 increase indentation after each line that ends with a colon?
 That's how I do it in my editor. The user would then only need
 to specify when to decrease indentation.

here's an example of the problem:
class foo( object):
def cat(self)
self.x=1
def dog
self.x=2

this is legal Python but it's not what you need 99% of the time.  There is no
cue to the editor to tell it to outdent to give me what I really want which is:

class foo( object):
def cat(self)
self.x=1
def dog
self.x=2

so there should be a mechanism for saying indent the level of the previous
definition.  For what it's worth, this would translate in speech recognition of
arm in vocola pseudocode to

new  method = def indentdef ^(self):{enter}{enter}{enter}srch backwards
and delete ^

which would allow me to create a method definition and put me back at a place
where I can speak the method name.  There's other stuff in these be done like
allowing you to modify various features by names such as adding/deleting
arguments, modifying array indices etc.  If you are not careful, I'll talk about
command disambiguation through scope reduction and the related visual elements
in the working environment.

I really need a job doing this UI stuff.  :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

[EMAIL PROTECTED] wrote:
 On Nov 14, 4:08 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
 Almar Klein wrote:
 Hi Eric,
 First of all, I like your initiative.
 there's nothing like self interest to drive one's initiative.  :-) 14 years 
 with
 speech recognition and counting.  I'm so looking to my 15th anniversary of 
 being
 injured next year

 another initiative is exporting the speech recognition environment to the 
 Linux
 context.  In a nutshell, he dictated to application on Windows, it tunnels 
 over
 the network to a Linux machine, and will allow you to cut and paste to and 
 from
 that Linux application.  I could definitely use some high quality volunteer
 talent for this effort.   it would make a huge quality of life difference to
 disabled developers.This work would also be usable by the folks in the 
 wine
 project who are supporting  NaturallySpeaking.

 I'm not sure if I undestand you correctly, but can't you just
 increase indentation after each line that ends with a colon?
 That's how I do it in my editor. The user would then only need
 to specify when to decrease indentation.
 here's an example of the problem:
 class foo( object):
 def cat(self)
 self.x=1
 def dog
 self.x=2

 this is legal Python but it's not what you need 99% of the time.  There is no
 cue to the editor to tell it to outdent to give me what I really want which 
 is:

 class foo( object):
 def cat(self)
 self.x=1
 def dog
 self.x=2

 so there should be a mechanism for saying indent the level of the previous
 definition.  For what it's worth, this would translate in speech 
 recognition of
 arm in vocola pseudocode to

 new  method = def indentdef ^(self):{enter}{enter}{enter}srch 
 backwards
 and delete ^

 which would allow me to create a method definition and put me back at a place
 where I can speak the method name.  There's other stuff in these be done like
 allowing you to modify various features by names such as adding/deleting
 arguments, modifying array indices etc.  If you are not careful, I'll talk 
 about
 command disambiguation through scope reduction and the related visual 
 elements
 in the working environment.

 I really need a job doing this UI stuff.  :-)
 
 The backspace key in emacs does exactly what you want. Have you tried
 it?

yes and it doesn't work right.  Type this in:

class pet (object):


def cat(self):


if food in bowl:
self.empty = True

def dog(self):


if food in bowl:
self.empty = True
else:
self.bark_nonstop()

 at the end of the method cat, a newline puts you at the left-hand margin and a
subsequent tab  lines you up with self.empty.  Pressing backspace at that point,
terminates the if.  It's reasonable behavior and should be useful when assigned
to the close block utterance.  But remember, my goal is to have a variety of
options for selecting the correct level of indentation with my eyes closed.
Speaking a lot to get a little effect is dangerous to the health of one's vocal
cords and, a text-to-speech output doesn't let you know what lines up with what.

 for what it's worth, in thinking about this problem, try to figure out what you
would say to someone who is slightly deaf and a poor typist to get them to
generate the code you want.  Then figure out what you want to say in the same
situation if you had a bad sore throat.


---eric
--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

[EMAIL PROTECTED] wrote:

  I don't understand. If you don't want to terminate the if, why do
 you hit backspace? What is it that you would like to have happen?

the goal is to make some aspects of indentation behave the same without context
dependency.  this goal exists for many features of programming assistance
because it's a prerequisite for lowering the vocal load for this aspect of
programming by voice

I want three indentation adjustment tools.  Indent to where a class should be,
indent to where a method should be, and outdent n levels (close block
(once|twice|thrice)).  This is probably best shown by example although, I'm not
guaranteeing my example will make it any clearer.  :-)


the current outdent capability conflates multiple outdent events.  The outdent
events are, at a minimum,:

Close block
close method
close class

Another way to look at these events are start method, start class and close
block.  Now using these events, let's compare a use case against the outdent
mechanism.

starting with an example of a previous message,

class pet (object):


def cat(self):


if food in bowl:
self.empty = True

def dog(self):

to start the dog method, after ending the Method, I would need to say something
like:

newline tab key Close block close block delta echo foxtrot dog left paren self
close paren colon...

But if the method ended like:

...

def cat(self):


self.empty = True

def dog(self):

I would only want to use a single close block to outdent.  unfortunately, this
 context dependent behavior is frustratingly wrong when it comes to creating
speech driven macros to enter templates.  it requires user intervention to tell
you how may times to outdent and that's counterproductive at best and physically
damaging at worst for a disabled user.


any clearer?



--
http://mail.python.org/mailman/listinfo/python-list

Re: special editor support for indentation needed.

[Eric S. Johansson]

Aaron Brady wrote:
 On Nov 14, 8:01 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
  I don't understand. If you don't want to terminate the if, why do
 you hit backspace? What is it that you would like to have happen?
 the goal is to make some aspects of indentation behave the same without 
 context
 dependency.  this goal exists for many features of programming assistance
 because it's a prerequisite for lowering the vocal load for this aspect of
 programming by voice

 I want three indentation adjustment tools.  Indent to where a class should 
 be,
 indent to where a method should be, and outdent n levels (close block
 (once|twice|thrice)).  This is probably best shown by example although, I'm 
 not
 guaranteeing my example will make it any clearer.  :-)

 the current outdent capability conflates multiple outdent events.  The 
 outdent
 events are, at a minimum,:

 Close block
 close method
 close class

 Another way to look at these events are start method, start class and close
 block.  Now using these events, let's compare a use case against the outdent
 mechanism.

 starting with an example of a previous message,

 class pet (object):
 
 
 def cat(self):
 
 
 if food in bowl:
 self.empty = True

 def dog(self):

 to start the dog method, after ending the Method, I would need to say 
 something
 like:

 newline tab key Close block close block delta echo foxtrot dog left paren 
 self
 close paren colon...

 But if the method ended like:

 ...

 def cat(self):
 
 
 self.empty = True

 def dog(self):

 I would only want to use a single close block to outdent.  unfortunately, 
 this
  context dependent behavior is frustratingly wrong when it comes to creating
 speech driven macros to enter templates.  it requires user intervention to 
 tell
 you how may times to outdent and that's counterproductive at best and 
 physically
 damaging at worst for a disabled user.

 any clearer?
 
 Greetings, Eric, great to read your posts.
 
 You'll acknowledge that there is no deterministic way to add newlines
 to a string of Python code.  That is, the following are all equivalent
 up to whitespace, syntactically correct, and distinct.

you meant indentation instead of newlines?

you are right all of those examples are syntactically correct and distinct.
This is why shifting the target of that to instead of specifying an outdent as
the mechanism for achieving proper indentation, instead naming the type of
indentation and using that as the cue for how far to indent.

examples:

Class indent: indent as far as the previous (non-commented, not in string) class
definition.  If there is no previous class definition, indentation is set to 
zero.

Method indent: indent as far as the previous (non-commented, not in string)
method.  If there is no previous method definition, search for the previous
class definition and indent by the number of spaces as determined by the editing
environment.  if there is no previous class definition, indentation is set to 
zero

nested indent: bad name but, it's midnight.  Indent according to the previous
line.  Alias for normal indentation (automatic, not bound to any particular
grammar).

function indent: indent set to zero.

using these definitions, most of the time indentation will be deterministic and
achieved using a single utterance.


 def cat(self):
 
 if food in bowl:
 self.empty = True

method indent

 def dog(self):
 ...
 
 def cat(self):
 
 if food in bowl:
 self.empty = True

end block

 def dog(self):
 ...
 
 def cat(self):
 
 if food in bowl:
 self.empty = True

nested indent

 def dog(self):
 ...
 
 def cat(self):
 
 if food in bowl:
 self.empty = True

function indent

 def dog(self):
 ...
 
 def cat(self):
 
 if food in bowl:
 self.empty = True

nested indent

 def dog(self):
 ...
 
 You noticed that the second-to-last one uses a variable that isn't
 guaranteed to be defined.

yes, I've seen at least a couple exceptions from that type of situation.

 
 You instructed the audience to imagine reading with its eyes closed.
 I imagined concluding the self.empty= True line, saying 'close
 block' aloud, and hearing a verbal prompt in response.
 
 'Close block def or block if?'

that's a good catch.  If the system has to ask me something to clarify, it's
telling me that I screwed up.  It's also forcing me to think about something
other than the task at hand and say something I shouldn't have to say.  Another
thing to think about is the cognitive overload a developer experiences when
using speech recognition.  Normally, you're thinking about the context within
the project, the code, the IDE/editor and now add to that, saying the right
command while thinking about how to correct your code when the inevitable
misrecognition happens and triggers a sequence of IDE

Re: I built a nice html templater!

[Eric S. Johansson]

Steve Holden wrote:
 Tim Roberts wrote:
 Derick van Niekerk [EMAIL PROTECTED] wrote:
 Ok - so it's not really an awesome achievement and only handles basic
 templating needs (no loops and other programming constructs) but maybe
 someone will find it useful.
 sarcasm
 Sure, that's what the world needed.  We didn't have enough Python HTML
 templaters already.
 /sarcasm

 Did you take even 3 minutes to look for a solution before you wrote this?
 There is even a nearly identical solution in the Python cookbook.
 
 While I agree it was a little naive to expect a huge amount of interest
 I think there's educational value in building a templating system of
 your own. Sarcasm id the lowest form of wit, and there's no real need
 for it here. You'd have been better saving your ire for someone who
 really deserves it. Sadly there are plenty around.

my replication of work was motivated by a very different need.  I built a web
framework that is friendly to speech recognition users. It uses plain English
words and very little special punctuation.  the internal CGI environment is also
very simple in case you have a memory deficit and need to refresh your memory on
the functionality between uses.  Almost every HTML template system, and web
framework I've seen look like they are designed to exclude disabled users.
Special punctuation, special spacing rules, non-English character sequences,
complex APIs, and lots of APIs say to the world no disabled need apply.

Before you protest and say that disabled users are a special case, remember that
almost everyone becomes disabled as a result of aging or accident.  a simple
broken wrist or arm could keep you from doing your job.  arthritis and other
joint disorders will make keyboards something you cannot stand the touch.  you
will not escape needing some form of accessibility tools if you decide to keep
using computers.

Now you're faced with a choice.  Do you want to design and build things that you
will not be able to use at some point or do you want to build systems that can
be used by you now, and you in the future.  let me play from personal
experience, it's far easier to build accessible systems before you need them
than after.
--
http://mail.python.org/mailman/listinfo/python-list

gdbm threadsafeness

[Eric S. Johansson]

how thread safe is the gdbm module?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode conversion problem (codec can't decode)

[Eric S. Johansson]

 
 Almost there: use string-escape instead; it takes a byte string and  
 returns another byte string in ASCII.

perfect.  Exactly what I wanted.  thank you so very much.
 
 I really don't care about the character set used.  I'm looking for a  
 matched set
 of operations that converts the string to a seven bits a form and back  
 to its
 original form.
 
 Ok, string-escape should work. But which database are you using that can't  
 handle 8bit strings?

I tripped over some bugs with pysqlite in terms of what it should and should 
not 
accept as text.  Now that I've gotten through my particular crisis I need to 
sit down and generate a test case so the problem can be fixed.

thanks again.

---eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Unicode conversion problem (codec can't decode)

[Eric S. Johansson]

I'm having a problem (Python 2.4) converting strings with random 8-bit 
characters into an escape form which is 7-bit clean for storage in a database. 
Here's an example:

body = meta['mini_body'].encode('unicode-escape')

when given an 8-bit string, (in meta['mini_body']), the code fragment above 
yields the error below.

'ascii' codec can't decode byte 0xe1 in position 13: ordinal not in range(128)

the string that generates that error is:

brReduce Whát You Owe by 50%. Get out of debt today!brReduuce Interest  
|V|onthlyy Paymeñts Easy, we will show you how..brFreee Quote in 10 
Min.brhttp://www.freefromdebtin.net.cn

I've read a lot of stuff about Unicode and Python and I'm pretty comfortable 
with how you can convert between different encoding types.  What I don't 
understand is how to go from a byte string with 8-bit characters to an encoded 
string where 8-bit characters are turned into  two character hexadecimal 
sequences.

I really don't care about the character set used.  I'm looking for a matched 
set 
of operations that converts the string to a seven bits a form and back to its 
original form.  Since I need the ability to match a substring of the original 
text while the string is in it's encoded state, something like Unicode-escaped 
encoding would work well for me.  unfortunately, I am missing some knowledge 
about encoding and decoding.  I wish I knew what cjson was doing because it 
does 
the right things for my project.  It takes strings or Unicode, stores 
everything 
as Unicode and then returns everything as Unicode.  Quite frankly, I love to 
have my entire system run using Unicode strings but again, I missing some 
knowledge on how to force all of my modules to be Unicode by default

any enlightenment would be most appreciated.

---eric


-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: anydbm safe for simultaneous writes?

[Eric S. Johansson]

chris wrote:
 I need simple data persistence for a cgi application that will be used
 potentially by multiple clients simultaneously.  So I need something
 that can handle locking among writes.  Sqlite probably does this, but
 I am using Python 2.4.4, which does not include sqlite.  The dbm-style
 modules would probably be fine, but I have no idea if they are write
 safe (I have no experience with the underlying unix stuff).  Any tips
 appreciated.

the often repeated answer that you need locking is correct but an incomplete 
answer.  it really depends on which DBM you are using.  If you are using a 
fairly recent bsdbm (a.k.a. sleepy cat) it does have the kind of lucky needs to 
fairly complex transactions.  Unfortunately, the API is a sufficiently 
unintelligible that it will take more than an afternoon to figure out how to 
even start to use it.

gdbm is a nice DBM that permits single writer/multiple readers.  If you open a 
DBM for read, any writer blocks.  You open it for read and some times multiple 
readers can get in but not always (or at least that's the way it seems here in 
practice).  when the DBM is busy, you will get an exception with an error value 
of: (11, 'Resource temporarily unavailable').  Just busy wait until this 
exception goes away and you'll get access to the DBM file.  Yes, this 
officially 
sucks but at least it's a workaround for the problem.

another way to solve this particular problem with DBM files is to stick inside 
a 
Pyro daemon.  Performance won't be too bad and you should be able to get it 
working relatively easily.  I will warn you that the RPC model for Pyro does 
take some getting used to if you're familiar with more traditional RPC 
environments.  Once you wrap your head around the Pyro model, it's pretty nice. 
  If you want, I can send you a copy of my Pyro daemon I use to wrap a DBM so I 
don't have to worry about multiple processes accessing the same DBM.

the one thing that really bothers me about the DBM interfaces is that the two 
main DBM's are really quite full-featured but the documentation presents a very 
sketchy description of what they support and how.  As a result, I suspect that 
DBMS don't get used as often as they could and people are pushed into more 
complex databases because they don't understand what DBM's are capable of.

Other folks have recommended some form of SQL and while SQL light is a very 
nice 
small database, personally, I find SQL unintelligible and I have lost more days 
than I care to think about trying to figure out how to do something in SQL.   
As 
result, I tend to go more towards databases such as metakit and buzhug 
(http://buzhug.sourceforge.net/).  the former is like gdbm and only handles a 
single writer.  It's really intended for single process use but I don't know if 
you can put it in a Pyro controlled deamon.  The latter looks pretty 
interesting 
because the documentation implies that it supports concurrent access on a per 
record level (menu item: concurrency control).

Given that I'm currently replacing a DBM for very much the same reason you are, 
I'm going to try using buzhug rather than facing SQL again.  I would be glad to 
compare notes with you if you care to go the same route.  Just let me know off 
list.

I wish you the best of luck in your project.

---eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Backup Script over ssh

[Eric S. Johansson]

Gabriel Genellina wrote:
 En Wed, 27 Feb 2008 13:32:07 -0200, Christian Kortenhorst  
 [EMAIL PROTECTED] escribi�:
 
 But there is no rsync for windows without using cygwin
 
 That's no big deal; rsync doesn't require tons of libraries, just  
 cygpopt-0.dll and cygwin1.dll. See this page:  
 http://www.brentnorris.net/rsyncntdoc.html
 If you prefer a nice GUI around it (mmm... not so nice actually :) )  
 http://www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp
 

windows rsync sans gui

http://www.itefix.no/phpws/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=6MMN_position=23:23

or google cwrsync

I use in conjunction with rsnapshot for backing up xp and vista machines

--- eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is Python really a scripting language?

[Eric S. Johansson]

John Nagle wrote:
  Yes.  One of the basic design flaws of UNIX was that interprocess
 communication was originally almost nonexistent, and it's still not all that
 great.  It's easy to run other programs, and easy to send command line
 parameters, but all you get back is a status code, plus console-type output.
 
  The UNIX world might have been quite different if, when you ran a
 subprocess, at the end you got return values for the command line
 parameters (argv/argc) and the environment back.  Then programs
 would behave more like big subroutines.  But all you get back
 is a status code, so running programs from a script tends to be
 a somewhat blind one-way process.

not if you use pickle.  the example below is not complete and I need to fix it 
to not raise privileges if name is None but it is complete enough to give you 
an 
idea.   the parent uses spawn_sub to send data to/from child.  child uses 
read_input/write_output to move data from/to the parent.  I should convert it 
to 
something like json to make it possible to work with other languages.



class process_handler (object):
 def read_input (self):
 get the input from standard and can convert to Python
 object

 pickle_input = sys.stdin.read()
 real_object = pickle.loads(pickle_input)
 return real_object

 def write_output (self, real_object, err_object = None):
  errors to standard error, output to standard out, objects
 in pickled form

 pickled_error = pickle.dumps(err_object)
 sys.stderr.write(pickled_error)

 pickled_output = pickle.dumps(real_object)
 sys.stdout.write(pickled_output)

 def spawn_sub(self, cmd_list,stuff_in, run_as=None):
 command_list is just that, a list of the command and all of its 
arguments.

stuff_in is the string sent to the sub process via standard in

stuff_out is the string returned from the sub process via standard 
out

error_stuff is the string returned from standard error.

stuff_out and error_stuff are returned as a tuple

run_as is the user name you want to run as.  This uses a trick with
sudo to enable privilege escalation

this is an example of a bad escalation specification in
sudoers.  It's sometimes bad because it doesn't restrict
who can use the command.  If you are trying to run a
program as a common but different user (such as www-data
because you need to share a database with a Web server, the
badness is measured in terms of what data said program can
change or reveal.  If the access cannot be exploited, then
they should be okay.  Unfortunately, in almost every
circumstance where privilege escalation techniques are
useful, there is an exploit waiting to happen.

be careful.

ALL ALL = (www-data) NOPASSWD: /home/esj/vacation_scan.py
 
 # syslog.syslog(subprocess args %s%str(cmd_list))
 p = subprocess.Popen(cmd_list, shell=False, bufsize=4000,
  stdin=subprocess.PIPE,
  stdout=subprocess.PIPE,
  stderr=subprocess.PIPE,
  close_fds=True)

 # always pickle what passes through even if it is a None
 pickle_in = pickle.dumps(stuff_in)

 (pickled_output, pickled_error) = p.communicate(pickle_in)

 stuff_output = pickle.loads(pickled_output)
 error_stuff = pickle.loads(pickled_error)
 # syslog.syslog( stuff_output %s, error_stuff %s%( stuff_output, 
error_stuff))
 return (stuff_output, error_stuff)

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is Python really a scripting language?

[Eric S. Johansson]

John Nagle wrote:
 Eric S. Johansson wrote:
 John Nagle wrote:
  Yes.  One of the basic design flaws of UNIX was that interprocess
 communication was originally almost nonexistent, and it's still not 
 all that
 great.  It's easy to run other programs, and easy to send command line
 parameters, but all you get back is a status code, plus console-type 
 output.

  The UNIX world might have been quite different if, when you ran a
 subprocess, at the end you got return values for the command line
 parameters (argv/argc) and the environment back.  Then programs
 would behave more like big subroutines. 
 not if you use pickle.  
 
  That assumes both programs were designed to intercommunicate that way.
 Most UNIX applications aren't.  There's no accepted standard on how
 UNIX programs should intercommunicate, other than the 1970s technology
 of piping human-readable strings around.  Yes, there are marshalling
 systems, of which Python's Pickle is one.  But there's no standard
 interprocess call system.  And Pickle is only a marshalling system,
 not a full IPC system.  There's no resource location system. (Where's
 the browser process? Where's the database back-end?)

I apologize if this gets you a bit cranky but I think you're conflating a few 
interprocess communications issues.  I know I didn't fully articulate what I 
had 
been doing and I apologize.

As your description above shows, there are multiple types of interprocess 
communications.  My example shows how it's possible to make two cooperatively 
designed programs act as if they are communicating via a remote procedure call 
across a parent-child process boundary.  Yes, other marshaling systems may be 
useful across multiple language environments.  I wasn't concerned about that.  
I 
had to get a job done so I used pickle.

when it comes right down to it, IPC systems are hard to do right. 
http://birrell.org/andrew/papers/ImplementingRPC.pdf is a pretty good reference 
for how to do it for our PCs.  Also, the definition of right, depends on the 
communications medium used.  For example, if the application is using pipes 
with 
sub processes, what I wrote is a workable implementation especially if you need 
to deal with privilege escalation.  If you're talking over sockets or some 
equivalent communications channel, then yes, you need some form of resource 
location as well as handling methods exposure and resolution on both server and 
client side.  But even if you have all of these items, you're still not out of 
the woods.  There's a fundamental issue of reliability in the face of this 
complexity.  I've written some code with psycho and, this is not meant as a 
slam 
against psycho, but the resource location subsystem was causing more problems 
than I care to deal with so I eliminated it from my project by hard coding 
certain essential bits of information.


 
  Both Gnome and OpenOffice use CORBA. But they use incompatible versions,
 and you have to have a CORBA ORB running for that to work.  There's
 OpenRPC, which isn't used much any more.  There's System V IPC, which
 isn't used much.  There are XML-based systems. There's REST, JSON, and
 similar approaches.  None of these approaches ever got the kind of
 widespread use that OLE did in the Microsoft world.

All of these examples are great examples of overly complex IPC mechanisms. 
while the complexity may be necessary if you are going to handle 99% of all 
cases, the complexity makes it more difficult to document functionality in a 
comprehensible way.  complexity reduces take up because it's too much work to 
figure out and use especially if it's a one-shot job.  I believe it's fairly 
clear that a very simple IPC mechanism could handle a significant majority of 
project needs while making IPC functionality accessible to more developers.  
XML 
RPC almost achieves that except for its functional call orientation.  But, I'm 
not a waste any more breath on what ifs because there's way too much 
technological alpha male behavior to ever build a simple common infrastructure 
component for IPC (or almost any other widely usable components for that 
matter).

---eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using Python To Change The World :)

[Eric S. Johansson]

[EMAIL PROTECTED] wrote:
 Hello, I'm a teen trying to do my part in improving the world, and me
 and my pal came up with some concepts to improve the transportation
 system.
 
 I have googled up and down for examples of using python to create a
 city street but I can not find any.

http://www.gis.usu.edu/~sanduku/public_html/dissertation/outline/node23.html

Automobile traffic has a very extensive body of literature involving 
simulation. Most people in the industrialized world deal with automobile 
traffic 
on a daily basis, and many studies are funded annually to alleviate existing or 
potential traffic problems. Several academic journals are dedicated exclusively 
to automobile traffic dynamics, new textbooks on the subject are published 
regularly, and the number of articles published each year dealing with 
automobile traffic number in the hundreds.


while they may not be in Python, I'm sure you can find modeling systems to do a 
you want to do for far less effort than it would take to re-create them from 
scratch.


-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Looking for a good Python environment

[Eric S. Johansson]

[EMAIL PROTECTED] wrote:
 Hey, I'm looking for a good Python environment. That is, at least an editor
 and a debugger, and it should run on Windows. Does anyone have any idea?

I've been looking for the equivalent although I want the IDE to run on Windows
and to be able to edit/debug/bzr files on a remote system (linux in VM or 
remote 
physical hardware).

Solutions that I've explored are:

Network filesystems (Samba, NFS)
Emacs plus tramp
eclipse plus remote file access
remote system IDE, local display with X11
local editor plus unison

Here's how they failed:

Network filesystems always fail because they get ownership and permissions 
wrong.  No matter what you set the mapping to, it's almost always wrong for 
some 
part of the system.  It's made worse because setup .py does not make it easy to 
force permissions and ownership to what you want them to be (afaik).   this 
forces the use of an ad hoc script to enforce permissions and ownership after 
running setup.py.

using this configuration, it is possible to hibernate your Windows machine but 
only if you manually restart your remote filesystem connections before trying 
to 
do anything with your IDE.

Emacs plus tramp is the best solution so far albeit somewhat fragile.  It's 
moderately difficult to jump into the right point in the filesystem although 
this may be an artifact of trying to use speech recognition for this task. 
another annoying problem is forcing Emacs to use UNIX format text files.  I 
know 
I just need to RTF but I haven't gotten around to it yet.

Emacs plus tramp is also the easiest to hibernate as it does not use persistent 
connections to remote machine but if the remote host isn't available when you 
try to access a file via recentf, you lose the reference to the file and need 
to 
type/speak the path in again.

Eclipse has been an unmitigated disaster for me.  It's fat, it's heavy, it 
pushes all of my other applications out of virtual memory and then I need to 
wait 10s of seconds when I switch.  I can't figure out which components of the 
bag of parts I need and easy eclipse is too old to use the remote file system 
access extension.  blech.

Using X11 for local display is great if the remote machine is local and you're 
not paging out to virtual memory.  most common problem is that the local X11 
display loses track of local Windows and you end up with this graphic ink blot 
on the screen that never quite goes away until you restart X11 and all the 
other 
applications through it.

with the X11 solution,  you cannot hibernate your host machine because the 
persistent connections break and cannot be restarted.

local editor plus unison sort of, kind of works.  Yes, you can edit all your 
files and replicate them on the target machine.  Ownership and permissions are 
broken.  There is a problem with UNIX versus DOS file format but once you force 
the editor to do the right thing, the format is right on the remote side.  It's 
clumsy but it does have the advantage that if you make changes on the remote 
system when debugging, those changes are replicated back on your editing house.

As for debugging, personally, I just use winpdb everywhere and just suffer with 
bad X11 connections.

One additional factor raised by split machine operations is how do you organize 
your files?  Do you have different repositories on different machines or do you 
have a single repository on your editing host and look to some form of 
replication for updates across one or more machines?

it's an interesting set of problems.  Today, I just muddle along as I don't 
really see a good solution.  I'm hoping I'll be proven wrong and find a 
solution 
that will make my life easier someday.

-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
http://mail.python.org/mailman/listinfo/python-list

setup.py question

[Eric S. Johansson]

I have an environment where I have a bunch of data files or use would like 
Python application.  I want to use the data_files specification of set up to 
distribute those files.  But I also need to change ownership and permissions.  
I 
know there's some way to do this because I've done it once before but I can't 
find how I did it and I can't find how to do in the documentation.  Any 
pointers 
on how to set ownership and permissions for files listed in the data_file 
section of a setup call would be wonderful.  For what it's worth, I have 
modified install(_install) methods to handle set gid wrappers.  It's a cool 
abuse of setup.  :-)

thanks

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IDE for Python

[Eric S. Johansson]

Ben Finney wrote:
 Stefan Behnel [EMAIL PROTECTED] writes:

 Neither? Emacs is both editor *and* IDE.

I think of it more as feature full but somehow unsatisfying.  For example, for 
those of us PRDs ( Politely Referred to as Disabled) who are trying to program 
by voice could use an enumeration of all symbols visible from a cursor on 
outward through method, class, and file scope, etc.  then we can take we can 
speak symbols and make them pronounceable as well as synthesize a grammar so 
that one can refer to symbols in the object hierarchy by absolute paths as well 
as individual symbols.

it's just an idea at this stage but it could be fun to see how well it would 
work in real life

-- 
http://mail.python.org/mailman/listinfo/python-list

unifying many packages under one name

[Eric S. Johansson]

I have a collection of packages and I want to put them under single unifying 
name.  my goal is to reduce namespace pollution and make all these packages 
accessible as 'import vvv.aaa'. In more detail, if I have packages 'aaa' and 
'bbb', what do I do to put those packages under unifying name such as 'vvv'? 
the only way I can see to do it is to create 'vvv' as a directory with its own 
__init__.py but I'm not sure that were work right either.


thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

in a bit of a quandary about an SMTP receiver

[Eric S. Johansson]

I have wasted way too much time on this problem already and I'm hoping it's 
just 
that I'm missing some bit of information somewhere.

I need an SMTP receiver so I can handle filter requests from a postfix mail 
server.  the asyncore version works fine for one request at a time.  This is 
great except I need to process bursts of 10 to 15 request per second and 
individual requests sometimes run 0.5-10 seconds per request.  most of the 
filter work is either network or database query limited so queuing up a bunch 
of 
requests and handling them in parallel should work fine.

I have tried using a threaded version od smtpd.py but, I'm not convinced it's 
running any more than one thread at a time and properly splitting off threads 
at 
the right time.  Maybe my test case was inadequate but, high level of no 
confidence there.   If someone can show me that I'm wrong, that would be 
wonderful.

starting point: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440690

Another recommendation was twisted as a foundation for building a new server 
but 
it would take me as long to build a new server from scratch using ordinary 
sockets as it would take me to learn how to use twisted.  the documentation 
leads me to two conclusions.  First is that twisted is a career, not something 
for getting a job done.  This is not meant to be disparaging but reflects three 
factors.  A steep learning curve, minimum amount of knowledge necessary to get 
a 
job done, and persistence of that knowledge once the job is done especially if 
you don't live in the twisted environment all the time.  The second is that for 
someone like me (speech recognition driven) twisted is pain.  Pain, pain, pain 
from way too much hand use caused by bumpy cap names.  normally, this shouldn't 
affect anybody else but for me, it is a serious disincentive.

Having said this, I have no other real objections to twisted and if someone 
wants to help by volunteering to build an SMTP receiver capable of being used 
as 
postfix filter interface, I would be glad to work with them.

The last option is building a new smtp filter around SocketServer but again, 
there is a serious lack of documentation making it another career option.

I am really stuck.  I can't go forward and there really isn't any other 
solution 
than I can see.  If there was some way to use the baseline asyncore code to 
handle multiple simultaneous requests, I could just do all my work another 
process but I'm not seeing how I can  context switch between multiple 
connections/connection states using asyncore as it stands today.

Help?

-- 
http://mail.python.org/mailman/listinfo/python-list

Python editors again (it's not the same old request)

[Eric S. Johansson]

I upgraded to version 9.5 and all of my tools which enabled me to program by 
voice in Emacs are broken.  it's one of those dagnabbit a moment's of life.

What I am looking for is a Windows based Python Smart editor that uses specific 
rich text edit controls as specified here:

http://knowledgebase.nuance.com/view.asp?tnID=5104sQuery=4247

Quoting from the article:

A window is considered standard if its window class name is one of the 
following:

Edit

RichEdit

RichEdit20A

RichEdit20W

RichEdit50W

If the name is not one of those, then an edit control is still considered 
standard if its window class name and window styles are similar to those of 
standard edit controls.



There is some other stuff in there about other classes that may be able to work 
in so far, they haven't yield anything useful to me.  Doesn't mean I won't keep 
trying but it's more than a tad frustrating trying to root out some of these 
magic numbers.  Any help would be most appreciated.  Actually, it would be 
really nice if wxwindows  and gtk used the standard classes underneath so 
accessibility would be there semiautomatically on Windows but that's a 
different 
conversation.

-- 
http://mail.python.org/mailman/listinfo/python-list

Python in the Mozilla world

[Eric S. Johansson]

this morning I was looking at Python and XUL.  I was impressed by the very 
interesting projects that were happening around 2005 but it seems like they 
have 
all died.  Integrating Python at the Mozilla was also very intriguing as it 
held 
the promise of eliminating JavaScript for extension development (yaaa).  But 
that seems to have died as well.  In fact, it looks like that almost all of the 
alternative languages for browsers have died for lack of interest or something. 
  I was really looking forward to pyax

As a result, I started looking at Python generating JavaScript and I know there 
is pypy but is that really something one can count on or is it more a good 
demonstration of technology?

Just wondering.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python editors again (it's not the same old request)

[Eric S. Johansson]

Chris Mellon wrote:
 wx does (in large part), but most likely the problem is that the rich
 text control used in most editors is not the win32 rich text control,
 but instead Scintilla, which is designed for source editing and is
 much easier to use. Very few editors, of any kind, use the native
 win32 text control for source highlighting.
 
 wx does have (some)  support for the accessibility features in win32,
 you might post a feature request on the wx bug tracker to add them to
 the wx platform bindings for Scintilla.
 
 The main reason editors don't use the standard control is for syntax
 highlighting and perhaps folding and margins, though, which I'm not
 sure are especially valuable to you. What kind of features makes a
 Python editor 'smart' for someone who's coding with a screen reader?

what you said makes wonderful scents.  Thank you for explaining.  Now, if you 
read the application note, after the list of rich text objects they expect, 
they 
described a fuzzy in between state where if you tweak the configuration, you 
get 
Select-and-Say but you know a whole bunch of things about the objects etc. 
would 
you be so kind as to read over that part of the application note and tell me if 
it applies to any of the Scintilla objects for text display?

I'm glad to hear you have some of the extensibility features.  Some are better 
than none.  There is an event coming up in the next few weeks that will trigger 
a need for accessibility interfaces on the Linux side.

Well, I'm not sure about a screen reader but I'm using speech to text.  My 
apologies if I wasn't clear (reading back, I see a couple dropouts that I 
didn't 
catch and change the meaning significantly. As a brief aside, one of the 
classic 
problems is can versus can't.  Which leaves you very much in doubt if someone 
writes I can go to bed with you.  Is it a misrecognition or an expression of 
desire?  only your natural language processing will know for sure:-)

there's a whole hierarchy of needs.  The voice coder project has done some nice 
work in that domain.  For me, the fundamental level is the ability to correct 
and replace without error.  I should be up to select a phrase or set of words 
and have that region highlighted properly so I can operate on it.  I should be 
able to delete the last utterance and not have it count wrong.

the next level (that the voice coder project handles) is the ability to dictate 
a word and depending on the context or its knowledge of symbols, generate a 
code 
symbol be a bumpy cap or joined with underscores or some combination thereof. 
Additionally, David Fox, primary developer, did some  absolutely  gorgeous 
worked with correction mechanisms.

The next level up would be contextual awareness of variables within your scope 
so that when you dictate something, you don't have to have a big collection of 
static symbols.  You create them dynamically based on where you are located in 
your code, which file, and what modules you include.  This last one is going to 
be difficult.  May not show up for a few years.

But all I'm asking for right now is simple Select-and-Say as outlined in that 
application note from nuance.  I can say _ with English words on either side 
and the code will work.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python in the Mozilla world

[Eric S. Johansson]

Steve Howell wrote:
 --- Eric S. Johansson [EMAIL PROTECTED] wrote:
 I would not completely give up on the idea of Python
 itself running in the browser, although obviously
 there have been lots of false starts.
 
 http://www.voidspace.org.uk/python/weblog/arch_d7_2007_04_28.shtml#e702

interesting.  Very interesting but I suspect the message is don't hold your 
breath but don't give up hope.


 Regarding using Python to generate JavaScript, I just
 get nervous any time code generation happens.  While
 JS is not a perfect language, it's tolerably close to
 Python in lots of cases, and if you have a Python back
 end, you can feed it JSON very easily from Python.

personally, that doesn't bother me.  I lived with Cfront to the point where I 
understood the output and was filing bug reports on it.
 
 To the extent that JS code incorporates lots of
 cross-platform idiosyncracies, I still think the
 strategy there is to dig into JS and learn how to
 encapsulate those within JS itself.

pick a toolkit and live with it.  Most of the reason why I'm looking for a 
JavaScript backend is because well, my hands and speech recognition don't work 
well with JavaScript.  So, if I could just generate JavaScript from Python I 
would be happy.  I especially would be happy if I could create Thunderbird or 
Firefox extensions using Python because the current model is so 
incomprehensibly 
documented.  What I need to do would take maybe a day if you're distracted but 
to spend some number of weeks learning how to accomplish that day's effort is a 
pretty low return on investment.  I don't see a career in plug-in writing is 
something worth chasing.  Anyway, that's my opinion and I'm living with the 
consequences.  :-)


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python in the Mozilla world

[Eric S. Johansson]

Steve Howell wrote:
 --- Eric S. Johansson [EMAIL PROTECTED] wrote:
 http://www.voidspace.org.uk/python/weblog/arch_d7_2007_04_28.shtml#e702
 interesting.  Very interesting but I suspect the
 message is don't hold your 
 breath but don't give up hope.

 
 Exactly. :)

This is one of those things where a foundation, with a smart person for making 
really simple things should get some money from the foundation and get it 
built. 
  I don't know about you but when I have a customer asking for a modification 
to 
an open source project, I respond much more quickly when they say here's your 
budget.  Although sometimes the budget is so small, I'm tempted to find 
someone 
in Romania or other cheap locations and stretch my dollar as far as possible. 
I'm certainly tempted to do that on my own projects.

 Well, that sounds pretty reasonable, and I'm sure a
 lot of folks are in a similar quandary.  They need to
 use JS to a certain degree, but nobody wants to make a
 career out of plug-in writing, etc.  (I certainly
 don't!) It wouldn't surprise me that there are lots of
 Python programmers who do JS maybe 5% of the time, and
 many of those folks can't justify the effort to go a
 bit deeper on the learning curve, create more of a
 community, etc.
 
 I guess I'm not helping you much other than to
 commiserate, but can I ask you to what extent you've
 looked into existing Python web frameworks, to see how
 much code there is out there that you could mine for
 your projects?  I stumbled on some pretty high quality
 Python code a few weeks ago that amounted to
 Javascript helpers, but now I can't find it for the
 life of me.  But it's out there...

actually, I've looked at some toolkits and they look really nice if I had a 
week 
to spend on them.  I'm trying to figure out how to fit something like these 
toolkits into my own framework (yes, another web framework.  This time, with 
accessibility in mind.  The motto is, learn in the morning, use in the 
afternoon, go home at night.)  But figuring out how to fit in Ajax type stuff
in the same way that the HTML has been simplified for 80% of the uses, requires 
a deeper knowledge of Ajax than I have.  And I'm unlikely to acquire in the 
near 
term unless I have a partner in crime to show me common idioms.

which is a pity because I have in mind a tool which could help writers for 
online comments.  Most of the current common techniques involve comments to a 
log entry or in some cases inter-line comments but the primary failing of these 
models is the ability to highlight just what the comment is about.  The user 
interface would be fairly simple.  Highlight the region and a text area appears 
below.  You enter text and hit submit or you can cancel.  A marker is left in 
the margins indicating the presence of a comment when you hit the marker, the 
text becomes visible again and the highlighted region becomes visible again. 
There are other refinements but that's fundamentally it.  I'll probably be 
motivated to jump into the JavaScript necessary after I finish and publish to 
other projects in Python.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python in the Mozilla world

[Eric S. Johansson]

Steve Howell wrote:
 --- Eric S. Johansson [EMAIL PROTECTED] wrote:
 
 Steve Howell wrote:
 --- Eric S. Johansson [EMAIL PROTECTED] wrote:

 http://www.voidspace.org.uk/python/weblog/arch_d7_2007_04_28.shtml#e702
 interesting.  Very interesting but I suspect the
 message is don't hold your 
 breath but don't give up hope.

 Exactly. :)
 This is one of those things where a foundation, with
 a smart person for making 
 really simple things should get some money from the
 foundation and get it built. 
 
 Well, this is a case where smart people (including Jim
 Hugunin) are getting some money from Microsoft, which
 probably still has more dollars to spend than the
 average foundation.  And some really smart people in
 the open source world (Miguel de Icaza, etc.) are
 tracking to it, according to the article.

this is good to know except I am somewhat cautious about the end result given 
that it's from Microsoft (explained below)

   As far as
 really simple things goes, it doesn't really fit in
 that category.

I spent way too many years as a designer of software and then systems and may 
have found what may be a universal constant based on how people understand 
complexity and politics.

In the beginning, almost every idea is simple.  simplicity helps you get a 
rough 
go/no go estimation of project success.  Simplicity helps you communicate the 
essential elements of the project to others so that you can get them to buy in 
(funding, resources).  However as you develop use cases, the project gets more 
and more complex those in command issue to implement at the worst possible time 
because they are nervous about the increased complexity blowing up the budget.

The really cool thing about complex systems is that it's like climbing a 
mountain.  You never know when you reach the top until you are almost there. 
the simplicity doesn't emerge until you're almost done but it will emerge.  If 
the apparent solution keeps getting more and more complex, then you really 
don't 
understand the problem and shouldn't even try to implement the solution.

this is a pattern I can almost take to the bank.  Simple idea, complex partial 
solution, simpler solution.  only experience will tell you when you have gotten 
the most simplicity out of the solution possible.  Now granted, some problems 
are inherently complex but if you contrast mid-understanding versus final 
solution, there will always be a big difference and complexity.

I've always thought Microsoft interfaces were horribly horribly complex and I 
think it's due to two factors.  The first is that they implement at the worst 
point in their understanding, and it's a barrier to entry for all third-party 
developers.

If you don't agree with these ideas, that's cool.  We can agree to disagree but 
this has been my experience over many years.

 As much as I love Python, though, I still think the
 future of browser-side programming for the next five
 or ten years is Javascript, and I think the real
 productivity gains are going to come when Javascript
 libraries mature, it becomes more common knowledge
 which libraries are best of breed, etc.

that's really a pity.  Although that is consistent with a recent announcement I 
thought regarding IBM and their funding of the Linux desktop accessibility.  I 
personally hate the whole Ajax JavaScript crap because it is really 
inaccessible 
on multiple levels.  a sardonic corner of my mind wonders if the productivity 
gains you mention it will be offset by the productivity losses caused by the 
unbelievably horrible debuggers and IDs available and users trying to use user 
applications with even worse user interfaces than we have today.  But I will 
say, they will be prettier with all sorts of flashing colors and moving things. 
  Skins!  Don't forget the choice of skins you'll have for applications just by 
changing a cascading style sheet.  Who needs usability when you can the color 
and type font of your user interface to match your whim...grumble

I think your observation is far more correct than either of us want it to be. 
This is yet another good reason why folks should really push for a simple 
browser environment to replace JavaScript.  I really don't think it's horribly 
hard but on the other hand, I don't understand the full environment (starting 
with a simple idea... :-)

Thanks for the post.  It's triggered some nice ideas in my head.

-- 
http://mail.python.org/mailman/listinfo/python-list