Re: why the different output in Eclipse and Python Shell?

[Terry Reedy]

On 8/1/2012 12:45 AM, levi nie wrote:

my code in Eclipse:

dict.fromkeys(['China','America'])


In Eclipse, I presume this prints nothing, as is normal for an editor.


print "dict is",dict

output: dict is 


This is red herring. The shell does the same with that line. It is not 
relevant to your question.



dict.fromkeys(['China','America'])

output:{'America': None, 'China': None}


The interactive interpreter echoes the result of evaluating expressions.

--
Terry Jan Reedy



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

why the different output in Eclipse and Python Shell?

[levi nie]

my code in Eclipse:

dict.fromkeys(['China','America'])
print "dict is",dict

output: dict is 

my code in Python Shell:

dict.fromkeys(['China','America'])

output:{'America': None, 'China': None}

Output in Python Shell is what i wanna,but why not in Eclipse?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] pyknon: Simple Python library to generate music in a hacker friendly way.

[Pedro Kroger]

On Aug 1, 2012, at 12:19 AM, Peter Billam  wrote:

> I'll check it out.  It probably fits into a whole software
> ecosystem that you're putting together …

yes, I use it for my book, Music for Geeks and Nerds and for teaching.

> It's a crowded area, e.g. my midi stuff is at:
>  http://www.pjb.com.au/midi/index.html

You have very interesting stuff, I'll check them out.

> and I'd probably do the above example by:
>  ~> muscript -midi   | 3/4 2.0
>  =1 treble 4 D 8 [F# A] 4 Bb
>  EOT

Nice. This reminded me to include a less simple example. After all,
the whole point of pyknon is to be able to generate music programmatically
using Python:

http://kroger.github.com/pyknon/

> You could consider posting Pyknon to comp.music.midi ;
> it's very low traffic, but some real gurus lurk there.

Good idea, thanks for the suggestion.

Cheers,

Pedro
-
http://pedrokroger.net
http://musicforgeeksandnerds.com

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

Re: missing python-config and building python on Windows

[Mark Hammond]

On 1/08/2012 10:48 AM, Damon Register wrote:

I am attempting to build gtk and glade using mingw/msys.  It seems that
some
of the packages require python.  I installed 2.7.3 using the installer from
python.org.  That worked for some of the packages but now I am trying to do
one that needs python-config which I don't find in the installation
directory.

I tried building from source using mingw/msys but that had too many
problems
so I gave up on that.  I thought I might try building with MSVC 2010 since
it appears to be supported and I have that at work.  There are a few
problems
with this:
1. though I have looked in a few readme files, I don't see instructions for
installing what I have just built using MSVC.  Where can I find the
instructions for installing after building with MSVC?


There is no such process.  In general, you can just run directly from 
the built tree.



2. I have searched the project directory but I don't find
python-config.  Is
this some sort of optional thing that isn't built by default?  I tried
searching this list and although I find a few questions about it, I
don't
see an answer to where I can find it.


I'm afraid I don't know what python-config is.  It appears it might be a 
reflection of how Python was configured and build on *nix systems - if 
that is the case then it is expected that one does not exist for Windows 
(as it doesn't use the *nix build chain).



3. It seems that MSVC doesn't produce the .a library files needed for
linking
into a mingw built program.  Do I have to do that fun trick to
create the
.a from the dll?


I'm surprised MSVC *can* build .a files for mingw - but AFAIK, even if 
MSVC could do that, I believe Python makes no attempt to build with 
support for linking into mingw programs.


Mark

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

Re: [ANN] pyknon: Simple Python library to generate music in a hacker friendly way.

[Peter Billam]

On 2012-07-30, Pedro Kroger  wrote:
> Pyknon is a simple music library for Python hackers. With Pyknon
> you  can generate Midi files quickly and reason about musical
> proprieties.  It works with Python 2.7 and 3.2.
> ... a basic example to create 4 notes and save into a MIDI file:
> from pyknon.genmidi import Midi
> from pyknon.music import NoteSeq
> notes1 = NoteSeq("D4 F#8 A Bb4")
> midi = Midi(1, tempo=90)
> midi.seq_notes(notes1, track=0)
> midi.write("demo.mid")
> It's available on PyPI and its homepage is
> http://kroger.github.com/pyknon/
> Pedro
> http://pedrokroger.net  http://musicforgeeksandnerds.com

I'll check it out.  It probably fits into a whole software
ecosystem that you're putting together ...

It's a crowded area, e.g. my midi stuff is at:
  http://www.pjb.com.au/midi/index.html
and I'd probably do the above example by:
  ~> muscript -midi 

missing python-config and building python on Windows

[Damon Register]

I am attempting to build gtk and glade using mingw/msys.  It seems that some
of the packages require python.  I installed 2.7.3 using the installer from
python.org.  That worked for some of the packages but now I am trying to do
one that needs python-config which I don't find in the installation directory.

I tried building from source using mingw/msys but that had too many problems
so I gave up on that.  I thought I might try building with MSVC 2010 since
it appears to be supported and I have that at work.  There are a few problems
with this:
1. though I have looked in a few readme files, I don't see instructions for
   installing what I have just built using MSVC.  Where can I find the
   instructions for installing after building with MSVC?

2. I have searched the project directory but I don't find python-config.  Is
   this some sort of optional thing that isn't built by default?  I tried
   searching this list and although I find a few questions about it, I don't
   see an answer to where I can find it.

3. It seems that MSVC doesn't produce the .a library files needed for linking
   into a mingw built program.  Do I have to do that fun trick to create the
   .a from the dll?

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

Re: Linux shell to python

[Barry Scott]

On 30 Jul 2012, at 23:56, Dan Stromberg  wrote:

> 
> On Mon, Jul 30, 2012 at 9:26 PM, Barry Scott  wrote:
> lspci gets all its information from the files in /sys/bus/pci/devices.
>  
> You can use os.listdir() to list all the files in the folder and then open
> the files you want to get the data you need.
> Gee, wouldn't it be more portable to parse lspci?  I wouldn't put it past the 
> (Linux) kernel devs to move the pseudo-filesystems around again...

No. The app is less stable the the linux user api gureentee.
I have been bitten with app output format changes but the /sys files have been
Reliable and far better focused at answering questions.

>  
> And of course you can write list comprehensions on as many lines as
> it take to make the code maintainable.
> Sigh, and I'm also not keen on multi-line list comprehensions, specifically 
> because I think they tend to make less readable code.  It also becomes a mess 
> when you need to insert print statements to get some visibility into what's 
> going on.
> 

With out trading examples of production code this is resolverable.

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

Re: NameError vs AttributeError

[Terry Reedy]

On 7/31/2012 4:49 PM, Chris Kaynor wrote:

On Tue, Jul 31, 2012 at 1:21 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:

Another example: KeyError and IndexError are both subscript errors,
but there is no SubscriptError superclass, even though both work
thru the same mechanism -- __getitem__.  The reason is that there is
no need for one. In 'x[y]', x is usually intented to be either a
sequence or mapping, but not possibly both. In the rare cases when
one wants to catch both errors, one can easily enough. To continue
the example above, popping an empty list and empty set produce
IndexError and KeyError respectively:

   try:
 while True:
   process(pop())
   except (KeyError, IndexError):
 pass  # empty collection means we are done

There is a base type for KeyError and IndexError: LookupError.

http://docs.python.org/library/exceptions.html#exception-hierarchy


Oh, so there is. Added in 1.5 strictly as a never-directly-raised base 
class for the above pair, now also directly raised in codecs.lookup. I 
have not decided if I want to replace the tuple in the code in my book.


--
Terry Jan Reedy



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

Re: Why 'Flat is better than nested'

[Terry Reedy]

On 7/31/2012 5:49 PM, Ian Kelly wrote:

On Tue, Jul 31, 2012 at 3:28 PM, Ifthikhan Nazeem  wrote:

as many as (about) 2*N - log2(N) parent child relationships

I would like to know how did you come up with the above formula? Forgive my
ignorance.


By non-rigorous experimentation, which did not quite count everything.


I come up with 2N - 2 myself.  If there are N leaf nodes and N - 1
non-leaf nodes, then there are 2N - 1 total nodes, each of which has
one parent except for the root.  That's 2N - 2 parent-child
relationships.


That looks right. I was trying to think recursively, which in this case 
is more rather than less complicated. That actually sharpens my original 
point. N-1 new nodes and 2N-2 new relationships is 3N-3 new entities.


The internal node limit of N-1 only applies to full-proper-strict binary 
trees without one-child internal nodes. Otherwise, a single leaf node 
could have an indefinite number of ancestors.


from https://en.wikipedia.org/wiki/Binary_tree
"A full binary tree (sometimes proper binary tree or 2-tree or strictly 
binary tree) is a tree in which every node other than the leaves has two 
children."


--
Terry Jan Reedy



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

Re: Is Python a commercial proposition ?

[David]

On 01/08/2012, lipska the kat  wrote:
> On 31/07/12 14:52, David wrote:
>>
>> [1] as in beer
>> [2] for research purposes
>
> There's one (as in 1 above) in the pump for you.

Great, more beer => better research => \o/\o/\o/
But, "pump" sounds a bit extreme .. I usually sip contentedly from a glass :p
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: simplified Python parsing question

[Chris Angelico]

On Tue, Jul 31, 2012 at 11:54 AM, Steven D'Aprano
 wrote:
> 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.

I go the opposite way. Google Docs works fine in my web browser, but
if it's a Word doc, I need to hunt down something that can read it.
I've yet to find any browser that can't handle a GDocs "publish" page,
but I have plenty of computers that don't have any
{Open|Libre|Liber|Libra|whatever the next generation is}-Office
installed.

Best is to put the information into your email/post. Next best is to
have a link to the information. Definitely worst is to force people to
download your file and try to read it.

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

Re: Why 'Flat is better than nested'

[Ian Kelly]

On Tue, Jul 31, 2012 at 3:28 PM, Ifthikhan Nazeem  wrote:
> as many as (about) 2*N - log2(N) parent child relationships
>
> I would like to know how did you come up with the above formula? Forgive my
> ignorance.

I come up with 2N - 2 myself.  If there are N leaf nodes and N - 1
non-leaf nodes, then there are 2N - 1 total nodes, each of which has
one parent except for the root.  That's 2N - 2 parent-child
relationships.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why 'Flat is better than nested'

[Ifthikhan Nazeem]

*as many as (about) 2*N - log2(N) parent child relationships*
*
*
I would like to know how did you come up with the above formula? Forgive my
ignorance.

--
Thanks and Best Regards,
Iftikhan Nazeem
*Skype* : iftecan2000



On Tue, Jul 31, 2012 at 11:04 PM, Terry Reedy  wrote:

> >>> import this
>
> prints 'The Zen of Python', a poem by Tim Peters that consists of python
> proverbs such as "Flat is better than nested." (Others things being equal)
> why? Because it is a restatement of the principle of parsimony, of not
> multiplying entities without necessity.
>
> Suppose we have a unstructured collection of N items. Organizer comes
> along and says 'Let there be structure. Let us organize the items as leaf
> nodes in a hierarchical tree' (which is equivalent to nesting). To do so,
> we can add as many as N-1 new non-leaf nodes and as many as (about) 2*N -
> log2(N) parent child relationships. In other words, nearly quadruple the
> number of entities to learn, discuss, and remember. Well, there had better
> be a good necessity to do so ;-).
>
> And, of course, once new entities *are* conjured up, it is hard to get rid
> of them.
>
> --
> Terry Jan Reedy
>
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Why 'Flat is better than nested'

