[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 (

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? D

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

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 fr

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 unno

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 Ma

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 > - is it still active, or will it now be? If so, > perhaps it should be add

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, bu

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

Re: [Python-Dev] Please help complete the AST branch

>I was suggesting that there > is an ongoing discussion that should continue on the compiler-sig. I'd be fine with keeping this on python-dev too. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] Please help complete the AST branch

That's fine with me. We had taken it to the compiler-sig when it wasn't clear there was interest in the ast branch :-). Jeremy On Tue, 4 Jan 2005 07:31:30 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >I was suggesting that there > > is an ongoing discussion that should continue on the c

Re: [Python-Dev] Please help complete the AST branch

On Tue, 2005-01-04 at 11:17, Jeremy Hylton wrote: > That's fine with me. We had taken it to the compiler-sig when it > wasn't clear there was interest in the ast branch :-). Ok, then I'll leave compiler-sig where it is. -Barry signature.asc Description: This is a digitally signed message part

[Python-Dev] Fwd: Thank You! :)

This really goes to all python-dev folks! -- Forwarded message -- From: Erik Johnson <[EMAIL PROTECTED]> Date: Tue, 4 Jan 2005 11:19:15 -0700 Subject: Thank You! :) To: [EMAIL PROTECTED] You probably get a number of messages like this, but here is mine... My name i

Re: [Python-Dev] Please help complete the AST branch

>> I was suggesting that there is an ongoing discussion that should >> continue on the compiler-sig. Guido> I'd be fine with keeping this on python-dev too. +1 for a number of reasons: * It's more visible and would potentially get more people interested in what's happening

Re: [Python-Dev] Please help complete the AST branch

On Jan 4, 2005, at 1:23 PM, Skip Montanaro wrote: I was suggesting that there is an ongoing discussion that should continue on the compiler-sig. Guido> I'd be fine with keeping this on python-dev too. +1 for a number of reasons: * It's more visible and would potentially get more people in

[Python-Dev] Let's get rid of unbound methods

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 supp

Re: [Python-Dev] Let's get rid of unbound methods

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 u

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 argumen

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.

Re: [Python-Dev] Let's get rid of unbound methods

On Tue, Jan 04, 2005, Jim Fulton wrote: > Guido van Rossum wrote: >> >> 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. > > duck typing? "If it loo

Re: [Python-Dev] Let's get rid of unbound methods

At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote: Of course, more changes would be needed: docs, the test suite, and some simplifications to the instance method object implementation in classobject.c. Does anyone think this is a bad idea? Code that currently does 'aClass.aMethod.im_func' in order t

Re: [Python-Dev] Please help complete the AST branch

