date:20100711

> I would like to propose removing IDLE from the standard library.
>
> I have been using IDLE since 2002 and have been doing my best to help
> maintain and further develop IDLE since 2005.

I'm surprised by the amount of interest this has raised already. To
answer a few questions that were raised:

In recent years I have worked up many patches, both bugfixes and new
features and improvements. Getting any attention to these was
non-trivial, and getting patches accepted (or an explanation why they
are rejected in some cases) almost always took many months, sometimes
years, and some are still unresolved. It has been very frustrating.

When I ran into bugs I fixed them and submitted a patch. I have also
done so for quite a few bugs reported by others. However, there are
currently several bugs in the tracker which nobody is taking any
notice of. IIRC most of the recent bugs are related to OSX or 64-bit
Windows.

To those who mention that IDLE is "okay" or "not going uphill", my
grandfather would say "if you aren't running forwards, you are falling
behind." You should know how IDLE looks to programmers seeing it for
the first time -- IDLE's quirky and old-fashioned looks and interface
are a major turnoff for new users. As a result I have stopped
recommending it to coworkers, despite personally liking IDLE, instead
recommending the basic command-line or IPython for interactive work,
and any other IDE or text editor for development.

I too prefer IDLE to the basic command line, and think that something
like IDLE is well-suited for learning/teaching Python. I also think an
interpreter with a nice GUI can be far superior to a text-only
interpreter. However, I've mostly lost hope for IDLE, and am currently
hoping that something else takes its place.

The fact is that for many years little effort has gone into developing
and maintaining IDLE, and I believe being tucked in a corner of the
Python codebase is a major reason for this. I really don't see why
IDLE has to be part of the standard library, what's wrong with IDLE
being an externally maintained application?

Yes, IDLE still works (mostly), but us few who continue to use it
could do so even if it weren't part of the standard library.

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Ronald Oussoren


On 11 Jul, 2010, at 10:57, Tal Einat wrote:
> 
> When I ran into bugs I fixed them and submitted a patch. I have also
> done so for quite a few bugs reported by others. However, there are
> currently several bugs in the tracker which nobody is taking any
> notice of. IIRC most of the recent bugs are related to OSX or 64-bit
> Windows.

The OSX issues al seem to be related to general Tk or Tkinter bugs
on OSX. I know to little about Tk and Tkinter to seriously work on 
those.

Ronald

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Antoine Pitrou

On Sat, 10 Jul 2010 21:33:28 -0400
Terry Reedy  wrote:
> 
> The problem here, it seems to me, is that all issues are autoassigned to 
> an inactive person (KBK) who does not really accept them except once a 
> year or so. I do not know whether all other commiter are unwilling to 
> commit IDLE issues, no matter how obvious and trivial, or if they all 
> think they 'belong' to KBK.

Well, how can you expect people to commit patches for something
they don't know or use?
(and, admittedly, something many of us don't care about)

Regards

Antoine.


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

Re: [Python-Dev] New regex module for 3.2?

2010-07-11 Thread anatoly techtonik

On Fri, Jul 9, 2010 at 6:59 PM, Jeffrey Yasskin  wrote:
>
> While the re2 comparison might be interesting from an abstract
> standpoint, it intentionally supports a different regex language from
> Python so that it can run faster and use less memory. Since re2 can
> never replace Python's re module, it doesn't make sense to hold MRAB's
> new module to that standard.

re2 comparison is interesting from the point of if it should be
included in stdlib.
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

On Sun, Jul 11, 2010 at 12:03 PM, Ronald Oussoren wrote:
>
> On 11 Jul, 2010, at 10:57, Tal Einat wrote:
>>
>> When I ran into bugs I fixed them and submitted a patch. I have also
>> done so for quite a few bugs reported by others. However, there are
>> currently several bugs in the tracker which nobody is taking any
>> notice of. IIRC most of the recent bugs are related to OSX or 64-bit
>> Windows.
>
> The OSX issues al seem to be related to general Tk or Tkinter bugs
> on OSX. I know to little about Tk and Tkinter to seriously work on
> those.
>
> Ronald

Perhaps, but the point is that these bugs remain. Certainly this isn't
because just you, out of the entire Python development community, know
little about Tk and Tkinter.

Using Tkinter is a major reason that maintaining and further
developing IDLE is difficult. For example, it took me many hours just
to get a working Tkinter scrolled frame widget, having had to write it
from scratch and struggle with the under-documented Canvas widget.
Another example is that integration of the new ttk (a.k.a. Tile)
widget set, which supports native look&feel on various platforms and
adds modern widgets, has still not been integrated despite being
available in Tk for years and despite considerable effort being
invested into it.

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New regex module for 3.2?

2010-07-11 Thread Eric Smith


On 7/11/2010 5:19 AM, anatoly techtonik wrote:

On Fri, Jul 9, 2010 at 6:59 PM, Jeffrey Yasskin  wrote:


While the re2 comparison might be interesting from an abstract
standpoint, it intentionally supports a different regex language from
Python so that it can run faster and use less memory. Since re2 can
never replace Python's re module, it doesn't make sense to hold MRAB's
new module to that standard.


re2 comparison is interesting from the point of if it should be
included in stdlib.


Is "it" re2 or regex? I don't see having 2 regular expression engines in 
the stdlib.


Eric.

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

Re: [Python-Dev] New regex module for 3.2?

2010-07-11 Thread Nick Coghlan

On Sun, Jul 11, 2010 at 7:19 PM, anatoly techtonik  wrote:
> On Fri, Jul 9, 2010 at 6:59 PM, Jeffrey Yasskin  wrote:
>>
>> While the re2 comparison might be interesting from an abstract
>> standpoint, it intentionally supports a different regex language from
>> Python so that it can run faster and use less memory. Since re2 can
>> never replace Python's re module, it doesn't make sense to hold MRAB's
>> new module to that standard.
>
> re2 comparison is interesting from the point of if it should be
> included in stdlib.

No it isn't. re2 is a wrapper for a third party engine that surrenders
some functionality in the pursuit of better bounds on memory and CPU
usage. It is not a drop-in replacement for re and cannot be by design:
"The one significant exception is that RE2 drops support for
backreferences and generalized zero-width assertions, because they
cannot be implemented efficiently." There is no reason to have two
distinct regex engines in the standard library - if someone knows
enough to realise they need the performance assurances of re2, they're
also likely to be able to find the Python wrappers for it.

regex is potentially interesting for the standard library as it *is*
intended to be a drop-in replacement for re that trades longer
compilation times (typically once per application) for faster match
times (potentially many times per application). The performance of re2
has nothing to do with the comparison between the current re module
and MRAB's regex module.

Regards,
Nick.

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread David Beazley


> I would like to propose removing IDLE from the standard library.
> 

-1000.   From the Python training department, I would like to say that this 
would be a horrible idea.   Having taught numerous on-site training courses for 
Python, the one thing that I've learned is that you never know what you're 
going to get when you show up to teach a course.   More often than not, you're 
thrown into some training room with a bunch of PCs, operated by someone who 
doesn't know anything about Python at all, and who had a hard enough time 
installing it in the first place.The fact that IDLE comes with Python means 
that even in such situations, as long as Python has been installed somewhere, 
there's going to be at least one halfway-reasonable environment for working 
with it (although I suppose there are some people who would still prefer to use 
the Windows command shell and Notepad).

For what it's worth, I think IDLE works fine as a development environment, 
despite the fact that it has some flaky bits.The most annoying issue that I 
encounter in classes is people starting IDLE by right-clicking on files.  This 
starts up IDLE without its subprocess and causes all sorts of bizarre problems 
related to the environment (e.g., restarting, module imports, etc.).  Other 
than that, it's fine.

Cheers,
Dave




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

[Python-Dev] Threading bug review + commit privs

2010-07-11 Thread Reid Kleckner

Hey all,

I'm porting some fixes for threading.py that we applied to unladen-swallow:
http://bugs.python.org/issue6643

We ran into these bizarre race conditions involving fork + threads
while running the test suite with a background JIT compilation thread.
 I really wish we weren't trying to support forking from a child
thread, but it's already in the test suite.  I've "solved" the problem
by throwing away radioactive locks that may have been held across a
fork.*

If I could get a reviewer to look at this, I would be very grateful,
since reviewing threading patches is somewhat tricky.  =/

I'm also expecting to be doing more work merging unladen-swallow into
the py3k-jit branch, so I was wondering if I could get commit
privileges for that.

Thanks,
Reid

* In general I wouldn't think this is safe, but we already do it for
_active_limbo_lock in threading.py.  One of the problems I've
encountered is that on OS X, releasing locks held by other threads
across a fork results in a crash.  Furthermore, when locks are
deallocated, the destructor does a non-blocking acquire and then
release, which I would think would crash.  However, we get lucky here,
because any thread that holds a lock across a fork usually holds a
reference to it on the stack.  Therefore the lock is leaked and the
destructor never run.  Moral: fork + threads is *crazy*, avoid it if
you can.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Guido van Rossum

On Sun, Jul 11, 2010 at 2:16 PM, David Beazley  wrote:
>
>> I would like to propose removing IDLE from the standard library.
>>
>
> -1000.   From the Python training department, I would like to say that this 
> would be a horrible idea.   Having taught numerous on-site training courses 
> for Python, the one thing that I've learned is that you never know what 
> you're going to get when you show up to teach a course.   More often than 
> not, you're thrown into some training room with a bunch of PCs, operated by 
> someone who doesn't know anything about Python at all, and who had a hard 
> enough time installing it in the first place.    The fact that IDLE comes 
> with Python means that even in such situations, as long as Python has been 
> installed somewhere, there's going to be at least one halfway-reasonable 
> environment for working with it (although I suppose there are some people who 
> would still prefer to use the Windows command shell and Notepad).
>
> For what it's worth, I think IDLE works fine as a development environment, 
> despite the fact that it has some flaky bits.    The most annoying issue that 
> I encounter in classes is people starting IDLE by right-clicking on files.  
> This starts up IDLE without its subprocess and causes all sorts of bizarre 
> problems related to the environment (e.g., restarting, module imports, etc.). 
>  Other than that, it's fine.
>
> Cheers,
> Dave

Right. IDLE fits a niche. It's never going to be the world's best
Python development environment but it isn't the worst either, and it's
worth keeping around.

There clearly are *some* folks who care enough about IDLE to submit
bug reports and fixes. How about we empower these people by giving at
least one of them commit privileges? IDLE development has often been
done by people who aren't otherwise contributing to the core, and we
surely should trust those folks with commit privileges.

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

Re: [Python-Dev] Can ftp url start with file:// ?

2010-07-11 Thread Steve Holden

Senthil Kumaran wrote:
> On Fri, Jul 09, 2010 at 02:32:04PM -0400, Fred Drake wrote:
>> FTP access also more often reflected the actual file hierarchy of the
>> machine, so trying that path as a system path is more likely to work
>> that I'd expect to see for HTTP.
> 
> I see the reason. But I doubt if this is a reliable approach.  Also
> when the scheme begins with file:// it should not be confused with
> ftp, so I think, that portion of code in urllib which work that way
> should be removed.
> 
> The issue8801 was fixed in a different way so that no regression is
> introduced. 
> 
> For 3.2 release, shall we do way with relying on ftp for file://
> scheme ? Currently for a url like
> file://somehost.domain//filesys/file.txt the flow control considers it
> a ftp url!
> 
> The expected behaviour might be throw an exception saying that file://
> url wont make any sense if it not localhost or absolute path.
> 
> What if 'somehost.domain' is actually hostname of the machine? Should
> file:// be allowed in that case or is it the reason to rely on ftp?
> But it still does not make much sense to use ftp, because there is no
> guarantee that ftp service is running in that machine.
> 
My own inclination would be to regard the current treatment of file: as
a bug (albeit one not worth fixing on 2.x). RFC 1630 specification lists
the "file" scheme as being for "local file access", and RFC 1738 says
they are for "host-specific file names" and points out that "The file
URL scheme is unusual in that it does not specify an Internet protocol
or access method for such files; as such, its utility in network
protocols between hosts is limited." Presumably a hostname in such a URI
would require that some host-specific protocol be used (but this should
be an access protocol like SMB or NFS, not a transfer protocol like FTP).

It seems pretty clear that randomly interpreting particular host names
to imply a specific remote-access protocol like FTP is bogus.

regards
 Steve

-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] Removing IDLE from the standard library