[Terry Reedy]

>>> import this

prints 'The Zen of Python', a poem by Tim Peters that consists of python 
proverbs such as "Flat is better than nested." (Others things being 
equal) why? Because it is a restatement of the principle of parsimony, 
of not multiplying entities without necessity.


Suppose we have a unstructured collection of N items. Organizer comes 
along and says 'Let there be structure. Let us organize the items as 
leaf nodes in a hierarchical tree' (which is equivalent to nesting). To 
do so, we can add as many as N-1 new non-leaf nodes and as many as 
(about) 2*N - log2(N) parent child relationships. In other words, nearly 
quadruple the number of entities to learn, discuss, and remember. Well, 
there had better be a good necessity to do so ;-).


And, of course, once new entities *are* conjured up, it is hard to get 
rid of them.


--
Terry Jan Reedy


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

Re: NameError vs AttributeError

[Chris Kaynor]

On Tue, Jul 31, 2012 at 1:21 PM, Terry Reedy  wrote:

> Another example: KeyError and IndexError are both subscript errors, but
> there is no SubscriptError superclass, even though both work thru the same
> mechanism -- __getitem__.  The reason is that there is no need for one. In
> 'x[y]', x is usually intented to be either a sequence or mapping, but not
> possibly both. In the rare cases when one wants to catch both errors, one
> can easily enough. To continue the example above, popping an empty list and
> empty set produce IndexError and KeyError respectively:
>

>   try:
> while True:
>   process(pop())
>   except (KeyError, IndexError):
> pass  # empty collection means we are done


There is a base type for KeyError and IndexError: LookupError.

http://docs.python.org/library/exceptions.html#exception-hierarchy


>
>
> --
> Terry Jan Reedy
>
>
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: NameError vs AttributeError

[Terry Reedy]

On 7/31/2012 6:36 AM, Ulrich Eckhardt wrote:

Hi!

Using Python 2.7, I stumbled across the fact that 'self.xy' raises an
AttributeError if self doesn't have an 'xy' as attribute, but 'xy' will
instead raise a NameError. To some extent, these two are very similar,
namely that the name 'xy' couldn't be resolved in a certain context, but
they don't have a common baseclass.


You have observed a true fact. The two errors both involve 
non-reconition of identifiers. In most cases, the identifiers are 
looked-up in a dict.



I guess one of the reasons is behind the way that Python handles
variable lookup, the plain 'xy' will find local and global names while
'self.xy' will only look into onself. However, this vague idea is far
from enough to explain it to someone else.

Can someone help me out?


1. Why two separate exceptions:

a) operational: two separate exceptions are possible.

Name lookup and attribute lookup goes thru separate machinery. Name 
lookup may go thru local, nonlocal, global (modular) and builtin 
namespaces. Attribute lookup goes thru instance, class, and superclasses 
to object. Name lookup is fixed except for nonlocal and global 
declarations local assignments. Attribute lookup can be over-riden with 
special methods (and special method lookup skips the instance).


b) practical: two separate exceptions are desirable.

One catches an exception to do something in the except clause. Name and 
attribute errors often have different causes and different associated 
actions.


def empty_and_process(poppable, process):
  try:
pop = popable.pop
  except AttributeError:
