Re: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure

[Brett Cannon]

On Mon, Feb 9, 2009 at 14:02, Guido van Rossum  wrote:

> On Mon, Feb 9, 2009 at 1:56 PM,   wrote:
> > Guido and I were discussing what a loader should be responsible for when
> > load_module is called and an exception is raised in relation to
> sys.modules
> > as PEP 302 says nothing about the topic.
> >
> > We both agree that if the loader added a module to sys.modules it should
> be
> > removed, otherwise it should be left alone.
> >
> > Assuming no one disagrees I will update the PEP to specify that this is
> the
> > expected job of loaders.
>
> (Note that currently most loaders we've looked at end up removing the
> module unconditionally, as this is what PyImport_ExecCodeModuleEx()
> does. PyImport_ReloadModule() has a super-duper hack to save the
> module object and put it back into sys.modules:
>
>if (newm == NULL) {
>/* load_module probably removed name from modules because of
> * the error.  Put back the original module object.  We're
> * going to return NULL in this case regardless of whether
> * replacing name succeeds, so the return value is ignored.
> */
>PyDict_SetItemString(modules, name, m);
>}
>
> If we could get conforming loaders to behave as proposed, we wouldn't
> need this ugly hack.
>

PEP 302 was updated in r69632.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Terry Reedy]

Martin v. Löwis wrote:

Terry Reedy wrote:

Guido van Rossum wrote:

Irix is long dead and we don't support it in any form or version.

I closed the tracker issue.  I will let Martin update PEP11.


I think you misunderstand the purpose of PEP 11. It is not meant
as a repository of platforms not longer supported,


However, that would be a useful purpose for people doing triage on 
tracker issues.


> but a list of

announcements of which systems will not be supported anymore in
*upcoming* releases.

It seems that the removal of Irix support has bypassed PEP 11.


If the complete end of Irix support had been documented, I would not 
have had to ask and several other issues would have already been closed.



Perhaps the PEP should be withdrawn.


Please no.

tjr

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] draft 3.1 release schedule

[Benjamin Peterson]

Here's a very tentative 3.1 release schedule.

3.1a1 March 7 (Saturday)
3.1a2 April 11 (Saturday)
3.1b1 May 2 (Saturday)
3.1b2 May 23 (Saturday)
3.1rc1 June 13 (Saturday)
3.1rc2 June 27 (Saturday)

I'm interested in your feedback with regards to the amount of time in
beta and RC phase. Do you think we need that much time? Otherwise, we
could move the final release back sometime in mid June.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

In article <499723cd.80...@v.loewis.de>,
 "Martin v. Lowis"  wrote:
> > That's fine as long as the distutils issue is resolved.
> I don't think this should be a prerequisite. As Ronald says: no fix
> without a bug report; if the system is capable of building the extension
> correctly, it should do so (so it's a bug and fixes can be backported
> to 2.6)

And it turns out it should not be a problem for 3.x (and future releases 
of 2.x).  Ronald fixed it several weeks ago here:
  

Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.util import get_platform; print(get_platform())
macosx-10.3-fat
>>> 

My apologies to Ronald and the cohort for not re-examining this 
recently.  The distutils "problem" isn't anymore.

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Martin v. Löwis]

> That's fine as long as the distutils issue is resolved.

I don't think this should be a prerequisite. As Ronald says: no fix
without a bug report; if the system is capable of building the extension
correctly, it should do so (so it's a bug and fixes can be backported
to 2.6)

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Small misleadingness in docs

[Greg Ewing]

Terry Reedy wrote:

The new (in 3.0 and maybe 2.6, but undocumented) special methods 
__instancecheck__ and __subclasscheck__ let one overload the default 
behavior of isinstance and issubclass.


That's fine for 3.0, but I don't think the current behaviour
should be removed from any 2.x version, as it would make
writing code that works over multiple 2.x versions difficult.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Martin v. Löwis]

Ronald Oussoren wrote:
> 
> On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:
> 
>>> A single installer could support both 32-bit on 10.4 and 64-bit on
>>> 10.5, but I don't think that's very useful because there are changes
>>> in the low-level unix API's that could result in different behaviour
>>> of a 32-bit and 64-bit script on the same system. In general 10.5 has
>>> much saner Unix API's than earlier releases.
>>
>> I don't get that. Why would the scripts behave differently on 10.5
>> depending on whether the Python interpreter is 32-bit or 64-bit?
>> Surely, the Unix API does the same thing, whether invoked from 32-bit
>> code, or 64-bit code, no?
> 
> I should have been more clear: the unix API for code that runs on
> 10.4 is slightly different than that for code that runs on 10.5+, Apple
> basiclly fixed a number of UNIX API-compliance issues in 10.5.

So how come? Are you really saying that 10.5 somehow knows whether the
code might also run on 10.4, and if so, deliberately behaves
differently?

So that a Python interpreter compiled for 10.4+ would behave differently
on a specific 10.5 installation than a Python interpreter compiled for
10.5+, on the very same system?

