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
with a
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
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
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
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
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,
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
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
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.
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
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:
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 la PEP
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 (bad)
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__ from
PEP 310?
It's
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 then pychecker bitches about
[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 for this pattern :)
+1.
[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:
[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 isn't able to realise
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),
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
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
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
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: sequence[T], initial: T =
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] wink.
Michael
___
Python-Dev
24 matches
Mail list logo
