Hello, Everyone. I have a problem when using Pexpect module.

[dachuan]

hi, everyone.
When I use Pexpect Module, I met the following problem and don't know how to
handle it.
Any advice is appreciated !

My environment:
Linux node08_xen3.4.3_rhel5_1 2.6.18.8-xen #1 SMP Wed Jul 14 17:20:01 CST
2010 i686 i686 i386 GNU/Linux  (FYI: this is a virtual machine.)
Python 2.5.5

and by the way, I have installed pexpect in another machine, and it works
pretty well, its environment is:
Linux WEB1 2.6.9-42.ELlargesmp #1 SMP Wed Jul 12 23:46:39 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux
Python 2.5.5


-bash-3.1$ ./ssh_mutual_trust.py -n
Traceback (most recent call last):
  File "./ssh_mutual_trust.py", line 427, in 
start(sys.argv[1:])
  File "./ssh_mutual_trust.py", line 405, in start
sshkeygen()
  File "./ssh_mutual_trust.py", line 137, in sshkeygen
keygen_child = pexpect.spawn(new_keygen_cmd)
  File "/usr/local/lib/python2.5/site-packages/pexpect.py", line 430, in
__init__
self._spawn (command, args)
  File "/usr/local/lib/python2.5/site-packages/pexpect.py", line 530, in
_spawn
raise ExceptionPexpect('Error! pty.fork() failed: ' + str(e))
pexpect.ExceptionPexpect: Error! pty.fork() failed: out of pty devices
-bash-3.1$


-- 
Dachuan Huang, Graduate Candidate
---
Cluster and Grid Computing Lab
Services Computing Technology and System Lab
Huazhong University of Science and Technology
Wuhan, 430074, China
Tel: +86-15902733227

Email: hdc1...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[rantingrick]

On Nov 4, 9:47 pm, Rustom Mody  wrote:
> However the original question -- mixing
> tabs and spaces is bad -- has got lost in the flames.  Do the most
> die-hard python fanboys deny this?

Hey we need to get something strait right now... i am the only true
fanboy around here, all the others are puesdo fanboys. Got it! ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Terry Reedy]

On 11/4/2010 10:47 PM, Rustom Mody wrote:


As far as I am concerned python would not be python if its
indentation=structure went.  However the original question -- mixing
tabs and spaces is bad -- has got lost in the flames.  Do the most
die-hard python fanboys deny this?


Of course not. Not mixing tabs and spaces has been the recommendation 
for perhaps a decade.



And if not is it asking too much (say in python3) that mixing tabs and spaces

> be flagged as an error or at least warning?

Making all mixture an error was considered but rejected as causing too 
much gratuitous breakage. One reason: you cut code from some source with 
the 'other' style and paste into code with 'your' style. Should you be 
*forced* (rather than merely advised) to convert before running the 
result even once. Guido decided that there was enough breakage from 
important things like unicode text and all new-style classes.


On the other hand, someone said that ambiguous mixtures now are prohibited.

--
Terry Jan Reedy

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

Re: Best method for a menu in a command line program?

[Terry Reedy]

On 11/4/2010 7:51 PM, Ben Finney wrote:

Terry Reedy  writes:


Others have answered that, but I would point to the inefficiency for
users of having to enter unit and value on two separate lines. The
prompt could be "Enter value and unit (f, c, or k) or q to quit: "
Allow upper and lower case, with or without a space between.


Well, if we're going to critique the design, I'd say that I find the GNU
Units programhttp://www.gnu.org/software/units/units.html>  to be a
good flexible implementation of a command-line units converter.

I suspect, though, that the object of the OP was not so much to make a
good unit converter, but rather to learn from a simple example exercise.


Right. I think he would learn something from the exercize I suggest.

--
Terry Jan Reedy

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

Re: Compare source code

[Rustom Mody]

The real issue is not tabs/spaces vs braces but academic/scientific
orientation vs engineering/commercial needs.
Mostly these worlds are so far separated that no dialogue happens --
think C vs Pascal, Java vs Eiffel etc

The problem -- actually advantage -- is that Python straddles both worlds.
Mailers messing code, even editors messing (large) refactorings are
engineering concerns.
The visual clarity of (usually small) pieces of code is an academic concern.

Ive been in both worlds: being able to have a significant piece of
code projected on a single screen is often the single biggest factor
which makes something teachable or not.  And indentation based
structure is not the only thing that aids this in languages like
python and haskell -- think of comprehensions, no type declarations,
REPL removing the need for (most) print statements etc etc.

Conversely there are 'real-world' situations where python's
indentation breaks things -- eg python-server-pages where python's
indentation mixes badly with html's  

As far as I am concerned python would not be python if its
indentation=structure went.  However the original question -- mixing
tabs and spaces is bad -- has got lost in the flames.  Do the most
die-hard python fanboys deny this?  And if not is it asking too much
(say in python3) that mixing tabs and spaces be flagged as an error or
at least warning?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess.Popen not replacing current process?

[Lawrence D'Oliveiro]

In message
<7c5be6d7-5782-44ad-aae7-7f7bbc798...@n32g2000prc.googlegroups.com>, goodman 
wrote:

> Though I'm still a little confused how, if subprocess.Popen is using
> os.execvp, it still maintains control of things like interrupts.

The implied point, being that we are spawning subprocesses, is that there is 
a fork call before the exec.

> Anyway, my problem is solved. Thanks!

Glad to hear it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Jeremy]

On Nov 4, 5:08 pm, Ned Deily  wrote:
> In article <6f087ce1-5391-4ee3-b92a-5a499fdf0...@semanchuk.com>,
>  Philip Semanchuk  wrote:
>
> > You might want to try this before running tar to see if it inhibits the ._
> > files:
> > export COPYFILE_DISABLE=True
>
> > I know that tells tar to ignore those files (resource forks, no?) when
> > building a tarball. I don't know if it helps with extraction though.
>
> Interesting.  It's been so long since I've had to deal with ._ 's (which
> is where metadata for extended attributes including resource forks are
> stored), I had forgotten about that poorly documented option for 10.5
> and 10.6.
>
> A little experiment: from OS X 10.6, I NFS-mount a remote Linux (ext3)
> file system and have created files on it with extended attributes.  
> Using ls on either the OS X or the Linux side, the ._ files appear as
> regular files.  On the Linux side,  I use gnu tar to archive the files
> and move that archive back to OS X.  If I then use the stock Apple 10.6
> tar to extract that archive to an HFS+ directory, the extended
> attributes are by default restored properly (they can be viewed with ls
> -l@) and no '._' files - great!  If I first export
> COPYFILE_DISABLE=True, then the tar extraction appears to ignore the ._
> files: the extended attributes are not set and the ._ files still do not
> appear.
>
> So the COPYFILE_DISABLE trick may very well work for this issue.  It
> still raises the question of why the ._ files are being created in the
> first place.  They shouldn't be on the python.org tarball so it would
> seem most likely they are due to some operation on the OS X machine that
> causes extended attributes to be created.  Nothing wrong with that, just
> kind of interesting.
>
> --
>  Ned Deily,
>  n...@acm.org

What I have done is perform the installation on a local hard drive
(not network storage).  This prevents any ._* files from being
created.  Now I just have to copy the installation to ~/Library/
Frameworks or just link to the local copy.  I started the compilation
when I left, tomorrow I'll finish up and see how it went.  I don't
anticipate any more problems.

Thanks,
Jeremy
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Tim Harig]

On 2010-11-04, Ben Finney  wrote:
> As has been noted before, there is no intuitive interface except the
> nipple. Everything else is not intuitive, but must be learned.

What exactly is so intuitive about being slapped in the face followed by
being slapped with a lawsuit?
-- 
http://mail.python.org/mailman/listinfo/python-list

C++ comment in Javadoc style -> reStructuredText compiler?

[Xavier Ho]

Hey all,

Apologies if I am posting this in the wrong list. Does anyone know of a good
compiler for javadoc comment style into reStructuredText, for Sphinx to
chew?

Cheers,
Xavier
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Ben Finney]

Tim Harig  writes:

> On 2010-11-04, Mark Wooding  wrote:
> > Tim Harig  writes:
> >> Actually, the left arrow key does not work at all intuitively. One
> >> would expect that it should go back to the previous page as it
> >> would in lynx, etc. It does not.
> >
> > It moves the cursor so you can hit links.  The l key takes you back
> > through your recent viewing history -- and has done for thirty years.
>
> As I said, that is probably intuitive for Emacs users; but, not all
> *nix users are Emacs users. To those of us that are not, the info
> interface seems quite alien.

You might make more headway in this discussion if you avoided conflating
“intuitive” (no computer UI is intuitive) with “familiar” (which is
relative to each user).

As has been noted before, there is no intuitive interface except the
nipple. Everything else is not intuitive, but must be learned.

-- 
 \   “Facts are meaningless. You could use facts to prove anything |
  `\that's even remotely true!” —Homer, _The Simpsons_ |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing File Objects into Subprocess.Popen

[Christian Heimes]

Am 04.11.2010 23:49, schrieb Brandon Harris:
>   What do you mean by rewind the file pointer before reading from it? 
> Seek back to the beginning? And It sounded very unlikely to me too, but 
> it's the only thing I have found that explains why a very verbose job 
> with tons of feedback locks up at the same point and won't process at all.

Look at a file handler like an old style magnetic tape. You just have
recorded your favorite song from radio onto a tape. What do you have to
do in order to listen to the song again? Press play? No, you have to
rewind first.

The MP3 generation will never understand the hard work of a mix tape
created recorded from radio broadcasts. ;)

Christian

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

Re: subprocess.Popen not replacing current process?

[goodman]

On Nov 4, 4:43 pm, Lawrence D'Oliveiro  wrote:
> In message
> <0f1a17f4-b6a9-4e89-ac26-74b1098a0...@b19g2000prj.googlegroups.com>, goodman
> wrote:
>
> > Hi, I'm wondering why subprocess.Popen does not seem to replace the
> > current process, even when it uses os.execvp (according to the
> > documentation:
> >http://docs.python.org/library/subprocess.html#subprocess.Popen).
>
> You’ll notice that in the list at the top of the functions that subprocess
> replaces, there are no os.exec* entries. subprocess is only for spawning new
> processes; if all you need to do is an exec, do an exec
> ; subprocess
> can’t offer anything to make that any simpler.

Thanks Lawrence. Forgive my recent followup, as I posted it before I
saw your message. I noticed that the exec*s were not replaced by
subprocess, so that makes sense to just use exec. Though I'm still a
little confused how, if subprocess.Popen is using os.execvp, it still
maintains control of things like interrupts.

Anyway, my problem is solved. Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best method for a menu in a command line program?

[Ben Finney]

braden faulkner  writes:

> Sorry, I wasn't aware it was doing that but... I've removed it :-)

Thank you, it's good to keep a polite discourse going :-)

-- 
 \“I don't accept the currently fashionable assertion that any |
  `\   view is automatically as worthy of respect as any equal and |
_o__)   opposite view.” —Douglas Adams |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best method for a menu in a command line program?

[Ben Finney]

Terry Reedy  writes:

> Others have answered that, but I would point to the inefficiency for
> users of having to enter unit and value on two separate lines. The
> prompt could be "Enter value and unit (f, c, or k) or q to quit: "
> Allow upper and lower case, with or without a space between.

Well, if we're going to critique the design, I'd say that I find the GNU
Units program http://www.gnu.org/software/units/units.html> to be a
good flexible implementation of a command-line units converter.

I suspect, though, that the object of the OP was not so much to make a
good unit converter, but rather to learn from a simple example exercise.

