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

[Jeroen Ruigrok van der Werven]

-On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote:
>But I, personally, would consider it a significant loss if IDLE went the way of
>the dodo or a third-party module. 

Why would it be a significant loss if it went the way of a third party
module? Clearly right now it's not being maintained as well as the rest of
Python. Maybe that's a clear indicator that it's better maintained
externally instead of in the main tree.

And for what it is worth, I personally never used it beyond one time looking
at it in disgust and neither do I know Pythonistas around me that use it.
Bpython and ipython do get installed a lot though, even on Windows. And all
these people, no matter their proficiency in programming, use an editor or
IDE of some sort, but not IDLE.

So I would not mourn to see IDLE get moved out of the main repository as I
do not see the added value or benefit, not even for training (and since
you're going to set up a training environment anyway, it can only be
described as lazy if you are adamant on having it included in the base
distribution).

Just my EUR 0,02.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Born from the Dark, in the black Cloak of Night...
___
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]

Am 12.07.2010 10:06, schrieb Jeroen Ruigrok van der Werven:
> -On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote:
>> But I, personally, would consider it a significant loss if IDLE went the way 
>> of
>> the dodo or a third-party module. 
> 
> Why would it be a significant loss if it went the way of a third party
> module? Clearly right now it's not being maintained as well as the rest of
> Python.

I start disagreeing here already. It *is* as well maintained as the rest
of Python - at least, there are many other parts of Python that get the
same attention (or less).

IDLE has been working for years, in a certain feature set. It just
doesn't need much "maintenance", except for updates when the world
around it is changing.

> Maybe that's a clear indicator that it's better maintained
> externally instead of in the main tree.

That's an unfounded theory, at best. Two experiments to pro

> So I would not mourn to see IDLE get moved out of the main repository as I
> do not see the added value or benefit

Now that's a different issue. You are not using it, fine. Does that mean
it should be removed? If we removed all modules that somebody is not
using, the standard library would be empty.

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

[Kurt B. Kaiser]

On Sun, Jul 11 2010, Bruce Sherwood wrote:

> 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.

Particularly on Windows, there is an expectation that a contemporary
programming language comes with a GUI.  Using the Windows Python shell
isn't very satisfactory, largely because of the poor file handling
capability in that environment.  IDLE provides a simple solution,
suitable for beginners as well as experts.  It provides one-keystroke
save/run in a fresh environment not associated with the GUI.  I have run
IDLE inside IDLE (though I'm not positive that will work right now).
How many IDEs can do that?

I've tried to channel Guido, and my general approach has been to provide
as much functionality as needed, but to hide the more advanced features
to avoid clutter.  When the 'experts' need them, they will find them.

I'm mystified about the comments that the GUI is ugly.  It is minimal.
On XP, it looks exactly like an XP window with a simple menubar.  Those
who haven't looked at it for awhile may not be aware of the recent
advances made by Tk in native look and feel.  What is ugly?

And IDLE is cross-platform.  There are perhaps deficiencies on the Mac,
but Ron has made good progress.  I haven't been able to come up with a
Mac yet, so I can't really comment.

IDLE works on 2.7 and 3.x.  Running IDLE on the trunk is a decent
test of Python and tkinter during development.

It seems that people who do Scheme write Scheme implementations, while
people who do Python write IDEs :-)

Usually, they keep adding features and buttons until it looks like
Eclipse.  That's fine.  But why turn IDLE into another example of that
style and diminish diversity in doing so?

On a netbook, screen space is at a premium, and a simple interface has
advantages.  There are many IDEs listed on the wiki if people are
looking for the more complex style, but I'd suggest that they aren't
appropriate for beginners.  And by beginners, I include elementary
school students.

IDLE works with "extensions".  Plug-ins, if you will.  The Option dialog
needs enhancement to support extension selection, and I believe there is
a patch to do that.  More extensions would be a good thing.

The .idlerc directory determines IDLE's configuration, including the
help source urls available on the Help menu.  By downloading .idlerc or
via indirection, a student environment can be set up including the day's
lesson and which extensions are activated.  Call tips and method name
completion can be "hidden" by increasing the time delay before they pop
up.

> 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.

Tal has made a couple of comments about not being able to run multiple
IDLEs at the same time, and he mentions

http://bugs.python.org/issue1529142

This bug has been closed for over a year, and you can run as many IDLEs
as you like.  You can run 2.7 and 3.x at the same time.  I would have
expected Tal to know that.

Also, the current right click edit action on Windows is to only open an
edit window; no shell.  And it uses the subprocess!  So, some of the
comments on this thread are not up to date.

The reason that bug languished for two years was because first, it was a
bit of a hack, and second, Windows was problematic in that it reused
sockets and often left zombie subprocesses behind which couldn't be
killed except with the task manager.  This causes real problems with
students - they lose confidence in the tool.

Scherer and Weeble put together a patch using ephemeral ports which
nailed the problem, and I checked it in right away and
forward/backported it.

As I recollect, much of what Scherer did in VIDLE related to running
multiple IDLE copies.

For that reason, the VIDLE changes have to be evaluated carefully to
determine what has already been incorporated.  I believe I added a
couple of his smaller changes, also.

Bruce, speaking of Dave Scherer, we've been trying to get a Python
Contributor Agreement from him.  Is that something you can help us wit

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

[Stefan Krah]

Jesse Noller  wrote:
> On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
> >>> (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.

[responding to Geremy]

I'm with Georg on this. If triaging needs a monetary incentive because it
is tedious work, so does committing. A lot of the abandoned issues aren't
very glamorous either.

Also, from the work that Mark Lawrence has been doing on the tracker in
the past few weeks, it's apparent that a dedicated person can achieve a
lot without pay.

Due to his tracker reshuffling, many issues got closed, several bug
reporters responded after years, etc. Thanks, Mark!


Stefan Krah


___
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

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Jeroen Ruigrok van der Werven wrote:

> -On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote:
>>But I, personally, would consider it a significant loss if IDLE went
>>the way of the dodo or a third-party module. 
>
> Why would it be a significant loss if it went the way of a third party
> module? Clearly right now it's not being maintained as well as the
> rest of Python. Maybe that's a clear indicator that it's better
> maintained externally instead of in the main tree.
>
> And for what it is worth, I personally never used it beyond one time
> looking at it in disgust 

Apparently you haven't looked recently.  If you'd describe specifically
what is disgusting on the current version, perhaps we can do something
about it.

> and neither do I know Pythonistas around me that use it.  Bpython and
> ipython do get installed a lot though, even on Windows. And all these
> people, no matter their proficiency in programming, use an editor or
> IDE of some sort, but not IDLE.

Well, I use it :-)  I used to use emacs to develop IDLE, but as IDLE
became more capable, I stopped using emacs (except to fix IDLE when I
break it completely :) When I find something I really miss, I add it.
But I don't just add features to check off a list.

Search on the status bar and jump to definition are next.

>
> So I would not mourn to see IDLE get moved out of the main repository
> as I do not see the added value or benefit, not even for training (and
> since you're going to set up a training environment anyway, it can
> only be described as lazy if you are adamant on having it included in
> the base distribution).

On Windows, IDLE opens when you right click / edit a .py. Very useful.

On linux, the packagers generally split IDLE off into a separate package
so Python can be installed without Tcl/Tk.  That doesn't mean it should
be removed from the tarball; their package build tools build several
packages from the single tarball at the same time.  Second guessing them
by having two tarballs just increases the work for everyone.

This could be done on Windows, but then you wouldn't have a GUI to use
right after running the Python installer.  Minimal installations are not
so important on Windows.

-- 
KBK
___
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

[Antoine Pitrou]

On Mon, 12 Jul 2010 05:20:49 -0400
"Kurt B. Kaiser"  wrote:
> 
> I'm mystified about the comments that the GUI is ugly.  It is minimal.
> On XP, it looks exactly like an XP window with a simple menubar.  Those
> who haven't looked at it for awhile may not be aware of the recent
> advances made by Tk in native look and feel.  What is ugly?

Ok, I've just tried IDLE (on py3k) for the first time in years. Under
Linux, the look is ugly and outdated; it uses some kind of Motif-like
widgets. Usability is inconsistent with the rest of the desktop, and
looks generally subpar (for example, you have to click on a menu to
open it; the file open dialog is antiquated and doesn't allow me to use
keyboard shortcuts).
The editor looks decent, though there doesn't seem to be a simple (e.g.
Shift+Tab) way of unindenting a block of code.

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

[Antoine Pitrou]

After a few keystrokes in the interactive interpreter, I got the
following traceback:

Traceback (most recent call last):
  File "Lib/idlelib/idle.py", line 11, in 
idlelib.PyShell.main()
  File "/home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py", line 1420,
in main
root.mainloop()
  File "/home/antoine/py3k/__svn__/Lib/tkinter/__init__.py", line 1009,
in mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0:
invalid start byte


The keystrokes were ['d', 'i', Ctrl+Space], which briefly displayed the
completion popup before crashing.

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

[geremy condra]

