Mailman 3 June 2006 - Python-Dev

msvccompiler.py: some remarks
by Jeroen Ruigrok van der Werven June 30, 2006

June 30, 2006

I am testing/working on some Python code on Windows. During this I encounter some issues where I am being told I don't have the .Net SDK installed. So I started investigating this issue and came to http://www.vrplumber.com/programming/mstoolkit/index.html I also checked the latest repository version of msvccompiler.py and I noticed a few potential issues: 1) If MSSdk is set it does not automatically mean that cl.exe and the rest are available. With the latest SDKs, Windows 2003 R2 at least, the bin directory contains no compilers, linkers or the like. On the other hand, it is perfectly valid to set MSSdk to your Platform SDK installation directory. So this is unfortunately a problematic solution as introduced in revision 42515. 2) As far as I have been able to determine .Net 2.0 uses sdkInstallRootv2.0. Also it installs by default under C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\ 3) The Windows 2003 R2 Platform SDK uses HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDKs\D2FF9F89-8AA2-4373-8A31-C838BF4DBBE1, which in turn has a entry for 'Install Dir' which lists the installation directory for the Platform SDK. 4) One line has p = r"Software\Microsoft\NET Framework Setup\Product", however, there's no subkey at all under my NET Framework Setup entry, only NDP, which in itself has two subkeys, namely: v1.1.4322 and v2.0.50727. The NET Framework Setup\Product seems to be limited to the old 1.0 setup which used a subkey like: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\Product\Microsoft .NET Framework Full v1.0.3705 (1033) This is what my 1.1 and 2.0 give: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322 and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 So effectively on newer installations (and 1.0 is more or less deprecate in favour of 1.1) this piece of code is rendered unusable. So basically a bunch of logic needs to be rewritten for newer version support and I will investigate this. Are there any other people working on this so that I can throw back/forth some ideas to make sure things keep working for various versions? -- Jeroen Ruigrok van der Werven

3 4

PEP 3103: A Switch/Case Statement
by Guido van Rossum June 30, 2006

June 30, 2006

I've written a new PEP, summarizing (my reaction to) the recent discussion on adding a switch statement. While I have my preferences, I'm trying to do various alternatives justice in the descriptions. The PEP also introduces some standard terminology that may be helpful in future discussions. I'm putting this in the Py3k series to gives us extra time to decide; it's too important to rush it. http://www.python.org/dev/peps/pep-3103/ Feedback (also about misrepresentation of alternatives I don't favor) is most welcome, either to me directly or as a followup to this post. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

12 48

xturtle.py a replacement for turtle.py(!?)
by Gregor Lingl June 29, 2006

June 29, 2006

xturtle.py, extended turtle graphics a new Tkinter based turtle graphics module for Python I just have released xturtle.py (v.0.91). It can be found at: http://sourceforge.net/tracker/?group_id=5470&atid=305470 with RequestID 1513695 (and 1513699 for the docs) and also here http://ada.rg16.asn-wien.ac.at/~python/xturtle with some supplementary information. xturtle was first announced at the edu-sig and is reported to work properly on all major platforms (Mac, Linux and Windows) Now I was suggested to discuss it on this list. So I'll try. For now I'll give only two indroductory statements and wait for a response, hoping that a fruitful discussion will evolve. (I) The module xturtle.py is an extended reeimplementation of turtle.py, retains its merits and is backward compatible to turtle.py. Enhancements over turtle.py are: # Better animation of the turtle movements, especially of turning the turtle. So the turtles can more easily be used as a visual feedback instrument by the (beginning) programmer. # Different turtle shapes, gif-images as turtle shapes, user defined and user controllable turtle shapes, among them compound (multicolored) shapes. # Fine control over turtle movement and screen updates via delay(), and enhanced tracer() and speed(), update() methods. # Aliases for the most commonly used commands, like fd for forward etc., following the early Logo traditions. This reduces the boring work of typing long sequences of commands, which often occur in a natural way when kids try to program fancy pictures on their first encounter with turtle graphcis (still not knowing nothing about loops). # Some simple commands/methods for creating event driven programs (mouse-, key-, timer-events). Especially useful for programming simple games. # A scrollable Canvas class. The scrollable Canvas can be extended interactively as needed while playing around with the turtle(s) (e. g. to follow some escaped turtle). The Window containing the default canvas when using the Pen - class also can be resized and repositioned programmatically. # Commands for controlling background color or background image. (II) Motives: I designed this module to provide utmost easy access to a sufficiently rich graphics toolkit. I consider this crucial as well for students as for teachers, who e. g. have to decide which programming language to use for teaching programming. Considering turtle graphics as a very appropriate tool for introductory programming courses I used the current turtle.py as a central tool in my book "Python for kids" despite beeing well aware of its deficiencies. Now I propose a better one. You may unterstand by intentions best by having a look at the 25+ example scripts (with the included demoViewer) provided in the xturtle.zip file, which can be downloaded from the above mentioned website. (I think these demos should not be included in the standard distribution, they could go into a special edu-distro as Kirby Urner suggested lately.) I would very much appreciate if xturtle.py could go into Python 2.5 Let's see Gregor