-- 
 \  “I am too firm in my consciousness of the marvelous to be ever |
  `\   fascinated by the mere supernatural …” —Joseph Conrad, _The |
_o__) Shadow-Line_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess.Popen not replacing current process?

[goodman]

On Nov 4, 1:22 am, goodman  wrote:
> Note: Our server is a Linux machine, but we're restricted to Python
> 2.4.
>
> Hi, I'm wondering why subprocess.Popen does not seem to replace the
> current process, even when it uses os.execvp (according to the
> documentation:http://docs.python.org/library/subprocess.html#subprocess.Popen).
> Specifically, when I try to kill a spawned process with Ctrl-C, the
> SIGINT does not seem to be sent to the spawned process.
>
> Some background: I have a Python script that calls shell scripts or
> commands. It does not need to regain control after calling these
> scripts or commands, so up to now I've been using an os.exec* command.
> It seems the subprocess module is the recommended way for spawning
> processes, but in this case perhaps it's better I stick with os.exec*?
> I've seen plenty of discussion about catching KeyboardInterrupt in the
> parent process and then manually killing the child, but (1) I can't
> use Popen.kill() on Python 2.4, and (2) this level of process
> management seems like overkill (pardon the potential for puns) in my
> case.
>
> Thanks for any help.

Following up, I can get the effect I want with the following:

try:
  p = subprocess.Popen([cmd, arg1, arg2])
  p.wait()
except KeyboardInterrupt:
  import signal
  os.kill(p.pid, signal.SIGKILL)

...but like I said, I don't think I should be managing this myself,
since I don't need to return from the new process. How can I make the
new process handle its own signals?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess.Popen not replacing current process?

[Lawrence D'Oliveiro]

In message
<0f1a17f4-b6a9-4e89-ac26-74b1098a0...@b19g2000prj.googlegroups.com>, goodman 
wrote:

> Hi, I'm wondering why subprocess.Popen does not seem to replace the
> current process, even when it uses os.execvp (according to the
> documentation:
> http://docs.python.org/library/subprocess.html#subprocess.Popen).

You’ll notice that in the list at the top of the functions that subprocess 
replaces, there are no os.exec* entries. subprocess is only for spawning new 
processes; if all you need to do is an exec, do an exec 
; subprocess 
can’t offer anything to make that any simpler.

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

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Ned Deily]

In article <6f087ce1-5391-4ee3-b92a-5a499fdf0...@semanchuk.com>,
 Philip Semanchuk  wrote:
> You might want to try this before running tar to see if it inhibits the ._ 
> files:
> export COPYFILE_DISABLE=True
> 
> 
> I know that tells tar to ignore those files (resource forks, no?) when 
> building a tarball. I don't know if it helps with extraction though.

Interesting.  It's been so long since I've had to deal with ._ 's (which 
is where metadata for extended attributes including resource forks are 
stored), I had forgotten about that poorly documented option for 10.5 
and 10.6.

A little experiment: from OS X 10.6, I NFS-mount a remote Linux (ext3) 
file system and have created files on it with extended attributes.  
Using ls on either the OS X or the Linux side, the ._ files appear as 
regular files.  On the Linux side,  I use gnu tar to archive the files 
and move that archive back to OS X.  If I then use the stock Apple 10.6 
tar to extract that archive to an HFS+ directory, the extended 
attributes are by default restored properly (they can be viewed with ls 
-l@) and no '._' files - great!  If I first export 
COPYFILE_DISABLE=True, then the tar extraction appears to ignore the ._ 
files: the extended attributes are not set and the ._ files still do not 
appear.

So the COPYFILE_DISABLE trick may very well work for this issue.  It 
still raises the question of why the ._ files are being created in the 
first place.  They shouldn't be on the python.org tarball so it would 
seem most likely they are due to some operation on the OS X machine that 
causes extended attributes to be created.  Nothing wrong with that, just 
kind of interesting.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Man pages and info pages

[Mark Wooding]

Tim Harig  writes:

> Right, and in info with the default key bindings, backspace takes me
> to the command help.  I would have expected it to either scroll up the
> page or take me to the previously visited node.

Sounds like your terminal is misconfigured.  Backspace should produce
^?, not ^H.  (Delete should produce some awful escape sequence.)

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing File Objects into Subprocess.Popen

[Brandon Harris]

 ok. Jumping back to the start of the file solved the problem. 
(file.seek(0)) Big thanks for that insight!


Brandon L. Harris


On 11/04/2010 05:49 PM, Brandon Harris wrote:
 What do you mean by rewind the file pointer before reading from it? 
Seek back to the beginning? And It sounded very unlikely to me too, 
but it's the only thing I have found that explains why a very verbose 
job with tons of feedback locks up at the same point and won't process 
at all.


I did try running communicate before and after the wait() but to no 
avail.


Brandon L. Harris


On 11/04/2010 05:39 PM, Antoine Pitrou wrote:

Try to rewind the file pointer before reading from it.




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

Re: functions, list, default parameters

[Mark Wooding]

Lawrence D'Oliveiro  writes:

> Mediocre programmers with a hankering towards cleverness latch onto it
> as an ingenious way of maintaing persistent context in-between calls
> to a function, completely overlooking the fact that Python offers much
> more straightforward, comprehensible, flexible, and above all
> maintainable ways of doing that sort of thing.

It does nowadays.  Once upon a time, Python didn't have proper closures,
and argument defaults, evaluated at function-definition time, were the
only way of capturing data from the surrounding environment.  You may be
confusing `mediocre' with `old-fashioned', and `a hankering towards
cleverness' with `wanting to run code on old Python interpreters'.  This
last may be because the relevant code was written back when those `old'
interpreters were shiny and new.

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: functions, list, default parameters

[Mark Wooding]

Lawrence D'Oliveiro  writes:

> In message <20101021235138.609fe...@geekmail.invalid>, Andreas
> Waldenburger wrote:
> > While not very commonly needed, why should a shared default argument be
> > forbidden?
>
> Because it’s safer to disallow it than to allow it.

Scissors with rounded ends are safer than scissors without.  Chopsticks
and plastic sporks are safer than metal cutlery.  We have sharp things
because they're /useful/.  Similarly, having mutable objects as argument
defaults can be useful.

(Based on experience with other languages, I suspect that evaluating the
default expression afresh for each call where it's needed would be more
useful; but it's way too late to change that now.)

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing File Objects into Subprocess.Popen

[Brandon Harris]

 What do you mean by rewind the file pointer before reading from it? 
Seek back to the beginning? And It sounded very unlikely to me too, but 
it's the only thing I have found that explains why a very verbose job 
with tons of feedback locks up at the same point and won't process at all.


I did try running communicate before and after the wait() but to no avail.

Brandon L. Harris


On 11/04/2010 05:39 PM, Antoine Pitrou wrote:

Try to rewind the file pointer before reading from it.


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

Re: Passing File Objects into Subprocess.Popen

[Antoine Pitrou]

On Thu, 04 Nov 2010 17:13:09 -0500
Brandon Harris  wrote:
>   I'm running python 2.5 and have bumped into an issue whereby the PIPE 
> in subprocess.Popen locks up after taking too many characters. I found 
> some documentation that discuss this problem and offers some ideas for 
> solutions, the best one being to pass a file object into subprocess 
> instead of PIPE.

This sounds rather unlikely. Have you used communicate()?

>  process = subprocess.Popen(my_cmd, stderr=my_stderr, stdout=my_stdout)
>  process.wait()
> 
>  print my_stderr.read()
>  print my_stdout.read()

Try to rewind the file pointer before reading from it.

Regards

Antoine.


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

Passing File Objects into Subprocess.Popen

[Brandon Harris]

 I'm running python 2.5 and have bumped into an issue whereby the PIPE 
in subprocess.Popen locks up after taking too many characters. I found 
some documentation that discuss this problem and offers some ideas for 
solutions, the best one being to pass a file object into subprocess 
instead of PIPE. This will allow for much larger std output.


http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/

The problem is that, while I can pass in a tempfile.TemporaryFile() and 
everything seems to go swimmingly, there doesn't seem to be anything 
written to file I handed Popen.


import tempfile
import subprocess

def awesome():
# I understand that not everyone has nuke, but it doesn't seem to 
matter what I run through it

# the result is the same.
my_cmd = '/usr/local/Nuke6.0v3/Nuke6.0 -V'

my_stderr = tempfile.TemporaryFile()
my_stdout = tempfile.TemporaryFile()

process = subprocess.Popen(my_cmd, stderr=my_stderr, stdout=my_stdout)
process.wait()

print my_stderr.read()
print my_stdout.read()

print "Finished!!!"

Any help on this issue would be awesome! thanks!

Brandon L. Harris



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

Re: Compare source code

[Seebs]

On 2010-11-04, Terry Reedy  wrote:
> I am sorry you feel compelled to use a language you so dislike. Not our 
> fault though.

I don't dislike it all that much.  What I dislike is being told that the
problems don't exist.

> If you add the normally redundant information in the form of explicit 
> dedents (anything starting with '#' and distinguishable from normal 
> comments), then it is not too hard to re-indent even after all indents 
> have been removed. I believe this has been dome more than once. By using 
> a stylized comment, the augmented code runs without preprocessing. I 
> also believe at lease one person has written a preprocessor for 
> 'python-with-braces'.

Yes.  They did this because there is no reason that anyone would ever
prefer it or find some benefit to it, of course.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Grant Edwards  wrote:
> It exists because so many people change whitespace intentionally in C
> source code because no two C programmers seem able to agree on how to
> format code.  Diff -b allows you to attempt to ignore semantically
> null stylistic changes made by programmers.

I don't agree with this interpretation, just because the changes it
filters out are hardly ever intentional when I actually look at them.

They're a mix of space/tab changes which don't affect actual indentation,
trailing whitespace, and the like.

The kinds of changes that would be made by C programmers trying to change
source formatting are usually far beyond what "diff -b" would "fix".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Final state of underlying sequence in islice

[Terry Reedy]

On 11/4/2010 12:42 PM, Shashank Singh wrote:


Are there any promises made with regard to final state of the underlying
sequence that islice slices?


The one you quote below.


for example consider this

 >>> from itertools import *
 >>> c = count()
 >>> list(islice(c, 1, 3, 50))
[1]
 >>> c.next()
51


When posting code and result, it is always a good idea to include 
version. It is even more important when reporting a (possible) bug, 
which might have been fixed already. As it turns out, I get the same 
behavior above and below with 3.1.2.



Now, the doc [1] says "If /stop/ is None, then iteration continues until
the iterator is exhausted, if at all; otherwise, it stops at the
specified position".


With a step  greater than 1, 'specified position' is ambiguous. Any stop 
value in [2,51] gives the same result. One could argue that the 
effective stop value is either last returned + step as above does, or 
last returned + 1 as Python version does.



It clearly is not stopping at stop (3).

Further, the doc gives an example of how this is *equivalent* to a
generator defined in the same section. It turns out, these two are not
exactly the
same if the side-effect of the code is considered on the underlying
sequence.

Redefining islice using the generator function defined in the doc gives
different (and from one pov, expected) result
 >>> def islice(iterable, *args):
... # islice('ABCDEFG', 2) --> A B
...
 >>> c = count()
 >>> list(islice(c, 1, 3, 50))
[1]
 >>> c.next()
2

While "fixing" this should be rather easy in terms of the change in code
required it might break any code depending
on this seemingly incorrect behavior.

[1]. http://docs.python.org/library/itertools.html#itertools.islice


If you file a bug report, please give the link.
If you do not want to, say so and I will.

--
Terry Jan Reedy

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

Re: Compare source code

[Tim Harig]

On 2010-11-04, Grant Edwards  wrote:
> On 2010-11-04, Seebs  wrote:
>> On 2010-11-04, D'Arcy J.M. Cain  wrote:
>>> Right.  If you mangle spaces in Python or mangle braces in C then
>>> recovery becomes impossible.  I don't think anyone is contesting that.
>>> What we question is the idea that somehow Python is special in this
>>> regard.  If you move files around in ways that change them then your
>>> tools are broken.  The fact that the breakage is somewhat "friendlier"
>>> to some types of files is interesting but irrelevant.
>>
>> Again, why does "diff -b" exist?
>>
>> It exists because so many things change whitespace unintentionally that
>> it's a common failure mode.
>
> It exists because so many people change whitespace intentionally in C
> source code because no two C programmers seem able to agree on how to
> format code.  Diff -b allows you to attempt to ignore semantically
> null stylistic changes made by programmers.

I have seen huge patches caused by nothing more then some edit that
accidently added a trailing space to a large number of lines.  White space
mangling happens all the time without people even knowing about it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Tim Harig]

On 2010-11-04, Mark Wooding  wrote:
> Tim Harig  writes:
>
>> When the GNU folk decided to clone *nix they decided that they knew
>> better and simply decided to create their own interfaces.
>
> This isn't the case.  Actually Info has a long history prior to GNU: it
> was the way that the documentation was presented at the MIT AI lab.  In
> fact, Info was used rather like a modern wiki.  The operating system
> they used, called ITS, didn't have a concept of file permissions, and
> users were encouraged to improve documentation (and programs).  The
> original Info viewer was implemented in Emacs (which also originated in
> ITS, years before GNU).

I was aware of Emacs history.  I was not aware that info actually dated
all the way back to ITS.  In retrospect, Stallman might have done better
cloning ITS as that seems to have been what he wanted to do anyway.  I
suppose that Emacs is basically just an ITS lookalike shell for making *nix
systems look like ITS.

Coming from a *nix background and not being an Emacs users, I prefer the
traditional *nix methods.

> documenting large software systems like Emacs and GCC, it doesn't seem
> unreasonable to provide manuals which are somewhat more discursive and
> leisurely than traditional Unix manpages.  I have a printed copy of the
> GNU Emacs 18 manual (from 1987): it's almost 300 pages long.  The modern
> manual for Emacs 23 is several /times/ larger than this.  Man pages
> don't scale that well.

Actually, they are capable of the same scalability.  I would suggest that
you read the ncurses man pages as they are displayed by pinfo.  The man
page links to other man pages that are organized by functionality in the
same kind of tree organization that is used for (text)info pages.

>> Actually, the left arrow key does not work at all intuitively.  One
>> would expect that it should go back to the previous page as it would
>> in lynx, etc.  It does not.
>
> It moves the cursor so you can hit links.  The l key takes you back
> through your recent viewing history -- and has done for thirty years.

As I said, that is probably intuitive for Emacs users; but, not all *nix
users are Emacs users.  To those of us that are not, the info interface
seems quite alien.

>> By tradition 'n' and 'p' are broken for scrolling in a page.  'b' is
>> often used in place of p but that seems to take one back to the top of
>> the page.
>
> Space and backspace are an older tradition.

Right, and in info with the default key bindings, backspace takes me to the
command help.  I would have expected it to either scroll up the page or
take me to the previously visited node.

>> The s key for a search is another example that has already been
>> discussed.
>
> I find C-s more useful in Info, because it searches interactively.  I
> frequently get muddled when I try to search in `modern' programs like
> web browsers, because they've gratuitously made C-s try to save the page
> (something one hardly ever wants to do) rather than search.  (Finding is
> different: finding is what happens at the end of a /successful/ search.
> So C-f is poorly chosen.)