On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah  wrote:
> Jesse Noller  wrote:
>> On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
>> >>> (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.
>
> [responding to Geremy]
>
> I'm with Georg on this. If triaging needs a monetary incentive because it
> is tedious work, so does committing. A lot of the abandoned issues aren't
> very glamorous either.

I'm not sure what you mean by "monetary incentive". I was considering
handing a t-shirt or beer token to the most productive sprinters, but
that's about the limit of it, and I suspect that would come out of my
pocket.

I'd also emphasize that I am exactly as far as I stated on this: I'm
mulling it over and asking for feedback. If it turns out that there
are other things that python-dev feels are more necessary but
similarly unglamorous, then I'll think about doing that instead.

> Also, from the work that Mark Lawrence has been doing on the tracker in
> the past few weeks, it's apparent that a dedicated person can achieve a
> lot without pay.

Indeed, although I'm again unsure what pay has to do with this.

> Due to his tracker reshuffling, many issues got closed, several bug
> reporters responded after years, etc. Thanks, Mark!

+1

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

[Ezio Melotti]

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

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
Indeed it's not clear if the names that appear in the maintainers.rst 
list are supposed to be added only to the nosy list or if it's possible 
to add them to the "assigned to" field too.
A way to avoid confusion is to mark the names that should be added to 
the "Assigned to" field with a '*', and add the others to the nosy list 
only.


E.g.:
unicodedata loewis, lemburg, ezio.melotti*
would mean "You can add loewis and lemburg to the nosy list and assign 
the issue to ezio.melotti".


Otherwise we can just decide that those names should just be added to 
the nosy list and let them assign the issue to themselves if they want 
to fix it.


Best Regards,
Ezio Melotti

___
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

[Tal Einat]

Hi Kurt, I'm glad you've joined this discussion.

My point is that whatever the reason, for the past five years (at
least) nearly every issue related to IDLE has taken years to be
resolved, and many have still not been resolved. As a result the
current state of IDLE is quite poor.

To be perfectly clear, I'm am not blaming anyone for this. I just
think this is something the development community should be more aware
of and decide how to deal with.

On Mon, Jul 12, 2010 at 12:20 PM, Kurt B. Kaiser wrote:
> Particularly on Windows, there is an expectation that a contemporary
> programming language comes with a GUI.  Using the Windows Python shell
> isn't very satisfactory, largely because of the poor file handling
> capability in that environment.  IDLE provides a simple solution,
> suitable for beginners as well as experts.  It provides one-keystroke
> save/run in a fresh environment not associated with the GUI.  I have run
> IDLE inside IDLE (though I'm not positive that will work right now).
> How many IDEs can do that?

[snip]

> On a netbook, screen space is at a premium, and a simple interface has
> advantages.  There are many IDEs listed on the wiki if people are
> looking for the more complex style, but I'd suggest that they aren't
> appropriate for beginners.  And by beginners, I include elementary
> school students.

I agree that IDLE is great specifically thanks to its simplicity, and
should be kept simple. I think something like IDLE can be great for
teaching and learning Python (and other uses as well) and has a place
in the stdlib. I'm simply not sure if IDLE in its current state is fit
for this purpose.

> I'm mystified about the comments that the GUI is ugly.  It is minimal.
> On XP, it looks exactly like an XP window with a simple menubar.  Those
> who haven't looked at it for awhile may not be aware of the recent
> advances made by Tk in native look and feel.  What is ugly?

IDLE may be somewhat close to looking like a native application, but
it is not quite there. Some examples:
* Users expect to be able to copy/paste using the mouse via the
right-click context menu, which is impossible in IDLE (in both shell
and editor windows).
* The selection jumping to the end of the line unexpectedly doesn't
happen in any other GUI text editor.
* The config dialog looks archaic.

As for the native look&feel, this has still not been integrated into
IDLE, though it seems now it will happen soon. This has already been
discussed here.

> IDLE works with "extensions".  Plug-ins, if you will.  The Option dialog
> needs enhancement to support extension selection, and I believe there is
> a patch to do that.  More extensions would be a good thing.

IDLE extensions are a pain to work with and badly supported.
Installing an extension requires manually placing it in the idlelib
directory and manually adding its config options to a certain text
file in that directory. In practice nobody ever takes the effort to
try installing an IDLE extension, such as my SearchBar extension.

There has been discussion on improving this situation, but again this
never actually happened. I tried to move this along with a patch which
adds an extension config dialog, which has been sitting in the issue
tracker ignored for two years.

> Tal has made a couple of comments about not being able to run multiple
> IDLEs at the same time, and he mentions
>
> http://bugs.python.org/issue1529142
>
> This bug has been closed for over a year, and you can run as many IDLEs
> as you like.  You can run 2.7 and 3.x at the same time.  I would have
> expected Tal to know that.

I clearly mentioned that as an example of a fix for a major usability
issue which took three years to resolve after a workaround was first
posted. It is worth noting that most people still don't use the
versions of Python (and IDLE) where this fix has been integrated.

> The reason that bug languished for two years was because first, it was a
> bit of a hack, and second, Windows was problematic in that it reused
> sockets and often left zombie subprocesses behind which couldn't be
> killed except with the task manager.  This causes real problems with
> students - they lose confidence in the tool.
>
> Scherer and Weeble put together a patch using ephemeral ports which
> nailed the problem, and I checked it in right away and
> forward/backported it.

True, but it took three whole years for this to happen. And this is
for a glaring, annoying and limiting issue that nearly every user of
IDLE has encountered.
___
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

[Tal Einat]

On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis"  wrote:
>> 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?

That's not a fair question!

There have been several such patches, but most will likely need
revision since they have been sitting around untouched for so long.
And there would have been many more patches if the existing ones would
have been addressed.

Getting a few current patches accepted is not the reason I posted here.

- 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

[Tal Einat]

On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis"  wrote:
>> 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.

That's debatable, and I disagree. IDLE-fork was a great success, for example.

If IDLE actually had many users today, certainly some of them would be
interested in trying out a version with usability fixes and
improvements. Waiting for a new release of Python can take over a
year. Furthermore, backwards compatibility issues and support by third
party libraries can delay migration to a newer version of Python even
further.

- 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

[Neil Hodgson]

Kurt B. Kaiser:

> I'm mystified about the comments that the GUI is ugly.  It is minimal.
> On XP, it looks exactly like an XP window with a simple menubar.  Those
> who haven't looked at it for awhile may not be aware of the recent
> advances made by Tk in native look and feel.  What is ugly?

   While Tk has improved at emulating native appearance, there are
still many differences.

   On the main editing screen of IDLE, the most noticeable issue is
that there is no horizontal scroll bar even though the text will move
left when you move the caret beyond the rightmost visible character.
The scrollbar and status bar have an appearance that looks to be from
Windows 2000, not Windows XP and there is no resizing gripper on the
right side of the status bar. The tear off menus are ugly as well as
being non-standard on all three major platforms.

   Use the "Configure IDLE..." and an "idle" dialog appears that also
looks to be from Windows 2000. I know Tk can do better than this as
Git Gui (the Tk (8.5.8) program I use most often) at least shows XP
themed buttons, scrollbars and other controls. However, the "idle"
dialog (as well as Git Gui) shows the largest remaining problem for Tk
user interfaces: keyboard navigation. When the "idle" dialog opens,
try doing anything with the keyboard. Chances are nothing will happen.
If you press Tab 16 times (yes, 16!) a focus rectangle will finally
show on the "Bold" check box. Another Tab takes you to the
"Indentation Width" slider. After that you don't see the focus until
it wraps around to "Bold" again. The Enter key doesn't trigger OK and
the Escape key doesn't let you escape.

   The Find and Replace dialogs are better as focus works as do Enter
and Escape but none of the buttons have mnemonics.

   This may all sound like picking nits but details and consistency
are important in user interfaces and this is just looking at the most
easily discovered problems.

   Neil
___
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

[Stefan Krah]

geremy condra  wrote:
> On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah  wrote:
> > Jesse Noller  wrote:
> >> On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
> >> >>> (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.
> >
> > [responding to Geremy]
> >
> > I'm with Georg on this. If triaging needs a monetary incentive because it
> > is tedious work, so does committing. A lot of the abandoned issues aren't
> > very glamorous either.
> 
> I'm not sure what you mean by "monetary incentive". I was considering
> handing a t-shirt or beer token to the most productive sprinters, but
> that's about the limit of it, and I suspect that would come out of my
> pocket.

Sorry for misinterpreting your intentions. I was reading this in the context
of "judicious application of PSF funds". What you are describing is of course
quite judicious.

To me, "PSF sponsored" sounded like there would be a lot more money involved.


Stefan Krah


___
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

[geremy condra]

On Mon, Jul 12, 2010 at 7:17 AM, Stefan Krah  wrote:
> geremy condra  wrote:
>> On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah  wrote:
>> > Jesse Noller  wrote:
>> >> On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:
>> >> >>> (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.
>> >
>> > [responding to Geremy]
>> >
>> > I'm with Georg on this. If triaging needs a monetary incentive because it
>> > is tedious work, so does committing. A lot of the abandoned issues aren't
>> > very glamorous either.
>>
>> I'm not sure what you mean by "monetary incentive". I was considering
>> handing a t-shirt or beer token to the most productive sprinters, but
>> that's about the limit of it, and I suspect that would come out of my
>> pocket.
>
> Sorry for misinterpreting your intentions. I was reading this in the context
> of "judicious application of PSF funds". What you are describing is of course
> quite judicious.
>
> To me, "PSF sponsored" sounded like there would be a lot more money involved.

Nope, as long as I can keep the costs under $100 or so (I'm the worlds
biggest cheapskate, shouldn't be a problem) I doubt I'll ask for
anything except that people promote and attend.

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] maintainers.rst enhancement (was: Removing IDLE from the standard library)

[R. David Murray]

On Mon, 12 Jul 2010 13:39:15 +0300, Ezio Melotti  wrote:
>   On 12/07/2010 2.56, "Martin v. L=F6wis" wrote:
> >> 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
>
> Indeed it's not clear if the names that appear in the maintainers.rst
> list are supposed to be added only to the nosy list or if it's
> possible to add them to the "assigned to" field too.  A way to avoid
> confusion is to mark the names that should be added to the "Assigned
> to" field with a '*', and add the others to the nosy list only.

Actually it is clear.  The text at the top of the file says the names
are there "to be added to the nosy list".  It does not mention assigning
bugs.  This was actually discussed at least briefly when the file
was created.  We probably should have included "*don't* assign tickets,
nosy the maintainer and let them pick it up if they want to" in the
intro text.

> E.g.:
>  unicodedata loewis, lemburg, ezio.melotti*
> would mean "You can add loewis and lemburg to the nosy list and assign
> the issue to ezio.melotti".  Otherwise we can just decide that those

I like this suggestion, but obviously we need to let those developers
who wish to do this "star" themselves.

If there are no objections to this change to maintainers.rst, I'll
start the ball rolling by marking myself for email, and adjusting
the introductory text accordingly.

--
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] maintainers.rst enhancement

[Michael Foord]

On 12/07/2010 12:42, R. David Murray wrote:

[snip...]
   

E.g.:
  unicodedata loewis, lemburg, ezio.melotti*
would mean "You can add loewis and lemburg to the nosy list and assign
the issue to ezio.melotti".  Otherwise we can just decide that those
 

I like this suggestion, but obviously we need to let those developers
who wish to do this "star" themselves.

If there are no objections to this change to maintainers.rst, I'll
start the ball rolling by marking myself for email, and adjusting
the introductory text accordingly.
   


Sounds good to me. You can leave me starred for unittest.

Michael


--
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/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] maintainers.rst enhancement (was: Removing IDLE from the standard library)

[R. David Murray]

On Mon, 12 Jul 2010 01:07:54 +0100, Mark Lawrence  
wrote:
> 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. :)

As someone else mentioned, it is relatively new.  It was created
partially in the hopes that the huge gaps in coverage would encourage
people to step forward and volunteer to be maintainers, and this
has indeed been happening slowly.  For example, Alexander Belopolsky
recently became a committer and picked up datetime, time, and
pickle.

Another issue with the file that may make it look a tad outdated is
that I think it hasn't been clear to everyone that it is designed to
hold *tracker ids* rather than *committer ids*.  I noticed the other
day that I had to translate from committer id to tracker id for someone
(I forget who, and I didn't have time to update the file at the time).

--
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

[R. David Murray]

On Mon, 12 Jul 2010 00:13:21 +0100, Mark Lawrence  
wrote:
> On 11/07/2010 19:40, "Martin v. L=F6wis" 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.

I suggested you use maintainers.rst to find people to add to the nosy
list, not to assign bugs to.  But I can understand your confusion about
that, given the name of the file, and the lack of complete process
documentation.

--
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

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Antoine Pitrou wrote:

> On Mon, 12 Jul 2010 05:20:49 -0400
> "Kurt B. Kaiser"  wrote:
>> 
>> I'm mystified about the comments that the GUI is ugly.  It is minimal.
>> On XP, it looks exactly like an XP window with a simple menubar.  Those
>> who haven't looked at it for awhile may not be aware of the recent
>> advances made by Tk in native look and feel.  What is ugly?
>
> Ok, I've just tried IDLE (on py3k) for the first time in years. Under
> Linux, the look is ugly and outdated; it uses some kind of Motif-like
> widgets.

That's because Linux isn't using Tk 8.5 yet.  Debian defaults to Tk 8.5
in experimental since March.  Most Linux is Tk 8.4.

On Windows, our installer is using 8.5.  Here's a screenshot from my 
eeePC, 1024 x 600:

http://images.rant.ml1.net/idle.gif

Quoting Tal:


> 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, you've got some catching up to do, yourself.  Tile went into Tk in
8.5, two years ago.  Linux is behind, we don't control that, but our
Windows installer and tkinter is cutting edge!  Thanks, Martin!  I don't
know what version is running on the Mac:

http://blog.markroseman.com/2007/12/tcltk-85-first.html


I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk
8.4.  I think you guys are  exaggerating.  It's not /all/ that ugly, not by a
long shot.  It's just not native look and feel (yet).


> Usability is inconsistent with the rest of the desktop, and
> looks generally subpar (for example, you have to click on a menu to
> open it; 

On Linux and Windows,  f  will drop the file menu.


> the file open dialog is antiquated and doesn't allow me to use
> keyboard shortcuts).

Looks much better in 8.5 and the shortcuts work.

http://images.rant.ml1.net/idle2.gif

> The editor looks decent, though there doesn't seem to be a simple (e.g.
> Shift+Tab) way of unindenting a block of code.

Pull down the format menu.  The dedent hotkey is Ctrl+[

This possibly could be changed to Shift+Tab by the user, but there may
be conflicts with completion.

-- 
KBK
___
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

[Antoine Pitrou]

On Mon, 12 Jul 2010 08:12:10 -0400
"Kurt B. Kaiser"  wrote:
> >
> > Ok, I've just tried IDLE (on py3k) for the first time in years. Under
> > Linux, the look is ugly and outdated; it uses some kind of Motif-like
> > widgets.
> 
> That's because Linux isn't using Tk 8.5 yet.  Debian defaults to Tk 8.5
> in experimental since March.  Most Linux is Tk 8.4.

No, that's wrong. Tk here is 8.6:

$ ldd build/lib.linux-x86_64-3.2/_tkinter.so 
[...]
libtk8.6.so.0 => /usr/lib64/libtk8.6.so.0 (0x7f4eb9259000)
libtcl8.6.so.0 => /usr/lib64/libtcl8.6.so.0 (0x7f4eb8f07000)
[...]

$ ./python -c "import tkinter; print(tkinter.TkVersion)"
8.6

> > the file open dialog is antiquated and doesn't allow me to use
> > keyboard shortcuts).
> 
> Looks much better in 8.5 and the shortcuts work.
> 
> http://images.rant.ml1.net/idle2.gif

Well, this is a Windows screenshot. I'm under Linux.



___
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

[geremy condra]

On Mon, Jul 12, 2010 at 8:12 AM, Kurt B. Kaiser  wrote:
> On Mon, Jul 12 2010, Antoine Pitrou wrote:
>
>> On Mon, 12 Jul 2010 05:20:49 -0400
>> "Kurt B. Kaiser"  wrote:
>>>
>>> I'm mystified about the comments that the GUI is ugly.  It is minimal.
>>> On XP, it looks exactly like an XP window with a simple menubar.  Those
>>> who haven't looked at it for awhile may not be aware of the recent
>>> advances made by Tk in native look and feel.  What is ugly?
>>
>> Ok, I've just tried IDLE (on py3k) for the first time in years. Under
>> Linux, the look is ugly and outdated; it uses some kind of Motif-like
>> widgets.
>
> That's because Linux isn't using Tk 8.5 yet.  Debian defaults to Tk 8.5
> in experimental since March.  Most Linux is Tk 8.4.

FYI, I'm at 8.5 here, running Ubuntu 9.10, haven't knowingly updated tk.

> On Windows, our installer is using 8.5.  Here's a screenshot from my
> eeePC, 1024 x 600:
>
> http://images.rant.ml1.net/idle.gif

You may have meant to put a different image up, this one is windows.

> Quoting Tal:
> 
>
>> 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, you've got some catching up to do, yourself.  Tile went into Tk in
> 8.5, two years ago.  Linux is behind, we don't control that, but our
> Windows installer and tkinter is cutting edge!  Thanks, Martin!  I don't
> know what version is running on the Mac:
>
> http://blog.markroseman.com/2007/12/tcltk-85-first.html
>
>
> I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk
> 8.4.  I think you guys are  exaggerating.  It's not /all/ that ugly, not by a
> long shot.  It's just not native look and feel (yet).

No offense, but I've been specifically asked not to do demos with IDLE
because it looked 'unprofessional'. Given the constraint of working
within tkinter that may not be something you can work around, but I'm
sure you can see that from a certain perspective that's beside the
point.

>> Usability is inconsistent with the rest of the desktop, and
>> looks generally subpar (for example, you have to click on a menu to
>> open it;
>
> On Linux and Windows,  f  will drop the file menu.
>
>
>> the file open dialog is antiquated and doesn't allow me to use
>> keyboard shortcuts).
>
> Looks much better in 8.5 and the shortcuts work.
>
> http://images.rant.ml1.net/idle2.gif
>
>> The editor looks decent, though there doesn't seem to be a simple (e.g.
>> Shift+Tab) way of unindenting a block of code.
>
> Pull down the format menu.  The dedent hotkey is Ctrl+[
>
> This possibly could be changed to Shift+Tab by the user, but there may
> be conflicts with completion.
>
> --
> KBK
> ___
> 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/debatem1%40gmail.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] Getting an optional parameter instead of creating a socket internally

