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
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
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
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
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
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,
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
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
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
[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
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
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
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
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
[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
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
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
[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
18 matches
Mail list logo