raise AttributeError("Can only empty_and_process objects with .pop 
method")


Whoops, programming typo raises NameError. It should *not* be caught, 
rather bug should be fixed.


Later usage error gets AttributeError, possibly documented. User decides 
whether it represents a bug to be fixed (the default) or a control 
signal to be caught and processed.


If one really does want the same action for the different mistakes, 
"except (NameError, AttributeError):" is easy enough to write.


2. Why no special base exception (NameAttrError ?).

Python exceptions started as strings with NO hierarchy. The current 
class system is still relatively flat. Flat is better than nested 
because nesting introduces a new entities and new entities should not be 
introduced without sufficient purpose and each one makes the whole 
harder to learn and remember. I suspect that if you grepped a large 
Python code corpus for this particular pair in except statements you 
would find it rare.


---
Another example: KeyError and IndexError are both subscript errors, but 
there is no SubscriptError superclass, even though both work thru the 
same mechanism -- __getitem__.  The reason is that there is no need for 
one. In 'x[y]', x is usually intented to be either a sequence or 
mapping, but not possibly both. In the rare cases when one wants to 
catch both errors, one can easily enough. To continue the example above, 
popping an empty list and empty set produce IndexError and KeyError 
respectively:


  try:
while True:
  process(pop())
  except (KeyError, IndexError):
pass  # empty collection means we are done

--
Terry Jan Reedy



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

Re: Linux shell to python

[88888 Dihedral]

Mark Lawrence於 2012年7月31日星期二UTC+8下午3時15分32秒寫道：
> On 31/07/2012 02:20, Dennis Lee Bieber wrote:
> 
> > On Mon, 30 Jul 2012 22:56:48 +, Dan Stromberg 
> 
> > declaimed the following in gmane.comp.python.general:
> 
> >
> 
> >
> 
> >> Sigh, and I'm also not keen on multi-line list comprehensions, specifically
> 
> >> because I think they tend to make less readable code.  It also becomes a
> 
> >> mess when you need to insert print statements to get some visibility into
> 
> >> what's going on.
> 
> >
> 
> > Cleanly splitting the list-comp by
> 
> >
> 
> > [ result-computation
> 
> > for-item-selection-clause
> 
> > if-filter-clause ]
> 
> >
> 
> > isn't that unreadable... But anyone doing
> 
> >
> 
> > [ result-
> 
> > -computation for-item-
> 
> > -selection-clause if-
> 
> > -filter-
> 
> > -clause ]
> 
> >
> 
> > should be pecked to death by a dead parrot.
> 
> >
> 
> 
> 
> Any particular species?
> 
> 
> 
> -- 
> 
> Cheers.
> 
> 
> 
> Mark Lawrence.

For each item in the known list that passes the required conditional test,
then  use the item to perform the tasks desired as instructed.

It is not necessary that a new list has to be constructed in the tasks.

A method which can produce a new object always involves some memory management. 
Therefore,  some error handling part should not be missing.


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

Re: Is Python a commercial proposition ?

[lipska the kat]

On 31/07/12 14:52, David wrote:

On 30/07/2012, lipska the kat  wrote:

On 30/07/12 14:06, Roy Smith wrote:


These days, I'm working on a fairly large web application (songza.com).


"We are very sorry to say that due to licensing constraints we cannot
allow access to Songza for listeners located outside of the United States."

Arse :-(


A free[1] US proxy could bypass[2] that page ... eg something like
http://www.airproxy.ca/

[1] as in beer
[2] for research purposes


Oh that's a bit good isn't it, just for research purposes of course.

There's one (as in 1 above) in the pump for you.

lipska

--
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
--
http://mail.python.org/mailman/listinfo/python-list

Re: docx/lxml

[Cyrille Leroux]

On Tuesday, July 31, 2012 5:13:12 PM UTC+2, Stefan Behnel wrote:
> Cyrille Leroux, 31.07.2012 17:01:
> 
> > I'm giving pip a try :
> 
> > 
> 
> > 
> 
> > 1/ Linux (debian lenny)
> 
> > - (as root) sh setuptools-0.6c11-py2.7.egg (ok)
> 
> > - (as root) cd pip-1.1 ; python setup.py install (ok)
> 
> > - pip : ImportError : No module named pkg_resources
> 
> > - damn, I guess it's going to be a pain, again
> 
> > - ... then I remember that anyway, I cannot access internet from my session
> 
> > - end of story for linux
> 
> > 
> 
> > 
> 
> > 2/ Back on Windows (7)
> 
> > 
> 
> > - setuptools-0.6c11.win32-py2.7.exe (ok)
> 
> > - (cmd) easy_install.exe pip : AttributeError : 'NoneType' object has no 
> > attribute 'clone'
> 
> > 
> 
> > Well, I think I'm starting to feel less and less enthusiastic about 
> > python... I didn't suspect it would be so difficult to write a basic doc 
> > file :)
> 
> 
> 
> "pip" goes with "distribute", not "setuptools".
> 
> 
> 
> http://packages.python.org/distribute/
> 
> 
> 
> Stefan

Ok, I will try it next time then, thank you.


In the end, I found a way around. I generated an html file, then, converted it 
to a doc file.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pass data to a subprocess

[andrea crotti]

2012/7/31 Laszlo Nagy :
>> I think I got it now, if I already just mix the start before another add,
>> inside the Process.run it won't see the new data that has been added after
>> the start. So this way is perfectly safe only until the process is launched,
>> if it's running I need to use some multiprocess-aware data structure, is
>> that correct?
>
> Yes. Read this:
>
> http://docs.python.org/library/multiprocessing.html#exchanging-objects-between-processes
>
> You can use Queues and Pipes. Actually, these are basic elements of the
> multiprocessing module and they are well documented. I wonder if you read
> the documentation at all, before posting questions here.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list


As I wrote "I found many nice things (Pipe, Manager and so on), but
actually even
this seems to work:" yes I did read the documentation.

I was just surprised that it worked better than I expected even
without Pipes and Queues, but now I understand why..

Anyway now I would like to be able to detach subprocesses to avoid the
nasty code reloading that I was talking about in another thread, but
things get more tricky, because I can't use queues and pipes to
communicate with a running process that it's noit my child, correct?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: docx/lxml

[Stefan Behnel]

Cyrille Leroux, 31.07.2012 17:01:
> I'm giving pip a try :
> 
> 
> 1/ Linux (debian lenny)
> - (as root) sh setuptools-0.6c11-py2.7.egg (ok)
> - (as root) cd pip-1.1 ; python setup.py install (ok)
> - pip : ImportError : No module named pkg_resources
> - damn, I guess it's going to be a pain, again
> - ... then I remember that anyway, I cannot access internet from my session
> - end of story for linux
> 
> 
> 2/ Back on Windows (7)
> 
> - setuptools-0.6c11.win32-py2.7.exe (ok)
> - (cmd) easy_install.exe pip : AttributeError : 'NoneType' object has no 
> attribute 'clone'
> 
> Well, I think I'm starting to feel less and less enthusiastic about python... 
> I didn't suspect it would be so difficult to write a basic doc file :)

"pip" goes with "distribute", not "setuptools".

http://packages.python.org/distribute/

Stefan


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

Re: Search and replace text in XML file?

[Paul Rudin]

Terry Reedy  writes:

> ... a proper text-editor*

>  * ... Notepad++ is one such on Windows.

Surely emacs is the only such on any platform? :)

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

Re: docx/lxml

[Cyrille Leroux]

On Tuesday, July 31, 2012 4:00:25 PM UTC+2, Pedro Kroger wrote:
> On Jul 31, 2012, at 10:36 AM, Cyrille Leroux wrote:
> 
> 
> 
> > - Do you know any *easy to use*, *easy to deploy* package to generate ".doc 
> > like" documents ?
> 
> > - Do you have any suggestion to do it differently (maybe with native 
> > packages ?)
> 
> > 
> 
> > - As a python newby, I don't understand why you have to go through the pain 
> > of installing packages since they should be able to work with just the 
> > __init__.py files ? 
> 
> > 
> 
> > Regards,
> 
> > 
> 
> > Cyrille
> 
> 
> 
> Hi,
> 
> 
> 
> May I suggest you use pip and, possibly, virtualenv?
> 
> pip makes it easy to install Python packages while virtualenv creates an 
> isolated Python environment
> 
> 
> 
> For instance, I just installed docx and its dependencies with:
> 
> 
> 
> pip install docx lxml datutils PIL
> 
> 
> 
> And I did that inside a testing virtualenv, so I wouldn't mess up my Python 
> setup.
> 
> 
> 
> pip and virtualenv make it really easy and painless to install Python 
> packages.
> 
> 
> 
> Cheers,
> 
> 
> 
> Pedro
> 
> -
> 
> http://pedrokroger.net
> 
> http://musicforgeeksandnerds.com


Thank you for your quick reply Pedro.

I'm giving pip a try :


1/ Linux (debian lenny)
- (as root) sh setuptools-0.6c11-py2.7.egg (ok)
- (as root) cd pip-1.1 ; python setup.py install (ok)
- pip : ImportError : No module named pkg_resources
- damn, I guess it's going to be a pain, again
- ... then I remember that anyway, I cannot access internet from my session
- end of story for linux


2/ Back on Windows (7)

- setuptools-0.6c11.win32-py2.7.exe (ok)
- (cmd) easy_install.exe pip : AttributeError : 'NoneType' object has no 
attribute 'clone'

Well, I think I'm starting to feel less and less enthusiastic about python... I 
didn't suspect it would be so difficult to write a basic doc file :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pass data to a subprocess

[Laszlo Nagy]

> I think I got it now, if I already just mix the start before another 
add, inside the Process.run it won't see the new data that has been 
added after the start. So this way is perfectly safe only until the 
process is launched, if it's running I need to use some 
multiprocess-aware data structure, is that correct?


Yes. Read this:

http://docs.python.org/library/multiprocessing.html#exchanging-objects-between-processes

You can use Queues and Pipes. Actually, these are basic elements of the 
multiprocessing module and they are well documented. I wonder if you 
read the documentation at all, before posting questions here.



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

Re: Pass data to a subprocess

[andrea crotti]

>
>
> def procs():
> mp = MyProcess()
> # with the join we are actually waiting for the end of the running time
> mp.add([1,2,3])
> mp.start()
> mp.add([2,3,4])
> mp.join()
> print(mp)
>

I think I got it now, if I already just mix the start before another
add, inside the Process.run it won't see the new data that has been
added after the start.

So this way is perfectly safe only until the process is launched, if
it's running I need to use some multiprocess-aware data structure, is
that correct?
-- 
http://mail.python.org/mailman/listinfo/python-list

Firefox 3.6 [OT] (was: Re: [ANN] pyknon: Simple Python library to generate music in a hacker friendly way.)

[Andrew Berg]

On 7/30/2012 9:25 PM, Steven D'Aprano wrote:
> I don't. But in my experience, the risk of security breaches is *much* 
> less than the chance that the new version will break functionality, 
> introduce bugs, have a worse user interface, and generally be a step 
> backwards rather than forward.
4.0 sucked. It had a radically new UI and it broke heaps of add-ons and
it leaked memory. 5.0 was slightly better, but still sucked because it
still leaked memory. 6.0 didn't suck so much because the memory leaks
were taken care of, and by this point there were extensions to deal with
certain issues (like not having a place for status bar icons). By 7.0,
there weren't really any more problems. By no means was the process
painless, but I've found the new UI to be a bit better than the old one
(at this point - not when 4.0 came out) now that the dust has settled.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: docx/lxml