[Mattias Brändström]

On Sun, Jul 11, 2010 at 9:06 PM,  wrote:

> 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
>
>
This seems like an interesting idea to me. I would like to figure out some
way I could help with the PEP. If you move the document, could you please
keep me updated on the new location?

:.:: mattias


> ___
> 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/thebrasse%40brasse.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] IRC culture (was: Removing IDLE from the standard library)

[R. David Murray]

On Sun, 11 Jul 2010 23:51:35 +0100, Mark Lawrence  
wrote:
> 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

It was clear from a message you sent to me, that I didn't see until
after your visit to the channel, that you don't have any experience
on IRC.  IRC is its own unique medium, with its own mores, conventions,
and culture.  That you perceived hostility was probably due to the nature
of the medium and its communication via short sentences and intertwined
conversations.  And yes, the IRC channel is our "office water cooler"
where we come to chat with each other about things unrelated to our coding
work, as well as serious talk about the coding and bug triage work (some
of which takes place *while* we're chatting about things like the World
Cup Final).  It's a community, and we hang out there because we find it
fun to do so.  We often tease each other mercilessly, and an outsider
would probably wonder what the heck was going on if they didn't stick
around long enough to get the flavor of the community.  But we also do
a lot of good communicating about bugs and code, helping each other to
improve the quality of Python.

I thought the conversation when you arrived was mostly positive, and we
were trying to share our (somewhat disjointed, as we admitted) wisdom
about what works best when doing triage.  Antoine did lead off with a
specific criticism, which was unfortunate and doubtless set a bad tone for
you, and his mini-rant could have been more politely phrased given that
you were a newcomer.  But I use the term "mini-rant" descriptively...that
is part of the IRC style of communication, for better or worse.

As several people have pointed out, currently there is a dearth of good
documentation about the Python workflow.  I think Jesse's sprint effort
is going to help improve this, and I know Brett Cannon really wants
to have time to work the docs over thoroughly.  But in the meantime,
what we have is "institutional knowledge" locked up in people's heads.
The python-dev mailing list is one way to get access to that knowledge,
as is the tracker-discuss list for triage in particular...and the
IRC channel is a great way to get access to that knowledge (like, for
example, the fact that maintainers.rst is not out of date :), if you
are comfortable with IRC style communication.

If you don't find the IRC channel a useful place, there's no reason
for you to hang out there.  We were offering you the opportunity to
experience the camaraderie and mutual help that we find there, and I'm
very sorry that you instead found the experience offputting.  It is not
an exclusive club (far from it) and you would be welcome to return.

As I also said to you in a private message, the non-exclusivity goes
both ways...there is no *formal* "triage team", and only some of us
who do triage work hang out on IRC, and only some of us who hang out
on #python-dev do triage work.  Further, many of the people who chat
regularly on the IRC channel are committers, which is one of the reasons
why it can be a rich resource while doing triage.  Often enough, bugs
get closed that way.[*]

--
R. David Murray  www.bitdance.com

But, to be honest, I remember that Arfrever asked about committing the
patch for a particular bug on at least three different days before
someone finally had the time to do it.  It was very appropriate for
that bugfix to go in before the release, and he was very patient, and it
did get done.
___
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

[Kevin Walzer]

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.



Not quite. It doesn't specify a version of Tk to run; it checks instead 
for whether Tk is built on Cocoa or Carbon. (It needs 8.5 to run on Cocoa.)



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


The checkForAppKit function queries the Tk windowing server for some 
information about its implementation. If it find 'AppKit,' then Cocoa's 
running: if no, then Carbon's running. If Carbon, then the code falls 
back to the current implementation.




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


I just tested it against Python 2.5/Tk 8.4.7 (the system install on 
Leopard), which runs on Carobn, and it works fine. I've also tested it 
against 2.6 with Tk-Cocoa, and again it runs fine.  I don't have access 
to other combinations of Python and Tk, such as Python 3.1, but I think 
these results indicate it's safe to apply.


--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

[Mark Lawrence]

On 12/07/2010 11:37, geremy condra wrote:

On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah  wrote:

Jesse Noller  wrote:

On Sun, Jul 11, 2010 at 8:22 PM, geremy condra  wrote:

(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.


[responding to Geremy]

I'm with Georg on this. If triaging needs a monetary incentive because it
is tedious work, so does committing. A lot of the abandoned issues aren't
very glamorous either.


I'm not sure what you mean by "monetary incentive". I was considering
handing a t-shirt or beer token to the most productive sprinters, but
that's about the limit of it, and I suspect that would come out of my
pocket.

Any chance of getting me a t-shirt autographed by the one and only BDFL? :)


I'd also emphasize that I am exactly as far as I stated on this: I'm
mulling it over and asking for feedback. If it turns out that there
are other things that python-dev feels are more necessary but
similarly unglamorous, then I'll think about doing that instead.


Also, from the work that Mark Lawrence has been doing on the tracker in
the past few weeks, it's apparent that a dedicated person can achieve a
lot without pay.


Indeed, although I'm again unsure what pay has to do with this.


Due to his tracker reshuffling, many issues got closed, several bug
reporters responded after years, etc. Thanks, Mark!


+1

Geremy Condra


