Mailman 3 January 2004 - Python-Dev

RE: [Python-Dev] PEP 324: popen5 - New POSIX process module
by Moore, Paul Jan. 7, 2004

Jan. 7, 2004

From: Peter Åstrand >> - The poll() method and returncode attribute aren't both needed. I like >> returncode's semantics better since it gives more information and it >> avoids using -1 as a magic number. > Well, as I described in another mail, it's actually a big advantage to > provide both a returncode attribute and an unmodified status value, since > it's makes it easy to migrate from the "old" API. Perhaps we'll need to > make some changes to the poll() method wrt Windows, though. The peculiar "combined" nature of a Unix status value has no analogue in Windows. And in the context of an object with multiple attributes, I don't see the need anyway. I'd suggest Popen.returncode - Process return code, valid on both Unix and Windows Popen.signal - Signal which caused the program to exit, Unix only. Code which is meant to be portable (to whatever extent that is possible) can use returncode without any problems. Code which is Unix-specific can worry about signal. (I'd suggest signal=0 means no signal occurred, and on Windows, signal is always 0. This means that it's still possible to write portable code which tests signal.) I'm not sure I see "migration from the old API" as an issue. Certainly not a "big advantage". This module should attempt to be "the best possible design", and as such should take the chance to ignore backwards compatibility. If it's good enough, people will be glad to change code to match. If it's *not* good enough, it won't succeed even if it tries to be compatible. This applies both to compatibility with existing Python modules (popenXXX, os, etc) and to compatibility with C APIs (which is where the overloaded returncode comes from). Let's get a good Pythonic design. Paul.

3 2

RE: [Python-Dev] Re: PEP 326 now online
by Robert Brewer Jan. 7, 2004

Jan. 7, 2004

Bob Ippolito wrote: > I just got a comment from another user suggesting modifying the > min/max.__cmp__ so that they are the actual minimum and maximum. > > An interesting approach, which makes some sense to me.Guido van Rossum wrote: and Guido van Rossum replied: > Not to me. Random reuses like this would make Python into a > mysterious language. More mysterious than these comparisons? ;) >>> 'a' > 3 True >>> '3' > 4 True Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

2 1

RE: [Python-Dev] PEP 324: popen5 - New POSIX process module
by Peter Åstrand Jan. 7, 2004

Jan. 7, 2004

> This PEP looks fantastic to me; I've often wanted a better set of > primitives for working with external processes, and your PEP has just > about everything I've ever wanted. Great :-) > I do have some minor nits to pick, though: > > - The preexec_args argument is extraneous considering how easy it is to > use a lambda construct to bind arguments to a function. Consider: > > Popen(..., preexec_fn=foo, preexec_args=(bar,baz)) > > vs. > > Popen(..., preexec_fn=lambda: foo(bar,baz)) Nice. The only drawback with this approach that I can think of right now is that this will be hard for newbies to understand, but if we give a few examples in the doc this is probably not a problem. I'll make this change, unless I hear protests. > - Rather than passing argv0 as a named argument, what about passing in > the program to execute instead? It would simplify code like this: > > Popen(child_program, *child_args[1:], argv0=child_args[0]) > > into this > > Popen(*child_args, program=child_program) > > Of course I'm not suggesting you change the default behavior of taking > argv0 *and* the program to execute from the first positional argument. I don't understand exactly what you mean here; could you provide a working example? > - The defaults for close_fds and universal_newlines should be False > rather than 0; this would make it clear from reading the synopsis that > these arguments are boolean-valued. Yes, I've fixed this now. > - The poll() method and returncode attribute aren't both needed. I like > returncode's semantics better since it gives more information and it > avoids using -1 as a magic number. Well, as I described in another mail, it's actually a big advantage to provide both a returncode attribute and an unmodified status value, since it's makes it easy to migrate from the "old" API. Perhaps we'll need to make some changes to the poll() method wrt Windows, though. > - Rather than raising a PopenException for incorrect arguments, I would > think that raising ValueError or TypeError would be more in line with > users' expectations. Sounds good to me. Anyone else has comments? > - How does this communicate() method interact with I/O redirection? Now I'm lost again. Which kind of redirection are you thinking about? /Peter

