Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Arfrever Frehtes Taifersar Arahesis 
2009-11-02 21:00 Benjamin Peterson  napisał(a):
> I've updated PEP 373 with my proposed release schedule:
>
> - 2.7/3.2 alpha 1 2009-12-05
> - 2.7/3.2 alpha 2 2010-01-09
> - 2.7/3.2 alpha 3 2010-02-06
> - 2.7/3.2 alpha 4 2010-03-06
> - 2.7/3.2 beta 1 2010-04-03
> - 2.7/3.2 beta 2 2010-05-01
> - 2.7/3.2 rc1 2010-05-29
> - 2.7/3.2 rc2 2010-06-12
> - 2.7/3.2 final 2010-06-26

PEP 3003 states that Python 3.2 will be released 18-24 months after
Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
theoretically Python 3.2 should be released not before 2010-12-19 [2].

[1] http://python.org/download/releases/3.1/
[2] datetime.date(2009, 6, 27) + datetime.timedelta(18 * 30)

--
Arfrever Frehtes Taifersar Arahesis
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE as default Python editor

2009-11-10 Thread Nick Coghlan 
Martin v. Löwis wrote:
> Nick Coghlan wrote:
>> Ben Finney wrote:
>>> anatoly techtonik  writes:
>>>
 Quite an interesting question recently popped up in pygame community
 that I'd like to ask to Python developers.
