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 hav
[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 o
[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 k
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 conse
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 behavio
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
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 conse
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 p
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 so
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
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
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, sp
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
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 b
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
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 Pytho
> > 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 an
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 pote
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 an
"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 anythin
[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
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 t
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
> 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
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 pa
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
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
--
T
[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 .
_
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 informat
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 br
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
31 matches
Mail list logo