Geremy, Stefan, Jesse and anyone that I might have missed, thanks for 
your kind responses, its given me quite a lift.


For the record note that I only got going because of a post on c.l.py 
from Terry Reedy, and that he too has been doing similar work on the 
issue tracker, my round Terry. :)


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] Getting an optional parameter instead of creating a socket internally

[exarkun]

On 12:30 pm, thebra...@brasse.org wrote:

On Sun, Jul 11, 2010 at 9:06 PM,  wrote:


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
This seems like an interesting idea to me. I would like to figure out 
some
way I could help with the PEP. If you move the document, could you 
please

keep me updated on the new location?


Sure.  If it moves, there'll be a pointer from its existing location to 
the new one.


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] [Idle-dev] Removing IDLE from the standard library

[Antoine Pitrou]

On Mon, 12 Jul 2010 00:36:33 +0200
"Martin v. Löwis"  wrote:
> > 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.
> 
[...]
> 
> 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).

+1. Don't be afraid. We are quite good at pointing out mistakes after
the fact :)

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?

[Nick Coghlan]

On Mon, Jul 12, 2010 at 9:42 AM, 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.

re2 deliberately omits some features for efficiency reasons, hence is
not even on the table as a possible replacement for the standard
library version. If someone is in a position where re2 can solve their
problems with the re module, they should also be in a position where
they can track it down for themselves.

MRAB's module offers a superset of re's features rather than a subset
though, so once it has had more of a chance to bake on PyPI it may be
worth another look.

Cheers,
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

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

[Titus von der Malsburg]

Hi I learned about the futures PEP only today.  I saw the example on
http://code.google.com/p/pythonfutures/

One thing that worries me is that this approach seems to bypass the
usual exception handling mechanism of Python.  In particular I'm
wondering why you have to do things like:

  if future.exception() is not None:
...

This reminds me a lot of how things are done in C but it's not very
pythonic.  Wouldn't it be possible and nicer to raise the exception --
if there was one inside the asynchronous job -- when the result of the
future is accessed?

  try:
print('%r page is %d bytes' % (url, len(future.result(
  except FutureError:
print('%r generated an exception: %s' % (url, future.exception()))

Best,

  Titus
___
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

[Michiel Overtoom]

Tal Einat wrote:


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


I use IDLE every day. It does everything I want an IDE to do, it looks 
simple and doesn't waste screen real estate like some other IDEs do, it 
supports proportionally spaced fonts correctly, its syntax coloring is 
easy configurable (not a nightmare like some scintilla-based IDEs), and 
it's instantly available on any PC on which I install Python.


I'd like to keep it in the stdlib.

Greetings,


___
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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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:
> 
> 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.

I wonder if moving it out of stdlib might actually help improve its
development velocity:  maybe if it were managed via bitbucket, with
user-visible forks to known fixes, etc., it would get "caught up" to
people's expectations.

Perhaps I'm really suggesting that there be an 'idle2' project nn
bitbucket, as a "friendly fork" of the mostly freeze-dried version in
stdlib.



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

iEYEARECAAYFAkw7JcAACgkQ+gerLs4ltQ73RACfTcPaDXPFlg8EWnBxYj3qfWwg
qswAn3Ws/FvYqLLiYGvgzEpd1sIpWuWJ
=ZlSp
-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

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

[Kevin Walzer]

On 7/12/10 10:16 AM, Michiel Overtoom wrote:

Tal Einat wrote:


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


I use IDLE every day. It does everything I want an IDE to do, it looks
simple and doesn't waste screen real estate like some other IDEs do, it
supports proportionally spaced fonts correctly, its syntax coloring is
easy configurable (not a nightmare like some scintilla-based IDEs), and
it's instantly available on any PC on which I install Python.

I'd like to keep it in the stdlib.


+1 to keeping it in the stdlib, in case my earlier comments didn't make 
that clear.


My own reasons for submitting patches to help with Tkinter on the Mac 
are pretty typical: the Cocoa-based implementation of Tk broke some 
things in IDLE because of different methods for menu placement, etc. I 
wanted this fixed, and since I might be the only Python person with the 
knowledge about Carbon vs. Cocoa internals in Tk to do it, I dug in, 
attempted to grok IDLE's rather baroque code, and eventually came up 
with some patches. Scratching my own itch, IOW.


I'm currently using Aquamacs/Emacs for my Python development because of 
some other issues with Tk-Cocoa (external to IDLE) on Leopard, but once 
I upgrade my OS, I plan to return to using IDLE for everyday Python 
development. Since Tkinter is my GUI toolkit of choice, I like to work 
in that environment.


Also, I strongly urge Guilherme (or someone) to commit his changes to 
IDLE. While I like IDLE and feel it is a very useful IDE for Python work 
even for someone who is past the beginner stage, I also agree that its 
current UI is dated. Adding the themed Tk widgets would likely make it 
more pleasant to use, as well as showing what can be done with the new 
widgets. (The existence and widespread use of archaic Tk extensions like 
Tix within Tkinter isn't a recommendation for the toolkit beyond 
backwards compatibility.)


--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] [Idle-dev] Removing IDLE from the standard library

[Nick Coghlan]

On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou  wrote:
> +1. Don't be afraid. We are quite good at pointing out mistakes after
> the fact :)

Just make sure to subscribe to python-checkins and keep an eye out for
replies to your commits. Most post hoc review comments come in as
replies to the commit notifications :)

Hmm, do we mention that part of the process in the dev docs
anywhere?... and it turns out we do, as Brett included it in the Intro
to Development article.

Cheers,
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] PEP 3148 ready for pronouncement [ACCEPTED]

[Nick Coghlan]

On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
 wrote:
> This reminds me a lot of how things are done in C but it's not very
> pythonic.  Wouldn't it be possible and nicer to raise the exception --
> if there was one inside the asynchronous job -- when the result of the
> future is accessed?

That's what actually happens, so you can code it either way (either
just calling result() and dealing with any exception that was raised,
or else checking for a non-None exception value directly).

Cheers,
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] PEP 3148 ready for pronouncement [ACCEPTED]

[Titus von der Malsburg]

On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote:
> On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
> That's what actually happens, so you can code it either way

That's great!  None of the examples I found used the pythonic
exception style, that's why I assumed that checking the "return value"
is the only possibility.  Reading the PEP carefully would have helped.
:-)

  Titus
___
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

[Michael Foord]

On 12/07/2010 15:42, Nick Coghlan wrote:

On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou  wrote:
   

+1. Don't be afraid. We are quite good at pointing out mistakes after
the fact :)
 

Just make sure to subscribe to python-checkins and keep an eye out for
replies to your commits. Most post hoc review comments come in as
replies to the commit notifications :)
   


That mailing list (python-checkins) is way too high traffic for many 
committers to monitor. I hope people making comments on checkins also 
email the committer directly.


All the best,

Michael


Hmm, do we mention that part of the process in the dev docs
anywhere?... and it turns out we do, as Brett included it in the Intro
to Development article.

Cheers,
Nick.

   



--
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] [Idle-dev] Removing IDLE from the standard library

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Tal Einat wrote:

> On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis"  wrote:
>>> 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.
>
> That's debatable, and I disagree. IDLE-fork was a great success, for example.

We had major contributions from David Scherer, Guido, and Stephen Gava.

But a key factor in its success was that I took it upon myself to keep
IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent
merges.  Once the project was completed, I arranged with SF to move the
IDLEfork repository, including history, back into Python.

This was not done with Noam's branch.  As a result, it gradually drifted
to the point where it became essentially unmergable.

Once we switch to Hg, we should be able to use distributed vc and topic
branches to facilitate community participation without the need for a
separate project.  None of this is automatic, of course, it requires
diligence, planning, and clean topic patches.

>
> If IDLE actually had many users today, certainly some of them would be
> interested in trying out a version with usability fixes and
> improvements. Waiting for a new release of Python can take over a
> year. Furthermore, backwards compatibility issues and support by third
> party libraries can delay migration to a newer version of Python even
> further.

There's no reason why we couldn't release interim IDLE testing packages
from somewhere other than python.org (for those that don't want to track
IDLE's Hg repo).  To do this successfully, we would need to avoid using
new Python features being introduced during that development cycle,
i.e. IDLE would be compatible with the previous Python release.

-- 
KBK
___
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

[Tal Einat]

Kurt B. Kaiser wrote:
>> 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, you've got some catching up to do, yourself.  Tile went into Tk in
> 8.5, two years ago.

I was referring to the integration of the new ttk widgets into IDLE,
which still hasn't happened despite two years having gone by.

Sorry for not being clear on that point.

- 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

[Bruce Sherwood]

On Mon, Jul 12, 2010 at 3:20 AM, Kurt B. Kaiser  wrote:

>
>
> As I recollect, much of what Scherer did in VIDLE related to running
> multiple IDLE copies.
>
> For that reason, the VIDLE changes have to be evaluated carefully to
> determine what has already been incorporated.  I believe I added a
> couple of his smaller changes, also.
>
> Bruce, speaking of Dave Scherer, we've been trying to get a Python
> Contributor Agreement from him.  Is that something you can help us with?
>
> --
> KBK
>

I don't recall that VIDLE has anything to do with running multiple IDLE
copies. What's in VIDLE is a lot of bug fixes and some improvements. For
example, you can configure it to not require having to save a file, which
makes it as easy to use for quick testing as the shell. Another improvement,
of high importance for our physics students and other novice programmers, is
to bring an error display forward. Many students fill the screen with the
edit window and the error message could be hidden, leaving them puzzled as
to why their program wasn't running. Stuff like that, all aimed at issues we
had seen with a large population of science and engineering students.

I'll say again that IDLE/VIDLE is an excellent environment for novices.
Issues identified here about look and feel etc. have just not been of any
importance in that context.

If you'll send me what you want from Scherer, I can contact him.

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

[Glyph Lefkowitz]

On Jul 12, 2010, at 4:34 AM, Éric Araujo wrote:

>> Plus,  is a useful resource
>> for core developers with only a little bit of free time to do a
>> review.
> 
> Title: “Review Tickets, By Order You Should Review Them In”
> I haven’t found a description of this order, can you explain? Thanks.

Part of the reason that the report is worded that way is that we may decide 
that the order should be different, but it will still be the order that you 
should review them in :).

Right now the order is "amount of time since last change, sorted from highest 
to lowest".  In other words, first come, first serve, by last activity.

___
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?

[Michael Foord]

On 12/07/2010 15:07, Nick Coghlan wrote:

On Mon, Jul 12, 2010 at 9:42 AM, 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.
 

re2 deliberately omits some features for efficiency reasons, hence is
not even on the table as a possible replacement for the standard
library version. If someone is in a position where re2 can solve their
problems with the re module, they should also be in a position where
they can track it down for themselves.

   


If it has *partial* compatibility, and big enough performance 
improvements for common cases, it could perhaps be used where the regex 
doesn't use unsupported features. This would have some extra cost in the 
compile phase, but would mean Python could ship with two regex engines 
but only one interface exposed to the programmer...