/ is even more intiuitive yet, it works in more, it works in less, it works
in vi, and it even works in firefox.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How convert list to nested dictionary?

[Arnaud Delobelle]

macm  writes:

> Hi Folks
>
> How convert list to nested dictionary?
>
 l
> ['k1', 'k2', 'k3', 'k4', 'k5']
 result
> {'k1': {'k2': {'k3': {'k4': {'k5': {}}
>
> Regards
>
> macm

reduce(lambda x,y: {y:x}, reversed(l), {})

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

Re: How convert list to nested dictionary?

[Chris Rebert]

> On 4 nov, 16:53, Chris Rebert  wrote:
>> On Thu, Nov 4, 2010 at 11:48 AM, macm  wrote:
>> > Hi Folks
>>
>> > How convert list to nested dictionary?
>>
>>  l
>> > ['k1', 'k2', 'k3', 'k4', 'k5']
>>  result
>> > {'k1': {'k2': {'k3': {'k4': {'k5': {}}
>>
>> We don't do homework.
>> Hint: Iterate through the list in reverse order, building up your
>> result. Using reduce() is one option.

On Thu, Nov 4, 2010 at 2:10 PM, macm  wrote:
> Thanks for your hint.

> Do you have good links or books to me learn "Functional Programming"?

Relevant to the particular problem you posed:
http://en.wikipedia.org/wiki/Fold_(higher-order_function)


> Show me, please! if you can.

I will give you this further hint:

def reducer(accumulator, elem):
# if accumulator = {'k5': {} }
# and elem = 'k4'
# then we want to return {'k4': {'k5': {} } }
now_implement_me()

l = ['k1', 'k2', 'k3', 'k4', 'k5']
result = reduce(reducer, reversed(l), {})

Note that:
reduce(reducer, reversed(l), {})
Is basically equivalent to:
reducer( reducer( reducer( reducer( reducer({}, 'k5'), 'k4'), 'k3'),
'k2'), 'k1')

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best method for a menu in a command line program?

[braden faulkner]

Sorry, I wasn't aware it was doing that but... I've removed it :-)

Sorry about that,
Braden Faulkner
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Tim Harig]

On 2010-11-04, Mark Wooding  wrote:
> Tim Harig  writes:
>
>> I use simple comments that are not effected by white space.  I don't
>> waste my time trying to make comments look artistic.  They are there
>> to convey information; not to look pretty.  I really detest having to
>> edit other peoples comment formatting where you have to re-align
>> everything if the length of any of comment lines change.
>
> I view source code as primarily a means of communication with human
> readers, and only secondarily as being machine readable.  I therefore
> think it's worth the effort to make source code readily legible, for
> example by making effective use of horizontal and vertical whitespace.
> A long time ago, I spent a little while studying graphic design, so I
> try to keep an eye on this sort of thing.

I agree that it should be clean, ledgible, and easy to parse; but, I can
that I can achieve this without making too many assumptions about
whitespace.  Think of it like the way HTML is *supposed* to work.  Ideally,
the web designer should stipulate the basic layout of the page; but,
details such as how wide the display is are better left to the browser to
figure out based on the actual conditions that it needs to display the
page.

> I'm interested in line length for two reasons: firstly, because I
> believe that there's an optimum line length for easy and rapid reading,
> which is probably a bit less than 80 columns; and secondly because I
> find that I make more effective use of the available space on my screen
> if I have several narrow columns rather than a few wide ones -- since
> most lines in source files are short, a wide column ends up being mostly
> empty on the right hand side, which is wasteful.

Don't get me wrong, I am not arguing against the eighty column stylistic
limit.  I totally agree with it within reason.

What I am arguing for is choice on how the code is displayed -- not how it
is actually written.  By using tabs, I can choose the trade-offs myself
when reading the code rather then being confined to how the writer made
their decision to view it.  Assuming that I have sufficient screen space,
I might choose a wider indent even though it might make the document wider
then 80 columns *when viewed*.  Other times, I may resign to view at the
shorter column width so that it fits in my window without side scrolling.
Either way, its my choice; and, when I am finished editing the file,
even if it exceeds 80 columns at my chosen column width, the file will
not exceed 80 columns, at the origional column width, in the actual
source as it is *written*.

Adjusting tab stops is merely for my viewing pleasure and it gives
everybody the choice to view it their way without effecting the code.  That
is why I prefer tabs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using google app through python

[Steve Holden]

On 11/1/2010 5:05 AM, charu gangal wrote:
> Hey! Can anyone help me with python script for reading google
> spreadsheets? what all packages do i need to import to make the code
> run successfully after deploying it on google environment..thnx in
> advance

I've found the xlrd module very usable.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17   http://us.pycon.org/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: How find all childrens values of a nested dictionary, fast!

[Arnaud Delobelle]

macm  writes:

> Hi Folks
>
> How find all childrens values of a nested dictionary, fast!
>
 a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc' 
 :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}}, 'ab' : 
 {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}}
 a['a']
> {'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
> 2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
 a['a']['b']
> {'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
> [68, 69, 66]}, '/': [51, 52, 54]}}
 a['a']['b'].values()
> [{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
> [51, 52, 54]}]
>
> Now I want find all values of key "/"
>
> Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]
>
> I am trying map, reduce, lambda.

Tough requirement, but I think I've got it.  Two lambdas, one reduce,
one map ;)

>>> a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]}, 'bc' 
>>> :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}},'ab' : 
>>> {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}}
>>> f = lambda v,k=None: v if k=="/" else reduce(list.__add__, map(lambda k: 
>>> f(v[k],k), v), []) 
>>> f(a)
[5, 6, 7, 8, 41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54, 21, 22, 23, 12, 
13, 14, 15]

This doesn't correspond with your desire result though.

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

Re: How convert list to nested dictionary?

[macm]

Hi Chris

Thanks for your hint.

I am reading this

http://www.amk.ca/python/writing/functional

Do you have good links or books to me learn "Functional Programming"?

but I am not asking "...because is easy but because is hard."

Show me, please! if you can.

Thanks is advance.

Best regards

macm


On 4 nov, 16:53, Chris Rebert  wrote:
> On Thu, Nov 4, 2010 at 11:48 AM, macm  wrote:
> > Hi Folks
>
> > How convert list to nested dictionary?
>
>  l
> > ['k1', 'k2', 'k3', 'k4', 'k5']
>  result
> > {'k1': {'k2': {'k3': {'k4': {'k5': {}}
>
> We don't do homework.
> Hint: Iterate through the list in reverse order, building up your
> result. Using reduce() is one option.
>
> Cheers,
> Chris

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

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Philip Semanchuk]

On Nov 4, 2010, at 4:05 PM, Ned Deily wrote:

> In article 
> <238cec6d-2f47-4c97-8941-e28e68089...@a9g2000pro.googlegroups.com>,
> Jeremy  wrote:
> [...]
>> I downloaded the source from python.org and extracted with 'tar -xzvf
>> Python-2.7.tgz'  My home space is on some network somewhere.  I think
>> the network filesystem creates the ._ at the beginning of the files.
>> It's really quite annoying.
> 
> It is and really shouldn't be happening.  If I understand correctly, 
> whoever administers your system is doing its users a disservice by 
> putting OS X home directories on such a file system.
> 
>>> The path names look a little suspicious, too:
>>> /home/jlconlin.  What file system type are these files on?  You
>>> shouldn't run into problems if you use an HFS+ file system (for
>>> instance) and extract the tarball from the command line using
>>> /usr/bin/tar.
>> 
>> I am intentionally installing in my home directory (i.e., /home/
>> jlconlin) because I don't have access to /usr/local.  Supposedly this
>> is possible, and in fact common.
> 
> It is common and not normally a problem.  I was just noting that the 
> path name was not the OS X default of /Users/jlconlin.
> 
> That said, there are a couple of options.  Either find another file 
> system to install to or, after extracting, you may be able to delete the 
> spurious '._' files by a judicious use of find (-name '\.\_*' perhaps), 
> or you could probably just ignore all the "compiling" errors.  Those 
> aren't "compile" errors in the sense of C compiler errors; rather they 
> are from one of the final install steps that produces optimized .pyc and 
> .pyo versions of all of the standard library .py files.  The ._ files 
> aren't python files but they do end in .py so compileall mistakenly 
> tries to bytecompile them, too.

You might want to try this before running tar to see if it inhibits the ._ 
files:
export COPYFILE_DISABLE=True


I know that tells tar to ignore those files (resource forks, no?) when building 
a tarball. I don't know if it helps with extraction though.

Good luck
Philip


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

Re: Compare source code

[Terry Reedy]

On 11/4/2010 4:17 AM, Seebs wrote:

I am sorry you feel compelled to use a language you so dislike. Not our 
fault though.



Other languages I use are mostly amenable to the development of tools
to automatically indent code.  Makefiles and Python are the only two
exceptions...


If you add the normally redundant information in the form of explicit 
dedents (anything starting with '#' and distinguishable from normal 
comments), then it is not too hard to re-indent even after all indents 
have been removed. I believe this has been dome more than once. By using 
a stylized comment, the augmented code runs without preprocessing. I 
also believe at lease one person has written a preprocessor for 
'python-with-braces'.


--
Terry Jan Reedy

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

3rd party python module with pyd picking up wrong dlls

[Pix]

Hi,

I'm trying to install OpenSSL by placing it in site-packages\OpenSSL.
In the directory there the following files,

crypto.pyd
libeay32.dll
rand.pyd
SSL.pyd
ssleay32.dll

When i try to import the module by doing "import OpenSSL" i get an
import error saying "ImportError: DLL load failed: The specified
module could not be found". It turns out that there is another module
(call it XXX) that is install which contains different versions of
libeay32.dll and ssleay32.dll. And the path to the XXX appears earlier
in os.environ['PATH'] than the OpenSSL dir. So this cause it to pick
up the wrong dll which in turn causes the import error. If i renamed
the dlls in XXX's dir then the import will work fine.

So my question is, shouldn't the import be picking up the dlls in the
module directory first before following the PATH in it's search order?
Seem that is doesn't make sense because if i put OpenSSL earlier in
the path, it would work for OpenSSL, but then XXX will be picking up
the wrong dll.

Any help is much appreciated!

Regards,
Pix
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Allow multiline conditions and the like

[Chris Rebert]

On Thu, Nov 4, 2010 at 11:09 AM, Mark Wooding  wrote:
> Chris Rebert  writes:
>> Or, if possible, refactor the conditional into a function (call) so
>> it's no longer multiline in the first place.
>
> No!  This /increases/ cognitive load for readers, because they have to
> deal with the indirection through the name.

If it's well-named, then the reader can delay having to read the definition.

> If you actually use the
> function multiple times, the mental overhead of forming the abstraction
> and associating it with the function name is shared across the various
> call sites and it's probably worth it.  If it's only called once, leave
> it inline.

I'd say it's a judgment call. If the condition is sufficiently
complicated and can be well-named, then I see justifying refactoring
it into a function even if it's only used once.
However, this is admittedly not a common situation.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Grant Edwards]

On 2010-11-04, Seebs  wrote:
> On 2010-11-04, D'Arcy J.M. Cain  wrote:
>> Right.  If you mangle spaces in Python or mangle braces in C then
>> recovery becomes impossible.  I don't think anyone is contesting that.
>> What we question is the idea that somehow Python is special in this
>> regard.  If you move files around in ways that change them then your
>> tools are broken.  The fact that the breakage is somewhat "friendlier"
>> to some types of files is interesting but irrelevant.
>
> Again, why does "diff -b" exist?
>
> It exists because so many things change whitespace unintentionally that
> it's a common failure mode.

It exists because so many people change whitespace intentionally in C
source code because no two C programmers seem able to agree on how to
format code.  Diff -b allows you to attempt to ignore semantically
null stylistic changes made by programmers.

-- 
Grant Edwards   grant.b.edwardsYow! I'm having a RELIGIOUS
  at   EXPERIENCE ... and I don't
  gmail.comtake any DRUGS
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, D'Arcy J.M. Cain  wrote:
> Right.  If you mangle spaces in Python or mangle braces in C then
> recovery becomes impossible.  I don't think anyone is contesting that.
> What we question is the idea that somehow Python is special in this
> regard.  If you move files around in ways that change them then your
> tools are broken.  The fact that the breakage is somewhat "friendlier"
> to some types of files is interesting but irrelevant.

Again, why does "diff -b" exist?

It exists because so many things change whitespace unintentionally that
it's a common failure mode.  Thus, people developing data file formats
often put substantial effort into *guaranteeing* that they will survive
changes to the contents of blocks of whitespace -- it won't matter
whether you used spaces or tabs, or how many spaces there are.  This
is done because, if you don't do it, your files sometimes get broken.

I have never heard of a problem where sending something via a common
commercial mail client with its default settings resulted in the
destruction of braces.  I have regularly seen people report that one
mail client or another is losing or adding spaces, converting tabs
to spaces, converting spaces to tabs, or whatever.

To some extent, it may be largely a matter of convention; it is
conceivable that, had Python been a major and influential language
in 1970, tools in general would be much more careful about preserving
spaces.  But that's not what happened.  Python was created in a world
where the decision had already been made by many engineers (often
poor ones) that it was not a big deal to mess up spacing a bit.

I'd guess this decision goes back to early typesetting.  Spaces
are fungible; other content isn't.  The distinction that is tracked
is "was there space between these characters or not".  Given that
widespread presupposition, and that many file formats have been
adapted to that, I don't think it was a good choice to build
something which would be broken by that common failure mode.

It's not as though widespread spacing problems are a surprise.  They
are so commonplace that multiple utility programs provide, as standard
options, features to work around them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Mark Wooding]

