[Python-Dev] update copyright date in PC/python_nt.rc?
Howdy, The copyright date was updated to 2005 in Python/getcopyright.c. Should the same be done in PC/python_nt.rc? Or perhaps, is there any reason python_nt.rc should NOT be updated? Cheers, Trent -- Trent Mick [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
[Python-Dev] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
I'd like to help develop Python for fun and profit and I've heard that posting patch reviews to python-dev is a good way to contribute. So here goes: PATCH REVIEW: [ 1098732 ] Skip Montanaro has written a patch which makes it so that you can inspect variable values in tracebacks. IMHO, it is a brilliant idea and can make debugging quite alot easier. However, I'm not so fond of the way that he has implemented it, it needs work. He basically outputs all names in all stackframes all the way up to the top which makes the traceback look way to cluttered. He has also implemented it as a hook to sys.excepthook, I would ike it to be the default way in which tracebacks are printed, or atleast ctivated by a command line switch to Python. What does everyone else think? Does Skip's idea have any merit? http://sourceforge.net/tracker/index.php?func=detail&aid=1098732&group_id=5470&atid=305470 -- mvh Björn ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote: Does Skip's idea have any merit? Yes, but not as a default behavior. Many people already consider the fact that tracebacks display file paths to be a potential security problem. If anything, the default traceback display should have less information, not more. (E.g., display module __name__ instead of the code's __file__). Also note that the stdlib already has a cgitb module that does this sort of display for CGI scripts, so the technique isn't new, and cgitb provides a good example for people to create their own advanced traceback formatters with. If there were another command line option added to Python for this, I'd personally prefer it be an option to enter the debugger when a terminal traceback is printed. Currently, I use 'python -i' so that I get an interpreter prompt, then use 'import pdb; pdb.pm()' to enter the debugger at the point where the error occurred. One can then print whatever local variables are desired, go up and down the stack, list code, and even perform calculations on the values on the stack. About the only place I can think of where such an extremely verbose traceback would be useful and safe, is inside of unit tests. I believe that the py.test package uses traceback introspection of this kind in order to display relevant values when an assertion fails. So, it might be useful in the context of a unit test error report to get some of that information, but even there, there is a question of how much is relevant for display. ___ 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] update copyright date in PC/python_nt.rc?
[Trent Mick] > The copyright date was updated to 2005 in Python/getcopyright.c. Should > the same be done in PC/python_nt.rc? Yes. > Or perhaps, is there any reason python_nt.rc should NOT be updated? Only reason I can think of is your inexcusable laziness for not having done it yourself . ___ 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] update copyright date in PC/python_nt.rc?
Only reason I can think of is your inexcusable laziness for not having done it yourself . Done. I'd ask whether I should backport this to release23-maint... but then I'd have to reason whether there is any point given that a 2.3.6 is unlikely. And I'd have to ask Anthony. and... enh. Trent -- Trent Mick [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
[Python-Dev] Clarification sought about including a multidimensional array object into Python core
There has recently been some much-needed discussion on the numpy-discussions list run by sourceforge regarding the state of the multidimensional array objects available for Python. It is desired by many that there be a single multidimensional array object in the Python core to facilitate data transfer and interfacing between multiple packages. I am a co-author of the current PEP regarding inclusion of the multidimensional array object into the core. However, that PEP is sorely outdated. Currently there are two multidimensional array objects that are in use in the Python community: Numeric --- original arrayobject created by Jim Hugunin and many others. Has been developed and used for 10 years. An upgrade that adds the features of numarray but maintains the same basic structure of Numeric called Numeric3 is in development and will be ready for more wide-spread use in a couple of weeks. Numarray --- in development for about 3 years. It was billed by some as a replacement for Numeric,. While introducing some new features, it still has not covered the full feature set that Numeric had making it impossible for all Numeric users to use it. In addition, it is still unacceptably slow for many operations that Numeric does well. Scientific users will always have to install more packages in order to use Python for their purposes. However, there is still the desire that the basic array object would be common among all Python users. To assist in writing a new PEP, we need clarification from Guido and others involved regarding 1) What specifically about Numeric prevented it from being acceptable as an addition to the Python core. 2) Are there any fixed requirements (other than coding style) before an arrayobject would be accepted into the Python core. Thanks for your comments. I think they will help the discussion currently taking place. -Travis Oliphant ___ 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] discourage patch reviews to the list? (was: Patch review: [ 1098732 ])
BJörn Lindqvist wrote: I'd like to help develop Python for fun and profit and I've heard that posting patch reviews to python-dev is a good way to contribute. So here goes: Are we actually promoting this? I am fine with people doing this when they have done five reviews and want their specific patch looked at (personally I prefer when people do it in a single email, but I can live with individual ones). But if people don't have that in mind, should we not be encouraging this? I mean it seems to be defeating the purpose of SF and having the various mailing lists that send out updates on SF posts. -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] Clarification sought about including a multidimensional array object into Python core
> 1) What specifically about Numeric prevented it from being acceptable as > an addition to the Python core. It's very long ago, I believe that the authors themselves didn't think it was good enough. It certainly had a very hackish coding style. Numarray was supposed to fix all that. I'm sorry to hear that it hasn't (yet) reached the maturity you find necessary. > 2) Are there any fixed requirements (other than coding style) before an > arrayobject would be accepted into the Python core. The intended user community must accept the code as "best-of-breed". It seems that the Num* community has some work to do in this respect. Also (this applies to all code) the code must be stable enough that the typical Python release cycle (about 18 months between feature releases) doesn't cause problems. Finally there must be someone willing to be responsible for maintenance of the code. -- --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] discourage patch reviews to the list?
Brett C. wrote: > But if people don't have that in mind, should we not be encouraging this? I mean it seems to be defeating the purpose of SF and having the various mailing lists that send out updates on SF posts. Clearly, the comment should *also* go to SF - posting it to python-dev may mean it gets lost eventually (in particular, when somebody gets to look at the patch). Björn did post his comment to SF, and a summary to python-dev. I personally think this is a good strategy: it puts focus on things that should be worked on. Let me explain why I think that these patches should be worked on: - it might be that the analysis of the patch suggests that the patch should be rejected, as-is. If so, it has a good chance to be closed *right away* with somebody with write privileges to the tracker, if he agrees with the analysis taken. People who care can follow the link in the email message, and see that the patch was closed. People who don't care can quickly grasp this is a patch review, and delete the message. - it might be that the analysis suggests changes. Posting it to python-dev gives the submitter of the patch a chance to challenge the review. If somebody thinks the requested changes are unecessary, they will comment. People actually prefer to discuss questionable requests for changes on the mailing list, instead of discussing them in the SF tracker. - it might be that the analysis recommend acceptance. Again, it might be that this can trigger a quick action by some committer - anybody else can safely ignore the message. However, *some* committer should take *some* action on the patch - one day or the other. Having the right to commit is a privilege, but it is also an obligation. The patch needs to be eventually looked at, and decided upon. Somebody already did the majority of the work, and suggested an action. It should be easy to decide whether this action is agreeable or not (unless the review is flawed, in which case the reviewer should be told about this). To put it the other way 'round: should we only discuss changes on python-dev which *don't* have patches on SF I don't think so. Furthermore, this strategy exposes the reviewer. A reviewer is somebody who will potentially get write access to the tracker, and perhaps CVS write access. A reviewer who wants to contribute in this way regularly clearly needs to gain the trust of other contributors, and posting smart, valuable, objective, balanced reviews on contributed patches is an excellent way to gain such trust (likewise, posting reviews which turn out to be flawed is a way to find out that the reviewer still needs to learn things before he can be trusted). Regards, Martin P.S. These remarks are mostly of general nature - I haven't actually studied yet Björn's review (but I leave it in my inbox so I can get back to it next week). ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
Phillip J. Eby wrote: Yes, but not as a default behavior. Many people already consider the fact that tracebacks display file paths to be a potential security problem. If anything, the default traceback display should have less information, not more. (E.g., display module __name__ instead of the code's __file__). Notice that this patch does not change the exception printing behaviour of Python at all. It just changes the implementation of traceback.print_exception, so it only affects code that actually uses this function. Furthermore, it only affects code that uses this function and is *changed* to supply the argument True for print_args. Also note that the stdlib already has a cgitb module that does this sort of display for CGI scripts, so the technique isn't new, and cgitb provides a good example for people to create their own advanced traceback formatters with. Sure. However, if this is frequently needed (outside the context of CGI), it would sure be helpful if the traceback module supported it. If there were another command line option added to Python for this, I'd personally prefer it be an option to enter the debugger when a terminal traceback is printed. Currently, I use 'python -i' so that I get an interpreter prompt, then use 'import pdb; pdb.pm()' to enter the debugger at the point where the error occurred. With the patch, you would have to add an explicit try/except into your code, to supply True for print_args (or set a sys.excepthook, as Skip suggests in his patch readme). 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
[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.340, 2.341
[EMAIL PROTECTED] writes: > Update of /cvsroot/python/python/dist/src/Python > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26507/Python > > Modified Files: > compile.c > Log Message: > Transform "x in (1,2,3)" to "x in frozenset([1,2,3])". > > Inspired by Skip's idea to recognize the throw-away nature of sequences > in this context and to transform their type to one with better performance. This breaks code: >>> [] in (1,) Traceback (most recent call last): File "", line 1, in ? TypeError: list objects are unhashable (and so breaks test_email -- is noone else running the test suite?). It's a cute idea, but IMHO violates the principle of least surprise too much. Cheers, mwh -- ZAPHOD: Who are you? ROOSTA: A friend. ZAPHOD: Oh yeah? Anyone's friend in particular, or just generally well-disposed to people? -- HHGttG, Episode 7 ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote: >>Does Skip's idea have >>any merit? > > Yes, but not as a default behavior. Many people already consider the > fact that tracebacks display file paths to be a potential security > problem. If anything, the default traceback display should have less > information, not more. (E.g., display module __name__ instead of the > code's __file__). Oh, come on. Making tracebacks less useful to protect people who accidentally spray them across the internet seems absurd. Would you like them not to show source, either? Cheers, mwh -- Many of the posts you see on Usenet are actually from moths. You can tell which posters they are by their attraction to the flames. -- Internet Oracularity #1279-06 ___ 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] Clarification sought about including a multidimensional array object into Python core
Travis Oliphant wrote: I am a co-author of the current PEP regarding inclusion of the multidimensional array object into the core. However, that PEP is sorely outdated. [...] 1) What specifically about Numeric prevented it from being acceptable as an addition to the Python core. 2) Are there any fixed requirements (other than coding style) before an arrayobject would be accepted into the Python core. I think you answered these questions yourself. If a PEP is sorely outdated after only 3 years of its life, there clearly is something wrong with the PEP. Python language features will have to live 10 years or so before they can be considered outdated, and then another 20 years before they can be removed (look at string exceptions as an example). So if it is still not clear what kind of API would be adequate after all these years, it is best (IMO) to wait a few more years for somebody to show up with a good solution to the problem (which I admit I don't understand). 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
On Feb 9, 2005, at 6:25 PM, Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote:
Does Skip's idea have
any merit?
Yes, but not as a default behavior. Many people already consider the
fact that tracebacks display file paths to be a potential security
problem. If anything, the default traceback display should have less
information, not more. (E.g., display module __name__ instead of the
code's __file__).
Oh, come on. Making tracebacks less useful to protect people who
accidentally spray them across the internet seems absurd. Would you
like them not to show source, either?
On Mac OS X the paths to the files are so long as to make the
tracebacks really ugly and *less* usable. I certainly wouldn't mind if
__name__ showed up instead of __file__. I have a "pywhich" script that
shows me the file given a name that I use:
(note that modulegraph.util.imp_find_module is like imp.find_module but
it will walk the packages to find the actual module and it only returns
the filename)
#!/usr/bin/env python
import sys, os
from modulegraph.util import imp_find_module
for module in sys.argv[1:]:
path,oext = os.path.splitext(imp_find_module(module)[1])
for ext in ('.py', oext):
if os.path.exists(path+ext):
print path+ext
break
-bob
___
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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
> > Oh, come on. Making tracebacks less useful to protect people who > > accidentally spray them across the internet seems absurd. Would you > > like them not to show source, either? My response exactly. > On Mac OS X the paths to the files are so long as to make the > tracebacks really ugly and *less* usable. I certainly wouldn't mind if > __name__ showed up instead of __file__. I have a "pywhich" script that > shows me the file given a name that I use: Well, sorry, but not everybody is as smart as you, and having the file name rather than the module name there helps debugging important sys.python issues. It wouldn't be the first time that someone has a hacked version of a standard module tucked away in a directory that happens to land on the path, and seeing the pathname is then a lot more productive than the module name. -- --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] Clarification sought about including a multidimensional array object into Python core
Martin v. Löwis wrote: Travis Oliphant wrote: I am a co-author of the current PEP regarding inclusion of the multidimensional array object into the core. However, that PEP is sorely outdated. [...] 1) What specifically about Numeric prevented it from being acceptable as an addition to the Python core. 2) Are there any fixed requirements (other than coding style) before an arrayobject would be accepted into the Python core. I think you answered these questions yourself. If a PEP is sorely outdated after only 3 years of its life, there clearly is something wrong with the PEP. Exactly, the PEP does not reflect the reality of what anybody wants in the core. It needs modification, or replacment. Can I just do that? Or do I need permission from Barrett and others who has only a passing interest in this anymore. Python language features will have to live 10 years or so before they can be considered outdated, and then another 20 years before they can be removed (look at string exceptions as an example). I think you misunderstood my meaning. For example Numeric has lived 10 years with very few changes. It seems to me it is rather stable. So if it is still not clear what kind of API would be adequate after all these years, it is best (IMO) to wait a few more years for somebody to show up with a good solution to the problem (which I admit I don't understand). It actually is pretty clear to many. There have been a wide variety of modules written on top of Numeric and Numarray. Most of the rough spots around the edges have been ironed out. Our arguments now are about packaging other code living on top of an arrayobject. Thanks for your help, -Travis ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
At 12:21 AM 2/10/05 +0100, Martin v. Löwis wrote: Phillip J. Eby wrote: Yes, but not as a default behavior. Many people already consider the fact that tracebacks display file paths to be a potential security problem. If anything, the default traceback display should have less information, not more. (E.g., display module __name__ instead of the code's __file__). Notice that this patch does not change the exception printing behaviour of Python at all. It just changes the implementation of traceback.print_exception, so it only affects code that actually uses this function. Furthermore, it only affects code that uses this function and is *changed* to supply the argument True for print_args. I was just responding to the OP, who was advocating it for Python default behavior, or behavior controlled by the command line. That's why I said, "Yes, but not as a default behavior." ___ 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] Clarification sought about including a multidimensional array object into Python core
On Wed, 9 Feb 2005 14:45:18 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > The intended user community must accept the code as "best-of-breed". > It seems that the Num* community has some work to do in this respect. I've not followed the num* discussion in quite a while, but my impression back then was that there wasn't "one" such community. Instead, the technical differences in the approaches required in specific fields, regarding things like the relative importance of memory profiles, speed, error handling, willingness to require modern C++ compilers, etc. made practical compromises quite tricky. I would love to be proven wrong. --david ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
At 11:25 PM 2/9/05 +, Michael Hudson wrote: "Phillip J. Eby" <[EMAIL PROTECTED]> writes: > At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote: >>Does Skip's idea have >>any merit? > > Yes, but not as a default behavior. Many people already consider the > fact that tracebacks display file paths to be a potential security > problem. If anything, the default traceback display should have less > information, not more. (E.g., display module __name__ instead of the > code's __file__). Oh, come on. Making tracebacks less useful to protect people who accidentally spray them across the internet seems absurd. Would you like them not to show source, either? I said that many people considered that to be the case, not that I did. ;) I'd personally prefer to read module names than filenames, so I guess I should've mentioned that. :) Of course, Guido has previously answered the filename vs. modulename question (years ago in fact), so it was moot even before I mentioned it. For some reason it slipped my mind at the time, though. ___ 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] Clarification sought about including a multidimensional array object into Python core
David Ascher wrote: I've not followed the num* discussion in quite a while, but my impression back then was that there wasn't "one" such community. Instead, the technical differences in the approaches required in specific fields, regarding things like the relative importance of memory profiles, speed, error handling, willingness to require modern C++ compilers, etc. made practical compromises quite tricky. I really appreciate comments from those who remember some of the old discussions. There are indeed some different needs. Most of this, however, is in the ufunc object (how do you do math with the arrays). And, a lot of this has been ameliorated with the new concepts of error modes that numarray introduced. There is less argumentation over the basic array object as a memory structure. The biggest argument right now is the design of the object: i.e. a mixture of Python and C (numarray) versus a C-only object (Numeric3). In other words, what I'm saying is that in terms of how the array object should be structure, a lot is known. What is more controversial is should the design be built upon Numarray's object structure (a mixture of Python and C), or on Numeric's --- all in C -Travis ___ 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
Phillip J. Eby wrote: I was just responding to the OP, who was advocating it for Python default behavior, or behavior controlled by the command line. That's why I said, "Yes, but not as a default behavior." I wasn't sure how to interpret the message - I could not find out whether you have looked at the patch, and agreed with it, or whether you merely read the OP's summary of the patch. 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] Clarification sought about including a multidimensional array object into Python core
Travis Oliphant wrote: Exactly, the PEP does not reflect the reality of what anybody wants in the core. It needs modification, or replacment. Can I just do that? My understanding is this: you can, and you should. You are the author of the PEP (together with Paul Barrett), and the PEP is still in Draft status (with a Python-Version of 2.2). Until the PEP is Accepted or Rejected status, you can make any changes to it that you want. It would be nice if you would track the Post-History section, and perhaps a History section at the end, pointing out that the PEP got completely restructured at some point. Or do I need permission from Barrett and others who has only a passing interest in this anymore. According to PEP 1, you could ask Barrett for a complete takeover, to remove him from the Authors list. If he agrees, there would be no problem to change that list after so much time has passed. I think you misunderstood my meaning. For example Numeric has lived 10 years with very few changes. It seems to me it is rather stable. I probably misunderstand something. If Numeric has been stable for 10 years, why is not good (no need to answer here - an answer in the PEP would be appreciated)? If there is something new to replace it, how stable is that? 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] Clarification sought about including a multidimensional array object into Python core
Travis Oliphant wrote: In other words, what I'm saying is that in terms of how the array object should be structure, a lot is known. What is more controversial is should the design be built upon Numarray's object structure (a mixture of Python and C), or on Numeric's --- all in C To me, this sounds like an implementation detail. I'm sure it is an important detail, as I understand all of this is mostly done for performance reasons. The PEP should list the options, include criteria for selection, and then propose a choice. People can then discuss whether the list of options is complete (if not, you need to extend it), whether the criteria are agreed (they might be not, and there might be difficult consensus, which the PEP should point out), and whether the choice is the right one given the criteria (there should be no debate about this - everybody should agree factually that the choice meets the criteria best). 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] discourage patch reviews to the list?
Martin v. Löwis wrote: Brett C. wrote: > But if people don't have that in mind, should we not be encouraging this? I mean it seems to be defeating the purpose of SF and having the various mailing lists that send out updates on SF posts. [SNIP] Björn did post his comment to SF, and a summary to python-dev. I personally think this is a good strategy: it puts focus on things that should be worked on. Let me explain why I think that these patches should be worked on: - it might be that the analysis of the patch suggests that the patch should be rejected, as-is. [SNIP] - it might be that the analysis suggests changes. [SNIP] - it might be that the analysis recommend acceptance. [SNIP] All valid points, but I also don't want people to suddenly start posting one-liners or bug posts. I guess it comes down to a signal-to-noise ratio and if the level of signal we are currently getting will hold. If we say it is okay for people to send in patch reviews *only* and not notifications of new patches, bug reports, or bug reviews, then I can handle it. To put it the other way 'round: should we only discuss changes on python-dev which *don't* have patches on SF I don't think so. And neither do I. I just don't want a ton of random emails on python-dev that really belong in the SF tracker instead. Reason why we don't tend to take direct bug reports in email unless there is a question over semantics. Furthermore, this strategy exposes the reviewer. A reviewer is somebody who will potentially get write access to the tracker, and perhaps CVS write access. A reviewer who wants to contribute in this way regularly clearly needs to gain the trust of other contributors, and posting smart, valuable, objective, balanced reviews on contributed patches is an excellent way to gain such trust (likewise, posting reviews which turn out to be flawed is a way to find out that the reviewer still needs to learn things before he can be trusted). That is a very good point. Guess I am softening on my rejection to this. =) If people in general agree to this idea of having people post patch reviews to python-dev I will update the dev intro essay to reflect all of this. I will also add a mention about the 5-1 patch review deal. [SNIP] P.S. These remarks are mostly of general nature - I haven't actually studied yet Björn's review (but I leave it in my inbox so I can get back to it next week). Same here. I didn't mean to single out Björn in any way. He just happened to trigger an email out of me. =) -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
[Python-Dev] Numeric life as I see it
Martin v. Löwis wrote: The PEP should list the options, include criteria for selection, and then propose a choice. People can then discuss whether the list of options is complete (if not, you need to extend it), whether the criteria are agreed (they might be not, and there might be difficult consensus, which the PEP should point out), and whether the choice is the right one given the criteria (there should be no debate about this - everybody should agree factually that the choice meets the criteria best). Unrealistic. I think it is undisputed that there are people with irreconcilably different needs. Frankly, we spent many, many months on the design of Numeric and it represents a set of compromises already. However, the one thing it wouldn't compromise on was speed, even at the expense of safety. A community exists that cannot live with this compromise. We were told that the Python core could also not live with that compromise. Over the years there was pressure to add safety, convenience, flexibility, etc., all sometimes incompatible with speed. Numarray represents in some sense the set of compromises in that direction, besides its technical innovations. Numeric / Numeric3 represents the need for speed camp. I think it is reasonable to suppose that the need for speed piece can be wrapped suitably by the need for safety-flexibility-convenience facilities. I believe that hope underlies Travis' plan. The Nummies (the official set of developers) thought that the Numeric code base was an unsuitable basis for further development. There was no dissent about that at least. My idea was to get something like what Travis is now doing done to replace it. I felt it important to get myself out of the picture after five years as the lead developer especially since my day job had ceased to involve using Numeric. However, removing my cork from the bottle released the unresolved pressure between these two camps. My plan for transition failed. I thought I had consensus on the goal and in fact it wasn't really there. Everyone is perfectly good-willed and clever and trying hard to "all just get along", but the goal was lost. Eric Raymond should write a book about it called "Bumbled Bazaar". I hope everyone will still try to achieve that goal. Interoperability of all the Numeric-related software (including supporting a 'default' plotting package) is required. Aside: While I am at it, let me reiterate what I have said to the other developers privately: there is NO value to inheriting from the array class. Don't try to achieve that capability if it costs anything, even just effort, because it buys you nothing. Those of you who keep remarking on this as if it would simply haven't thought it through IMHO. It sounds so intellectually appealing that David Ascher and I had a version of Numeric that almost did it before we realized our folly. ___ 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] discourage patch reviews to the list?
Brett C. wrote: All valid points, but I also don't want people to suddenly start posting one-liners or bug posts. I agree that keeping the noise level low is desirable; I hope this will come out naturally when we start commenting on high-noise remarks. For example, I would have no problems telling somebody who says "me too" on a feature request that he should go away and come back with an implementation of the requested feature. I would still apply the "standard" conventions of python-dev: that you should be fairly knowledgable about the things you are talking about before posting. I guess it comes down to a signal-to-noise ratio and if the level of signal we are currently getting will hold. If we say it is okay for people to send in patch reviews *only* and not notifications of new patches, bug reports, or bug reviews, then I can handle it. People do tend to notify about patches from time to time, especially when they are committers, and want to weigh in their reputation to advance peer review of the proposed changes. Other people who notify about new patches they made will continue to get my "5 for 1" offer which actually triggered this new interest in contributing-by-reviewing. Another reason not to post patches to python-dev is message size for modem users although I'm doubtful how valid this rationale is these days, given ADSL, spam, HTML mails, and everything... And neither do I. I just don't want a ton of random emails on python-dev that really belong in the SF tracker instead. Reason why we don't tend to take direct bug reports in email unless there is a question over semantics. I certainly don't want to see random comments on python-dev, either (and I do see random comments come in bursts, and have to choose to ignore entire threads because of that. I don't have to write python-dev summaries, though :-) I disagree with the primary reason not to take bug reports on python-dev, however: bug reports in email get lost if not immediately processed; usage of a tracker is necessary to actually "keep track". So this kind of bug management is the primary reason for the tracker, not that we want to keep random users out of python-dev (although this is a convenient side effect). 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] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
Phillip> I was just responding to the OP, who was advocating it for Phillip> Python default behavior, or behavior controlled by the command Phillip> line. That's why I said, "Yes, but not as a default behavior." My original intent was that it would probably not fly as default behavior. I'm not sure I would always want that behavior either. I would like it for long-running daemons that crash while unattended (places where "python -i" wouldn't really help). 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
[Python-Dev] Re: Numeric life as I see it
Martin v. Löwis wrote: The PEP should list the options, include criteria for selection, and then propose a choice. People can then discuss whether the list of options is complete (if not, you need to extend it), whether the criteria are agreed (they might be not, and there might be difficult consensus, which the PEP should point out), and whether the choice is the right one given the criteria (there should be no debate about this - everybody should agree factually that the choice meets the criteria best). Unrealistic. I think it is undisputed that there are people with irreconcilably different needs. Frankly, we spent many, many months on the design of Numeric and it represents a set of compromises already. However, the one thing it wouldn't compromise on was speed, even at the expense of safety. A community exists that cannot live with this compromise. We were told that the Python core could also not live with that compromise. I'm not sure I agree. The ufuncobject is the only place where this concern existed (should we trip OverFlow, ZeroDivision, etc. errors durring array math). Numarray introduced and implemented the concept of error modes that can be pushed and popped. I believe this is the right solution for the ufuncobject. One question we are pursuing is could the arrayobject get into the core without a particular ufunc object. Most see this as sub-optimal, but maybe it is the only way. Over the years there was pressure to add safety, convenience, flexibility, etc., all sometimes incompatible with speed. Numarray represents in some sense the set of compromises in that direction, besides its technical innovations. Numeric / Numeric3 represents the need for speed camp. I don't see numarray as representing this at all. To me, numarray represents the desire to have more flexible array types (specifically record arrays and maybe character arrays). I personally don't see Numeric3 as in any kind of "need for speed" camp either. I've never liked this distinction, because I don't think it represents a true dichotomy. To me, the differences between Numeric3 and numarray are currently more "architectural" than implementational. Perhaps you are referring to the fact that because numarray has several portions written in Python it is "more flexible" or "more convenient" but slower for small arrays. If you are saying that then I guess Numeric3 is a "need for speed" implementation, and I apologize for not understanding. I think it is reasonable to suppose that the need for speed piece can be wrapped suitably by the need for safety-flexibility-convenience facilities. I believe that hope underlies Travis' plan. If the "safety-flexibility-convenience" facilities can be specified, then I'm all for one implementation.Numeric3 design goals do not go against any of these ideas intentionally. The Nummies (the official set of developers) thought that the Numeric code base was an unsuitable basis for further development. There was no dissent about that at least. My idea was to get something like what Travis is now doing done to replace it. I felt it important to get myself out of the picture after five years as the lead developer especially since my day job had ceased to involve using Numeric. Some of the parts needed to be re-written, but I didn't think that meant moving away from the goal to have a single C-type that is the arrayobject. During this process Python 2.2 came out and allowed sub-classing from C-types. As Perry mentioned, and I think needs to be emphasized again, this changed things as any benefit from having a Python-class for the final basic array type disappeared --- beyond ease of prototyping and testing. However, removing my cork from the bottle released the unresolved pressure between these two camps. My plan for transition failed. I thought I had consensus on the goal and in fact it wasn't really there. Everyone is perfectly good-willed and clever and trying hard to "all just get along", but the goal was lost. Eric Raymond should write a book about it called "Bumbled Bazaar". This is an accurate description. Fortunately, I don't think any ill-will exists (assuming I haven't created any with my recent activities). I do want to "get-along." I just don't want to be silent when there are issues that I think I understand. I hope everyone will still try to achieve that goal. Interoperability of all the Numeric-related software (including supporting a 'default' plotting package) is required. Utopia is always out of reach :-) Aside: While I am at it, let me reiterate what I have said to the other developers privately: there is NO value to inheriting from the array class. Don't try to achieve that capability if it costs anything, even just effort, because it buys you nothing. Those of you who keep remarking on this as if it would simply haven't thought it through IMHO. It sounds so intellectually appealing that David Asc
Re: [Python-Dev] Re: Numeric life as I see it
[Paul] > > Aside: While I am at it, let me reiterate what I have said to the > > other developers privately: there is NO value to inheriting from the > > array class. Don't try to achieve that capability if it costs > > anything, even just effort, because it buys you nothing. Those of you > > who keep remarking on this as if it would simply haven't thought it > > through IMHO. It sounds so intellectually appealing that David Ascher > > and I had a version of Numeric that almost did it before we realized > > our folly. [Travis] > I appreciate some of what Paul is saying here, but I'm not fully > convinced that this is still true with Python 2.2 and up new-style > c-types. The concerns seem to be over the fact that you have to > re-implement everything in the sub-class because the base-class will > always return one of its objects instead of a sub-class object. > It seems to me, however, that if the C methods use the object type > alloc function when creating new objects then some of this problem is > avoided (i.e. if the method is called with a sub-class type passed in, > then a sub-class type gets set). This would severely constrain the __new__ method of the subclass. > Have you looked at how Python now allows sub-classing in C? I'm not an > expert here, but it seems like a lot of the problems you were discussing > have been ameliorated. There are probably still issues, but > > I will know more when I seen what happens with a Matrix Object > inheriting from a Python C-array object. And why would a Matrix need to inherit from a C-array? Wouldn't it make more sense from an OO POV for the Matrix to *have* a C-array without *being* one? > I'm wondering if anyone else with more knowledge about new-style c-types > could help here and show me the error of my thinking. I'm trying... -- --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: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
[Travis] I appreciate some of what Paul is saying here, but I'm not fully convinced that this is still true with Python 2.2 and up new-style c-types. The concerns seem to be over the fact that you have to re-implement everything in the sub-class because the base-class will always return one of its objects instead of a sub-class object. It seems to me, however, that if the C methods use the object type alloc function when creating new objects then some of this problem is avoided (i.e. if the method is called with a sub-class type passed in, then a sub-class type gets set). This would severely constrain the __new__ method of the subclass. I obviously don't understand the intricacies here, so fortunately it's not a key issue for me because I'm not betting the farm on being able to inherit from the arrayobject. But, it is apparent that I don't understand all the issues. Have you looked at how Python now allows sub-classing in C? I'm not an expert here, but it seems like a lot of the problems you were discussing have been ameliorated. There are probably still issues, but I will know more when I seen what happens with a Matrix Object inheriting from a Python C-array object. And why would a Matrix need to inherit from a C-array? Wouldn't it make more sense from an OO POV for the Matrix to *have* a C-array without *being* one? The only reason I'm thinking of here is to have it inherit from the C-array many of the default methods without having to implement them all itself. I think Paul is saying that this never works with C-types like arrays, and I guess from your comments you agree with him. The only real reason for wanting to construct a separate Matrix object is the need to overload the * operation to do matrix multiplication instead of element-by-element multiplication. -Travis ___ 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: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
On Wed, 09 Feb 2005 22:02:11 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote: GvR: >And why would a Matrix need to inherit from a C-array? Wouldn't it >make more sense from an OO POV for the Matrix to *have* a C-array >without *being* one? Travis: > The only reason I'm thinking of here is to have it inherit from the > C-array many of the default methods without having to implement them all > itself. I think Paul is saying that this never works with C-types like > arrays, and I guess from your comments you agree with him. > > The only real reason for wanting to construct a separate Matrix object > is the need to overload the * operation to do matrix multiplication > instead of element-by-element multiplication. This is dredging stuff up from years (and layers and layers of new memories =), but I think that what Paul was referring to was in fact independent of implementation language. The basic problem, IIRC, had to do with the classic (it turns out) problem of confusing the need for reuse of implementation bits with interface inheritance. We always felt that things that people felt were "array-like" (Matrices, missing value arrays, etc.) _should_ inherit from array, and that (much like you're saying), it would save work. In practice, however, there were a few problems (again, from lousy memory), all boiling down to the fact that the array object implemenation implies interfaces that weren't actually applicable to the others. The biggest problems had to do with the fact that when you do subclassing, you end up in a nasty combinatorial problem when you wanted to figure out what operand1 operator operand2 means, if operand1 is a derivative and operand2 is a different derivative. In other words, if you multiply a matrix with a missingvalues array, what should you do? Having a common inheritance means you need to _stop_ default behaviors from happening, to avoid meaningless results. It gets worse with function calls that take "array-like objects" as arguments. A lot of this may be resolvable with the recent notions of adaptation and more formalized interfaces. In the meantime, I would, like Paul, recommend that you separate the interface-bound type aspects (which is what Python classes are in fact!) from the implementation sharing. This may be obvious to everyone, and if so, sorry. --david ___ 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
