On 7-nov-2005, at 23:34, Martin v. Löwis wrote:
> BJörn Lindqvist wrote:
>> How would the value equality operator deal with recursive objects?
>>
>> class Foo:
>> def __init__(self):
>> self.foo = self
>>
>> Seems to me that it would take atleast some special-casing to get
>> Foo() ==
Patch / Bug Summary
___
Patches : 365 open ( +5) / 2961 closed ( +5) / 3326 total (+10)
Bugs: 904 open (+11) / 5367 closed (+14) / 6271 total (+25)
RFE : 200 open ( +1) / 189 closed ( +0) / 389 total ( +1)
New / Reopened Patches
__
new funct
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> BJörn Lindqvist wrote:
>> How would the value equality operator deal with recursive objects?
>>
>> class Foo:
>> def __init__(self):
>> self.foo = self
>>
>> Seems to me that it would take atleast some special-casing to get
>> Foo() ==
Jeremy Hylton wrote:
> I think part of the problem is that setup.py has a bunch of heuristics
> that are intended to do the right thing without user intervention.
> If, on the other hand, the user wants to intervene, because "the right
> thing" is wrong for cross-compiling, you are kind of stuck.
Neal Norwitz wrote:
> First, distutils is required to build all the modules.
As Guido already suggests, this assertion is false. In a
cross-compilation environment, I would try to avoid distutils,
and indeed, the build process to do so is still supported.
> Second, in configure we try to run lit
BJörn Lindqvist wrote:
> How would the value equality operator deal with recursive objects?
>
> class Foo:
> def __init__(self):
> self.foo = self
>
> Seems to me that it would take atleast some special-casing to get
> Foo() == Foo() to evalute to True in this case...
This is sort-of
On Mon, 2005-11-07 at 16:38, Jeremy Hylton wrote:
> I think part of the problem is that setup.py has a bunch of heuristics
> that are intended to do the right thing without user intervention.
> If, on the other hand, the user wants to intervene, because "the right
> thing" is wrong for cross-comp
On 11/7/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> We've been having some issues and discussions at work about cross
> compiling. There are various people that have tried (are) cross
> compiling python. Right now the support kinda sucks due to a couple
> of reasons.
This might make a good spr
On 11/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> About using distutils to build the extensions, this is because some
> extensions require quite a bit of logic to determine the build
> commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils
> way of building extensions using Mod
I was interested in getting feedback from current mail group users.We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband.Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast vide
I know some folks have successfully used cross-compilation before. But
this was in a distant past. There was some support for it in the
configure script; surely you're using that? I believe it lets you
specify defaults for the TRY_RUN macros. But it's probably very
primitive.
About using distutils
We've been having some issues and discussions at work about cross
compiling. There are various people that have tried (are) cross
compiling python. Right now the support kinda sucks due to a couple
of reasons.
First, distutils is required to build all the modules. This means
that python must be
Two more thoughts in this thread.
(1) The "key" idiom is a great pattern but I don't think it would work
well to make it a standard language API.
(2) I'm changing my mind about the default hash().
The original default hash() (which would raise TypeError if __eq__ was
overridden but __hash__ was
How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to evalute to True in this case...
--
mvh Björn
_
Bryan Olson wrote:
> From what I can tell, We need to address fixing the
> PEP process before there is any point in working on PEP's,
I think this is a somewhat fair point (although perhaps a bit overstated) -
David and Barry can be busy IRL, which can certainly slow down the process of
PEP sub
15 matches
Mail list logo
