[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
<[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 :).
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
"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
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
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
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
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:
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
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
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
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
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 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
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
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
>
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
[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
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
>
[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 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
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
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
>> 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
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
"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
>> 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
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
>> 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
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
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.
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
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
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
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
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
[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 <[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
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:
>
> > 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
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
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
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
43 matches
Mail list logo