If so, I'm -1 on providing two sets of binaries for the same Python
version (one in 10.4+ mode and one in 10.5+ mode). Otherwise, this
sounds like a good source of confusion: "are you using Python 3.1
as compiled for 10.4 or 3.1 as compiled for 10.5?" - "well, how
do I tell?"

Is this Apple's DLL hell?

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Alex Martelli]

On Sat, Feb 14, 2009 at 3:22 AM, Ned Deily  wrote:
   ...
> have done complete and thorough testing.  (In particular, I have no
> access to a G5 for 64-bit PPC testing.)

I have a PowerMac G5 at home and I'll be glad to run tests if it
helps.  (It runs 10.5: "family pack" licenses are cheap, so I've
always routinely upgraded all my home Macs to recent OSX releases).
(I'm not home during the weekend though).


Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 19:44, Ned Deily wrote:


In article <499707a0.7000...@v.loewis.de>,
"Martin v. Lowis"  wrote:

That said, the difference between a binary capable of running on
10.4+ and one running 10.3+ is minimal. I introduced weak-linking  
for

a number of symbols that are not present on 10.3.9 in the 2.5
timeframe and that could should continue to work in the future. I
won't notice when someone introduces additional calls to functions
not available on 10.3 though.


Sounds good to me!


That's fine as long as the distutils issue is resolved.  I believe the
way things stand today is that a "fat" Python built with a deployment
target of 10.3 will report a platform of "ppc" or "i386" even on  
10.4 or

10.5 systems and even though the extensions are, in fact, "fat".  This
means developers who provide uploads to PyPI of packages with C
extensions have to upload two versions even though the contents of  
both

can be identical.  (The appscript has run into this problem.)   And it
causes maintenance issues for users with multiple architectures.

With the target set to 10.4, the platform is reported correctly as
"fat".  And, for 10.5 4-way, "universal".


Please file an issue for this at the python tracker. The intended  
behaviour
is that the reported platform is the platform that distutils can build  
for on
the current machine (ppc only on 10.3, "fat" on 10.4 and "universal"  
on 10.5,

given a 4-way build of python).

Getting the experience entire correct probably requires changes to other
tools as well (such as setuptools, it should be taught that a  
"universal" egg

can satisify a dependency when the current platform is "fat" or "ppc".

Issues like this is why I've asked on the pythonmac-sig if anyone is  
interested
on sprinting on macpython at Pycon. Getting these things correct takes  
time
and is much easier when several people can work on it at the same  
location.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Martin v. Löwis]

Terry Reedy wrote:
> Guido van Rossum wrote:
>> Irix is long dead and we don't support it in any form or version.
> 
> I closed the tracker issue.  I will let Martin update PEP11.

I think you misunderstand the purpose of PEP 11. It is not meant
as a repository of platforms not longer supported, but a list of
announcements of which systems will not be supported anymore in
*upcoming* releases.

It seems that the removal of Irix support has bypassed PEP 11.
Perhaps the PEP should be withdrawn.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The fate of 3.0.*

[Brett Cannon]

Don't rely on me getting importlib bootstrapped in by 3.1. It would be great
if I pull it off, but I am afraid that is being optimistic. The library
itself should definitely be done, though.

On Feb 13, 2009 7:56 PM, "Antoine Pitrou"  wrote:

Benjamin Peterson  python.org> writes: > > Are we going to
keep developing the 3.0 ma...
Focusing on 3.1 should be ok.
So what are the expected efforts for 3.1?
- io-in-C
- import-in-Python
- ... anything else?

Regards

Antoine.

___ Python-Dev mailing list
Python-Dev@python.org http...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

In article <878wo8swxe@xemacs.org>,
 "Stephen J. Turnbull"  wrote:
> Guido van Rossum writes:
> 
>  > Actually I expect that to be fairly common among people who are not so
>  > much into technology, strapped for funds but appreciative of quality,
>  > bought an expensive Mac once expecting it would last a long time, and
>  > are hanging on to it until it dies (which could be a long time). Their
>  > hardware may not support newer OS X versions.
> 
> I'm quite familiar with that.  Thing is, although I still have a
> Panther box running, I gave up on updating *anything* on it when
> Leopard came out, because I had to spend too much time fighting with
> bitrot in packages which stopped working after upgrades on my Tiger
> box, let alone on Panther.  The Panther box still does the stuff that
> I want it to do, but it isn't going to learn any new tricks, I'm
> afraid.
> 
> If that is a more general phenomenon, I have to wonder whether people
> with old Macs with old OSes are going to be all that interested in
> shiny new Pythons.
> 
> I think that the extra effort of building an extra installer for 10.4
> will be well-repaid in better support for 10.5 users, and the option
> of abandoning the 10.4 installer in a few months if it doesn't get
> very many downloads.

You mentioned MacPorts earlier.  FWIW, here's their position on version 
support:

"We provide a single software tree that attempts to track the latest 
release of every software title (port) we distribute, without splitting 
them into "stable" Vs. "unstable" branches, targetting mainly the 
current Mac OS X release (10.5, A.K.A Leopard) and the immediately 
previous one (10.4, A.K.A. Tiger)."

And Fink, the other major open-source package provider for OS X, is even 
more explicit:

"The Fink project is no longer able to offer support for users of Fink 
on Mac OS X 10.3. In reality there has been very little support for some 
time, so this announcement simply formalizes that fact.
This means that there will not be any further updates, not even security 
updates, for Mac OS X 10.3 users. Their existing installations will 
continue to work, but the software that is installed will not be updated.
We believe that the majority of our users are using Mac OS X 10.4 or 
10.5 and hope that this does not inconvenience too many people."

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:


A single installer could support both 32-bit on 10.4 and 64-bit on
10.5, but I don't think that's very useful because there are changes
in the low-level unix API's that could result in different behaviour
of a 32-bit and 64-bit script on the same system. In general 10.5 has
much saner Unix API's than earlier releases.


I don't get that. Why would the scripts behave differently on 10.5
depending on whether the Python interpreter is 32-bit or 64-bit?
Surely, the Unix API does the same thing, whether invoked from 32-bit
code, or 64-bit code, no?


I should have been more clear: the unix API for code that runs on
10.4 is slightly different than that for code that runs on 10.5+, Apple
basiclly fixed a number of UNIX API-compliance issues in 10.5.

Those differences might affect the behaviour of the Python interpreter,
and at least would make the configure stage even more involved for
such a build, because several configure-checks give different output
for MACOSX_DEPLOYMENT_TARGET=10.4 and MACOSX_DEPLOYMENT_TARGET=10.5.

I haven't checked yet if it is even possible to have a 64-bit binary
that runs on 10.4 and 10.5.





I still wish there were 10.3+ installers that also include 64-bit
code. I don't get it why that can't be technically possible.


The problem with 10.3 support is that we need volunteers to actually
investigate and fix issues that only occur on 10.3 systems. I cannot
be that volunteer because I no longer have access to systems that are
capable of running 10.3.


I don't think it is necessary to actually test whether the binaries
work on 10.3; I don't test the Windows installers on Windows 2000,
either. For me, it's good enough if we believe that the installer
"should" work on 10.3.

Then, if somebody reports a problem, we can still consider what to do.
If there are no reports, it either means there are no problems, or
nobody uses it, or nobody bothers reporting the problems.


I'm not 100% happy with this, but I could live with this. As long as  
Apple

ships a 10.3 SDK I might even be able to check for unsupported API
calls once in while.

Having thought a little more about the issues, I do think that we  
should provide
an installer that runs on as many systems as possible.  As Guido noted  
many

people don't bother to upgrade, and I'd expect many schools to be that
category as well (as an example of a type of organisation that's often  
lacking

in funding).

I need more time to think about the options, and I don't think there's  
a reason

to rush this and would prefer to discuss this issue at Pycon.

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

In article <499707a0.7000...@v.loewis.de>,
 "Martin v. Lowis"  wrote:
> > That said, the difference between a binary capable of running on
> > 10.4+ and one running 10.3+ is minimal. I introduced weak-linking for
> > a number of symbols that are not present on 10.3.9 in the 2.5
> > timeframe and that could should continue to work in the future. I
> > won't notice when someone introduces additional calls to functions
> > not available on 10.3 though.
> 
> Sounds good to me!

That's fine as long as the distutils issue is resolved.  I believe the 
way things stand today is that a "fat" Python built with a deployment 
target of 10.3 will report a platform of "ppc" or "i386" even on 10.4 or 
10.5 systems and even though the extensions are, in fact, "fat".  This 
means developers who provide uploads to PyPI of packages with C 
extensions have to upload two versions even though the contents of both 
can be identical.  (The appscript has run into this problem.)   And it 
causes maintenance issues for users with multiple architectures.

With the target set to 10.4, the platform is reported correctly as 
"fat".  And, for 10.5 4-way, "universal".

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Stephen J. Turnbull]