1 0

RE: [Python-Dev] PEP 326 now online
by Chermside, Michael Jan. 7, 2004

Jan. 7, 2004

Josiah Carlson writes: > I've submitted my latest changes that I believe address the concerns > brought up since I last emailed the list. [...] > The major change of note: it is no longer a builtin. Nice work! With this current proposal, you've gotten my vote to a solid +0. I find your current motivation far more convincing -- although I don't think this is something *I* would need much, I can see the advantages to having standard High and Low objects. The only open issue that I think presents any significant barrier is the question of where to put them. No answer proposed so far seems like the "one obvious place", and most have been, well, a bit peculiar (function attributes; sorting properties of function objects). Of these, I think using min and max (the functions) is my favorite solution, judging by the simple metric of what would I be most likely to remember if I had seen it mentioned in a manual once but hadn't actually used it for a long time. But Guido seems to find this a bit "too clever". -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.

1 0

Relaxing Unicode error handling
by Martin v. Loewis Jan. 7, 2004

Jan. 7, 2004

People keep complaining that they get Unicode errors when funny characters start showing up in their inputs. In some cases, these people would apparantly be happy if Python would just "keep going", IOW, they want to get moji-bake (garbled characters), instead of exceptions that abort their applications. I'd like to add a static property unicode.errorhandling, which defaults to "strict". Applications could set this to "replace" or "ignore", silencing the errors, and risking loss of data. What do you think? Regards, Martin

11 25

Dots in __name__ break import -- fixable?
by Evan Simpson Jan. 7, 2004

Jan. 7, 2004

There must be some code in the import machinery that assumes (with excellent reason) that the __name__ of the module from which it is called will never contain periods. Consider the following: >>> __name__ = 'a.b.c' >>> import string >>> string <module 'a.b.string' from '/usr/lib/python2.3/string.pyc'> The peculiar behavior is *only* triggered by periods: >>> __name__ = ''.join(map(chr, range(1, 256))).replace('.', '') >>> import string >>> string <module 'string' from '/usr/lib/python2.3/string.pyc'> Would this be easy to fix? It would fall into the realm of "so don't do that!" except that Zope's Python Scripts set their __name__ to their Zope Id, which can contain periods. Cheers, Evan @ 4-am

2 2

Re: [Python-Dev] Re: PEP 326 now online
by Guido van Rossum Jan. 7, 2004

Jan. 7, 2004

> > > One idea was to create a type called 'extreme', bind it to cmp.extreme, > > > and subclass high/low from extreme. Of course that is just one more > > > arbitrary object attached to cmp, which is even more odd. > > > > > > Another option would be for min.Min and max.Max, but I'm pretty sure > > > that would be confusing. > > > > > > The convenient part about putting them as attributes of cmp is that it > > > is obvious that they are most useful when it comes to comparing against > > > other objects. > > > > I'm not convinced. > > Seemingly you are not convinced that creating attributes for cmp is > reasonable. Seemingly, attributes for min and max are equivalently as > unreasonable (and may be confusing). > > How about them being attributes of object, or even placed in the math > module? > > - Josiah Module attributes make sense; make them attributes of object has the unfortunate side effect that they will be attributes of *all* objects and that doesn't seem a good idea. The math module is only appropriate if this is primarily about float numbers. And see PEP 747 in that case. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

RE: [Python-Dev] PEP 326 now online
by Michael Chermside Jan. 7, 2004

Jan. 7, 2004