Michael


MRAB's module offers a superset of re's features rather than a subset
though, so once it has had more of a chance to bake on PyPI it may be
worth another look.

Cheers,
Nick.

   



--
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

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Antoine Pitrou wrote:

> On Mon, 12 Jul 2010 08:12:10 -0400
> "Kurt B. Kaiser"  wrote:
>> >
>> > Ok, I've just tried IDLE (on py3k) for the first time in years. Under
>> > Linux, the look is ugly and outdated; it uses some kind of Motif-like
>> > widgets.
>> 
>> That's because Linux isn't using Tk 8.5 yet.  Debian defaults to Tk 8.5
>> in experimental since March.  Most Linux is Tk 8.4.
>
> No, that's wrong. Tk here is 8.6:
>
> $ ldd build/lib.linux-x86_64-3.2/_tkinter.so 
> [...]
>   libtk8.6.so.0 => /usr/lib64/libtk8.6.so.0 (0x7f4eb9259000)
>   libtcl8.6.so.0 => /usr/lib64/libtcl8.6.so.0 (0x7f4eb8f07000)
> [...]
>
> $ ./python -c "import tkinter; print(tkinter.TkVersion)"
> 8.6

What distro are you using?  Tk8.6 is still in beta.

Still looks crummy?  Bummer.

>> > the file open dialog is antiquated and doesn't allow me to use
>> > keyboard shortcuts).
>> 
>> Looks much better in 8.5 and the shortcuts work.
>> 
>> http://images.rant.ml1.net/idle2.gif
>
> Well, this is a Windows screenshot. I'm under Linux.

Fine, I showed it as an example of the improvement in 8.5.  Most people,
I think, are using Windows or Macs.  Looks decent, don't you think?

I don't have Tk8.5 running under Linux yet, much less 8.6.  But the Tk
release docs claim improvement under X11.

It's possible we may have to use Tk theming to get full benefit of the
Tile improvements in X11.

-- 
KBK
___
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

[Kurt B. Kaiser]

On Mon, Jul 12 2010, geremy condra wrote:

> No offense, but I've been specifically asked not to do demos with IDLE
> because it looked 'unprofessional'. Given the constraint of working
> within tkinter that may not be something you can work around, but I'm
> sure you can see that from a certain perspective that's beside the
> point.

Right, I stay away from working on Tk.  It's not even a tkinter issue.
I hope it will continue to get better, but I imagine it's a moving 
target for the Tk developers.

In your case, just bring up Wing.  That'll impress them.  As long as
it's not on netbook :-)

-- 
KBK
___
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

[Reid Kleckner]

On Mon, Jul 12, 2010 at 9:20 AM, Kurt B. Kaiser  wrote:
> Also, the current right click edit action on Windows is to only open an
> edit window; no shell.  And it uses the subprocess!  So, some of the
> comments on this thread are not up to date.
>
> The reason that bug languished for two years was because first, it was a
> bit of a hack, and second, Windows was problematic in that it reused
> sockets and often left zombie subprocesses behind which couldn't be
> killed except with the task manager.  This causes real problems with
> students - they lose confidence in the tool.
>
> Scherer and Weeble put together a patch using ephemeral ports which
> nailed the problem, and I checked it in right away and
> forward/backported it.

That's great news!  I TAed a freshman Python class this January, and
Windows users ran into this problem a lot.  Mostly when hitting 'x' in
the upper right.  Fortunately, some quick searching led me to the
Python tracker where I found the workaround.  :)

(Somwhat off-topic):  Another pain point students had was accidentally
shadowing stdlib modules, like random.  Renaming the file didn't solve
the problem either, because it left behind .pycs, which I had to help
them delete.

Overall, I would say that IDLE worked very well in that situation, so
while it does have its quirks, it worked very well for us.  Imagine
trying to get students started with Eclipse or NetBeans.  Yuck!

Reid
___
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?

[Antoine Pitrou]

On Mon, 12 Jul 2010 16:18:38 +0100
Michael Foord  wrote:
> On 12/07/2010 15:07, Nick Coghlan wrote:
> > On Mon, Jul 12, 2010 at 9:42 AM, 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.
> >>  
> > re2 deliberately omits some features for efficiency reasons, hence is
> > not even on the table as a possible replacement for the standard
> > library version. If someone is in a position where re2 can solve their
> > problems with the re module, they should also be in a position where
> > they can track it down for themselves.
> >
> >
> 
> If it has *partial* compatibility, and big enough performance 
> improvements for common cases, it could perhaps be used where the regex 
> doesn't use unsupported features. This would have some extra cost in the 
> compile phase, but would mean Python could ship with two regex engines 
> but only one interface exposed to the programmer...

You're forgetting the maintenance cost.

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

[Bill Janssen]

Stephen Hansen  wrote:

> On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden  wrote:
> 
> > 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.
> >
> 
> Er, how hostile.
> 
> My point is, the poster made an assertion-- that you couldn't do the simple
> act as launching idle from a command line, and printing Hi. Maybe they
> can't, I have no idea.
> 
> I know I can. I know that  I have also opened random python files, saved
> them, and ran them with IDLE. I don't use IDLE beyond that though: I live in
> TextMate on my mac.
> 
> My point was not, "IDLE is perfect". My point was, "You've claimed you can't
> even print out a word in IDLE, so its utterly and completely non-functional"
> -- and that assertion surprises me and I challenge.

Steve, you encouraged me to try it again.  From an xterm on OS X 10.5.8,
it launches fine (long as you know where it is --
/System/Library/Frameworks/Python.framework/Versions/Current/bin/idle).
Seems to work OK for what it is, too.  Same for Terminal.  When I start
it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window
pops up under the Emacs window, which is why I didn't see it over the
weekend.

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] Removing IDLE from the standard library

[Antoine Pitrou]

On Mon, 12 Jul 2010 11:23:04 -0400
"Kurt B. Kaiser"  wrote:
> 
> What distro are you using?  Tk8.6 is still in beta.

It's Mandriva 2010.1

> Still looks crummy?  Bummer.

Yes.

> Fine, I showed it as an example of the improvement in 8.5.  Most people,
> I think, are using Windows or Macs.  Looks decent, don't you think?

Yes, it does. If indeed the main target population for IDLE is Windows
and Mac users (since Linux users have a lot of alternatives almost by
default), then I suppose the situation is not that bad.

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?

[Tim Wintle]

On Mon, 2010-07-12 at 16:18 +0100, Michael Foord wrote: 
> On 12/07/2010 15:07, Nick Coghlan wrote:
> > On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Aprano  
> > wrote:
> >
> > re2 deliberately omits some features for efficiency reasons, hence is
> > not even on the table as a possible replacement for the standard
> > library version. If someone is in a position where re2 can solve their
> > problems with the re module, they should also be in a position where
> > they can track it down for themselves.
> >
> 
> If it has *partial* compatibility, and big enough performance 
> improvements for common cases, it could perhaps be used where the regex 
> doesn't use unsupported features. This would have some extra cost in the 
> compile phase, but would mean Python could ship with two regex engines 
> but only one interface exposed to the programmer...

I'm not sure how common those cases are - I played around with RE2 a few
months ago and found that the majority of regular expressions in my own
code were noticeably slower running under RE2 than python's re module -
RE2 just puts much nicer theoretical bounds on cases that were (in my
code at least) unusual.

The really good use case for RE2 is for applications where users can
write regular expressions as input (exactly what RE2 was designed for) -
but I'm not sure how common those applications are.

Tim Wintle

___
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

[Nick Coghlan]

On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord
 wrote:

> That mailing list (python-checkins) is way too high traffic for many
> committers to monitor. I hope people making comments on checkins also email
> the committer directly.

Not normally, no - there's no easy way to connect a checkin message to
a committer's email address, so it's usually just a matter of hitting
"Reply" and sending the review comment to the list. With a new
committer I'll make the effort to cc them directly in case they aren't
subscribed yet, but I expect everyone else to be monitor the checkins
list.

If the list is too high volume, filter it down to just those issues
with your checkin name in the "From" or "To" fields (your own checkin
messages will have the former, while replies should have the latter,
even though the email address in both cases will actually be
python-check...@python.org.

Cheers,
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] commit privs

[Collin Winter]

On Sun, Jul 11, 2010 at 9:28 AM, 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.
___
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

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Neil Hodgson wrote:

>On the main editing screen of IDLE, the most noticeable issue is
> that there is no horizontal scroll bar even though the text will move
> left when you move the caret beyond the rightmost visible character.

That was a design decision by Guido to encourage keeping to 80 columns.

> The scrollbar and status bar have an appearance that looks to be from
> Windows 2000, not Windows XP

Tk issue, maybe we can address it with theming.

> and there is no resizing gripper on the right side of the status
> bar. 

Although the corner can be dragged, that would be useful.  As I
recollect, we special-cased it so there is a space for the Mac gripper!

> The tear off menus are ugly as well as being non-standard on all three
> major platforms.

Well, would you discard them? They can (occasionally) be useful.

>Use the "Configure IDLE..." and an "idle" dialog appears that also
> looks to be from Windows 2000. I know Tk can do better than this as
> Git Gui (the Tk (8.5.8) program I use most often) at least shows XP
> themed buttons, scrollbars and other controls. However, the "idle"
> dialog (as well as Git Gui) shows the largest remaining problem for Tk
> user interfaces: keyboard navigation. When the "idle" dialog opens,
> try doing anything with the keyboard. Chances are nothing will happen.
> If you press Tab 16 times (yes, 16!) a focus rectangle will finally
> show on the "Bold" check box. Another Tab takes you to the
> "Indentation Width" slider. After that you don't see the focus until
> it wraps around to "Bold" again. The Enter key doesn't trigger OK and
> the Escape key doesn't let you escape.
>
>The Find and Replace dialogs are better as focus works as do Enter
> and Escape but none of the buttons have mnemonics.
>
>This may all sound like picking nits but details and consistency
> are important in user interfaces and this is just looking at the most
> easily discovered problems.

No, these are worthwhile improvements, and not too difficult.

-- 
Thanks, KBK
___
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

[Nick Coghlan]

On Tue, Jul 13, 2010 at 1:44 AM, Bill Janssen  wrote:
> Steve, you encouraged me to try it again.  From an xterm on OS X 10.5.8,
> it launches fine (long as you know where it is --
> /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle).
> Seems to work OK for what it is, too.  Same for Terminal.  When I start
> it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window
> pops up under the Emacs window, which is why I didn't see it over the
> weekend.

FWIW, "./python -m idlelib,idle" launched the shell window for me on
two development installs. "python -m idlelib.idle" didn't work
intially on the system Python (since Kubuntu leaves idle out by
default), but it worked fine once I installed the idle package.

(Oh, and I can confirm it still looks like a Tcl/Tk app on Kubuntu
rather than a KDE app even with Tk 8.5)

Cheers,
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

[Tal Einat]

On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote:
> On Mon, Jul 12 2010, Tal Einat wrote:
>
>> On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis"  
>> wrote:
 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.