Tim Harig  writes:

> I use simple comments that are not effected by white space.  I don't
> waste my time trying to make comments look artistic.  They are there
> to convey information; not to look pretty.  I really detest having to
> edit other peoples comment formatting where you have to re-align
> everything if the length of any of comment lines change.

I view source code as primarily a means of communication with human
readers, and only secondarily as being machine readable.  I therefore
think it's worth the effort to make source code readily legible, for
example by making effective use of horizontal and vertical whitespace.
A long time ago, I spent a little while studying graphic design, so I
try to keep an eye on this sort of thing.

I'm interested in line length for two reasons: firstly, because I
believe that there's an optimum line length for easy and rapid reading,
which is probably a bit less than 80 columns; and secondly because I
find that I make more effective use of the available space on my screen
if I have several narrow columns rather than a few wide ones -- since
most lines in source files are short, a wide column ends up being mostly
empty on the right hand side, which is wasteful.

It's true that a source file is not the same as a typeset document: the
most obvious difference is that source files are modified over time,
sometimes by many hands, and that therefore some of the tradeoffs are
different.  I dislike `pretty' boxes around large comments, for example,
because maintaining the right hand edge is unnecessarily tedious.  But
sometimes careful alignment can help a reader spot a symmetry or find
his way through a repetitive section such a table more easily.

(Unfortunately, I appear to have strange ideas about what `legible'
means...)

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Mark Wooding  wrote:
> Seebs  writes:
>> Python's the only language I use where an obvious flaw, which is
>> repeatedly observed by everyone I know who uses the language, is
>> militantly and stridently defended by dismissing, insulting, and
>> attacking the character and motives of anyone who suggests that it
>> might be a bit of a nuisance.

> So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
> a pretty similar reaction.

I don't use it.  I'm also not as sure that the parens are an obvious
flaw -- I am not aware of whole categories of software which regularly
destroy parens.

>   * I /do/ have a significant problem with cutting and pasting code in
> Python.  In most languages, I can haul a chunk of code about, hit
> C-M-q, and Emacs magically indents the result properly.  This is,
> unfortunately, impossible with Python.  It has caused me real bugs,
> and I have to be extra careful to fix the indentation up.

That was the thing which bit me the worst.  I had a fairly large block
of code in a first-pass ugly program.  I wanted to start refactoring
it, so I moved a big hunk of code into a method (with plans to further
refactor).  It took about fifteen minutes to redo the logic.

> I /like/ Python.  I use it frequently.  I /don't/ want to change its
> structure marked by indentation.  I'm /willing/ to put up with some
> inconvenience because Python makes up for it in other ways.  But there
> /is/ inconvenience, and it does need putting up with.  I think the
> benefits are worth the costs; others may disagree.

That makes sense to me.  I think it depends a lot on what I compare
Python to.  I get along quite well with Ruby, but I loathe PHP.  Comparing
Python to Ruby, I find the indentation quite annoying.  Comparing Python to
PHP, I find the indentation a very mild price to pay for my sanity.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best method for a menu in a command line program?

[Terry Reedy]

On 11/3/2010 9:19 PM, braden faulkner wrote:

I'm using a menu for my command line app using this method.

choice = "foobar"
while choice != "q":
 if choice == "c":
 temp = input("Celsius temperature:")
 print "Fahrenheit:",celsius_to_fahrenheit(temp)
 elif choice == "f":
 temp = input("Fahrenheit temperature:")
 print "Celsius:",fahrenheit_to_celsius(temp)
 elif choice != "q":
 print_options()
 choice = raw_input("option:")

Just wondering if there is another or more efficient way I should be doing it?


Others have answered that, but I would point to the inefficiency for 
users of having to enter unit and value on two separate lines. The 
prompt could be "Enter value and unit (f, c, or k) or q to quit: "

Allow upper and lower case, with or without a space between.

--
Terry Jan Reedy

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

Re: Best method for a menu in a command line program?

[D'Arcy J.M. Cain]

On Thu, 4 Nov 2010 19:46:28 + (UTC)
Grant Edwards  wrote:
> I don't know whether it's that somebody is bragging about having a
> blackberry/iphone (whoop-de-friggin-do!), or that having one is
> somehow a valid excuse for poorly-written postings.  I'm not

It's really just a matter of not knowing or caring how to change the
default.  Mine says "Sent from my brain".

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[D'Arcy J.M. Cain]

On Thu, 4 Nov 2010 19:37:25 + (UTC)
Tim Harig  wrote:
> On 2010-11-04, D'Arcy J.M. Cain  wrote:
> You are the one who seems to be on a crusade against against braces.  It

You totally misunderstand me.  I am not on a crusade of any sort.  I am
happy with Python and the number of other people who are happy with it
is interesting but does not change my life in any significant way.  As
long as there are enough people using it to keep it alive that's all I
care about.  If no one was on a crusade to convince people that
indentation as syntax (can we call is IAS from now on?) was evil then I
wouldn't be posting anything at all on the subject.  I am being totally
reactionary here.

> would seem to me, that if you want people to accept that white space
> formatting is superior, that you would be looking for a simple way to solve
> the white space mangling problem.

I might if it was a problem for me.

> The world is full of broken tools that many of us have to use; but, why
> should we accept that your choice is superior when other choices manage to
> work with these tools without issues.

You don't have to accept anything.  Choose your own tools.  I happen to
choose Python and the tools that I choose to use work fine for me.

> the source in binary.  I also consider the move toward XML based document
> formats a move in the right direction.

Don't get me started on XML.  ;-)

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Ned Deily]

In article 
<238cec6d-2f47-4c97-8941-e28e68089...@a9g2000pro.googlegroups.com>,
 Jeremy  wrote:
[...]
> I downloaded the source from python.org and extracted with 'tar -xzvf
> Python-2.7.tgz'  My home space is on some network somewhere.  I think
> the network filesystem creates the ._ at the beginning of the files.
> It's really quite annoying.

It is and really shouldn't be happening.  If I understand correctly, 
whoever administers your system is doing its users a disservice by 
putting OS X home directories on such a file system.

> > The path names look a little suspicious, too:
> > /home/jlconlin.  What file system type are these files on?  You
> > shouldn't run into problems if you use an HFS+ file system (for
> > instance) and extract the tarball from the command line using
> > /usr/bin/tar.
> 
> I am intentionally installing in my home directory (i.e., /home/
> jlconlin) because I don't have access to /usr/local.  Supposedly this
> is possible, and in fact common.

It is common and not normally a problem.  I was just noting that the 
path name was not the OS X default of /Users/jlconlin.

That said, there are a couple of options.  Either find another file 
system to install to or, after extracting, you may be able to delete the 
spurious '._' files by a judicious use of find (-name '\.\_*' perhaps), 
or you could probably just ignore all the "compiling" errors.  Those 
aren't "compile" errors in the sense of C compiler errors; rather they 
are from one of the final install steps that produces optimized .pyc and 
.pyo versions of all of the standard library .py files.  The ._ files 
aren't python files but they do end in .py so compileall mistakenly 
tries to bytecompile them, too.

> Is it safe to ignore these modules then?

Yes.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Ways of accessing this mailing list?

[Mark Wooding]

John Bond  writes:

> Hope this isn't too O/T - I was just wondering how people read/send to
> this mailing list, eg. normal email client, gmane, some other software
> or online service?
>
> My normal inbox is getting unmanageable, and I think I need to find a
> new way of following this and other lists.

I read and post to it as comp.lang.python.  I maintain a local NNTP
server, which interacts with my ISP's news server.  I read and post news
(and mail) using GNU Emacs and Gnus.

(Interestingly, if enormous folders are your problem, Gnus can apply
news-like expiry rules to email folders.)

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[News123]

On 11/02/2010 02:42 PM, Steven D'Aprano wrote:

> However, there is a Python wiki. It doesn't get anywhere near as much 
> love as it deserves, and (I think) the consensus was that the official 
> Python docs should stay official, but link to the wiki for user-
> contributed content. This hasn't happened yet.
> 
> http://wiki.python.org/moin/


That sounds like an excellent idea.
I often would have appreciated more examples or discussions about a
given module/class/function without having to fall back to Google.


It might be a good compromise:

clearly separating official doc and examples, but accepting, that the
doc is often insufficient without digging into the sources or searching
for more xamples.

The more one uses python, the easier it becomes to find what one looks for.

My first Impression about Python however was:
- the basic language is rather easy to learn
- the library documentation was more difficult to understand than the
one for PHP or for Perl.



> Frankly, I think that the best thing you could do is start a fork of the 
> docs and see if you get any interest from people. If you do, then you can 
> go back to python-dev with proof that there is a genuine popular desire 
> for more structured, PHP-style documentation.

I'd prefer crosslinking the doc with something, that's easier for
beginners of for people who never used a given library before.

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

Re: Best method for a menu in a command line program?

[Grant Edwards]

