Walter Dörwald wrote:
> Greg Ewing wrote:
>> It would be less efficient in the cases where you don't
>> need to check for NULL and/or clear the reference
>> afterwards.
>
> Both should be optimized away by the compiler.
How? I don't see how the compiler can know either of
those things.
--
Greg
_
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Personally, I see Py3k as a vetting mechanism for all those hair-brained
> > ideas that really shouldn't make it into any Python version (3k or
> > otherwise), with the po
Greg Ewing wrote:
> Walter Dörwald wrote:
>> Greg Ewing wrote:
>>> It would be less efficient in the cases where you don't
>>> need to check for NULL and/or clear the reference
>>> afterwards.
>>
>> Both should be optimized away by the compiler.
>
> How? I don't see how the compiler can know eithe
At 07:20 PM 4/19/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
>>That is, it defines the function with MAKE_CLOSURE instead of
>>MAKE_FUNCTION. It also puts a reference to the cell object in the
>>class's dictionary, let's say under __cell__.
>
>Presumably it would first check if there
On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Here's how you solve the "how does super() get the current class" problem,
> using existing compiler and VM constructs, and without relying on class
> names, or on functions not being decorated, or anything like that. And
> it's so simple you
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> On the contrary, it's precisely when you *don't* know
> what classes are going be mixed in with you that super()
> is likely to go haywire. Your super() call ends up
> calling a method that you know nothing about, and
> the method being called isn
At 09:06 AM 4/19/2006 +0100, Guido van Rossum wrote:
>On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Here's how you solve the "how does super() get the current class" problem,
> > using existing compiler and VM constructs, and without relying on class
> > names, or on functions not being
Giovanni Bajo wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>> The use case for super() is where you have a chain of
>> methods that are sufficiently compatible that you don't
>> need to know or care which one you're calling next.
>> That's not usually the case with __init__ methods.
>
> It wo
Phillip J. Eby wrote:
> That is, it defines the function with MAKE_CLOSURE instead of
> MAKE_FUNCTION. It also puts a reference to the cell object in the class's
> dictionary, let's say under __cell__.
Presumably it would first check if there was already a __cell__
put there by another functio
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> The arguments against super() are> understandable -- if you only think about your own class, or completely> disregard MI. I think that's irresponsible: super() always calls the
> right baseclass method,On the contrary, it's pr
On 4/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:> Here's how you solve the "how does super() get the current class" problem,> using existing compiler and VM constructs, and without relying on class
> names, or on functions not being decor
Barry Warsaw wrote:
> On Mon, 2006-04-17 at 16:08 -0700, Brian Harring wrote:
>
>> The issue I'm seeing is that the wart you're pointing at is a general
>> issue not limited to strings- everyone sooner or later has flattening
>> code that hits the "recursively iterate over this container, except
On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Hmm, the reference to Dylan's next method (along with a few other comments in
> this thread) makes me believe a magic autosuper() equivalent would really need
> to be based on a thread-local context, rather than any kind of static code
> analysi
On 4/11/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> If the __signature__ is parsed from the first line, it puts it right
> below the function definition.
>
> def pattern_search(seq, pattern, start=0):
> """ fn(str, str, int) -> (str, int)
>
> Get a sub-string and index usin
Guido van Rossum wrote:
> Here's a related but more complicated wish: define a function in such
> a way that certain parameters *must* be passed as keywords, *without*
> using *args or **kwds. This may require a new syntactic crutch.
A single '*' could indicate that no additional positional argume
[I don't want to lose this message, but I don't have the time to read
it and do the complementary source research right now. So I'm
recommending you do some more research yourself.]
You're right that the API is very complex. However have you tried
stepping through some typical calls? There's a "fa
On 4/12/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> > I agree that such a test suite would be helpful. I don't think it
> > should wait for Python 3000.
>
> Possible plan:
>
> Add 'spec' or 'specification' or 'language', 'implementation',
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Py3k suggestion: make ... a generally legal expression.
Yup.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[email protected]
http://mail.python.org/
Steven Bethard wrote:
> -
> UserDict.DictMixin.update
> -
...
> To clean this up, we'd need the ability to identify self and dict as
> positional only arguments. AFAICT, the current proposal doesn't solve
> this problem. Off the top of my head, I d
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Here's a related but more complicated wish: define a function in such
>> a way that certain parameters *must* be passed as keywords, *without*
>> using *args or **kwds. This may require a new syntactic crutch.
>
> A single '*' could indicate that no
If you and/or Terry would post this that would be great -- I do have
plenty of net access here but my time is very fragmented. Once it's
posted I'll blog a link.
One comment: I would add explicitly to the subject that the PSF is
currently requesting mentors, not students. Perhaps
Subject: Pyth
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Even if it did become available, we might not want to
> use it. In recent times I've come round to the view that,
> on modern architectures where cacheing is all-important,
> refcounting + cyclic garbage collection may well be
> *better* than mark
On 4/19/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> Wild idea.
>
> When I was a newbie, I repeatedly make the mistake of writing
>
> alist = alist.sort()
>
> I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C).
> "UseForbidden" can be used only to return from a function. Any o
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andy Sy wrote:
>
> > I don't know about you, but with the addition of send() to deal with
> > the problem outlined in PEP 342, generators are starting to look more
> > and more like a Rube Goldberg contraption. Could anything be more
> > Pythonic
Guido van Rossum wrote:
> On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Hmm, the reference to Dylan's next method (along with a few other comments in
>> this thread) makes me believe a magic autosuper() equivalent would really
>> need
>> to be based on a thread-local context, rather than
Walter Dörwald wrote:
> The "checking for NULL" scenario looks somewhat like this:
>
> And the "clearing the reference" scenario should look ike this:
But only if the reference is a local to the function,
and it's used in a disciplined enough way, and the
compiler is smart enough. None of those
Phillip J. Eby wrote:
> No, the compiler does it, it's not an execution time thing. That is,
> the code object is set for a certain number of "cell vars", and that's
> what allocates the cell object when the code is executed and the frame
> is set up.
What I mean is, however it's done, all th
Guido van Rossum wrote:
> Regarding the syntax, IMO *if* we use this we should do it so that you can
> write
>
> super.foobar(args)
I was thinking of something like
__super__.foobar(self, args)
i.e. __super__ would just do the work of finding the appropriate
unbound method. This would
Guido van Rossum wrote:
> Um, you don't seem to be familiar with the theory of cooperative
> method calls I believe I cited the book from which I got this in some
> original writings regarding new-style classes (no time to look it up
> right now).
I'd be interested to see that when you do get tim
Nick Coghlan wrote:
> Hmm, the reference to Dylan's next method (along with a few other
> comments in this thread) makes me believe a magic autosuper() equivalent
> would really need to be based on a thread-local context, rather than any
> kind of static code analysis.
Why? I don't see what co
Greg Ewing wrote:
> Walter Dörwald wrote:
>
>> The "checking for NULL" scenario looks somewhat like this:
>>
>> And the "clearing the reference" scenario should look ike this:
>
> But only if the reference is a local to the function,
True Py_CLEAR(foo->bar->baz) probably won't be optimized.
>
On Tue, Apr 18, 2006 at 09:41:20PM -0400, Edward C. Jones wrote:
> Wild idea.
>
> When I was a newbie, I repeatedly make the mistake of writing
>
> alist = alist.sort()
>
> I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C).
> "UseForbidden" can be used only to return from a f
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:> Um, you don't seem to be familiar with the theory of cooperative> method calls I believe I cited the book from which I got this in some> original writings regarding new-style classes (no time to look it up
> right now).I'd b
> > Guido van Rossum wrote:
> > > Um, you don't seem to be familiar with the theory of cooperative
> > > method calls I believe I cited the book from which I got this in some
> > > original writings regarding new-style classes (no time to look it up
> > > right now).
> On 4/19/06, Greg Ewing <[EMA
Guido van Rossum wrote:
> Not that I disagree -- do you have specific data or reasoning to back
> this up? I'd love to hear that we were right all the time! :-)
No, I don't, sorry, it's just a hypothesis. But
I do like the way most Python garbage goes away
almost immediately, instead of hanging a
[Neal asked me to post this nitpick in case someone else posts the
announcement]
On 4/19/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> This spring and summer, Google corporation will again provide several
> hundred stipends for students (18+, undergraduate thru PhD programs)
> to write new open
On Wed, Apr 19, 2006, Guido van Rossum wrote:
>
> Regarding the syntax, IMO *if* we use this we should do it so that you
> can write
>
> super.foobar(args)
>
> where currently you'd write
>
> super(ClassName, self).foobar(args)
>
> 'super' could be a new keyword. In 3.0 we could just mak
On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
[Guido]
> >We could probably
> >introduce this in 2.6 if the super object, when called, would return
> >itself; then IMO no __future__ statement would be required since
> >existing code using super would continue to work.
>
> I assume you mean t
On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Here's a related but more complicated wish: define a function in such
> > a way that certain parameters *must* be passed as keywords, *without*
> > using *args or **kwds. This may require a new syntactic crutch.
>
> A
On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> A different idea from another part of the thread would be to allow a parameter
> list rather than an identifier after **:
>
>def f(**(paramA, paramB=10)):
>print paramA, paramB
Hm, -1. Without the explanation I would have *no* idea
On 4/19/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> I would like to see Python 3.0 before the turn of the next millennium. I
> suggest that Python 2.6 be devoted to implementing some of the backward
> compatible changes for Python 3.0. In particular, do the long-overdue
> reorganization of the
On 4/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Again, in my opinion, features should necessitate the Python 3.x release.
> Is the integer division change sufficient to necessitate 3.0 after 2.6?
> Goodness, I hope not.
It's the other way around. int/int alone isn't enough to trigger 3.0;
On 4/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> -1. Python 3k (non-alpha, beta, etc.) should come out when it's ready.
> No sooner.
Right.
> Personally, I see Py3k as a vetting mechanism for all those hair-brained
> ideas that really shouldn't make it into any Python version (3k or
> oth
On 4/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >Oh, I believe super() also supports static and/or class methods. I'm> >not sure how to handle this but I'm sure you can think of something.>> If super.foobar(args) -> super(ThisClass,firstarg).foobar(args), then it
> will Just Work(TM) for
On 4/19/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
[responding to some confusing text from me about super in a static method]
> That's not how it works (and that's good; refusing the temptation to guess,
> and what not :) super() cannot make any assumptions about the next class in
> the MRO, a
On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Then you'd have:
>
>def f(a, *(b, c=1, *args), **(d, e=2, **kwds)):
># Silly function
>
> 'a' would be a normal positional-or-keyword argument
> 'b' would be a required positional-only argument
Am I reading that correctly?
Looking
On Wed, 2006-04-19 at 20:17 +1000, Nick Coghlan wrote:
> Unfortunately, the thread fizzled without generating any additional interest.
> I don't recall the topic really coming up since then.
Maybe because the proposal got too complex while trying to be so
general?
-Barry
signature.asc
Descri
Guido van Rossum wrote:
> I wouldn't recommend this approach to anyone.
What about a variation ? It's arguably a 2.5a1 bug that yield expressions are
permitted in generator expressions, but this suggests a slight syntax
extension.
Suppose
wrapper( for after )
would mean what can in 2.5a1 b
Terry, if you can post this during the day, please go ahead and do so
and incorporate Guido's and Aahz's comments. If you don't have a
chance today, I will post it tonight when I get home which will almost
definitely be after 8pm PT/11pm ET.
Thanks,
n
--
On 4/19/06, Guido van Rossum <[EMAIL PROT
> Greg Ewing writes:
> > Personally I think that the use of diamond inheritance should be
> > severely discouraged, if not banned completely.
and Aahz replies:
> But multiple inheritance with new-style classes is inherently diamond
> inheritance -- how do you propose to deal with that?
Multiple i
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 4/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Personally, I see Py3k as a vetting mechanism for all those hair-brained
> > ideas that really shouldn't make it into any Python version (3k or
> > otherwise),
>
> Huh? Why should Py3k be rel
On 4/19/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I wouldn't recommend this approach to anyone.
>
> What about a variation ?
I haven't seen any convincing argument showing that this feature is
useful or that the code becomes more readable when this feature is
used
Greg Ewing wrote:
> There's a lot more to this than syntax. The oddities
> surrounding Python generators are mostly due to their
> "one-level-deep" nature, i.e. they're not full coroutines.
> And there are deep implementation reasons for that.
Does this mean that Py3K intends to reuse major porti
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> If syntax is all you're concerned about, you could translate
> that into Python as something like
>f = url(future(fetch))
Are you sure it wouldn't be
f = Future(fetch, url)
a bit like
result = ActiveObject(function, args)
> Now,
Guido van Rossum wrote:
> On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>Guido van Rossum wrote:
>>
>>>Here's a related but more complicated wish: define a function in such
>>>a way that certain parameters *must* be passed as keywords, *without*
>>>using *args or **kwds. This may require
On Thu, Apr 20, 2006, Andy Sy wrote:
> Greg Ewing wrote:
>>
>> There's a lot more to this than syntax. The oddities
>> surrounding Python generators are mostly due to their
>> "one-level-deep" nature, i.e. they're not full coroutines.
>> And there are deep implementation reasons for that.
>
> Doe
Andy Sy <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > There's a lot more to this than syntax. The oddities
> > surrounding Python generators are mostly due to their
> > "one-level-deep" nature, i.e. they're not full coroutines.
> > And there are deep implementation reasons for that.
>
> Does
On 4/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Here's a related but more complicated wish: define a function in such
> a way that certain parameters *must* be passed as keywords, *without*
> using *args or **kwds. This may require a new syntactic crutch.
I don't know if this counts as
[Greg Ewing]
>> Even if it [mark-sweepish gc] did become available, we might not
>> want to> use it. In recent times I've come round to the view that,
>> on modern architectures where cacheing is all-important,
>> refcounting + cyclic garbage collection may well be
>> *better* than mark-and-sweep o
Guido van Rossum wrote:
> On 4/19/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
>
>>Wild idea.
>>
>>When I was a newbie, I repeatedly make the mistake of writing
>>
>>alist = alist.sort()
>>
>>I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C).
>>"UseForbidden" can be used only
On Wed, Apr 19, 2006 at 03:07:50PM -0400, Tim Peters wrote:
> and it matters. I noted this in public in 1999, after Neal
> Schemenauer tried replacing all of Python's gc with BDW mark-sweep,
> and reported:
>
> I started with Sam Rushing's patch and modified it for Python
> 1.5.2c. To m
Tim> That thread should still be required reading for anyone thinking of
Tim> changing CPython's gc strategy:
Tim> http://mail.python.org/pipermail/python-list/1999-July/0073.html
I think its article number may have changed in the last few years. I found
what I think you referred
[Tim Peters]
...
>>That thread should still be required reading for anyone thinking of
>> changing CPython's gc strategy:
>>
>> http://mail.python.org/pipermail/python-list/1999-July/0073.html
[Brian Harring]
> Seem to have missed a few digits in the url...
>
> http://mail.python.org/pipermail
On 4/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ...
I'll be perfectly happy to leave the matter (and the mailing list) at
that - once said that your complete wording left an unfortunate doubt
: it maybe reflects my failure to adjust the subject of the thread to
a proposal and examples th
On 4/19/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> BTW, what about replacing the geeky and arguably lengthy keyword
> "lambda" with either :
>
> given- much clearer and slightly more concise; or
> ? - slightly clearer and much more concise ?
Guido's already said that lambda will st
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I once considered and rejected this syntax since another logical
> interpretation would be that any positional arguments are accepted but
> *ignored*.
I was about to suggest that perhaps this is how it should be int
On 4/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I once considered and rejected this syntax since another logical
> > interpretation would be that any positional arguments are accepted but
> > *ignored*.
>
>
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Py3k suggestion: make ... a generally legal expression.
>
> Yup.
An addition for PEP 3100 under core language.
___
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It seems you are right (I was paying attention, but apparently to the
> wrong stuff); after going through most of the py3k list history, those
> changes that would have been backwards compatible were basically
> reject
Terry Reedy wrote:
> Given that keyword only functions should be fairly rare (given that we have
> survived thus long without), is a syntactic abbreviation needed?
It's quite common to see documentation warn API users only to call a
function with keyword arguments, so there's definitely a desire
It seems that python-3000 is more about language issues than CPython
issues. Still, I'll ask the question just to nip it in the bud early:
Any possibility of working on the CPython GIL and MP problems in python-3000?
The reason I ask is because most solutions might involve
incompatibilities with
[forgot to cc: python-3000; sorry for the dup, Terry]
On 4/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> >> Py3k suggestion: make ... a generally legal expre
On 4/19/06, Luis P Caamano <[EMAIL PROTECTED]> wrote:
> It seems that python-3000 is more about language issues than CPython
> issues. Still, I'll ask the question just to nip it in the bud early:
>
> Any possibility of working on the CPython GIL and MP problems in python-3000?
>
> The reason I as
"Aahz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [Neal asked me to post this nitpick in case someone else posts the
> announcement]
Thank you. Really.
> Either s/between/from/ or s/through/and/
Yes. Late night continuity disconnect.
> Python: because we care about langu
Brett Cannon wrote:
> I just know this is going to fall under Guido's "code first, then we
> consider" rule. The GIL is not currently going to go anywhere without
> a thorough rearchitecture of the interpreter and that is not planned
> for Python 3000. Plus most people here, based on the last tim
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> One comment: I would add explicitly to the subject that the PSF is
> currently requesting mentors, not students. Perhaps
>
> Subject: Python Software Foundation looking for mentors for the
> Google Summer of Code
>
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry, if you can post this during the day, please go ahead and do so
> and incorporate Guido's and Aahz's comments.
My revision is both pasted below and attached as a text file. I am not
posting because I prefer you
"Ian Bicking" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I don't know if there's an advantage to presenting a signature that
> accurately describes the function; it can never *really* be accurate in
> all cases, as there can be all sorts of constraints that are impossible
> to
It would be interesting to bring ILU up-to-date. Get the ILU C
library compiling nicely on POSIX (should be trivial), then bring the
Python bindings up-to-date. That would, once again, give us ONC RPC
and CORBA compatibility, both IPC and RPC.
Bill
> Brett Cannon wrote:
> > I just know this is
On 4/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I recommend profiling. I seem to recall that last time we did this, we
> found that creating the frame object is a significant cost factor.
That's part of it. Plus there's a tuple allocation (and copy).
n
___
I decided to take some of the ideas discussed in the string formatting
thread, add a few touches of my own, and write up a PEP.
http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt
(I've also submitted the PEP via the normal channels.)
I don't have a prototype, however the PEP is expli
[major contextectomy of a python-dev post -- despite the header, this is
now the python-3000 list, not python-dev]
On Thu, Apr 20, 2006, Anthony Baxter wrote:
>
> urllib->urllib2
That reminds me. Anyone want to write a PEP for merging urllib2 into
urllib for Python 3.0? More precisely, we shoul
Josiah Carlson wrote:
> Andy Sy <[EMAIL PROTECTED]> wrote:
>> Does this mean that Py3K intends to reuse major portions of
>> Python 2.x's implementation?
>
> Aahz just answered this.
> From the discussion I've been paying attention to over the last few
> years, *some* parts of Py3k will be backwa
83 matches
Mail list logo