>>
>> That's debatable, and I disagree. IDLE-fork was a great success, for example.
>
> We had major contributions from David Scherer, Guido, and Stephen Gava.
>
> But a key factor in its success was that I took it upon myself to keep
> IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent
> merges.  Once the project was completed, I arranged with SF to move the
> IDLEfork repository, including history, back into Python.
>
> This was not done with Noam's branch.  As a result, it gradually drifted
> to the point where it became essentially unmergable.

Actually, Noam's branch was pretty much merged back as is -- that's
where IDLE's auto-completion functionality came from. The later
changes he made on that branch were never merged, as you mentioned,
because Noam never bothered.

I have been maintaining my own fork of IDLE for several years and
manually keeping it in sync with IDLE (this was simple). The
difference is that there was no single major new feature I was working
on, such as the addition of a sub-process in IDLE-fork or Noam's
addition of auto-completion. I was mostly making relatively minor
fixes and changes which were not interrelated. I saw no reason to have
them all merged back at once, so I posted patches as soon as I felt
they were ready, and did the best I could to get them accepted. I
eventually gave up on this process because every patch took far too
long to be addressed and finally accepted or rejected, and I realized
that most of the work I had done would never be merged back into the
mainstream version of IDLE.
___
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

[Michael Foord]

On 12/07/2010 16:52, Nick Coghlan wrote:

On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord
  wrote:

   

That mailing list (python-checkins) is way too high traffic for many
committers to monitor. I hope people making comments on checkins also email
the committer directly.
 

Not normally, no - there's no easy way to connect a checkin message to
a committer's email address,


There's a one-to-one mapping somewhere.


so it's usually just a matter of hitting
"Reply" and sending the review comment to the list. With a new
committer I'll make the effort to cc them directly in case they aren't
subscribed yet, but I expect everyone else to be monitor the checkins
list.
   


Without contacting committers, rather than firing into the black depths 
of a high traffic list, I strongly suspect that much of the feedback is 
lost.


All the best,

Michael


If the list is too high volume, filter it down to just those issues
with your checkin name in the "From" or "To" fields (your own checkin
messages will have the former, while replies should have the latter,
even though the email address in both cases will actually be
python-check...@python.org.

Cheers,
Nick.

   



--
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

[Python-Dev] More C API abstraction for user defined types

[Petre Galan]

Hello,
Defining a user type which implements number protocol should be treated as a 
number (long) in PyArg_ParseTuple using "l" format.
In getargs.c:
case 'l': {/* long int */
long *p = va_arg(*p_va, long *);
long ival;
if (float_argument_error(arg))
return converterr("integer", arg, msgbuf, bufsize);
ival = PyLong_AsLong(arg);

if (ival == -1 && PyErr_Occurred())
return converterr("integer", arg, msgbuf, bufsize);
else
*p = ival;
break;
}
ival should not be resolved through PyLong_AsLong, but through 
functionality/interface like PyNumber_Long, thus allowing more diversity in 
accessing the PyArg_Parse interfaces.

Petre

___
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

[Ian Bicking]

On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam  wrote:

> 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.
>

I also like this idea.  This means Python comes with an IDE "out of he box"
but without the overhead of a management and release process that is built
for something very different than a GUI program (the standard library).
This would mean that IDLE would be in site-packages, could easily be
upgraded using normal tools, and maybe most importantly it could have its
own community tools and development process that is more casual (and can
more easily integrate new contributors) and higher velocity of changes and
releases.  Python releases would then ship the most recent stable release of
IDLE.

-- 
Ian Bicking  |  http://blog.ianbicking.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

[Michael Foord]

On 12/07/2010 19:21, Ian Bicking wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam > wrote:


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.


I also like this idea.  This means Python comes with an IDE "out of he 
box" but without the overhead of a management and release process that 
is built for something very different than a GUI program (the standard 
library).  This would mean that IDLE would be in site-packages, could 
easily be upgraded using normal tools, and maybe most importantly it 
could have its own community tools and development process that is 
more casual (and can more easily integrate new contributors) and 
higher velocity of changes and releases.  Python releases would then 
ship the most recent stable release of IDLE.


IDLE itself is probably stable enough that being able to "upgrade in 
place" is not a high priority. That could change based on this thread of 
course.


I would *really* support this approach with "pip" once distutils2 is 
complete and integrated into the standard library. I would really like 
Python to come with a capable package manager "out of the box" but 
understand your reluctance to tie pip to the Python release schedule. 
Having pip installed into site-packages by default, so that it *can* be 
upgraded in place, would be win-win as far as I can tell. Slight thread 
hijacking I realise... :-)


All the best,

Michael


--
Ian Bicking  | http://blog.ianbicking.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/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] A grammatical oddity: trailing commas in argument lists.

[Mark Dickinson]

On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan  wrote:
> +1 for fixing it from me, unless any of the other implementations object.
>
> @Mark: my comment on the tracker issue had an implied "...unless you
> really want to" on the end :)

Thanks! Patch at http://bugs.python.org/issue9232

Mark
___
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]

On Jul 12, 2010, at 11:36 AM, Reid Kleckner wrote:

> (Somwhat off-topic):  Another pain point students had was accidentally
> shadowing stdlib modules, like random.  Renaming the file didn't solve
> the problem either, because it left behind .pycs, which I had to help
> them delete.

I feel your pain.  It seems like every third person who starts playing with 
Twisted starts off by making a file called 'twisted.py' and then getting really 
confused by the behavior.  I would love it if this could be fixed, but I 
haven't yet thought of a solution that would be less confusing than the problem 
itself.___
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

[Oleg Broytman]

On Mon, Jul 12, 2010 at 03:48:12PM -0400, Glyph Lefkowitz wrote:
> I feel your pain.  It seems like every third person who starts playing with 
> Twisted starts off by making a file called 'twisted.py' and then getting 
> really confused by the behavior.  I would love it if this could be fixed, but 
> I haven't yet thought of a solution that would be less confusing than the 
> problem itself.

   Doesn't absolute import help?

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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] maintainers.rst enhancement

[Terry Reedy]

On 7/12/2010 7:42 AM, R. David Murray wrote:

Another 'enhancement' might be to have a program occasionally email 
people with the items they are currently signed up for, to encourage 
editing.



--
R. David Murray  www.bitdance.com



--
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] Removing IDLE from the standard library

[geremy condra]

On Mon, Jul 12, 2010 at 11:32 AM, Kurt B. Kaiser  wrote:
> On Mon, Jul 12 2010, geremy condra wrote:
>
>> No offense, but I've been specifically asked not to do demos with IDLE
>> because it looked 'unprofessional'. Given the constraint of working
>> within tkinter that may not be something you can work around, but I'm
>> sure you can see that from a certain perspective that's beside the
>> point.
>
> Right, I stay away from working on Tk.  It's not even a tkinter issue.
> I hope it will continue to get better, but I imagine it's a moving
> target for the Tk developers.
>
> In your case, just bring up Wing.  That'll impress them.  As long as
> it's not on netbook :-)

The point isn't to impress them. The point is to not embarrass us. I
just do it in gedit and ipython now, and I use an eee 901 for all my
presentations and a good bit of my work and it seems to be fine, which
is not paying much of a complement to IDLE.

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] More C API abstraction for user defined types

[Nick Coghlan]

On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan  wrote:
> ival should not be resolved through PyLong_AsLong, but through
> functionality/interface like PyNumber_Long, thus allowing more diversity in
> accessing the PyArg_Parse interfaces.

Sounds like a reasonable idea to me, but it needs to be a posted as a
feature request on the tracker.

Cheers,
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

[Martin v. Löwis]

Am 12.07.2010 13:01, schrieb Tal Einat:
> On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis"  wrote:
>>> 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?
> 
> That's not a fair question!
> 
> There have been several such patches, but most will likely need
> revision since they have been sitting around untouched for so long.
> And there would have been many more patches if the existing ones would
> have been addressed.
> 
> Getting a few current patches accepted is not the reason I posted here.

Ok. Then I guess I cannot help further - I certainly don't support
removal of IDLE from the standard library.

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

[Terry Reedy]

On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:


On Windows, IDLE opens when you right click / edit a .py. Very useful.


On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the 
installer just copies forward the association from long ago, before IDLE 
was available, or at least so usable. I have thought of changing that, 
but I do not know what the replacement incantation would be.

--
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

[Fred Drake]

On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman  wrote:
>   Doesn't absolute import help?

Not when both modules are at the top level; both acceptably provide
the same name.  The let's-play-with-it script just wasn't *intended*
to be a module.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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

[Michael Foord]

On 12/07/2010 22:33, Fred Drake wrote:

On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman  wrote:
   

   Doesn't absolute import help?
 

Not when both modules are at the top level; both acceptably provide
the same name.  The let's-play-with-it script just wasn't *intended*
to be a module.


   


I'm sure Brett will love this idea, but if it was impossible to reimport 
the script being executed as __main__ with a different name it would 
solve these problems.


Michael Foord


   -Fred

   



--
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] PEP 3148 ready for pronouncement [ACCEPTED]

[Brian Quinlan]

On 13 Jul 2010, at 00:59, Titus von der Malsburg wrote:


On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote:

On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
That's what actually happens, so you can code it either way


That's great!  None of the examples I found used the pythonic
exception style, that's why I assumed that checking the "return value"
is the only possibility.  Reading the PEP carefully would have helped.
:-)


