I reverted both changes. They can be re-applied after the 2.5 is unfrozen. -- n
On 4/15/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Saturday 14 April 2007 10:07, Kristján Valur Jónsson wrote:
> > Hello all.
> > I made two checkins to the 25 maintainance branch before Martin
> > kindly poin
On Saturday 14 April 2007 10:07, Kristján Valur Jónsson wrote:
> Hello all.
> I made two checkins to the 25 maintainance branch before Martin
> kindly pointed out to me that it is frozen. These are quite
> simple fixes to real crashes I have experienced. The fix in
> frameobject.c will be necessar
On 4/15/07, SevenInchBread <[EMAIL PROTECTED]> wrote:
[...]
> --
> "What's money? A man is a success if he gets up in the morning and goes to
> bed at night and in between does what he wants to do." ~ Bob Dylan
If you ask me, SevenInchBread (not her real name) is a Troll. Let her
prove she isn't.
On Sun, 15 Apr 2007 18:18:16 -0400, SevenInchBread <[EMAIL PROTECTED]> wrote:
>>>Do you have commit access? What's your real name?
>I prefer to remain pseudonymous, and I don't have commit access.
>
>Yeah... they're not terribly useful - more or less there for the sake of
>being there. Batteries in
> def cat(x): return x
>
> def multimap(func, s, n=2):
> assert n > 0, "n must be positive"
> return (map(func, seq)
> if n == 1 else
> map(lambda x: multimap(func, x, n-1),
> seq))
>
> def multifilter(func, s, n=2):
> return multimap(lambda x: fi
Do you have commit access? What's your real name?
I prefer to remain pseudonymous, and I don't have commit access.
Yeah... they're not terribly useful - more or less there for the sake of
being there. Batteries included and all that
...but now I've got a more useful idea for a function wrapper
Hi Raymond,
Thanks for the detailed explanation!
> I'm not sure what your code was doing where the bugfix would cause
> breakage. If its __getitem__() override returned a meaningful value
> for each element in obj.keys(), then it should have worked fine. Of
> course, if it was raising an except
People seem to be pushing for a consistent method for checking the "x-ness"
of objects (that is, interfaces that the object implements).
So I present an idea for a simple and straightforward type that provides a
way to construct descriptions of object structures, and I'd like some help
expanding
On 4/15/07, SevenInchBread <[EMAIL PROTECTED]> wrote:
> So I've cooked up some very simple functions to add to functools - to expand
> it into a more general-purpose module.
>
> def cat(x): return x
>
> class nullfunc(object):
> def __call__(self, *args, **kargs): return self
> def __getatt
> So if it's alright with the privledged folk - I'd like to commit
> these minor (and probably non-controversial) additions to the functools
> module.
Do you have commit access? What's your real name?
-1 on these additions. If lambda x:x would be added, it should be named
"identity", not "cat
SevenInchBread <[EMAIL PROTECTED]> wrote:
> So I've cooked up some very simple functions to add to functools - to expand
> it into a more general-purpose module.
[snip]
I don't use a functional approach very often, but I haven't ever had a
case where I would want or need to use any of the functio
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> Carl Banks wrote:
>> > I'd like to see it accept a flags argument over what kind of buffer
>> > it's allowed to return. I'd rather not burden the user to check
>> all > the entries in bufferinfo to make sure it doesn't get something
>> > unexpect
Here is my "final" draft of the extended buffer interface PEP.
For those who have been following the discussion, I eliminated the
releaser object and the lock-buffer function. I decided that there is
enough to explain with the new striding and sub-offsets without the
added confusion of rel
ACTIVITY SUMMARY (03/20/07 - 03/27/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1646 open ( +2) / 8583 closed ( +1) / 10229 total ( +3)
Average duration of open issues: 747 days.
Medi
Carl Banks wrote:
> Tr
> ITSM that we are using the word "view" very differently. Consider
> this example:
>
> A = zeros((100,100))
> B = A.transpose()
You are thinking of NumPy's particular use case. I'm thinking of a
generic use case. So, yes I'm using the word view in two different
cont
Greg Ewing wrote:
> But since the NumPy object has to know about the provider,
> it can simply pass the release call on to it if appropriate.
> I don't see how this case necessitates making the release call
> on a different object.
>
> I'm -1 on involving any other objects or returning object
> re
> I'll be as brief as possible. The welcome message to this list suggested
> that I post a brief introduction of myself, so here it goes. I've been
> programming for about 10 years now (7 professionally). I would rank
> myself as a moderate programmer always looking to improve, and
> would like
So if it's alright with the privledged folk - I'd like to commit these
minor (and probably non-controversial) additions to the functools module.
def cat(x): return x
def multimap(func, s, n=2):
assert n > 0, "n must be positive"
return (map(func, seq)
if n == 1 else
So I've cooked up some very simple functions to add to functools - to expand
it into a more general-purpose module.
def cat(x): return x
class nullfunc(object):
def __call__(self, *args, **kargs): return self
def __getattr__(self, name):return getattr(None, name)
def multimap(fun
19 matches
Mail list logo