On 11-7-2010 14:52, Guido van Rossum wrote:

On Sun, Jul 11, 2010 at 2:16 PM, David Beazley  wrote:



I would like to propose removing IDLE from the standard library.



-1000.   From the Python training department, I would like to say that this 
would be a horrible idea.   Having taught numerous on-site training courses for 
Python, the one thing that I've learned is that you never know what you're 
going to get when you show up to teach a course.   More often than not, you're 
thrown into some training room with a bunch of PCs, operated by someone who 
doesn't know anything about Python at all, and who had a hard enough time 
installing it in the first place.The fact that IDLE comes with Python means 
that even in such situations, as long as Python has been installed somewhere, 
there's going to be at least one halfway-reasonable environment for working 
with it (although I suppose there are some people who would still prefer to use 
the Windows command shell and Notepad).

For what it's worth, I think IDLE works fine as a development environment, 
despite the fact that it has some flaky bits.The most annoying issue that I 
encounter in classes is people starting IDLE by right-clicking on files.  This 
starts up IDLE without its subprocess and causes all sorts of bizarre problems 
related to the environment (e.g., restarting, module imports, etc.).  Other 
than that, it's fine.

Cheers,
Dave


Right. IDLE fits a niche. It's never going to be the world's best
Python development environment but it isn't the worst either, and it's
worth keeping around.

There clearly are *some* folks who care enough about IDLE to submit
bug reports and fixes. How about we empower these people by giving at
least one of them commit privileges? IDLE development has often been
done by people who aren't otherwise contributing to the core, and we
surely should trust those folks with commit privileges.



Can I take a really big liberty and volunteer Terry Reedy for the job.

Kindest regards.

Mark Lawrence.

___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Kevin Walzer


On 7/11/10 5:03 AM, Ronald Oussoren wrote:






The OSX issues al seem to be related to general Tk or Tkinter bugs
on OSX. I know to little about Tk and Tkinter to seriously work on
those.


Ronald,

How about http://bugs.python.org/issue6075? I first submitted that patch 
in May '09, and updated it in October '09 on request from you, and it's 
just sat there since...


--Kevin


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

On Sun, Jul 11, 2010 at 11:57 AM, Tal Einat wrote:
>> I would like to propose removing IDLE from the standard library.
>>
>> I have been using IDLE since 2002 and have been doing my best to help
>> maintain and further develop IDLE since 2005.
>
> I'm surprised by the amount of interest this has raised already. To
> answer a few questions that were raised:
>
> To those who mention that IDLE is "okay" or "not going uphill", my
> grandfather would say "if you aren't running forwards, you are falling
> behind." You should know how IDLE looks to programmers seeing it for
> the first time -- IDLE's quirky and old-fashioned looks and interface
> are a major turnoff for new users. As a result I have stopped
> recommending it to coworkers, despite personally liking IDLE, instead
> recommending the basic command-line or IPython for interactive work,
> and any other IDE or text editor for development.
>
> I too prefer IDLE to the basic command line, and think that something
> like IDLE is well-suited for learning/teaching Python. I also think an
> interpreter with a nice GUI can be far superior to a text-only
> interpreter. However, I've mostly lost hope for IDLE, and am currently
> hoping that something else takes its place.
>
> The fact is that for many years little effort has gone into developing
> and maintaining IDLE, and I believe being tucked in a corner of the
> Python codebase is a major reason for this. I really don't see why
> IDLE has to be part of the standard library, what's wrong with IDLE
> being an externally maintained application?
>
> Yes, IDLE still works (mostly), but us few who continue to use it
> could do so even if it weren't part of the standard library.

Most of the responses up to this point have been strongly against my
proposal. The main reason given is that it is nice to have a graphical
IDE supported out-of-the-box with almost any Python installation. This
is especially important for novice programmers and in teaching
environments. I understand this sentiment, but I think that supplying
a quirky IDE with many caveats, lacking documentation, some bugs and a
partially working debugger ends up causing more confusion than good.

Initially (five years ago!) I tried to overcome these issues by
improving IDLE, solving problems and adding a few key features.
Without going into details, suffice to say that IDLE hasn't improved
much since 2005 despite my efforts. For example, see
http://bugs.python.org/issue1529142, where it took nearly 3 years to
fix a major issue from the moment I posted the first workaround. For
another example, see http://bugs.python.org/issue3068, where I posted
a patch for an extension configuration dialog over two years ago, and
it hasn't received as much as a sneeze in response.

Although several people say that they think having IDLE in the stdlib
is important, the fact is that IDLE is considered quite unimportant by
most of the Python community. Having IDLE in the stdlib may be
convenient for a few people, but most never use it and don't care
about it. I think that in its current state, IDLE may still be helpful
for learning Python, but it is more likely to drive away users who run
into its various quirks and problems. And for experienced Python
developers, very few actually use IDLE, and those who do could easily
install it if it weren't part of the stdlib.

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

Guido van Rossum wrote:
>David Beazley wrote:
>>
>>> I would like to propose removing IDLE from the standard library.
>>>
>>
>> -1000.   From the Python training department, I would like to say that this 
>> would be a horrible idea.
>
>Right. IDLE fits a niche. It's never going to be the world's best
>Python development environment but it isn't the worst either, and it's
>worth keeping around.
>
>There clearly are *some* folks who care enough about IDLE to submit
>bug reports and fixes. How about we empower these people by giving at
>least one of them commit privileges? IDLE development has often been
>done by people who aren't otherwise contributing to the core, and we
>surely should trust those folks with commit privileges.

This would certainly be a great improvement on the current situation.

However, I still think IDLE is not currently in a state that it should
be suggested for use by beginners.

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting an optional parameter instead of creating a socket internally

2010-07-11 Thread Jesus Cea

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/10 04:03, exar...@twistedmatrix.com wrote:
> On 12 Apr, 11:19 pm, j...@jcea.es wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
>>> Jesus Cea  jcea.es> writes:

 PS: "socket.setdefaulttimeout()" is not enough, because it could
 shutdown a perfectly functional connection, just because it was idle
 for
 too long.
>>>
>>> The socket timeout doesn't shutdown anything. It just puts a limit on
>>> how much
>>> time recv() and send() can block. Then it's up to you to detect
>>> whether the
>>> server is still alive (for example by pinging it through whatever
>>> means the
>>> application protocol gives you).
>>
>> A regular standard library (let say, poplib) would abort, after getting
>> the timeout exception.
 4. Modify client libraries to accept a new optional socket-like object
 as an optional parameter. This would allow things like transparent
 compression or encryption, or to replace the socket connection by
 anything else (read/write to shared memory or database, for example).
>>>
>>> This could be useful too.
>>
>> I have been thinking about this for years. Do you actually think this
>> could be formally proposed?.
> 
> Every once in a while I make a little bit more progress on the PEP I'm
> working on for this.  If you want to talk more about this, you can find
> me in #python-dev or #twisted on freenode.
> 
> Jean-Paul

Jean-Paul, I would like to have this for 3.2. How is the PEP going?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTDnfL5lgi5GaxT1NAQJOIAP+IAARGsWGeReG21Mc70AxT9e82TqrPY65
053GpfnqDW/poCHdHKv5NeDPso02tDeJvZ53cB23ximQKM9qg1j9XzXP/5AJcjke
eVJaS9K8K6/Z1o97iDZb3Evkt7q2Dn7VG4QjJn6cy9lh841HDRFn/+HIuQLgoMyh
stvK53cj7n4=
=JrAg
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] I use both IDLE and my console

2010-07-11 Thread Van

Hello all,
  Buggy or not it's quite handy and as I said I use both when programming in 
python. To discontinue it is just not a good idea.
Hausburn___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] commit privs

2010-07-11 Thread Antoine Pitrou

On Sun, 11 Jul 2010 13:23:13 +
Reid Kleckner  wrote:
> 
> I'm also expecting to be doing more work merging unladen-swallow into
> the py3k-jit branch, so I was wondering if I could get commit
> privileges for that.

It sounds good to me. Also, thanks for your threading patches!

Regards

Antoine.


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

Re: [Python-Dev] Threading bug review + commit privs

2010-07-11 Thread Georg Brandl

Am 11.07.2010 15:23, schrieb Reid Kleckner:

> I'm also expecting to be doing more work merging unladen-swallow into
> the py3k-jit branch, so I was wondering if I could get commit
> privileges for that.

Sure -- send your public key to me, and I'll set you up.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Bill Janssen

Tal Einat  wrote:

> Although several people say that they think having IDLE in the stdlib
> is important, the fact is that IDLE is considered quite unimportant by
> most of the Python community. Having IDLE in the stdlib may be
> convenient for a few people, but most never use it and don't care
> about it. I think that in its current state, IDLE may still be helpful
> for learning Python, but it is more likely to drive away users who run
> into its various quirks and problems. And for experienced Python
> developers, very few actually use IDLE, and those who do could easily
> install it if it weren't part of the stdlib.

I agree with you on this, Tal.  On OS X, this is particularly
aggravating, as the Apple-supplied Python doesn't seem to include a
working version, and installing MacPython leads to other problems (see,
for instance, the thread at
http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5b66).

For David and other teachers, there are plenty of alternative IDEs,
outlined at
http://wiki.python.org/moin/IntegratedDevelopmentEnvironments.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can ftp url start with file:// ?

2010-07-11 Thread Fred Drake

On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran  wrote:
> I see the reason. But I doubt if this is a reliable approach.  Also
> when the scheme begins with file:// it should not be confused with
> ftp, so I think, that portion of code in urllib which work that way
> should be removed.

I'm not trying to defend the current behavior of defaulting to FTP as
a good thing; it's definitely surprising.  I am trying to rationalize
it so I can be sure I understand why it might have been done to start
with.

My own preference is to kick out any non-local references with an
exception that can be detected (possibly derived from ValueError) so
that applications that want rewrite (hopefully with user agreement!)
can do so.  (Checking for non-local file: URLs on input might be
better, of course.)

  -Fred

-- 
Fred L. Drake   
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] commit privs

2010-07-11 Thread Brett Cannon

On Sun, Jul 11, 2010 at 09:28, Antoine Pitrou  wrote:
> On Sun, 11 Jul 2010 13:23:13 +
> Reid Kleckner  wrote:
>>
>> I'm also expecting to be doing more work merging unladen-swallow into
>> the py3k-jit branch, so I was wondering if I could get commit
>> privileges for that.
>
> It sounds good to me. Also, thanks for your threading patches!

+1 from me as well.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

> Initially (five years ago!) I tried to overcome these issues by
> improving IDLE, solving problems and adding a few key features.
> Without going into details, suffice to say that IDLE hasn't improved
> much since 2005 despite my efforts. For example, see
> http://bugs.python.org/issue1529142, where it took nearly 3 years to
> fix a major issue from the moment I posted the first workaround. For
> another example, see http://bugs.python.org/issue3068, where I posted
> a patch for an extension configuration dialog over two years ago, and
> it hasn't received as much as a sneeze in response.

I can understand that this is frustrating, but please understand that
this is not specific to your patches, or to IDLE. Many other patches on
bugs.python.org remain unreviewed for many years. That's because many of
the issues are really tricky, and there are very few people who both
have the time and the expertise to evaluate them.

FWIW, I don't consider a few months as a "long" time for a patch review.
At the moment, I'm personally able to perhaps review one issue per week
(sometimes less); at this rate, it'll take several years until I get
to everything.

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

