sturlamolden a écrit :
> On 13 Des, 19:16, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
> Personally I find properties atrocious and unsafe.
What a strange observation from someone wanting to introduce defmacros
and customizable syntax in Python
> One cannot
> distinguish between a function
Aahz wrote:
>> Unless it's a new style class with __slots__
>
> []
>
> Naw, I'll skip the rant this time. ;-)
Wuss! I was looking forward to it :)
Tim Delaney
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Christian Heimes <[EMAIL PROTECTED]> wrote:
>Steven D'Aprano wrote:
>>
>> I'm not quite sure I understand that criticism. How is that different
>> from things which are not properties?
>>
>> foo.baz = 2 # oops, I meant bar
>>
>> will succeed regardless of whether
Steven D'Aprano wrote:
> I'm not quite sure I understand that criticism. How is that different
> from things which are not properties?
>
> foo.baz = 2 # oops, I meant bar
>
> will succeed regardless of whether foo.bar is an attribute or a property.
Unless it's a new style class with __slots__
On Thu, 13 Dec 2007 13:35:24 -0800, sturlamolden wrote:
> On 13 Des, 19:16, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
>> I don't feel that it's especially inconsistent, and I like decorators.
>> Having to write foo everywhere isn't that nice, but it's only mildly
>> worse than C# to me - I find
Duncan Booth wrote:
> Unfortunately as currently implemented, getter setter and deleter just
> update the existing property, so the getter defined in B changes how the
> property works in A as well. I think the intention may have been that they
> should create a new property each time, but this
On 13 Des, 19:16, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> I don't feel that it's especially inconsistent, and I like decorators.
> Having to write foo everywhere isn't that nice, but it's only mildly
> worse than C# to me - I find the extra block levels really atrocious.
Personally I find pro
Christian Heimes <[EMAIL PROTECTED]> wrote:
> Python 2.6 and 3.0 have a more Pythonic way for the problem:
>
> class A(object):
> @property
> def foo(self):
> return self._foo
>
> @foo.setter
> def foo(self, value)
> self._foo = value
>
> @foo.deletter
>
On Dec 13, 2007 12:04 PM, Patrick Mullen <[EMAIL PROTECTED]> wrote:
> > > > > Kay Schluehr wrote:
> > > > > Python 2.6 and 3.0 have a more Pythonic way for the problem:
> > > > > class A(object):
> > > > > @property
> > > > > def foo(self):
> > > > > return self._foo
> > > > > @
> > > > Kay Schluehr wrote:
> > > > Python 2.6 and 3.0 have a more Pythonic way for the problem:
> > > > class A(object):
> > > > @property
> > > > def foo(self):
> > > > return self._foo
> > > > @foo.setter
> > > > def foo(self, value)
> > > > self._foo = value
> >
sturlamolden a écrit :
> On 12 Des, 17:00, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
>> Python has not become what it is, and achieved the success it has,
>> because a bunch of people really wanted to use Lisp but didn't think
>> other people could handle it.
>>
>> The goal of these sorts of dis
On 12 Des, 18:58, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> I don't see an indication that anybody but the creator of Psyco does
> understand the code base. *g*
Then you haven't been reading the right IRC channel recently. ;-)
> Guido has stated his opinion about optimizations more than onc
On Dec 12, 8:23 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2007 12:53 PM, George Sakkis <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 12, 1:12 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> > > Kay Schluehr wrote:
> > > > class A(object):
> > > > foo = property:
> > > >
On Dec 12, 2:23 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2007 12:53 PM, George Sakkis <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 12, 1:12 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> > > Kay Schluehr wrote:
> > > > class A(object):
> > > > foo = property:
> > > >
On Dec 12, 2007 12:53 PM, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Dec 12, 1:12 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> > Kay Schluehr wrote:
> > > class A(object):
> > > foo = property:
> > > def fget(self):
> > > return self._foo
> > > def fset(sel
On Dec 12, 3:36 pm, sturlamolden <[EMAIL PROTECTED]> wrote:
> On 12 Des, 12:56, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> > Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
> > would have an impact comparable to the decorator syntax sugar, if not
> > more.
>
> I think it is
On Dec 12, 1:12 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Kay Schluehr wrote:
> > class A(object):
> > foo = property:
> > def fget(self):
> > return self._foo
> > def fset(self, value):
> > self._foo = value
>
> > which was translated as follows
On Dec 12, 4:09 am, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> I vaguely remember a discussion a few years ago, where someone made
> the quite reasonable suggestion of introducing some kind of
> thunk_statement:
>
> class A(object):
> foo = property:
> def fget(self):
> retu
Kay Schluehr wrote:
> class A(object):
> foo = property:
> def fget(self):
> return self._foo
> def fset(self, value):
> self._foo = value
>
> which was translated as follows:
>
> class A(object):
> def thunk():
> def fget(self):
>
Kay Schluehr wrote:
> Given that the Python core team has been mostly silent about JIT
> compilation and Armin Rigos work in particular which started 5 years
> ago ( Psyco will not be promoted towards Python 3.0 and there is no
> indication that anyone but Armin would maintain Psyco ) I wonder abo
On 12 Des, 17:00, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> Python has not become what it is, and achieved the success it has,
> because a bunch of people really wanted to use Lisp but didn't think
> other people could handle it.
>
> The goal of these sorts of discussions should be to make Pytho
On 12 Des, 17:44, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
> Programmable syntax is a very powerful concept.
You don't have to use the programmable syntax just because it's there.
But I do realize it would be a misfeature if it is abused.
Two points:
* Programmable syntax would make it eas
On Wed, Dec 12, 2007 at 06:36:49AM -0800, sturlamolden wrote regarding Re: Is a
"real" C-Python possible?:
>
> On 12 Des, 12:56, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> > Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
&
On Dec 12, 2007 8:36 AM, sturlamolden <[EMAIL PROTECTED]> wrote:
> On 12 Des, 12:56, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> > Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
> > would have an impact comparable to the decorator syntax sugar, if not
> > more.
>
> I think
On 12 Des, 12:56, George Sakkis <[EMAIL PROTECTED]> wrote:
> Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
> would have an impact comparable to the decorator syntax sugar, if not
> more.
I think it is one step closer to Lisp. I believe that it would be
worth considering a
On Dec 12, 4:09 am, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Curiously, whenever property syntax is discussed the
> discussion loses track and is dragged away by needless side
> discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
> which he finally muses about replacing the class
sturlamolden wrote:
> def fibo(n):
> while 1:
> try:
> return fibo.seq[n]
> except AttributeError:
> fibo.seq = [0, 1, 1]
> except IndexError:
> fibo.seq.append( fibo.seq[-2] + fibo.seq[-1] )
I really like this formulation. However, i
sturlamolden wrote:
> On 11 Des, 20:25, John Nagle <[EMAIL PROTECTED]> wrote:
>
>> Shed Skin effort. Its author writes "Am I the only one seeing the potential
>> of an implicitly statically typed Python-like-language that runs at
>> practically the same speed as C++?"
>
> Don't forget about Pyrex
On Dec 12, 9:04 am, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2:18 am, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
> > On Dec 12, 7:34 am, sturlamolden <[EMAIL PROTECTED]> wrote:
> > > I am not sure why a new type annotation syntax was needed Python 3:
>
> > Because people care about a fe
On Dec 12, 2:18 am, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On Dec 12, 7:34 am, sturlamolden <[EMAIL PROTECTED]> wrote:
> > I am not sure why a new type annotation syntax was needed Python 3:
>
> Because people care about a feature when there is @syntax.
Good point; the inverse is not true thou
On Dec 12, 7:34 am, sturlamolden <[EMAIL PROTECTED]> wrote:
> On 12 Des, 04:45, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> > Python 3 will have optional 'type' annotations, where 'type' includes
> > abstract base classes defined by the interface (methods). So parameters
> > could be annotated as
On 12 Des, 04:45, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> Python 3 will have optional 'type' annotations, where 'type' includes
> abstract base classes defined by the interface (methods). So parameters
> could be annotated as a Number or Sequence, for instance, which is more
> useful often tha
On Dec 12, 4:45 am, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "sturlamolden" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
> | We could include optional static typing in
> | Python, and have an optional static optimizing native compiler for
> | selected portions of code.
>
> Pyth
"sturlamolden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| We could include optional static typing in
| Python, and have an optional static optimizing native compiler for
| selected portions of code.
Python 3 will have optional 'type' annotations, where 'type' includes
abstrac
sturlamolden a écrit :
-snip)
> We could include optional static typing in
> Python,
Please wait - going to get my gun...
--
http://mail.python.org/mailman/listinfo/python-list
On 11 Des, 20:25, John Nagle <[EMAIL PROTECTED]> wrote:
> Shed Skin effort. Its author writes "Am I the only one seeing the potential
> of an implicitly statically typed Python-like-language that runs at
> practically the same speed as C++?"
Don't forget about Pyrex and PyPy's RPython.
By the wa
John Nagle a écrit :
> sturlamolden wrote:
>
>> On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
>>
>>> "Premature optimization is the root of all evil in programming."
>>> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>> Hoare)
>
>
>We're ten years into Python, and
John Nagle schrieb:
> sturlamolden wrote:
>> On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
>>
>>> "Premature optimization is the root of all evil in programming."
>>> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>> Hoare)
>
>We're ten years into Python, and it's s
On Tue, 11 Dec 2007 11:25:32 -0800, John Nagle wrote:
> sturlamolden wrote:
>> On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
>>
>>> "Premature optimization is the root of all evil in programming."
>>> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>> Hoare)
>
> We
sturlamolden <[EMAIL PROTECTED]> writes:
> On 10 Des, 23:54, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
>
>> Or a lack of time and money. Lisp is one of the older programming
>> languages around, and at a time had BigBucks(tm) invested on it to try
>> and make it practically usable.
>
> Yes.
On 2007-12-10, sturlamolden wrote:
> We have seen several examples that 'dynamic' and 'interpreted'
> languages can be quite efficient: There is an implementation of Common
> Lisp - CMUCL - that can compete with Fortran in efficiency for
> numerical computing. There are also versions of Lisp than
On Dec 11, 2007 1:25 PM, John Nagle <[EMAIL PROTECTED]> wrote:
> sturlamolden wrote:
> > On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
> >
> >> "Premature optimization is the root of all evil in programming."
> >> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
> >> Hoare)
sturlamolden <[EMAIL PROTECTED]> writes:
> On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
>
>> "Premature optimization is the root of all evil in programming."
>> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>> Hoare)
>
> Oh, I was Hoare? Thanks. Anyway, it doesn't chan
sturlamolden wrote:
> On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
>
>> "Premature optimization is the root of all evil in programming."
>> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>> Hoare)
We're ten years into Python, and it's still a naive interpreter.
It'
On 11 Des, 10:10, Duncan Booth <[EMAIL PROTECTED]> wrote:
> @memoize(3)
> def fib(n):
>if n == 0 or n == 1:
> return n
>else:
> return fib(n-1) + fib(n-2)
The thing I would do is:
def fibo(n):
while 1:
try:
return fibo.seq[n]
except AttributeE
On Dec 11, 3:10 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
> sturlamolden <[EMAIL PROTECTED]> wrote:
> > On 9 Des, 23:34, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> >> >http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-pyth
> >> >...
>
> >> The Ruby developers are allowed to be
sturlamolden <[EMAIL PROTECTED]> wrote:
> On 9 Des, 23:34, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
>> >http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-pyth
>> >...
>>
>> The Ruby developers are allowed to be proud. They were able to
>> optimize some aspects of the implemen
> We obviously need more effort to make Python more efficient for CPU
> bound tasks. Particularly JIT compilation like Java, compilation like
> Lisp or data specialization like Psyco.
Given that the Python core team has been mostly silent about JIT
compilation and Armin Rigos work in particular wh
On 9 Des, 23:34, Christian Heimes <[EMAIL PROTECTED]> wrote:
> >http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-pyth...
>
> The Ruby developers are allowed to be proud. They were able to optimize
> some aspects of the implementation to get one algorithm about 14 times
> faster. Th
On 10 Des, 23:49, [EMAIL PROTECTED] (Aahz) wrote:
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
> Hoare)
Oh, I was Hoare? Thanks. Anyway, it doesn't change the argument that
optimizing in wrong places is
On 10 Des, 23:54, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Or a lack of time and money. Lisp is one of the older programming
> languages around, and at a time had BigBucks(tm) invested on it to try
> and make it practically usable.
Yes. But strangely enough, the two Lisp implementations t
sturlamolden a écrit :
> On 9 Des, 23:34, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
>
>>Nevertheless it is just one algorithm that beats Python in an area that
>>is well known to be slow. Python's numbers are several factors slower
>>than C code because the overhead of the dynamic language th
In article <[EMAIL PROTECTED]>,
sturlamolden <[EMAIL PROTECTED]> wrote:
>
>Donald Knuth, one of the fathers of modern computer science, is famous
>for stating that "premature optimization is the root of all evil in
>computer science."
>From my .sig database:
"Premature optimization is the root
Jack a écrit :
> Aahz a écrit
>>
>>Could you provide some evidence that Python is slower than Java or PHP?
>
>
> I think most Java-Python benchmarks you can find online will indicate
> that Java is a 3-10 times faster. A few here:
> http://mail.python.org/pipermail/python-list/2002-January/12578
On 9 Des, 23:34, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Nevertheless it is just one algorithm that beats Python in an area that
> is well known to be slow. Python's numbers are several factors slower
> than C code because the overhead of the dynamic language throws lots of
> data out of the
On 9 Des, 22:14, "Jack" <[EMAIL PROTECTED]> wrote:
> I understand that the standard Python distribution is considered
> the C-Python. Howerver, the current C-Python is really a combination
> of C and Python implementation. There are about 2000 Python files
> included in the Windows version of Pyth
[EMAIL PROTECTED] a écrit :
(snip)
> I'd like to provide some evidence that Python is *faster* than Java.
Then benchmark the time taken for the interpreter (oops, sorry: "VM") to
start !-)
--
http://mail.python.org/mailman/listinfo/python-list
Jack a écrit :
>>>I'm not sure
>>>how much of the C-Python is implemented in C but I think the more
>>>modules implemented in C, the better performance and lower memory
>>>footprint it will get.
>>
>>Prove it. ;-)
>
>
> I guess this is subjective :)
If yes, benchmarks are not an argument. Else,
On Dec 9, 10:07 pm, "Jack" <[EMAIL PROTECTED]> wrote:
> >> I think most Java-Python benchmarks you can find online will indicate
> >> that Java is a 3-10 times faster. A few here:
> >>http://mail.python.org/pipermail/python-list/2002-January/125789.html
> >>http://blog.snaplogic.org/?p=55
>
> > The
On Dec 9, 1:14 pm, "Jack" <[EMAIL PROTECTED]> wrote:
> I wonder if it's possible to have a Python that's completely (or at
> least for the most part) implemented in C, just like PHP - I think
> this is where PHP gets its performance advantage. Or maybe I'm wrong
> because the core modules that matt
On Dec 9, 3:23 pm, [EMAIL PROTECTED] (Aahz) wrote:
> In article <[EMAIL PROTECTED]>,
>
> Jack <[EMAIL PROTECTED]> wrote:
>
> >I understand that the standard Python distribution is considered
> >the C-Python. Howerver, the current C-Python is really a combination
> >of C and Python implementation. T
On Dec 9, 10:43 pm, "Jack" <[EMAIL PROTECTED]> wrote:
>
> http://blog.snaplogic.org/?p=55
There's some choice nonsense here, albeit on a different topic:
"Coding for wxwidgets, using a QT or GTK bridge, or using TCL/TK is
hardly an optimal solution when writing complex graphical
applications, and
Jack a écrit :
> I understand that the standard Python distribution is considered
> the C-Python. Howerver, the current C-Python is really a combination
> of C and Python implementation. There are about 2000 Python files
> included in the Windows version of Python distribution. I'm not sure
> how m
on 12/10/2007 05:14 AM Jack wrote :
> I wonder if it's possible to have a Python that's completely (or at
> least for the most part) implemented in C, just like PHP - I think
> this is where PHP gets its performance advantage. Or maybe I'm wrong
> because the core modules that matter are already
On Dec 9, 10:04 pm, Paul McGuire <[EMAIL PROTECTED]> wrote:
> On Dec 9, 6:07 pm, "Jack" <[EMAIL PROTECTED]> wrote:
>
> > Plus, Psyco is not the
> > main stream and has stopped development.
>
>
>
> What makes you think it has stopped development? I just swung by the
> SF project page, and its most
"Jack" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The second articple does have a column for Psyco. It helps in some areas
| but still not good enough to stand up against Java. Plus, Psyco is not
the
| main stream and has stopped development.
It further development is effecti
On Dec 9, 6:07 pm, "Jack" <[EMAIL PROTECTED]> wrote:
> Plus, Psyco is not the
> main stream and has stopped development.
>
What makes you think it has stopped development? I just swung by the
SF project page, and its most recent news post was just 2 months ago.
Psyco may not be in the standard
>> I think most Java-Python benchmarks you can find online will indicate
>> that Java is a 3-10 times faster. A few here:
>> http://mail.python.org/pipermail/python-list/2002-January/125789.html
>> http://blog.snaplogic.org/?p=55
>
> There are lies, damn lies and benchmarks. :)
>
> Pure Python cod
"Jack" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|I understand that the standard Python distribution is considered
| the C-Python. Howerver, the current C-Python is really a combination
| of C and Python implementation. There are about 2000 Python files
| included in the Windows
Jack wrote:
> I guess this is subjective :) - that's what I felt in my experience
> with web applications developed in Python and PHP. I wasn't able to
> find a direct comparison online.
Please compare the number of serious bugs and vulnerabilities in PHP and
Python.
> I understand. Python module
That first article is five years old... I wouldn't give too much
weight to it.
--
http://mail.python.org/mailman/listinfo/python-list
Jack wrote:
> I wonder if it's possible to have a Python that's completely (or at
> least for the most part) implemented in C, just like PHP - I think
> this is where PHP gets its performance advantage. Or maybe I'm wrong
PHP is slower than Python.
--
http://mail.python.org/mailman/listinfo/pyt
>> I'm not sure
>>how much of the C-Python is implemented in C but I think the more
>>modules implemented in C, the better performance and lower memory
>>footprint it will get.
>
> Prove it. ;-)
I guess this is subjective :) - that's what I felt in my experience
with web applications developed i
Jack schrieb:
> I understand that the standard Python distribution is considered
> the C-Python. Howerver, the current C-Python is really a combination
> of C and Python implementation. There are about 2000 Python files
> included in the Windows version of Python distribution. I'm not sure
> how mu
In article <[EMAIL PROTECTED]>,
Jack <[EMAIL PROTECTED]> wrote:
>
>I understand that the standard Python distribution is considered
>the C-Python. Howerver, the current C-Python is really a combination
>of C and Python implementation. There are about 2000 Python files
>included in the Windows versi
I understand that the standard Python distribution is considered
the C-Python. Howerver, the current C-Python is really a combination
of C and Python implementation. There are about 2000 Python files
included in the Windows version of Python distribution. I'm not sure
how much of the C-Python is im
76 matches
Mail list logo