>>> This forum is specifically about development *of* Python.
>> Anatoly's question is actually a fair one for python-dev - we're the
>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>> continuing to do so.
> 
> But he didn't - instead, he asked how many of us use it. Usage by
> committers is not (or shouldn't be) a primary criterion for including
> or not including something. Instead, usage in the community should be,
> and python-dev is indeed the wrong place to estimate that.

I took it as being a somewhat relevant leading question. If the response
had been "No, none of us use it" then the obvious follow-up question
would be "Why do you ship something that you don't consider worth using?".

I agree I was responding to a question that wasn't actually written in
the email though (and as I said in my other message, agree that it can't
be replaced without someone putting up a serious alternative for
consideration that ticks all the same boxes that IDLE currently ticks
and then offers significant improvements over and above that).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 83

2009-11-10 Thread wa2n39 
Unreg
--Pesan Asli--
Dari:[email protected]
Pengirim:[email protected]
Ke:[email protected]
Balas Ke:[email protected]
Perihal:Python-Dev Digest, Vol 76, Issue 83
Terkirim:10 Nov 2009 03:00

Send Python-Dev mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."


Today's Topics:

   1. Re: Retrieve an arbitrary element fromasetwithoutremoving it
  (Nick Coghlan)


--

Message: 1
Date: Tue, 10 Nov 2009 20:51:19 +1000
From: Nick Coghlan 
To: "Martin v. L?wis" 
Cc: [email protected]
Subject: Re: [Python-Dev] Retrieve an arbitrary element from
asetwithoutremoving it
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

Martin v. L?wis wrote:
>> I'm not sure, but isn't that thread-unsafe?
> 
> You are right; it's thread-unsafe.
> 
> I would fix it by catching the RuntimeError, and retrying. Given the
> current GIL strategy (including proposed changes to it), it won't happen
> two times in a row, so the number of retries would be bounded.

It's also one of the major reasons for not sharing mutable containers
between threads if you can avoid it (and serialising access to them if
you can't)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---


--

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev


End of Python-Dev Digest, Vol 76, Issue 83
**


Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from asetwithoutremoving it

2009-11-10 Thread Nick Coghlan 
Martin v. Löwis wrote:
>> I'm not sure, but isn't that thread-unsafe?
> 
> You are right; it's thread-unsafe.
> 
> I would fix it by catching the RuntimeError, and retrying. Given the
> current GIL strategy (including proposed changes to it), it won't happen
> two times in a row, so the number of retries would be bounded.

It's also one of the major reasons for not sharing mutable containers
between threads if you can avoid it (and serialising access to them if
you can't)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Nick Coghlan 
Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-11-02 21:00 Benjamin Peterson  napisał(a):
>> I've updated PEP 373 with my proposed release schedule:
>>
>> - 2.7/3.2 alpha 1 2009-12-05
>> - 2.7/3.2 alpha 2 2010-01-09
>> - 2.7/3.2 alpha 3 2010-02-06
>> - 2.7/3.2 alpha 4 2010-03-06
>> - 2.7/3.2 beta 1 2010-04-03
>> - 2.7/3.2 beta 2 2010-05-01
>> - 2.7/3.2 rc1 2010-05-29
>> - 2.7/3.2 rc2 2010-06-12
>> - 2.7/3.2 final 2010-06-26
> 
> PEP 3003 states that Python 3.2 will be released 18-24 months after
> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
> theoretically Python 3.2 should be released not before 2010-12-19 [2].

The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
should have been", so the starting point for the 18-24 month rule of
thumb is actually back when 3.0 was released in Dec 2008. This was
discussed a fair bit back when the decision was made to do the short
release cycle between 3.0 and 3.1 in order to address some of the more
glaring shortcomings of the 3.0 release.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from asetw ithoutremoving it

2009-11-10 Thread Antoine Pitrou 
Nick Coghlan  gmail.com> writes:
> 
> It's also one of the major reasons for not sharing mutable containers
> between threads if you can avoid it (and serialising access to them if
> you can't)

Not necessarily, for example it is common to rely on the fact that list.append()
is atomic.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenSSL vulnerability

2009-11-10 Thread Barry Warsaw 

On Nov 8, 2009, at 12:56 PM, Martin v. Löwis wrote:

Also, for Python 2.5 and earlier, any SSL-based code is vulnerable  
to a MitM
anyway, so this can only be an issue for code using the new APIs  
in Python

2.6.


That's not going to stop the
wannabe-self-proclaimed-so-called-vulnerability-"experts" from  
whining

about Python not releasing updated binary distributions though. :-(


The Windows binaries currently build with 0.9.8g. Since changing that
would be a source code change (even though just a single line), I  
think
a full source release would be necessary (most likely then for both  
2.6

and 3.1).


I don't think it's worth making a quick 2.6.5 release for this if it's  
primary intent is to produce new Windows binaries.  I'm okay with  
making the changes to the tree, but we'll release 2.6.5 on a "normal"  
schedule.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from asetwithoutremoving it

2009-11-10 Thread Nick Coghlan 
Antoine Pitrou wrote:
> Nick Coghlan  gmail.com> writes:
>> It's also one of the major reasons for not sharing mutable containers
>> between threads if you can avoid it (and serialising access to them if
>> you can't)
> 
> Not necessarily, for example it is common to rely on the fact that 
> list.append()
> is atomic.

s/"mutable
containers"/"mutable-containers-that-object-loudly-to-their-size-changing-during-iteration
-like-sets-and-dicts" :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenSSL vulnerability

2009-11-10 Thread Nick Coghlan 
Barry Warsaw wrote:
> I don't think it's worth making a quick 2.6.5 release for this if it's
> primary intent is to produce new Windows binaries.  I'm okay with making
> the changes to the tree, but we'll release 2.6.5 on a "normal" schedule.

Perhaps publish a source patch relative to 2.6.4 for people that would
like to rebuild their own Windows binaries with just that change?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenSSL vulnerability

2009-11-10 Thread Barry Warsaw 

On Nov 10, 2009, at 8:28 AM, Nick Coghlan wrote:


Barry Warsaw wrote:
I don't think it's worth making a quick 2.6.5 release for this if  
it's
primary intent is to produce new Windows binaries.  I'm okay with  
making
the changes to the tree, but we'll release 2.6.5 on a "normal"  
schedule.


Perhaps publish a source patch relative to 2.6.4 for people that would
like to rebuild their own Windows binaries with just that change?


+1.  A link to that could easily go on the 2.6.4 page.  Perhaps the  
right way to do it is to put the blessed patch in roundup and add a  
link to that patch file on the website.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Guido van Rossum 
On Tue, Nov 10, 2009 at 5:13 AM, Nick Coghlan  wrote:
> Arfrever Frehtes Taifersar Arahesis wrote:
>> 2009-11-02 21:00 Benjamin Peterson  napisał(a):
>>> I've updated PEP 373 with my proposed release schedule:
>>>
>>> - 2.7/3.2 alpha 1 2009-12-05
>>> - 2.7/3.2 alpha 2 2010-01-09
>>> - 2.7/3.2 alpha 3 2010-02-06
>>> - 2.7/3.2 alpha 4 2010-03-06
>>> - 2.7/3.2 beta 1 2010-04-03
>>> - 2.7/3.2 beta 2 2010-05-01
>>> - 2.7/3.2 rc1 2010-05-29
>>> - 2.7/3.2 rc2 2010-06-12
>>> - 2.7/3.2 final 2010-06-26
>>
>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>
> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
> should have been", so the starting point for the 18-24 month rule of
> thumb is actually back when 3.0 was released in Dec 2008. This was
> discussed a fair bit back when the decision was made to do the short
> release cycle between 3.0 and 3.1 in order to address some of the more
> glaring shortcomings of the 3.0 release.

Was this discussed somewhere? When I agreed to an early 3.1 release
(or did I propose it?) I'm quite sure that I expected 3.2 to come the
usual time (i.e., 18-24 months) after 3.1. I think I said something to
the extent of "we'll treat 3.1 the same way we treat any release"
which IMO implies a lifetime of 18-24 months.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Replacing IDLE

2009-11-10 Thread anatoly techtonik 
On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis"  wrote:
>>
>> Anatoly's question is actually a fair one for python-dev - we're the
>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>> continuing to do so.
>
> OTOH, the second (or, rather, third) question (does anybody think it
> should be replaced) is indeed on-topic for python-dev.

That is the exact question I have in my mind. Sorry for not being able
to state it clearly. I'll be more straightforward next time.

> I didn't really answer that question before, so I do now: I have not
> personally plans to replace it, and I'm skeptical wrt. anybody else's
> plans unless there is specific code in existence that IDLE could be
> replaced *with*.

There are a lot of Python editors. It is unlikely that they implement
all IDLE features, but I believe that 20% of IDLE features that is
used by 80% of users are guaranteed by any editor out of the box.
Assuming that they are more extensible than IDLE anyway. (I would say
"perfection is achieved when there is nothing more to add...", but I
promised to be straightforward).

If we filter list of http://wiki.python.org/moin/PythonEditors by
language/license/framework, we will be able to see if there is any
suitable open source Python code to replace IDLE's.


Then there will be another issue - all editors are based upon some
frameworks - I didn't see any popular cross-platform GUI toolkits in
Python, so we will inevitably face the need to replace Tkinter with
other default GUI toolkit.

Should we place an editor first and combine the list a of unique
features of IDLE that we (as developers) will surely miss  OR  should
we think what GUI framework will be more beneficial for Python users
if shipped by default (keeping in mind that we might have to add
missing features to whatever editor we choose later)?

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Ronald Oussoren 

On 10 Nov, 2009, at 17:20, anatoly techtonik wrote:

> On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis"  
> wrote:
>>> 
>>> Anatoly's question is actually a fair one for python-dev - we're the
>>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>>> continuing to do so.
>> 
>> OTOH, the second (or, rather, third) question (does anybody think it
>> should be replaced) is indeed on-topic for python-dev.
> 
> That is the exact question I have in my mind. Sorry for not being able
> to state it clearly. I'll be more straightforward next time.

What's so bad about IDLE that you'd like to replace it? The obvious alternative 
to replacing IDLE is to fix whatever is wrong with it. 

I sometimes use IDLE and it's not too bad as a simple Python editor.  A major 
reason for not using it more often is that the keystrokes for my prefered 
text-editor are in my muscle memory and IDLE is not that much of an improvement 
over my current habits that I'm willing the re-educate myself.

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Antoine Pitrou 
Guido van Rossum  python.org> writes:
> 
> Was this discussed somewhere?

I don't remember so, except for a short subthread on python-ideas where you
indeed mentioned (to my disappointment :-)) that you were against a one-year
release period.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Guido van Rossum 
On Tue, Nov 10, 2009 at 8:09 AM, Antoine Pitrou  wrote:
> Guido van Rossum  python.org> writes:
>>
>> Was this discussed somewhere?
>
> I don't remember so, except for a short subthread on python-ideas where you
> indeed mentioned (to my disappointment :-)) that you were against a one-year
> release period.

Trust me on this too, please. We used to have releases once a year and
we got really big serious feedback from our biggest users that the
release cycle was going too fast. We discussed it amply and agreed on
a minimum time of 18 months between releases. This was quite a while
ago (I recall it being somewhere between 2000 and 2004) but I don't
see that the situation has really changed -- if anything, we need to
slow down more. We should really have a PEP for this, like we do for
bugfix releases (PEP 6), but at the time we weren't so anal about PEPs
for process.

I realize this can be frustrating for developers who want to see their
code released. I had the same feeling at the time. But when it was
explained to me what a version upgrade looks like for a typical large
company who have 100,000 or more lines of Python, often with
insufficient tests, written by people who no longer work for the
company or expensive consultants, I realized that releasing once a
year was a break-neck pace for such users. There was wide discussion
and community agreement on the 18 months minimum, as a compromise
between the needs of large users (who would have been happier with two
years) and the desires of developers (who, like you, preferred shorter
release cycles).

I really don't think we should change this "contract with our users"
now. If necessary, we'll have to write a PEP to describe and explain
it.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] raw binary data and 2to3

2009-11-10 Thread Lennart Regebro 
2009/11/9 Benjamin Peterson :
> Not to my knowledge. I would prefer to not add a fixer for this
> directly to 2to3 because it is not correct for most programs. However,
> I think 2to3 should grow some sort of plugin system, so custom fixers
> can easily be written and used.

Well, 2to3 is only plugins, so. :) The difficulty in writing fixers is
understanding the abstract parse tree or whatever it's called and how
to use it. Documentation on that for people who don't have a doctorate
in computer linguistics would probably be a good idea. ;)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Raymond Hettinger 


[Guido van Rossum]

. We used to have releases once a year and
we got really big serious feedback from our biggest users that the
release cycle was going too fast. We discussed it amply and agreed on
a minimum time of 18 months between releases. 


If the language moratorium goes into effect, would shorter release cycles
still have a negative impact?  Do people possibly want slower changes
to the language and faster updates to the library?

I don't know the answer.  Just asking how this matches up with the
feedback you have gotten previously.


Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Raymond Hettinger wrote:
> [Guido van Rossum]
>> . We used to have releases once a year and
>> we got really big serious feedback from our biggest users that the
>> release cycle was going too fast. We discussed it amply and agreed on
>> a minimum time of 18 months between releases. 
> 
> If the language moratorium goes into effect, would shorter release cycles
> still have a negative impact?  Do people possibly want slower changes
> to the language and faster updates to the library?
> 
> I don't know the answer.  Just asking how this matches up with the
> feedback you have gotten previously.

Depends on the kind of changes you are talking about:  backward-
incompatible ones (like the hashlib / medusa ones in 2.6, for instance)
are likely going to be unpopular with the "Python with a tie" crowd (I
think that was the name of the IPC BoF from which the original feedback
coalesced).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr5tC0ACgkQ+gerLs4ltQ4QzQCg1eUsdnAEyIficxjeFQevR9ul
pv0An2qpDswkGhqAHkM2REtGE9Zpz8+V
=t5kK
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Michael Foord 

anatoly techtonik wrote:

On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis"  wrote:
  

Anatoly's question is actually a fair one for python-dev - we're the
ones that *ship* Idle, so it is legitimate to ask our reasons for
continuing to do so.
  

OTOH, the second (or, rather, third) question (does anybody think it
should be replaced) is indeed on-topic for python-dev.



That is the exact question I have in my mind. Sorry for not being able
to state it clearly. I'll be more straightforward next time.

  

I didn't really answer that question before, so I do now: I have not
personally plans to replace it, and I'm skeptical wrt. anybody else's
plans unless there is specific code in existence that IDLE could be
replaced *with*.



There are a lot of Python editors. It is unlikely that they implement
all IDLE features, but I believe that 20% of IDLE features that is
used by 80% of users are guaranteed by any editor out of the box.
Assuming that they are more extensible than IDLE anyway. (I would say
"perfection is achieved when there is nothing more to add...", but I
promised to be straightforward).

If we filter list of http://wiki.python.org/moin/PythonEditors by
language/license/framework, we will be able to see if there is any
suitable open source Python code to replace IDLE's.

  


Why replace IDLE?


Then there will be another issue - all editors are based upon some
frameworks - I didn't see any popular cross-platform GUI toolkits in
Python, so we will inevitably face the need to replace Tkinter with
other default GUI toolkit.

  
This just *won't* happen. (At least not in the forseeable future.) 
Better filter your list to only those IDEs that use Tkinter or have a 
GUI not dependent on packages that aren't already in the standard library.



Michael

--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Martin v. Löwis 
> If we filter list of http://wiki.python.org/moin/PythonEditors by
> language/license/framework, we will be able to see if there is any
> suitable open source Python code to replace IDLE's.

This is not how it works. We cannot incorporate something into Python
without explicit consent and support from the author(s). So for any
editor to be incorporated as a replacement (along with all libraries
it depends on) we would need a commitment from the author(s) that they
support the fork that we create (and eventually abandon their
stand-alone release in favor of the fork).

> Should we place an editor first and combine the list a of unique
> features of IDLE that we (as developers) will surely miss  OR  should
> we think what GUI framework will be more beneficial for Python users
> if shipped by default (keeping in mind that we might have to add
> missing features to whatever editor we choose later)?

I think neither approach can possibly work. It's always the authors of
contribution who need to act first.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Martin v. Löwis 
>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
> 
> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
> should have been", so the starting point for the 18-24 month rule of
> thumb is actually back when 3.0 was released in Dec 2008. This was
> discussed a fair bit back when the decision was made to do the short
> release cycle between 3.0 and 3.1 in order to address some of the more
> glaring shortcomings of the 3.0 release.

I agree with everybody else who said that

a) there was *no* consensus that the release cycle for 3.2 should be
   shortened because of 3.1 being released early. I also remember the
   opposite.

