Re: Python for WEB-page !?
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
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
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?
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?
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
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?
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
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
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
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
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
On 3/30/2016 9:09 AM, Chris Angelico wrote: On Thu, Mar 31, 2016 at 12:06 AM, Eric S. Johansson 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
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
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
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 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
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 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)
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
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
On 1/5/2015 7:24 AM, Chris Angelico wrote: On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki 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
Re: need some guidance on Python syntax smart editor for use with speech recognition
On 1/5/2015 3:12 AM, Chris Angelico wrote: On Mon, Jan 5, 2015 at 6:43 PM, Eric S. Johansson 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
need some guidance on Python syntax smart editor for use with speech recognition
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
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
On 8/14/2014 2:37 PM, Peter Pearson wrote: On Wed, 13 Aug 2014 14:16:02 -0600, Ian Kelly 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
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: Captcha identify
On 8/12/2014 9:46 PM, Chris Angelico wrote: On Wed, Aug 13, 2014 at 11:36 AM, Wesley 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: parsley parsing question, how to make a variable grammar
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 stamp"11: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
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 ':' :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 = :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
On 6/3/2014 7:29 PM, Chris Angelico wrote: On Wed, Jun 4, 2014 at 9:22 AM, Eric S. Johansson 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
Re: OT: This Swift thing
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
parsley parsing question
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 # # uses # template # returns(|file: |) # remembers # alt form # template[:] # 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?
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
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?
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 undefined"until 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
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
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
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?
On Tue, 06 Aug 2013 09:27:10 -0400, Burak Arslan 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] G&S Opera Co: Pirates of Penzance
On Sun, 28 Jul 2013 19:49:07 -0400, Ethan Furman 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?
On Mon, 22 Jul 2013 08:11:25 -0400, Gilles wrote: On Sun, 21 Jul 2013 18:28:27 -0600, Michael Torrie 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)
On Thu, 18 Jul 2013 00:36:17 -0400, Aseem Bansal 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: Editor Ergonomics [was: Important features for editors]
On Fri, 12 Jul 2013 18:34:30 -0400, Dennis Lee Bieber 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: Understanding other people's code
On Fri, 12 Jul 2013 10:22:59 -0400, L O'Shea 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]
On Fri, 12 Jul 2013 00:24:26 -0400, Steven D'Aprano 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
On Fri, 05 Jul 2013 23:13:24 -0400, Rustom Mody 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")
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
toggle name, With explanations
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
Re: simplified Python parsing question
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
Re: simplified Python parsing question
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
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
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
simplified Python parsing question
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
Re: need python+windows edit control help
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
need python+windows edit control help
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: Static typing, Python, D, DbC
On 9/12/2010 4:28 PM, Paul Rubin wrote: Bearophile 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
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
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 edi
Re: pep 8 constants
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
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 pe
Re: pep 8 constants
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
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
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. > x equalsR E D plus > three 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 c
Re: pep 8 constants
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
Rhodri James wrote: > On Mon, 29 Jun 2009 06:07:19 +0100, Eric S. Johansson > wrote: > >> 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. >> > > [snip sundry examples] > > Yes, yes, recognition systems need both training and a careful selection > of words to recognise to be effective. This I learned twenty years ago: > if "cap" has a high failure rate, use something else. A more profitable way would be to build a framework doing the right job and not trying to make it happen by side effect and "speaking the keyboard". Speaking the keyboard is whenever you force someone to go through gyrations to adjust spacing, case or special single character assertions (i.e.;). > > As far as I can tell, the only thing that you are even vaguely suggesting > for convention use is underscores_with_everything. As promised, I laugh > hollowly. I'm sorry. It may have been too subtle. I'm suggesting a smart editor that can tell me anything about any name in the body of code I'm working or anything I've included. with that kind of tool, I can have a command grammar that is much friendlier to the voice and gets work done faster than typing.things such as: what is this name? it's a class. What are its methods? tree branch root root template plea se .root(howmany=1, branches=3, nodes={}) and the query can go from there. Using tools like these, one can keep pep-8 conventions and not create a discriminatory environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: pep 8 constants
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
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
alex23 wrote: > "Eric S. Johansson" 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 fo
Re: pep 8 constants
Peter Otten wrote: > Eric S. Johansson wrote: > >> MultiWordName mulitwordname >> very high error rate. many retries or hand hurting typing. > > Can you define macros in your speech recognition software? > > multiwordname > > 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*]" 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
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 name higher than normal recognition error rate. can require multiple tries or hand correction MultiWordName mulitwordname very high error rate. many retries or hand hurting typing. multi_word_name multiwordname normal error rate (low), can need multiple tries or hand correction StdlYCps sierra tango delta lima yankee charley 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: pep 8 constants
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: special editor support for indentation needed.
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.
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.
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] = {esc}xgoto-line{enter}$1{Enter}; go to Line [Number] = {esc}xgoto-line{enter}$1$2{Enter}; go to Line [Number]= {esc}xgoto-line{enter}$1$2$3{Enter}; go to Line [Number] = {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.
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.
[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
Re: special editor support for indentation needed.
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.
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. , 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 NaturallyS
Re: special editor support for indentation needed.
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): > ... > &
Re: special editor support for indentation needed.
[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.
[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 ^(self):{enter}"""{enter}"""{enter}> 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.
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 ^(self):{enter}"""{enter}"""{enter} 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
special editor support for indentation needed.
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: I built a nice html templater!
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. >> >> Sure, that's what the world needed. We didn't have enough Python HTML >> templaters already. >> >> >> 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
how thread safe is the gdbm module? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode conversion problem (codec can't decode)
> > 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)
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: Reduce Whát You Owe by 50%. Get out of debt today!Reduuce Interest & |V|onthlyy Paymeñts Easy, we will show you how..Freee Quote in 10 Min.http://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: Backup Script over ssh
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=pagemaster&PAGE_user_op=view_page&PAGE_id=6&MMN_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: anydbm safe for simultaneous writes?
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: Is Python really a scripting language?
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: Is Python really a scripting language?
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: Looking for a good Python environment
[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
Re: Using Python To Change The World :)
[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: IDE for Python
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
setup.py question
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
unifying many packages under one name
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
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
Re: Python in the Mozilla world
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
Re: Python in the Mozilla world
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
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 editors again (it's not the same old request)
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
Python in the Mozilla world
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