[Python-Dev] Mac questions
I'm working on refactoring Python/import.c, currently the case_ok() function. I was wondering about these lines: /* new-fangled macintosh (macosx) */ #elif defined(__MACH__) defined(__APPLE__) defined(HAVE_DIRENT_H) Is this for Mac OSX? Does the Mac have a case insensitive file system (my experiments on the SF compile farm say no)? And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac questions
On Jan 4, 2005, at 5:00 AM, Thomas Heller wrote: I'm working on refactoring Python/import.c, currently the case_ok() function. I was wondering about these lines: /* new-fangled macintosh (macosx) */ #elif defined(__MACH__) defined(__APPLE__) defined(HAVE_DIRENT_H) Is this for Mac OSX? Does the Mac have a case insensitive file system (my experiments on the SF compile farm say no)? Yes, this tests positive for Mac OS X (and probably other variants of Darwin). Yes, Mac OS X uses a case preserving but insensitive file system by default (HFS+), but has case sensitive file systems (UFS, and a case sensitive version of HFS+, NFS, etc.). The SF compile farm may use one of these alternative file systems, probably NFS if anything. And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Yes, definitely. I'm positive you can do this with CoreServices, but I'm not sure it's portable to Darwin (not Mac OS X). I'm sure there is some Darwin-compatible way of doing it, but I don't know it off the top of my head. I'll try to remember to look into it if nobody else finds it first. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
On Jan 4, 2005, at 5:56 AM, Jack Jansen wrote: On 3 Jan 2005, at 23:40, Bob Ippolito wrote: Most people on Mac OS X have a lot of memory, and Mac OS X generally does a good job about swapping in and out without causing much of a problem, so I'm personally not very surprised that it could go unnoticed this long. *Except* when you're low on free disk space. 10.2 and before were really bad with this, usually hanging the machine, 10.3 is better but it's still pretty bad when compared to other unixen. It probably has something to do with the way OSX overcommits memory and swapspace, for which it apparently uses a different algorithm than FreeBSD or Linux. I wouldn't be surprised if the bittorrent problem report in this thread was due to being low on diskspace. And that could also be true for the original error report that sparked this discussion. I was able to trigger this bug with a considerable amount of free disk space using a laptop that has 1GB of RAM, although I did have to increase the buffer size from the given example quite a bit to get it to fail. After all, a 32-bit process can't have more than 4 GB of addressable memory. I am pretty sure that OS X is never supposed to overcommit memory. The disk thrashing probably has a lot to do with the fact that Mac OS X will grow and shrink its swap based on demand, rather than having a fixed size swap partition as is common on other unixen. I've never seen the problem myself, though. From what I remember about Linux, its malloc implementation merely increases the address space of a process. The actual allocation will happen when you try and access the memory, and if it's overcommitted things will fail in a bad way. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac questions
On 4 Jan 2005, at 11:41, Bob Ippolito wrote: And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Yes, definitely. I'm positive you can do this with CoreServices, but I'm not sure it's portable to Darwin (not Mac OS X). I'm sure there is some Darwin-compatible way of doing it, but I don't know it off the top of my head. I'll try to remember to look into it if nobody else finds it first. I haven't used pure darwin, but I assume it has support for FSRefs, right? Then you could use FSPathMakeRef() to turn the filename into an FSRef, and then FSGetCatalogInfo() to get the true filename. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Please help complete the AST branch
On Mon, 2005-01-03 at 23:17, Tony Meyer wrote: Perhaps interested parties should take up the discussion on the compiler-sig. This isn't listed in the 'currently active' SIGs list on http://python.org/sigs/ - is it still active, or will it now be? If so, perhaps it should be added to the list? By 'discussion on', do you mean via the wiki at http://www.zope.org/Members/jeremy/CurrentAndFutureProjects/PythonAST? If compiler-sig is where ASTers want to hang out, I'd be happy to resurrect it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac questions
On Jan 4, 2005, at 7:42 AM, Jack Jansen wrote: On 4 Jan 2005, at 11:41, Bob Ippolito wrote: And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Yes, definitely. I'm positive you can do this with CoreServices, but I'm not sure it's portable to Darwin (not Mac OS X). I'm sure there is some Darwin-compatible way of doing it, but I don't know it off the top of my head. I'll try to remember to look into it if nobody else finds it first. I haven't used pure darwin, but I assume it has support for FSRefs, right? Then you could use FSPathMakeRef() to turn the filename into an FSRef, and then FSGetCatalogInfo() to get the true filename. I believe your assumption is wrong. CoreServices is not open source, and this looks like it confirms my suspicion: (from CoreFoundation/CFURL.h) #if !defined(DARWIN) struct FSRef; CF_EXPORT CFURLRef CFURLCreateFromFSRef(CFAllocatorRef allocator, const struct FSRef *fsRef); CF_EXPORT Boolean CFURLGetFSRef(CFURLRef url, struct FSRef *fsRef); #endif /* !DARWIN */ -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please help complete the AST branch
The list archives look like they are mostly full of spam, but it's also the only list we've used to discuss the ast work. I haven't really worried whether the sig was active, as long as the list was around. I don't mind if you want to resurrect it. Is there some way to delete the spam from the archives? By discussion on I meant a discussion of the remaining work. I'm not sure why you quoted just that part. I was suggesting that there is an ongoing discussion that should continue on the compiler-sig. Jeremy On Tue, 04 Jan 2005 07:43:28 -0500, Barry Warsaw [EMAIL PROTECTED] wrote: On Mon, 2005-01-03 at 23:17, Tony Meyer wrote: Perhaps interested parties should take up the discussion on the compiler-sig. This isn't listed in the 'currently active' SIGs list on http://python.org/sigs/ - is it still active, or will it now be? If so, perhaps it should be added to the list? By 'discussion on', do you mean via the wiki at http://www.zope.org/Members/jeremy/CurrentAndFutureProjects/PythonAST? If compiler-sig is where ASTers want to hang out, I'd be happy to resurrect it. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Jan 4, 2005, at 1:28 PM, Guido van Rossum wrote: Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing. +1 I like this idea. It may have some effect on current versions of PyObjC though, because we really do care about what self is in order to prevent crashes. This is not a discouragement; we are already using custom descriptors and a metaclass, so it won't be a problem to do this ourselves if we are not doing it already. I'll try and find some time later in the week to play with this patch to see if it does break PyObjC or not. If it breaks PyObjC, I can sure that PyObjC 1.3 will be compatible with such a runtime change, as we're due for a refactoring in that area anyway. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote: In my blog I wrote: Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing. Does anyone think this is a bad idea? Anyone want to run with it? I like the idea, it means I can get rid of this[1] func = getattr(cls, 'do_command', None) setattr(cls, 'do_command', staticmethod(func.im_func)) # don't let anyone on c.l.py see this .. or at least change the comment *grin*, -Jack [1] http://cvs.sourceforge.net/viewcvs.py/lyntin/lyntin40/sandbox/leantin/mudcommands.py?view=auto ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Let's get rid of unbound methods
[Guido van Rossum] Let's get rid of unbound methods. +1 [Jim Fulton] duck typing? Requiring a specific interface instead of a specific type. [Guido] Does anyone think this is a bad idea? [Jim] It *feels* very disruptive to me, but I'm probably wrong. We'll still need unbound builtin methods, so the concept won't go away. In fact, the change would mean that the behavior between builtin methods and python methods would become more inconsistent. The type change would be disruptive and guaranteed to break some code. Also, it would partially breakdown the distinction between functions and methods. The behavior, on the other hand, would remain essentially the same (sans type checking). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: In my blog I wrote: Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing. This would make pickling (or any serialization mechanism) of `Class.method' based on name next to impossible. Right now, with the appropriate support, this works: import pickle class Foo: ... def bar(self): pass ... pickle.loads(pickle.dumps(Foo.bar)) unbound method Foo.bar I don't see how it could if Foo.bar were just a function object. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 04 Jan 2005 20:02:06 GMT, Jp Calderone [EMAIL PROTECTED] wrote: On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: In my blog I wrote: Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing. This would make pickling (or any serialization mechanism) of `Class.method' based on name next to impossible. Right now, with the appropriate support, this works: It occurs to me that perhaps I was not clear enough here. What I mean is that it is possible to serialize unbound methods currently, because they refer to both their own name, the name of their class object, and thus indirectly to the module in which they are defined. If looking up a method on a class object instead returns a function, then the class is no longer knowable, and most likely the function will not have a unique name which can be used to allow a reference to it to be serialized. In particular, I don't see how one will be able to write something equivalent to this: import new, copy_reg, types def pickleMethod(method): return unpickleMethod, (method.im_func.__name__, method.im_self, method.im_class) def unpickleMethod(im_name, im_self, im_class): unbound = getattr(im_class, im_name) if im_self is None: return unbound return new.instancemethod(unbound.im_func, im_self, im_class) copy_reg.pickle(types.MethodType, pickleMethod, unpickleMethod) But perhaps I am just overlooking the obvious. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 4 Jan 2005 12:18:15 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: [me] Actually, unbound builtin methods are a different type than bound builtin methods: [Jim] Of course, but conceptually they are similar. You would still encounter the concept if you got an unbound builtin method. Well, these are all just implementation details. They really are all just callables. [Jp] This would make pickling (or any serialization mechanism) of `Class.method' based on name next to impossible. Right now, with the appropriate support, this works: import pickle class Foo: ... def bar(self): pass ... pickle.loads(pickle.dumps(Foo.bar)) unbound method Foo.bar I don't see how it could if Foo.bar were just a function object. Is this a purely theoretical objection or are you actually aware of anyone doing this? Anyway, that approach is pretty limited -- how would you do it for static and class methods, or methods wrapped by other decorators? It's not a feature I often depend on, however I have made use of it on occassion. Twisted's supports serializing unbound methods this way, primarily to enhance the useability of tap files (a feature whereby an application is configured by constructing a Python object graph and then pickled to a file to later be loaded and run). Objection may be too strong a word for my stance here, I just wanted to point out another potentially incompatible behavior change. I can't think of any software which I cam currently developing or maintaining which benefits from this feature, it just seems unfortunate to further complicate the already unpleasant business of serialization. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 11:40 AM 1/4/05 -0800, Guido van Rossum wrote: [Jim] We'll still need unbound builtin methods, so the concept won't go away. In fact, the change would mean that the behavior between builtin methods and python methods would become more inconsistent. Actually, unbound builtin methods are a different type than bound builtin methods: type(list.append) type 'method_descriptor' type([].append) type 'builtin_function_or_method' Compare this to the same thing for a method on a user-defined class: type(C.foo) type 'instancemethod' type(C().foo) type 'instancemethod' (The 'instancemethod' type knows whether it is a bound or unbound method by checking whether im_self is set.) [Phillip] Code that currently does 'aClass.aMethod.im_func' in order to access the function object would break, as would code that inspects 'im_self' to determine whether a method is a class or instance method. (Although code of the latter sort would already break with static methods, I suppose.) Right. (But I think you're using the terminology in a cunfused way -- im_self distinguishes between bould and unbound methods. Class methods are a different beast.) IIUC, when you do 'SomeClass.aMethod', if 'aMethod' is a classmethod, then you will receive a bound method with an im_self of 'SomeClass'. So, if you are introspecting items listed in 'dir(SomeClass)', this will be your only clue that 'aMethod' is a class method. Similarly, the fact that you get an unbound method object if 'aMethod' is an instance method, allows you to distinguish it from a static method (if the object is a function). That is, I'm saying that code that looks at the type and attributes of 'aMethod' as retrieved from 'SomeClass' will now not be able to distinguish between a static method and an instance method, because both will return a function instance. However, the 'inspect' module uses __dict__ rather than getattr to get at least some attributes, so it doesn't rely on this property. I guess for backwards compatibility, function objects could implement dummy im_func and im_self attributes (im_func returning itself and im_self returning None), while issuing a warning that this is a deprecated feature. +1 on this part if the proposal goes through. On the proposal as a whole, I'm -0, as I'm not quite clear on what this is going to simplify enough to justify the various semantic impacts such as upcalls, pickling, etc. Method objects will still have to exist, so ISTM that this is only going to streamline the __get__(None,type) branch of functions' descriptor code, and the check for im_self is None in the __call__ of method objects. (And maybe some eval loop shortcuts for calling methods?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] super() harmful?
[Josiah] Agreed. While it seems that super() is the 'modern paradigm' for this, I have been using base.method(self, ...) for years now, and have been quite happy with it. After attempting to convert my code to use the super() paradigm, and having difficulty, I discovered James Knight's Python's Super Considered Harmful (available at http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I discovered how super really worked (I should have read the documention in the first place), and reverted my changes to the base.method version. I think that James Y Knight's page misrepresents the issue. Quoting: Note that the __init__ method is not special -- the same thing happens with any method, I just use __init__ because it is the method that most often needs to be overridden in many classes in the hierarchy. But __init__ *is* special, in that it is okay for a subclass __init__ (or __new__) to have a different signature than the base class __init__; this is not true for other methods. If you change a regular method's signature, you would break Liskov substitutability (i.e., your subclass instance wouldn't be acceptable where a base class instance would be acceptable). Super is intended for use that are designed with method cooperation in mind, so I agree with the best practices in James's Conclusion: * Use it consistently, and document that you use it, as it is part of the external interface for your class, like it or not. * Never call super with anything but the exact arguments you received, unless you really know what you're doing. * When you use it on methods whose acceptable arguments can be altered on a subclass via addition of more optional arguments, always accept *args, **kw, and call super like super(MyClass, self).currentmethod(alltheargsideclared, *args, **kwargs). If you don't do this, forbid addition of optional arguments in subclasses. * Never use positional arguments in __init__ or __new__. Always use keyword args, and always call them as keywords, and always pass all keywords on to super. But that's not the same as calling it harmful. :-( -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Tim Peters [EMAIL PROTECTED] wrote: [Tim Peters] ... Unbound methods are used most often (IME) to call a base-class method from a subclass, like my_base.the_method(self, ...). It's especially easy to forget to write `self, ` there, and the exception msg then is quite focused because of that extra bit of type checking. Otherwise I expect we'd see a more-mysterious AttributeError or TypeError when the base method got around to trying to do something with the bogus `self` passed to it. [Josiah Carlson] Agreed. Well, it's not that easy to agree with. Guido replied that most such cases would raise an argument-count-mismatch exception instead. I expect that's because he stopped working on Zope code, so actually thinks it's odd again to see a gazillion methods like: class Registerer(my_base): def register(*args, **kws): my_base.register(*args, **kws) I bet he even presumes that if you chase such chains long enough, you'll eventually find a register() method *somewhere* that actually uses its arguments wink. If type checking is important, one can always add it using decorators. Then again, I would be willing to wager that most people wouldn't add it due to laziness, until it bites them for more than a few hours worth of debugging time. While it seems that super() is the 'modern pradigm' for this, I have been using base.method(self, ...) for years now, and have been quite happy with it. After attempting to convert my code to use the super() paradigm, and having difficulty, I discovered James Knight's Python's Super Considered Harmful (available at http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I discovered how super really worked (I should have read the documention in the first place), and reverted my changes to the base.method version. How did super() get into this discussion? I don't think I've ever used it myself, but I avoid fancy inheritance graphs in my own code, so can live with anything. It was my misunderstanding of your statement in regards to base.method. I had thought that base.method(self, ...) would stop working, and attempted to discover how one would be able to get the equivalent back, regardless of the inheritance graph. I could live with it too, but I would probably use an equivalent of the following (with actual type checking): def mysuper(typ, obj): lm = list(o.__class__.__mro__) indx = lm.index(typ) if indx == 0: return obj return super(lm[indx-1], obj) All in all, I'm -0. I don't desire to replace all of my base.method with mysuper(base, obj).method, but if I must sacrifice convenience for the sake of making Python 2.5's implementation simpler, I guess I'll deal with it. My familiarity with grep's regular expressions leaves something to be desired, so I don't know how often base.method(self,...) is or is not used in the standard library. I think there may be a misunderstanding here. Guido isn't proposing that base.method(self, ...) would stop working -- it would still work fine. The result of base.method would still be a callable object: it would no longer be of an unbound method type (it would just be a function), and wouldn't do special checking on the first argument passed to it anymore, but base.method(self, ...) would still invoke the base class method. You wouldn't need to rewrite anything (unless you're doing heavy-magic introspection, picking callables apart). Indeed, there was a misunderstanding on my part. I misunderstood your discussion of base.method(self, ...) to mean that such things would stop working. My apologies. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Csv] csv module TODO list
Andrew There's a bunch of jobs we (CSV module maintainers) have been Andrew putting off - attached is a list (in no particular order): ... In addition, it occurred to me this evening that there's functionality in the csv module I don't think anybody uses. For example, you can register CSV dialects by name, then pass in the string name instead of the dialect class. I'd be in favor of scrapping list_dialects, register_dialect and unregister_dialect altogether. While they are probably trivial little functions I don't think they add much if anything to the implementation and just complicate the _csv extension module slightly. I'm also not aware that anyone really uses the Sniffer class, though it does provide some useful functionality should you need to analyze random CSV files. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: Re: [Python-Dev] Will ASTbranch compile on windows yet?
[TIM] I don't have time to join the current crusade. If there's pent-up interest among Windows users, it would be good to say which compiler(s) you can use, since I expect not everyone can deal with VC 7.1 (e.g., I think Raymond Hettinger is limited to VC 6; and you said you worked up a VC 6 patch, but didn't say whether you could use 7.1 now). I've attached an updated patch that gets things working against current cvs. This also includes some fixes for typos that appear to have slipped through gcc and my have caused obscure bugs in *nix as well. I'll gladly fix the MSVC 7.1 project files after someone with commit privleges merges changes from HEAD as Jeremy requested. Any windows users building based on this patch would also need to run the 'asdl_c.py' utility manually right now before compiling. Something like: C:\Src\ast-branch\dist\src\Parserasdl_c.py -h ..\Include -c ..\Python Python.asdl I'll get a proper fix in for MSVC 7.1, but don't feel like dealing with it for the obsolete 6.0 project files. -Grant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