b) whatever past discussion may have been, it would be a mistake to
   release 3.2 earlier than 18 months after 3.1.

Of course, 2.7 *could* be released by the proposed schedule; it just
would have to be decoupled from 3.2 (just as 2.6 eventually got
decoupled from 3.0).

I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Nick Coghlan 
Martin v. Löwis wrote:
>>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
>> should have been", so the starting point for the 18-24 month rule of
>> thumb is actually back when 3.0 was released in Dec 2008. This was
>> discussed a fair bit back when the decision was made to do the short
>> release cycle between 3.0 and 3.1 in order to address some of the more
>> glaring shortcomings of the 3.0 release.
> 
> I agree with everybody else who said that
> 
> a) there was *no* consensus that the release cycle for 3.2 should be
>shortened because of 3.1 being released early. I also remember the
>opposite.
> 
> b) whatever past discussion may have been, it would be a mistake to
>release 3.2 earlier than 18 months after 3.1.

Fair enough - I didn't remember that discussion all that well, but
assumed it had reached that consensus due to the lack of comment when
Benjamin originally posted his proposed schedule. Your response and
Guido's clearly indicate otherwise :)

If that wasn't the consensus, then all the dates should slide back 6
months (i.e. no alphas until June 2010). (I actually prefer that since
it gives me a chance to find a cleaner approach to the runpy.run_path
problem, but didn't want to rehash a discussion I thought we had already
had)

