[Python-Dev] TRUNK FREEZE for 2.5b2, tomorrow Tuesday 11th, 00:00 UTC
The trunk is frozen from 00:00 UTC Tuesday the 11th of July. This is in about 16 hours or so time. As usual, unless you're a member of the release team, please don't checkin past that time until I send an email that the release is done. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] "Missing" 2.5 feature
Tim Peters wrote: > Just to make life harder ;-), I should note that code, docs and tests > for sys._current_frames() are done, on the tim-current_frames branch. > All tests pass, and there are no leaks in the new code. It's just a > NEWS blurb away from being just another hectic release memory :-) Wouldn't this function be better named sys._getframes since we already have a sys._getframe for getting the current frame? -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] "Missing" 2.5 feature
On Sun, 9 Jul 2006 20:45:05 -0700, Neal Norwitz wrote: > There hasn't been much positive response (in the original thread or > here). Given you forgot about it for over a year, how important can > it be? :-) For me it would be very important because I often wonder where the threads are currently working in my multithreaded apps. As a partial solution, I wrote a "thread monitor" that tracks all thread's frames using a trace function and generates tracebacks on demand. This slows down program execution of course. With that function, it would be much simpler to see the current state of the program (which is trivial in environments like the JVM for example). Kind regards, Alexander ___ 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] Explicit Lexical Scoping (pre-PEP?)
>> > Part of the reason why its so hard to name this feature is that >> > it's real name is something like "Hey, Python, you know that cool >> > funky thing you do with defining variables in the same scope as >> > they are assigned? Well, don't do that here." Guido> Sorry, that sounds like a B.S. argument. You can translate most Guido> language constructs into long sentences if you want to. I think Talin's got a point though. It seems hard to find one short English word that captures the essence of the desired behavior. None of the words in his list seem strongly suggestive of the meaning to me. I suspect that means one's ultimately as good (or as bad) as the rest. how-about-"lookout"?-ly, y'rs, Skip ___ 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] "Missing" 2.5 feature
On 10/07/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote: > On Sun, 9 Jul 2006 20:45:05 -0700, Neal Norwitz wrote: > > > There hasn't been much positive response (in the original thread or > > here). Given you forgot about it for over a year, how important can > > it be? :-) > I'm the SoC student working on the improvements for pdb, one of the improvements is allowing thread debugging. I was in fact, going to use the threadframe module if it was available on the system, having this method in the Python core is an even better solution. cheering-for-tim-ly yr's, Matt -- http://mattssanctuary.blogspot.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] User's complaints
Hi, On Tue, Jul 04, 2006 at 04:49:13PM -0700, Neal Norwitz wrote: > On 7/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > From actual users of > > the language I get more complaints about the breakneck speed of > > Python's evolution than about the brokenness of the current language. I'd like to report another (subjective) experience in favor of the "Python is complete enough already" camp, from last year's EuroPython, during Guido's keynote. He announced he accepted two of the major 2.5 PEPs: the 'yield' extension, and I think the 'with' statement. This didn't draw much applause. It certainly gave me the impression that many changes in Python are advocated and welcomed by only a small fraction of users. I cannot be objective here, though, being myself firmly of the impression that there are only so many syntactic features you can put in a language before it stops being elegant and starts promoting obscure code... > PS. One thing I tend to talk to users about is stability of the > interpreter. When I talk about crashing the interpreter, the most > common first reaction I get is "you can crash the interpreter? How do > you do that?" I take that answer as a good sign. :-) Indeed :-) Getting some more python-dev discussions about Lib/test/crashers/*.py would be nice too, though. A bientot, Armin ___ 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] Fix for Lib/test/leakers/test_gestalt.py
I think this fixes the leak in Lib/test/leakers/test_gestalt.py. Index: Python/mactoolboxglue.c === --- Python/mactoolboxglue.c (revision 50522) +++ Python/mactoolboxglue.c (working copy) @@ -60,8 +60,9 @@ strncpy(buf, input, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; } + Py_DECREF(rv); } - + Py_XDECREF(m); return buf; } I'm less sure about this one, but it looks like the DECREF is also required: Index: Python/mactoolboxglue.c === --- Python/mactoolboxglue.c (revision 50522) +++ Python/mactoolboxglue.c (working copy) @@ -60,8 +60,9 @@ strncpy(buf, input, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; } + Py_DECREF(rv); } - + Py_XDECREF(m); return buf; } Thomas ___ 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] "Missing" 2.5 feature
[Neal Norwitz] > There hasn't been much positive response (in the original thread or > here). Do note that there was little response of any kind, but all it got was positive. It's not sexy, but is essential for debugging deadlocks. If you ask for positive response, you'll get some -- the use is obvious for those who need it. I didn't (and don't) think this needs a "sales job". > Given you forgot about it for over a year, how important can it be? :-) Important enough that I stopped beating my wife to write the code ;-) > What's the justifcation to add this feature, but none of the others? Don't know which others you have in mind. This is very simple code, changes no existing behaviors, and has no potential to break other code. There is an extension module that tries to do the same, but can't do so wholly safely. It needs to be in the core to be done correctly. The new code, docs and tests are 100% ready to go. How do the others you have in mind stack up against those, point by point? > Can we defer this to 2.6? Of course, although waiting another ~18 months given the above seems needlessly wasteful. ___ 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] Discussion on Lib/test/crashers/
As I am sure some have noticed, as part of my dissertation I have been trying to fix the various crashers. I currently have some patches in SF for some of the crashers. The other ones Armin and I have been talking, while others I have not started yet. Review for the patches or help with fixing the ones I have not gotten to would be great. http://www.python.org/sf/1202533 has a potential fix for the infinite_rec_*.py crashers. PyObject_Call() basically needs a recursion check. But there were some issues with PyErr_NormalizeException() blowing up while trying to normalize the exception, that also needs to watch out for hitting the recursion limit and returning a RuntimeError that does not need normalization itself. http://www.python.org/sf/1377858 has a patch for weakref_in_del.py . Turns out if you create a new weakref in a __del__ for self the weakref is never notified that self is gone and it no longer has a valid weakref to anything. Added a check after __del__ is called to make sure that if any weakrefs were created that they get cleared. http://www.python.org/sf/1303614 is a discussion currently between Armin and I on how to handle del___dict__.py . Looks like more careful reference counting is needed, but Armin is worried about a performance hit. There is also a patch there to fix loosing_dict_ref.py . dangerous_subclassing.py, modify_dict_attr.py, and nasty_eq_vs_dict.py I have not gotten to yet. I am ignoring bogus_code_obj.py, gc_inspection.py, and recursive_call.py since they either require setting the recursion depth higher or involve an extension module. -Brett ___ 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] Add new PyErr_WarnEx() to 2.5?
As noted in http://mail.python.org/pipermail/python-dev/2006-May/065478.html it looks like we need a new Python C API function to make new warnings from the struct module non-useless. For example, runnning test_zipfile on Windows now yields """ test_zipfile C:\Code\python\lib\struct.py:63: DeprecationWarning: struct integer overflow masking is deprecated return o.pack(*args) """ This is useless because the message points _into_ struct.py, not to the code calling struct.pack(). Consequently I have no idea where the offending pack() call is, and neither do you ;-) The current PyErr_Warn() doesn't allow for passing a non-zero `stacklevel` argument to warnings.warn(), so there's little the C code in _struct.c can do to make the warning more useful. ___ 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] Discussion on Lib/test/crashers/
Brett Cannon wrote: > As I am sure some have noticed, as part of my dissertation I have been > trying to fix the various crashers. Nice project. One quick thought: Any crasher that relies on gc.get_referrers() should not be considered a bug. The codebase should not be convoluted, complexified, obfucated, altered, touched, or slowed down just prevent perverse, sadistic safe-cracking using this tool. The docs are clear on this subject: "Care must be taken when using objeccts returned by get_referrers() becasue some of them could still be under construction and hence in a temporarily invalid state. Avoid using get_referrers() for any purpose other than debugging." Raymond ___ 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] Discussion on Lib/test/crashers/
On 7/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> As I am sure some have noticed, as part of my dissertation I have been> trying to fix the various crashers.Nice project.One quick thought: Any crasher that relies on gc.get_referrers() shouldnot be considered a bug.Right. That is on the list of crashers I am ignoring. The codebase should not be convoluted,complexified, obfucated, altered, touched, or slowed down just preventperverse, sadistic safe-cracking using this tool. The docs are clear onthis subject:"Care must be taken when using objeccts returned by get_referrers() becasue some of them could still be under construction and hence in atemporarily invalid state. Avoid using get_referrers() for any purposeother than debugging."And I am trying to make sure all the fixes are not superfluous but fix actual issues in the code and behaviour of Python. -Brett ___ 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] "Missing" 2.5 feature
Tim Peters wrote: [Neal Norwitz] There hasn't been much positive response (in the original thread or here). Do note that there was little response of any kind, but all it got was positive. It's not sexy, but is essential for debugging deadlocks. If you ask for positive response, you'll get some -- the use is obvious for those who need it. I didn't (and don't) think this needs a "sales job". FWIW, I think this patch should go in. The benefits are obvious and real. But, the imagined costs of a new feature during beta are illusory. In this case, practicality beats pedantry. For the users, it is a net win if this goes in. Raymond ___ 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] "Missing" 2.5 feature
+1 On 7/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Tim Peters wrote: > [Neal Norwitz] > > > There hasn't been much positive response (in the original thread or > here). > > Do note that there was little response of any kind, but all it got was > positive. It's not sexy, but is essential for debugging deadlocks. > If you ask for positive response, you'll get some -- the use is > obvious for those who need it. I didn't (and don't) think this needs > a "sales job". > > > > FWIW, I think this patch should go in. The benefits are obvious and real. > But, the imagined costs of a new feature during beta are illusory. > > In this case, practicality beats pedantry. For the users, it is a net win > if this goes in. > > > Raymond > > > > ___ > 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/guido%40python.org > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: > I think Talin's got a point though. It seems hard to find one short English > word that captures the essence of the desired behavior. None of the words > in his list seem strongly suggestive of the meaning to me. I suspect that > means one's ultimately as good (or as bad) as the rest. What's wrong with "nonlocal"? I don't think i've seen an argument against that one so far (from Talin or others). -- ?!ng ___ 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] User's complaints
On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote: > didn't draw much applause. It certainly gave me the impression that > many changes in Python are advocated and welcomed by only a small > fraction of users. The benefits of changes are usually clear, but I don't think the costs of changes are fully assessed. python-dev considers the cost of changes to CPython's implementation, but I don't think the cost changes to Jython, IronPython, or PyPy are taken into account here. PyPy probably has enough representatives here who would squawk if something was difficult, but I don't think Jython or IronPython do. I think if we assessed those costs fully, the bar for changes to the language would be a good deal higher. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: > > I think Talin's got a point though. It seems hard to find one short English > > word that captures the essence of the desired behavior. None of the words > > in his list seem strongly suggestive of the meaning to me. I suspect that > > means one's ultimately as good (or as bad) as the rest. > > What's wrong with "nonlocal"? I don't think i've seen an argument > against that one so far (from Talin or others). It's a made-up word. You won't find it in the dictionary and the google define: query sends me to a wikipedia page about quantum mechanics. It also expresses itself in the negative form "not local" as opposed to the positive form like global "this is a global." Finally, I think it sounds yucky. To express this email in the positive form: 1. Reserved words should be real words. 2. The meaning of the word should be clear. 3. "Put statements in positive form." (Strunk & White) 4. The word should sound good. global meets all of these requirements. "free" was the word I remember preferring from earlier discussions, but I think it fails #2. (Too much confusion about freeing memory, for example.) Jeremy > > > -- ?!ng > ___ > 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/jeremy%40alum.mit.edu > ___ 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] "Missing" 2.5 feature
On Tuesday 11 July 2006 06:16, Raymond Hettinger wrote: > FWIW, I think this patch should go in. The benefits are > obvious and real. Yep. I'm going to check it in, unless someone else beats me to it in the next couple of hours before the b2 freeze. > But, the imagined costs of a new feature > during beta are illusory. This, I cannot agree with. The costs and risks of just continuing to add new features all through the release process are high. The chances of us releasing a broken Python increases dramatically. Then we have to do emergency bugfix releases. And I'm sorry, but the release process is not something that's zero work. Sure, it's zero work _for_ _you_ , but not for Martin, Fred and myself. > In this case, practicality beats pedantry. I don't think trying to produce the most stable and bugfree Python possible could in _anyway_ be considered "pedantry", and it makes me quite grumpy to have it described in that way. > For the users, it > is a net win if this goes in. In the case of this feature, that's true. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Explicit Lexical Scoping (pre-PEP?)
> What's wrong with "nonlocal"? I don't think i've seen an argument > against that one so far (from Talin or others). It sounds a bit awkward to me. Also, it would be nice if the keyword indicated which scope was operative. If I've followed the discussions correctly, I think the parent scope would be operative, so I humbly suggest "parent". Mike ___ 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] "Missing" 2.5 feature
[Raymond] >> FWIW, I think this patch should go in. The benefits are >> obvious and real. [Anthony Baxter] > Yep. I'm going to check it in, unless someone else beats me to it in > the next couple of hours before the b2 freeze. I'll merge it from my branch right after I send this email. It still needs a NEWS blurb, which I'll write. Thanks! You made the right decision :-) >> But, the imagined costs of a new feature during beta are illusory. > This, I cannot agree with. The costs and risks of just continuing to > add new features all through the release process are high. The > chances of us releasing a broken Python increases dramatically. Then > we have to do emergency bugfix releases. And I'm sorry, but the > release process is not something that's zero work. Sure, it's zero > work _for_ _you_ , but not for Martin, Fred and myself. I agree. For example, even here (i.e., a pure, simple "new feature"), as I noted from the start, it's possible that my doc changes broke the LaTeX somehow, and that would be disruptive. >> In this case, practicality beats pedantry. > I don't think trying to produce the most stable and bugfree Python > possible could in _anyway_ be considered "pedantry", and it makes me > quite grumpy to have it described in that way. He meant that "no new features", while a useful guideline, can be counterproductive if followed slavishly. >> For the users, it is a net win if this goes in. > In the case of this feature, that's true. More to the point, at this stage in the release process this specific little new feature carries almost no risk of loss for anyone. ___ 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] "Missing" 2.5 feature
On Tuesday 11 July 2006 06:52, Tim Peters wrote: > > I don't think trying to produce the most stable and bugfree > > Python possible could in _anyway_ be considered "pedantry", and > > it makes me quite grumpy to have it described in that way. > > He meant that "no new features", while a useful guideline, can be > counterproductive if followed slavishly. I'm not taking a slavish "no new features" line. I _am_ saying that any new features, post beta, require a good justification and a clear understanding of the risks that are added by the new code. In this case, the tradeoff is fine. Simply saying code is very low risk isn't enough - there also has to be a positive reason for the code going in. The ability to debug deadlocks is a good thing, and the clincher (once I sat and thought about it a bit) is that there is _already_ a module out there that attempts to do this, albeit in a buggy fashion. This is pretty clear indication that there is a demand for the feature. Similarly, the PyErr_WarnEx() is _probably_ a good thing to add in, because otherwise we can't do anything about the struct warning. But that really will have to wait until post-beta2 at this point. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Klocwork analysis of source if we want it
http://www.klocwork.com/company/releases/06_26_06.aspLooks like Klocowork is doing the same thing as Coverity and providing free static analysis of source for open source projects. Doubt we want this *and* Coverity, but figured wouldn't hurt to let people know about it. -Brett ___ 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] "Missing" 2.5 feature
Anthony Baxter wrote: But, the imagined costs of a new feature during beta are illusory. This, I cannot agree with. The costs and risks of just continuing to add new features all through the release process are high. I meant this particular feature. In general, there ought to be some distinction between patches that affect everything (i.e. AST) and patches that affect a tiny portion of the universe (a new itertool or Tim's patch) -- the latter tend to be poorly exercised during beta releases anyway, so we are kidding ourselves about the impact of putting them in a second beta. IMO, the most substantial risks we have with Py2.5 still lie with the big changes that went in early. The SF tracker indicates that these are still not fully debugged. And I'm sorry, but the release process is not something that's zero work. No doubt about that. You work is appreciated and your decisions are respected. I'm just suggesting a shift in emphasis to where the risks are. For the users, it is a net win if this goes in. In the case of this feature, that's true. It seems we're thinking along the same lines. Raymond ___ 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] Fix for Lib/test/leakers/test_gestalt.py
Thomas Heller schrieb:
> I think this fixes the leak in Lib/test/leakers/test_gestalt.py.
>
> Index: Python/mactoolboxglue.c
> ===
> --- Python/mactoolboxglue.c (revision 50522)
> +++ Python/mactoolboxglue.c (working copy)
> @@ -60,8 +60,9 @@
> strncpy(buf, input, sizeof(buf) - 1);
> buf[sizeof(buf) - 1] = '\0';
> }
> + Py_DECREF(rv);
> }
> -
> + Py_XDECREF(m);
> return buf;
> }
>
>
> I'm less sure about this one, but it looks like the DECREF
> is also required:
(Here's the patch that I *really* meant)
Index: Mac/Modules/macosmodule.c
===
--- Mac/Modules/macosmodule.c (Revision 50515)
+++ Mac/Modules/macosmodule.c (Arbeitskopie)
@@ -375,6 +375,7 @@
/* And try again... */
h = GetResource('Estr', err);
}
+ Py_DECREF(m);
}
}
/*
Thomas
___
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] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > What's wrong with "nonlocal"? I don't think i've seen an argument > against that one so far (from Talin or others). On Mon, 10 Jul 2006, Jeremy Hylton wrote: > It's a made-up word. You won't find it in the dictionary and the > google define: query sends me to a wikipedia page about quantum > mechanics. Two million Google hits for "nonlocal" seems like plenty. The explanation of "nonlocal" is pretty straightforward -- If the definition of f() contains an assignment to x, then x is a local variable in f, unless x is declared nonlocal. > To express this email in the positive form: > 1. Reserved words should be real words. > 2. The meaning of the word should be clear. > 3. "Put statements in positive form." (Strunk & White) > 4. The word should sound good. > > global meets all of these requirements. But it's the wrong word. "Purple" also meets all of these requirements. I'd rather accurately express the concept in the negative (the true meaning really is in the negative: "don't make a new binding"), than choose a simple-sounding word that is essentially a lie. x = 1 def f(x): print x def g(): global x x = 3 print x The "x" used in g is not global at all -- it belongs to f. -- ?!ng ___ 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] User's complaints
Not to mention the cost to documentation and books everywhere -- updating our own docs is only the tip of the iceberg. And then updating the users' brains is an even bigger job... (Though at least it is highly parallellizable. :-) --Guido On 7/10/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote: > > didn't draw much applause. It certainly gave me the impression that > > many changes in Python are advocated and welcomed by only a small > > fraction of users. > > The benefits of changes are usually clear, but I don't think the costs > of changes are fully assessed. python-dev considers the cost of > changes to CPython's implementation, but I don't think the cost > changes to Jython, IronPython, or PyPy are taken into account here. > PyPy probably has enough representatives here who would squawk if > something was difficult, but I don't think Jython or IronPython do. > > I think if we assessed those costs fully, the bar for changes to the > language would be a good deal higher. > > --amk > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:> > I think Talin's got a point though. It seems hard to find one short English > > word that captures the essence of the desired behavior. None of the words> > in his list seem strongly suggestive of the meaning to me. I suspect that> > means one's ultimately as good (or as bad) as the rest. >> What's wrong with "nonlocal"? I don't think i've seen an argument> against that one so far (from Talin or others).It's a made-up word. You won't find it in the dictionary and the google define: query sends me to a wikipedia page about quantummechanics. It also expresses itself in the negative form "not local"as opposed to the positive form like global "this is a global." Finally, I think it sounds yucky.To express this email in the positive form:1. Reserved words should be real words.2. The meaning of the word should be clear.3. "Put statements in positive form." (Strunk & White) 4. The word should sound good.global meets all of these requirements. "free" was the word Iremember preferring from earlier discussions, but I think it fails #2. (Too much confusion about freeing memory, for example.) I remember previous discussions also referring to spelling this as "outer" which IMO passes #2 as well as the other, although arguably #4 is subjective ;-).-Almann -- Almann T. Goo[EMAIL PROTECTED] ___ 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] Explicit Lexical Scoping (pre-PEP?)
Guido van Rossum wrote: > Then let's allow > > nonlocal x = 12 > > as a shortcut for > > nonlocal x > x = 12 I thought you didn't like that, because in nonlocal x = 12 x = 42 it's not clear whether these are talking about the same x or not. -- 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
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Mike Krell wrote: > If I've followed the discussions correctly, I think the parent scope > would be operative, so I humbly suggest "parent". -1, this is far too commonly used as a variable name. -- 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
Re: [Python-Dev] "Missing" 2.5 feature
[Scott Dial] > Wouldn't this function be better named sys._getframes since we already > have a sys._getframe for getting the current frame? http://mail.python.org/pipermail/python-dev/2005-March/051887.html The first & only name suggested won. As it says there, I usually have no appetite for naming arguments. ___ 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] Support for PyGetSetDefs in pydoc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patch #1520294 adds support for attributes defined with PyGetSetDef in extension modules to pydoc, specifically so things like help (array.array.typecode) gives something useful, like the attribute's docstring for instance. Along the way, I added types.GetSetterType and inspect.isgetsetter(), along with tests and docs. Now I definitely think that the pydoc change should go into Python 2.5 and be backported to Python 2.4, but it's a bit of a question whether the types.py and inspect.py changes should go into Python 2.5 now that we're in beta. I personal think they're worthwhile changes to go it, but I won't argue too hard for them since the pydoc fixes can be implemented with local changes to pydoc.py alone. Thoughts? - -Barry https://sourceforge.net/tracker/? func=detail&atid=305470&aid=1520294&group_id=5470 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLMEYnEjvBPtnXfVAQKB8gQAmkk0V0B0xdRD/Xgko4vD0JmvFiXZL3EO bEzE9Wtn8u54JB/EXLdocjeFLjlOzlSzalLKGvxgQHyKGP0F8CSBN6mIreTsztct wl58FyPro3mkwsamUrkPzf/xSZk/4tO81oXPkuzqANbv+0WEnD5MmdSpVqz7jQIo qqbAqah2ha4= =kxSp -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] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > > What's wrong with "nonlocal"? I don't think i've seen an argument > > against that one so far (from Talin or others). > > On Mon, 10 Jul 2006, Jeremy Hylton wrote: > > It's a made-up word. You won't find it in the dictionary and the > > google define: query sends me to a wikipedia page about quantum > > mechanics. > > Two million Google hits for "nonlocal" seems like plenty. > The explanation of "nonlocal" is pretty straightforward -- > > If the definition of f() contains an assignment to x, then > x is a local variable in f, unless x is declared nonlocal. > > > To express this email in the positive form: > > 1. Reserved words should be real words. > > 2. The meaning of the word should be clear. > > 3. "Put statements in positive form." (Strunk & White) > > 4. The word should sound good. > > > > global meets all of these requirements. > > But it's the wrong word. "Purple" also meets all of these requirements. No. Don't be silly. The current use of global meets the requirements. The meaning there is clear, because global means global namespace. If purple were a keyword, I wouldn't know what it means. I was not proposing the use of global for some other meaning (and thought I made that clear in the remainder of the message). Jeremy > > I'd rather accurately express the concept in the negative (the > true meaning really is in the negative: "don't make a new binding"), > than choose a simple-sounding word that is essentially a lie. > > x = 1 > > def f(x): > print x > > def g(): > global x > x = 3 > print x > > The "x" used in g is not global at all -- it belongs to f. > > > -- ?!ng > ___ 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] Explicit Lexical Scoping (pre-PEP?)
On Mon, 2006-07-10 at 16:43 -0400, Jeremy Hylton wrote: > To express this email in the positive form: > 1. Reserved words should be real words. > 2. The meaning of the word should be clear. > 3. "Put statements in positive form." (Strunk & White) > 4. The word should sound good. As I've been following this thread I find that the word "extern" keeps coming to mind. It's debatable whether "extern" passes #1, although my dictionary has an entry for it. But more importantly, there seems to be fairly strong parallels between what we're discussing here and its meaning in C/C++ (i.e. the symbol is defined outside of the current scope). So I think "extern" easily passes #2 for C/C++ programmers, and I think others can probably guess that extern == external (my wife did, at least). I haven't seen this suggested yet so I thought I'd just throw it out there. Matt ___ 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] Explicit Lexical Scoping (pre-PEP?)
On Mon, 10 Jul 2006, Jeremy Hylton wrote: > The current use of global meets the requirements. The meaning there > is clear, because global means global namespace. If purple were a > keyword, I wouldn't know what it means. I was not proposing the use > of global for some other meaning (and thought I made that clear in the > remainder of the message). My apologies. I misunderstood you -- i thought you were suggesting it as an alternative to "nonlocal". -- ?!ng ___ 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] Doctest and Footnotes
A coworker of mine (Gary Poster) had a really good idea a couple weeks ago: teach doctest about ReST-style footnotes. I implemented it over the weekend and brought it to Tim Peter's attention today. Tim generally liked the idea and suggested I bring it up here. Here's the idea: when a footnote is referenced in prose, execute the code associated with the footnote at that point. For example: """ After initializing the system [#init]_ it is possible to retrieve status information: >>> system.status() 'good to go' [snip some of the doctest] .. [#init] Initialize the system: >>> system = System() >>> system.init() """ The footnote code is executed every time the footnote is referenced, and is /not/ executed at any other time (i.e. it's not executed at the point the footnote is defined). A warning is generated if a footnote (that includes code) is defined but never used. This would allow moving repetitive or verbose code (e.g. tests for corner cases) into footnotes so they won't hinder the documentation aspect of a test. It also allows defining reusable bits of setup code, freeing the doctest author to structure the prose as they wish instead of being constrained by having to place bits of code with common environmental needs together. I've implemented this in a branch of zope.testing (which contains a copy of a post-Python 2.4.3 version of doctest (http://tinyurl.com/nekam). The behavior is controlled by an optionflag, much like ELLIPSIS or NORMALIZE_WHITESPACE. Tim has given me a few pointers on improvements to make, which I'll work on this week. Thoughts/questions? -- Benji York Senior Software Engineer Zope Corporation ___ 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] Explicit Lexical Scoping (pre-PEP?)
>> What's wrong with "nonlocal"? I don't think i've seen an argument >> against that one so far (from Talin or others). Mike> It sounds a bit awkward to me. Also, it would be nice if the Mike> keyword indicated which scope was operative. Sounds awkward to me as well. Couldn't put my finger on it until seeing Jeremy's post though. I don't think the keyword should indicate a scope. I'd prefer it if LOAD_ just percolated its way up the chain of cells (or could be identified at compile time by inspecting the AST as I think Guido intends) without the programmer having to name the binding scope. Maybe if it names the function containing the variable to bind. Nothing static (like "up 3 levels") though. Mike> If I've followed the discussions correctly, I think the parent Mike> scope would be operative, so I humbly suggest "parent". Since it might not just be in the immediate parent scope, how about "ancestor"? <0.5 wink> Skip ___ 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] Doctest and Footnotes
At 11:36 PM 7/10/2006 -0400, Benji York wrote: >The footnote code is executed every time the footnote is referenced, and >is /not/ executed at any other time (i.e. it's not executed at the point >the footnote is defined). A warning is generated if a footnote (that >includes code) is defined but never used. > >This would allow moving repetitive or verbose code (e.g. tests for >corner cases) into footnotes so they won't hinder the documentation >aspect of a test. It also allows defining reusable bits of setup code, >freeing the doctest author to structure the prose as they wish instead >of being constrained by having to place bits of code with common >environmental needs together. > >I've implemented this in a branch of zope.testing (which contains a copy >of a post-Python 2.4.3 version of doctest (http://tinyurl.com/nekam). >The behavior is controlled by an optionflag, much like ELLIPSIS or >NORMALIZE_WHITESPACE. Tim has given me a few pointers on improvements >to make, which I'll work on this week. > >Thoughts/questions? It would be nice if tracebacks in the footnote show the invoking context, so that if a footnote is invoked from more than one place, you'll be able to tell which one from any errors that occur. I haven't looked at the code, so perhaps you've already done this. My other thought would be that having a patch that works against the 2.5 version of doctest would be good, as 2.5 has fixes to make doctest work with zipped (or egged) doctest files. Apart from those two comments, it sounds like an interesting idea. ___ 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] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I don't think the keyword should indicate a scope. > I'd prefer it if LOAD_ just percolated its way up the chain of > cells (or could be identified at compile time by inspecting the AST as I > think Guido intends) without the programmer having to name the binding > scope. I agree completely. I realize that probably wasn't clear when I said "it would be nice if the keyword indicated which scope was operative". I was really only trying to proffer a keyword which would hopefully suggest to a newbie that they should percolate up the chain of scopes. In this sense, the word "outer" works for me, but I'm sympathetic to Andrew Koenig's argument that "outer" is confusing because the innermost binding is actually affected. > Since it might not just be in the immediate parent scope, how about > "ancestor"? <0.5 wink> That thought had occurred to me, but then I beat it down with a stick :-) My rationale was that the affected binding is the one seen by the parent, even if the parent did not create the binding itself. Greg Ewing's point about parent being a common variable name is well-taken, though. Mike ___ 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] Explicit Lexical Scoping (pre-PEP?)
Ka-Ping Yee wrote: > On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: > >>I think Talin's got a point though. It seems hard to find one short English >>word that captures the essence of the desired behavior. None of the words >>in his list seem strongly suggestive of the meaning to me. I suspect that >>means one's ultimately as good (or as bad) as the rest. > > > What's wrong with "nonlocal"? I don't think i've seen an argument > against that one so far (from Talin or others). Well, I just think that a fix for "an aesthetic wart" should be, well, aesthetic :) I also think that it won't be a complete disaster if we do nothing at all - there *are* existing ways to deal with this problem; there are even some which aren't hackish and non-obvious. For example, its easy enough to create an object which acts as an artificial scope: def x(): scope = object() scope.x = 1 def y(): scope.x = 2 To my mind, the above code looks about as elegant and efficient as most of the proposals put forward so far, and it already works. How much are we really saving here by building this feature into the language? -- Talin ___ 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] In defense of Capabilities [was: doc for new restricted execution design for Python]
Brett Cannon wrote: > Using a factory method callback, one could store the PyCodeObject in a C > proxy object that just acts as a complete delegate, forwarding all method > calls to the internally stored PyCodeObject. That would work. > > > For this initial implementation, though, I am not going to try to support > this. We can always add support like this later since it doesn't > fundamentally break or change anything that is already planned. Let's > focus > on getting even more basic stuff working before we start to get too fancy. > > -Brett Thinking about this some more, I've come up with a simpler idea for a generic wrapper class. The wrapper consists of two parts: a decorator to indicate that a given method is 'public', and a C 'guard' wrapper that insures that only 'public' members can be accessed. So for example: from Sandbox import guard, public class FileProxy: # Public method, no decorator @public def read( length ): ... @public def seek( offset ): ... # Private method, no decorator def open( path ): ... # Construct an instance of FileProxy, and wrap a # guard object around it. Any attempt to access a non-public # attribute will raise an exception (or perhaps simply report # that the attribute doesn't exist.) fh = guard( FileProxy() ) Now, from my point of view this *is* 'the basic stuff'. In other words, this right here is the fundamental sandbox mechanism, and everything else is built on top of it. Now, the C 'guard' function is only a low-level means to insure that no-one can mess with the object; It is not intended to be the actual restriction policy itself. Those are placed in the wrapper classes, just as in your proposed scheme. (This goes back to my basic premise, that a simple "yes/no" security feature can be used to build up much more complex and subtle security features.) The only real complexity of this, as I see it, is that methods to references will have to be themselves wrapped. In other words, if I say 'fh.read' without the (), what I get back can't be the actual read function object - that would be too easy to fiddle with. What I'd have to get is a wrapped version of the method that is a callable. One relatively simply way to deal with this is to have the 'public' decorator create a C wrapper for the function object, and store it as an attribute of the function. The class wrapper then simply looks up the attribute, and if it has an attribute wrapper, returns that, otherwise it fails. (Although, I've often wished for Python to have a variant of __call__ that could be used to override individual methods, i.e.: __call_method__( self, methodname, *args ) This would make the guard wrapper much easier to construct, since we could restrict the methods only to being called, and not allow references to methods to be taken.) -- Talin ___ 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] Klocwork analysis of source if we want it
Brett Cannon wrote: > http://www.klocwork.com/company/releases/06_26_06.asp > > Looks like Klocowork is doing the same thing as Coverity and providing > free static analysis of source for open source projects. Doubt we want > this *and* Coverity, but figured wouldn't hurt to let people know about it. See http://python.org/sf/1484556 ISTM that it generates too many false positives to be useful. 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] Explicit Lexical Scoping (pre-PEP?)
Jeremy Hylton wrote: > To express this email in the positive form: > 1. Reserved words should be real words. > 2. The meaning of the word should be clear. > 3. "Put statements in positive form." (Strunk & White) > 4. The word should sound good. agreed. a word should describe what a thing is, not what it isn't. not entirely sure about "global", though; things like "outer" and "extern(al)" might be better (especially if we could ignore C, which I don't think we can). cannot think of prior art here, but there has to be some. anyone ? ___ 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] Explicit Lexical Scoping (pre-PEP?)
Talin wrote: > I also think that it won't be a complete disaster if we do nothing at > all - there *are* existing ways to deal with this problem; there are > even some which aren't hackish and non-obvious. For example, its easy > enough to create an object which acts as an artificial scope: > > def x(): >scope = object() >scope.x = 1 >def y(): > scope.x = 2 > > To my mind, the above code looks about as elegant and efficient as most > of the proposals put forward so far, and it already works. > > How much are we really saving here by building this feature into the > language? I don't think anyone commented on my "mutable" post, but as I mentioned in that post, if you look at the use cases for this, what most use cases really need is *mutation*, not *rebinding*. ___ 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] easy_install
Here's something to discuss: First, let me say that I love easy_install. I absolutely "just works" and does what I want, and makes it really simple to install whatever bit of Python code I need. At the same time, however, I get kind of scared when I hear people on the list discussing the various hacks needed to get setuputils and distutils et al all playing nice with each other (monkeypatching, etc.) Having done a small bit of fiddling with distutils myself (as a user, I mean), I can see that while there's a terrific amount of effort put into it, its also not for the feignt of heart. That's not entirely distutil's fault - I gather that it's dealing with a lot of accumulated cruft (I imagine things like different and strange ways of archiving modules, dynamic modifications to path, all that sort of thing.) It seems to me that if someone was going to spend some energy on this list coming up with proposals to improve Python, the thing that would have the most positive benefit in the long run (with the possible exception of Brett's work on rexec) would be a unified and clean vision of the whole import / package / download architecture. Now, speaking from complete ignorance here, I might be way off base - it may be that this matter is well in hand, perhaps on some other mailing list. I don't know. In any case, I wanted to throw this out there... -- Talin ___ 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] Explicit Lexical Scoping (pre-PEP?)
On 7/10/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Jeremy Hylton wrote: > > > To express this email in the positive form: > > 1. Reserved words should be real words. > > 2. The meaning of the word should be clear. > > 3. "Put statements in positive form." (Strunk & White) > > 4. The word should sound good. > > agreed. a word should describe what a thing is, not what it isn't. Just looking at a thesaurus, came up with expose. Not to mention outward, remote, peripheral and without. We already have a 'with' keyword, why not 'without'? Oh, I guess it fails #3...and #2...and #4 too. Screw it, just go with alien. :-) http://thesaurus.reference.com/browse/outer n ___ 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