Re: [Python-Dev] Removing IDLE from the standard library

>> There clearly are *some* folks who care enough about IDLE to submit
>> bug reports and fixes. How about we empower these people by giving at
>> least one of them commit privileges? IDLE development has often been
>> done by people who aren't otherwise contributing to the core, and we
>> surely should trust those folks with commit privileges.
>>
> 
> Can I take a really big liberty and volunteer Terry Reedy for the job.

It doesn't work that way. You can't volunteer somebody else (*).

If Terry would volunteer himself, he'd get commit access in no time.

Regards,
Martin

(*) so when you assign bugs to me, it probably means that they get less
attention, not more.
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

On Jul 11, 2010, at 10:22 AM, Tal Einat wrote:

> Most of the responses up to this point have been strongly against my
> proposal. The main reason given is that it is nice to have a graphical
> IDE supported out-of-the-box with almost any Python installation. This
> is especially important for novice programmers and in teaching
> environments. I understand this sentiment, but I think that supplying
> a quirky IDE with many caveats, lacking documentation, some bugs and a
> partially working debugger ends up causing more confusion than good.

The people who are actually *in* those environments seem to disagree with you 
:).  I think you underestimate the difficulty of getting software installed and 
overestimate the demands of new Python users and students.

While I don't ever use IDLE if there's an alternative available, I have been 
very grateful many times for its presence in environments where it was a 
struggle even to say "install Python".  A workable editor and graphical shell 
is important, whatever its flaws.  (And I think you exaggerate IDLE's flaws 
just a bit.)

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

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:

>> Initially (five years ago!) I tried to overcome these issues by
>> improving IDLE, solving problems and adding a few key features.
>> Without going into details, suffice to say that IDLE hasn't improved
>> much since 2005 despite my efforts. For example, see
>> http://bugs.python.org/issue1529142, where it took nearly 3 years to
>> fix a major issue from the moment I posted the first workaround. For
>> another example, see http://bugs.python.org/issue3068, where I posted
>> a patch for an extension configuration dialog over two years ago, and
>> it hasn't received as much as a sneeze in response.
> 
> I can understand that this is frustrating, but please understand that
> this is not specific to your patches, or to IDLE. Many other patches on
> bugs.python.org remain unreviewed for many years. That's because many of
> the issues are really tricky, and there are very few people who both
> have the time and the expertise to evaluate them.

This problem seems to me to be the root cause here.

Guido proposes to give someone interested in IDLE commit access, and hopefully 
that will help in this particular area.  But, as I recall, at the last language 
summit there was quite a bit of discussion about how to address the broader 
issue of patches falling into a black hole.  Is anybody working on it?

(This seems to me like an area where a judicious application of PSF funds might 
help; if every single bug were actively triaged and responded to, even if it 
weren't reviewed, and patch contributors were directed to take specific steps 
to elicit a response or a review, the fact that patch reviews take a while 
might not be so bad.)

> FWIW, I don't consider a few months as a "long" time for a patch review.

It may not be a long time compared to other patch reviews, but it is a very 
long time for a volunteer to wait for something, especially if that "something" 
is "any indication that the python developers care that this patch was 
submitted at all".

There seems to be at least one thread a month on this list from a disgruntled 
community member complaining (directly or indirectly) about this delay.  I 
think that makes it a big problem.

> At the moment, I'm personally able to perhaps review one issue per week
> (sometimes less); at this rate, it'll take several years until I get
> to everything.

I guess it depends what you mean by "everything", but given that the open bug 
count is actually increasing at a significant rate, I would say that you can 
never possibly get to "everything".

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

Re: [Python-Dev] Can ftp url start with file:// ?

2010-07-11 Thread Bill Janssen

Fred Drake  wrote:

> On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran  wro=
> te:
> > I see the reason. But I doubt if this is a reliable approach. =A0Also
> > when the scheme begins with file:// it should not be confused with
> > ftp, so I think, that portion of code in urllib which work that way
> > should be removed.
> 
> I'm not trying to defend the current behavior of defaulting to FTP as
> a good thing; it's definitely surprising.  I am trying to rationalize
> it so I can be sure I understand why it might have been done to start
> with.
> 
> My own preference is to kick out any non-local references with an
> exception that can be detected (possibly derived from ValueError) so
> that applications that want rewrite (hopefully with user agreement!)
> can do so.  (Checking for non-local file: URLs on input might be
> better, of course.)

Sounds like a good plan to me, too.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting an optional parameter instead of creating a socket internally

2010-07-11 Thread exarkun


On 03:11 pm, j...@jcea.es wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/10 04:03, exar...@twistedmatrix.com wrote:

On 12 Apr, 11:19 pm, j...@jcea.es wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/13/2010 12:47 AM, Antoine Pitrou wrote:

Jesus Cea  jcea.es> writes:


PS: "socket.setdefaulttimeout()" is not enough, because it could
shutdown a perfectly functional connection, just because it was 
idle

for
too long.


The socket timeout doesn't shutdown anything. It just puts a limit 
on

how much
time recv() and send() can block. Then it's up to you to detect
whether the
server is still alive (for example by pinging it through whatever
means the
application protocol gives you).


A regular standard library (let say, poplib) would abort, after 
getting

the timeout exception.
4. Modify client libraries to accept a new optional socket-like 
object

as an optional parameter. This would allow things like transparent
compression or encryption, or to replace the socket connection by
anything else (read/write to shared memory or database, for 
example).


This could be useful too.


I have been thinking about this for years. Do you actually think this
could be formally proposed?.


Every once in a while I make a little bit more progress on the PEP I'm
working on for this.  If you want to talk more about this, you can 
find

me in #python-dev or #twisted on freenode.

Jean-Paul


Jean-Paul, I would like to have this for 3.2. How is the PEP going?.


It's still little more than an outline.  You can see it here:

 http://twistedmatrix.com/trac/wiki/ProtocolPEP

And if you're interested in helping, we can figure out a way to do that 
(you can have edit permission on the wiki or we can move the document 
elsewhere, whatever).


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

> (This seems to me like an area where a judicious application of PSF
> funds might help; if every single bug were actively triaged and
> responded to, even if it weren't reviewed, and patch contributors were
> directed to take specific steps to elicit a response or a review, the
> fact that patch reviews take a while might not be so bad.)

I'm skeptical. The current triage process often results in assigning
bugs to somebody, with the entirely unfounded expectation that somebody
then will act on it - unfortunately, both the submitter and the triager
seem to have that expectation.

Unfortunately, it's often not clear what the submitter wants: does she
want to help, or want to get help? For a bug report, I often post a
message "can you provide a patch?", but sometimes, it isn't that clear.

>> At the moment, I'm personally able to perhaps review one issue per week
>> (sometimes less); at this rate, it'll take several years until I get
>> to everything.
> 
> I guess it depends what you mean by "everything", but given that the
> open bug count is actually /increasing/ at a significant rate, I would
> say that you can never possibly get to "everything".

Right, I was trying to put things positively :-)

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Antoine Pitrou

On Sun, 11 Jul 2010 14:59:14 -0400
Glyph Lefkowitz  wrote:
> 
> Guido proposes to give someone interested in IDLE commit access, and 
> hopefully that will help in > this particular area.  But, as I recall, at the 
> last language summit there was quite a bit of
> discussion about how to address the broader issue of patches falling into a 
> black hole.  Is
> anybody working on it?

I think the best way to "work on it" is to work on having more core
developers, possibly with a more diverse range of interests.

> (This seems to me like an area where a judicious application of PSF funds 
> might help; if every
> single bug were actively triaged and responded to, even if it weren't 
> reviewed, and patch
> contributors were directed to take specific steps to elicit a response or a 
> review, the fact that
> patch reviews take a while might not be so bad.)

The operative word being "judicious". It is not obvious who should get
funded, and for what tasks.
Some specific issues (like email in 3.x) are large enough that they can
be the sole focus of a fund grant. But I'm not sure triaging can apply.

(besides, I am wary of making the job of interacting with our users and
contributors a paid position, rather than a collective task.)

> > FWIW, I don't consider a few months as a "long" time for a patch review.
> 
> It may not be a long time compared to other patch reviews, but it is a very 
> long time for a
> volunteer to wait for something, especially if that "something" is "any 
> indication that the
> python developers care that this patch was submitted at all".

Agreed.
Also, the later the response arrives, the likelier it is to be along
the lines of “the patch doesn't apply cleanly anymore, can you write
another one?”.

Regards

Antoine.


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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread A.M. Kuchling

On Sun, Jul 11, 2010 at 05:22:28PM +0300, Tal Einat wrote:
> Initially (five years ago!) I tried to overcome these issues by
> improving IDLE, solving problems and adding a few key features.
> Without going into details, suffice to say that IDLE hasn't improved
> much since 2005 despite my efforts. For example, see

Is it maybe time for another idle-fork project to develop IDLE outside
the stdlib for a while, and then the forked version could be swallowed
wholesale by the Python 3.2 release?

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread R. David Murray

On Sun, 11 Jul 2010 14:59:14 -0400, Glyph Lefkowitz  
wrote:
> On Jul 11, 2010, at 2:37 PM, Martin v. L=F6wis wrote:
> > I can understand that this is frustrating, but please understand that
> > this is not specific to your patches, or to IDLE. Many other patches  on
> > bugs.python.org remain unreviewed for many years. That's because many of
> > the issues are really tricky, and there are very few people who both
> > have the time and the expertise to evaluate them.
> 
> This problem seems to me to be the root cause here.
> 
> Guido proposes to give someone interested in IDLE commit access, and
> hopefully that will help in this particular area.  But, as I recall, at
> the last language summit there was quite a bit of discussion about how
> to address the broader issue of patches falling into a black hole.  Is
> anybody working on it?

As Martin indicated, the biggest single problem is people hours, and
the only way to address that is to get more people involved.

Jesse has started the sprint sponsorship committee.  Presumably at
least some reviewed and committed core patches will come out of that,
as well as hopefully raising the general activity level.  Jesse's effort
is already bearing fruit in that I think many more people are thinking
about holding sprints than has been true in the past.  ("Oh, you mean *I*
could do that?  Cool.")

I and the other triage people have gotten some new triage people
involved.  We've also gotten some new committers.

Ezio Melotti presented a talk on core development at the Italian
Pycon, and will present it again at EuroPython.  Brian Curtin did
a presentation on bug fixing for the Chicago users group and has
turned his presentation into documentation for the Sprint committee.

Dan Buch will be giving a talk on Python development at PyOhio, and
Catherin Devlin has set up other activities at aimed at introducing
people to core development (her "teach me" session, and I'll be leading
the core sprint after the con).

Hopefully all of these activities will put some more people on track
to helping out with issue review, patch development, and, eventually,
becoming committers.

So yes, things are being done.

Anyone who wants to help out or has idea is, of course, welcome :)

> (This seems to me like an area where a judicious application of PSF
> funds might help; if every single bug were actively triaged and
> responded to, even if it weren't reviewed, and patch contributors were
> directed to take specific steps to elicit a response or a review, the
> fact that patch reviews take a while might not be so bad.)

I scanned the commit log, and it looks to me like somewhere around 30
people have been active during the past month.  That's not too bad,
but each of us has specific areas of interest and limited time, and so
bugs outside of those interest areas are more likely to get dropped on
the floor.

So, this is indeed an area where improvement is theoretically possible,
but I'm not sure how we get from here to there.  As you say, one option is
for the PSF to fund people to do it somehow.  (I'd be happy to be one of
those people for some number of hours a week, by the way, but I doubt that
the PSF budget is going to stretch to that kind of ongoing commitment.)

But...if we had *enough* people volunteering, it would indeed be
theoretically possible to consciously spread out the load so that
issues get responded to in a timely fashion with constructive feedback.
I'm not sure how we would structure this, but if someone steps forward to
be organizer/driver, I bet we could come up with something.  (Get lots
of people to *sign up* for a one hour slot of triage work per week?)
I don't think we have enough active volunteers now, but perhaps we
can get there.