> Of course, 2.7 *could* be released by the proposed schedule; it just
> would have to be decoupled from 3.2 (just as 2.6 eventually got
> decoupled from 3.0).

That leads to a 2.x version with features that aren't yet available in a
3.x version though. I thought we weren't planning on doing that anymore.

> I personally think that decoupling the releases would be best, i.e.
> not start thinking about 3.2 for another 6 months.

Or just have the timing be 18 months for 3.2 and 24 months for 2.7 (i.e.
push the first alpha of both back to June next year).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reworking the GIL

2009-11-10 Thread Antoine Pitrou 

Hello again,

I've now removed priority requests, tried to improve the internal doc a 
bit, and merged the changes into py3k.

Afterwards, the new Windows 7 buildbot has hung in test_multiprocessing, 
but I don't know whether it's related.

Regards

Antoine.


Guido van Rossum  python.org> writes:
> 
> 
> I would remove them -- if and when we find there's a need for
> something like them I suspect it won't look like what you currently
> have, so it's better not to complexificate your current patch with
> them. (I would remove all traces, including the conditions passed into
> the end macros.)
> 
> >> My only suggestion so far: the description could use more explicit
> >> documentation on the various variables and macros and how they
> >> combine.
> >
> > Is it before or after
> > http://mail.python.org/pipermail/python-checkins/2009-
November/087482.html ?
> 
> After. While that is already really helpful, not all the code is
> easily linked back to paragraphs in that comment block, and some
> variables are not mentioned by name in the block.
>


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

