2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>:
> Martin suggests, and I agree, that we should release Python 3.0 final and
> 2.6.1 at the same time. Makes sense to me. That would mean that Python
> 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!).
2.6.1 only two months after 2
Facundo Batista wrote:
> 2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>:
>
>> Martin suggests, and I agree, that we should release Python 3.0 final and
>> 2.6.1 at the same time. Makes sense to me. That would mean that Python
>> 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!).
Le Tuesday 18 November 2008 11:03:02 Facundo Batista, vous avez écrit :
> 2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>:
> > Martin suggests, and I agree, that we should release Python 3.0 final and
> > 2.6.1 at the same time. Makes sense to me. That would mean that Python
> > 2.6.1 should be ready
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin suggests, and I agree, that we should release Python 3.0 final
and 2.6.1 at the same time. Makes sense to me. That would mean that
Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready
then!).
Should w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 18, 2008, at 5:03 AM, Facundo Batista wrote:
2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>:
Martin suggests, and I agree, that we should release Python 3.0
final and
2.6.1 at the same time. Makes sense to me. That would mean that
Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 18, 2008, at 8:07 AM, Christian Heimes wrote:
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin suggests, and I agree, that we should release Python 3.0
final and 2.6.1 at the same time. Makes sense to me. That wou
Hello ,
I'm not really a programmer but I am working to be one
I just thought may be this is worth considering for future enhancement
with python's range
I've you considered trying out something of these nature with range:
/>>> 900 in range(20**30)/
you'll have to wait for sometime to get a
Barry Warsaw wrote:
Actually, I've wanted to do timed releases, though I think monthly is
unrealistic. Maybe every two months is about the right time frame.
Timed releases are nice because everybody then knows when a patch is
due, from developers to downstream consumers.
From my point of vi
Hello,
You're using range objects in ways that were hardly intended. If range objects
had to be magically smart about everything, the language would be slower
overall just to enable a questionable use case.
Plain comparison operators and isinstance or type checks against int will make
your lif
On Tue, 18 Nov 2008 16:01:35 +0100, Owolabi Abdulkareem wrote:
> I just thought may be this is worth considering for future enhancement
> with python's range
>
> I've you considered trying out something of these nature with range:
>
> />>> 900 in range(20**30)/
>
> you'll have to wait for s
Attached program works with
callback = GSL_FUNCTION(self.f)
set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
But core dumps with
set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)
I do not understand the difference. Must be one of these possibilities
Lambert, David W (S&T) wrote:
Attached program works with
callback = GSL_FUNCTION(self.f)
set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
But core dumps with
set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)
I had to change your module a bit to lo
Core dumps generated using ctypes are not covered by the warrantee. ;-)
On Tue, Nov 18, 2008 at 12:26 PM, Lambert, David W (S&T)
<[EMAIL PROTECTED]> wrote:
>
> Attached program works with
>
>callback = GSL_FUNCTION(self.f)
>set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
>
> B
Guido van Rossum wrote:
> Core dumps generated using ctypes are not covered by the warrantee. ;-)
True, although it's a little bizarre that the version with the temporary
variable works, but the one without it doesn't.
Then again, the temp variable does change the timing on the Python side
as wel
>> Should we release 2.6.1rc1, too?
>
> Do we need rc's for point releases?
We have been doing them in the past, a week before the release.
In this case, I could accept a waiver, given that the previous
release acts very well as a release candidate for this release.
Regards,
Martin
> From my point of view bi-monthly release are too much. For a ?.?.1
> release two months are fine because several issues are found by 3rd
> party authors. But after that a release every quarter is sufficient.
>
> * .1 release two months after the .0 release
> * .2, .3, .4 and .5 release every qua
"Martin v. Löwis" writes:
> While I'm happy that Barry has automated his part to a high degree,
> my part is, unfortunately, much less automated. I could personally
> automate the build process a bit more, but part of it is also testing
> of the installers, which is manual.
Maybe you could de
Seconded. I tried Python 3K for the first time this weekend, spent a
few hours with the 2to3 tool and we have 80% of SQLAlchemy unit tests
passing on 3.0 now. It was far easier than I'd hoped, and the
decisions made in PY3K make perfect sense to me. Its a better
language and I think it
> > While I'm happy that Barry has automated his part to a high degree,
> > my part is, unfortunately, much less automated. I could personally
> > automate the build process a bit more, but part of it is also testing
> > of the installers, which is manual.
>
> Maybe you could delegate a lot of
"Martin v. Löwis" writes:
> That's not the issue - I don't mind spending that time. However, it
> means that several hours pass between starting the release process,
> and making the binaries available - during this time, users always
> complain why the Windows binaries are not released yet.
20 matches
Mail list logo