It would also be great if every committer could find time to look at
one bug *outside* of their main interest area for every N hours
they spend on their interest area.  (I try to do this, with varying
degrees of success depending on the week.)

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Brett Cannon

On Sun, Jul 11, 2010 at 13:30, R. David Murray  wrote:
> On Sun, 11 Jul 2010 14:59:14 -0400, Glyph Lefkowitz  
> wrote:
>> On Jul 11, 2010, at 2:37 PM, Martin v. L=F6wis wrote:
>> > I can understand that this is frustrating, but please understand that
>> > this is not specific to your patches, or to IDLE. Many other patches  on
>> > bugs.python.org remain unreviewed for many years. That's because many of
>> > the issues are really tricky, and there are very few people who both
>> > have the time and the expertise to evaluate them.
>>
>> This problem seems to me to be the root cause here.
>>
>> Guido proposes to give someone interested in IDLE commit access, and
>> hopefully that will help in this particular area.  But, as I recall, at
>> the last language summit there was quite a bit of discussion about how
>> to address the broader issue of patches falling into a black hole.  Is
>> anybody working on it?
>
> As Martin indicated, the biggest single problem is people hours, and
> the only way to address that is to get more people involved.
>
> Jesse has started the sprint sponsorship committee.  Presumably at
> least some reviewed and committed core patches will come out of that,
> as well as hopefully raising the general activity level.  Jesse's effort
> is already bearing fruit in that I think many more people are thinking
> about holding sprints than has been true in the past.  ("Oh, you mean *I*
> could do that?  Cool.")
>
> I and the other triage people have gotten some new triage people
> involved.  We've also gotten some new committers.
>
> Ezio Melotti presented a talk on core development at the Italian
> Pycon, and will present it again at EuroPython.  Brian Curtin did
> a presentation on bug fixing for the Chicago users group and has
> turned his presentation into documentation for the Sprint committee.
>
> Dan Buch will be giving a talk on Python development at PyOhio, and
> Catherin Devlin has set up other activities at aimed at introducing
> people to core development (her "teach me" session, and I'll be leading
> the core sprint after the con).
>
> Hopefully all of these activities will put some more people on track
> to helping out with issue review, patch development, and, eventually,
> becoming committers.
>
> So yes, things are being done.
>
> Anyone who wants to help out or has idea is, of course, welcome :)
>
>> (This seems to me like an area where a judicious application of PSF
>> funds might help; if every single bug were actively triaged and
>> responded to, even if it weren't reviewed, and patch contributors were
>> directed to take specific steps to elicit a response or a review, the
>> fact that patch reviews take a while might not be so bad.)
>
> I scanned the commit log, and it looks to me like somewhere around 30
> people have been active during the past month.  That's not too bad,
> but each of us has specific areas of interest and limited time, and so
> bugs outside of those interest areas are more likely to get dropped on
> the floor.
>
> So, this is indeed an area where improvement is theoretically possible,
> but I'm not sure how we get from here to there.  As you say, one option is
> for the PSF to fund people to do it somehow.  (I'd be happy to be one of
> those people for some number of hours a week, by the way, but I doubt that
> the PSF budget is going to stretch to that kind of ongoing commitment.)
>

I have a grant in to work on Python full-time for 2-3 months with one
of the focus points being improving the developer docs.

-Brett


> But...if we had *enough* people volunteering, it would indeed be
> theoretically possible to consciously spread out the load so that
> issues get responded to in a timely fashion with constructive feedback.
> I'm not sure how we would structure this, but if someone steps forward to
> be organizer/driver, I bet we could come up with something.  (Get lots
> of people to *sign up* for a one hour slot of triage work per week?)
> I don't think we have enough active volunteers now, but perhaps we
> can get there.
>
> It would also be great if every committer could find time to look at
> one bug *outside* of their main interest area for every N hours
> they spend on their interest area.  (I try to do this, with varying
> degrees of success depending on the week.)
>
> --
> R. David Murray                                      www.bitdance.com
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Michael Foord


On 11/07/2010 20:47, A.M. Kuchling wrote:

On Sun, Jul 11, 2010 at 05:22:28PM +0300, Tal Einat wrote:
   

Initially (five years ago!) I tried to overcome these issues by
improving IDLE, solving problems and adding a few key features.
Without going into details, suffice to say that IDLE hasn't improved
much since 2005 despite my efforts. For example, see
 

Is it maybe time for another idle-fork project to develop IDLE outside
the stdlib for a while, and then the forked version could be swallowed
wholesale by the Python 3.2 release?
   


Whilst I would *really* like to see bugfixes and minor improvements in 
functionality incorporated back into IDLE (who wouldn't?) I think it is 
important that IDLE remains focused on its nice of being a "simple" or 
"beginners" IDE, without trying to become a full blown IDE that is even 
harder for us to maintain.


Speaking of which, the IDLE.app that comes with Python 2.7 for Mac OS X 
isn't working for me. Anyone else seeing that?


All the best,

Michael Foord


--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Georg Brandl

Am 11.07.2010 20:59, schrieb Glyph Lefkowitz:
> 
> On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:
> 
>>> Initially (five years ago!) I tried to overcome these issues by
>>> improving IDLE, solving problems and adding a few key features.
>>> Without going into details, suffice to say that IDLE hasn't improved
>>> much since 2005 despite my efforts. For example, see
>>> http://bugs.python.org/issue1529142, where it took nearly 3 years to
>>> fix a major issue from the moment I posted the first workaround. For
>>> another example, see http://bugs.python.org/issue3068, where I posted
>>> a patch for an extension configuration dialog over two years ago, and
>>> it hasn't received as much as a sneeze in response.
>>
>> I can understand that this is frustrating, but please understand that
>> this is not specific to your patches, or to IDLE. Many other patches on
>> bugs.python.org  remain unreviewed for many years.
>> That's because many of
>> the issues are really tricky, and there are very few people who both
>> have the time and the expertise to evaluate them.
> 
> This problem seems to me to be the root cause here.
> 
> Guido proposes to give someone interested in IDLE commit access, and hopefully
> that will help in this particular area.  But, as I recall, at the last 
> language
> summit there was quite a bit of discussion about how to address the broader
> issue of patches falling into a black hole.  Is anybody working on it?
> 
> (This seems to me like an area where a judicious application of PSF funds 
> might
> help; if every single bug were actively triaged and responded to, even if it
> weren't reviewed, and patch contributors were directed to take specific steps 
> to
> elicit a response or a review, the fact that patch reviews take a while might
> not be so bad.)

Honestly, how would you feel as a committer to have scores of issues assigned
to you -- as a consequence of speedy triage -- knowing that you have to invest
potentially hours of volunteer time into them, while the person doing the
triaging is done with the bug in a few minutes and paid for it?  I'd feel a
little bit duped.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Nick Coghlan

On Mon, Jul 12, 2010 at 6:30 AM, R. David Murray  wrote:
> So, this is indeed an area where improvement is theoretically possible,
> but I'm not sure how we get from here to there.  As you say, one option is
> for the PSF to fund people to do it somehow.  (I'd be happy to be one of
> those people for some number of hours a week, by the way, but I doubt that
> the PSF budget is going to stretch to that kind of ongoing commitment.)

One problem that can arise is that when the active maintainer for a
particular area gets caught up in other things (e.g. KBK for Idle in
this particular case - added directly to cc list), then the commit
rate for that area drastically slows down. Other committers have
become accustomed to deferring to the judgement of the active
maintainer, so if that judgement isn't forthcoming, then things don't
go in.

As a community of volunteers, obviously the amount of time we can
devote to Python varies based on other commitments. Perhaps we need to
encourage active maintainers to be more proactive about identifying
folks that regularly submit good patches that may be candidates for
commit access in that area. Otherwise, when an active maintainer's
time is taken up by other things there's an understandable reluctance
to tread on an active maintainer's toes by bypassing them and giving
the task to someone else. Not only that, but the current maintainer is
usually in the best position to judge the quality of submitted
patches, as they're the most familiar with the code in question.

While there are many areas of the standard library that don't even
have *one* designated maintainer at this point in time, our goal
should probably be to try to reach the point of having at least two
maintainers for each area so that one person getting busy doesn't halt
progress.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Bruce Sherwood

Perhaps there are two separable issues. Many of us see it as extremely
important that some IDLE be part of the standard Python distribution
("batteries included"), for the reasons that several people have given.
However, there is merit to the suggestion to have an active separate
development, with the understanding that periodically this separate
development is a candidate for inclusion in the standard distribution,
replacing whatever IDLE had been there.

In the 2009 Google Summer of Code I was the mentor for a Brazilian
student, Guilherme
Polo, who completed and extended important improvements to IDLE made during
the previous year by David Scherer. Given the somewhat official nature of
this work, I assumed that these needed improvements would make it into the
standard distribution, but as far as I know that hasn't happened. It would
seem that if even this "sponsored" project didn't impact the standard Python
distribution, something is broken in the procedures, and probably what is
needed is, as Guido says, that someone be given the authority to get
improvements to IDLE into the standard distribution. Making a significant
change to the update procedures is clearly needed.

Even if this needed change is made, there is also merit to Tai's suggestion
of creating a separate project, to encourage developers like him to work
together to improve IDLE, without having as a first priority to worry about
getting it into the standard distribution, but with the clear understanding
that this is the place to go for improvements to migrate into the standard
distribution.

Bruce Sherwood

P.S. I'll add that IDLE has been EXTREMELY important for a large population
of relatively casual users of Python, the thousands of science and
engineering university students enrolled in the "Matter & Interactions"
intro physics curriculum developed by Ruth Chabay and me (
matterandinteractions.org). A major feature of this curriculum is a serious
introduction to computational modeling, in which students write short Python
programs to model physical systems. Computational modeling is now central to
all of science and engineering but alas has not made its way into
undergraduate curricula in an institutionalized way.

A big difficulty is that students come to college knowledgeable about all
aspects of computers save one: programming. So the programming environment
has to be exceptionally easy to learn and use. Python itself has the
necessary properties, and Python+Visual (called VPython, vpython.org) lets
the students focus on the physics while VPython generates real-time
navigable 3D animations of the computational models, as a side effect of the
computational code.

IDLE has proved to be the right editing tool for this population, as
essentially nothing needs to be learned, and there is near-instantaneous
edit/run transitions which encourage rapid testing. In a physics course we
have to focus on strict minimalism as far as the programming is concerned.
We teach a bare minimum of needed concepts; for example, we introduce while
loops but not for loops. We cannot afford to teach about a professional IDE;
IDLE is fine and has worked well for us. (We're currently bundling with
VPython the Scherer/Polo version of IDLE, which for reasons of clarity we're
calling VIDLE.)

A final personal note is that while I use Eclipse for working on the Visual
module, which is written in C++, I find VIDLE a delightful environment for
developing Python programs for physics education.
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

> In the 2009 Google Summer of Code I was the mentor for a Brazilian
> student, Guilherme Polo, who completed and extended important
> improvements to IDLE made during the previous year by David Scherer.
> Given the somewhat official nature of this work, I assumed that these
> needed improvements would make it into the standard distribution, but as
> far as I know that hasn't happened. It would seem that if even this
> "sponsored" project didn't impact the standard Python distribution,
> something is broken in the procedures, and probably what is needed is,
> as Guido says, that someone be given the authority to get improvements
> to IDLE into the standard distribution. Making a significant change to
> the update procedures is clearly needed.

I don't think so; instead, the perception of authority needs to be
adjusted (in the specific case). Guilherme could have committed these
changes, but, for whatever reason, decided not to. Nor did his direct
mentor (i.e. you) tell him to commit the changes, and neither did I.

> Even if this needed change is made, there is also merit to Tai's
> suggestion of creating a separate project, to encourage developers like
> him to work together to improve IDLE, without having as a first priority
> to worry about getting it into the standard distribution, but with the
> clear understanding that this is the place to go for improvements to
> migrate into the standard distribution.

Again, Guilherme could commit his changes any time.

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

Re: [Python-Dev] Removing IDLE from the standard library

Martin v. Löwis wrote:
>> Initially (five years ago!) I tried to overcome these issues by
>> improving IDLE, solving problems and adding a few key features.
>> Without going into details, suffice to say that IDLE hasn't improved
>> much since 2005 despite my efforts. For example, see
>> http://bugs.python.org/issue1529142, where it took nearly 3 years to
>> fix a major issue from the moment I posted the first workaround. For
>> another example, see http://bugs.python.org/issue3068, where I posted
>> a patch for an extension configuration dialog over two years ago, and
>> it hasn't received as much as a sneeze in response.
>
> I can understand that this is frustrating, ...

I am not writing this to vent my frustration, and have purposely
avoided making that the issue.

> ... but please understand that
> this is not specific to your patches, or to IDLE. Many other patches on
> bugs.python.org remain unreviewed for many years. That's because many of
> the issues are really tricky, and there are very few people who both
> have the time and the expertise to evaluate them.

I am aware of the situation with regard to issue reviews, but I think
with IDLE there is more going on. In other parts of the Python
codebase, a workaround for a major usability issue wouldn't normally
have taken nearly three years to resolve after a working patch was
submitted. And a working, well-tested patch wouldn't normally have sat
ignored for over two years. Well, perhaps these things happen
occasionally, but with IDLE this is the norm.

> FWIW, I don't consider a few months as a "long" time for a patch review.
> At the moment, I'm personally able to perhaps review one issue per week
> (sometimes less); at this rate, it'll take several years until I get
> to everything.

I'm not talking about a few months, I'm talking about at least six
months in most cases, years in many cases, as in the examples I
mentioned.

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

> I am aware of the situation with regard to issue reviews, but I think
> with IDLE there is more going on. In other parts of the Python
> codebase, a workaround for a major usability issue wouldn't normally
> have taken nearly three years to resolve after a working patch was
> submitted.

Oh sure it does. Just look at all the cross-compilation bug reports and
patches that get submitted.

> And a working, well-tested patch wouldn't normally have sat
> ignored for over two years. Well, perhaps these things happen
> occasionally, but with IDLE this is the norm.

Unfortunately, they happen more often than you think.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Guilherme Polo

2010/7/11 "Martin v. Löwis" :
>> In the 2009 Google Summer of Code I was the mentor for a Brazilian
>> student, Guilherme Polo, who completed and extended important
>> improvements to IDLE made during the previous year by David Scherer.
>> Given the somewhat official nature of this work, I assumed that these
>> needed improvements would make it into the standard distribution, but as
>> far as I know that hasn't happened. It would seem that if even this
>> "sponsored" project didn't impact the standard Python distribution,
>> something is broken in the procedures, and probably what is needed is,
>> as Guido says, that someone be given the authority to get improvements
>> to IDLE into the standard distribution. Making a significant change to
>> the update procedures is clearly needed.
>
> I don't think so; instead, the perception of authority needs to be
> adjusted (in the specific case). Guilherme could have committed these
> changes, but, for whatever reason, decided not to. Nor did his direct
> mentor (i.e. you) tell him to commit the changes, and neither did I.
>
>> Even if this needed change is made, there is also merit to Tai's
>> suggestion of creating a separate project, to encourage developers like
>> him to work together to improve IDLE, without having as a first priority
>> to worry about getting it into the standard distribution, but with the
>> clear understanding that this is the place to go for improvements to
>> migrate into the standard distribution.
>
> Again, Guilherme could commit his changes any time.
>
> Regards,
> Martin

I think Martin has always supported me in some way and I really
appreciate that. But, maybe because I won commit privileges solely
based on GSoC work, I felt other developers wouldn't approve my
commits without previous discussion and that is the major reason for
not committing most of my patches.

-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

Glyph Lefkowitz wrote:
>
> On Jul 11, 2010, at 10:22 AM, Tal Einat wrote:
>
> The people who are actually *in* those environments seem to disagree with
> you :).  I think you underestimate the difficulty of getting software
> installed and overestimate the demands of new Python users and students.
> While I don't ever use IDLE if there's an alternative available, I have been
> very grateful many times for its presence in environments where it was a
> struggle even to say "install Python".  A workable editor and graphical
> shell is important, whatever its flaws.  (And I think you exaggerate IDLE's
> flaws just a bit.)

