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 top
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 l
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
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
> 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
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,
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
>
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'v
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
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, bu
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
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
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 sam
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 th
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
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://bug
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://
> 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 U
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
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 arc
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
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
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/M
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.
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
-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)
iQCVAwUBSZbWDHEjvBPtnXfVA
-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
> 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
> (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 t
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
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 acceptabl
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 spl
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 aft
> 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/
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 search
35 matches
Mail list logo