[Pedro Kroger]

On Jul 31, 2012, at 10:36 AM, cyrille.ler...@gmail.com wrote:

> - Do you know any *easy to use*, *easy to deploy* package to generate ".doc 
> like" documents ?
> - Do you have any suggestion to do it differently (maybe with native packages 
> ?)
> 
> - As a python newby, I don't understand why you have to go through the pain 
> of installing packages since they should be able to work with just the 
> __init__.py files ? 
> 
> Regards,
> 
> Cyrille

Hi,

May I suggest you use pip and, possibly, virtualenv?
pip makes it easy to install Python packages while virtualenv creates an 
isolated Python environment

For instance, I just installed docx and its dependencies with:

pip install docx lxml datutils PIL

And I did that inside a testing virtualenv, so I wouldn't mess up my Python 
setup.

pip and virtualenv make it really easy and painless to install Python packages.

Cheers,

Pedro
-
http://pedrokroger.net
http://musicforgeeksandnerds.com

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

Re: Is Python a commercial proposition ?

[David]

On 30/07/2012, lipska the kat  wrote:
> On 30/07/12 14:06, Roy Smith wrote:
>>
>> These days, I'm working on a fairly large web application (songza.com).
>
> "We are very sorry to say that due to licensing constraints we cannot
> allow access to Songza for listeners located outside of the United States."
>
> Arse :-(

A free[1] US proxy could bypass[2] that page ... eg something like
http://www.airproxy.ca/

[1] as in beer
[2] for research purposes
-- 
http://mail.python.org/mailman/listinfo/python-list

docx/lxml

[cyrille . leroux]

Hello,

I'm trying to use the docx package to generate documents containing some text 
and tables.

I don't want to install any module since I just want my coworkers to copy a 
directory and run a script, without installing tons of softwares (Just 
python2.7 which is already installed).

First, I downloaded docx package, copied the docx directory I found. Then, I 
added its path (sys.path.append())

But it complained it missed a lxml package. Ok, I downloaded it, copied the 
lxml directory.

This time, it wanted a etree.py file. I search and found it is generated during 
installation... But I don't want to install it ! I searched again, and found 
that anyway, even if I install it to get this file, it will need other 
libraries... At this point, I already lost too much time, so I quit. It's way 
too much work for what I have to do.


[My questions :]

- Do you know any *easy to use*, *easy to deploy* package to generate ".doc 
like" documents ?
- Do you have any suggestion to do it differently (maybe with native packages ?)

- As a python newby, I don't understand why you have to go through the pain of 
installing packages since they should be able to work with just the __init__.py 
files ? 

Regards,

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

Re: profiling and optimizing

[Peter Otten]

Rita wrote:

> I recently inherented a large python process and everything is lovely. As
> a learning experience I would like to optimize the code so I ran it thru
> the profiler
> 
> python -m cProfile myscript.py
> 
> It seems majority of the time is taking in the deep copy but that seems to
> come from a function (or functions) in the code. Is there a way to
> optimize that? perhaps have a C implementation of the deep copy? Would
> that be feasible?

To give what the other respondents said a different angle: if you replace 
the deep with a shallow copy: do your unit tests start to fail? 

You don't have any? Add them before you start tinkering with the code ;)


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

Re: argparse limitations

[Benoist Laurent]

> The standard way, however, is to have a parser that takes the first 
> non-option argument as a subcommand name and parses the remaining arguments 
> according to that subcommand. Your command line users are more likely to be 
> able to understand how to use the program if it works that way.

I'll do this way.
Thank a lot.

Ben

Le Jul 31, 2012 à 3:04 PM, Oscar Benjamin a écrit :

> 
> 
> On 31 July 2012 13:51, Benoist Laurent  wrote:
> 
> Le Jul 31, 2012 à 1:45 PM, Oscar Benjamin a écrit :
> 
>> 
>> 
>> On 31 July 2012 12:03, Benoist Laurent  wrote:
>> Finally.
>> 
>> The code I proposed doesn't work in this case: if you add any positional 
>> argument to one of the subparsers, then the parsing doesn't work anymore.
>> The reason seems to be that argparse thinks the last argument of the first 
>> parser is the last but one argument.
>> Hence, if a subparser takes some arguments, it fails.
>> 
>> Example: if the "-n" argument of the foo parser is set mandatory (so becomes 
>> "n" instead of "-n")
>> 
>> python toto.py foo.txt bar.txt foo 10
>> usage: toto.py [-h] [fname [fname ...]] command ...
>> toto.py: error: argument command: invalid choice: '10' (choose from 'foo', 
>> 'bar')
>> 
>> What about:
>> 
>> $ python toto.py foo.txt bar.txt foo -n 10
>> 
>> Note that contrary to what you said above, your program does not work like a 
>> "standard unix tool". A standard command line program to do what you want 
>> would normally look like
> 
> You're right.
> But then, using argparse, I would have to add the same argument to all my 
> subparsers since argparse does the work sequentially: once it recognized the 
> start of a subparser, everything that follows have to be an argument of this 
> subparser.
> Hence, arguments (therefore options) from the main parser are not recognized 
> anymore.
> 
> If the parsing after the subcommand is to be the same for each subcommand, 
> then don't use subparsers. You could just make the first argument be the 
> command name and use one parser for everything.
> 
> If the parsing is supposed to be different for different subcommands then use 
> subparsers and add the files argument to each subparser; you can make a 
> function to add the common arguments and options if you don't want to 
> duplicate the code.
> 
> Well I guess it is a intrinsec limitation: I think it's quite natural that 
> the user can't enter a filename named as a command.
> 
> There is an intrinsic limitation on any parser that it must be possible to 
> determine the targets of the arguments uniquely. If you want the parser to 
> scan through and take the first argument matching 'foo' or 'bar' and parse 
> the remaining arguments accordingly then you already have your solution. It 
> just won't work if the user wants to pass in a file called 'foo' or 'bar' 
> (maybe that's acceptable, though).
> 
> The standard way, however, is to have a parser that takes the first 
> non-option argument as a subcommand name and parses the remaining arguments 
> according to that subcommand. Your command line users are more likely to be 
> able to understand how to use the program if it works that way.
> 
> Oscar.

-- 
Benoist Laurent
Laboratoire de Biochimie Theorique / CNRS UPR 9080
Institut de Biologie Physico-Chimique
13, rue Pierre et Marie Curie
F-75005 Paris
Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56

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

Re: argparse limitations

[Oscar Benjamin]

On 31 July 2012 13:51, Benoist Laurent  wrote:

>
> Le Jul 31, 2012 à 1:45 PM, Oscar Benjamin a écrit :
>
>
>
> On 31 July 2012 12:03, Benoist Laurent  wrote:
>
>> Finally.
>>
>> The code I proposed doesn't work in this case: if you add any positional
>> argument to one of the subparsers, then the parsing doesn't work anymore.
>> The reason seems to be that argparse thinks the last argument of the
>> first parser is the last but one argument.
>> Hence, if a subparser takes some arguments, it fails.
>>
>> Example: if the "-n" argument of the foo parser is set mandatory (so
>> becomes "n" instead of "-n")
>>
>> python toto.py foo.txt bar.txt foo 10
>> usage: toto.py [-h] [fname [fname ...]] command ...
>> toto.py: error: argument command: invalid choice: '10' (choose from
>> 'foo', 'bar')
>>
>
> What about:
>
> $ python toto.py foo.txt bar.txt foo -n 10
>
> Note that contrary to what you said above, your program does not work like
> a "standard unix tool". A standard command line program to do what you want
> would normally look like
>
>
> You're right.
> But then, using argparse, I would have to add the same argument to all my
> subparsers since argparse does the work sequentially: once it recognized
> the start of a subparser, everything that follows have to be an argument of
> this subparser.
> Hence, arguments (therefore options) from the main parser are not
> recognized anymore.
>

If the parsing after the subcommand is to be the same for each subcommand,
then don't use subparsers. You could just make the first argument be the
command name and use one parser for everything.

If the parsing is supposed to be different for different subcommands then
use subparsers and add the files argument to each subparser; you can make a
function to add the common arguments and options if you don't want to
duplicate the code.

Well I guess it is a intrinsec limitation: I think it's quite natural that
> the user can't enter a filename named as a command.
>

There is an intrinsic limitation on any parser that it must be possible to
determine the targets of the arguments uniquely. If you want the parser to
scan through and take the first argument matching 'foo' or 'bar' and parse
the remaining arguments accordingly then you already have your solution. It
just won't work if the user wants to pass in a file called 'foo' or 'bar'
(maybe that's acceptable, though).

The standard way, however, is to have a parser that takes the first
non-option argument as a subcommand name and parses the remaining arguments
according to that subcommand. Your command line users are more likely to be
able to understand how to use the program if it works that way.

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

Re: py2c - an open source Python to C/C++ is looking for developers

[Stefan Behnel]

Stefan Behnel, 31.07.2012 07:23:
> From a look at the source code, it seems hard to bring it together with
> anything. It looks very monolithic.

Hmm, sorry, I mixed it up with "2c.py", which is yet another of those
Python-to-C compilers with an all too similar name.

https://code.google.com/p/2c-python/

There are a couple of others here:

http://wiki.python.org/moin/PythonImplementations

Seeing the number of those compilers, almost none of which is commonly used
and/or still alive as a project, the question really is: why another one?

I mean, it's totally fine as a hobby educational project, sure, and I
really don't want to discourage anyone from going through this to have fun.

But apart from "just for fun", what is the goal that would make this
particular compiler different from the others? And also different enough to
merit its own source base, instead of basing it on one of the existing
projects? I don't consider "source is harder to read than to write" a good
answer to this in general.

Stefan


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

Re: argparse limitations

[Benoist Laurent]

Le Jul 31, 2012 à 1:45 PM, Oscar Benjamin a écrit :

> 
> 
> On 31 July 2012 12:03, Benoist Laurent  wrote:
> Finally.
> 
> The code I proposed doesn't work in this case: if you add any positional 
> argument to one of the subparsers, then the parsing doesn't work anymore.
> The reason seems to be that argparse thinks the last argument of the first 
> parser is the last but one argument.
> Hence, if a subparser takes some arguments, it fails.
> 
> Example: if the "-n" argument of the foo parser is set mandatory (so becomes 
> "n" instead of "-n")
> 
> python toto.py foo.txt bar.txt foo 10
> usage: toto.py [-h] [fname [fname ...]] command ...
> toto.py: error: argument command: invalid choice: '10' (choose from 'foo', 
> 'bar')
> 
> What about:
> 
> $ python toto.py foo.txt bar.txt foo -n 10
> 
> Note that contrary to what you said above, your program does not work like a 
> "standard unix tool". A standard command line program to do what you want 
> would normally look like

You're right.
But then, using argparse, I would have to add the same argument to all my 
subparsers since argparse does the work sequentially: once it recognized the 
start of a subparser, everything that follows have to be an argument of this 
subparser.
Hence, arguments (therefore options) from the main parser are not recognized 
anymore.

> 
> $ python toto.py foo -n 10 foo.txt bar.txt

Same remark as above: if I want the command line to look like this, then I 
would have setup each subparser with all the main program options.


> 
> or perhaps
> 
> $ python toto.py foo foo.txt bar.txt -n 10
> 
> so that the algorithm for differentiating the command 'foo' from the 
> filenames is well defined. How do you propose that your user enters a 
> filename 'foo'?

Well I guess it is a intrinsec limitation: I think it's quite natural that the 
user can't enter a filename named as a command.


> 
> Oscar.
> 
> 
> 
> Any solution?
> 
> Cheers,
> Ben
> 
> 
> 
> Le Jul 31, 2012 à 12:37 PM, Benoist Laurent a écrit :
> 
>> Really sorry about that.
>> 
>> So, for the community, below is the full code for a tool that behaves like a 
>> Unix standard tool.
>> It takes in argument the files to process and a command.
>> 
>> """Just to setup a command-line parser that acts just like a unix
>> standard tool."""
>> 
>> import argparse
>> import sys
>> 
>> def define_options():
>> parser = argparse.ArgumentParser()
>> parser.add_argument("fname", help="input file", nargs="*")
>> 
>> # create subparsers
>> subparsers = parser.add_subparsers(dest="cmd", metavar="command")
>> 
>> # create the parser for the "foo" command
>> get_parser = subparsers.add_parser("foo", help="foo help")
>> get_parser.add_argument("-n", help="number of foo to print", 
>> type=int, default=10)
>> 
>> # create the parser for the "bar" command
>> sum_parser = subparsers.add_parser("bar", help="bar help")
>> 
>> return parser
>> 
>> 
>> if __name__ == '__main__':
>> args = define_options().parse_args()
>> 
>> if not args.fname:
>> content = sys.stdin.read()
>> # do something
>> else:
>> for fname in args.fname:
>> with(open(fname, "rt")) as f:
>> content = f.read()
>> # do somet
>> 
>> 
>> Benoist
>> 
>> 
>> 
>> Le Jul 31, 2012 à 11:55 AM, Oscar Benjamin a écrit :
>> 
>>> 
>>> On Jul 31, 2012 10:32 AM, "Benoist Laurent"  wrote:
>>> >
>>> > Well sorry about that but it seems I was wrong.
>>> > It was Friday evening and I guess I've not been careful.
>>> >
>>> > Actually when you specify nargs="?",  the doc says "One argument will be 
>>> > consumed from the command line if possible, and produced as a single 
>>> > item".
>>> > So you can't pass several arguments to the program.
>>> 
>>> Right below that in the docs it explains about using nargs='*' and 
>>> nargs='+'. One of those will do what you want.
>>> 
>>> Oscar.
>>> 
>>> >
>>> > So, to rephrase the question, how can I get a argument parser that parses 
>>> > the command-line just as Unix grep would do?
>>> > i.e.
>>> >
>>> > $ echo 42 > foo.txt
>>> > $ echo 172 >> foo.txt
>>> > $ cp foo.txt bar.txt
>>> > $
>>> > $ grep 42 foo.txt
>>> > 42
>>> > $ grep 42 foo.txt bar.txt
>>> > foo.txt:42
>>> > bar.txt:42
>>> > $ cat foo.txt | grep 42
>>> > 42
>>> > $ grep -c 42 foo.txt
>>> > 1
>>> >
>>> >
>>> > Cheers,
>>> > Ben
>>> >
>>> >
>>> >
>>> >
>>> > Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :
>>> >
>>> >>
>>> >>
>>> >> Yes basically looks like you get it.
>>> >> I have to further test it but my first impression is that it's correct.
>>> >>
>>> >> So actually the point was to use nargs="?".
>>> >>
>>> >> Thank you very much.
>>> >> Ben
>>> >>
>>> >>
>>> >>
>>> >> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
>>> >>
>>> >>> Benoist Laurent wrote:
>>> >>>
>>>  I'm impletting a tool in Python.
>>> 
>>>  I'd like this tool to behave like a standard unix tool, as grep for
>>>

Re: profiling and optimizing

[Oscar Benjamin]

On 31 July 2012 13:13, Rita  wrote:

> hello,
>
> I recently inherented a large python process and everything is lovely. As
> a learning experience I would like to optimize the code so I ran it thru
> the profiler
>
> python -m cProfile myscript.py
>
> It seems majority of the time is taking in the deep copy but that seems to
> come from a function (or functions) in the code. Is there a way to optimize
> that? perhaps have a C implementation of the deep copy? Would that
> be feasible?
>

I think you'll need to provide more information to get an answer to your
question. Why are you copying? What are you copying? Do you need a
deep-copy?

I don't really know what you're doing but my first approach would be to try
and reduce or eliminate the deep copies rather than implement them in c.

Oscar.


>
>
>
>
>
>
> --
> --- Get your facts first, then you can distort them as you please.--
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: profiling and optimizing

[Stefan Behnel]

Rita, 31.07.2012 14:13:
> I recently inherented a large python process and everything is lovely. As a
> learning experience I would like to optimize the code so I ran it thru the
> profiler
> 
> python -m cProfile myscript.py
> 
> It seems majority of the time is taking in the deep copy but that seems to
> come from a function (or functions) in the code. Is there a way to optimize
> that? perhaps have a C implementation of the deep copy? Would that
> be feasible?

Those approaches would be my second (or maybe even later) step. The first
one would be to check if the deep copy is really necessary, and if so, if
it is really necessary to do it over the full depth of the entire object graph.

Stefan


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

Re: profiling and optimizing

[Chris Angelico]

On Tue, Jul 31, 2012 at 10:13 PM, Rita  wrote:
> It seems majority of the time is taking in the deep copy but that seems to
> come from a function (or functions) in the code. Is there a way to optimize
> that?

Why is the program deep-copying things? Rather than making deepcopy
faster, consider doing it less.

Normally I would first ask: Does the program even NEED optimization?
Often the answer is no, because it's already fast enough - for
instance, if it spends all its time waiting for the internet, there's
little point reducing its CPU footprint. However, that point is moot
in this instance, since you're doing the profiling/optimization for
education rather than performance :) Have fun with it!

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

Re: Is Python a commercial proposition ?

[Roy Smith]

In article <50177b4d$0$29867$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> Do they consider that perhaps there are alternatives to threads?

There's basically two reasons people use threads.

First is because it's a convenient way to multiplex short-lived tasks on 
a single processor.  What people tend to forget is that we managed to do 
that before there were threads.  Event loops still work perfectly fine.  
For an interesting example, http://www.gevent.org/.

Second is because we have multiple long-lived, compute-bound tasks and 
want to be able to take advantage of multiple processors.  For that, 
multiprocessing works just fine most of the time.  And multiprocess has 
the advantage over multithreading in that the processes can run on 
different machines, so you're not limited by the number of cores you can 
get on a single CPU.

What multiprocessing doesn't give you is fine-grain task switching.  So 
we're left with the set of jobs which consist of many (but not more than 
the number of cores on one CPU) compute-bound tasks, that we know how to 
parallelize, and require fine-grain task switching.  Sure, that's an 
important set of jobs, but there's a whole huge world of computing that 
doesn't fit into that box.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Eric S. Johansson]

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

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

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

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


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


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


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


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






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

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


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


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




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

Re: argparse limitations

[Oscar Benjamin]

On 31 July 2012 12:03, Benoist Laurent  wrote:

> Finally.
>
> The code I proposed doesn't work in this case: if you add any positional
> argument to one of the subparsers, then the parsing doesn't work anymore.
> The reason seems to be that argparse thinks the last argument of the first
> parser is the last but one argument.
> Hence, if a subparser takes some arguments, it fails.
>
> Example: if the "-n" argument of the foo parser is set mandatory (so
> becomes "n" instead of "-n")
>
> python toto.py foo.txt bar.txt foo 10
> usage: toto.py [-h] [fname [fname ...]] command ...
> toto.py: error: argument command: invalid choice: '10' (choose from 'foo',
> 'bar')
>

What about:

$ python toto.py foo.txt bar.txt foo -n 10

Note that contrary to what you said above, your program does not work like
a "standard unix tool". A standard command line program to do what you want
would normally look like

$ python toto.py foo -n 10 foo.txt bar.txt

or perhaps

$ python toto.py foo foo.txt bar.txt -n 10

so that the algorithm for differentiating the command 'foo' from the
filenames is well defined. How do you propose that your user enters a
filename 'foo'?

Oscar.


>
> Any solution?
>
> Cheers,
> Ben
>
>
>
> Le Jul 31, 2012 à 12:37 PM, Benoist Laurent a écrit :
>
> Really sorry about that.
>
> So, for the community, below is the full code for a tool that behaves like
> a Unix standard tool.
> It takes in argument the files to process and a command.
>
> """Just to setup a command-line parser that acts just like a unix
> standard tool."""
>
> import argparse
> import sys
>
> def define_options():
> parser = argparse.ArgumentParser()
> parser.add_argument("fname", help="input file", nargs="*")
>
> # create subparsers
> subparsers = parser.add_subparsers(dest="cmd", metavar="command")
>
> # create the parser for the "foo" command
> get_parser = subparsers.add_parser("foo", help="foo help")
> get_parser.add_argument("-n", help="number of foo to print",
> type=int, default=10)
>
> # create the parser for the "bar" command
> sum_parser = subparsers.add_parser("bar", help="bar help")
>
> return parser
>
>
> if __name__ == '__main__':
> args = define_options().parse_args()
>
> if not args.fname:
> content = sys.stdin.read()
> # do something
> else:
> for fname in args.fname:
> with(open(fname, "rt")) as f:
> content = f.read()
> # do somet
>
>
> Benoist
>
>
>
> Le Jul 31, 2012 à 11:55 AM, Oscar Benjamin a écrit :
>
>
> On Jul 31, 2012 10:32 AM, "Benoist Laurent"  wrote:
> >
> > Well sorry about that but it seems I was wrong.
> > It was Friday evening and I guess I've not been careful.
> >
> > Actually when you specify nargs="?",  the doc says "One argument will be
> consumed from the command line if possible, and produced as a single item".
> > So you can't pass several arguments to the program.
>
> Right below that in the docs it explains about using nargs='*' and
> nargs='+'. One of those will do what you want.
>
> Oscar.
>
> >
> > So, to rephrase the question, how can I get a argument parser that
> parses the command-line just as Unix grep would do?
> > i.e.
> >
> > $ echo 42 > foo.txt
> > $ echo 172 >> foo.txt
> > $ cp foo.txt bar.txt
> > $
> > $ grep 42 foo.txt
> > 42
> > $ grep 42 foo.txt bar.txt
> > foo.txt:42
> > bar.txt:42
> > $ cat foo.txt | grep 42
> > 42
> > $ grep -c 42 foo.txt
> > 1
> >
> >
> > Cheers,
> > Ben
> >
> >
> >
> >
> > Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :
> >
> >>
> >>
> >> Yes basically looks like you get it.
> >> I have to further test it but my first impression is that it's correct.
> >>
> >> So actually the point was to use nargs="?".
> >>
> >> Thank you very much.
> >> Ben
> >>
> >>
> >>
> >> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
> >>
> >>> Benoist Laurent wrote:
> >>>
>  I'm impletting a tool in Python.
> 
>  I'd like this tool to behave like a standard unix tool, as grep for
> 
>  exemple. I chose to use the argparse module to parse the command line
> and
> 
>  I think I'm getting into several limitations of this module.
> 
> 
> > First Question.
> 
>  How can I configure the the ArgumentParser to allow the user to give
> 
>  either an input file or to pipe the output from another program?
> 
> 
>  $ mytool.py file.txt
> 
>  $ cat file.txt | mytool.py
> >>>
> >>>
> >>> $ echo alpha > in.txt
> >>> $ cat in.txt | ./mytool.py
> >>> ALPHA
> >>> $ cat in.txt | ./mytool.py - out.txt
> >>> $ cat out.txt
> >>> ALPHA
> >>> $ ./mytool.py in.txt
> >>> ALPHA
> >>> $ ./mytool.py in.txt out2.txt
> >>> $ cat out2.txt
> >>> ALPHA
> >>> $ cat ./mytool.py
> >>> #!/usr/bin/env python
> >>> assert __name__ == "__main__"
> >>>
> >>> import argparse
> >>> import sys
> >>>
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument("infile", nargs="?", type=argparse.Fi

NameError vs AttributeError

[Ulrich Eckhardt]

Hi!

Using Python 2.7, I stumbled across the fact that 'self.xy' raises an 
AttributeError if self doesn't have an 'xy' as attribute, but 'xy' will 
instead raise a NameError. To some extent, these two are very similar, 
namely that the name 'xy' couldn't be resolved in a certain context, but 
they don't have a common baseclass.


I guess one of the reasons is behind the way that Python handles 
variable lookup, the plain 'xy' will find local and global names while 
'self.xy' will only look into onself. However, this vague idea is far 
from enough to explain it to someone else.


Can someone help me out?

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

Re: Linux shell to python

[Alister]

On Tue, 31 Jul 2012 08:15:32 +0100, Mark Lawrence wrote:

> On 31/07/2012 02:20, Dennis Lee Bieber wrote:
>> On Mon, 30 Jul 2012 22:56:48 +, Dan Stromberg 
>> declaimed the following in gmane.comp.python.general:
>>
>>
>>> Sigh, and I'm also not keen on multi-line list comprehensions,
>>> specifically because I think they tend to make less readable code.  It
>>> also becomes a mess when you need to insert print statements to get
>>> some visibility into what's going on.
>>
>>  Cleanly splitting the list-comp by
>>
>>  [ result-computation
>>  for-item-selection-clause if-filter-clause ]
>>
>> isn't that unreadable... But anyone doing
>>
>>  [ result-
>>  -computation for-item- -selection-clause if- -filter-
>>  -clause ]
>>
>> should be pecked to death by a dead parrot.
>>
>>
> Any particular species?

as has already been hinted - Norwegian Blue



-- 
Question: Is it better to abide by the rules until they're changed or
help speed the change by breaking them?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: argparse limitations

[Benoist Laurent]

Finally.

The code I proposed doesn't work in this case: if you add any positional 
argument to one of the subparsers, then the parsing doesn't work anymore.
The reason seems to be that argparse thinks the last argument of the first 
parser is the last but one argument.
Hence, if a subparser takes some arguments, it fails.

Example: if the "-n" argument of the foo parser is set mandatory (so becomes 
"n" instead of "-n")

python toto.py foo.txt bar.txt foo 10
usage: toto.py [-h] [fname [fname ...]] command ...
toto.py: error: argument command: invalid choice: '10' (choose from 'foo', 
'bar')


Any solution?

Cheers,
Ben



Le Jul 31, 2012 à 12:37 PM, Benoist Laurent a écrit :

> Really sorry about that.
> 
> So, for the community, below is the full code for a tool that behaves like a 
> Unix standard tool.
> It takes in argument the files to process and a command.
> 
> """Just to setup a command-line parser that acts just like a unix
> standard tool."""
> 
> import argparse
> import sys
> 
> def define_options():
> parser = argparse.ArgumentParser()
> parser.add_argument("fname", help="input file", nargs="*")
> 
> # create subparsers
> subparsers = parser.add_subparsers(dest="cmd", metavar="command")
> 
> # create the parser for the "foo" command
> get_parser = subparsers.add_parser("foo", help="foo help")
> get_parser.add_argument("-n", help="number of foo to print", 
> type=int, default=10)
> 
> # create the parser for the "bar" command
> sum_parser = subparsers.add_parser("bar", help="bar help")
> 
> return parser
> 
> 
> if __name__ == '__main__':
> args = define_options().parse_args()
> 
> if not args.fname:
> content = sys.stdin.read()
> # do something
> else:
> for fname in args.fname:
> with(open(fname, "rt")) as f:
> content = f.read()
> # do somet
> 
> 
> Benoist
> 
> 
> 
> Le Jul 31, 2012 à 11:55 AM, Oscar Benjamin a écrit :
> 
>> 
>> On Jul 31, 2012 10:32 AM, "Benoist Laurent"  wrote:
>> >
>> > Well sorry about that but it seems I was wrong.
>> > It was Friday evening and I guess I've not been careful.
>> >
>> > Actually when you specify nargs="?",  the doc says "One argument will be 
>> > consumed from the command line if possible, and produced as a single item".
>> > So you can't pass several arguments to the program.
>> 
>> Right below that in the docs it explains about using nargs='*' and 
>> nargs='+'. One of those will do what you want.
>> 
>> Oscar.
>> 
>> >
>> > So, to rephrase the question, how can I get a argument parser that parses 
>> > the command-line just as Unix grep would do?
>> > i.e.
>> >
>> > $ echo 42 > foo.txt
>> > $ echo 172 >> foo.txt
>> > $ cp foo.txt bar.txt
>> > $
>> > $ grep 42 foo.txt
>> > 42
>> > $ grep 42 foo.txt bar.txt
>> > foo.txt:42
>> > bar.txt:42
>> > $ cat foo.txt | grep 42
>> > 42
>> > $ grep -c 42 foo.txt
>> > 1
>> >
>> >
>> > Cheers,
>> > Ben
>> >
>> >
>> >
>> >
>> > Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :
>> >
>> >>
>> >>
>> >> Yes basically looks like you get it.
>> >> I have to further test it but my first impression is that it's correct.
>> >>
>> >> So actually the point was to use nargs="?".
>> >>
>> >> Thank you very much.
>> >> Ben
>> >>
>> >>
>> >>
>> >> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
>> >>
>> >>> Benoist Laurent wrote:
>> >>>
>>  I'm impletting a tool in Python.
>> 
>>  I'd like this tool to behave like a standard unix tool, as grep for
>> 
>>  exemple. I chose to use the argparse module to parse the command line 
>>  and
>> 
>>  I think I'm getting into several limitations of this module.
>> 
>> 
>> > First Question.
>> 
>>  How can I configure the the ArgumentParser to allow the user to give
>> 
>>  either an input file or to pipe the output from another program?
>> 
>> 
>>  $ mytool.py file.txt
>> 
>>  $ cat file.txt | mytool.py
>> >>>
>> >>>
>> >>> $ echo alpha > in.txt
>> >>> $ cat in.txt | ./mytool.py 
>> >>> ALPHA
>> >>> $ cat in.txt | ./mytool.py - out.txt
>> >>> $ cat out.txt 
>> >>> ALPHA
>> >>> $ ./mytool.py in.txt 
>> >>> ALPHA
>> >>> $ ./mytool.py in.txt out2.txt
>> >>> $ cat out2.txt 
>> >>> ALPHA
>> >>> $ cat ./mytool.py
>> >>> #!/usr/bin/env python
>> >>> assert __name__ == "__main__"
>> >>>
>> >>> import argparse
>> >>> import sys
>> >>>
>> >>> parser = argparse.ArgumentParser()
>> >>> parser.add_argument("infile", nargs="?", type=argparse.FileType("r"), 
>> >>> default=sys.stdin)
>> >>> parser.add_argument("outfile", nargs="?", type=argparse.FileType("w"), 
>> >>> default=sys.stdout)
>> >>> args = parser.parse_args()
>> >>>
>> >>> args.outfile.writelines(line.upper() for line in args.infile)
>> >>>
>> >>> Is that good enough?
>> >>>
>> >>>
>> >>> -- 
>> >>> http://mail.python.org/mailman/listinfo/python-list
>> >>>
>> >>
>> >> -- 
>> >> Benoist Laurent
>> >> Laboratoire de 

Re: argparse limitations

[Benoist Laurent]

Really sorry about that.

So, for the community, below is the full code for a tool that behaves like a 
Unix standard tool.
It takes in argument the files to process and a command.

"""Just to setup a command-line parser that acts just like a unix
standard tool."""

import argparse
import sys

def define_options():
parser = argparse.ArgumentParser()
parser.add_argument("fname", help="input file", nargs="*")

# create subparsers
subparsers = parser.add_subparsers(dest="cmd", metavar="command")

# create the parser for the "foo" command
get_parser = subparsers.add_parser("foo", help="foo help")
get_parser.add_argument("-n", help="number of foo to print", 
type=int, default=10)

# create the parser for the "bar" command
sum_parser = subparsers.add_parser("bar", help="bar help")

return parser


if __name__ == '__main__':
args = define_options().parse_args()

if not args.fname:
content = sys.stdin.read()
# do something
else:
for fname in args.fname:
with(open(fname, "rt")) as f:
content = f.read()
# do somet


Benoist



Le Jul 31, 2012 à 11:55 AM, Oscar Benjamin a écrit :

> 
> On Jul 31, 2012 10:32 AM, "Benoist Laurent"  wrote:
> >
> > Well sorry about that but it seems I was wrong.
> > It was Friday evening and I guess I've not been careful.
> >
> > Actually when you specify nargs="?",  the doc says "One argument will be 
> > consumed from the command line if possible, and produced as a single item".
> > So you can't pass several arguments to the program.
> 
> Right below that in the docs it explains about using nargs='*' and nargs='+'. 
> One of those will do what you want.
> 
> Oscar.
> 
> >
> > So, to rephrase the question, how can I get a argument parser that parses 
> > the command-line just as Unix grep would do?
> > i.e.
> >
> > $ echo 42 > foo.txt
> > $ echo 172 >> foo.txt
> > $ cp foo.txt bar.txt
> > $
> > $ grep 42 foo.txt
> > 42
> > $ grep 42 foo.txt bar.txt
> > foo.txt:42
> > bar.txt:42
> > $ cat foo.txt | grep 42
> > 42
> > $ grep -c 42 foo.txt
> > 1
> >
> >
> > Cheers,
> > Ben
> >
> >
> >
> >
> > Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :
> >
> >>
> >>
> >> Yes basically looks like you get it.
> >> I have to further test it but my first impression is that it's correct.
> >>
> >> So actually the point was to use nargs="?".
> >>
> >> Thank you very much.
> >> Ben
> >>
> >>
> >>
> >> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
> >>
> >>> Benoist Laurent wrote:
> >>>
>  I'm impletting a tool in Python.
> 
>  I'd like this tool to behave like a standard unix tool, as grep for
> 
>  exemple. I chose to use the argparse module to parse the command line and
> 
>  I think I'm getting into several limitations of this module.
> 
> 
> > First Question.
> 
>  How can I configure the the ArgumentParser to allow the user to give
> 
>  either an input file or to pipe the output from another program?
> 
> 
>  $ mytool.py file.txt
> 
>  $ cat file.txt | mytool.py
> >>>
> >>>
> >>> $ echo alpha > in.txt
> >>> $ cat in.txt | ./mytool.py 
> >>> ALPHA
> >>> $ cat in.txt | ./mytool.py - out.txt
> >>> $ cat out.txt 
> >>> ALPHA
> >>> $ ./mytool.py in.txt 
> >>> ALPHA
> >>> $ ./mytool.py in.txt out2.txt
> >>> $ cat out2.txt 
> >>> ALPHA
> >>> $ cat ./mytool.py
> >>> #!/usr/bin/env python
> >>> assert __name__ == "__main__"
> >>>
> >>> import argparse
> >>> import sys
> >>>
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument("infile", nargs="?", type=argparse.FileType("r"), 
> >>> default=sys.stdin)
> >>> parser.add_argument("outfile", nargs="?", type=argparse.FileType("w"), 
> >>> default=sys.stdout)
> >>> args = parser.parse_args()
> >>>
> >>> args.outfile.writelines(line.upper() for line in args.infile)
> >>>
> >>> Is that good enough?
> >>>
> >>>
> >>> -- 
> >>> http://mail.python.org/mailman/listinfo/python-list
> >>>
> >>
> >> -- 
> >> Benoist Laurent
> >> Laboratoire de Biochimie Theorique / CNRS UPR 9080
> >> Institut de Biologie Physico-Chimique
> >> 13, rue Pierre et Marie Curie
> >> F-75005 Paris
> >> Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56
> >>
> >> -- 
> >> http://mail.python.org/mailman/listinfo/python-list
> >
> >
> > -- 
> > Benoist Laurent
> > Laboratoire de Biochimie Theorique / CNRS UPR 9080
> > Institut de Biologie Physico-Chimique
> > 13, rue Pierre et Marie Curie
> > F-75005 Paris
> > Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56
> >
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >

-- 
Benoist Laurent
Laboratoire de Biochimie Theorique / CNRS UPR 9080
Institut de Biologie Physico-Chimique
13, rue Pierre et Marie Curie
F-75005 Paris
Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56

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

Re: argparse limitations

[Oscar Benjamin]

On Jul 31, 2012 10:32 AM, "Benoist Laurent"  wrote:
>
> Well sorry about that but it seems I was wrong.
> It was Friday evening and I guess I've not been careful.
>
> Actually when you specify nargs="?",  the doc says "One argument will be
consumed from the command line if possible, and produced as a single item".
> So you can't pass several arguments to the program.

Right below that in the docs it explains about using nargs='*' and
nargs='+'. One of those will do what you want.

Oscar.

>
> So, to rephrase the question, how can I get a argument parser that parses
the command-line just as Unix grep would do?
> i.e.
>
> $ echo 42 > foo.txt
> $ echo 172 >> foo.txt
> $ cp foo.txt bar.txt
> $
> $ grep 42 foo.txt
> 42
> $ grep 42 foo.txt bar.txt
> foo.txt:42
> bar.txt:42
> $ cat foo.txt | grep 42
> 42
> $ grep -c 42 foo.txt
> 1
>
>
> Cheers,
> Ben
>
>
>
>
> Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :
>
>>
>>
>> Yes basically looks like you get it.
>> I have to further test it but my first impression is that it's correct.
>>
>> So actually the point was to use nargs="?".
>>
>> Thank you very much.
>> Ben
>>
>>
>>
>> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
>>
>>> Benoist Laurent wrote:
>>>
 I'm impletting a tool in Python.

 I'd like this tool to behave like a standard unix tool, as grep for

 exemple. I chose to use the argparse module to parse the command line
and

 I think I'm getting into several limitations of this module.


> First Question.

 How can I configure the the ArgumentParser to allow the user to give

 either an input file or to pipe the output from another program?


 $ mytool.py file.txt

 $ cat file.txt | mytool.py
>>>
>>>
>>> $ echo alpha > in.txt
>>> $ cat in.txt | ./mytool.py
>>> ALPHA
>>> $ cat in.txt | ./mytool.py - out.txt
>>> $ cat out.txt
>>> ALPHA
>>> $ ./mytool.py in.txt
>>> ALPHA
>>> $ ./mytool.py in.txt out2.txt
>>> $ cat out2.txt
>>> ALPHA
>>> $ cat ./mytool.py
>>> #!/usr/bin/env python
>>> assert __name__ == "__main__"
>>>
>>> import argparse
>>> import sys
>>>
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("infile", nargs="?", type=argparse.FileType("r"),
>>> default=sys.stdin)
>>> parser.add_argument("outfile", nargs="?", type=argparse.FileType("w"),
>>> default=sys.stdout)
>>> args = parser.parse_args()
>>>
>>> args.outfile.writelines(line.upper() for line in args.infile)
>>>
>>> Is that good enough?
>>>
>>>
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>>
>>
>> --
>> Benoist Laurent
>> Laboratoire de Biochimie Theorique / CNRS UPR 9080
>> Institut de Biologie Physico-Chimique
>> 13, rue Pierre et Marie Curie
>> F-75005 Paris
>> Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
> --
> Benoist Laurent
> Laboratoire de Biochimie Theorique / CNRS UPR 9080
> Institut de Biologie Physico-Chimique
> 13, rue Pierre et Marie Curie
> F-75005 Paris
> Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: argparse limitations

[Benoist Laurent]

Well sorry about that but it seems I was wrong.
It was Friday evening and I guess I've not been careful.

Actually when you specify nargs="?",  the doc says "One argument will be 
consumed from the command line if possible, and produced as a single item".
So you can't pass several arguments to the program.

So, to rephrase the question, how can I get a argument parser that parses the 
command-line just as Unix grep would do?
i.e.

$ echo 42 > foo.txt
$ echo 172 >> foo.txt
$ cp foo.txt bar.txt
$
$ grep 42 foo.txt
42
$ grep 42 foo.txt bar.txt
foo.txt:42
bar.txt:42
$ cat foo.txt | grep 42
42
$ grep -c 42 foo.txt
1


Cheers,
Ben




Le Jul 27, 2012 à 7:08 PM, Benoist Laurent a écrit :

> 
> 
> Yes basically looks like you get it.
> I have to further test it but my first impression is that it's correct.
> 
> So actually the point was to use nargs="?".
> 
> Thank you very much.
> Ben
> 
> 
> 
> Le Jul 27, 2012 à 5:44 PM, Peter Otten a écrit :
> 
>> Benoist Laurent wrote:
>> 
>>> I'm impletting a tool in Python.
>>> I'd like this tool to behave like a standard unix tool, as grep for
>>> exemple. I chose to use the argparse module to parse the command line and
>>> I think I'm getting into several limitations of this module.
>>> 
 First Question.
>>> How can I configure the the ArgumentParser to allow the user to give
>>> either an input file or to pipe the output from another program?
>>> 
>>> $ mytool.py file.txt
>>> $ cat file.txt | mytool.py
>> 
>> $ echo alpha > in.txt
>> $ cat in.txt | ./mytool.py 
>> ALPHA
>> $ cat in.txt | ./mytool.py - out.txt
>> $ cat out.txt 
>> ALPHA
>> $ ./mytool.py in.txt 
>> ALPHA
>> $ ./mytool.py in.txt out2.txt
>> $ cat out2.txt 
>> ALPHA
>> $ cat ./mytool.py
>> #!/usr/bin/env python
>> assert __name__ == "__main__"
>> 
>> import argparse
>> import sys
>> 
>> parser = argparse.ArgumentParser()
>> parser.add_argument("infile", nargs="?", type=argparse.FileType("r"), 
>> default=sys.stdin)
>> parser.add_argument("outfile", nargs="?", type=argparse.FileType("w"), 
>> default=sys.stdout)
>> args = parser.parse_args()
>> 
>> args.outfile.writelines(line.upper() for line in args.infile)
>> 
>> Is that good enough?
>> 
>> 
>> -- 
>> http://mail.python.org/mailman/listinfo/python-list
>> 
> 
> -- 
> Benoist Laurent
> Laboratoire de Biochimie Theorique / CNRS UPR 9080
> Institut de Biologie Physico-Chimique
> 13, rue Pierre et Marie Curie
> F-75005 Paris
> Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

-- 
Benoist Laurent
Laboratoire de Biochimie Theorique / CNRS UPR 9080
Institut de Biologie Physico-Chimique
13, rue Pierre et Marie Curie
F-75005 Paris
Tel. +33 [0]1 58 41 51 67 or +33 [0]6 21 64 50 56

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

Re: Linux shell to python

[Chris Angelico]

On Tue, Jul 31, 2012 at 5:15 PM, Mark Lawrence  wrote:
> On 31/07/2012 02:20, Dennis Lee Bieber wrote:
>>
>> should be pecked to death by a dead parrot.
>>
>
> Any particular species?

I'm sure that, if you're in Norway, you could find an appropriate
bird. But for those of us for whom that's not an option, I'd be
content to nail the programmer's feet to the cage and then return him
whence he came as a faulty model. Unfortunately local law enforcement
would want in on that deal.

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

Re: Linux shell to python

[Mark Lawrence]

On 31/07/2012 02:20, Dennis Lee Bieber wrote:

On Mon, 30 Jul 2012 22:56:48 +, Dan Stromberg 
declaimed the following in gmane.comp.python.general:



Sigh, and I'm also not keen on multi-line list comprehensions, specifically
because I think they tend to make less readable code.  It also becomes a
mess when you need to insert print statements to get some visibility into
what's going on.


Cleanly splitting the list-comp by

[ result-computation
for-item-selection-clause
if-filter-clause ]

isn't that unreadable... But anyone doing

[ result-
-computation for-item-
-selection-clause if-
-filter-
-clause ]

should be pecked to death by a dead parrot.



Any particular species?

--
Cheers.

Mark Lawrence.

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