I would like to note that I am one of those in those environments.

I have used IDLE to teach Python to new users, and their opinion of
IDLE (and Python as a consequence) wasn't great, precisely because of
the bugs and quirks. Recently I have stopped recommending IDLE for
beginners and have found that this avoids quite a few snags, which is
significant.

I have also been in environments where installing anything was
problematic and having IDLE available out-of-the-box was supposed to
be a clear win. I certainly used it, but all of my coworkers
(experienced Pythonistas who have worked with IDLE before) ended up
preferring the basic interpreter and text editors such as vim, despite
my advocacy of IDLE, because they tired of IDLE's snags (e.g. the
inability to run several instances in parallel).

My point is that I don't think I am exaggerating IDLE's flaws. I'm not
saying that it is no longer usable or useful, but I am saying that its
current state is not "okay".

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

> I think Martin has always supported me in some way and I really
> appreciate that. But, maybe because I won commit privileges solely
> based on GSoC work, I felt other developers wouldn't approve my
> commits without previous discussion and that is the major reason for
> not committing most of my patches.

I'm not blaming you for that; I can fully understand how you feel
and how things came about.

I was just refuting the claim that something was fundamentally wrong,
when, among us three, there was just somebody failing to say "go ahead"
(and I'd like to stress that *either* of us three could have said that).

So: go ahead. I won't have the time to review your changes in detail,
and nobody else will, so just put them in, and we wait for people to
complain (in which case I'd hope that you would be around to respond
quickly - as you did in the past).

If there is also Tk patches involved, please do have them reviewed,
though.

Regards,
Martin

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Ron Adam




On 07/10/2010 06:05 PM, Tal Einat wrote:

Hello,

I would like to propose removing IDLE from the standard library.

I have been using IDLE since 2002 and have been doing my best to help
maintain and further develop IDLE since 2005.

In recent years IDLE has received negligible interest and attention from
the Python community. During this time IDLE has slowly gone downhill.
The documentation and tutorials grow increasingly out of date.
Cross-platform support has degraded with the increasing popularity of
OSX and 64-bit platforms. Bugs take months, and sometimes more than a
year, to be solved. Features that have since become common-place, such
as having a non-intrusive search box instead of a dialog, are obviously
and painfully lacking, making IDLE feel clumsy and out-dated.

For these reasons, I think it would be fitting to remove IDLE from the
standard library. IDLE is no longer recommended to beginners, IMO
rightfully so, and this was the main reason for its inclusion in the
standard library. Furthermore, if there is little or no interest in
developing and maintaining IDLE, it should be removed to avoid having
buggy and badly supported software in the standard library.



There might be another alternative.

Both idle and pydoc are applications (are there others?) that are in the 
standard library.  As such, they or parts of them, are possibly importable 
to other projects.  That restricts changes because a committer needs to 
consider the chances that a change may break something else.


I suggest they be moved out of the lib directory, but still be included 
with python.  (Possibly in the tools directory.)  That removes some of the 
backward compatibility restrictions or at least makes it clear there isn't 
a need for backward compatibility.


Would a change of this sort help make things any easier?

(Note: idle isn't in the lib directory on Ubuntu.)

Ron

___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

Guilherme Polo wrote:
> 2010/7/11 "Martin v. Löwis" :
>>> In the 2009 Google Summer of Code I was the mentor for a Brazilian
>>> student, Guilherme Polo, who completed and extended important
>>> improvements to IDLE made during the previous year by David Scherer.
>>> Given the somewhat official nature of this work, I assumed that these
>>> needed improvements would make it into the standard distribution, but as
>>> far as I know that hasn't happened. It would seem that if even this
>>> "sponsored" project didn't impact the standard Python distribution,
>>> something is broken in the procedures, and probably what is needed is,
>>> as Guido says, that someone be given the authority to get improvements
>>> to IDLE into the standard distribution. Making a significant change to
>>> the update procedures is clearly needed.
>>
>> I don't think so; instead, the perception of authority needs to be
>> adjusted (in the specific case). Guilherme could have committed these
>> changes, but, for whatever reason, decided not to. Nor did his direct
>> mentor (i.e. you) tell him to commit the changes, and neither did I.
>>
>>> Even if this needed change is made, there is also merit to Tai's
>>> suggestion of creating a separate project, to encourage developers like
>>> him to work together to improve IDLE, without having as a first priority
>>> to worry about getting it into the standard distribution, but with the
>>> clear understanding that this is the place to go for improvements to
>>> migrate into the standard distribution.
>>
>> Again, Guilherme could commit his changes any time.
>>
>> Regards,
>> Martin
>
> I think Martin has always supported me in some way and I really
> appreciate that. But, maybe because I won commit privileges solely
> based on GSoC work, I felt other developers wouldn't approve my
> commits without previous discussion and that is the major reason for
> not committing most of my patches.

FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's
project of the same name, in a sense). The idea was to have a fork of
IDLE with new features which need to be tried out by "beta testers" to
iron out all of the glitches before making it into the main version,
like IDLE-fork back in the beginning of the decade. However I have
utterly failed in promoting this project and getting "beta testers" on
board, at least partially due to the lack of interest from the
community (and admittedly my lack of PR skills).

- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

> My point is that I don't think I am exaggerating IDLE's flaws. I'm not
> saying that it is no longer usable or useful, but I am saying that its
> current state is not "okay".

So can you produce a list of patches that you think can be accepted as-is?

Preferably, make to lists: bug fixes, and new features. The bug fixes
could be either for 2.x or 3.x; the new features would preferably be
for just 3.x.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's
> project of the same name, in a sense). The idea was to have a fork of
> IDLE with new features which need to be tried out by "beta testers" to
> iron out all of the glitches before making it into the main version,
> like IDLE-fork back in the beginning of the decade. However I have
> utterly failed in promoting this project and getting "beta testers" on
> board, at least partially due to the lack of interest from the
> community (and admittedly my lack of PR skills).

I think such a thing must inherently fail - precisely for these reasons.

It's much better to release proposed new features along with Python,
and wait for feedback. Users won't start trying things out until after
the release. This is a general problem, and lead Barry Warsaw to believe
that "release candidates" are an utter waste of time.

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

Re: [Python-Dev] Removing IDLE from the standard library

On 11/07/2010 19:59, Glyph Lefkowitz wrote:

On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:

Initially (five years ago!) I tried to overcome these issues by
improving IDLE, solving problems and adding a few key features.
Without going into details, suffice to say that IDLE hasn't improved
much since 2005 despite my efforts. For example, see
http://bugs.python.org/issue1529142, where it took nearly 3 years to
fix a major issue from the moment I posted the first workaround. For
another example, see http://bugs.python.org/issue3068, where I posted
a patch for an extension configuration dialog over two years ago, and
it hasn't received as much as a sneeze in response.

I can understand that this is frustrating, but please understand that
this is not specific to your patches, or to IDLE. Many other patches on
bugs.python.org remain unreviewed for many years. That's because many of
the issues are really tricky, and there are very few people who both
have the time and the expertise to evaluate them.

This problem seems to me to be the root cause here.

Guido proposes to give someone interested in IDLE commit access, and hopefully
that will help in this particular area. But, as I recall, at the last language
summit there was quite a bit of discussion about how to address the broader
issue of patches falling into a black hole. Is anybody working on it?

(This seems to me like an area where a judicious application of PSF funds might
help; if every single bug were actively triaged and responded to, even if it
weren't reviewed, and patch contributors were directed to take specific steps
to elicit a response or a review, the fact that patch reviews take a while
might not be so bad.)