Guido van Rossum writes:

 > Actually I expect that to be fairly common among people who are not so
 > much into technology, strapped for funds but appreciative of quality,
 > bought an expensive Mac once expecting it would last a long time, and
 > are hanging on to it until it dies (which could be a long time). Their
 > hardware may not support newer OS X versions.

I'm quite familiar with that.  Thing is, although I still have a
Panther box running, I gave up on updating *anything* on it when
Leopard came out, because I had to spend too much time fighting with
bitrot in packages which stopped working after upgrades on my Tiger
box, let alone on Panther.  The Panther box still does the stuff that
I want it to do, but it isn't going to learn any new tricks, I'm
afraid.

If that is a more general phenomenon, I have to wonder whether people
with old Macs with old OSes are going to be all that interested in
shiny new Pythons.

I think that the extra effort of building an extra installer for 10.4
will be well-repaid in better support for 10.5 users, and the option
of abandoning the 10.4 installer in a few months if it doesn't get
very many downloads.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Daniel (ajax) Diniz]

Terry Reedy wrote:
> Can http://bugs.python.org/issue995458
> "Does not build selected SGI specific modules"be closed?
>
> PEP11 lists Irix 4 as gone.  What about Irix 6?
> http://www.python.org/dev/peps/pep-0011/

Thank you, thank you, thank you :)