15 26

PEP 328 and PEP 338, redux
by Jim Jewett June 29, 2006

June 29, 2006

> Real-world usage case for import __main__? Typically for inter-module communication. A standard name (such as lobby, or __settings__) would work as well, but __main__ is what we have, for backwards compatibility. -jJ

1 0

Joke: Rush Limbaugh (a joke in and of himself)
by Scott David Daniels June 29, 2006

June 29, 2006

Rush Limbaugh was detained and questioned for transporting a possible illegal Viagra prescription into the country. Well... a least we know his back is feeling better. -- Scott David Daniels Scott.Daniels(a)Acm.Org

2 2

document @property?
by Georg Brandl June 29, 2006

June 29, 2006

In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? Georg

3 2

once [was: Simple Switch statementZ]
by Jim Jewett June 29, 2006

June 29, 2006

On 6/25/06, Ka-Ping Yee <python-dev at zesty.ca> wrote: > def f(x): > def g(y): > return y + once x > return g > Does "once" mean not really once here, but "once for each new function > object that's created for g"? Until today, it hadn't really occurred to me that once could mean once per module load rather than once per defining scope. I suppose that is reasonable if the values really are constant, but most of the concerns are about what to do when this assumption is violated. It does add a bit of funny flow-control, though. def f(): def g(): def h(): once x # or switch Normally, there wouldn't be any need to even look inside g (let alone h) at module load time, because the definition of f was run, but the definitions of g and h were not. With module-level once, x is implicitly a module-level variable despite the nesting. Guido: > He specifically wants the latter semantics because it solves the > problem of binding the value of a loop control variable in an outer > scope: Not really. To solve the loop control problem (where the "constant" is certainly not a run-time constant), a once variable also has to be eagerly evaluated. (function definition time?) Nick suggested using once to delay computation of expensive defaults. This means that even if every generated function has its own once variable, none of those variables would be bound to any specific value until they are called -- by which time the loop variable may well be rebound. -jJ

5 9

PyGIL_ and --without-threads
by Thomas Heller June 29, 2006

June 29, 2006

The PyGIL_ function prototypes in the header files are not protected within #ifdef WITH_THREADS ... #endif blocks. I think it is worth do implement this although currently I don't have time for that. Thanks, Thomas

1 0

PEP 328 and PEP 338, redux
by Nick Coghlan June 29, 2006

June 29, 2006

Mitch Chapman [1] tripped over the fact that relative imports don't like main modules because __name__ doesn't contain any package hierarchy information. It occurred to me that a slight modification to PEP 338 might solve the problem fairly cleanly: instead of simply setting __name__ to '__main__' for a module in a package, the -m switch could prepend the package name so that relative imports can work correctly. Inside the module, the test for "am I the main module" would need to be "__name__.endswith('__main__')" instead of "__name__ == '__main__'", but other than that, there should be very little impact. By sticking the main module into sys.modules under two different names (once with the package prefix and once without), runpy could even take care of ensuring that the following invariant held: import __main__ by_name = __import__(__main__.__name__) assert by_name is __main__ The behaviour of top level modules would be unaffected, since they won't have a package prefix. Cheers, Nick. [1] http://www.python.org/sf/1510172 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

7 9

Re: [Python-Dev] [Python-checkins] r47142 - in python/trunk: Doc/lib/librunpy.tex Lib/runpy.py Lib/test/test_runpy.py
by Anthony Baxter June 29, 2006

June 29, 2006

On Wednesday 28 June 2006 20:41, nick.coghlan wrote: > Author: nick.coghlan > Date: Wed Jun 28 12:41:47 2006 > New Revision: 47142 > > Modified: > python/trunk/Doc/lib/librunpy.tex > python/trunk/Lib/runpy.py > python/trunk/Lib/test/test_runpy.py > Log: > Make full module name available as __module_name__ even when > __name__ is set to something else (like '__main__') Er. Um. Feature freeze? Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1