Mailman 3 Python 2.1 PEPs - Python-Dev

Python 2.1 PEPs

barry＠digicool.com

17 Apr 2001 17 Apr '01

9:53 p.m.

Now that Python 2.1 is officially out the door, it's time to do some spring cleaning on the PEPs. I'm currently processing the latest batch of PEP requests, and I'm going to create a Python 2.2 release schedule PEP. It's time to make an update pass through PEP 0 too. Here are the following PEPs that are marked as "Active for Python 2.1", along with a small commentary about changing their status. PEP authors, please take a close look at your Python 2.1 PEPs and make any final revisions that are necessary. Let me know if you disagree with my proposed disposition of the PEP. Note: individual PEP owners should update their own PEPs; I will take care of noodging you and updating PEP 0. If you are unable to make commits to the PEPs, send the updated text to me and I'll commit them. I 42 pep-0042.txt Small Feature Requests Hylton The perennial PEP, this will be moved to the "Python 2.2 Current" category. It should be updated if necessary. S 205 pep-0205.txt Weak References Drake Fred should do an update pass to reflect Python 2.1 Reality (e.g. weakref.mapping()). This PEP should then be marked as Final and moved to the Finished PEPs category. I 226 pep-0226.txt Python 2.1 Release Schedule Hylton This PEP should get a final pass (no need for "tentative"s any more!), marked as Final and moved to the Finished category. S 227 pep-0227.txt Statically Nested Scopes Hylton Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality, then mark it as Final and I'll move it to the Finished category. S 229 pep-0229.txt Using Distutils to Build Python Kuchling Andrew, same deal with this PEP... S 233 pep-0233.txt Python Online Help Prescod What is up with this PEP? Progress on this seems to have stalled, so I propose marking it "Deferred" and moving it out of the active PEP category (to where, I'm not yet sure). S 235 pep-0235.txt Import on Case-Insensitive Platforms Peters I think this one's done, so it should be marked as Final and moved to the Finished PEPs category. Tim should make any final edits necessary. S 236 pep-0236.txt Back to the __future__ Peters Same for this one, Tim... S 243 pep-0243.txt Module Repository Upload Mechanism Reifschneider This isn't strictly tied to the Python 2.1 release, so I propose to simply shuffle it over to the "Active for Python 2.2" category. Cheers, -Barry

Show replies by date

Guido van Rossum

17 Apr 17 Apr

10:07 p.m.

...

I 226 pep-0226.txt Python 2.1 Release Schedule Hylton

This PEP should get a final pass (no need for "tentative"s any more!), marked as Final and moved to the Finished category.

Could we recycle this PEP number for the 2.1.1 release schedule (see my previous post here)? That seems easier than having a new PEP for each micro-release.

...

S 227 pep-0227.txt Statically Nested Scopes Hylton

Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality, then mark it as Final and I'll move it to the Finished category.

I have promised Jeremy a bunch of updates to this. I'll get on it.

...

S 229 pep-0229.txt Using Distutils to Build Python Kuchling

Andrew, same deal with this PEP...

S 233 pep-0233.txt Python Online Help Prescod

What is up with this PEP? Progress on this seems to have stalled, so I propose marking it "Deferred" and moving it out of the active PEP category (to where, I'm not yet sure).

Superseded by pydoc, I imagine. Working code beats ambitious plans every time :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

barry＠digicool.com

10:36 p.m.

...

...
...
...
...
"GvR" == Guido van Rossum writes:

GvR> Could we recycle this PEP number for the 2.1.1 release GvR> schedule (see my previous post here)? That seems easier than GvR> having a new PEP for each micro-release. PEP numbers are a plentiful resource! I'd prefer to give it a new PEP number. >> S 227 pep-0227.txt Statically Nested Scopes Hylton GvR> I have promised Jeremy a bunch of updates to this. I'll get GvR> on it. Excellent, thanks. GvR> Superseded by pydoc, I imagine. Working code beats ambitious GvR> plans every time :-)

...

...
...
...
...
"PP" == Paul Prescod writes:

PP> Ping asked to take over the code because he wanted to do it PP> with Pydoc. He didn't do the online help part. I'm not sure PP> if he thought I was going to do that part or if he just didn't PP> get to it. Either way, it is less than a weekend's work to add PP> pydoc to the interactive shell (and thus make it "online PP> help") so I can do it in the next few weeks. GvR> Actually, "from pydoc import help" already works; after that GvR> you can type "help" or "help(module)" etc. Or is "online GvR> help" more than that? So Paul, what should be done about PEP 233? Move it to "active for Python 2.2"? -Barry

Paul Prescod

18 Apr 18 Apr

12:03 a.m.

"Barry A. Warsaw" wrote:

...

So Paul, what should be done about PEP 233? Move it to "active for Python 2.2"?

Move it to "implemented." We can haggle about details but most of the features I'd hoped for are implemented thanks to Ping! -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

barry＠digicool.com

3:47 a.m.

...

...
...
...
...
"PP" == Paul Prescod writes:

>> So Paul, what should be done about PEP 233? Move it to >> "active for Python 2.2"? PP> Move it to "implemented." We can haggle about details but most PP> of the features I'd hoped for are implemented thanks to Ping! Can you please update the text of PEP 233 to reflect Current (or near-Current) Reality? Thanks, -Barry

Guido van Rossum

3:53 a.m.

...

GvR> Could we recycle this PEP number for the 2.1.1 release GvR> schedule (see my previous post here)? That seems easier than GvR> having a new PEP for each micro-release.

PEP numbers are a plentiful resource! I'd prefer to give it a new PEP number.

One day I'm going to argue that anything limited to 4 digits can't possibly be called "plentiful", but not this millennium. :-) I didn't mean to save a PEP number -- I just meant to keep the 2.1 followup releases together. I explained this to Barry over lunch and he agrees now. --Guido van Rossum (home page: http://www.python.org/~guido/)