2009-11-10 Thread Antoine Pitrou 

Le Thu, 05 Nov 2009 22:53:27 -0500, R. David Murray a écrit :
> The buildbot waterfall is much greener now.  Thanks to all who have
> contributed to making it so (and it hasn't just been Mark and Antoine
> and I, though we've been the most directly active (and yes, Mark, you
> did contribute several fixes!)).

The buildbots still show occasional oddities. For example, right now in 
the page "http://www.python.org/dev/buildbot/3.x/";, some results have 
disappeared (the columns for "AMD64 Ubuntu" builders have become empty). 

Moreover, some buildslaves have gone back in time (they are building 
r76188 after having built and tested r76195)... I swear the new GIL 
doesn't include a time machine.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

2009-11-10 Thread Martin v. Löwis 
>> The buildbot waterfall is much greener now.  Thanks to all who have
>> contributed to making it so (and it hasn't just been Mark and Antoine
>> and I, though we've been the most directly active (and yes, Mark, you
>> did contribute several fixes!)).
> 
> The buildbots still show occasional oddities. For example, right now in 
> the page "http://www.python.org/dev/buildbot/3.x/";, some results have 
> disappeared (the columns for "AMD64 Ubuntu" builders have become empty). 

Yes, I noticed it too. It will go away after some page reloads.

> Moreover, some buildslaves have gone back in time (they are building 
> r76188 after having built and tested r76195)... I swear the new GIL 
> doesn't include a time machine.

That's because I resubmitted these changes after restarting the master.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Benjamin Peterson 
2009/11/10 "Martin v. Löwis" :
> I personally think that decoupling the releases would be best, i.e.
> not start thinking about 3.2 for another 6 months.

The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6 months.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Martin v. Löwis 
Benjamin Peterson wrote:
> 2009/11/10 "Martin v. Löwis" :
>> I personally think that decoupling the releases would be best, i.e.
>> not start thinking about 3.2 for another 6 months.
> 
> The problem with that is that there is a period of time where 2.x has
> features which 3.x doesn't. My preference is to move back the whole
> schedule 6 months.

