Mailman 3 August 2004 - Python-Dev

'commands' module on Win32
by Nick Coghlan Aug. 13, 2004

Aug. 13, 2004

Bug #1008275 refers to attempting to run commands.getstatusoutput() on win32, and the fact that it breaks. The reason it breaks is because it expects a posix shell, and this is noted in the documentation for the module (or rather, the module is noted as only supported on Unix). commands.getstatusoutput() and commands.getoutput() can easily be fixed to run properly on Windows (using "if os.name == 'posix'" to select the correct formatting for the shell command). Only the first one actually needs to be fixed, since getoutput() just returns the second element of the tuple returned by getstatusoutput() The dirty holdout is commands.getstatus(). This function does *not* simply return the first element of the tuple returned by commands.getstatusoutput() as you might expect. Instead of returning the status code resulting from executing its argument as a shell command, it insteads calls 'ls -ld <arg>' to get the file information. (And this is a function in the commands module exactly why?) This actually works for me, but only because I have MSYS & MINGW installed :) Anyway, getstatusoutput() and getoutput() seem like very handy ways to make a command line call and get its results. I'd never seen them before because they're squirelled away as Unix specific modules. Are there any objections to changing this module so that only getstatus() is marked as Unix specific? I ask, because I don't want to start work on a documentation patch if the idea is a non-starter (the code & test changes are already done, butI think the hardest part of the exercise will be moving the documentation out of the 'Unix-specific' part of the doc tree). Cheers, Nick. -- Nick Coghlan | Eugene, Oregon Email: ncoghlan(a)email.com | USA

3 3

Prothon on CPython intrepreter? [PROTHON]
by Mark Hahn Aug. 13, 2004

Aug. 13, 2004