On 2010-11-04, Ned Deily  wrote:
>  Ben Finney  wrote:
>> brf...@gmail.com writes:
>> > Thanks again, 
>> > Braden Faulkner
>> >
>> > Sent wirelessly from my BlackBerry device on the Bell network.
>> > Envoy?? sans fil par mon terminal mobile BlackBerry sur le r??seau de Bell.
>> 
>> Please show your thanks by *not* spamming the forum with each message;
>> compose your messages from a mail client that doesn't feel the need to
>> blather about itself in the message body.
>> 
>> -- 
>>  \   ???For fast acting relief, try slowing down.??? ???Jane Wagner, via 
>> |
>>   `\   Lily Tomlin |
>> _o__)  |
>> Ben Finney
>
> If I were a rude person, I might observe that "spamming" is relative: 
> some who obsess about "spam" might consider 2 lines less of an evil than 
> 5 lines.
>
> But I'm not, so I won't.

I must admit that I sympathise with Ben: I find those "sent from my
iphone/blackberry" lines exruciatingly annoying, and I'm not really
sure why.

They waste less space than my (or Ben's) sig, and actually do convey
some sort of (pointless) information -- unlike randomly chosen
Zippy-the-pinhead quotes.

Still, I find them very smug, self-satisfied and irritating.  Sort of
like those doors from the Serious Cybernetics Corporation.

I don't know whether it's that somebody is bragging about having a
blackberry/iphone (whoop-de-friggin-do!), or that having one is
somehow a valid excuse for poorly-written postings.  I'm not
specifically accusing Braden Faulkner of posting badly written
articles, but it does seem to be a trend among people who use iphones
and blackberrys to post.

-- 
Grant Edwards   grant.b.edwardsYow! I didn't order any
  at   WOO-WOO ... Maybe a YUBBA
  gmail.com... But no WOO-WOO!


Posted from my Linux computer using mutt!
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Final state of underlying sequence in islice

[Ned Deily]

In article 
,
 Shashank Singh  wrote:
> Are there any promises made with regard to final state of the underlying
> sequence that islice slices?
[...] 
> While "fixing" this should be rather easy in terms of the change in code
> required it might break any code depending
> on this seemingly incorrect behavior.

I suggest you open an issue at http://bugs.python.org/.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Compare source code

[Tim Harig]

On 2010-11-04, D'Arcy J.M. Cain  wrote:
> On Thu, 4 Nov 2010 17:55:55 + (UTC)
> Tim Harig  wrote:
>> What Seebs is refering to is that it is difficult or impossible to
>> re-indent Python source automatically after the indent structure has been
>> broken (such as his email being converted to html on the server or a web
>
> Right.  If you mangle spaces in Python or mangle braces in C then
> recovery becomes impossible.  I don't think anyone is contesting that.

Examples of communication channels that mangle white space abound.  I don't
know of any that mangle either braces or pascal style start/end blocks.

You are the one who seems to be on a crusade against against braces.  It
would seem to me, that if you want people to accept that white space
formatting is superior, that you would be looking for a simple way to solve
the white space mangling problem.

> What we question is the idea that somehow Python is special in this
> regard.  If you move files around in ways that change them then your
> tools are broken.  The fact that the breakage is somewhat "friendlier"

The world is full of broken tools that many of us have to use; but, why
should we accept that your choice is superior when other choices manage to
work with these tools without issues.

> tools are broken.  The fact that the breakage is somewhat "friendlier"
> to some types of files is interesting but irrelevant.  What would you
> say to a file transfer program that changed Word documents?  What about
> executable files?

Transfering binary programs has always been an issue and using text based
communications (preferably human readable) has always been considered a
good design decision.  I put up with Python's white space idiosyncrasies;
I wouldn't even bother looking at a language that requires me to enter
the source in binary.  I also consider the move toward XML based document
formats a move in the right direction.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Jeremy]

On Nov 4, 1:23 pm, Ned Deily  wrote:
> In article
> <3d9139ae-bd6f-4567-bb02-b21a8ba86...@o15g2000prh.googlegroups.com>,
>
>
>
>
>
>  Jeremy  wrote:
> > I'm having trouble installing Python 2.7 on OSX 10.6  I was able to
> > successfully compile it from source, but ran into problems when I did
> > make install.  The error I got (I received many similar errors) was:
>
> > /usr/bin/install -c -m 644 ../LICENSE /home/jlconlin/Library/
> > Frameworks/Python.framework/Versions/2.7/lib/python2.7/LICENSE.txt
> > PYTHONPATH=/home/jlconlin/Library/Frameworks/Python.framework/Versions/
> > 2.7/lib/python2.7  DYLD_FRAMEWORK_PATH=/home/jlconlin/src/Python-2.7/
> > build: \
> >            ./python -Wi -tt 
> > /home/jlconlin/Library/Frameworks/Python.framework/
> > Versions/2.7/lib/python2.7/compileall.py \
> >            -d 
> > /home/jlconlin/Library/Frameworks/Python.framework/Versions/2.7/
> > lib/python2.7 -f \
> >            -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
> >            
> > /home/jlconlin/Library/Frameworks/Python.framework/Versions/2.7/lib/
> > python2.7
> > Listing /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> > 2.7/lib/python2.7 ...
> > Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> > 2.7/lib/python2.7/._BaseHTTPServer.py ...
> > Sorry: TypeError: ('compile() expected string without null bytes',)
> > Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> > 2.7/lib/python2.7/._Bastion.py ...
> > Sorry: TypeError: ('compile() expected string without null bytes',)
> > Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> > 2.7/lib/python2.7/._CGIHTTPServer.py ...
> > Sorry: TypeError: ('compile() expected string without null bytes',)
>
> How did you obtain and unpack the source?  It looks like you used
> something that created the old-style "._" hidden forks when extracting
> the source.  

I downloaded the source from python.org and extracted with 'tar -xzvf
Python-2.7.tgz'  My home space is on some network somewhere.  I think
the network filesystem creates the ._ at the beginning of the files.
It's really quite annoying.


> The path names look a little suspicious, too:
> /home/jlconlin.  What file system type are these files on?  You
> shouldn't run into problems if you use an HFS+ file system (for
> instance) and extract the tarball from the command line using
> /usr/bin/tar.

I am intentionally installing in my home directory (i.e., /home/
jlconlin) because I don't have access to /usr/local.  Supposedly this
is possible, and in fact common.

>
> > PS. Python compiled correctly, but a few modules were not found/made
> > but I don't think they are important.
>
> > Python build finished, but the necessary bits to build these modules
> > were not found:
> > _bsddb             dl                 gdbm
> > imageop            linuxaudiodev      ossaudiodev
> > spwd               sunaudiodev
>
> Yes, all of those are to be expected on an OS X 64-bit build.

Is it safe to ignore these modules then?

Thanks,
Jeremy
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Mark Wooding]

Tim Harig  writes:

> When the GNU folk decided to clone *nix they decided that they knew
> better and simply decided to create their own interfaces.

This isn't the case.  Actually Info has a long history prior to GNU: it
was the way that the documentation was presented at the MIT AI lab.  In
fact, Info was used rather like a modern wiki.  The operating system
they used, called ITS, didn't have a concept of file permissions, and
users were encouraged to improve documentation (and programs).  The
original Info viewer was implemented in Emacs (which also originated in
ITS, years before GNU).

Texinfo was a GNU innovation: the idea that you could build both the
Info document and a nice printable manual from a single source was
novel, as was the application to Unix.  But, since Stallman was
documenting large software systems like Emacs and GCC, it doesn't seem
unreasonable to provide manuals which are somewhat more discursive and
leisurely than traditional Unix manpages.  I have a printed copy of the
GNU Emacs 18 manual (from 1987): it's almost 300 pages long.  The modern
manual for Emacs 23 is several /times/ larger than this.  Man pages
don't scale that well.

I do agree it's annoying that the official coreutils documentation is in
Texinfo.

> Actually, the left arrow key does not work at all intuitively.  One
> would expect that it should go back to the previous page as it would
> in lynx, etc.  It does not.

It moves the cursor so you can hit links.  The l key takes you back
through your recent viewing history -- and has done for thirty years.

> By tradition 'n' and 'p' are broken for scrolling in a page.  'b' is
> often used in place of p but that seems to take one back to the top of
> the page.

Space and backspace are an older tradition.

> The s key for a search is another example that has already been
> discussed.

I find C-s more useful in Info, because it searches interactively.  I
frequently get muddled when I try to search in `modern' programs like
web browsers, because they've gratuitously made C-s try to save the page
(something one hardly ever wants to do) rather than search.  (Finding is
different: finding is what happens at the end of a /successful/ search.
So C-f is poorly chosen.)

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Tim Harig]

On 2010-11-04, Mark Wooding  wrote:
> Tim Harig  writes:
> This is wishful thinking.  Firstly, code written with a narrow
> indentation offset (e.g., two spaces) can take up an uncomfortable width
> when viewed with a wider offset.

I can accept that as a trade-off.  People have different ideas about
acceptable column width anyway.  I use 8 space tab stops and target 
to no more then 80 columns.  If somebody uses 2 space tab stops, its going
to go over the 80 columns a little bit; but, not so much as cause a major
issue.

> Secondly, if you want other parts (e.g., per-line comments) of lines
> with different indentations to align, then you'll have to take into
> account the tab width.  Technically, you could arrange that between any
> pair of alignment points of any pair of lines there are the same number
> of tab characters; but this is also doomed to uncomfortably wide lines;
> it also suffers because it imposes an /a priori/ upper bound on the
> indentation level.

I use simple comments that are not effected by white space.  I don't waste
my time trying to make comments look artistic.  They are there to convey
information; not to look pretty.  I really detest having to edit other
peoples comment formatting where you have to re-align everything if the
length of any of comment lines change.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling/Installing Python 2.7 on OSX 10.6

[Ned Deily]

In article 
<3d9139ae-bd6f-4567-bb02-b21a8ba86...@o15g2000prh.googlegroups.com>,
 Jeremy  wrote:

> I'm having trouble installing Python 2.7 on OSX 10.6  I was able to
> successfully compile it from source, but ran into problems when I did
> make install.  The error I got (I received many similar errors) was:
> 
> /usr/bin/install -c -m 644 ../LICENSE /home/jlconlin/Library/
> Frameworks/Python.framework/Versions/2.7/lib/python2.7/LICENSE.txt
> PYTHONPATH=/home/jlconlin/Library/Frameworks/Python.framework/Versions/
> 2.7/lib/python2.7  DYLD_FRAMEWORK_PATH=/home/jlconlin/src/Python-2.7/
> build: \
>   ./python -Wi -tt 
> /home/jlconlin/Library/Frameworks/Python.framework/
> Versions/2.7/lib/python2.7/compileall.py \
>   -d 
> /home/jlconlin/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7 -f \
>   -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
>   
> /home/jlconlin/Library/Frameworks/Python.framework/Versions/2.7/lib/
> python2.7
> Listing /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> 2.7/lib/python2.7 ...
> Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> 2.7/lib/python2.7/._BaseHTTPServer.py ...
> Sorry: TypeError: ('compile() expected string without null bytes',)
> Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> 2.7/lib/python2.7/._Bastion.py ...
> Sorry: TypeError: ('compile() expected string without null bytes',)
> Compiling /home/jlconlin/Library/Frameworks/Python.framework/Versions/
> 2.7/lib/python2.7/._CGIHTTPServer.py ...
> Sorry: TypeError: ('compile() expected string without null bytes',)

How did you obtain and unpack the source?  It looks like you used 
something that created the old-style "._" hidden forks when extracting 
the source.  The path names look a little suspicious, too: 
/home/jlconlin.  What file system type are these files on?  You 
shouldn't run into problems if you use an HFS+ file system (for 
instance) and extract the tarball from the command line using 
/usr/bin/tar. 
 
> PS. Python compiled correctly, but a few modules were not found/made
> but I don't think they are important.
> 
> Python build finished, but the necessary bits to build these modules
> were not found:
> _bsddb dl gdbm
> imageoplinuxaudiodev  ossaudiodev
> spwd   sunaudiodev

Yes, all of those are to be expected on an OS X 64-bit build.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Best method for a menu in a command line program?

[Ned Deily]

In article <87wrotfhj2@benfinney.id.au>,
 Ben Finney  wrote:
