Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>> It would be nice if there was a similar mechanism for normal instance
>> methods
>> as well:
>>
>>method = function(some_callable)
>>
>
> If you know you have to put something around it, what's wrong with writing
>
> method = lambda *args:
Nick Coghlan schrieb:
> It would be nice if there was a similar mechanism for normal instance methods
> as well:
>
>method = function(some_callable)
>
If you know you have to put something around it, what's wrong with writing
method = lambda *args:some_callable(*args)
If that happens of
Jim Jewett schrieb:
> hash was just changed to support the common use of id, even though
> some people argued it was *really* a bug in the classes themselves.
> This is a similar situation.
Similar still different. In the case of __hash__ returning id(),
it is very clear what the intention of the
Guido van Rossum schrieb:
>> >__eq__ methods should always return True or False. They should
>> >only raise an exception if there is some internal error within
>> >one of the objects being compared -- they should never raise
>> >an exception because the other object is of an unexpe
On 8/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Michael Chermside schrieb:
> > I propose that we institute a new policy. The policy should state:
> >
> >__eq__ methods should always return True or False. They should
> >only raise an exception if there is some internal error withi
On 8/11/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis writes:
> > Now I looked at it, and think that the recipe is broken.
>
> Not broken, but perhaps wrongheaded. The recipe went out of its way
> to ensure that it would raise an exception of enum values from different
> enumer
It's sometimes useful to be able to use an existing callable as a method of a
new class. If the callable is a real function, this is easy. You just
including the following line in the class definition:
method = some_callable
However, callable objects without a function-like __get__ method ca
I know that it is a subject of an annual discussion, but since I could
not find any mention of it in the last year, let me ask this question
again: why is file.readinto "Undocumented"? It is quite useful,
particularly with numpy.
Would a patch adding "readinto" to StringIO be acceptable?
_
Michael Chermside schrieb:
> Not broken, but perhaps wrongheaded. The recipe went out of its way
> to ensure that it would raise an exception of enum values from different
> enumerations were compared. There's nothing out there saying that this
> is a bad thing to do.
And it's actually fine for th
M.-A. Lemburg wrote:
> Guido van Rossum wrote:
>> Marc-Andre, how's the patch coming along?
>
> I'm working on it.
>
> Since we only want equal compares to generate the warning,
> I have to add a rich compare function to Unicode objects.
Here's an initial version:
http://sourceforge.net/tracker
Martin v. Löwis writes:
> Now I looked at it, and think that the recipe is broken.
Not broken, but perhaps wrongheaded. The recipe went out of its way
to ensure that it would raise an exception of enum values from different
enumerations were compared. There's nothing out there saying that this
is
Martin v. Löwis wrote:
> Now I looked at it, and think that the recipe is broken. It should
> add an __eq__ method which is
> def __eq__(self, other):
> return type(self) is type(other) \
> and self.EnumType is other.EnumType \
> and self.__value==other.__value)
Absol
Phillip J. Eby schrieb:
> Actually, this isn't as hard as you're implying. In at least the
> "compiler.ast" package, such an operation would be represented as a
> CallFunc node as the child of an Assign node. Wrapping the call node's
> main child expression in a Getattr for __setcall__ would then
At 09:40 PM 8/11/2006 +0200, Martin v. Löwis wrote:
>Michael Urman schrieb:
> > On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> >> The question doesn't make sense: in Python, you assign to a name,
> >> an attribute or a subscript, and that's it.
> >
> > Just to play devil's advocate here, wh
Armin Ronacher schrieb:
> Right, I didn't know that. From that old bug report it sounded like a
> programmer
> should be able to select a specific UCD version.
Well, my comment was that _IDNA_ needs to access _3.2_. This isn't as
general as "any application needs to access any version". We likely
Neal Becker schrieb:
>> No. Array references (x[i]) and attribute references (x.a) represent
>> "locations". Function calls represent values. This is no different
>> than the distinction between lvalues and rvalues in C.
>>
>
> Except this syntax is valid in c++ where X() is a constructor call:
>
Michael Urman schrieb:
> On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> The question doesn't make sense: in Python, you assign to a name,
>> an attribute or a subscript, and that's it.
>
> Just to play devil's advocate here, why not to a function call via a
> new __setcall__?
Just try s
Chris S schrieb:
> I'm happy to see Elementtree being considered for inclusion with 2.5.
> However, before committing to this decision, there's an issue
> regarding it's namespace parsing that should be addressed. Although
> Elmenttree is in most respects an excellent XML parser, a huge gotcha
> th
Michael Chermside schrieb:
> I don't *strongly* object to this consensus, but if you haven't
> glanced at my original example, take a look - it might convince you.
> The proposed solution will not help with my example.
I ignored your example the first time because it was too complicated
to underst
There are errors now after the testsuite has finished. Taken from the very end
of the
amd64 test log (for example).
http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/1403/step-test/0
[...]
293 tests OK.
26 tests skipped:
test_aepack test_al test_applesingle test_bsddb18
Guido van Rossum schrieb:
> Me too, and that's what we'll do in py3k. But in 2.5, we're bound by
> the decisions we made in 1999-2000 about unicode. (Unless Martin has a
> convincing reason not to have a warning?)
Only the general anti-warning argument: it's not the developer which
will see the wa
Greg Ewing schrieb:
> That can't be right, because it would mean that
> anyone who runs a program that contains a
> patented algorithm, even one bought or otherwise
> obtained from someone else, would need to
> individually negotiate a licence with the
> patent owner. That clearly doesn't happen.
Chris Spencer writes:
> there's an issue
> regarding [ElementTree's] namespace parsing that should be addressed.
[... it performs namespace rewriting ...]
> while most users and the w3 spec
> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting)
> agree this feature is actually
Guido van Rossum wrote:
> Marc-Andre, how's the patch coming along?
I'm working on it.
Since we only want equal compares to generate the warning,
I have to add a rich compare function to Unicode objects.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#
I'm happy to see Elementtree being considered for inclusion with 2.5.
However, before committing to this decision, there's an issue
regarding it's namespace parsing that should be addressed. Although
Elmenttree is in most respects an excellent XML parser, a huge gotcha
that often makes Elementtree
On 8/11/06, Neal Becker <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> >> It makes just as much sense as assigning to an array access, and the
> >> semantics would be pretty similar.
> >
> > No. Array references (x[i]) and attribut
OK, I'll withdraw from this discussion again. Thanks all!
On 8/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Travis E. Oliphant wrote:
> > Travis E. Oliphant wrote:
> >> Here is my C-API proposal
> >>
> >> 1) PyIndex_Check(obj)
> >>
> >>Similar to PyIter_Check(obj) as it just checks for whe
On 8/11/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
> > > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > > > I'm in favour of having this __eq__ just return False. I don't think
> > > > the warning is
Guido writes:
> Alas, I have no idea what it does. Can you come up with an example
> that doesn't require enums and localization?
Sorry. Here's the short version:
Fact 1: Sometimes people create objects that raise exceptions when
compared for equality. Maybe it's a bad idea to do this, and object
so it should be fixed, or at least checked for conformness by the code.-tomerOn 8/11/06, Tim Peters <
[EMAIL PROTECTED]> wrote:[tomer filiba]> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.> if i raise an in
[tomer filiba]
> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
> if i raise an instance, sys.exc_info() confuses the exception value for
> the exception type, and the exception value is set None. if i raise
Travis E. Oliphant wrote:
> Travis E. Oliphant wrote:
>> Here is my C-API proposal
>>
>> 1) PyIndex_Check(obj)
>>
>>Similar to PyIter_Check(obj) as it just checks for whether or not the
>> object can call nb_index. Actually implemented as a macro.
>>
>> 2) PyObject* PyNumber_Index(obj)
>>
>>
Travis E. Oliphant wrote:
> Here is my C-API proposal
>
> 1) PyIndex_Check(obj)
>
>Similar to PyIter_Check(obj) as it just checks for whether or not the
> object can call nb_index. Actually implemented as a macro.
>
> 2) PyObject* PyNumber_Index(obj)
>
>Simple interface around nb_inde
Guido van Rossum wrote:
> On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>> It makes just as much sense as assigning to an array access, and the
>> semantics would be pretty similar.
>
> No. Array references (x[i]) and attribute references (x.a) represent
> "locations". Function calls repr
Armin Rigo wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
>>> On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
I'm in favour of having this __eq__ just return False. I don't think
the warning is necessary, (...)
>>> +1
>> Can you expl
opened a new bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1538556&group_id=5470&atid=105470
On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsy
Hi,
On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
> > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > > I'm in favour of having this __eq__ just return False. I don't think
> > > the warning is necessary, (...)
> >
> > +1
>
> Can you explain why you beli
while working on a library for raising exceptions in the context
of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
if i raise an instance, sys.exc_info() confuses the exception value for
the exception type, and the exception value is set None. if i raise the
type itself, the i
Here is my C-API proposal
1) PyIndex_Check(obj)
Similar to PyIter_Check(obj) as it just checks for whether or not the
object can call nb_index. Actually implemented as a macro.
2) PyObject* PyNumber_Index(obj)
Simple interface around nb_index that calls it if possible and returns
Ty
Georg Brandl wrote:
> Is this considered a bug? Sure, deleting modules from sys.modules
> isn't quite common, but it happened to me on one occasion.
>
> Python 2.4.3 (#1, Jul 29 2006, 10:52:20)
> >>> import logging
> >>> import sys
> >>> del logging
> >>> del sys.modules['logging']
> >>> ^D
>
40 matches
Mail list logo