I'd add that it would feel more natural to me to write:

 try:
   print('%r page is %d bytes' % (url, len(future.result(
- except FutureError:
-   print('%r generated an exception: %s' % (url, future.exception()))
+ except FutureError as e:
+   print('%r generated an exception: %s' % (url, e))

Cheers,
Brian
___
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]

Am 12.07.2010 23:21, schrieb Terry Reedy:
> On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
> 
>> On Windows, IDLE opens when you right click / edit a .py. Very useful.
> 
> On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the
> installer just copies forward the association from long ago, before IDLE
> was available, or at least so usable. I have thought of changing that,
> but I do not know what the replacement incantation would be.

There should be an "Edit with IDLE" (sic) context menu item.

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

[Fred Drake]

On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
 wrote:
> I'm sure Brett will love this idea, but if it was impossible to reimport the
> script being executed as __main__ with a different name it would solve these
> problems.

Indeed!  And I'd be quite content with such a solution, since I
consider scripts and modules to be distinct.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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

[Martin v. Löwis]

>> Not normally, no - there's no easy way to connect a checkin message to
>> a committer's email address,
> 
> There's a one-to-one mapping somewhere.

Unfortunately, no: we don't have email addresses of all committers.

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

[Michael Foord]

On 12/07/2010 22:47, Fred Drake wrote:

On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
  wrote:
   

I'm sure Brett will love this idea, but if it was impossible to reimport the
script being executed as __main__ with a different name it would solve these
problems.
 

Indeed!  And I'd be quite content with such a solution, since I
consider scripts and modules to be distinct.
   


It seems to bite every newbie at some point. The change would have to go 
through the usual deprecation cycle I guess.


All the best,

Michael Forod



   -Fred

   



--
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] [Idle-dev] Removing IDLE from the standard library

[Nick Coghlan]

On Tue, Jul 13, 2010 at 3:39 AM, Michael Foord
 wrote:
>> Not normally, no - there's no easy way to connect a checkin message to
>> a committer's email address,
>
> There's a one-to-one mapping somewhere.

That "somewhere" isn't readily available when I hit reply to the
checkin email though (for me, "somewhere" is generally my python-dev
archive - I think the actual mapping file is a private one on the SVN
server somewhere).

>> so it's usually just a matter of hitting
>> "Reply" and sending the review comment to the list. With a new
>> committer I'll make the effort to cc them directly in case they aren't
>> subscribed yet, but I expect everyone else to be monitor the checkins
>> list.
>>
>
> Without contacting committers, rather than firing into the black depths of a
> high traffic list, I strongly suspect that much of the feedback is lost.

Not that I've noticed. If someone doesn't respond to a comment I've
made on python-checkins I'll follow up with them directly and point
out that monitoring python-checkins for responses after making a
commit is an obligation of making use of commit privileges, just as
much as of one as running (at least relevant parts of) the test suite
before committing and then checking the buildbots to see you haven't
broken anything on other platforms.

Cheers,
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

[Benjamin Peterson]

2010/7/12 "Martin v. Löwis" :
>>> Not normally, no - there's no easy way to connect a checkin message to
>>> a committer's email address,
>>
>> There's a one-to-one mapping somewhere.
>
> Unfortunately, no: we don't have email addresses of all committers.

What about the python-committers mailing list? That has at least all
the active ones, correct?



-- 
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] [Idle-dev] Removing IDLE from the standard library

[Antoine Pitrou]

On Mon, 12 Jul 2010 17:47:31 -0400
Fred Drake  wrote:

> On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
>  wrote:
> > I'm sure Brett will love this idea, but if it was impossible to reimport the
> > script being executed as __main__ with a different name it would solve these
> > problems.
> 
> Indeed!  And I'd be quite content with such a solution, since I
> consider scripts and modules to be distinct.

Except that modules can often be executed as scripts...

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

[Terry Reedy]

On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:

Am 12.07.2010 23:21, schrieb Terry Reedy:

On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:


On Windows, IDLE opens when you right click / edit a .py. Very useful.


On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the
installer just copies forward the association from long ago, before IDLE
was available, or at least so usable. I have thought of changing that,
but I do not know what the replacement incantation would be.


There should be an "Edit with IDLE" (sic) context menu item.


I agree, and thought about requesting such, but there is not and never 
has been for me that I know of. Actually, I would like Edit with IDLE 
x.y and Run with x.y so it is easy to test a file with different versions.


XP with updates, install for everyone, make install the default Python.

Should I open a tracker issue?

--
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

[Michael Foord]

On 12/07/2010 22:52, Nick Coghlan wrote:

[snip...]

so it's usually just a matter of hitting
"Reply" and sending the review comment to the list. With a new
committer I'll make the effort to cc them directly in case they aren't
subscribed yet, but I expect everyone else to be monitor the checkins
list.

   

Without contacting committers, rather than firing into the black depths of a
high traffic list, I strongly suspect that much of the feedback is lost.
 

Not that I've noticed. If someone doesn't respond to a comment I've
made on python-checkins I'll follow up with them directly and point
out that monitoring python-checkins for responses after making a
commit is an obligation of making use of commit privileges, just as
much as of one as running (at least relevant parts of) the test suite
before committing and then checking the buildbots to see you haven't
broken anything on other platforms.

   
Given how high traffic python-checkins is I don't consider that a 
reasonable place to send follow-up and nor do I consider it the 
responsibility of committers to monitor it. As you said earlier this 
*isn't* in our standard dev procedures and nor do I think it should be. 
If you can't find an email address then either python-comitters or 
python-dev would be a better place to send feedback.


Michael


Cheers,
Nick.

   



--
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] avoiding accidental shadowing of top-level libraries by the main module

[Nick Coghlan]

On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake  wrote:
> On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
>  wrote:
>> I'm sure Brett will love this idea, but if it was impossible to reimport the
>> script being executed as __main__ with a different name it would solve these
>> problems.
>
> Indeed!  And I'd be quite content with such a solution, since I
> consider scripts and modules to be distinct.

And here I've been busily blurring that distinction for years ;)

(actually, the whole "name == '__main__'" idiom meant the distinction
was already pretty blurry long before I got involved)

I take it the concrete proposal here is if the filename of a new
module matches either __main__.__file__ or __main__.__cached__, then
that module should be ignored completely for import purposes allowing
a module with the same name later on sys.path to be found?

I'm not sure I like that, I'd be more inclined to just return the
__main__ module in that case rather than letting the search continue
further down sys.path (although I agree the current semantics of
getting two copies of the same module under different names in this
case are less than ideal).

Cheers,
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] avoiding accidental shadowing of top-level libraries by the main module

[Michael Foord]

On 12/07/2010 23:05, Nick Coghlan wrote:

On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake  wrote:
   

On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
  wrote:
 

I'm sure Brett will love this idea, but if it was impossible to reimport the
script being executed as __main__ with a different name it would solve these
problems.
   

Indeed!  And I'd be quite content with such a solution, since I
consider scripts and modules to be distinct.
 

And here I've been busily blurring that distinction for years ;)

(actually, the whole "name == '__main__'" idiom meant the distinction
was already pretty blurry long before I got involved)

I take it the concrete proposal here is if the filename of a new
module matches either __main__.__file__ or __main__.__cached__, then
that module should be ignored completely for import purposes allowing
a module with the same name later on sys.path to be found?
   


An explicit error being raised instead would be just as good.

Michael


I'm not sure I like that, I'd be more inclined to just return the
__main__ module in that case rather than letting the search continue
further down sys.path (although I agree the current semantics of
getting two copies of the same module under different names in this
case are less than ideal).

Cheers,
Nick.

   



--
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] [Idle-dev] Removing IDLE from the standard library

[Martin v. Löwis]

Am 12.07.2010 23:57, schrieb Benjamin Peterson:
> 2010/7/12 "Martin v. Löwis" :
 Not normally, no - there's no easy way to connect a checkin message to
 a committer's email address,
>>>
>>> There's a one-to-one mapping somewhere.
>>
>> Unfortunately, no: we don't have email addresses of all committers.
> 
> What about the python-committers mailing list? That has at least all
> the active ones, correct?

Probably. Also, Dirkjan is maintaining a list for the Mercurial migration.

So it is probably the case that one could be constructed if desired.
It's just that "we" (the people maintaining the subversion access
control) don't have such a list.

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

[Nick Coghlan]

On Tue, Jul 13, 2010 at 8:04 AM, Michael Foord
 wrote:
> Given how high traffic python-checkins is I don't consider that a reasonable
> place to send follow-up and nor do I consider it the responsibility of
> committers to monitor it. As you said earlier this *isn't* in our standard
> dev procedures and nor do I think it should be. If you can't find an email
> address then either python-comitters or python-dev would be a better place
> to send feedback.

Umm, yeah it is - Brett's Intro to Development *is* the documentation
of the workflow procedures, and it says that committers are expected
to subscribe to both python-checkins and python-committers.

And, as I said, I've been working this way for years, and haven't seen
any of my comments or anyone else's made on python-checkins go
unaddressed (although we've occasionally had to follow up by finding
the committer's email address and adding it directly, that's fairly
rare). It *really* isn't very hard to ignore most of the traffic on
that list and just look at your own commits (and any responses). (I
don't do that myself unless I'm busy, as I quite like doing after the
fact reviews of commits)

Bringing the whole of python-dev into a python-checkins discussion is
only necessary if there are any actual disagreements regarding a
commit (99% of what we spot in post review is just typos in
documentation, comments and text strings, as well as minor things like
poor choices of internal variable names).

Cheers,
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] avoiding accidental shadowing of top-level libraries by the main module

[Nick Coghlan]

On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord
 wrote:
> An explicit error being raised instead would be just as good.

Ah, refusing the temptation to guess.

So the idea would be, when attempting to import __main__ under it's
original name:
3.2 issue a DeprecationWarning
3.3 raise ImportError

It still strikes me as wrong for the base import implementation, but
PEP 302 may provide a mechanism for an interpreter shell to add its
own "newbie protection" hooks (and that would have the virtue of being
available much earlier and with a much lower chance of breaking
anything).

Cheers,
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

[Eric Smith]

On 7/12/2010 5:57 PM, Benjamin Peterson wrote:

2010/7/12 "Martin v. Löwis":

Not normally, no - there's no easy way to connect a checkin message to
a committer's email address,


There's a one-to-one mapping somewhere.


Unfortunately, no: we don't have email addresses of all committers.


What about the python-committers mailing list? That has at least all
the active ones, correct?


I put some effort into this a while ago and failed. Not all committers 
are subscribed, and for those that are we don't have a way of mapping 
them to names. Ideally I'd like to see a table with tracker id, 
username, email addresses, real name. But without a way of automatically 
keeping it up-to-date, I don't think it will happen.


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

[Python-Dev] Intended behavior of backlash in raw strings

[John Arbash Meinel]

I'm trying to determine if this is intended behavior:

>>> r"\""
'\\"'

>>> r'\''
"\\'"

Normally, the quote would end the string, but it gets escaped by the
preceding '\'. However, the preceding slash is interpreted as 'not a
backslash' because of the raw indicator, so it gets left in verbatim.

Note that it works anywhere:

>>> r"testing \" backslash and quote"
'testing \\" backslash and quote'

It happens that this is the behavior I want, but it seemed just as
likely to be an error. I tested it with python2.5 and 2.6 and got the
same results.

Is this something I can count on? Or is it undefined behavior and I
should really not be doing it?

John
=:->
___
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] avoiding accidental shadowing of top-level libraries by the main module

[Michael Foord]

On 12/07/2010 22:59, Antoine Pitrou wrote:

On Mon, 12 Jul 2010 17:47:31 -0400
Fred Drake  wrote:

   

On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
  wrote:
 

I'm sure Brett will love this idea, but if it was impossible to reimport the
script being executed as __main__ with a different name it would solve these
problems.
   

Indeed!  And I'd be quite content with such a solution, since I
consider scripts and modules to be distinct.
 

Except that modules can often be executed as scripts...
   


Allowing a module-executed-as-script to be in sys.modules twice with 
different names and classes is still a recipe for problems. For example 
see this blog entry from Phil Hassey, an experienced Python developer, 
caused by this issue:


http://www.philhassey.com/blog/2009/07/16/oddball-python-252-import-issue/

For scripts that need to be in sys.modules with their "real" name (e.g. 
modules executed with python -m) the following trivial workaround is 
possible:


if __name__ == '__main__':
sys.modules[real_name] = sys.modules['__main__']

That avoids the problem of error messages like:

TypeError: unbound method foo() must be called with A instance as first 
argument (got A instance instead)