FWIW, I don't consider a few months as a "long" time for a patch review.

It may not be a long time compared to other patch reviews, but it is a very long time for a
volunteer to wait for something, especially if that "something" is "any indication
that the python developers care that this patch was submitted at all".

There seems to be at least one thread a month on this list from a disgruntled
community member complaining (directly or indirectly) about this delay. I
think that makes it a big problem.

At the moment, I'm personally able to perhaps review one issue per week
(sometimes less); at this rate, it'll take several years until I get
to everything.

I guess it depends what you mean by "everything", but given that the open bug count is
actually increasing at a significant rate, I would say that you can never possibly get to
"everything".

___
IDLE-dev mailing list
idle-...@python.org
http://mail.python.org/mailman/listinfo/idle-dev

I have been attempting to fill this hole and have been faced with
animosity from people who "hang out" on the python-dev IRC channel. I
thought it was a complete and utter waste of space, so I don't intend
going back. I would like things fixed, not a cosy little "who's round
is it next" mentality from the triage team. IMHO if they spent more
time doing things, and less time talking crap via IRC, things might get
done. And before anyone says anything, I have been a former MBCS and
CEng and only gave up cos I couldn't afford the annual fees cos of my
health.

Kindest regards.

Mark Lawrence

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

Re: [Python-Dev] Removing IDLE from the standard library


On 11/07/2010 23:18, Tal Einat wrote:

Martin v. Löwis wrote:

Initially (five years ago!) I tried to overcome these issues by
improving IDLE, solving problems and adding a few key features.
Without going into details, suffice to say that IDLE hasn't improved
much since 2005 despite my efforts. For example, see
http://bugs.python.org/issue1529142, where it took nearly 3 years to
fix a major issue from the moment I posted the first workaround. For
another example, see http://bugs.python.org/issue3068, where I posted
a patch for an extension configuration dialog over two years ago, and
it hasn't received as much as a sneeze in response.


I can understand that this is frustrating, ...


I am not writing this to vent my frustration, and have purposely
avoided making that the issue.


... but please understand that
this is not specific to your patches, or to IDLE. Many other patches on
bugs.python.org remain unreviewed for many years. That's because many of
the issues are really tricky, and there are very few people who both
have the time and the expertise to evaluate them.


I am aware of the situation with regard to issue reviews, but I think
with IDLE there is more going on. In other parts of the Python
codebase, a workaround for a major usability issue wouldn't normally
have taken nearly three years to resolve after a working patch was
submitted. And a working, well-tested patch wouldn't normally have sat
ignored for over two years. Well, perhaps these things happen
occasionally, but with IDLE this is the norm.


FWIW, I don't consider a few months as a "long" time for a patch review.
At the moment, I'm personally able to perhaps review one issue per week
(sometimes less); at this rate, it'll take several years until I get
to everything.


I'm not talking about a few months, I'm talking about at least six
months in most cases, years in many cases, as in the examples I
mentioned.

- Tal Einat


I can understand your frustration, but in response to an appeal from 
Terry Reedy some weeks back on c.l.py I've done a substantial amount of 
work in the last couple of weeks to clear outstanding issues, sadly IDLE 
just sits in the pile.  Ow, but hang on a minute,  I've already 
volunteered TJR to take this on, I believe he's up for it, I'll support 
him up to the hilt, so why the hell can't we get on with it?  Or would 
the triage team as it stands object cos they'll be put out of a job? :)


Kindest regards.

Mark Lawrence.

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

Re: [Python-Dev] Removing IDLE from the standard library

2010/7/11 Mark Lawrence :
>
> I have been attempting to fill this hole and have been faced with animosity
> from people who "hang out" on the python-dev IRC channel.  I thought it was
> a complete and utter waste of space, so I don't intend going back.  I would
> like things fixed, not a cosy little "who's round is it next" mentality from
> the triage team.  IMHO if they spent more time doing things, and less time
> talking crap via IRC, things might get done.  And before anyone says
> anything, I have been a former MBCS and CEng and only gave up cos I couldn't
> afford the annual fees cos of my health.

What exactly is the "who's round is it next" mentality?


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

Re: [Python-Dev] Removing IDLE from the standard library


On 11/07/2010 19:40, "Martin v. Löwis" wrote:

There clearly are *some* folks who care enough about IDLE to submit
bug reports and fixes. How about we empower these people by giving at
least one of them commit privileges? IDLE development has often been
done by people who aren't otherwise contributing to the core, and we
surely should trust those folks with commit privileges.



Can I take a really big liberty and volunteer Terry Reedy for the job.


It doesn't work that way. You can't volunteer somebody else (*).

If Terry would volunteer himself, he'd get commit access in no time.

Regards,
Martin

(*) so when you assign bugs to me, it probably means that they get less
attention, not more.


Martin,

Thanks for your response.

IIRC Terry Reedy has already volunteered to do this, if I'm incorrect 
I'll apologise right now to both of you.


As for assigning bugs, I've been told to use the maintainer.rst list, so 
either the list is wrong, or I've had finger problems.  If it's the 
latter I again say sorry.


Kindest regards.

Mark Lawrence

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

Re: [Python-Dev] Removing IDLE from the standard library

2010/7/11 Mark Lawrence :
> I can understand your frustration, but in response to an appeal from Terry
> Reedy some weeks back on c.l.py I've done a substantial amount of work in
> the last couple of weeks to clear outstanding issues, sadly IDLE just sits
> in the pile.  Ow, but hang on a minute,  I've already volunteered TJR to
> take this on, I believe he's up for it, I'll support him up to the hilt, so
> why the hell can't we get on with it?  Or would the triage team as it stands
> object cos they'll be put out of a job? :)

And as Martin has already noted, only Terry can volunteer himself.


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

Re: [Python-Dev] Can ftp url start with file:// ?

2010-07-11 Thread Steven D'Aprano

On Mon, 12 Jul 2010 12:01:07 am Steve Holden wrote:
> My own inclination would be to regard the current treatment of file:
> as a bug (albeit one not worth fixing on 2.x). 
...
> Presumably a 
> hostname in such a URI would require that some host-specific protocol
> be used (but this should be an access protocol like SMB or NFS, not a
> transfer protocol like FTP).

KDE uses SMB for non-local hostnames in file URIs.

> It seems pretty clear that randomly interpreting particular host
> names to imply a specific remote-access protocol like FTP is bogus.

Agreed. The right behaviour is to raise an exception and let the caller 
deal with it, or provide a means to register an alternative.



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New regex module for 3.2?

2010-07-11 Thread Steven D'Aprano

On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote:
> > re2 comparison is interesting from the point of if it should be
> > included in stdlib.
>
> Is "it" re2 or regex? I don't see having 2 regular expression engines
> in the stdlib.

There's precedence though... the old regex engine and the new re engine 
were side-by-side for many years before regex was deprecated and 
finally removed in 2.5. Hypothetically, re2 could similarly be added to 
the standard library while re is deprecated.

-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 3:19 PM, Martin v. Löwis wrote:

> Unfortunately, it's often not clear what the submitter wants: does she
> want to help, or want to get help? For a bug report, I often post a
> message "can you provide a patch?", but sometimes, it isn't that clear.

Perhaps this is the one area where the biggest advance could be made: a 
clarification of the workflow.

My experience with Python issues which have been "triaged" is that everyone who 
triages tickets has a slightly different idea of who is responsible for the 
ticket and what they're supposed to do next at every point in the process.  
Triage, as described on , emphasizes 
making sure "that all fields in the issue tracker are properly set", rather 
than on communicating with the contributor or reporter.

On Twisted, we try to encourage triagers to focus on communicating the workflow 
ramifications of what a particular contributor has done.  We try to provide a 
response to the bug reporter or patch submitter that says "thanks, but in order 
to move this along, you need to go through the following steps" and sometimes 
even attach a link to the workflow document pointing out exactly where in the 
process the ticket is now stuck.  (At least, that's what we're trying to do.)

