"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.
> > 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
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
"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
> 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
>> 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
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
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
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
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
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
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
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 ,
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
-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
-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
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
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
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!).
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
20 matches
Mail list logo