On 2005 Jan 04, at 17:17, Jeremy Hylton wrote: That's fine with me. We had taken it to the compiler-sig when it wasn't clear there was interest in the ast branch :-). Speaking for myself, I have a burning interest in the AST branch (though I can't seem to get it correctly downloaded so far, I gue

Re: [Python-Dev] Let's get rid of unbound methods

At 01:36 PM 1/4/05 -0500, Jim Fulton wrote: duck typing? AKA latent typing or, "if it walks like a duck and quacks like a duck, it must be a duck." Or, more pythonically: if hasattr(ob,"quack") and hasattr(ob,"duckwalk"): # it's a duck This is as distinct from both 'if isinstance(ob,D

[Python-Dev] Will ASTbranch compile on windows yet?

I submitted patch "[ 742621 ] ast-branch: msvc project sync" in the VC6.0 days. There were some required changes to headers as well as the project files. It had discouraged me in the past when Jeremy made calls for help on the astbranch and I wasn't even sure if the source was in a compilable

Re: [Python-Dev] Let's get rid of unbound methods

[Guido] > 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 > un

Re: [Python-Dev] Will ASTbranch compile on windows yet?

[EMAIL PROTECTED] > I submitted patch "[ 742621 ] ast-branch: msvc project sync" in > the VC6.0 days. There were some required changes to headers > as well as the project files. It had discouraged me in the past > when Jeremy made calls for help on the astbranch and I wasn't > even sure if the so

Re: [Python-Dev] Let's get rid of unbound methods

Phillip J. Eby wrote: At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote: Of course, more changes would be needed: docs, the test suite, and some simplifications to the instance method object implementation in classobject.c. Does anyone think this is a bad idea? Code that currently does 'aClass.aMet

Re: [Python-Dev] Let's get rid of unbound methods

[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: >>> ty

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

Re: [Python-Dev] Let's get rid of unbound methods

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 builti

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 func

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

Re: [Python-Dev] Let's get rid of unbound methods

[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

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 u

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 d

Re: [Python-Dev] Please help complete the AST branch

Alex Martelli wrote: On 2005 Jan 04, at 17:17, Jeremy Hylton wrote: That's fine with me. We had taken it to the compiler-sig when it wasn't clear there was interest in the ast branch :-). Speaking for myself, I have a burning interest in the AST branch (though I can't seem to get it correctly do

Re: [Python-Dev] Please help complete the AST branch

Jeff Epler wrote: On Mon, Jan 03, 2005 at 06:02:52PM -0800, Brett C. wrote: Although if someone can start sooner than by all means, go for it! And obviously help would be great since it isn't a puny codebase (4,000 lines so far for the CST->AST and AST->bytecode code). And obviously knowing a litt

Re: [Python-Dev] Please help complete the AST branch

Does anyone want to volunteer to integrate the current head to the branch? I think that's a pretty important near-term step. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http:/

Re: [Python-Dev] Let's get rid of unbound methods

On 4-jan-05, at 19:28, Guido van Rossum wrote: 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) It caught bugs for me a couple of times. If I remember correctly I was callin

[Python-Dev] 2.3.5 schedule, and something I'd like to get in

First question: what is the Python 2.3.5 release schedule and who is responsible? Second question: I thought this info was in a PEP somewhere, but I could only find PEPs on major releases, should I have found this info somewhere? And now the question that matters: there's some stuff I'd really

[Python-Dev] 2.3.5 schedule, and something I'd like to get in

First question: what is the Python 2.3.5 release schedule and who is responsible? Second question: I thought this info was in a PEP somewhere, but I could only find PEPs on major releases, should I have found this info somewhere? And now the question that matters: there's some stuff I'd really

Re: [Python-Dev] Let's get rid of unbound methods

On Jan 4, 2005, at 6:01 PM, Jack Jansen wrote: On 4-jan-05, at 19:28, Guido van Rossum wrote: 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) It caught bugs for me a couple

Re: [Python-Dev] 2.3.5 schedule, and something I'd like to get in

Jack Jansen wrote: First question: what is the Python 2.3.5 release schedule and who is responsible? Last I heard it is going to be released "in January", and Anthony Baxter is the release manager. Second question: I thought this info was in a PEP somewhere, but I could only find PEPs on major re

Re: [Python-Dev] 2.3.5 schedule, and something I'd like to get in

On Jan 4, 2005, at 6:54 PM, Martin v. Löwis wrote: Jack Jansen wrote: First question: what is the Python 2.3.5 release schedule and who is responsible? Last I heard it is going to be released "in January", and Anthony Baxter is the release manager. Second question: I thought this info was in a

Re: [Python-Dev] Please help complete the AST branch

Guido van Rossum <[EMAIL PROTECTED]> writes: > I'd be fine with keeping this on python-dev too. Maybe tag the Subject: with [AST] when starting a thread? -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/

Re: [Python-Dev] Let's get rid of unbound methods

Tim Peters <[EMAIL PROTECTED]> wrote: > Guido wrote: > > Let's get rid of unbound methods. When class C defines a method [snip] > Really? 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

[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 >

Re: [Python-Dev] Let's get rid of unbound methods

[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 check

Re: [Python-Dev] Let's get rid of unbound methods

On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote: Tim Peters <[EMAIL PROTECTED]> wrote: Guido wrote: Let's get rid of unbound methods. When class C defines a method [snip] Really? Unbound methods are used most often (IME) to call a base-class method from a subclass, like my_base.the_method(self, .

Re: [Python-Dev] Let's get rid of unbound methods

On Tue, 2005-01-04 at 18:01, Jack Jansen wrote: > But I'm more worried about losing the other information in an unbound > method, specifically im_class. I would guess that info is useful to > class browsers and such, or are there other ways to get at that? That would be my worry too. OTOH, we

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 qu

[Python-Dev] csv module TODO list

There's a bunch of jobs we (CSV module maintainers) have been putting off - attached is a list (in no particular order): * unicode support (this will probably uglify the code considerably). * 8 bit transparency (specifically, allow \0 characters in source string and as delimiters, etc). * Rea

[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 regi

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

Re: [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. It's very difficult