Can I close these other IRIX issues?

http://bugs.python.org/issue2048
http://bugs.python.org/issue1086642
http://bugs.python.org/issue1178510
http://bugs.python.org/issue1070140

Do you know of other OSes (among commercial Unix, mostly) that could
also get the axe?

Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Terry Reedy]

Guido van Rossum wrote:

Irix is long dead and we don't support it in any form or version.

On Sat, Feb 14, 2009 at 9:07 AM, Terry Reedy  wrote:

Can http://bugs.python.org/issue995458
"Does not build selected SGI specific modules"be closed?

PEP11 lists Irix 4 as gone.  What about Irix 6?
http://www.python.org/dev/peps/pep-0011/

Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that Irix
specific modules are gone from Py3.
http://www.python.org/dev/peps/pep-3108/#irix
Does Py3 still have Irix 6 support?


I closed the tracker issue.  I will let Martin update PEP11.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Martin v. Löwis]

> A single installer could support both 32-bit on 10.4 and 64-bit on 
> 10.5, but I don't think that's very useful because there are changes 
> in the low-level unix API's that could result in different behaviour
> of a 32-bit and 64-bit script on the same system. In general 10.5 has
> much saner Unix API's than earlier releases.

I don't get that. Why would the scripts behave differently on 10.5
depending on whether the Python interpreter is 32-bit or 64-bit?
Surely, the Unix API does the same thing, whether invoked from 32-bit
code, or 64-bit code, no?

>> I still wish there were 10.3+ installers that also include 64-bit
>> code. I don't get it why that can't be technically possible.
> 
> The problem with 10.3 support is that we need volunteers to actually 
> investigate and fix issues that only occur on 10.3 systems. I cannot
> be that volunteer because I no longer have access to systems that are
>  capable of running 10.3.

I don't think it is necessary to actually test whether the binaries
work on 10.3; I don't test the Windows installers on Windows 2000,
either. For me, it's good enough if we believe that the installer
"should" work on 10.3.

Then, if somebody reports a problem, we can still consider what to do.
If there are no reports, it either means there are no problems, or
nobody uses it, or nobody bothers reporting the problems.

> That said, the difference between a binary capable of running on
> 10.4+ and one running 10.3+ is minimal. I introduced weak-linking for
> a number of symbols that are not present on 10.3.9 in the 2.5
> timeframe and that could should continue to work in the future. I
> won't notice when someone introduces additional calls to functions
> not available on 10.3 though.

Sounds good to me!

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Guido van Rossum]

Irix is long dead and we don't support it in any form or version.

On Sat, Feb 14, 2009 at 9:07 AM, Terry Reedy  wrote:
> Can http://bugs.python.org/issue995458
> "Does not build selected SGI specific modules"be closed?
>
> PEP11 lists Irix 4 as gone.  What about Irix 6?
> http://www.python.org/dev/peps/pep-0011/
>
> Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that Irix
> specific modules are gone from Py3.
> http://www.python.org/dev/peps/pep-3108/#irix
> Does Py3 still have Irix 6 support?
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 13:05, Martin v. Löwis wrote:



2. Release an installer built for 10.4 and higher.
  pros: one size fits all
  cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc


Why is it that such an installer couldn't include 64-bit support?
Wouldn't 10.4 just ignore architectures it doesn't know about?
Also, didn't 10.4 already support ppc64?


10.4 only supported 64-bit code for a very limited number of system  
libraries, basicly just enough to support running 64-bit number  
crunching code.  System-wide support for 64-bit code was added in 10.5.


A single installer could support both 32-bit on 10.4 and 64-bit on  
10.5, but I don't think that's very useful because there are changes  
in the low-level unix API's that could result in different behaviour  
of a 32-bit and 64-bit script on the same system. In general 10.5 has  
much saner Unix API's than earlier releases.





So, to summarize, I will build and test installer images for 3.0.1  
built

for 10.4+ and for 10.5+ and will make them available, if there is
interest.  If someone else is planning on making official  
installer(s),

I'd be happy to pass along my experiences so far.  In any case, I
strongly urge that the minimum support level be 10.4.


I still wish there were 10.3+ installers that also include 64-bit  
code.

I don't get it why that can't be technically possible.


The problem with 10.3 support is that we need volunteers to actually
investigate and fix issues that only occur on 10.3 systems. I cannot be
that volunteer because I no longer have access to systems that are
capable of running 10.3.

That said, the difference between a binary capable of running on 10.4+
and one running 10.3+ is minimal. I introduced weak-linking for a number
of symbols that are not present on 10.3.9 in the 2.5 timeframe and that
could should continue to work in the future. I won't notice when someone
introduces additional calls to functions not available on 10.3 though.

Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 12:22, Ned Deily wrote:

