Jim Jewett wrote:
(2) A function as a parameter isn't good enough, because the
passed-in function can't see bindings in the surrounding larger
function. (It still sees the lexical scope it which it was defined.)
That sounds confused, because the lexical scope it which
it was defined is exactly
On Thu, 17 Mar 2005 14:34:23 +1300, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Not to mention that if the seq is empty, there's no
> way of knowing what T to instantiate...
You just use the same T as inferred for seq : sequence[T] .
Michael
___
Python-Dev
On Wed, 16 Mar 2005 08:28:22 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > > Thinking ahead to generic types, I'd like the full signature to be:
> > >
> > > def sum(seq: sequence[T], initial: T = 0) -> T.
> >
> > Would this _syntax_ work with generic types:
> >
> > def sum(seq: sequenc
John Williams wrote:
Michael Walter wrote:
Would this _syntax_ work with generic types:
def sum(seq: sequence[T], initial: T = T()) -> T.
This doesn't make sense with existing semantics because default
arguments are evaluated when the function is defined, but T() can't be
evaluated until the fu
Tim Peters wrote:
I can't say it bothers me to specify an appropriate identity element
when 0 is inappropriate.
Maybe instead of a single sum() function, each summable
type should have a sum() static method which uses an
identity appropriate to that type.
So to sum a list of integers you would use
Samuele Pedroni wrote:
well, I think some people desire a more streamlined way of writing code
like:
def f(...)
...
def g(...)
...
x = h(...,f,g)
Using the recently-proposed 'where' facility, this could
be written
x = h(..., f, g) where:
def f(...):
...
def g(...):
Jim Jewett wrote:
It may be time to PEP (or re-PEP), if only to clarify what people are
actually asking for.
I will PEPify this, unless someone does not think I am the correct person
to do so. The PEP is probably a better place to try to address questions
you raise, as well as give the rationale
On a platform I won't mention here I'm running into problems compiling
Python, because of it defining _POSIX_C_SOURCE.
It turns out that on this platform the definition causes all sorts of
declarations in sys/types.h to be skipped (presumably because they're
not official Posix identifiers), whi
> [Gregory P. Smith]
> > or make it even uglier to hide from pychecker by writing that as:
> >
> > exec("""
> > try:
> > set
> > except NameError:
> > from sets import Set as set
> > """)
>
> I presume that was somewhat tongue-in-cheek, but if it wasn't, please
> reconsider. Modulefinder
[Jack Jansen]
> On a platform I won't mention here I'm running into problems compiling
> Python, because of it defining _POSIX_C_SOURCE.
...
> Does anyone know what the real meaning of this define is?
LOL. Here's the Official Story:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_cha
[Bob Ippolito]
try:
set
except NameError:
from sets import Set as set
You don't need the rest.
[Skip Montanaro]
>>> Sure, but then pychecker bitches about a statement that appears to
>>> have no effect. ;-)
[Bob Ippolito]
>> Well then fix PyChecker to look
On Fri, Mar 11, 2005 at 06:47:11PM -0500, Bob Ippolito wrote:
>
> On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote:
>
> >
> >Bob> try:
> >Bob> set
> >Bob> except NameError:
> >Bob> from sets import Set as set
> >
> >Bob> You don't need the rest.
> >
> >Sure, but the
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> >>Josiah Carlson wrote:
> >>
> >>
> >>>Since PEP 310 was already mentioned, can we just say that the discussion
> >>>can be boiled down to different ways of spelling __enter__/__exit
Michael Walter wrote:
On Tue, 15 Mar 2005 07:47:20 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
But I'm not so sure now. Thinking ahead to generic types, I'd like the
full signature to be:
def sum(seq: sequence[T], initial: T = 0) -> T.
Would this _syntax_ work with generic types:
def sum
> > Thinking ahead to generic types, I'd like the full signature to be:
> >
> > def sum(seq: sequence[T], initial: T = 0) -> T.
>
> Would this _syntax_ work with generic types:
>
> def sum(seq: sequence[T], initial: T = T()) -> T.
Maybe, but it would preclude union types; continuing with the
> I guess that leaves Alex's question of whether or not supplying a string of
> some
> description as the initial value can be legitimately translated to:
>
>if isinstance(initial, basestring):
> return initial + type(initial)().join(seq)
If you're trying to get people in the habit of w
> >>Lambda will be more difficult. Eric Raymond adapted an anti-gun control
> >>slogan and said "you can pry lambda out of my cold dead hands." A bunch
> >>of folks will sorely miss the ability to create anonymous functions on
> >>the fly. When lambda is used for deferred argument evaluation (a
On Tue, 15 Mar 2005 07:47:20 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> But I'm not so sure now. Thinking ahead to generic types, I'd like the
> full signature to be:
>
> def sum(seq: sequence[T], initial: T = 0) -> T.
Would this _syntax_ work with generic types:
def sum(seq: seque
On Mar 16, 2005, at 8:37 AM, Nick Coghlan wrote:
Bob Ippolito wrote:
On Mar 16, 2005, at 6:19, Raymond Hettinger wrote:
Some folks on comp.lang.python have been pushing for itertools to
include a flatten() operation. Unless you guys have some thoughts on
the subject, I'm inclined to accept the req
On Thursday 17 March 2005 00:28, Anthony Baxter wrote:
> The release24-maint branch should be considered FROZEN as at UTC
> on 2005-03-18
That should of course be 2005-03-17.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
__
The release24-maint branch should be considered FROZEN as at UTC
on 2005-03-18 - in other words, in about 11 hours time. Allegedly this is
around 1900 on the 17th for the US East Coast. I'll post again once it's
unfrozen. From here, we'll be aiming at a 2.4.1 final for the 29th - straight
af
Bob Ippolito wrote:
On Mar 16, 2005, at 6:19, Raymond Hettinger wrote:
Some folks on comp.lang.python have been pushing for itertools to
include a flatten() operation. Unless you guys have some thoughts on
the subject, I'm inclined to accept the request.
Rather than calling it flatten(), it would
Guido van Rossum wrote:
2. How would the initial value that forms the basis of summation be built for
non-empty sequences?
Here's you're way off. There's never any use of "+=", so never any
need to create a new object. The algorithm I had in mind was:
- if empty, return 2nd arg
- if one item, retu
On Mar 16, 2005, at 6:19, Raymond Hettinger wrote:
Some folks on comp.lang.python have been pushing for itertools to
include a flatten() operation. Unless you guys have some thoughts on
the subject, I'm inclined to accept the request.
Rather than calling it flatten(), it would be called "walk" and
Josiah Carlson wrote:
Greg Ewing <[EMAIL PROTECTED]> wrote:
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
w
Phillip J. Eby wrote:
At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
Does deciding whether or not to supply the function really need to be
dependent on whether or not a format for __signature__ has been chosen?
Um, no. Why would you think that?
Pronoun confusion. I interpreted an 'it' in your mes
Some folks on comp.lang.python have been pushing for itertools to
include a flatten() operation. Unless you guys have some thoughts on
the subject, I'm inclined to accept the request.
Rather than calling it flatten(), it would be called "walk" and provide
a generalized capability to descend throu
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Since PEP 310 was already mentioned, can we just say that the discussion
> > can be boiled down to different ways of spelling __enter__/__exit__ from
> > PEP 310?
>
> It's not quite the same thing. PEP 310 suggests a mechanis
28 matches
Mail list logo