This involves a lot of repeating ourselves in ticket comments, but it's well 
worth it (and as more of the repetition moves into citing links to documents 
that have been written to describe aspects of the workflow, it's less onerous).

 describes what the steps are, but it's in 
a sort of procedural passive voice that doesn't say who is responsible for 
doing reviews or how to get a list of patches which need to be reviewed or what 
exactly a third-party non-core-committer reviewer should do to remove the 
'Patch review' keyword.

 and 
 meander around a bit, but a 
while ago we re-worked them so that each section has a specific audience 
(authors, reviewers, or external patch submitters) and that helped readers 
understand what they're intended to do.

Plus,  is a useful resource for core 
developers with only a little bit of free time to do a review.

(I'm just offering some suggestions based on what I think has worked, not to 
hold Twisted up as a paragon of a perfect streamlined process.  We still have 
folks complain about stuck patches, these documents are _far_ from perfect, and 
there are still some varying opinions about how certain workflow problems 
should be dealt with and differences in quality of review.  Plus, we have far 
fewer patches to deal with than Python.  Nevertheless, the situation used to be 
worse for us, and these measures seem to have helped.)___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 5:33 PM, Georg Brandl wrote:

> Honestly, how would you feel as a committer to have scores of issues assigned
> to you -- as a consequence of speedy triage -- knowing that you have to invest
> potentially hours of volunteer time into them, while the person doing the
> triaging is done with the bug in a few minutes and paid for it?  I'd feel a
> little bit duped.

That doesn't strike me as a particularly useful type of triage.

The most useful type of triage in this case would be the kind where the bug 
gets re-assigned to the *original contributor*, not a core committer, with a 
message clearly saying "thanks!  but we will not do anything further with this 
ticket until *you* do XYZ."  This may result in some tickets getting left by 
wayside, but at least it will be clear that they have been left by the wayside, 
and whose responsibility they really are.

Even so, I would certainly feel better having scores of issues assigned to me 
than I would feel having scores of issues that are just hanging out in limbo 
forever.

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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Steve Holden

Stephen Hansen wrote:
> On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo  > wrote:
> 
> By "never had a problem" do you mean using some of the latest versions
> ? Here, running "idle" from a mac terminal and trying to type: print
> "hi" crashes when entering the quotation mark. 
> 
> 
> Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel.
> 
One of the good things about the python-dev community is its commitment
to test-driven development. If you are prepared to define "fine" as
'successfully runs \'print "hello"\'' then I guess we should be
perfectly happy about IDLE.

> From the lurking crowd-- Please don't consider removing IDLE until there
> is a compelling replacement ready. It's better to have a limited IDE
> that works everywhere (even if in a limited fashion-- people are free to
> try out one of the many excellent full-featured Python IDE's out there
> after they advance to that point) then not.
> 
1: I refuse to see why we need a "compelling replacement" for a piece of
software whose performance might be actively deterring people from
taking up the language. ["Have you thought about Python?" "Yeah, but I
tried it {meaning "I downloaded some random Python release and tried
IDLE, which by modern standards appears completely lame"} and it
sucked". If this is our standard for "compelling" then it appears the
command-line interpreter is the competition.

2: Correct me if I am wrong, but isn't the implied promise of including
something in the stdlib that there will be active maintainers? If that's
the case then we need to either recruit more active maintainers than the
package currently has or look at dropping it.

3: If IDLE *is* going to be dropped from the stdlib it should be
deprecated first just like anything else.

4: It's all very well chastising "the development community" because
IDLE issues get assigned to kbk and nothing happens about them, but it's
not like kbk is receiving any kind of rewards for working on these
tickets, and precious little indication that anyone else is prepared to
roll up their sleeves and ask to take over the tickets [apologies to
anyone who has actually done this and been rebuffed] to get them fixed
quicker.

5: Decide for yourself whether I am one of "the lurking crowd". I teach
Python classes for a living (among other things) and invest quite a bit
of time in the Python community one way or the other. I am not a Mac
user, but another instructor I have employed is, and he has discussed
with Mac users exactly how deficient the IDLE environment is when
compared with standard Mac utilities.

6: When I give students a free choice of the development environment,
they often choose IDLE "because it comes with Python". This usually
results in a certain amount of discussion and comparison with tools like
Wing, PythonWin and so on. Which in itself isn't a bad thing, but IDLE
complares so badly with the other products that I sometimes feel Python
suffers by association.

IDLE has simplicity on its side, but every way it interacts with the
user appears to be non-standard for most platforms. It needs some
maintenance, but I don't see where that's going to come from.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] Removing IDLE from the standard library


> IIRC Terry Reedy has already volunteered to do this

Hmm. I don't recall that happening.

> As for assigning bugs, I've been told to use the maintainer.rst list, so
> either the list is wrong, or I've had finger problems.  If it's the
> latter I again say sorry.

I see. What copy have you been using specifically? I think I need to
remove myself from these lists.

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

Re: [Python-Dev] Removing IDLE from the standard library


On 12/07/2010 00:56, "Martin v. Löwis" wrote:



IIRC Terry Reedy has already volunteered to do this

Apologies to Terry if this is incorrect, but I believe this to be the case.


Hmm. I don't recall that happening.


As for assigning bugs, I've been told to use the maintainer.rst list, so
either the list is wrong, or I've had finger problems.  If it's the
latter I again say sorry.


I see. What copy have you been using specifically? I think I need to
remove myself from these lists.

Regards,
Martin


Hi Martin,

Again thanks for the response.

I've been working from this:-
http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers.rst

It strikes me as being so sadly outdated that it's getting less than 
useless, or I assume that it's the same old case of not enough 
volunteers?  Why did I bother. :)


Kindest regards.

Mark Lawrence.



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

Re: [Python-Dev] Removing IDLE from the standard library

On Sun, Jul 11, 2010 at 7:13 PM, Mark Lawrence  wrote:

>
> Martin,
>
> Thanks for your response.
>
> IIRC Terry Reedy has already volunteered to do this, if I'm incorrect I'll
> apologise right now to both of you.
>
> As for assigning bugs, I've been told to use the maintainer.rst list, so
> either the list is wrong, or I've had finger problems.  If it's the latter I
> again say sorry.
>
> Kindest regards.
>
> Mark Lawrence

Hey Mark - I've noticed some of your cleanup/triaging in my bug queue
at least (multiprocessing) and I thought I'd thank you - I didn't know
who you were!

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread geremy condra

On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou  wrote:
> On Sun, 11 Jul 2010 14:59:14 -0400
> Glyph Lefkowitz  wrote:
>>
>> Guido proposes to give someone interested in IDLE commit access, and 
>> hopefully that will help in > this particular area.  But, as I recall, at 
>> the last language summit there was quite a bit of
>> discussion about how to address the broader issue of patches falling into a 
>> black hole.  Is
>> anybody working on it?
>
> I think the best way to "work on it" is to work on having more core
> developers, possibly with a more diverse range of interests.
>
>> (This seems to me like an area where a judicious application of PSF funds 
>> might help; if every
>> single bug were actively triaged and responded to, even if it weren't 
>> reviewed, and patch
>> contributors were directed to take specific steps to elicit a response or a 
>> review, the fact that
>> patch reviews take a while might not be so bad.)
>
> The operative word being "judicious". It is not obvious who should get
> funded, and for what tasks.
> Some specific issues (like email in 3.x) are large enough that they can
> be the sole focus of a fund grant. But I'm not sure triaging can apply.

I'm mulling over starting a monthly triage sprint under the auspices of
Jesse Noeller's PSF sponsored sprints in the hopes of making this a
little more fun. I'd appreciate comments on the idea.

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread geremy condra

On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
> On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou  wrote:
>> On Sun, 11 Jul 2010 14:59:14 -0400
>> Glyph Lefkowitz  wrote:
>>>
>>> Guido proposes to give someone interested in IDLE commit access, and 
>>> hopefully that will help in > this particular area.  But, as I recall, at 
>>> the last language summit there was quite a bit of
>>> discussion about how to address the broader issue of patches falling into a 
>>> black hole.  Is
>>> anybody working on it?
>>
>> I think the best way to "work on it" is to work on having more core
>> developers, possibly with a more diverse range of interests.
>>
>>> (This seems to me like an area where a judicious application of PSF funds 
>>> might help; if every
>>> single bug were actively triaged and responded to, even if it weren't 
>>> reviewed, and patch
>>> contributors were directed to take specific steps to elicit a response or a 
>>> review, the fact that
>>> patch reviews take a while might not be so bad.)
>>
>> The operative word being "judicious". It is not obvious who should get
>> funded, and for what tasks.
>> Some specific issues (like email in 3.x) are large enough that they can
>> be the sole focus of a fund grant. But I'm not sure triaging can apply.
>
> I'm mulling over starting a monthly triage sprint under the auspices of
> Jesse Noeller's PSF sponsored sprints in the hopes of making this a
> little more fun. I'd appreciate comments on the idea.
>
> Geremy Condra
>

Apologies, Jesse, I thought your name had an extra 'e' in it.

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

On Sun, Jul 11, 2010 at 8:07 PM, Mark Lawrence  wrote:

>>
>> I see. What copy have you been using specifically? I think I need to
>> remove myself from these lists.
>>
>> Regards,
>> Martin
>
> Hi Martin,
>
> Again thanks for the response.
>
> I've been working from this:-
> http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers.rst
>
> It strikes me as being so sadly outdated that it's getting less than
> useless, or I assume that it's the same old case of not enough volunteers?
>  Why did I bother. :)
>
> Kindest regards.
>
> Mark Lawrence.

That file is too young to be out of date, and like I said, I've found
the help useful Mark, so I wouldn't throw your hands up. That file
should probably be updated/refreshed as people want, the idea behind
it was to build a table of experts or people who voluntarily sign up
to be the more active maintainers for a domain or standard library
module.

I maintain the idea is a good one - even if Martin wants off due to
lack of time, it's important for people who are just coming in, such
as Mark, to have some idea of where or *who* to talk to about
something specific. We can obviously see the frightening number of
gaps we have for "specific" maintainers.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New regex module for 3.2?

2010-07-11 Thread geremy condra

On Sun, Jul 11, 2010 at 7:42 PM, Steven D'Aprano  wrote:
> On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote:
>> > re2 comparison is interesting from the point of if it should be
>> > included in stdlib.
>>
>> Is "it" re2 or regex? I don't see having 2 regular expression engines
>> in the stdlib.
>
> There's precedence though... the old regex engine and the new re engine
> were side-by-side for many years before regex was deprecated and
> finally removed in 2.5. Hypothetically, re2 could similarly be added to
> the standard library while re is deprecated.

While I realize I'm not the target audience for this, there are a lot
of things I'd like to see more in the stdlib than a second re engine.

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
> On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou  wrote:
>> On Sun, 11 Jul 2010 14:59:14 -0400
>> Glyph Lefkowitz  wrote:
>>>
>>> Guido proposes to give someone interested in IDLE commit access, and 
>>> hopefully that will help in > this particular area.  But, as I recall, at 
>>> the last language summit there was quite a bit of
>>> discussion about how to address the broader issue of patches falling into a 
>>> black hole.  Is
>>> anybody working on it?
>>
>> I think the best way to "work on it" is to work on having more core
>> developers, possibly with a more diverse range of interests.
>>
>>> (This seems to me like an area where a judicious application of PSF funds 
>>> might help; if every
>>> single bug were actively triaged and responded to, even if it weren't 
>>> reviewed, and patch
>>> contributors were directed to take specific steps to elicit a response or a 
>>> review, the fact that
>>> patch reviews take a while might not be so bad.)
>>
>> The operative word being "judicious". It is not obvious who should get
>> funded, and for what tasks.
>> Some specific issues (like email in 3.x) are large enough that they can
>> be the sole focus of a fund grant. But I'm not sure triaging can apply.
>
> I'm mulling over starting a monthly triage sprint under the auspices of
> Jesse Noeller's PSF sponsored sprints in the hopes of making this a
> little more fun. I'd appreciate comments on the idea.
>
> Geremy Condra


Well, I'd like to get the sprint "how to" docs in shape, and then yeah
- we can totally do this. The sprints focuses were designed to help
with this pain (as others have pointed out) as well as other pain
points we've seen. Also note, hosting a "virtual sprint" or something
like that, which the sponsored sprint group simply helps advertise and
promote can help with this as well.

It's important though, when looking at triaging to keep in mind:
Moving the bug around (reassigning, etc) is of minimal use in a fair
number of cases - now, making sure it has a reproducible test case
(and can be reproduced), making sure the broken platforms are
enumerated, that patches have tests and docs (and are based on the
current trunk/whatever) and so on are much more valuable in the long
run.

Just some food for thought - and something to keep in mind if and when
we get to document more of this/etc.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]

On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum  wrote:
[snip]
> Great points Jesse! Since I really don't have the time or expertise to
> make a judgment on this PEP, I hereby appoint you chair of the
> approval process for this PEP. That basically means that when you
> think it's ready to be approved, you say so, and it's a done deal. The
> remaining feedback cycle is up to you now -- it sounds like you're
> ready for closure, which sounds good to me (again, without having read
> the PEP or tried to write something using the proposed code). You can
> do it however you like: you can declare it approved now, or read it
> over once more yourself and suggest some final changes, or set a
> period (e.g. 48 hours) during which final comments have to be
> received, which you then will judge by merit or by your whim, or you
> can flip a coin or say a prayer... (I've tried most of those myself in
> the past and haven't done too badly if I say so myself. :-) You're the
> boss now. I know you will do the right thing for this PEP.
>
> --
> --Guido van Rossum (python.org/~guido)
>

So, after some cool down - and the last rounds of discussion which
triggered some jiggery-pokery on Brian's part, I'm accepting PEP 3148
"futures - execute computations asynchronously". I feel that it's a
good addition, and a good start for something bigger down the road.

Brian - you'll need to provide someone such as Martin or Georg your
public key for ssh access into SVN, and you'll need developer access
to the bug tracker.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]

2010/7/11 Jesse Noller :
> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum  wrote:
> [snip]
>> Great points Jesse! Since I really don't have the time or expertise to
>> make a judgment on this PEP, I hereby appoint you chair of the
>> approval process for this PEP. That basically means that when you
>> think it's ready to be approved, you say so, and it's a done deal. The
>> remaining feedback cycle is up to you now -- it sounds like you're
>> ready for closure, which sounds good to me (again, without having read
>> the PEP or tried to write something using the proposed code). You can
>> do it however you like: you can declare it approved now, or read it
>> over once more yourself and suggest some final changes, or set a
>> period (e.g. 48 hours) during which final comments have to be
>> received, which you then will judge by merit or by your whim, or you
>> can flip a coin or say a prayer... (I've tried most of those myself in
>> the past and haven't done too badly if I say so myself. :-) You're the
>> boss now. I know you will do the right thing for this PEP.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
> So, after some cool down - and the last rounds of discussion which
> triggered some jiggery-pokery on Brian's part, I'm accepting PEP 3148
> "futures - execute computations asynchronously". I feel that it's a
> good addition, and a good start for something bigger down the road.
>
> Brian - you'll need to provide someone such as Martin or Georg your
> public key for ssh access into SVN, and you'll need developer access
> to the bug tracker.

Oh, don't worry. He's already been hacking happily on Windows stuff.


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

Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]