Speaking of an OS X installer for 3.0.1, over the last few weeks I  
have
been working on tidying up the OS X installer build process.  While  
the

basic OS X build/installer process is good, some cruft has accumulated
over the past years and a number of mostly minor issues arose due to  
the
3.x split.  IMO, the most important issues were with IDLE and,  
thanks to
Ronald, we did get the most important fixes for OS X IDLE checked-in  
in

time for 3.0.1; they are also in py3k and will be going into trunk and
26.  I have a few other fixes that apply just to the OSX build/ 
installer
parts which did not get submitted in time for the 3.0.1 cutoff but  
which
are ready to go for 3.x and 2.x.  Basically they fix some version  
number
updating and ensure that the installer image will be built  
reproducibly

in a clean environment so there is no contamination of the installer
images.  Currently, that's easy to do as happened with the first round
of the OS X 2.6 installer (e.g. with a locally installed Tcl/Tk).   
They
also allow images to build for various OS X version.  More on that  
below.


There's one problem with building with an entirely clean environment  
though, the 2.5 installers were build with a locally instaled Tcl/Tk  
on purpose. Such a build uses a locally installed Tcl/Tk when  
available and uses the system version when it is not. Several Tkinter  
users on OSX pushed heavily for that because appearently the system Tk  
is much less usable than the 3th-party install.


I don't care much either way, IMHO the look and feel of Tk apps sucks  
with either version of Tcl/Tk and I don't use Tkinter anyway.




I would like to get to the point where the OS X images can be  
generated

and tested automatically.  I think that is reasonable and achievable.
It's not quite there yet but I can now semi-automatically produce  
images
for 2.6, 2.7 (trunk), 3.0, and 3.1 (py3k) in both the traditional  
"fat"
(32-bit i386) for 10.4/10.5 and, for 10.5, "universal" (4-way 32-bit  
and

64-bit intel/ppc).  They all have been passing the standard regrtest
with no new obvious (to me) regressions but I certainly won't claim to
have done complete and thorough testing.  (In particular, I have no
access to a G5 for 64-bit PPC testing.)


I'd love to get to the point where it's possible to completely  
automaticly build the installers. I noticed one issue with that that  
I'll fix in the near future: the current build script for the OSX  
installer relies on the availability of the HTML docs download on the  
Python ftp-site. That dependency should no longer be necessary now  
that the documentation is build using a pure python toolchain.





However the "official" OS X images are built, there is an important
issue about them that should be addressed now.   That issue is which  
OS
X versions should be supported by installer images.  (This may well  
have
been discussed before so my apologies if I am covering old ground  
here.)




The last Apple point release of 10.3 was in 4/2005.  10.4 was also
released then.  The last Apple maintenance release of 10.4 was in
11/2007.  10.5 was released in 10/2007 and, with subsequent update
releases, remains the current system.  While no release dates have  
been

announced, 10.6 (Snow Leopard) is rumored to be nearing release.  If
Apple follows past practices, they will likely terminate all support  
for
10.4 (release n-2) when 10.6 releases and will continue to support  
10.5

(n-1) for the lifetime of 10.6.  Needless to say, Apple stopped
supporting 10.3 a long time ago and, if 10.6 does release in the not
too-distant future, 10.4's days are numbered.


It's not just what Apple supports though, there's also the question of  
what

people actually use.

That said, unless anyone wants to step in to support 10.3 systems I'm in
favour of completely dropping 10.3 support in the binary installers. The
reason for that is twofold: first of all 10.3 is ancient, and more  
importantly

I no longer have access to hardware that will run 10.3 and can therefore
no longer test if 10.3 support actually works.



What does this mean for Python?  To date, there have been no official
3.0 OS X installers released.  Because of the deficiencies of building
for the long-unsupported 10.3 (the distutils bug, the lack of 64-bit
support, and probably other things I'm not aware of), I think it is  
very

important that the 3.0.1 get off on the right foot by changing the
minimum supported versions now.


I see three plausible options:

1. Release an installer built for 10.5 and higher.
  pros: delivers 32-support and 64-support;
  cons: prematurely disenfranchises 10.4 users

2. Release an installer built for 10.4 and higher.
  pros: one size fits all
  cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc

3. Release two installers, one each for 10.4+ and 10.5+.
   pros: supports current and future systems;
  delivers 64-support to 10.

Re: [Python-Dev] Small misleadingness in docs

[Terry Reedy]

Greg Ewing wrote:

Georg Brandl wrote:

Since I cannot imagine a scenario where you would want to have 
non-classes

as the arguments of issubclass(),


I had one today, which is what led me to discover this.
I'm working on a Python-Ruby bridge that wraps Ruby
objects and classes in Python objects.

I wanted to make isinstance() and issubclass() work in
the expected way when applied to wrappers around Ruby
classes. The ability to fake things using __classes__
and __bases__ turned out to be very handy.


The new (in 3.0 and maybe 2.6, but undocumented) special methods 
__instancecheck__ and __subclasscheck__ let one overload the default 
behavior of isinstance and issubclass.  So there is no reason to have 
the default behavior necessarily cover 'unusual' cases.  See

http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass
and http://bugs.python.org/issue5250.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 3.0.1

[Ronald Oussoren]

On 14 Feb, 2009, at 9:55, Martin v. Löwis wrote:


Any chance of getting a Mac installer for this one?


Chances are non-zero, yes.



I had hoped to build one last night, but got home way later than I had  
planned. The installer is building as I type this.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Irix still supported? (was Re: Tracker archeology)

[Terry Reedy]

Can http://bugs.python.org/issue995458
"Does not build selected SGI specific modules"be closed?

PEP11 lists Irix 4 as gone.  What about Irix 6?
http://www.python.org/dev/peps/pep-0011/

Pep3108 notes that IRIX is no longer produced as of Dec 2006 and that 
Irix specific modules are gone from Py3.

http://www.python.org/dev/peps/pep-3108/#irix
Does Py3 still have Irix 6 support?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Guido van Rossum]

