On Jan 5, 2005, at 6:36 PM, Guido van Rossum wrote:
The idea of calling both __init__ methods doesn't work if there's a
diamond; if there *is* a diamond (or could be one), using super() is
the only sane solution.
Very true.
So then don't use it. You couldn't have diamonds at all before 2.2.
With *c
[Ilya Sandler]
> A problem:
>
> The current struct.unpack api works well for unpacking C-structures
where
> everything is usually unpacked at once, but it
> becomes inconvenient when unpacking binary files where things
> often have to be unpacked field by field. Then one has to keep track
> of of
On Jan 5, 2005, at 18:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don't get
A problem:
The current struct.unpack api works well for unpacking C-structures where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to be unpacked field by field. Then one has to keep track
of offsets, slice the strings,cal
>>I'm still trying to understand what *needs* to be done - I would move to
>>how this is done only later. What APIs should be extended/changed, and
>>in what way?
[...]
>The reader interface currently returns a row at a time, consuming as many
>lines from the supplied iterable (with the most common
Can you please elaborate on that? What needs to be done, and how is
that going to be done? It might be possible to avoid considerable
uglification.
>>
>> I'm not altogether sure there. The parsing state machine is all written in
>> C, and deals with signed chars - I expect we'll need t
Jack Jansen wrote:
But I do care:-) Specifically because I trust the crowd here to come up
with good ideas (even if they're not Mac users:-).
Thanks a lot.
The "new" solution is basically to go back to the Unix way of building
an extension: link it against nothing and sort things out at runtime
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don't get the part why "-undefined dynamic_lookup"
is a good
On Wed, 5 Jan 2005 18:00:38 -0500, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2005, at 1:23 PM, Guido van Rossum wrote:
> >> The issue of mixing super() and explicit calls to the superclass's
> >> method occur with any method. (Thus making it difficult/impossible for
> >> a framework to
[Grmpf. I should check which account I use before pressing send. Here
goes again]
On 5-jan-05, at 1:08, Bob Ippolito wrote:
The problem we're trying to solve is that due to the way Apple's
framework architecture works newer versions of frameworks are
preferred (at link time, and sometimes ev
On Jan 5, 2005, at 17:38, Martin v. Löwis wrote:
Bob Ippolito wrote:
Nope. The only way to link to a non-current framework version is to
forego any linker searching and specify the dyld file directly, i.e.
/Library/Frameworks/Python.framework/Versions/2.3/Python. The gcc
toolchain does not
On Jan 5, 2005, at 1:23 PM, Guido van Rossum wrote:
The issue of mixing super() and explicit calls to the superclass's
method occur with any method. (Thus making it difficult/impossible for
a framework to convert to using super without breaking client code
that
subclasses).
Well, client classes wh
Hi Phillip,
On Wed, Jan 05, 2005 at 01:03:42PM -0500, Phillip J. Eby wrote:
> >Is there any other use case for 'C.x' not returning the same as
> >'appropriate_super_class_of_C.__dict__["x"]' ?
>
> Er, classmethod would be one; a rather important one at that.
Oups. Right, sorry.
Armin
Bob Ippolito wrote:
Nope. The only way to link to a non-current framework version is to
forego any linker searching and specify the dyld file directly, i.e.
/Library/Frameworks/Python.framework/Versions/2.3/Python. The gcc
toolchain does not in any way whatsoever understand versioned
framewor
Michael Hudson wrote:
Martin, can you please believe that Jack, Bob, Ronald et al know what
they are talking about here?
I find that really hard to believe, because it contradicts to what I
think Apple wants me to believe. I'm willing to follow a series of
statements that I can confirm to be facts
On Jan 5, 2005, at 16:58, Martin v. Löwis wrote:
Ronald Oussoren wrote:
It gets worse when you have a user-installed python 2.3 and a
user-installed python 2.4. Those will be both be installed as
/Library/Frameworks/Python.framework.
Yes, but one is installed in Versions/2.3, and the other in
Ver
Andrew McNamara wrote:
Can you please elaborate on that? What needs to be done, and how is
that going to be done? It might be possible to avoid considerable
uglification.
I'm not altogether sure there. The parsing state machine is all written in
C, and deals with signed chars - I expect we'll need
Ronald Oussoren wrote:
It gets worse when you have a user-installed python 2.3 and a
user-installed python 2.4. Those will be both be installed as
/Library/Frameworks/Python.framework.
Yes, but one is installed in Versions/2.3, and the other in
Versions/2.4.
This means that you cannot use the
-
On Jan 5, 2005, at 16:15, Martin v. Löwis wrote:
Bob Ippolito wrote:
Then you haven't done the appropriate research by searching
pythonmac-sig.
Hmm.
> Do you even own a Mac?
Do I have to, in order to understand the issues?
But to answer your question: yes, I do.
Well, this issue has been discussed
Jeremy Hylton <[EMAIL PROTECTED]> writes:
>> 29 conflicts
>
> Oh. That's not as bad as I expected.
Proceeding
>> Major conflict:
>> Python/compile.c(Probably not merged during 1st merge)
>
> I think that's right. I didn't merge any of the changes, then.
>
>> Lib/test/test_c
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.8&only_with_tag=ast-branch&view=auto
>
> Clicking on the above gave me:
>
> (502) Bad Gateway
> The proxy server received an i
Bob Ippolito wrote:
Then you haven't done the appropriate research by searching
pythonmac-sig.
Hmm.
> Do you even own a Mac?
Do I have to, in order to understand the issues?
But to answer your question: yes, I do.
Regards,
Martin
___
Python-Dev mailing
On Wed, 05 Jan 2005 13:20:51 -0500, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton <[EMAIL PROTECTED]> writes:
>
> > Does anyone want to volunteer to integrate the current head to the
> > branch? I think that's a pretty important near-term step.
>
> I'll take a shot at it.
Great! I
On Wed, 5 Jan 2005 13:28:11 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Would it be helpful for me to move the peepholer out of compile.c into a
> separate source file?
It doesn't really matter. There are two reasons. 1) We've been
working on the new compiler code in newcompile.c, rath
Quite a while ago I posted some material to the csv-list about
problems using the csv module on Unix-style colon-separated files --
it just doesn't deal properly with backslash escaping and is quite
useless for this kind of file. I seem to recall the general view was
that it wasn't intended for thi
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> The existing ast-branch mostly works, but it does not include most of
> the new features of Python 2.4. There is a substantial integration
> effort, perhaps easy for someone who does a lot of CVS branch merges.
> (In particular, the head has already be
Would it be helpful for me to move the peepholer out of compile.c into a
separate source file?
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
> I think it would be easier to create a new branch from the current
> head, integrate the small number of changed files from ast-branch, and
> work with that branch instead. The idea is that it's an end-run
> around doing an automatic CVS merge and relying on someone to manually
> merge the chang
> The issue of mixing super() and explicit calls to the superclass's
> method occur with any method. (Thus making it difficult/impossible for
> a framework to convert to using super without breaking client code that
> subclasses).
Well, client classes which are leaves of the class tree can still
s
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> Does anyone want to volunteer to integrate the current head to the
> branch? I think that's a pretty important near-term step.
I'll take a shot at it.
I see the following:
2216 changes:
1428 modifications w/o confict
399 adds
360 removes
29 conflict
> Um, isn't all this stuff going to be more complicated and spread out over
> more of the code than just leaving unbound methods in place?
Well, in an early version of Python it was as simple as I'd like ot to
be again: the instancemethod type was only used for bound methods
(hence the name) and C
At 12:29 PM 1/5/05 -0500, Barry Warsaw wrote:
On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote:
> I think it would be reasonable to assign im_class only to functions
> defined in class scope. The only serialization that would break in that
> case is if your example had a 'del f' at the end.
+1.
"Jeremy Hylton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The file Python/compile.txt on the ast-branch has a brief overview of
> the project:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.8&only_with_tag=ast-branch&view=auto
At 04:30 PM 1/5/05 +, Armin Rigo wrote:
Hi Guido,
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> Let's get rid of unbound methods.
Is there any other use case for 'C.x' not returning the same as
'appropriate_super_class_of_C.__dict__["x"]' ?
Er, classmethod would be one; a
Armin Rigo wrote:
Hi Jim,
On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote:
Actually, unbound builtin methods are a different type than bound
builtin methods:
Of course, but conceptually they are similar. You would still
encounter the concept if you got an unbound builtin method.
There
Skip Montanaro wrote:
> 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 a
> duck typing?
That's the Australian pronunciation of "duct taping".
___
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-arc
On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote:
> I think it would be reasonable to assign im_class only to functions
> defined in class scope. The only serialization that would break in that
> case is if your example had a 'del f' at the end.
+1. If you're doing something funkier, then you
On Wed, 2005-01-05 at 10:37, Glyph Lefkowitz wrote:
> One approach I have taken in order to avoid copiously over-documenting
> every super() using class is to decouple different phases of
> initialization by making __init__ as simple as possible (setting a few
> attributes, resisting the temptatio
I'm not sure why super got dragged into this, but...
On Jan 4, 2005, at 9:02 PM, Guido van Rossum wrote:
I think that James Y Knight's page misrepresents the issue. Quoting:
But __init__ *is* special, in that it is okay for a subclass __init__
(or __new__) to have a different signature than the ba
The existing ast-branch mostly works, but it does not include most of
the new features of Python 2.4. There is a substantial integration
effort, perhaps easy for someone who does a lot of CVS branch merges.
(In particular, the head has already been merged to this branch once.)
I think it would b
Alex Martelli wrote:
def f(*a): pass class C(object): pass class D(object): pass C.f = D.f
= f
If now we want C.f.im_class to differ from D.f.im_class then we need
f to get copied implicitly when it's assigned to C.f (or, of course,
when C.f is accessed... but THAT might be substantial overhead).
On Thu, 6 Jan 2005 01:32:44 +0900, Jiwon Seo <[EMAIL PROTECTED]> wrote:
> I'd like to help here on the AST branch, if it's not too late.
> (Especially I'm interested with the generator expression part.)
Great! It's not too late.
> If I want to volunteer, do I just begin to work with it? Or do I
Hi Guido,
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> Let's get rid of unbound methods.
Is there any other use case for 'C.x' not returning the same as
'appropriate_super_class_of_C.__dict__["x"]' ? I guess it's too late now but
it would have been nice if user-defined __g
I'd like to help here on the AST branch, if it's not too late.
(Especially I'm interested with the generator expression part.)
If I want to volunteer, do I just begin to work with it? Or do I need
to read something or discuss with someone?
Thanks.
Jiwon.
On Mon, 3 Jan 2005 23:03:33 -0500, Jerem
Hi Jim,
On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote:
> >Actually, unbound builtin methods are a different type than bound
> >builtin methods:
>
> Of course, but conceptually they are similar. You would still
> encounter the concept if you got an unbound builtin method.
There are
On Wed, 2005-01-05 at 12:11 +0100, Alex Martelli wrote:
> Hmmm, seems to me we'd need copies of the function object for this
> purpose:
For the stated use-case of serialization, only one copy would be
necessary, and besides - even *I* don't use idioms as weird as the one
you are suggesting very
On Tue, 2005-01-04 at 22:12 -0500, Bob Ippolito wrote:
> If you have a class hierarchy where this is a problem, it's probably
> pretty fragile to begin with, and you should think about making it
> simpler.
I agree with James's rant almost entirely, but I like super() anyway. I
think it is an in
On Jan 5, 2005, at 3:33 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when buildin
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Bob Ippolito wrote:
>> It doesn't for reasons I care not to explain in depth, again.
>> Search the pythonmac-sig archives for longer explanations. The
>> gist is that you specifically do not want to link directly to the
>> framework at all when b
On 2005 Jan 05, at 12:40, Ronald Oussoren wrote:
...
The Tiger that was released at WWDC included a patched version of
Python 2.3.3. See:
http://www.opensource.apple.com/darwinsource/WWDC2004/.
Thanks! So, since WWDC was on June 28 and 2.3.4 had been released on
May 27, we get some first sen
>Quite a while ago I posted some material to the csv-list about
>problems using the csv module on Unix-style colon-separated files --
>it just doesn't deal properly with backslash escaping and is quite
>useless for this kind of file. I seem to recall the general view was
>that it wasn't intended fo
On 2005 Jan 04, at 22:11, Brett C. wrote:
...
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 guess
it's just my usual CVS-clumsiness and I'll soon find out what I'm
doing wrong & fix it)
See
http://www.python
On 5-jan-05, at 12:28, Alex Martelli wrote:
On 2005 Jan 05, at 00:06, Jack Jansen wrote:
...
We've solved this issue for the trunk and we can solve it for 2.4.1:
if MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it
to 10.3. Moreover, when it is 10.3 or higher (possibly after bei
On 2005 Jan 05, at 00:06, Jack Jansen wrote:
...
We've solved this issue for the trunk and we can solve it for 2.4.1:
if MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to
10.3. Moreover, when it is 10.3 or higher (possibly after being
forced) we use the dynamic_lookup way of
On 2005 Jan 05, at 04:42, Barry Warsaw wrote:
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?
Th
>Also, review comments from Neal Norwitz, 22 Mar 2003 (some of these should
>already have been addressed):
I should apologise to Neal here for not replying to him at the time.
Okay, going though the issues Neal raised...
>* remove TODO comment at top of file--it's empty
Was fixed.
>* is CSV go
>> Yep, although that means we wear the cost of decoding and encoding for
>> all 8 bit input.
>
>Right, but it makes the code very clean and straight forward.
I agree it makes for a very clean solution, and 99% of the time I'd
chose that option.
>Again, it depends on what you need. If performance
Andrew McNamara wrote:
Yes, although it would be nice to also retain the 8-bit versions as well.
You can do so by using latin-1 as default encoding. Works great !
Yep, although that means we wear the cost of decoding and encoding for
all 8 bit input.
Right, but it makes the code very clean and stra
>> Yes, although it would be nice to also retain the 8-bit versions as well.
>
>You can do so by using latin-1 as default encoding. Works great !
Yep, although that means we wear the cost of decoding and encoding for
all 8 bit input.
What does the _sre.c code do?
>Depends on your needs: CSV file
Andrew McNamara wrote:
Andrew McNamara wrote:
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).
Martin v. Löwis wrote:
Can you please elaborate on that? What
>> Andrew McNamara wrote:
>>> 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).
>>
>Martin v. Löwis wrote:
>> Can you please elaborate on that? What n
On 5-jan-05, at 9:33, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when building exte
Martin v. Löwis wrote:
Andrew McNamara wrote:
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).
Can you please elaborate on that? What needs to be done, and h
Andrew McNamara wrote:
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).
Can you please elaborate on that? What needs to be done, and how is
that going to be
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is that
you specifically do not want to link directly to the framework at all
when building extensions.
Because an Apple-built extension then
66 matches
Mail list logo