Josiah Carlson writes: > I believe I've addressed the majority of concerns had for the All > (previously Some) concept and object (the PEP editor seems to agree), > and the PEP has been posted as PEP 326. > > Give it a look: http://www.python.org/peps/pep-0326.html > > As always, comments, questions, and suggestions are always appreciated. Thanks Josiah, it looks to me like you did a good job of boiling things down to a single, specific proposal and collecting and clearly stating the arguments in favor. That's what PEP writing is all about. Unfortunately, after reading PEP 326, I find myself convinced that it is NOT a good idea, and I would encourage the BDFL to reject the PEP. My reasons are quite simple: (1) As the PEP demonstrates, creating a value that sorts larger than any other is extremely trivial. (2) The PEP's motivation succesfully demonstrates that having a "largest" value for pre-population or sentinal purposes is useful for certain algorithms. But it provides NO reason why each author of such an algorithm could not simply create such an "All" object themselves. (3) The bar is quite high for adding new built-ins. This PEP, for instance, either break or render quite confusing any program which used the identifier "All". So, unless someone shows me a convincing argument for why this is more useful when used as a built-in constant rather than being coded by each user, I think this PEP should not be included in Python. Please feel free to include this viewpoint in the "Dissenting Opinion" section of the PEP. -- Michael Chermside

7 9

RE: [Python-Dev] PEP 324: popen5 - New POSIX process module
by Moore, Paul Jan. 6, 2004

Jan. 6, 2004

From: John Williams > - Would you consider adding an example of how to chain processes > together into a pipeline? You say this is possible, and I'm assuming > that's what the PIPE constant is for, but I'd like to see it written out > to make sure I'm understanding it correctly. There's actually an example in the source code. Looking at it, I have come to the conclusion that I don't like PIPE, but I can't see an obviously better answer. The example from the code is: p1 = Popen(["dmesg"], stdout=PIPE) p2 = Popen(["grep", "hda"], stdin=p1.fromchild) result = p2.communicate()[0] Some things immediately spring from this: 1. stdout=PIPE doesn't feel like it adds anything. It's "obvious" that I want a pipe. But of course there's no way the code realises that unless I say so. 2. fromchild doesn't look too nice. I'd prefer to use "stdin=p1.stdout". 3. communicate() doesn't really describe what it does very well. As far as PIPE goes, the issue is that there are (to me) two, almost equally common, options - to simply inherit the parent's stdXXX (like os.system does) and to set up pipes to (some or all of) the child's stdXXX, which the parent then talks to. PIPE says to set up a pipe, where the default is to inherit. I'd like to see a better option, but I can't immediately think of one. This cries out for a "just do what I mean" option :-) Maybe inverting the sense of the argument, and saying pipe=STDOUT, or in the case of multiple pipes, pipe=(STDIN, STDOUT), is better. What do people think? But remember that *all* of these look worse if you don't use from...import style: stdout=popen5.PIPE or pipe=popen5.STDOUT. Part of me wonders whether the creation of the child process should be split out of the constructor, so that we do p1 = Popen(...); p1.start(). Then setting up pipes could happen between the two. But I can't think of a syntax I like for setting up pipes even then, and I see no other advantage to a separate start() method. I'll see what this feels like when I have practical experience implementing the Windows version under my belt... Paul. PS If this becomes a design discussion, is python-dev (or even python-list) appropriate? Would it be better to set up a SIG for this, much like optparse had the getopt-sig for a while?

2 1

test_unicode_file fails on Linux
by Jeremy Hylton Jan. 6, 2004

Jan. 6, 2004

The utime() call is failing for one of the Unicode file names. build> ./python ../Lib/test/test_unicode_file.py test_directories (__main__.TestUnicodeFiles) ... ok test_equivalent_files (__main__.TestUnicodeFiles) ... ok test_single_files (__main__.TestUnicodeFiles) ... '@test-\xc3\xa0\xc3\xb2' '@test-\xc3\xa0\xc3\xb2' u'@test-\xe0\xf2' ERROR ====================================================================== ERROR: test_single_files (__main__.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_unicode_file.py", line 143, in test_single_files self._test_single(TESTFN_UNICODE) File "../Lib/test/test_unicode_file.py", line 117, in _test_single self._do_single(filename) File "../Lib/test/test_unicode_file.py", line 33, in _do_single os.utime(filename, None) UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-7: ordinal not in range(128) I'm running on a RH9 system. I see that the code hasn't changed since the beginning of the month, so I'm surprised to only discover it now. I can't recall the last time I did a full test run, so I'm not sure how long it has been failing. Jeremy

7 8