On Sat, Feb 14, 2009 at 3:54 AM, Stephen J. Turnbull  wrote:
> I would suppose most folks who are running 10.4 even today are "cranks
> like me, baby, we were born to fuss!"  Ahem, anyway, I suspect
> people who care that much about stability are generally old-school
> types who are willing to roll their own to some extent.

Actually I expect that to be fairly common among people who are not so
much into technology, strapped for funds but appreciative of quality,
bought an expensive Mac once expecting it would last a long time, and
are hanging on to it until it dies (which could be a long time). Their
hardware may not support newer OS X versions.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 3.0.1

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 13, 2009, at 11:46 PM, Benjamin Kaplan wrote:


Any chance of getting a Mac installer for this one?


I believe Ronald is planning to upload it soon.
Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZbWDHEjvBPtnXfVAQJNOQQAl89fJc7ezmpaDlClehtFJTwX5xE7JAtD
yZ47O9yUOQfdIem2l1VVApHnsnUmLKILYG3v4MHiWJBjOT10Oxjc4JKlV3nmREda
aUYOHCk1aHrPgdLHS4Cb/NBA6uYoG/+fHBcEMujClxv30lUTj76kDcjIMlflcpu6
r9I/jJdYywg=
=nyT7
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The fate of 3.0.*

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 13, 2009, at 10:02 PM, Guido van Rossum wrote:


Amen. I can see two scenarios where we might release 3.0.2: (a) if we
find a really severe error in 3.0.1 (or perhaps a security problem);
(b) if 3.1 ends up getting delayed severely.

In case (a) happens it's okay if the 3.0 branch is left alone until
the time we need to make that one patch. The probability of (b) is
low, so let's worry about that when it happens, and let's try not to
make it happen. :-)


That's more than fine with me! :)

Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZbVYnEjvBPtnXfVAQKVxgP+NFpKibfYS5cjk68H/ImTYydGX82skFzP
vtKNEvJeYdLg+WCpC88W9mL8jqBiG4yyKIXXF2hlVkX74tZbR3FU+V1EbXSvC46d
rO5ZzFWMaVW/qrxepeY2tAiUCr82CVD1b6W8E0IAms7UjUKBPS9n2fYKsWOGEQph
1pLbdp7CBek=
=j0yP
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

> But no way to share aggregated search results (I've sent some
> off-list), 'follow' users (i.e., be added as nosy for issues where
> user A is nosy), auto-add as nosy based on keywords, etc. Someday we
> could have these nosy features hosted externally, e.g. as an AppEngine
> app that subscribes to python-bugs and sends alerts to users matching
> the message (by keyword, performed action, new stage, etc.).

Please, please, no. If you can add it to an external application,
please, pretty pretty please, add it to roundup directly (or, rather,
to this specific tracker).

> 
>>> Right now, more efficient searching and aggregation along with some
>>> (local, flexible) UI tweaks sum it up.
>> Efficient in what way?
> 
> Having those complex searches in a less convoluted workflow, allowing
> more work to be done faster and in a less error prone way.

If it's useful to you, it might be useful to others as well. So consider
contributing free-form searches to roundup (in addition to form-based
searches).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Martin v. Löwis]

> (This may well have 
> been discussed before so my apologies if I am covering old ground here.)

There might have been discussions on pythonmac lists, but no recent ones
on python-dev, AFAIR.

> The last Apple point release of 10.3 was in 4/2005.  10.4 was also 
> released then. [...]  Needless to say, Apple stopped 
> supporting 10.3 a long time ago and, if 10.6 does release in the not 
> too-distant future, 10.4's days are numbered.

I think this is a matter of personal judgment. If there has been a point
release as recent as three years ago, I wouldn't call that "long ago".
People often continue to use operating systems 10 years after the vendor
stopped supporting it.

So I would personally think that it is desirable to continue supporting
10.3 if possible. For comparison, the Python Windows binaries support
systems back to Windows 2000, but not anymore the non-NT systems (ie.
Windows 95, Windows 98, Windows ME).

> 1. Release an installer built for 10.5 and higher.
>pros: delivers 32-support and 64-support;
>cons: prematurely disenfranchises 10.4 users