barry＠digicool.com

3:46 a.m.

...

...
...
...
...
"GvR" == Guido van Rossum writes:

GvR> One day I'm going to argue that anything limited to 4 digits GvR> can't possibly be called "plentiful", but not this GvR> millennium. :-) Just as plentiful as 32-bit IP addresses, oil reserves, and 640KB of main memory... oh wait. :) GvR> I didn't mean to save a PEP number -- I just meant to keep GvR> the 2.1 followup releases together. I explained this to GvR> Barry over lunch and he agrees now. Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to PEP 226. -Barry

Guido van Rossum

5:19 a.m.

...

GvR> I didn't mean to save a PEP number -- I just meant to keep GvR> the 2.1 followup releases together. I explained this to GvR> Barry over lunch and he agrees now.

Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to PEP 226.

OK. So we need a 2.2.1 Czar. Any volunteers? --Guido van Rossum (home page: http://www.python.org/~guido/)

Thomas Wouters

3:26 p.m.

On Tue, Apr 17, 2001 at 06:49:07PM -0500, Guido van Rossum wrote:

...

...
GvR> I didn't mean to save a PEP number -- I just meant to keep GvR> the 2.1 followup releases together. I explained this to GvR> Barry over lunch and he agrees now.

Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to PEP 226.

...

OK. So we need a 2.2.1 Czar. Any volunteers?

I assume you mean a 2.1.x Czar :) I'm willing to do it, given that it doesn't require much attention *now* (except checking the checkin messages, which I do anyway) and I fully expect to be able to free all the time I need in a few weeks anyway. But I'm perfectly happy with Moshe or someone else doing it, too. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Guido van Rossum

8:34 p.m.

...

...
...
Yup, but I'll leave it to you (or the 2.1.1 Czar) to make changes to PEP 226.

...
OK. So we need a 2.2.1 Czar. Any volunteers?

I assume you mean a 2.1.x Czar :)

Yes. :-)

...

I'm willing to do it, given that it doesn't require much attention *now* (except checking the checkin messages, which I do anyway) and I fully expect to be able to free all the time I need in a few weeks anyway. But I'm perfectly happy with Moshe or someone else doing it, too.

Excellent. I'd say let's divide labor here -- piling it all on Moshe isn't fair. You & Moshe can have a race who gets the first bugfix release out! :-) PEP 226 is all yours! --Guido van Rossum (home page: http://www.python.org/~guido/)

Tim Peters

2:25 p.m.

[Guido]

...

... I didn't mean to save a PEP number -- I just meant to keep the 2.1 followup releases together. I explained this to Barry over lunch and he agrees now.