(Two different classes with the same name created - one from __main__ 
and one from real_name.) Use cases for *genuinely* reimporting the same 
module with different names (as different module objects rather than 
aliases) are relatively rare, and the problem of modules *accidentally* 
reimporting themselves not that rare.


All the best,

Michael





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/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] avoiding accidental shadowing of top-level libraries by the main module

[Michael Foord]

On 12/07/2010 23:23, Nick Coghlan wrote:

On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord
  wrote:
   

An explicit error being raised instead would be just as good.
 

Ah, refusing the temptation to guess.

So the idea would be, when attempting to import __main__ under it's
original name:
3.2 issue a DeprecationWarning
3.3 raise ImportError

   

That's what I was suggesting.


It still strikes me as wrong for the base import implementation, but
PEP 302 may provide a mechanism for an interpreter shell to add its
own "newbie protection" hooks (and that would have the virtue of being
available much earlier and with a much lower chance of breaking
anything).
   


That would be a nice thing to have for earlier versions of Python. 
Personally I think the confusion the problem it causes would be nicer fixed.


All the best,

Michael


Cheers,
Nick.

   



--
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

[Michael Foord]

On 12/07/2010 23:00, Terry Reedy wrote:

On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:

Am 12.07.2010 23:21, schrieb Terry Reedy:

On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:


On Windows, IDLE opens when you right click / edit a .py. Very useful.


On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps 
the
installer just copies forward the association from long ago, before 
IDLE

was available, or at least so usable. I have thought of changing that,
but I do not know what the replacement incantation would be.


There should be an "Edit with IDLE" (sic) context menu item.


I agree, and thought about requesting such, but there is not and never 
has been for me that I know of. Actually, I would like Edit with IDLE 
x.y and Run with x.y so it is easy to test a file with different 
versions.




I have "Edit with IDLE" as a context menu option for Windows 7 - so it 
does exist *sometimes*. Either an XP issue or a "your system" issue I guess.


Michael


XP with updates, install for everyone, make install the default Python.

Should I open a tracker issue?




--
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

[Paul Moore]

On 12 July 2010 23:00, Terry Reedy  wrote:
> On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
>>
>> There should be an "Edit with IDLE" (sic) context menu item.
>
> I agree, and thought about requesting such, but there is not and never has
> been for me that I know of.

There is for me. I think what Martin meant was that the standard
install puts one there, and if you don't have one it looks like your
install is broken somehow.

> Actually, I would like Edit with IDLE x.y and
> Run with x.y so it is easy to test a file with different versions.

I'm not sure I would, too much menu clutter. But as an install-time
option I'd be OK with it.

> XP with updates, install for everyone, make install the default Python.
>
> Should I open a tracker issue?

If you can reproduce it, I guess so. But as I say, I have the entry
(Win7, 2.6.3, install for everyone, default Python). So it's not a
universal issue.

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] [Idle-dev] Removing IDLE from the standard library

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Tal Einat wrote:

> I have been maintaining my own fork of IDLE for several years and
> manually keeping it in sync with IDLE (this was simple). The
> difference is that there was no single major new feature I was working
> on, such as the addition of a sub-process in IDLE-fork or Noam's
> addition of auto-completion. I was mostly making relatively minor
> fixes and changes which were not interrelated. I saw no reason to have
> them all merged back at once, so I posted patches as soon as I felt
> they were ready, and did the best I could to get them accepted. I
> eventually gave up on this process because every patch took far too
> long to be addressed and finally accepted or rejected, and I realized
> that most of the work I had done would never be merged back into the
> mainstream version of IDLE.

There were several contributing factors.  I decided to stop committing
new features in 2.7 and focus on bugs for several reasons.  First, IDLE3
needed work to get it running smoothly.  Second, committing, forward
porting and running the (manual) functional tests on a bunch of small
features was a bit of a pain.  Third, leaving the new features to IDLE3
was a draw to get people to use the new version.  Then, about two years
ago, I got buried with PSF/PyCon issues.

If you'll look back in the IDLE NEWS, you'll see I was giving your
patches quite a bit of attention.

So never say never.

-- 
KBK
___
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]

On Jul 12, 2010, at 5:47 PM, Fred Drake wrote:

> On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
>  wrote:
>> I'm sure Brett will love this idea, but if it was impossible to reimport the
>> script being executed as __main__ with a different name it would solve these
>> problems.
> 
> Indeed!  And I'd be quite content with such a solution, since I
> consider scripts and modules to be distinct.

but ... isn't the whole point of 'python -m' to make scripts and modules _not_ 
be distinct?___
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

[Eric Smith]

On 7/12/2010 6:04 PM, Michael Foord wrote:

Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor it. As you said earlier this
*isn't* in our standard dev procedures and nor do I think it should be.
If you can't find an email address then either python-comitters or
python-dev would be a better place to send feedback.


Maybe reply-to on the checkin messages could be set to python-dev. Not 
sure if that's a mailman feature, though.


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] Removing IDLE from the standard library

[Martin v. Löwis]

Am 13.07.2010 00:00, schrieb Terry Reedy:
> On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
>> Am 12.07.2010 23:21, schrieb Terry Reedy:
>>> On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
>>>
 On Windows, IDLE opens when you right click / edit a .py. Very useful.
>>>
>>> On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the
>>> installer just copies forward the association from long ago, before IDLE
>>> was available, or at least so usable. I have thought of changing that,
>>> but I do not know what the replacement incantation would be.
>>
>> There should be an "Edit with IDLE" (sic) context menu item.
> 
> I agree, and thought about requesting such

You misunderstand. There should be such a menu item *today*, *on your
machine*. If it's not there, either the installation procedure went
wrong, or you opted out of having it.

> Should I open a tracker issue?

Please, no.

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

[Ron Adam]

On 07/12/2010 01:21 PM, Ian Bicking wrote:

On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam mailto:r...@ronadam.com>> wrote:

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.


I also like this idea.  This means Python comes with an IDE "out of he
box" but without the overhead of a management and release process that
is built for something very different than a GUI program (the standard
library).  This would mean that IDLE would be in site-packages, could
easily be upgraded using normal tools, and maybe most importantly it
could have its own community tools and development process that is more
casual (and can more easily integrate new contributors) and higher
velocity of changes and releases.  Python releases would then ship the
most recent stable release of IDLE.


Yes, if you follow the guide lines for the rest of the library, anything 
that is removed needs to be depreciated first and anything thats added 
needs to be carefully looked at to be sure it doesn't break anything that 
may depend on it.  That is good for the rest of the standard library but 
really slows things down for an application like idle.  Just removing those 
restrictions would make things a lot simpler and speed things up 
considerably I think.


The site-packages directory is still in the lib path and so things there 
are still importable.  That is why I suggested the tools directory. 
Another place would be in the same directory the python executable lives.


But the exact location isn't really the important thing, having a clear 
policy on how the upgrade policy differs from the python library is what is 
needed.


Ron




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] Removing IDLE from the standard library

[Terry Reedy]

On 7/12/2010 2:05 AM, "Martin v. Löwis" wrote:

What I specifically want right now is Commit Authorization Privilege,
especially for IDLE,


Not sure who could grant that, but as far as I can: you have it.


If I were approved to commit patches directly, then by implication I 
should be able to approve others doing the same. That is occasionally 
done now by others, but I wanted to be clear that for the present, the 
latter is all I could and would do.


--
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

[Python-Dev] python-checkins

[Antoine Pitrou]

Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit :
> Given how high traffic python-checkins is I don't consider that a 
> reasonable place to send follow-up and nor do I consider it the 
> responsibility of committers to monitor it.

You don't have to receive e-mail from it. Just take a look at the
archives from time to time after you have done some commits.
In a threaded view, it's easy to spot the few messages which aren't
commit notifications, since they are the only one not at the top-level.

Regatds

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?

[Collin Winter]

On Mon, Jul 12, 2010 at 8:18 AM, Michael Foord
 wrote:
> On 12/07/2010 15:07, Nick Coghlan wrote:
>>
>> On Mon, Jul 12, 2010 at 9:42 AM, 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.
>>>
>>
>> re2 deliberately omits some features for efficiency reasons, hence is
>> not even on the table as a possible replacement for the standard
>> library version. If someone is in a position where re2 can solve their
>> problems with the re module, they should also be in a position where
>> they can track it down for themselves.
>>
>>
>
> If it has *partial* compatibility, and big enough performance improvements
> for common cases, it could perhaps be used where the regex doesn't use
> unsupported features. This would have some extra cost in the compile phase,
> but would mean Python could ship with two regex engines but only one
> interface exposed to the programmer...

FWIW, this has all been discussed before:
http://aspn.activestate.com/ASPN/Mail/Message/python-dev/3829265. In
particular, I still believe that, "it's not obvious that enough Python
regexes would benefit from re2's performance/restrictions tradeoff to
make such a hybrid system worthwhile in the long term. (There is no
representative corpus of real-world Python regexes weighted for
dynamic execution frequency to use in assessing such tradeoffs
empirically like there is for JavaScript.)"

Collin

>> MRAB's module offers a superset of re's features rather than a subset
>> though, so once it has had more of a chance to bake on PyPI it may be
>> worth another look.
>>
>> Cheers,
>> Nick.
>>
>>
>
>
> --
> 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/collinwinter%40google.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] [Idle-dev] Removing IDLE from the standard library

[Neil Hodgson]

Kurt B. Kaiser:

>> The tear off menus are ugly as well as being non-standard on all three
>> major platforms.
>
> Well, would you discard them? They can (occasionally) be useful.

   Yes, I would replace the menus with ones missing the tear line.
Most of the GUI toolkits experimented with tear-offs (Mac in late 80s,
GTK+ up until 2002) and dropped them or hid them in a rarely visited
API. The idea initially appeared reasonable ("I can have the Run and
Check commands available with a single click") but was found to be too
confusing in use.

   IDLE, because it uses a separate top-level window for each file and
shell suffers more than most applications. A menu is torn off from one
window and always applies to that window but shows no visual affinity
with that window: its window is not even activated when a menu command
acts on it.

   Neil
___
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] python-checkins replies

[Michael Foord]

On 12/07/2010 23:48, Eric Smith wrote:

On 7/12/2010 6:04 PM, Michael Foord wrote:

Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor it. As you said earlier this
*isn't* in our standard dev procedures and nor do I think it should be.
If you can't find an email address then either python-comitters or
python-dev would be a better place to send feedback.


Maybe reply-to on the checkin messages could be set to python-dev. Not 
sure if that's a mailman feature, though.
I think this would be a good idea. It would be nice to have on-topic 
traffic here. :-)


Michael



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/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] PEP 3148 ready for pronouncement [ACCEPTED]

[Greg Ewing]

Titus von der Malsburg wrote:

None of the examples I found used the pythonic
exception style, that's why I assumed that checking the "return value"
is the only possibility.  Reading the PEP carefully would have helped.
:-)


I had to read the pep fairly carefully before I noticed
this too, so perhaps it could be made more prominent.

--
Greg
___
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