Ok, fine with me as well. FWIW, I don't see that (2.7 released before
3.2) as a problem (but I understand that others might, for what I would
consider formal reasons).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE as default Python editor

2009-11-10 Thread Georg Brandl 
Nick Coghlan schrieb:
> Martin v. Löwis wrote:
>> Nick Coghlan wrote:
>>> Ben Finney wrote:
 anatoly techtonik  writes:

> Quite an interesting question recently popped up in pygame community
> that I'd like to ask to Python developers.
 This forum is specifically about development *of* Python.
>>> Anatoly's question is actually a fair one for python-dev - we're the
>>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>>> continuing to do so.
>> 
>> But he didn't - instead, he asked how many of us use it. Usage by
>> committers is not (or shouldn't be) a primary criterion for including
>> or not including something. Instead, usage in the community should be,
>> and python-dev is indeed the wrong place to estimate that.
> 
> I took it as being a somewhat relevant leading question. If the response
> had been "No, none of us use it" then the obvious follow-up question
> would be "Why do you ship something that you don't consider worth using?".

Quite simple: because we can't possibly ship Emacs.

cheers,
Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 87

2009-11-10 Thread wa2n39 
Stop email
Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT

-Original Message-
From: [email protected]
Date: Tue, 10 Nov 2009 23:09:45 
To: 
Subject: Python-Dev Digest, Vol 76, Issue 87

Send Python-Dev mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."


Today's Topics:

   1. Re: 2.7/3.2 release schedule (Martin v. L?wis)
   2. Re: 2.7/3.2 release schedule (Nick Coghlan)
   3. Re: Reworking the GIL (Antoine Pitrou)
   4. Re: Status of the Buildbot fleet and related bugs (Antoine Pitrou)
   5. Re: Status of the Buildbot fleet and related bugs
  (Martin v. L?wis)
   6. Re: 2.7/3.2 release schedule (Benjamin Peterson)
   7. Re: 2.7/3.2 release schedule (Martin v. L?wis)


--

Message: 1
Date: Tue, 10 Nov 2009 22:05:41 +0100
From: "Martin v. L?wis" 
To: Nick Coghlan 
Cc: Python Development 
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
> 
> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
> should have been", so the starting point for the 18-24 month rule of
> thumb is actually back when 3.0 was released in Dec 2008. This was
> discussed a fair bit back when the decision was made to do the short
> release cycle between 3.0 and 3.1 in order to address some of the more
> glaring shortcomings of the 3.0 release.

I agree with everybody else who said that

a) there was *no* consensus that the release cycle for 3.2 should be
   shortened because of 3.1 being released early. I also remember the
   opposite.

b) whatever past discussion may have been, it would be a mistake to
   release 3.2 earlier than 18 months after 3.1.

Of course, 2.7 *could* be released by the proposed schedule; it just
would have to be decoupled from 3.2 (just as 2.6 eventually got
decoupled from 3.0).

I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.

Regards,
Martin


--

Message: 2
Date: Wed, 11 Nov 2009 07:16:50 +1000
From: Nick Coghlan 
To: "Martin v. L?wis" 
Cc: Python Development 
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

Martin v. L?wis wrote:
>>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
>> should have been", so the starting point for the 18-24 month rule of
>> thumb is actually back when 3.0 was released in Dec 2008. This was
>> discussed a fair bit back when the decision was made to do the short
>> release cycle between 3.0 and 3.1 in order to address some of the more
>> glaring shortcomings of the 3.0 release.
> 
> I agree with everybody else who said that
> 
> a) there was *no* consensus that the release cycle for 3.2 should be
>shortened because of 3.1 being released early. I also remember the
>opposite.
> 
> b) whatever past discussion may have been, it would be a mistake to
>release 3.2 earlier than 18 months after 3.1.

Fair enough - I didn't remember that discussion all that well, but
assumed it had reached that consensus due to the lack of comment when
Benjamin originally posted his proposed schedule. Your response and
Guido's clearly indicate otherwise :)

If that wasn't the consensus, then all the dates should slide back 6
months (i.e. no alphas until June 2010). (I actually prefer that since
it gives me a chance to find a cleaner approach to the runpy.run_path
problem, but didn't want to rehash a discussion I thought we had already
had)

> Of course, 2.7 *could* be released by the proposed schedule; it just
> would have to be decoupled from 3.2 (just as 2.6 eventually got
> decoupled from 3.0).

That leads to a 2.x version with features that aren't yet available in a
3.x version though. I thought we weren't planning on doing that anymore.

> I personally think that decoupling the releases would be best, i.e.
> not start thinking about 3.2 for another 6 months.

