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
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
Only reason I can think of is your inexcusable laziness for not having
done it yourself wink.
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...
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
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
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
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
[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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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
[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
[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
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
26 matches
Mail list logo