I added a "[bugfix release dates go here]" marker to PEP 226 to remind him <wink>. Jeremy (he's still listed as the author) may want to clear out the "Open issues for Python 2.0 beta 2" section.

Paul Prescod

17 Apr 17 Apr

10:28 p.m.

"Barry A. Warsaw" wrote:

...

...

S 233 pep-0233.txt Python Online Help Prescod

What is up with this PEP? Progress on this seems to have stalled, so I propose marking it "Deferred" and moving it out of the active PEP category (to where, I'm not yet sure).

Ping asked to take over the code because he wanted to do it with Pydoc. He didn't do the online help part. I'm not sure if he thought I was going to do that part or if he just didn't get to it. Either way, it is less than a weekend's work to add pydoc to the interactive shell (and thus make it "online help") so I can do it in the next few weeks. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

Guido van Rossum

10:29 p.m.

...

Ping asked to take over the code because he wanted to do it with Pydoc. He didn't do the online help part. I'm not sure if he thought I was going to do that part or if he just didn't get to it. Either way, it is less than a weekend's work to add pydoc to the interactive shell (and thus make it "online help") so I can do it in the next few weeks.

Actually, "from pydoc import help" already works; after that you can type "help" or "help(module)" etc. Or is "online help" more than that? Ping pointed out (in private email) that adding pydoc.help to __builtin__ in site.py is the wrong thing to do because pydoc is large and it would slow down startup too much. He recommended to add a small bootstrap function instead that imports and invokes pydoc.help instead. --Guido van Rossum (home page: http://www.python.org/~guido/)

Paul Prescod

10:58 p.m.

Guido van Rossum wrote:

...

...

Actually, "from pydoc import help" already works; after that you can type "help" or "help(module)" etc. Or is "online help" more than that?

No, that looks like it is basically what you want. I didn't envision help as a totally separate "mode" but I'm not picky.

...

Ping pointed out (in private email) that adding pydoc.help to __builtin__ in site.py is the wrong thing to do because pydoc is large and it would slow down startup too much. He recommended to add a small bootstrap function instead that imports and invokes pydoc.help instead.

Right, but the bootstrap was always part of the proposal! Now that you've pointed out the impressive online help facility in pydoc it seems that the only thing we need to make it exactly what I envisioned is a few lines of code. I'm sorry I didn't figure that out last week! All it would take now is class help: def __repr__(self): import pydoc __builtins__.help = pydoc.help repr(__builtins__.help) But hindsight is 20/20. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

Thomas Wouters

11:20 p.m.

On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:

...

All it would take now is

class help: def __repr__(self): import pydoc __builtins__.help = pydoc.help repr(__builtins__.help)

...

But hindsight is 20/20.

You realize this isn't going to work, right ? The 'help' class will shadow the 'help' builtin. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Paul Prescod

18 Apr 18 Apr

12:28 a.m.

Thomas Wouters wrote:

...

On Tue, Apr 17, 2001 at 10:28:15AM -0700, Paul Prescod wrote:

...
All it would take now is

class help: def __repr__(self): import pydoc __builtins__.help = pydoc.help repr(__builtins__.help)

...
But hindsight is 20/20.

You realize this isn't going to work, right ? The 'help' class will shadow the 'help' builtin.

We do not have to call the class "help" nor to define it in the __main__ or __builtins__ context. Or were you getting at something deeper? -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

Ka-Ping Yee

12:43 a.m.

On Tue, 17 Apr 2001, Paul Prescod wrote:

...

Right, but the bootstrap was always part of the proposal!

Right.

...

All it would take now is

class help: def __repr__(self): import pydoc __builtins__.help = pydoc.help repr(__builtins__.help)

Yes, pretty much. I suggested something to that effect on Friday night. (Guido decided it was too late in the game to change site.py at that point.) Here was my proposed addition to site.py: # Define the built-in object "help" to provide interactive help. class Helper: def __repr__(self): import inspect if inspect.stack()[1][3] == '?': # not called from a function self() return '' return '<Helper instance>' def __call__(self, arg=None): import pydoc pydoc.help(arg) __builtin__.help = Helper() Why the strange check involving inspect.stack()? inspect.stack()[1][3] is the co_name of the parent frame. If we check that the __repr__ is not being requested by a function call, everything works perfectly in IDLE as well as the plain interpreter, and the helper object is still safe to pass around. Nothing breaks even if you say help(help). The above few lines are a reasonable addition to sitecustomize.py if you happen to be setting up a local installation of Python. -- ?!ng "If I have seen farther than others, it is because I was standing on a really big heap of midgets." -- K. Eric Drexler

Guido van Rossum

3:50 a.m.

...

Why the strange check involving inspect.stack()? inspect.stack()[1][3] is the co_name of the parent frame. If we check that the __repr__ is not being requested by a function call, everything works perfectly in IDLE as well as the plain interpreter, and the helper object is still safe to pass around. Nothing breaks even if you say help(help).

This is one of the reasons why I didn't want to add this to the 2.1 release at such a late point. I have no easy way to verify that this is always true, and in fact I have no idea what inspect.stack()[1][3] means. :-( I just add "from pydoc import help" to my $PYTHONSTARTUP file. --Guido van Rossum (home page: http://www.python.org/~guido/)

Ka-Ping Yee

4:34 a.m.

On Tue, 17 Apr 2001, Guido van Rossum wrote:

...

This is one of the reasons why I didn't want to add this to the 2.1 release at such a late point. I have no easy way to verify that this is always true, and in fact I have no idea what inspect.stack()[1][3] means. :-(

Would you have preferred to write sys._getframe().f_back.f_code.co_name ? It's the same thing. -- ?!ng "If I have seen farther than others, it is because I was standing on a really big heap of midgets." -- K. Eric Drexler

Guido van Rossum

11:31 a.m.

...

On Tue, 17 Apr 2001, Guido van Rossum wrote:

...
This is one of the reasons why I didn't want to add this to the 2.1 release at such a late point. I have no easy way to verify that this is always true, and in fact I have no idea what inspect.stack()[1][3] means. :-(

Would you have preferred to write

sys._getframe().f_back.f_code.co_name

? It's the same thing.

Well, that clears up one mystery. The rest of your explanation of why this is correct (as opposed to why this works in the two cases you've tried :-) is still completely opaque to me...

...

# Define the built-in object "help" to provide interactive help. class Helper: def __repr__(self): import inspect if inspect.stack()[1][3] == '?': # not called from a function self() return '' return '<Helper instance>' def __call__(self, arg=None): import pydoc pydoc.help(arg) __builtin__.help = Helper()

Why the strange check involving inspect.stack()? inspect.stack()[1][3] is the co_name of the parent frame. If we check that the __repr__ is not being requested by a function call, everything works perfectly in IDLE as well as the plain interpreter, and the helper object is still safe to pass around. Nothing breaks even if you say help(help).

--Guido van Rossum (home page: http://www.python.org/~guido/)

Jeremy Hylton

7:37 p.m.

...

...
...
...
...
"KPY" == Ka-Ping Yee writes:

KPY> On Tue, 17 Apr 2001, Guido van Rossum wrote:

...

...
This is one of the reasons why I didn't want to add this to the 2.1 release at such a late point. I have no easy way to verify that this is always true, and in fact I have no idea what inspect.stack()[1][3] means. :-(

KPY> Would you have preferred to write KPY> sys._getframe().f_back.f_code.co_name KPY> ? It's the same thing. It's certainly clearer that inspect.stack()[1][3]. Does the existence of the inspect module imply that we need to maintain its interface? If we did, then we have some weird limits on the order of things in stack frames. Jeremy

Tim Peters

3:44 p.m.

...

S 236 pep-0236.txt Back to the __future__ Peters

Same for this one, Tim...

Part of the initial text in this should (as PEP 236 itself says) move into PEP 5, but other than that it reflects 2.1's reality. PEP 5 is Paul's. Happy to move stuff into PEP 5 for him, but the instant I do that you just *know* Guido will force me to change all sorts of things in PEP 5 that Paul would vehemently disown <wink>.

Paul Prescod

4:05 p.m.

Tim Peters wrote:

...

...
S 236 pep-0236.txt Back to the __future__ Peters

Same for this one, Tim...

Part of the initial text in this should (as PEP 236 itself says) move into PEP 5, but other than that it reflects 2.1's reality. PEP 5 is Paul's. Happy to move stuff into PEP 5 for him, but the instant I do that you just *know* Guido will force me to change all sorts of things in PEP 5 that Paul would vehemently disown <wink>.

If you want to work out a clear status for PEP 5's process, you're welcome to take it over! -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

8408

Age (days ago)

8409

Last active (days ago)

List overview

Download

22 comments

7 participants

participants (7)

barry＠digicool.com
Guido van Rossum
Jeremy Hylton
Ka-Ping Yee
Paul Prescod
Thomas Wouters
Tim Peters

Python 2.1 PEPs

barry＠digicool.com

Guido van Rossum

barry＠digicool.com

Paul Prescod

barry＠digicool.com

Guido van Rossum

barry＠digicool.com

Guido van Rossum

Thomas Wouters

Guido van Rossum

Tim Peters

Paul Prescod

Guido van Rossum

Paul Prescod

Thomas Wouters

Paul Prescod

Ka-Ping Yee

Guido van Rossum

Ka-Ping Yee

Guido van Rossum

Jeremy Hylton

Tim Peters

Paul Prescod

tags

participants (7)