I don't think this should be done.

> 2. Release an installer built for 10.4 and higher.
>pros: one size fits all
>cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc

Why is it that such an installer couldn't include 64-bit support?
Wouldn't 10.4 just ignore architectures it doesn't know about?
Also, didn't 10.4 already support ppc64?

> 3. Release two installers, one each for 10.4+ and 10.5+.
> pros: supports current and future systems;
>delivers 64-support to 10.5+ users;
>could choose to drop 10.4 installers anytime after 10.6 
>releases;
> cons: some extra work to build/release
>  (but not much and not often);
>  others??

I don't think this should be done, either. The whole point of
"universal" binaries is that it simplifies choice for end users.

> With the improvements to the build process and the experience I've had 
> so far, I would strongly recommend option 3.  I am willing to commit to 
> supplying those images for 3.0.1 and beyond until we can get to a more 
> automated process.  Or I'd be happy to work with someone else to make it 
> happen for 3.0.1.  Now that the tarball is out, I will be able to get 
> the images built and tested this weekend.

Ultimately, this is for the port maintainer to decide (IMO), which is
still Ronald Oussouren. If he passes this role on to you, it would be
all fine with me, and you could do with the port whatever you please
(even though I might still dislike the additional clutter of two OSX
installers)

> So, to summarize, I will build and test installer images for 3.0.1 built 
> for 10.4+ and for 10.5+ and will make them available, if there is 
> interest.  If someone else is planning on making official installer(s), 
> I'd be happy to pass along my experiences so far.  In any case, I 
> strongly urge that the minimum support level be 10.4.

I still wish there were 10.3+ installers that also include 64-bit code.
I don't get it why that can't be technically possible.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Small misleadingness in docs

[Greg Ewing]

Georg Brandl wrote:


Since I cannot imagine a scenario where you would want to have non-classes
as the arguments of issubclass(),


I had one today, which is what led me to discover this.
I'm working on a Python-Ruby bridge that wraps Ruby
objects and classes in Python objects.

I wanted to make isinstance() and issubclass() work in
the expected way when applied to wrappers around Ruby
classes. The ability to fake things using __classes__
and __bases__ turned out to be very handy.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OS X Installer for 3.0.1 and supported versions

[Stephen J. Turnbull]

Ned Deily writes:

 > I see three plausible options:
 > 
 > 1. Release an installer built for 10.5 and higher.
 >pros: delivers 32-support and 64-support;
 >cons: prematurely disenfranchises 10.4 users

+0 This would bother me; I have a couple of older Macs that run 10.4.
But it's acceptable (I can always use MacPorts or build from source).
I would suppose most folks who are running 10.4 even today are "cranks
like me, baby, we were born to fuss!"  Ahem, anyway, I suspect
people who care that much about stability are generally old-school
types who are willing to roll their own to some extent.

 > 2. Release an installer built for 10.4 and higher.
 >pros: one size fits all
 >cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc

-1 I think if you're going to have a break, make it a big one.  By the
time people who use installers are using Python 3.0 a lot, most of
them will be on 10.6.

 > 3. Release two installers, one each for 10.4+ and 10.5+.
 > pros: supports current and future systems;
 >delivers 64-support to 10.5+ users;
 >could choose to drop 10.4 installers anytime after 10.6 
 >releases;
 > cons: some extra work to build/release
 >  (but not much and not often);

+1

 > work on futures.  And this same discussion and decision needs to be made 
 > going forward for 2.7 and 2.6.x (I think the change should be made for 
 > 2.6.2).

Generally my inclination is the same here, but the distinction between
options 2 and 3 is a little less extreme.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

Speaking of an OS X installer for 3.0.1, over the last few weeks I have 
been working on tidying up the OS X installer build process.  While the 
basic OS X build/installer process is good, some cruft has accumulated 
over the past years and a number of mostly minor issues arose due to the 
3.x split.  IMO, the most important issues were with IDLE and, thanks to 
Ronald, we did get the most important fixes for OS X IDLE checked-in in 
time for 3.0.1; they are also in py3k and will be going into trunk and 
26.  I have a few other fixes that apply just to the OSX build/installer 
parts which did not get submitted in time for the 3.0.1 cutoff but which 
are ready to go for 3.x and 2.x.  Basically they fix some version number 
updating and ensure that the installer image will be built reproducibly 
in a clean environment so there is no contamination of the installer 
images.  Currently, that's easy to do as happened with the first round 
of the OS X 2.6 installer (e.g. with a locally installed Tcl/Tk).  They 
also allow images to build for various OS X version.  More on that below.

I would like to get to the point where the OS X images can be generated 
and tested automatically.  I think that is reasonable and achievable.  
It's not quite there yet but I can now semi-automatically produce images 
for 2.6, 2.7 (trunk), 3.0, and 3.1 (py3k) in both the traditional "fat" 
(32-bit i386) for 10.4/10.5 and, for 10.5, "universal" (4-way 32-bit and 
64-bit intel/ppc).  They all have been passing the standard regrtest 
with no new obvious (to me) regressions but I certainly won't claim to 
have done complete and thorough testing.  (In particular, I have no 
access to a G5 for 64-bit PPC testing.)