I got such excellent help from Python-dev on the Prothon decimal question that I've come back for a really big question. :-) I've announced recently that Prothon was switching from a homegrown (CProthon) interpreter to a .Net implementation like IronPython. The logic was that Prothon would get a library and a community much faster. What it got very quickly was a backlash from people, including Guido, who wanted Prothon to stay away from the dark side and remain pure like CPython. I've said in the past that Prothon couldn't use the CPython interpreter. I made this determination late last year when I first started the Prothon project because CPython was incompatible with my goals of pre-emptive threads with no GIL, object locking, etc. Now I find myself compromising my goals for .Net in that I cannot implement object-locking and lightweight threads. I am also going to be mixing real classes with my prototypes, although this is something I have determined I want to do for other reasons (it's a long story). I'm sure you've heard the joke that ends with "we've established you're a whore, now we are just haggling over the price". If I can compromise Prothon for .Net, why can't I compromise it some more for CPython? So I am thinking of doing a Prothon implementation in CPython before doing the .Net version. I will get a library and community fast like I would have with .Net. This CPython->.Net->CProthon roadmap will get Prothon out quickly and slowly easy my wild ideas for the interpreter into Prothon. It will also make CPython a multiple language VM for the first time. So, I'll finally get to some questions: 1) Guido: Does this address the reason you asked me not to switch to .Net, or did you specifically want me to do CProthon? I think this will still be a good sandbox for Python. It should be quite interesting to see how far I can stretch the Python interpreter. Who knows how many of my CProthon engine features I might be able to add to CPython. 2) Lenard Lindstrom said he thought I could "Add some extra byte code instructions to handle Prothon's distinct scoping rules and implement prototypes using PyType_Type". He also said "All attribute accesses would be through a special attribute handler method". I don't know the Python interpreter code yet, but does this sound workable to everyone? It doesn't have to be Python compatible. 3) Could Tim Peter's welcome offer to Prothon here on Python-dev be stretched to include the many questions I would have when modifying CPython? In other words would this project be welcomed as a sandbox for Python or would it be an unwelcome drain on your limited resources? If any of you want to see background material on Prothon, my VanPy talk is at: http://prothon.org/pub/prothon/docs/vanpy/ProthonTalk.htm. The section titled "engine" is about the homegrown engine and wouldn't be applicable to anything on .Net or CPython. Thanks for you attention. I would love to find a solution that lets me work with the wonderful Python community.

3 4

Call for defense of @decorators
by Guido van Rossum Aug. 13, 2004

Aug. 13, 2004

It seems a public outcry against @decorators has started. When I let Anthony check it in for 2.4a2, the plan was to see how it fares in a2 and a3, and possibly take it out in 2.4b1. If you don't want that to happen, you might want to say something in public in defense of @decorators. We also need help updating the PEP; it doesn't mention @decorators, and it doesn't even begin to mention the pro and con of many other suggestions (does it say why "def decorator func(...)" was rejected?). I don't have time for any of this; I can barely make time for a few emails per day. Perhaps the @advocates can elect or volunteer a PEP editor. I really don't care if everybody thinks it's ugly. I do care to find out about usability issues. For example, it may cause problems for Leo, but I don't know how bad that is. I also want to find out about superior syntax proposals (from __future__ import decorators might be acceptable). An argument about timing: IMO there's no point in putting it off until 2.5 -- the syntax options don't get prettier, backwards compatibility issues don't get easier by waiting, and as it is it will probably take a year from 2.4's release in December before it is the mainstream Python version. --Guido van Rossum (home page: http://www.python.org/~guido/)

43 169

Re: [Python-Dev] Another approach to decorators.
by Michel Pelletier Aug. 13, 2004

Aug. 13, 2004

> Message: 2 > Date: Tue, 10 Aug 2004 12:55:19 -0400 > From: Martin Zarate <mzarate(a)uoguelph.ca> > Subject: [Python-Dev] Another approach to decorators. > To: python-dev(a)python.org > Message-ID: <1092156919.4118fdf7b71c4(a)webmail.uoguelph.ca> > Content-Type: text/plain; charset=ISO-8859-1 > > @ means nothing to an uninformed eye. This violates the most important > feature of Python (imho) which is that it is "runnable pseudocode". Yes! > I submit that the most Python solution, that would also be legible (but not > necessarily very pretty) would be to actually make the decorator a bona-fide > block that you nest your class or function into. > > remake functor(foo, bar), staticmethod: > def baz(): > pass > > This concretely shows the relationship of the original define statement to its > wrapper objects. The principle is simple - the remake block will close with > only one object in its immediate namespace I like your idea a lot, buy why just one? Your scheme of making decorators a block could be applied to several methods in a class: class Foo: decorate static: def static1(blah...): pass def static2(blah...): pass To me, this idea looks more like Python than all the rest, and allows you to consolidate related decorated methods and classes. Nest them to apply decorators "aquisition style": class Foo: decorate static: def static1(blah...): pass decorate locksFile: def static2andLocks(blah...): # both decorators appy pass -Michel

8 16

Re: 'commands' module on Win32
by Johannes Gijsbers Aug. 13, 2004

Aug. 13, 2004

Nick Coghlan <ncoghlan(a)iinet.net.au> wrote: > Are there any objections to changing this module so that only > getstatus() is marked as Unix specific? Not from me. > I ask, because I don't want to start work on a documentation patch if > the idea is a non-starter (the code & test changes are already done, > butI think the hardest part of the exercise will be moving the > documentation out of the 'Unix-specific' part of the doc tree). This is pretty easy actually. In fact, while I was checking whether it really was easy, I created a patch you could use. It's attached. Johannes

1 0

Error in Python Tutorial on Multiple Inheritence
by Steven Kah Hien Wong Aug. 13, 2004

Aug. 13, 2004

Hi, From: http://docs.python.org/tut/node11.html#SECTION0011510000000000000000 This paragraph (last two sentences): It is clear that indiscriminate use of multiple inheritance is a maintenance nightmare, given the reliance in Python on conventions to avoid accidental name conflicts. A well-known problem with multiple inheritance is a class derived from two classes that happen to have a common base class. While it is easy enough to figure out what happens in this case (the instance will have a single copy of ``instance variables'' or data attributes used by the common base class), it is not clear that these semantics are in any way useful. Maybe I have misread, but I have interpreted that as meaning the two children will share the same instance of the base class. So if one child changes its parent, the other child will pick up that change, too. But I did some quick tests, and it turns out this isn't so. class CommonBase: x = 0 class ChildOne(CommonBase): None class ChildTwo(CommonBase): None class ChildOneAndTwo(ChildOne, ChildTwo): def run(self): ChildOne.x = 1 print "one =", ChildOne.x print "two =", ChildTwo.x ChildOneAndTwo().run() And the output was: $ python multi.py one = 1 two = 0 According to the documentation, I thought it should be: one = 1 two = 1 Mind you, I find the current behaviour is much more useful, so I am saying the documentation is in error, not the implementation. :) Have I simply misread? If so, maybe that paragraph should be rewritten to make it more clear. With an example like the above, perhaps? Steven Wong

6 5

Could getpass use streams other than stdin?
by Mike Brown Aug. 13, 2004

Aug. 13, 2004

On posix, it would be useful if I could have getpass.getpass() write the prompt to stderr or to an arbitrary stream (file-like object), rather than always writing to stdin. In my use case, I need to send the results of a command-line script to stdout after the user authenticates, and the user may be redirecting stdout, so I don't want the password prompt to pollute the output. If I could have the "Password: " show up in stderr, that would be ideal. I don't think this would be terribly difficult to implement an API like def getpass(prompt='', stream=None) if stream is None: stream = sys.stdin ... but I'm unsure of the nuances of termios and arbitrary streams. Would it be better to just make the choice be between stdin and stderr? -- in which case the API would be something like def getpass(prompt='', use_stderr=False) Or is the whole exercise a waste of time? Thanks

2 2

RE: [Python-Dev] Unifying Long Integers and Integers: baseint
by Delaney, Timothy C (Timothy) Aug. 13, 2004

Aug. 13, 2004

Gareth McCaughan wrote: > I don't think this is a good reason for rejecting "integer" > as the name of the common supertype of int and long. You'd use > isinstance(x,integer) to check whether x is an integer of > built-in type, just as you currently use isinstance(x,float) > to check whether x is a floating-point number of built-in > type. I see no reason why a cumbersome name is much advantage. All this brings to mind - is there actually a good reason to need a base type? Why not just define baseinteger as: baseinteger = int, long if the only reason for it is to use isinstance? Tim Delaney

3 3

RE: [Python-Dev] Unifying Long Integers and Integers: baseint
by Delaney, Timothy C (Timothy) Aug. 12, 2004

Aug. 12, 2004

guido(a)python.org wrote: >> All this brings to mind - is there actually a good reason to need a >> base type? Why not just define baseinteger as: >> >> baseinteger = int, long >> >> if the only reason for it is to use isinstance? > > So that an extension author *could* write an int-like type deriving > from it? Fair 'nuff. Tim Delaney

1 0

RE: [Python-Dev] Re: Decorators after 'def' should be reconsidered
by Delaney, Timothy C (Timothy) Aug. 12, 2004

Aug. 12, 2004

Barry Warsaw wrote: > On Thu, 2004-08-12 at 15:14, Skip Montanaro wrote: > >> I think '*' is syntactically available for this use. > > That was one of the characters I tried back when I was looking for @ > alternatives. For some reason I can't explain, this one just rubs me > the wrong way. > > i'll-let-tim-psychoanalyze-the-reasons-why-ly y'rs, Well, not the Tim you were thinking of, but ... I think the reason * doesn't work is that it is partially superscripted in most fonts. For example, compare: *deco @deco -deco @ and - are vertically centred with the text. However, * is positioned slightly above the text. Tim Delaney

1 0