Or just have the timing be 18 months for 3.2 and 24 months for 2.7 (i.e.
push the first alpha of both ba

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Raymond Hettinger 


[MvL]

I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.


[Benjamin] 

The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6 months.


My preference is to decouple and let 2.7 go out 18 months after 2.6.
In general, 2.x users should not have to pay a price for whatever
we do with 3.x.


Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread anatoly techtonik 
On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren  wrote:
>
> What's so bad about IDLE that you'd like to replace it?

That was exactly my previous question. You don't use IDLE either, so
why not to replace it with something that you can actually use, with
something that is at least extensible? So people will be interested to
learn and contribute.

> The obvious alternative to replacing IDLE is to fix whatever is wrong with it.

It is also obvious that developer would better download a decent
editor than bog their mind with once perspective, but now dead
technology IDLE was build upon.

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread anatoly techtonik 
On Tue, Nov 10, 2009 at 9:26 PM, Michael Foord
 wrote:
>
>> Then there will be another issue - all editors are based upon some
>> frameworks - I didn't see any popular cross-platform GUI toolkits in
>> Python, so we will inevitably face the need to replace Tkinter with
>> other default GUI toolkit.
>
> This just *won't* happen. (At least not in the forseeable future.) Better
> filter your list to only those IDEs that use Tkinter or have a GUI not
> dependent on packages that aren't already in the standard library.

That is a real stumbling block. There aren't any GUI toolkits in pure
Python to be included alongside the editor, and those Tkinter bindings
that compiled for every platform are just useless. If there is a
reason that we just *won't* let any GUI framework (except Tkinter)
slip into Python distribution then of course, any talk about editor is
just a waste of time. But I'd like to see is that reason is real to
know when to expect the changes.

I've done a small research about Tkinter editors to investigate the
solution you proposed. http://wiki.python.org/moin/PythonEditors shows
that these were made with Tk:

Pye - not true, either switched or wrong project, but PyQT4 -
http://code.google.com/p/pye-editor/
xRope - GPL and probably worse than IDLE -
http://sourceforge.net/projects/xrope/
IDEStudio - enhanced IDLE, dead - http://wiki.python.org/moin/IDEStudio
SourceNavigator - GPL, C and not really an editor -
http://sourcenav.sourceforge.net/

There is only one perspective project called Leo (with MIT license)
that was historically written in Tkinter with the goal (I believe) to
construct pure Python editor. It is editor with outlines unique in the
way that it is able to rewrite itself literally at runtime. I believe
only using such advanced tool one can cope with Tkinter
inconsistencies and limitations. Since the beginning Leo has also
developed PyQT4 interface.

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7/3.2 release schedule

2009-11-10 Thread Guido van Rossum 
On Tue, Nov 10, 2009 at 10:26 AM, Raymond Hettinger  wrote:
>
> [Guido van Rossum]
>>
>> . We used to have releases once a year and
>> we got really big serious feedback from our biggest users that the
>> release cycle was going too fast. We discussed it amply and agreed on
>> a minimum time of 18 months between releases.
>
> If the language moratorium goes into effect,

"If"? It's already Approved. :-)

> would shorter release cycles
> still have a negative impact?  Do people possibly want slower changes
> to the language and faster updates to the library?
>
> I don't know the answer.  Just asking how this matches up with the
> feedback you have gotten previously.

I expect it wouldn't make a difference since backwards compatibility
testing involves a lot more than language syntax.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread anatoly techtonik 
On Tue, Nov 10, 2009 at 10:49 PM, "Martin v. Löwis"  wrote:
>
> This is not how it works. We cannot incorporate something into Python
> without explicit consent and support from the author(s). So for any
> editor to be incorporated as a replacement (along with all libraries
> it depends on) we would need a commitment from the author(s) that they
> support the fork that we create (and eventually abandon their
> stand-alone release in favor of the fork).
>

Does that mean even if authors of some imaginary editor agree to
incorporate their code into Python, the framework that it is built
upon will have to be incorporated into Python also (and eventually
abandoned at original location)?

In this situation I see no way we can provide any decent tools for GUI
like for default editor.

Thanks for support.
-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Stephen J. Turnbull 
anatoly techtonik writes:

 > Does that mean even if authors of some imaginary editor agree to
 > incorporate their code into Python, the framework that it is built
 > upon will have to be incorporated into Python also (and eventually
 > abandoned at original location)?

I would assume so.  How else can Python guarantee its maintenance?

 > In this situation I see no way we can provide any decent tools for GUI
 > like for default editor.

IDLE *is* a "decent tool".  You don't have to like it, but it's good
enough to get started.  By the time you realize its limitations, you
should have a handle on easy_install.

The promise is "batteries included."  Nobody promised you a nickel
metal hydride battery that you can use as a replacement in your Prius.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Greg Ewing 

anatoly techtonik wrote:


why not to replace it with something that you can actually use, with
something that is at least extensible? So people will be interested to
learn and contribute.


IDLE is written in Python, so it's about as extensible
as you can get.

Seems to me the only kind of IDE that it makes sense to
ship with Python is one that is written in Python and
maintained by the core developers. Anything else is best
left as a third party package for download by those
who want to use it.

Tkinter is arguably not a very good basis for it from a
technical point of view, but so far all the alternatives
are too bloated and/or nonportable to consider bundling
with the standard distribution.

So the only realistic alternatives at the moment seem
to be either IDLE+Tkinter or nothing.

Quite likely most experienced developers use something
else, and wouldn't care if IDLE were removed and not
replaced with anything. But there are benefits to having
a standard, lightweight IDE present in most Python
installations. Books and tutorials can be designed around
it, for example, with fairly high assurance that it will
be available to beginners who aren't comfortable finding
their way around text editors and command shells.

So, I'd say that, like democracy, it's not very good, but
it's better than any of the alternatives. :-)

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Martin v. Löwis 
> Does that mean even if authors of some imaginary editor agree to
> incorporate their code into Python, the framework that it is built
> upon will have to be incorporated into Python also (and eventually
> abandoned at original location)?

It depends. It should work the same way as IDLE: it's ok that Tcl/Tk
itself is not included in Python, however, Tkinter is.

If that imaginary editor has lots of build dependencies that make
it really difficult to use it, I would be opposed to including it.
If it requires one library that is typically already available on
a Linux system, it would be fine with me.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Greg Ewing 

Martin v. Löwis wrote:


If that imaginary editor has lots of build dependencies that make
it really difficult to use it, I would be opposed to including it.
If it requires one library that is typically already available on
a Linux system, it would be fine with me.


If I manage to get PyGUI into a practically usable
state and it ever gets included in the core distribution,
then it might be a viable basis for a modernised version
of IDLE. That's probably a fairly long way off, though.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Vincent Manis 
On 2009-11-10, at 22:07, Greg Ewing wrote:
> So, I'd say that, like democracy, [IDLE is] not very good, but
> it's better than any of the alternatives. :-)


Speaking purely as a Python user, I am very happy that IDLE is part of the 
Python distribution. Personally, I use and like emacs too much, and have no use 
for IDLE for my own programming at all. But I have taught a lot of Python 
classes, and being able to tell the IT staff `please install Python x.y on the 
machines in the lab', and then knowing that students have everything they need 
to do their lab work, is a major plus. (I found that many of the students 
stayed with IDLE even after their course was over, too.)

As a side observation, I think the main reasons why Tk is so resistant to 
removal from Python (and several other dynamic languages) is that its 
developers took very seriously the idea of being lightweight and portable, 
while many other toolkits grew more and more complex. Not all GUI toolkits are 
like that; I have nice things to say about FLTK, for example. Perhaps one day 
somebody will do a revision of Tk (sans Tcl) for the 21st century, but until 
then, Greg's Winston Churchill quote applies not just to IDLE but also to Tk. 

[`This horse is dead, please stop flogging it.' `No it's not, it's just 
observing the moratorium']

-- v
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Vincent Manis 
On 2009-11-10, at 22:17, Martin v. Löwis wrote:
> If that imaginary editor has lots of build dependencies that make
> it really difficult to use it, I would be opposed to including it.
> If it requires one library that is typically already available on
> a Linux system, it would be fine with me.
s/Linux/Linux, Mac (Aqua, not X11), and Windows/

-- v
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Ronald Oussoren 

On 11 Nov, 2009, at 2:48, anatoly techtonik wrote:

> On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren  
> wrote:
>> 
>> What's so bad about IDLE that you'd like to replace it?
> 
> That was exactly my previous question. You don't use IDLE either, so
> why not to replace it with something that you can actually use, with
> something that is at least extensible? So people will be interested to
> learn and contribute.

I don't use IDLE because I'm too used to my current editor, which btw. is the 
cmd-line version of vim.  That offers everything I need from a Python editor.  
That said, I have used IDLE occasionaly and it works fine for a basic Python 
environment.

IDLE is extensible, I've seen a number of IDLE extensions on the IDLE-dev 
mailinglist (). That list 
would be a better location to discus this.

BTW. You still haven't mentioned why you think IDLE should be replaced.
> 
>> The obvious alternative to replacing IDLE is to fix whatever is wrong with 
>> it.
> 
> It is also obvious that developer would better download a decent
> editor than bog their mind with once perspective, but now dead
> technology IDLE was build upon.

Tk is actively developed, it is not dead technology.  Replacing IDLE by an 
editor which uses another toolkit would either mean that the default editor 
uses libraries not in the stdlib, or the inclusion of that toolkit in the 
stdlib. 

Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com