Neal Norwitz wrote:
> This is the part I don't get. For the external developers, if they
> care about compatibility, why aren't they testing periodically,
> regardless of alpha/beta releases?
because they don't want to waste time and effort on testing against
releases that are not necessarily a
On Friday 14 July 2006 17:00, Fredrik Lundh wrote:
> because they don't want to waste time and effort on testing against
> releases that are not necessarily a close approximation of the full
> release? testing takes time, and time can be used for many
> different things.
Oddly enough, so does rel
On Friday 14 July 2006 16:39, Neal Norwitz wrote:
> Remember I also tried to push for more features to go in early?
> That would have given more time for external testing. Still
> features are coming in. Python developers weren't happy about
> having to get things in earlier. I don't see a prac
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > On systems that are not Unix-derived (which, nowadays, are rare),
> > there is commonly no such thing as a program name in the first place.
> > It is possible to get into that state on some Unices - i.e. ones which
> > have a form of exec that takes a fi
Nick Maclaren wrote:
>> I don't think that applies to the Python args[] though,
>> since its args[0] isn't the path of the OS-level
>> executable, it's the path of the main Python script.
>
> Oh, yes, it does! The file descriptor or inode number could refer to
> the script just as well as it cou
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> "from __future__ import new_classes" exists, but the syntax is
>> different:
>>
>> __metaclass__ = type
>
> Although it's not a very obvious spelling,
> particularly to the casual reader who may not be
> familiar with the intricacies of classes and
> meta
[EMAIL PROTECTED] writes:
> I just would have appreciated the opportunity to participate in the
> discussion before the betas were out and the featureset frozen.
I think something that has happened to some extent with this release
is that there was a long-ish period where stuff got discussed and
Greg Ewing wrote:
> Nick Maclaren wrote:
>> On systems that are not Unix-derived (which, nowadays, are rare),
>> there is commonly no such thing as a program name in the first place.
>> It is possible to get into that state on some Unices - i.e. ones which
>> have a form of exec that takes a file d
I have posted the following message to idle-dev,
but no reply yet. Just a suggestion:
The firewall warning message in the Pythonshell window
was introduced in Python 2.3 (IDLE 1.0 or something similar?)
I remember well the problems, to which it was the answer.
(If I remember correctly I was inv
Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> a longer beta period gives *external* developers more time to catch
>> up, and results in less work for the end users.
>
> This is the part I don't get. For the external developers, if they
> care about compatibility, why aren't they testing periodically
Greg Ewing wrote:
> Maybe sys needs to be split into two modules, with
> the non-sensitive one pre-imported (so that the
> importless interpreter you suggest wouldn't be
> unnecessarily crippled).
Maybe not splitting it, but providing a read-only mechanism of getting at
certain elements, with "im
Anthony Baxter wrote:
> On Friday 14 July 2006 16:39, Neal Norwitz wrote:
>> Remember I also tried to push for more features to go in early?
>> That would have given more time for external testing. Still
>> features are coming in. Python developers weren't happy about
>> having to get things in
Gregor Lingl wrote:
> I have posted the following message to idle-dev,
> but no reply yet. Just a suggestion:
>
> The firewall warning message in the Pythonshell window
> was introduced in Python 2.3 (IDLE 1.0 or something similar?)
>
> I remember well the problems, to which it was the answer.
On Fri, Jul 14, 2006 at 12:00:07PM +0200, Giovanni Bajo wrote:
> unstable or whatnot. There is no official statement of the kind "all
> the real development is done in branches, the trunk is always very
> stable, feel free to grab it". Thus, we (external developers) assume
> that it's better to wai
>> If you're concerned about noticing when a new release train is
>> pulling out of the station ...
glyph> I am aware of when new releases come out :). What I'm not aware
glyph> of is what features (may) have broken my code, and why.
Hmmm... Well, you could subscribe to the p
Greg> Maybe there could be an "unstable" release phase that lasts for a
Greg> whole release cycle. So you'd first release version 2.n as
Greg> "unstable", and keep 2.(n-1) as the current "stable" release. Then
Greg> when 2.(n+1) is ready, 2.n would become "stable" and 2.(n+1) would
>> I believe there was some shortening of the 2.5 release cycle two or
>> three months ago.
Fred> The squeezing of the releases isn't where the problem is, I think.
Had we been in alpha a bit longer (officially before feature freeze) I think
there'd have been less back-and-forth abou
"A.M. Kuchling" wrote:
>> While the new python.org is very nice, I do note that there's no "blogs"
>> entry on the front page, something which has become a fixture on almost
>> every other website I visit regularly.
>
> A 'Blogs' link could be trivially added by linking to
> planet.python.org, thou
Neal> How often is the python build broken or otherwise unusable?
Not very often. I use the head branch of the repository as the source of
the interpreter I run on my laptop. It generally takes just a couple
minutes on my now-aging PowerBook to svn up and reinstall. I can only
recall one
>> This is the part I don't get. For the external developers, if they
>> care about compatibility, why aren't they testing periodically,
>> regardless of alpha/beta releases?
Fredrik> because they don't want to waste time and effort on testing
Fredrik> against releases that a
Guido van Rossum wrote:
...
>
> This is an illustration of the dilemma of maintaining a popular
> language: Everybody hates change (me too!) but everybody also has one
> thing that's bothering them so much they absolutely want it to be
> changed. If you were to implement all those personal pet pee
On 7/14/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Friday 14 July 2006 16:39, Neal Norwitz wrote:
> > Remember I also tried to push for more features to go in early?
> > That would have given more time for external testing. Still
> > features are coming in. Python developers weren't happy
On 7/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Anthony Baxter wrote:
> > On Friday 14 July 2006 16:39, Neal Norwitz wrote:
> >> Remember I also tried to push for more features to go in early?
> >> That would have given more time for external testing. Still
> >> features are coming in. Pyth
[EMAIL PROTECTED] wrote:
> Greg> Maybe there could be an "unstable" release phase that lasts
> for a Greg> whole release cycle. So you'd first release version
> 2.n as Greg> "unstable", and keep 2.(n-1) as the current "stable"
> release. Then Greg> when 2.(n+1) is ready, 2.n would
On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
> (add PEP announcements and python-dev summary items to the mix, and you
> have a high-quality development blog generated entirely from existing content)
> (hmm. maybe this could be put together by a robot? time to start hacking on
>
[Fredrik Lundh]
def counter(num):
num = mutable_int(num)
def inc():
num += 1
return num
return inc
>>
>> feel free to replace that += with an .add(1) method call; the point
>> wasn't the behaviour of
Pierre Baillargeon schrieb:
> Currently, many 64-bits Oses cannot uses the dlmodule due to the conflicts
> between the sizes of int, long and char *. That is well. The check is made as
> run-time, which is also very well.
>
> The problem is that the Python configuration script (setup.py) also make
Jeremy Hylton wrote:
>> When the slave suffers a real failure due to a backwards
>> incompatibility, it
>> will take a developer of the application to figure out what it was
>> that broke
>> the application's tests.
>>
>> So while I think it's a great idea, I also think it will need significant
>
On Fri, 14 Jul 2006 06:46:55 -0500, [EMAIL PROTECTED] wrote:
>
>Neal> How often is the python build broken or otherwise unusable?
>
>Not very often.
I have to agree. The effort I'm talking about is not in fixing large numbers
of problems, but simply gearing up to properly test to see if there
On Thu, 13 Jul 2006 23:39:06 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>On 7/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> a longer beta period gives *external* developers more time to catch up,
>> and results in less work for the end users.
>This is the part I don't get. For the exter
Gregor Lingl <[EMAIL PROTECTED]> wrote:
> I have posted the following message to idle-dev,
> but no reply yet. Just a suggestion:
>
> The firewall warning message in the Pythonshell window
> was introduced in Python 2.3 (IDLE 1.0 or something similar?)
Speaking of 'features that would have been
On 7/14/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
> > (add PEP announcements and python-dev summary items to the mix, and you
> > have a high-quality development blog generated entirely from existing
> > content)
> > (hmm. maybe
You must be misunderstanding. The root problem is that people
(rightly) complain that the language changes too much. And you want to
"fix" this by adding a deep and fundamental change to the language?
What planet are you from? It reminds me of Jini, which was presented
as a new standard to address
Whoa, whoa. What's the *problem* we're trying to solve here?
On 7/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Maybe sys needs to be split into two modules, with
> > the non-sensitive one pre-imported (so that the
> > importless interpreter you suggest wouldn't be
> > unn
On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Whoa, whoa. What's the *problem* we're trying to solve here?I have a use case for sandboxing. I am already having to plan to have a mini-sys module in a sandbox so that they cannot get access to dangerous things.
-BrettOn 7/14/06, Nick Coghla
On 7/14/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Whoa, whoa. What's the *problem* we're trying to solve here?
>
> I have a use case for sandboxing. I am already having to plan to have a
> mini-sys module in a sandbox so that they can
On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/14/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > Whoa, whoa. What's the *problem* we're trying to solve here?
>> I have a use case for sandboxing. I am already having to plan to h
Christopher Armstrong wrote:
> python -U is a failure for obvious reasons and a
> __future__ import is clearly better.
I disagree.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
Christopher Armstrong wrote:
> I'm at least willing to set up the buildbots for projects I care about
> (Twisted, pydoctor, whatever), and perhaps help out with the setting
> up the buildmaster.
If you need trigger calls from subversion's post-commit hooks, please
let me know, and I can set them u
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> http://www.python.org/dev/tools/, in a discussion of checkin policies,
> does say:
>
> The Python source tree is managed for stability, meaning that
> if you make a checkout at a random point in time the tree will almos
On Fri, 14 Jul 2006 23:38:52 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Christopher Armstrong wrote:
>> python -U is a failure for obvious reasons and a
>> __future__ import is clearly better.
>
>I disagree.
I am surprised that you do, since I thought that Chris's conclusion was
pr
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, 13 Jul 2006 23:27:56 -0500, [EMAIL PROTECTED] wrote:
>
>>The buildbot idea sounds excellent.
>
> Thanks. If someone can set this up, it pretty much addresses my
> concerns.
> ...
> I am aware of when new releases come out :).
[EMAIL PROTECTED] wrote:
> A __future__ import would allow these behaviors to be upgraded
> module-by-module.
No it wouldn't.
__future__ works solely on the semantics of different pieces of syntax,
because any syntax changes are purely local to the current module. This
doesn't work for datatyp
43 matches
Mail list logo