> brf...@gmail.com writes:
> > Thanks again, 
> > Braden Faulkner
> >
> > Sent wirelessly from my BlackBerry device on the Bell network.
> > Envoyé sans fil par mon terminal mobile BlackBerry sur le réseau de Bell.
> 
> Please show your thanks by *not* spamming the forum with each message;
> compose your messages from a mail client that doesn't feel the need to
> blather about itself in the message body.
> 
> -- 
>  \   “For fast acting relief, try slowing down.” —Jane Wagner, via |
>   `\   Lily Tomlin |
> _o__)  |
> Ben Finney

If I were a rude person, I might observe that "spamming" is relative: 
some who obsess about "spam" might consider 2 lines less of an evil than 
5 lines.

But I'm not, so I won't.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Compare source code

[Mark Wooding]

Tim Harig  writes:

> So, your telling me that mixing tabs and spaces is considered a good
> practice in Haskell?

It doesn't seem to be a matter which is discussed much.  I think Haskell
programmers are used to worrying their brains with far more complicated
things like wobbly[1] types.

> I would argue that text files do not have tab stops -- text editors
> do.  So long as you use tabs for all of your indenting, it is quite
> safe to set the editors tab stops however one likes since the editor's
> tab stop doesn't effect the output of the file.

This is wishful thinking.  Firstly, code written with a narrow
indentation offset (e.g., two spaces) can take up an uncomfortable width
when viewed with a wider offset.

Secondly, if you want other parts (e.g., per-line comments) of lines
with different indentations to align, then you'll have to take into
account the tab width.  Technically, you could arrange that between any
pair of alignment points of any pair of lines there are the same number
of tab characters; but this is also doomed to uncomfortably wide lines;
it also suffers because it imposes an /a priori/ upper bound on the
indentation level.

[1] Proper technical term.  I kid you not.

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How convert list to nested dictionary?

[Chris Rebert]

On Thu, Nov 4, 2010 at 11:48 AM, macm  wrote:
> Hi Folks
>
> How convert list to nested dictionary?
>
 l
> ['k1', 'k2', 'k3', 'k4', 'k5']
 result
> {'k1': {'k2': {'k3': {'k4': {'k5': {}}

We don't do homework.
Hint: Iterate through the list in reverse order, building up your
result. Using reduce() is one option.

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

How convert list to nested dictionary?

[macm]

Hi Folks

How convert list to nested dictionary?

>>> l
['k1', 'k2', 'k3', 'k4', 'k5']
>>> result
{'k1': {'k2': {'k3': {'k4': {'k5': {}}

Regards

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

Re: Compare source code

[D'Arcy J.M. Cain]

On Thu, 4 Nov 2010 17:55:55 + (UTC)
Tim Harig  wrote:
> What Seebs is refering to is that it is difficult or impossible to
> re-indent Python source automatically after the indent structure has been
> broken (such as his email being converted to html on the server or a web

Right.  If you mangle spaces in Python or mangle braces in C then
recovery becomes impossible.  I don't think anyone is contesting that.
What we question is the idea that somehow Python is special in this
regard.  If you move files around in ways that change them then your
tools are broken.  The fact that the breakage is somewhat "friendlier"
to some types of files is interesting but irrelevant.  What would you
say to a file transfer program that changed Word documents?  What about
executable files?

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Neil Cerutti]

On 2010-11-04, Grant Edwards  wrote:
> On 2010-11-04, Neil Cerutti  wrote:
>> On 2010-11-04, D'Arcy J.M. Cain  wrote:
 * Not being able to write an auto-indenter, ever, because it
 is by design theoretically impossible:  Annoying.
>>>
>>> Right.  And in C you can never write an auto-bracer for
>>> exactly the same reason.
>>
>> It's not right, actually. Auto-indent is fairly easy in
>> Python. Auto-dedent is the impossible part.
>
> I think in common usage the term "auto-intender" refers to a
> program that can automatically control source indentation
> (which inclulde both "indenting" and "dindenting" source
> lines).

Thanks for the correction. Autoindent doesn't mean that to me
(I'm a vi user), but I should have figured out what he meant from
the context.

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

Re: Allow multiline conditions and the like

[Mark Wooding]

Chris Rebert  writes:

> Or, if possible, refactor the conditional into a function (call) so
> it's no longer multiline in the first place.

No!  This /increases/ cognitive load for readers, because they have to
deal with the indirection through the name.  If you actually use the
function multiple times, the mental overhead of forming the abstraction
and associating it with the function name is shared across the various
call sites and it's probably worth it.  If it's only called once, leave
it inline.

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How find all childrens values of a nested dictionary, fast!

[Peter Otten]

macm wrote:

> About Peter script
> 
> I am receiving
> 
 for v in f(a['a']['b']):
> ... b.extend(v)
> ...
> Traceback (most recent call last):
>   File "", line 2, in 
> TypeError: 'int' object is not iterable
> 
> I am trying understand this error.

You are probably mixing Diez' implementation of f() with my invocation code. 
Or you have modified the input data and now it contains int values.

Peter

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

Re: How find all childrens values of a nested dictionary, fast!

[macm]

Peter

Ok! Both works fine!

Thanks a lot!

>>> for v in f(a['a']['b']):
... b.extend(v)

b

Now I will try find which script is the fast!

Regards

macm



On 4 nov, 15:56, macm  wrote:
> Hi Folks
>
> Thanks a lot
>
> Script from Diez works:
>
> print list(f(a))
>
> but should be
>
> print list(f(a['a']['b']))
>
> to fit my example.
>
> About Peter script
>
> I am receiving
>
> >>> for v in f(a['a']['b']):
>
> ...     b.extend(v)
> ...
> Traceback (most recent call last):
>   File "", line 2, in 
> TypeError: 'int' object is not iterable
>
> I am trying understand this error.
>
> Best Regards and thanks a lot again!
>
> Mario
> macm
>
> On 4 nov, 15:26, Peter Otten <__pete...@web.de> wrote:
>
> > macm wrote:
> > > How find all childrens values of a nested dictionary, fast!
>
> >  a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc'
> >  :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}},
> >  'ab' : {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}} a['a']
> > > {'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
> > > 2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
> >  a['a']['b']
> > > {'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
> > > [68, 69, 66]}, '/': [51, 52, 54]}}
> >  a['a']['b'].values()
> > > [{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
> > > [51, 52, 54]}]
>
> > > Now I want find all values of key "/"
>
> > > Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]
>
> > > I am trying map, reduce, lambda.
>
> > Hmm, I'm trying none of these and get a different result:
>
> > >>> def f(d):
>
> > ...     stack = [d.iteritems()]
> > ...     while stack:
> > ...             for k, v in stack[-1]:
> > ...                     if k == "/":
> > ...                             yield v
> > ...                     else:
> > ...                             stack.append(v.iteritems())
> > ...                             break
> > ...             else:
> > ...                     stack.pop()
> > ...>>> b = []
> > >>> for v in f(a):
>
> > ...     b.extend(v)
> > ...>>> b
>
> > [5, 6, 7, 8, 41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54, 21, 22, 23, 12,
> > 13, 14, 15]
>
> > What am I missing?
>
> > Peter
>
>

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

Re: Compare source code

[Tim Harig]

On 2010-11-04, MRAB  wrote:
> On 04/11/2010 16:49, Mark Wooding wrote:
>> Seebs  writes:
>>* I don't have many problems with tools trashing whitespace in Python
>>  programs, though I have seen web forum software mangling
>>  indentation; since this makes nontrivial chunks of almost any
>>  programming language illegible, I'm more than willing to blame the
>>  forum software for this.  I haven't personally seen indentation
>>  trashed by email software, for example (though I steer well clear of
>>  people who try to send me HTML mail).
>>
> If you don't use  ...  or some such then any programming
> language is going to look bad!

Looking bad and being unrecoverable are two different things.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How find all childrens values of a nested dictionary, fast!

[macm]

Hi Folks

Thanks a lot

Script from Diez works:

print list(f(a))

but should be

print list(f(a['a']['b']))

to fit my example.



About Peter script

I am receiving

>>> for v in f(a['a']['b']):
... b.extend(v)
...
Traceback (most recent call last):
  File "", line 2, in 
TypeError: 'int' object is not iterable

I am trying understand this error.

Best Regards and thanks a lot again!

Mario
macm






On 4 nov, 15:26, Peter Otten <__pete...@web.de> wrote:
> macm wrote:
> > How find all childrens values of a nested dictionary, fast!
>
>  a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc'
>  :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}},
>  'ab' : {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}} a['a']
> > {'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
> > 2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
>  a['a']['b']
> > {'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
> > [68, 69, 66]}, '/': [51, 52, 54]}}
>  a['a']['b'].values()
> > [{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
> > [51, 52, 54]}]
>
> > Now I want find all values of key "/"
>
> > Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]
>
> > I am trying map, reduce, lambda.
>
> Hmm, I'm trying none of these and get a different result:
>
> >>> def f(d):
>
> ...     stack = [d.iteritems()]
> ...     while stack:
> ...             for k, v in stack[-1]:
> ...                     if k == "/":
> ...                             yield v
> ...                     else:
> ...                             stack.append(v.iteritems())
> ...                             break
> ...             else:
> ...                     stack.pop()
> ...>>> b = []
> >>> for v in f(a):
>
> ...     b.extend(v)
> ...>>> b
>
> [5, 6, 7, 8, 41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54, 21, 22, 23, 12,
> 13, 14, 15]
>
> What am I missing?
>
> Peter

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

Re: Compare source code

[Tim Harig]

On 2010-11-04, Neil Cerutti  wrote:
> On 2010-11-04, D'Arcy J.M. Cain  wrote:
Seebs Wrote:
>>> * Not being able to write an auto-indenter, ever, because it
>>> is by design theoretically impossible:  Annoying.
>>
>> Right.  And in C you can never write an auto-bracer for exactly
>> the same reason.
>
> It's not right, actually. Auto-indent is fairly easy in
> Python. Auto-dedent is the impossible part.

What Seebs is refering to is that it is difficult or impossible to
re-indent Python source automatically after the indent structure has been
broken (such as his email being converted to html on the server or a web
forum without the possibility of  or [code] tags).  When C becomes
so obfiscated, you can run it through indent to recover the structure of
the source to something that you are familiar with (I actually think macros
could cause problems; but, Seebs has already admitted weaknesses in the C
preprocessor.).  The same is not always true for Python where information
about the code structure may be destroyed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Tim Harig]

On 2010-11-04, Mark Wooding  wrote:
> Tim Harig  writes:
>
>> Python is the only language that I know that *needs* to specify tabs
>> versus spaces since it is the only language I know of which uses
>> whitespace formating as part of its syntax and structure.
>
> You need to get out more.  Miranda, Gofer, Haskell, F#, make(1), and

I have never heard of Gofer.

I have heard the name Miranda and I know that it is a (purely?) functional
language; but, that is all that I know.

I took a cursory look at Haskell a while back; but, I ultimately chose to
learn Erlang instead as its error management constructs had real world
application for me.

I also looked at F# and Scala; but, neither are really applicable on my
chosen platform.  With F# being such a new language, I suspect that it
borrowed its indent practices either from Haskell or from Python.

I already introduced the make tab oriented syntax and Seebs has labeled it
as a major anti-pattern.

I am also aware of other langauges such as Boo; but, I don't really
consider them individually relevant to the conversation as they are
explicitly using a Python based syntax.  For this discussion I merely group
them with Python.

>> Mixed usage may be annoying in other languages; but, it breaks Python.
>
> I disagree.  The Haskell '98 report specifies (correctly) that tabs are
> every eight columns, and a tab moves to the next tab stop.  Python makes
> the same specification; it's just the users who actually want to stamp
> out tabs.

So, your telling me that mixing tabs and spaces is considered a good
practice in Haskell?  No, mixing tabs and spaces in Python isn't illegal;
but, I have never seen good outcomes from doing so.  No matter how you
define a tab, most people do not have their editor configured to show them
the difference between a tab stop and the equivilant number of spaces.
I have never experienced ill effects from using tabs alone.

> Flamebait: it's not the tabs that cause the problem: it's that some
> people are under the mistaken impression that the position of tab stops
> in text files is a matter for local preference.

I would argue that text files do not have tab stops -- text editors do.  So
long as you use tabs for all of your indenting, it is quite safe to set the
editors tab stops however one likes since the editor's tab stop doesn't
effect the output of the file.  That way, everybody can edit their code
using an apparent indent level that is comfortable for them without being
disruptive to the code.  It is a win-win situation for everybody.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Emile van Sebille]

On 11/4/2010 7:15 AM Neil Cerutti said...

The handsome ':' terminator of if/elif/if statements allows us to
omit a newline, conserving vertical space. This improves the
readability of certain constructs.

if x: print(x)
elif y: print(y)
else: print()



Analogously, x+=1;y=f(x);return

We don't have to eliminate ':'s.

Emile

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

Re: What people are using to access this mailing list

[Peter Pearson]

On Wed, 3 Nov 2010 08:02:29 + (UTC), John Bond  wrote:
> Hope this isn't too O/T - I was just wondering how people read/send to this 
> mailing list, eg. normal email client, gmane, some other software or online 
> service?

Usenet via a server at news.individual.net,
newsgroup name comp.lang.python, client slrn.

-- 
To email me, substitute nowhere->spamcop, invalid->net.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[MRAB]

On 04/11/2010 16:49, Mark Wooding wrote:

Seebs  writes:


Python's the only language I use where an obvious flaw, which is
repeatedly observed by everyone I know who uses the language, is
militantly and stridently defended by dismissing, insulting, and
attacking the character and motives of anyone who suggests that it
might be a bit of a nuisance.


So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
a pretty similar reaction.

My observations on this general discussion.

   * Python is far from unique in its use of significant whitespace.
 Miranda was inferring program structure from indentation in 1985.
 Haskell and F# are more modern examples.


occam was doing it in 1983.


   * I don't have many problems with tools trashing whitespace in Python
 programs, though I have seen web forum software mangling
 indentation; since this makes nontrivial chunks of almost any
 programming language illegible, I'm more than willing to blame the
 forum software for this.  I haven't personally seen indentation
 trashed by email software, for example (though I steer well clear of
 people who try to send me HTML mail).


If you don't use  ...  or some such then any programming
language is going to look bad!

[snip]
--
http://mail.python.org/mailman/listinfo/python-list

Re: How find all childrens values of a nested dictionary, fast!

[Peter Otten]

macm wrote:

> How find all childrens values of a nested dictionary, fast!
> 
 a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc'
 :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}},
 'ab' : {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}} a['a']
> {'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
> 2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
 a['a']['b']
> {'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
> [68, 69, 66]}, '/': [51, 52, 54]}}
 a['a']['b'].values()
> [{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
> [51, 52, 54]}]
> 
> Now I want find all values of key "/"
> 
> Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]
> 
> I am trying map, reduce, lambda.

Hmm, I'm trying none of these and get a different result:

>>> def f(d):
... stack = [d.iteritems()]
... while stack:
... for k, v in stack[-1]:
... if k == "/":
... yield v
... else:
... stack.append(v.iteritems())
... break
... else:
... stack.pop()
...
>>> b = []
>>> for v in f(a):
... b.extend(v)
...
>>> b
[5, 6, 7, 8, 41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54, 21, 22, 23, 12, 
13, 14, 15]

What am I missing?

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

Re: Compare source code

[Grant Edwards]

On 2010-11-04, Neil Cerutti  wrote:
> On 2010-11-04, D'Arcy J.M. Cain  wrote:
>>> * Not being able to write an auto-indenter, ever, because it
>>> is by design theoretically impossible:  Annoying.
>>
>> Right.  And in C you can never write an auto-bracer for exactly
>> the same reason.
>
> It's not right, actually. Auto-indent is fairly easy in
> Python. Auto-dedent is the impossible part.

I think in common usage the term "auto-intender" refers to a program
that can automatically control source indentation (which inclulde both
"indenting" and "dindenting" source lines).

-- 
Grant Edwards   grant.b.edwardsYow! I'm having BEAUTIFUL
  at   THOUGHTS about the INSIPID
  gmail.comWIVES of smug and wealthy
   CORPORATE LAWYERS ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How find all childrens values of a nested dictionary, fast!

[Diez B. Roggisch]

macm  writes:

> Hi Folks
>
> How find all childrens values of a nested dictionary, fast!

There is no faster than O(n) here. 
>
 a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc' 
 :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}}, 'ab' : 
 {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}}
 a['a']
> {'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
> 2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
 a['a']['b']
> {'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
> [68, 69, 66]}, '/': [51, 52, 54]}}
 a['a']['b'].values()
> [{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
> [51, 52, 54]}]
>
> Now I want find all values of key "/"
>
> Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]

a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc' 
:{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}}, 'ab' : {'/' 
:[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}}


def f(d):
if "/" in d:
for v in d["/"]:
yield v
for value in d.values():
if isinstance(value, dict):
for v in f(value):
yield v


print list(f(a))

But that gives me a different result:

  [5, 6, 7, 8, 1, 2, 3, 4, 41, 42, 44, 51, 52, 54, 68, 69, 66, 21, 22,
  23, 12, 13, 14, 15]

Why don't you expect e.g. 23 in your output?

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

Re: Compare source code

[Neil Cerutti]

On 2010-11-04, D'Arcy J.M. Cain  wrote:
>> * Not being able to write an auto-indenter, ever, because it
>> is by design theoretically impossible:  Annoying.
>
> Right.  And in C you can never write an auto-bracer for exactly
> the same reason.

It's not right, actually. Auto-indent is fairly easy in
Python. Auto-dedent is the impossible part.

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

Re: Compare source code

[Mark Wooding]

Tim Harig  writes:

> Python is the only language that I know that *needs* to specify tabs
> versus spaces since it is the only language I know of which uses
> whitespace formating as part of its syntax and structure.

You need to get out more.  Miranda, Gofer, Haskell, F#, make(1), and
many others, all use indentation to indicate structure; YAML isn't a
programming language, but it also uses indentation to indicate
structure, as do a number of wiki markup languages; there are also
representations of Lisp S-expressions which use indentation instead of
parentheses.

> Mixed usage may be annoying in other languages; but, it breaks Python.

I disagree.  The Haskell '98 report specifies (correctly) that tabs are
every eight columns, and a tab moves to the next tab stop.  Python makes
the same specification; it's just the users who actually want to stamp
out tabs.

Flamebait: it's not the tabs that cause the problem: it's that some
people are under the mistaken impression that the position of tab stops
in text files is a matter for local preference.

-- [mdw]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Mark Wooding]

Seebs  writes:

> Python's the only language I use where an obvious flaw, which is
> repeatedly observed by everyone I know who uses the language, is
> militantly and stridently defended by dismissing, insulting, and
> attacking the character and motives of anyone who suggests that it
> might be a bit of a nuisance.

So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
a pretty similar reaction.

My observations on this general discussion.

  * Python is far from unique in its use of significant whitespace.
Miranda was inferring program structure from indentation in 1985.
Haskell and F# are more modern examples.

  * I don't have many problems with tools trashing whitespace in Python
programs, though I have seen web forum software mangling
indentation; since this makes nontrivial chunks of almost any
programming language illegible, I'm more than willing to blame the
forum software for this.  I haven't personally seen indentation
trashed by email software, for example (though I steer well clear of
people who try to send me HTML mail).

  * I /do/ have a significant problem with cutting and pasting code in
Python.  In most languages, I can haul a chunk of code about, hit
C-M-q, and Emacs magically indents the result properly.  This is,
unfortunately, impossible with Python.  It has caused me real bugs,
and I have to be extra careful to fix the indentation up.

  * I've just noticed that Emacs's Python mode has a magic keystroke
which appears to do the right thing for cut-and-pasted code.  This
is symptomatic of a bigger problem: simply by being different from
the mainstream, Python requires that one work with it differently.
It requires different tools, and different techniques.  Many
languages use some kind of brackets to mark substructure, so tools
have become good at handling bracketed substructure, whether for
automatic indentation or navigation.  Python marks (some)
substructure differently, so users need to learn new techniques or
tools for working with it.

I /like/ Python.  I use it frequently.  I /don't/ want to change its
structure marked by indentation.  I'm /willing/ to put up with some
inconvenience because Python makes up for it in other ways.  But there
/is/ inconvenience, and it does need putting up with.  I think the
benefits are worth the costs; others may disagree.

-- [mdw], a smug Lisp weenie at heart.
-- 
http://mail.python.org/mailman/listinfo/python-list

sigaction?

[Neal Becker]

Why doesn't python signal support sigaction?  I'm interested in trying 
sigaction with SA_RESTART to prevent interrupted system calls.  Or, would 
the usage of SA_RESTART within python cause other problems?

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

Re: DateTime object

[M.-A. Lemburg]

jf wrote:
> Hi,
> 
> I've a bug in my code and I'm trying de reproduce it.
> 
> To trace the bug I print arguments, and it produces this:
> {'date': }
> 
> My question is: what is: ?
> 
> I use mx.DateTime put if I print it I get:
> 
> 
> So what kind of object  is ?

You might be using the old Python implementation of mxDateTime
(mx/DateTime/mxDateTime/mxDateTime_Python.py):

def __repr__(self):
return ""% (
self.year, self.month, self.day, self.hour, self.minute,
self.second, id(self))

Note however, that there's no "T" in the string shown for the
repr(), so perhaps this is some other implementation.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 04 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[John Nagle]

On 10/31/2010 6:52 AM, jf wrote:

Le 31/10/2010 13:10, Martin v. Loewis a écrit :

I've a project with tabs and spaces mixed (yes I know it's bad).

I edit each file to remove tabs, but it's so easy to make a mistake.
Do you know a tools to compare the initial file with the cleaned one to
know if the algorithms are the same ?


Tools/scripts/reindent.py of the standard Python distribution normalizes
white space in source code.


So great, you save my time !
Should I be worry about this comment in reindent.py "So long as the
input files get a clean bill of health from tabnanny.py, reindent should
do a good job." ?


   Are both of those tools consistent with the interpretation of mixed 
tabs and spaces in Python 3.x?


   The current CPython parser front end is smart about this.  Tabs
and spaces can be mixed provided that the semantics of the program
do not depend on the width of a tab.  This was not the case in
early 2.x versions.  (When did that go in?)

   The key to doing this right is to compare the whitespace of an
indented line with the line above it.  The longer whitespace string must
start with the shorter whitespace string, whether it's tabs, spaces, or
any combination thereof.  If it does not, the indentation is ambiguous.
For all unambiguous cases, you can then convert tabs to spaces or vice
versa with any number of spaces to tabs, and the semantics of the
program will not change.

   It's not clear whether "tabnanny" or "reindent" have smart semantics
like CPython.  The documentation doesn't say.  If they don't, they
should, or it should be documented that they're broken.

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

Re: functions, list, default parameters

[Robert Kern]

On 11/4/10 2:07 AM, Lawrence D'Oliveiro wrote:

In message, Robert Kern
wrote:


On 11/2/10 2:12 AM, Lawrence D'Oliveiro wrote:


In message, Robert
Kern wrote:


"Immutable objects" are just those without an obvious API for modifying
them.


They are ones with NO legal language constructs for modifying them. Hint:
if a selector of some part of such an object were to occur on the LHS of
an assignment, and that would raise an error, then the object is
immutable. The interpreter already knows all this.


Incorrect. RHS method calls can often modify objects.


So bloody what?


So examining LHS "selectors" is not sufficient for determining immutability.


Show me the algorithm that the interpreter can use to determine whether or
not an object is mutable.


Go look in the code for the one it already uses in places where immutable
objects are currently required.


Like hashes for dictionary keys? The code just calls the __hash__ method and 
trusts that you designed the object correctly. It does not verify anything. 
Although, strictly speaking, it doesn't require immutability of keys.


This is actually another one of those places where the Python language 
developers defined a concept but did not equip the interpreter with a way to 
verify compliance with the concept. A proper hashable object has a __hash__ 
method and an __eq__ method defined such that if two objects compare equal, they 
also hash equal. But nothing in the interpreter ever tries to verify that this 
is true. Nor can it except by an impossible exhaustive search of all the 
possible objects.


Care to point me to specific place in the Python code you are talking about? Or 
even just a slightly more specific direction would suffice. I don't really know 
what you might be talking about.



With various trickeries, I can mutate any immutable object.


None within the Python language itself. Which is what we’re talking about
here: a language construct which is probably one of the top 3 sources of
grief to Python newbies. And not-so-newbies.


"import ctypes" is within the Python language.


And in the old BASIC days, we had “PEEK” and “POKE”. So by your reasoning,
that invalidated the language rules, too.


I'm not talking about BASIC at all. Nor am I talking about invalidation of 
language rules in either BASIC or Python. I am only talking about whether or not 
the Python interpreter is able to determine if an object is immutable or not.


But this really is a side point. I'm happy to drop it.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Final state of underlying sequence in islice

[Shashank Singh]

Hi,

Apologies if this has been discussed in this list before. Google has not
been very helpful in locating any such
previous discussion.

Are there any promises made with regard to final state of the underlying
sequence that islice slices?
for example consider this

>>> from itertools import *
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
51

Now, the doc [1] says "If *stop* is None, then iteration continues until the
iterator is exhausted, if at all; otherwise, it stops at the specified
position".
It clearly is not stopping at stop (3).

Further, the doc gives an example of how this is *equivalent* to a generator
defined in the same section. It turns out, these two are not exactly the
same if the side-effect of the code is considered on the underlying
sequence.

Redefining islice using the generator function defined in the doc gives
different (and from one pov, expected) result
>>> def islice(iterable, *args):
... # islice('ABCDEFG', 2) --> A B
...
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
2

While "fixing" this should be rather easy in terms of the change in code
required it might break any code depending
on this seemingly incorrect behavior.

[1]. http://docs.python.org/library/itertools.html#itertools.islice
-- 
Regards
Shashank Singh
shashank.sunny.si...@gmail.com
http://www.cse.iitb.ac.in/~shashanksingh
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[D'Arcy J.M. Cain]

On 04 Nov 2010 08:17:10 GMT
Seebs  wrote:
> Outside of people who seem to be deeply emotionally invested in insisting
> that it is never, at all, in ANY way, for ANY person, annoying, it seems
> to be pretty consistent to observe that, benefits or no benefits, it has
> some kind of non-zero annoyance value.

Who are these people that believe that no one finds indentation as
syntax annoying?  I haven't seen any evidence in this group.  Let's
leave the straw men out of this.  Many of us don't find it annoying
ourselves, that's for sure but we aren't trying to read anyone else's
mind.  We're all pretty sure that *you* find it annoying but there is
no telepathy involved there.

> * Not having to type braces:  Yay!

Which I always found annoying given that I was already adding signals
(indentation) that I was starting a block.

> * Having structure map to functionality:  Some people quite like it, and

Some of us think that it is a contender for the single greatest thing
about Python.

> * Not being able to write an auto-indenter, ever, because it is by
>   design theoretically impossible:  Annoying.

Right.  And in C you can never write an auto-bracer for exactly the
same reason.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

How find all childrens values of a nested dictionary, fast!

[macm]

Hi Folks

How find all childrens values of a nested dictionary, fast!

>>> a = {'a' : {'b' :{'/' :[1,2,3,4], 'ba' :{'/' :[41,42,44]} ,'bc' 
>>> :{'/':[51,52,54], 'bcd' :{'/':[68,69,66]}}},'c' :{'/' :[5,6,7,8]}}, 'ab' : 
>>> {'/' :[12,13,14,15]}, 'ac' :{'/' :[21,22,23]}}
>>> a['a']
{'c': {'/': [5, 6, 7, 8]}, 'b': {'ba': {'/': [41, 42, 44]}, '/': [1,
2, 3, 4], 'bc': {'bcd': {'/': [68, 69, 66]}, '/': [51, 52, 54]}}}
>>> a['a']['b']
{'ba': {'/': [41, 42, 44]}, '/': [1, 2, 3, 4], 'bc': {'bcd': {'/':
[68, 69, 66]}, '/': [51, 52, 54]}}
>>> a['a']['b'].values()
[{'/': [41, 42, 44]}, [1, 2, 3, 4], {'bcd': {'/': [68, 69, 66]}, '/':
[51, 52, 54]}]

Now I want find all values of key "/"

Desire result is [41, 42, 44, 1, 2, 3, 4, 68, 69, 66, 51, 52, 54]

I am trying map, reduce, lambda.

Regards

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

Re: Compare source code

[Lawrence D'Oliveiro]

In message , Seebs wrote:

> The question is *why* diff has that option.
> 
> The answer is because whitespace changes (spaces to tabs, different
> tab stops, etcetera) are an extremely common failure mode, such that
> it's quite common for files to end up with unintentional whitespace
> changes.

Except the diff option is to *ignore* such differences, not highlight them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python documentation too difficult for beginners

[Lawrence D'Oliveiro]

In message , Cameron 
Simpson wrote:

> But its weakness is stuff like this:
> 
>   http://epydoc.sourceforge.net/stdlib/Canvas.Polygon-class.html
> 
> Automatic docness, no useful information.

But it Conforms to Documentation-Production Metrics as decreed by the 
Corporate Task Force on Policy. So long as the divisions are satisfying the 
official metrics on documentation production, that must mean the project is 
meeting its goals.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Allowing comments after the line continuation backslash

[Lawrence D'Oliveiro]

In message , Chris 
Rebert wrote:

> Actually, my PEP 8 reference was in regards to the (imo, terrible)
> UseOfCamelCaseForNonClasses (Python != C#), not the formatting of the
> for-loop; hence the "In any case" qualification.

Hmm ... OK, I might accept that particular criticism. I have to say it’s a 
habit I picked up in my Mac programming days, that I find hard to shake. I 
do sometimes deliberately use lowercase_with_underscores, but then I keep 
LapsingBackAgain.

At least I prefer Bactrian to Dromedary. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Lawrence D'Oliveiro]

In message , Seebs wrote:

> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.

I’m thinking of going the other way. After many years of treating tabs as 
four-column steps, I might give up on them and use spaces everywhere.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: functions, list, default parameters

[Lawrence D'Oliveiro]

In message , Robert Kern 
wrote:

> On 11/2/10 2:12 AM, Lawrence D'Oliveiro wrote:
>
>> In message, Robert
>> Kern wrote:
>>
>>> "Immutable objects" are just those without an obvious API for modifying
>>> them.
>>
>> They are ones with NO legal language constructs for modifying them. Hint:
>> if a selector of some part of such an object were to occur on the LHS of
>> an assignment, and that would raise an error, then the object is
>> immutable. The interpreter already knows all this.
> 
> Incorrect. RHS method calls can often modify objects.

So bloody what?

> Show me the algorithm that the interpreter can use to determine whether or
> not an object is mutable.

Go look in the code for the one it already uses in places where immutable 
objects are currently required.

>>> With various trickeries, I can mutate any immutable object.
>>
>> None within the Python language itself. Which is what we’re talking about
>> here: a language construct which is probably one of the top 3 sources of
>> grief to Python newbies. And not-so-newbies.
> 
> "import ctypes" is within the Python language.

And in the old BASIC days, we had “PEEK” and “POKE”. So by your reasoning, 
that invalidated the language rules, too.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Man pages and info pages

[Lawrence D'Oliveiro]

In message
<1bdce24e-4406-44c5-9133-bfd0acd02...@p1g2000yqm.googlegroups.com>, rustom 
wrote:

> The printed python docs come to several thousand pages.  Do we want them
> to be 1 manpage? a hundred? a thousand?

Perl managed to condense a lot of useful information into a handful of man 
pages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Allowing comments after the line continuation backslash

[Lawrence D'Oliveiro]

In message , Roy Smith wrote:

>> 
> 
> That URL takes me to a github page.  Can you be more specific about
> which file I should be looking at?

The extract I previously quoted was from dvd_menu_animator.

> 2) You have provided comments for each function, such as (lines 36-37):
> 
> def NewLayer(svg, LayerName) :
> # adds a new layer to the SVG document and returns it.
> 
> This is good, but would be even more useful if it were turned into a
> docstring ...

I am ambivalent about the usefulness of docstrings. I find them mainly handy 
in stuff imported from library modules, of which this is not one.

> 3) I find the deeply nested style you use very difficult to read.  For
> example, on lines 80-103.  As I read this, here's how I mentally process
> it:
> 
> "OK, here's a function call (minor stumble over the open paren not being
> on the same line as the function name, but I can get past that).  The
> first argument is TheLayer.  The second argument is whatever
> inkex.addNS() returns.  Umm..."

You’re looking at it wrong. It’s building a data structure to go into an SVG 
file. Think of each piece of the expression as directly mapping to the 
corresponding piece of the structure being built. The value being built for 
the “d” attribute is just a sequence of control points for the path.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: execute shell script from python, needs sys.argv

[Peter Otten]

Matt wrote:

> I am trying to execute a shell script from within python..  This shell
> script takes the format, where $1 and $2 are variables from the
> command line: cat $1 | Fastx_trimmer -n COUNT -o $2
> 
> straight into the cmd line it would be:  cat file.1 | Fastx_trimmer -n
> COUNT -o file.2
> 
> So,  know that there is a way to do this in python using the
> subprocess module, but despite a lot of effort, I can't seem to get
> this to work, and precisely because of those arguments taken from the
> command line.
> 
> I was thinking that the easiest thing to so was to
> 
> import sys, os, subprocess
> proc = subprocess.call([cat sys.argv[1] | fastx_trimmer -n COUNT -o
> sys.argv[2]], shell=True)
> 
> this clearly does not work...
> 
> alternatively, I could put the shell command in its own file, say
> fastx.sh, and pass it's arguments to it vie the command line.
> 
> import sys, os, subprocess
> proc = subprocess.call([fastx.sh, sys.argv[1], sys.argv[2]],
> shell=True)
> 
> But, this does not seem to work as this is not the proper way to pass
> arguments to the shell script.
> 
> in short, I'm sure that this is a easy fix, but given my still limited
> python vocabulary, it eludes me.

You could do it in two steps:

>>> from subprocess import *
>>> source = Popen(["cat", "/usr/share/dict/words"], stdout=PIPE)
>>> call(["wc"], stdin=source.stdout)
  98569   98568  931708
0
>>>

A similar example is here, under a "can't miss" headline:

http://docs.python.org/library/subprocess.html#replacing-shell-pipeline

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

Re: execute shell script from python, needs sys.argv

[Benjamin Kaplan]

On Thu, Nov 4, 2010 at 11:37 AM, Matt  wrote:
> Hi All,
>
> I am trying to execute a shell script from within python..  This shell
> script takes the format, where $1 and $2 are variables from the
> command line: cat $1 | Fastx_trimmer -n COUNT -o $2
>
> straight into the cmd line it would be:  cat file.1 | Fastx_trimmer -n
> COUNT -o file.2
>
> So,  know that there is a way to do this in python using the
> subprocess module, but despite a lot of effort, I can't seem to get
> this to work, and precisely because of those arguments taken from the
> command line.
>
> I was thinking that the easiest thing to so was to
>
> import sys, os, subprocess
> proc = subprocess.call([cat sys.argv[1] | fastx_trimmer -n COUNT -o
> sys.argv[2]], shell=True)
>

Python is not the shell. Shell commands are not python commands. You
need either a string or a list of strings, so any literal have to be
in quotes. Also, subprocess can't handle the redirection. You need to
run it as two commands.

proc1 = subprocess.Popen(["cat", sys.argv[1]],stdout =
subprocess.PIPE, shell = True)
proc2 = subprocess.Popen(["fastx_trimmer", "-n", "COUNT", "-o",
sys.argv[2]],stdin=proc1.stdout, shell=True)


> this clearly does not work...
>
> alternatively, I could put the shell command in its own file, say
> fastx.sh, and pass it's arguments to it vie the command line.
>
> import sys, os, subprocess
> proc = subprocess.call([fastx.sh, sys.argv[1], sys.argv[2]],
> shell=True)
>

Again, you need a string. fastx.sh looks for a python object called
fastx and tries accessing an attribute called sh in that object. Ov
course, there's no such thing. Put quotes around it and it will work.

> But, this does not seem to work as this is not the proper way to pass
> arguments to the shell script.
>
> in short, I'm sure that this is a easy fix, but given my still limited
> python vocabulary, it eludes me.
>
> Thanks, Matt
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Popen Question

[Alain Ketterlin]

moogyd  writes:

 import os, subprocess
 os.environ['MYVAR'] = "myval"
 p = subprocess.Popen(['echo', '$MYVAR'],shell=True)

 p = subprocess.Popen(['echo', '$MYVAR'])
 $MYVAR
>
 p = subprocess.Popen('echo $MYVAR',shell=True)
 myval
>
 p = subprocess.Popen('echo $MYVAR')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
> errread, errwrite)
>   File "/usr/lib64/python2.6/subprocess.py", line 1106, in
> _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
>
> I am not really sure I understand these results.
> 1) No idea what is going on
> 2) As (1). What isn't myval printed out (rather than $MYVAR)
> 3) Works as I wanted it to
> 4) Why do I need shell=True ?

Expanding $MYVAR into its value is a feature of the shell (afaik all
shells use the same syntax). Popen without shell=True uses the execvp()
system call directly, without going through the shell variable expansion
process (cases 2 and 4 above). For example, case 4 above asks execvp to
(find and) execute a program named "echo $MYVAR" (an 11-letter name,
where the fifth letter is space and the sixth is $ -- a perfectly valid
file/program name).

Then, if you use shell=True with a list, only the first word is used as
a command, and the others are kept in positional parameters. That's why
your first try fails (try 'sh -c echo $HOME' in a shell, without the
single quotes, and you'll get empty output).

> The documentation isn't very clear to me (it seems you need to
> understand the underlying system calls).

You're probably right. The base fact here is: the use of variables is a
feature of the shell. No shell, no variable.

> Can anyone explain (or provide link) for this behaviour in simple
> English?

Shell variables are explained in detail in any shell man page. The
execvp() system call has its own man page.

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

execute shell script from python, needs sys.argv

[Matt]

Hi All,

I am trying to execute a shell script from within python..  This shell
script takes the format, where $1 and $2 are variables from the
command line: cat $1 | Fastx_trimmer -n COUNT -o $2

straight into the cmd line it would be:  cat file.1 | Fastx_trimmer -n
COUNT -o file.2

So,  know that there is a way to do this in python using the
subprocess module, but despite a lot of effort, I can't seem to get
this to work, and precisely because of those arguments taken from the
command line.

I was thinking that the easiest thing to so was to

import sys, os, subprocess
proc = subprocess.call([cat sys.argv[1] | fastx_trimmer -n COUNT -o
sys.argv[2]], shell=True)

this clearly does not work...

alternatively, I could put the shell command in its own file, say
fastx.sh, and pass it's arguments to it vie the command line.

import sys, os, subprocess
proc = subprocess.call([fastx.sh, sys.argv[1], sys.argv[2]],
shell=True)

But, this does not seem to work as this is not the proper way to pass
arguments to the shell script.

in short, I'm sure that this is a easy fix, but given my still limited
python vocabulary, it eludes me.

Thanks, Matt


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

Re: [ANN] pyOpenSSL 0.11 released

[Giampaolo Rodolà]

2010/11/1  :
> Hello all,
>
> I'm happy to announce the release of pyOpenSSL 0.11.  The primary change
> from the last release is that Python 3.2 is now supported.  Python 2.4
> through Python 2.7 are still supported as well.  This release also fixes a
> handful of bugs in error handling code.  It also adds APIs for generating
> and verifying cryptographic signatures and it improves the test suite to
> cover nearly 80% of the implementation.
>
> Downloads and more details about the release can be found on the release
> page:
>
>   https://launchpad.net/pyopenssl/main/0.11
>
> Enjoy,
> Jean-Paul
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Congratulations!


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cms 4 static pages?

[Daniel Fetchinson]

> m looking 4 a framework, that allows to build static community software
> (similar to facebook) without having to start scripts, database
> connects, admin cookies, e.t.c.
>
> means - should be dynamic without really being dynamic, delivering just
> static pages. (yes, i know e.g. nginx does that by caching, thats not
> what i want!)
>
> features wanted:
>
> a not database driven
>
> b password access ist done by just renaming users home directory. User
> at logout will receive new secret subdirectory name 4 new login.
>
> c no clientside scripting. changing layout will be done by rebuilding
> all relevant static pages in user directory once by serverside script.
>
> d new entries e.g. mail, discussions will be queued, user just sees: tnx
> 4 your new article, page will be rebuilt in ... estimated 3 seconds ...
> or estimated 10 seconds ... depending on load and todo queue length.
>
> e load balancing is done by just replicating static pages between
> servers after new rebuild of static pages.
>
> f simulation of received mail directory through just rebuilding relevant
> static html tree. attachments not allowed.
>
> g intelligent todo queue 4 resorting mail sent, received, discussions,
> look and feel before rebuilding static user pages. (herein lies the
> intelligence of the whole system)
>
> h notifications 4 new mail, messages, e.t.c. are just updates in static
> html fields. if user gets offline (measured by time since last update of
> static pages) user will be informed once a day by mail.
>
> i simulation of locking can easily be done by dotfiles.
>
> j according 2 my calculations such system should be able 2 satisfy any
> bandwidth without causing significant load of cpu, due 2 low protocol
> overhead and no server side scripting, no database load. overload of
> server should not possible by design.
>
> k modules, addon 4 twitter e.g., nice 2 have
>
>
> (and no, no java!) any pointers?

Yeah, rethink your design!

Seriously, you listed a number of features which are not really
features but implementation details and you haven't told us what your
original goals are which you think are fulfilled by these
implementation details. If you would clearly state what your goals are
(regardless of how it is implemented) I'm 100% certain a better
implementation can be found than the one you enumerated.

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Popen Question

[Ravi]

On Nov 4, 7:06 pm, moogyd  wrote:
> Hi,
> I usually use csh for my simulation control scripts, but these scripts
> are becoming more complex, so I plan to use python for the next
> project.
> To this end, I am looking at subprocess.Popen() to actually call the
> simulations, and have a very basic question which is demonstrated
> below.
>
> [sde:st...@lbux03 ~]$ python
> Python 2.6 (r26:66714, Feb 21 2009, 02:16:04)
> [GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> import os, subprocess
> >>> os.environ['MYVAR'] = "myval"
> >>> p = subprocess.Popen(['echo', '$MYVAR'],shell=True)
>
> >>> p = subprocess.Popen(['echo', '$MYVAR'])
> >>> $MYVAR
> >>> p = subprocess.Popen('echo $MYVAR',shell=True)
> >>> myval
> >>> p = subprocess.Popen('echo $MYVAR')
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
>     errread, errwrite)
>   File "/usr/lib64/python2.6/subprocess.py", line 1106, in
> _execute_child
>     raise child_exception
> OSError: [Errno 2] No such file or directory
>
> I am not really sure I understand these results.
> 1) No idea what is going on
> 2) As (1). What isn't myval printed out (rather than $MYVAR)
> 3) Works as I wanted it to
> 4) Why do I need shell=True ?
> The documentation isn't very clear to me (it seems you need to
> understand the underlying system calls).
>
> Can anyone explain (or provide link) for this behaviour in simple
> English?
> Thanks,
> Steven

try giving /bin/echo
-- 
http://mail.python.org/mailman/listinfo/python-list