We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement. We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCod
Guido van Rossum wrote:
> On 4/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> A question for Guido: Is this flexibility for argument passing only, or does
>> it apply to parameter declarations as well?
>
> [Nick, could you trim your posts a bit? I'm on a trip with very short
> intervals of net
Talin wrote:
> And on the calling side:
>
>def func2( adama, valeri, thrace ):
> ...
>
>func2( valeri='cylon', 'human', 'human' )
>
> In this case, however, I don't see why we can't have the keyword
> arguments out of order. In the above example, the 'valeri' parameter
> gets filled
On Apr 16, 2006, at 4:40 PM, Guido van Rossum wrote:
> On 4/16/06, Kendall Clark <[EMAIL PROTECTED]> wrote:
>> A perfectly reasonable suggestion. I like this better than writing a
>> PEP. Alas, that doesn't mean I have time to do it, which sucks. I
>> guess I shouldn't have proposed a feature for
> What I would like to be able to write is:
>
>def function( *args, option=False ):
> ...
(...)
For the same reasons, being able to do the equivalent when calling
any given function would be nice as well. e.g.
function(first, second, *args, something=True)
If something like this is
[Talin]
> 1) I don't know if this is already on the table, but I sure would like
> to be able to have more options as far as mixing positional and
> keyword arguments.
I thought it might be useful to look at a few places where we
currently have to do some hackery to get the function signature we
w
On 4/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The rest of it was just suggesting that permitting keyword
> parameters/arguments after *args should be the *only* change we make in this
> area. I don't see any point in permitting positional arguments to come after a
> keyword argument, even a
"Talin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The important thing is that the behavior be clear and unambiguous,
> which I think this is.
Many would also prefer that functions calls not become noticeable slower
than they already are.
tjr
_
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The PSF (you) needs to create a page (in the wiki is fine) with
> instructions for mentors, and make sure that is linked to from the
> code.google.com/soc/ page as "(ideas)" after our name, just like the
> Perl found
On 4/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> The PyPy group also has a few prospective mentors, projects, and mentees.
> On the presumption that PSF coordinating sponsership is not limited to
> CPython only projects, I forwarded Neal's SoC py-dev post to their list.
Excellent. I was thi
One thing I forgot to mention. There will likely be people we don't
know who offer to be mentors. It's great to get new people involved.
Though we need to ensure they can handle the job.
Guido suggested and I think it's a good idea to have any unknown
person (*) to get 2 references that are kno
On 4/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Talin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > The important thing is that the behavior be clear and unambiguous,
> > which I think this is.
>
> Many would also prefer that functions calls not become noticeable slower
Guido van Rossum wrote:
> On 4/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> The rest of it was just suggesting that permitting keyword
>> parameters/arguments after *args should be the *only* change we make in this
>> area. I don't see any point in permitting positional arguments to come after
> Unless you have a concrete solution (short of allowing '=' in
> expressions :-) there's no solution and you're wasting everybody's
> time for explaining how useful it would be.
If we had symbols, we could write something like
if assign('x, some_expression):
print x
Presumably a refe
Aahz wrote:
>On Sun, Apr 16, 2006, Tim Peters wrote:
>
>
>>Now that I think of it, though, I've been burned perhaps twice in my
>>total Python life by recursing on a string when I didn't intend to.
>>Apart from flatten()-ish functions, I'm not sure I've written anything
>>vulnerable to that.
>>
On 4/17/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> How slow *are* function calls? There seems to be a common "function
> calls in Python are slow" meme. It's never been a significant issue
> for me, but my code is pretty much always IO-bound, so that doesn't
> surprise me. Are they slow enough to
Raymond Hettinger wrote:
> -1 on making strings non-iterable. The cure is worse than the disease.
> In ML, characters and strings are different datatypes and it is a
> complete PITA. I suspect that making strings non-iterable would make
> the language more difficult to use rather than simpler
On 4/17/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> BTW, do we want to allow foo(1, *args1, 2, *args2, 3)?
>
> And what about foo(bar=17, **kwargs1, baz=23, **kwargs2)?
There's probably not much use for those but at least the first isn't
ambiguous so could be allowed if it doesn't complicate t
On 4/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> The proposal wasn't to remove iterability in general, only to require
> the use of an explicit method when iterating over strings. It's not a
> huge change by any means; a speed bump for a small number of people,
> perhaps, but no real functiona
On Mon, Apr 17, 2006 at 05:40:19PM -0500, Ian Bicking wrote:
> Raymond Hettinger wrote:
> > -1 on making strings non-iterable. The cure is worse than the disease.
> > I'm also -1 on almost all proposals of this kind. IMHO, the first cut
> > of Py3000 should be directed at subtracting the cruf
Guido van Rossum wrote:
> Inlining code obviously addresses this, but that's often killing code
> structure.
unless you can get the compiler to do it for you.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listin
[Brian Harring]
> 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 for instances of these classes".
Good recap. For more info,
In an old thread ("dictionary tuning", 2003[1]) Raymond H laid out the
typical use cases of dicts and found there were many subclasses of
"typical" and speeding one up hurt the others. The results are in
dist/Object/dictnotes.txt A couple of the particular use cases have
since been satisfied by
Michael P. Soulier wrote:
> Although you do have to put the current class name in the method calls, as
> super() requires it as the first argument. I never understood that. Why would
> I wish to use super(Bar) if I'm in class Foo? Cannot Foo be implied here?
The problem is that there's no way for
Aahz wrote:
> Remember that in its current form super() is a regular function; it
> cannot be implied without stack hackery.
I'm not sure it's all that easy even with stack hackery.
Remember that you want the class that the def statement
of the method was written inside, not the class of
self.
-
Tim Peters wrote:
> I expect it depends on whether someone writes text-processing
> algorithms. If you do, it's quite natural to iterate over strings.
Personally I never find it natural to iterate over strings,
because it makes me think "this is going to be horrendously
inefficient", and I go lo
Guido van Rossum wrote:
> On 4/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>The proposal wasn't to remove iterability in general, only to require
>>the use of an explicit method when iterating over strings. It's not a
>>huge change by any means; a speed bump for a small number of people,
>>p
Greg Ewing wrote:
> Aahz wrote:
>>Remember that in its current form super() is a regular function; it
>>cannot be implied without stack hackery.
>
>
> I'm not sure it's all that easy even with stack hackery.
> Remember that you want the class that the def statement
> of the method was written ins
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.
Perhaps:
def func(x, *args=(), foo=1): ...
Well, that doesn
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 worked fine for me when I forced my
Bill Janssen wrote:
> Presumably a reference to a Python symbol would be not just the symbol
> name string, but also an indicator of the namespace of the symbol.
That would be something very new -- nothing like that was
implied by the original suggestion, and no other language
I know of that has
Guido van Rossum wrote:
> Inlining
> code obviously addresses this, but that's often killing code
> structure.
Would automated inlining be a legitimate use for ast-hacking?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.
On Mon, Apr 17, 2006, Ian Bicking wrote:
>
> Polymorphism between things that aren't similar is bad; in another
> context it is called implicit coersion, like '1'+2=='12'. That's
> what string iteration looks like to me -- strings aren't sequences of
> strings. It can be convenient to treat them
Ian Bicking wrote:
> So I don't think
> there's any parallel to ML or other languages with character types.
If you're after parallels, there's BASIC, which also
didn't have a character type, and didn't try to pretend
that strings were arrays of anything. The equivalent
of s[i] would be mid$(s, i,
Guido van Rossum wrote:
> If we did end up allowing multiple **kwds, the code implementing calls
> should check that they don't overlap with each other or with other
> keyword args or with named positional args,
An alternative might be to add a + operator to dicts
which disallowed overlaps. That
Talin wrote:
> In this case, however, I don't see why we can't have the keyword
> arguments out of order.
But what's the *benefit* of being allowed to write that?
> The important thing is that the behavior be clear and unambiguous,
> which I think this is.
It might be unambiguous, but I disagre
I imagine most of the people on this list have seen it already, but if
not, I wanted to point out Logix:
http://www.livelogix.net/logix/
It's an interesting (working) experiment in building a Python with some
very serious twists. In the context of this list, it might serve as a
springboard for G
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 4/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>
>> The PyPy group also has a few prospective mentors, projects, and
>> mentees.
>> On the presumption that PSF coordinating sponsership is not limited to
>> CPython
On Mon, 2006-04-17 at 14:01 -0700, Raymond Hettinger wrote:
> -1 on making strings non-iterable. The cure is worse than the disease.
> In ML, characters and strings are different datatypes and it is a
> complete PITA. I suspect that making strings non-iterable would make
> the language more
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
> for instances of these
Barry Warsaw wrote:
> I wouldn't want to generalize this, but it is not infrequent that
> people mistakenly iterate over strings when they want to treat them
> atomically. difflib not withstanding, and keeping Guido's
> pronouncement in mind, I do think people want to treat strings
> atomically mu
On 4/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> Your next post answered my question as to mentor eligibility: known of by
> you or two references therefrom. But back to project eligibility: how far
> beyond direct implementation-related projects? How about progammer support
> like pylint/p
Paul Moore gmail.com> writes:
>
> On 4/17/06, Terry Reedy udel.edu> wrote:
> >
> > "Talin" acm.org> wrote in message
> > news:loom.20060417T072709-664 post.gmane.org...
> > > The important thing is that the behavior be clear and unambiguous,
> > > which I think this is.
> >
> > Many would als
Greg Ewing canterbury.ac.nz> writes:
> Talin wrote:
>
> > In this case, however, I don't see why we can't have the keyword
> > arguments out of order.
>
> But what's the *benefit* of being allowed to write that?
>
> > The important thing is that the behavior be clear and unambiguous,
> > which
> I am curious about last year's results for PSF projects: how many of how> many actually finished enough to collect the full stipend? Is there a
> report that I never saw?Here's a write up about last year's projects:http://wiki.python.org/moin/SummerOfCode/2005Payment was all or nothing. I thou
45 matches
Mail list logo