On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson  wrote:
> 2010/7/11 Jesse Noller :
>> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum  wrote:
>> [snip]
>>> Great points Jesse! Since I really don't have the time or expertise to
>>> make a judgment on this PEP, I hereby appoint you chair of the
>>> approval process for this PEP. That basically means that when you
>>> think it's ready to be approved, you say so, and it's a done deal. The
>>> remaining feedback cycle is up to you now -- it sounds like you're
>>> ready for closure, which sounds good to me (again, without having read
>>> the PEP or tried to write something using the proposed code). You can
>>> do it however you like: you can declare it approved now, or read it
>>> over once more yourself and suggest some final changes, or set a
>>> period (e.g. 48 hours) during which final comments have to be
>>> received, which you then will judge by merit or by your whim, or you
>>> can flip a coin or say a prayer... (I've tried most of those myself in
>>> the past and haven't done too badly if I say so myself. :-) You're the
>>> boss now. I know you will do the right thing for this PEP.
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>>
>>
>> So, after some cool down - and the last rounds of discussion which
>> triggered some jiggery-pokery on Brian's part, I'm accepting PEP 3148
>> "futures - execute computations asynchronously". I feel that it's a
>> good addition, and a good start for something bigger down the road.
>>
>> Brian - you'll need to provide someone such as Martin or Georg your
>> public key for ssh access into SVN, and you'll need developer access
>> to the bug tracker.
>
> Oh, don't worry. He's already been hacking happily on Windows stuff.
>
>
> --
> Regards,
> Benjamin
>

Wrong Brian - that's Brian Curtin, this is Brian Quinlan - I double
checked the committer's list (http://www.python.org/dev/committers).

We now have two Brians. I say we name them PresentBrian and FutureBrian.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]

2010/7/11 Jesse Noller :
> On Sun, Jul 11, 2010 at 10:07 PM, Benjamin Peterson  
> wrote:
>> 2010/7/11 Jesse Noller :
>>> On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum  wrote:
>>> [snip]
 Great points Jesse! Since I really don't have the time or expertise to
 make a judgment on this PEP, I hereby appoint you chair of the
 approval process for this PEP. That basically means that when you
 think it's ready to be approved, you say so, and it's a done deal. The
 remaining feedback cycle is up to you now -- it sounds like you're
 ready for closure, which sounds good to me (again, without having read
 the PEP or tried to write something using the proposed code). You can
 do it however you like: you can declare it approved now, or read it
 over once more yourself and suggest some final changes, or set a
 period (e.g. 48 hours) during which final comments have to be
 received, which you then will judge by merit or by your whim, or you
 can flip a coin or say a prayer... (I've tried most of those myself in
 the past and haven't done too badly if I say so myself. :-) You're the
 boss now. I know you will do the right thing for this PEP.

 --
 --Guido van Rossum (python.org/~guido)

>>>
>>> So, after some cool down - and the last rounds of discussion which
>>> triggered some jiggery-pokery on Brian's part, I'm accepting PEP 3148
>>> "futures - execute computations asynchronously". I feel that it's a
>>> good addition, and a good start for something bigger down the road.
>>>
>>> Brian - you'll need to provide someone such as Martin or Georg your
>>> public key for ssh access into SVN, and you'll need developer access
>>> to the bug tracker.
>>
>> Oh, don't worry. He's already been hacking happily on Windows stuff.
>>
>>
>> --
>> Regards,
>> Benjamin
>>
>
> Wrong Brian - that's Brian Curtin, this is Brian Quinlan - I double
> checked the committer's list (http://www.python.org/dev/committers).
>
> We now have two Brians. I say we name them PresentBrian and FutureBrian.

My apologies, Brians!


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

Re: [Python-Dev] Issue 2986: difflib.SequenceMatcher is partly broken

2010-07-11 Thread Tim Peters

[Terry Reedy]
> I had considered the possibility of option A for 2.7 and A & C for 3.2. But
> see below.
>
> Since posting, I did an experiment with a 700 char paragraph of text (the
> summary from the post) compared to an 'edited' version. I did the
> comparision with and without the current heuristic. I did not notice much
> time difference (a couple of seconds either way) and the edit list was
> essentially the same.

When the sequences contain M (in seq1) and N (in seq2) instances of a
given element, the inner matching loop goes around M*N times
processing them.  Unless the element is identified as "junk" and/or
"popular", in which case the outer loop finds the M instances (in
seq1), one at a time, and the inner loop is skipped for each (because
b2j does not contain the junk/popular element as a key, so the inner
loop ends up iterating over the empty "nothing" list).

Of course the speed difference is minor unless M*N is large.  For
example, when M and N are both on the order of thousands, M*N is on
the order of millions.  Such cases motivated the original "auto junk"
heuristic (large "before" and "after" text files with thousands of
repetitions of boilerplate lines - I suspect at least some of this
input was computer-generated).

> The heuristic lowered the reported match ratio from .96 to .88, which
> would be bad when one wanted the unaltered value.

Except that the ratio is defined as being twice the number of matches
divided by the sum of the lengths of the sequences, so has no
interpretation independent of exactly how matching was performed.
Junk can have a very large effect on this.  IOW, the ratio is not a
property of the sequences, it emerges from all the details of how
matches were found.

BTW, it's not clear whether ratio() computes a _useful_ value in the
presence of junk, however that may be defined.  Perhaps it would be
better to, e.g., not use the lengths of the matches or of the input
sequences directly, but to adjust all of them by pretending junk
elements didn't exist.  Or not - it's unclear.

For example, if the sequences are

['j1', 'a', 'j2']
and
['j3', 'a', 'j4']

where j1, j2, j3, and j4 are considered to be junk, what _is_ a useful
ratio?  As is, it returns 0.333 (1 match, so returns 2.0 * 1 / (3 + 3)
= 1/3).  But if we didn't count junk elements at all, the "correct"
ratio would be 1.0 (2.0 * 1 match, out of 2 total non-junk elements in
the input sequences).

I suspect nobody cares ;-)


> I do not know which, if any, chars other than 'e' were junked as that info
> currently is not exposed. I propose below that it should be.

An auto-junk-detection gimmick certainly should allow finding out what
it decided junk was.

> I intentionally did not list as options
>
> D. Keep the status quo that is buggy for certain uses.
>
> Good things often have more uses than the inventor intended or expected.
> They should not be prevented.
>
> E. Completely remove the heuristic, which would restore 'buggy' performance
> for other uses.
>
> One of the closed issues was E, rejected for that reason.
>
> ---
> I also did not list one of my original ideas, but after the discussion it is
> looking better to me. It is based on the following statement of the current
> heuristic:
>
> "Disregard as junk common items that occur in more that 1% of the positions
> in second sequence b, as long as b is long enough so that duplicates cannot
> be called common."

I'm not sure what "so that duplicates cannot be called common" means.
Being common shouldn't, on its own, disqualify something from being
junk.

The essence of (a better notion of) junk probably has much more to do
with "lumpiness" in the distribution of element frequencies.  In the
DNA example, I bet no one of {A, G, C, T} appears "way more"
frequently than any other, so it's crazy to call any of them "junk".
But, e.g., if we were trying to compare simple melodies, a "silence"
token would probably be very frequent compared to any individual note.

> Tim, I do not know if you remember why you choose 200 as the cutoff,

I was afraid the auto-junk heuristic would end up doing silly things
on short sequences, and 200 "isn't short" - LOL.  Sheesh.

> but the above assumes that the following in not just a coincidence:
>
> (2 > 199*.01) == True
> (2 > 200*.01) == False
>
> In other words, 200 is the smallest length for b that prevents the junking
> of duplicates.

Well, the rule was also "> 1%", and floating arithmetic isn't used for
that part ... it's here:

if n >= 200 and len(indices) * 100 > n:

where n is the length of the sequence.  len(indices) * 100 > n is
mathematically (not necessarily numerically) equivalent to
len(indices) > n / 100, or, IOW, the thing appears in more than 1% of
the positions.  It certainly was the intent that nothing would be
called junk unless it appeared at least twice, so the "n >= 200"
clause ensures that 1% of n is at least 2.

> F. Generalize the heuristic by replacing '1' with 'k', where k can be

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

2010-07-11 Thread Bruce Sherwood

On the notion that IDLE is fatally flawed and is driving away potential
users of Python (to put the statements in their most extreme form):

It seems that there are (at least) two very different communities people
have in mind. I can appreciate that highly expert programmers may find IDLE
insufficient for their needs, and it might even be the case that these
people should be advised not to even try IDLE. But I want to stress as
strongly as possible that for a very large community of nonexpert users of
Python, IDLE has been extremely important and works very well for their
purposes. Editing is pretty much like what they're already used to in word
processors, which is certainly not the case with professional tools such as
vim or Emacs.

That said, yes, there are some significant deficiencies with the current
IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear
from Martin that Guilherme is free to commit his important bug fixes and
improvements. I'm afraid that neither Guilherme nor I understood the
procedures and thought that we had to wait for others to act.

Bruce Sherwood
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-11 Thread Terry Reedy


On 7/11/2010 2:40 PM, "Martin v. Löwis" wrote:

Guido

There clearly are *some* folks who care enough about IDLE to submit
bug reports and fixes. How about we empower these people by giving at
least one of them commit privileges? IDLE development has often been
done by people who aren't otherwise contributing to the core, and we
surely should trust those folks with commit privileges.


It appears Guiherme Polo already has commit privileges and just needs 
help exercising them, which I have offered, along with Martin's 
encouragement. Multiple IDLE maintainers would be even better.


Mark Lawrence

Can I take a really big liberty and volunteer Terry Reedy for the job.


Thank you for the nomination.


If Terry would volunteer himself, he'd get commit access in no time.


What I specifically want right now is Commit Authorization Privilege, 
especially for IDLE, but in general would be fine. I am thinking about 
working working one or more 'beginners' who are 'shy' about acting 
independently, or who are not yet authorized to do so, and who would 
like help getting their feet 'wet', so to speak. I think I would enjoy 
this sort of pair development.


In regard to IDLE, who, short of Guido, is in charge? Is there a design 
doc? It appears that several people have ideas in their heads, such as 
'keep it simple'. Abstractly, I agree with that, but who decides what is 
simple, to the point of vetoing something as 'too complex'?


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Ronald Oussoren

On 11 Jul, 2010, at 15:24, Kevin Walzer wrote:

> On 7/11/10 5:03 AM, Ronald Oussoren wrote:
>> 
> 
>> 
>> The OSX issues al seem to be related to general Tk or Tkinter bugs
>> on OSX. I know to little about Tk and Tkinter to seriously work on
>> those.
> 
> Ronald,
> 
> How about http://bugs.python.org/issue6075? I first submitted that patch in 
> May '09, and updated it in October '09 on request from you, and it's just sat 
> there since...

If I read the patch correctly it replaces the existing 8.4 support by support 
for 8.5. That would not be acceptable because it would result in a 
non-functional version of IDLE for anyone that hasn't installed a custom copy 
of Tk.

The "checkForAppKit" function doesn't work with the system version of Tk that 
Python currently links to.

Does the patch work with the system version of Tk 8.4 on OSX? 

Ronald
> 
> --Kevin
> 
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
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-dev] Removing IDLE from the standard library

2010-07-11 Thread Ronald Oussoren


On 11 Jul, 2010, at 19:35, Bill Janssen wrote:

> Tal Einat  wrote:
> 
>> Although several people say that they think having IDLE in the stdlib
>> is important, the fact is that IDLE is considered quite unimportant by
>> most of the Python community. Having IDLE in the stdlib may be
>> convenient for a few people, but most never use it and don't care
>> about it. I think that in its current state, IDLE may still be helpful
>> for learning Python, but it is more likely to drive away users who run
>> into its various quirks and problems. And for experienced Python
>> developers, very few actually use IDLE, and those who do could easily
>> install it if it weren't part of the stdlib.
> 
> I agree with you on this, Tal.  On OS X, this is particularly
> aggravating, as the Apple-supplied Python doesn't seem to include a
> working version, and installing MacPython leads to other problems (see,
> for instance, the thread at
> http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5b66).

Apple doesn't ship IDLE.app, but does ship the rest of the code. It should be 
fairly easy
to create a small IDLE.app using the python.org source tree that uses 
/usr/bin/python.

Ronald

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

Re: [Python-Dev] Removing IDLE from the standard library