However the "official" OS X images are built, there is an important 
issue about them that should be addressed now.   That issue is which OS 
X versions should be supported by installer images.  (This may well have 
been discussed before so my apologies if I am covering old ground here.)

Some background: OS X 10.4 (Tiger) introduced 2-way ("fat") executables 
and libraries which include object code for both ppc and i386 in the 
same files.  OS X 10.5 (Leopard) extended that support to 4-way 
("universal"), adding 64-bit x86_64 and ppc64.  In 10.5, much, but not 
all, of OS X and a growing number of applications are shipped as 4-way 
universal.  The OS X developer tools include SDKs to allow cross-builds 
for various OS X levels and architectures.  There is a build-time 
environ variable, MACOSX_DEPLOYMENT_TARGET, which specifies the minimum 
OSX releases that an executable will work with. 

Starting in 2006, the 2.5.x series of Python OS X installers were 
released as "fat" but built with MACOSX_DEPLOYMENT_TARGET=10.3 so that 
the same installer image would work on 10.3 PPC and 10.4 PPC and intel.   
Unfortunately, along the way, there was a significant bug in 
distutils.util.get_platform not returning "fat" in the platform string; 
among other things this has had impact on packages on PyPI.  Ronald 
fixed the problem prior to 2.5.2 (?) but, for compatibility, the fix is 
only effective if MACOSX_DEPLOYMENT_TARGET >= 10.4 and the 2.5.x 
installers continued to be built as 10.3.  Also unfortunately, the 
deployment target for the first 2.6 OS X installer was not updated.  In 
the meantime, Ronald added support for 64-bit and 4-way universal builds 
for 10.5 but, to date, no official installer images have been released 
with that enabled although clearly people are already building their own 
64-bit OS X pythons.

The last Apple point release of 10.3 was in 4/2005.  10.4 was also 
released then.  The last Apple maintenance release of 10.4 was in 
11/2007.  10.5 was released in 10/2007 and, with subsequent update 
releases, remains the current system.  While no release dates have been 
announced, 10.6 (Snow Leopard) is rumored to be nearing release.  If 
Apple follows past practices, they will likely terminate all support for 
10.4 (release n-2) when 10.6 releases and will continue to support 10.5 
(n-1) for the lifetime of 10.6.  Needless to say, Apple stopped 
supporting 10.3 a long time ago and, if 10.6 does release in the not 
too-distant future, 10.4's days are numbered.

What does this mean for Python?  To date, there have been no official 
3.0 OS X installers released.  Because of the deficiencies of building 
for the long-unsupported 10.3 (the distutils bug, the lack of 64-bit 
support, and probably other things I'm not aware of), I think it is very 
important that the 3.0.1 get off on the right foot by changing the 
minimum supported versions now.

I see three plausible options:

1. Release an installer built for 10.5 and higher.
   pros: delivers 32-support and 64-support;
   cons: prematurely disenfranchises 10.4 users

2. Release an installer built for 10.4 and higher.
   pros: one size fits all
   cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc

3. Release two installers, one each for 10.4+ and 

Re: [Python-Dev] The fate of 3.0.*

[Martin v. Löwis]

Benjamin Peterson wrote:
> Are we going to keep developing the 3.0 maintenance branch in
> expectation of releasing 3.0.2 sometime or will we just focus our
> efforts on 3.1?

Traditionally, we had one last bugfix release after then next feature
release. So I think we should release 3.0.2 right after 3.1 gets
releases, and then close the branch for bug fixes.

As a consequence, we should continue to backport bug fixes to the
3.0 maintenance branch.

Another issue is security releases. For regular releases, I'm still
proposing that we provide security fixes up to five (5) years after
the original release, which would be until 2014. We need to decide
whether to do that for 3.0 as well, and, if not, announce in the
final release that it is really final.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 3.0.1

[Martin v. Löwis]

> Any chance of getting a Mac installer for this one?

Chances are non-zero, yes.

Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Small misleadingness in docs

[Georg Brandl]

Raymond Hettinger schrieb:
> [Greg Ewing]
>> I've discovered something slightly misleading in the docs
>> for PyObject_IsInstance:
>>
>>   When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
>>   returns true. If A and B are different objects, B's __bases__
>>   attribute is searched...
>>
>> This suggests that issubclass(A, A) will always be true,
>> regardless of what attributes A has. However, this turns
>> out not to be so -- A must also have a __bases__ attribute,
>> otherwise it's rejected as not being sufficiently class-like.
> 
> This smells like a bug that brings issubclass() out of sync with isinstance().
> Perhaps issubclass() should do what the docs say and start by
> testing whether A and B are the same object.

Since I cannot imagine a scenario where you would want to have non-classes
as the arguments of issubclass(), making sure that both *are* classes
sounds like a good idea to prevent bugs.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com