Tennessee Leeuwenburg writes:
> Can I ask if there's any sense in pursuing a release schedule which
> is slow for whatever might be deemed the "most core modules" but
> faster for "less core modules"?
I think you need to be more specific about how many levels of "fast"
there should be, and why
On Wed, May 13, 2009 at 1:26 PM, "Martin v. Löwis" wrote:
> > Just food for thought here, but seeing how 3.1 is going to be a real
> featureful
> > schedule despite being released shortly after 3.0, wouldn't it make sense
> to
> > tighten future release planning a little?
>
> Do you have any speci
Antoine Pitrou writes:
> Just food for thought here, but seeing how 3.1 is going to be a
> real featureful schedule despite being released shortly after 3.0,
> wouldn't it make sense to tighten future release planning a little?
With all due respect, it's easy and natural to have a short,
featu
2009/5/12 Robert Brewer :
> There's a major change in functionality in the cgi module between Python
> 2 and Python 3 which I've just run across: the behavior of
> FieldStorage.read_multi, specifically when an HTTP app accepts a file
> upload within a multipart/form-data payload.
>
> In Python 2, e
MRAB wrote:
Next you'll be saying that they should be named after years. Python
2010, anyone? :-)
To keep people on their toes, we should switch to a
completely random new naming scheme with every release,
like Microsoft has been doing with Windows.
--
Greg
___
Graham Dumpleton wrote:
> 2009/5/12 Robert Brewer :
> > There's a major change in functionality in the cgi module between
> Python
> > 2 and Python 3 which I've just run across: the behavior of
> > FieldStorage.read_multi, specifically when an HTTP app accepts a file
> > upload within a multipart/f
> Just food for thought here, but seeing how 3.1 is going to be a real
> featureful
> schedule despite being released shortly after 3.0, wouldn't it make sense to
> tighten future release planning a little?
Do you have any specific releases in mind that you would like to apply
such a tightened sc
On Tue, May 12, 2009 at 3:06 PM, Antoine Pitrou wrote:
> Hello,
>
> Just food for thought here, but seeing how 3.1 is going to be a real
> featureful
> schedule despite being released shortly after 3.0, wouldn't it make sense to
> tighten future release planning a little? I was thinking something
On May 12, 2009, at 6:06 PM, Antoine Pitrou wrote:
Just food for thought here, but seeing how 3.1 is going to be a real
featureful
schedule despite being released shortly after 3.0, wouldn't it make
sense to
tighten future release planning a little? I was thinking something
like doing a
ma
MRAB mrabarnett.plus.com> writes:
> Next you'll be saying that they should be named after years. Python
> 2010, anyone?
After py3k, that would be a regression ;)
cheers
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Antoine Pitrou wrote:
Hello,
Just food for thought here, but seeing how 3.1 is going to be a real featureful
schedule despite being released shortly after 3.0, wouldn't it make sense to
tighten future release planning a little? I was thinking something like doing a
major release every 12 months
Hello,
Just food for thought here, but seeing how 3.1 is going to be a real featureful
schedule despite being released shortly after 3.0, wouldn't it make sense to
tighten future release planning a little? I was thinking something like doing a
major release every 12 months (rather than 18 to 24 mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou napsal(a):
> Hello,
>
> I don't think it has already posted to the list, apologies if it has.
>
> Some Linux tools and vendors have been hit by an alleged "security hole" where
> an embedded Python interpreter will prepend the curren
On May 11, 2009, at 1:29 PM, Jeroen Ruigrok van der Werven wrote:
-On [20090511 14:47], Aahz (a...@pythoncraft.com) wrote:
On Monday 2009-05-11, mail.python.org will be switched to another
machine
starting roughly at 14:00 UTC. This should be invisible (expected
downtime is less than ten min
-On [20090512 18:41], Barry Warsaw (ba...@python.org) wrote:
>Somehow, personalization got turned off for python-checkins. This
>disables VERPing of the headers. I've turned it back on, so please
>let me know if that fixes the issue. This did not appear to happen
>si
On Tue, May 12, 2009 05:27 PM, Collin Winter wrote:
> On Tue, May 12, 2009 at 4:45 AM, Cesare Di Mauro
> wrote:
>> Another note. Fredrik Johansson let me note just few minutes ago that
>> I've
>> compiled my sources without PGO optimizations enabled.
>>
>> That's because I used Visual Studio Expre
On Tue, May 12, 2009 at 4:45 AM, Cesare Di Mauro
wrote:
> Another note. Fredrik Johansson let me note just few minutes ago that I've
> compiled my sources without PGO optimizations enabled.
>
> That's because I used Visual Studio Express Edition.
>
> So another gain in performances can be obtained
On Thu, May 12, 2009 01:40PM, Antoine Pitrou wrote:
>
> Hi Cesare,
>
> Cesare Di Mauro a-tono.com> writes:
>>
>> It was my idea too, but first I need to take a deep look at what parts
>> of code are changed from 2.6 to 3.0.
>> That's because I don't know how much work is required for this
>> "forw
Hi Cesare,
Cesare Di Mauro a-tono.com> writes:
>
> It was my idea too, but first I need to take a deep look at what parts
> of code are changed from 2.6 to 3.0.
> That's because I don't know how much work is required for this
> "forward" port.
If you have some questions or need some help, send
19 matches
Mail list logo
