Op 2005-03-21, Jeff Shannon schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef [EMAIL PROTECTED]:
I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
I said that the way that binding a
Antoon Pardon wrote:
Op 2005-03-21, Jeff Shannon schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef [EMAIL PROTECTED]:
I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
I said that the way
Op 2005-03-22, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-03-21, Jeff Shannon schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef [EMAIL PROTECTED]:
I find it odd that you start by saying you still find them very
consistent and here
On 16 Mar 2005 06:37:45 -0500, Carl Shapiro [EMAIL PROTECTED]
wrote:
I have a virtually completed port of CMUCL to Win32. And, if I was
not busy organizing a Lisp conference, it would be publicly available
by now.
If it's the conference I think, then the deadline for papers was about
a week
Antoon Pardon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
And does this code object know which non-local names are on an
intermediate level and which are global?
Yes (from 2.2):
import dis
x = 1
def f():
... y = 2
... def g():
...z = 3
...print x,y,z
... return
Op 2005-03-18, Jeff Shannon schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-03-16, Jeff Shannon schreef [EMAIL PROTECTED]:
Bruno Desthuilliers wrote:
- if x is a class attribute of class A and a is an instance of A,
a.x=anyvalue create a new instance attribute x instead of modifying
Op 2005-03-18, Bengt Richter schreef [EMAIL PROTECTED]:
[ ... ]
BTW, I would like a re-assign or find-and-rebind operation spelled := which
would
make x := 123 mean look for x as if to read its value in a right hand side
expression,
(except do not look into __builtins__) and wherever
Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef [EMAIL PROTECTED]:
I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
I said that the way that binding a name on a class instance always
creates an instance attribute
Op 2005-03-16, Jeff Shannon schreef [EMAIL PROTECTED]:
Bruno Desthuilliers wrote:
A few examples:
[...]
- to get the length of a sequence, you use len(seq) instead of seq.len()
- to call objects attributes by name, you use [get|set]attr(obj, name
[,value]) instead of obj.[get|set]attr(name
Antoon Pardon wrote:
Op 2005-03-16, Jeff Shannon schreef [EMAIL PROTECTED]:
Bruno Desthuilliers wrote:
- if x is a class attribute of class A and a is an instance of A,
a.x=anyvalue create a new instance attribute x instead of modifying A.x
This is very consistent with the way that binding a name
On Fri, 18 Mar 2005 09:16:42 -0800, Jeff Shannon [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
Op 2005-03-16, Jeff Shannon schreef [EMAIL PROTECTED]:
Bruno Desthuilliers wrote:
- if x is a class attribute of class A and a is an instance of A,
a.x=anyvalue create a new instance attribute x
Mike == Mike Meyer [EMAIL PROTECTED] writes:
Mike The real problem is that newbies won't know which features
Mike are meta features best left to experts, and which features
Mike are ok for everyday programmers to use.
I suppose that a typical lazy newbie will just skip metaclasses
Mike Meyer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
The real problem is that newbies won't know which features are meta
features best left to experts, and which features are ok for everyday
programmers to use.
I think the original contributor to this thread was fairly
Kay Schluehr [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Some people refused properties in Python for exactly this reason.
Defining somewhat like:
def _get_X(self):
return self._X
def _set_X(self,X):
self._X =3D X
X =3D property(_get_X, _set_X )
in a
Kay Schluehr schrieb:
Some people refused properties in Python for exactly this reason.
Defining somewhat like:
def _get_X(self):
return self._X
def _set_X(self,X):
self._X = X
X = property(_get_X, _set_X )
in a Java-style fashion is indeed awfull and clumsy and that people
dismiss such
Op 2005-03-16, Jeff Shannon schreef [EMAIL PROTECTED]:
news.sydney.pipenetworks.com wrote:
More in relation to the original topic, why can't people just ignore
features they don't understand and may never use directly.
Because they may get stuck maintaining code that uses those features.
Jeff Shannon [EMAIL PROTECTED] wrote:
Because they may get stuck maintaining code that uses those features.
Now, I'm generally in agreement with you -- in general, Python
features that aren't straightforward (e.g. metaclasses) are clearly
advanced features and aren't likely to be in
Tim == Tim Daneliuk [EMAIL PROTECTED] writes:
Tim Except that in this case, removal will also complicate code
Tim in some cases. Consider this fragment of Tkinter logic:
Tim UI.CmdBtn.menu.add_command(label=MyLabel,
Tim command=lambda cmd=cmdkey: CommandMenuSelection(cmd))
Torsten == Torsten Bronger [EMAIL PROTECTED] writes:
There would be keywords for static and class methods, no
distinction between Unicode and non-Unicode
You couldn't do that 15 years ago because there were no Unicode
that time.
Torsten I've never said that Guido was
Paul Boddie wrote:
The principal advantage of the property function was to permit the
definition of active attributes without having a huge
if...elif...else statement in the __getattr__ method. So the
motivation was seemingly to externalize the usually simple logic in
__getattr__ so that one
Fernando schrieb:
The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and
Steven Bethard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Certainly descriptors in the wrong hands could lead to confusing,
unreadable code. But Python is a we're all adults here language, and
so we have to trust other coders to be responsible.
The problem is as much
Hallchen!
news.sydney.pipenetworks.com [EMAIL PROTECTED] writes:
Torsten Bronger wrote:
[...]
I have exactly the same impression, but for me it's the reason
why I feel uncomfortable with them. For example, I fear that a
skilled package writer could create a module with surprising
Torsten Bronger wrote:
Hallchen!
news.sydney.pipenetworks.com [EMAIL PROTECTED] writes:
Torsten Bronger wrote:
[...]
I have exactly the same impression, but for me it's the reason
why I feel uncomfortable with them. For example, I fear that a
skilled package writer could create a module with
Brandon J. Van Every [EMAIL PROTECTED] writes:
Last I looked, 2 years ago?, there were no compiled, open source lisps that
ran on Windows. Has this changed?
I have a virtually completed port of CMUCL to Win32. And, if I was
not busy organizing a Lisp conference, it would be publicly
news.sydney.pipenetworks.com said unto the world upon 2005-03-16 05:57:
SNIP
trust the guy to do a good job. If you don't, then you can write it
yourself which means you can do exactly how you want it which again
makes the whole argument mute.
Anyone else having images of mimes engaged in street
Torsten Bronger wrote:
Hallöchen!
Moin!
[First, I wanted to say descriptors instead of decorators (I
superseded my post).]
The goal is to trigger function calls when attributes are accessed.
This is called properties in C# (and maybe in Ruby, too). Python
now also has this concept. What
On Wed, 16 Mar 2005 16:35:57 -0600, Mike Meyer wrote:
The real problem is that newbies won't know which features are meta
features best left to experts, and which features are ok for everyday
programmers to use.
We recently saw a thread (couldn't find it in google groups) where
some was
Jeff Shannon wrote:
news.sydney.pipenetworks.com wrote:
More in relation to the original topic, why can't people just ignore
features they don't understand and may never use directly.
Because they may get stuck maintaining code that uses those features.
Now, I'm generally in agreement with
Hallchen!
Steven Bethard [EMAIL PROTECTED] writes:
Torsten Bronger wrote:
the underlying constructs are utterly ugly, as are some of
Python's features (e.g. __getattr__ and such, and decorators, in
order to get nice class properties).
What do you find ugly about __getattr__?
[First, I
Torsten Bronger wrote:
Steven Bethard [EMAIL PROTECTED] writes:
Interesting. I've never thought that. What parts strike you as
patchwork?
Well, with a little bit of experience in the field of programming
languages, you can see which elements had been added later (ie years
after
In-Reply-To: [EMAIL PROTECTED]
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Nick Craig-Wood wrote:
Torsten Bronger [EMAIL PROTECTED] wrote:
The current snapshot is a
Torsten Bronger wrote:
Interesting. I've never thought that. What parts strike you as
patchwork?
Well, with a little bit of experience in the field of programming
languages, you can see which elements had been added later (ie years
after Python's creation). Properties surely would have
Hallchen!
Serge Orlov [EMAIL PROTECTED] writes:
Torsten Bronger wrote:
Interesting. I've never thought that. What parts strike you as
patchwork?
Well, with a little bit of experience in the field of programming
languages, you can see which elements had been added later (ie
years after
Tim Daneliuk wrote:
In-Reply-To: [EMAIL PROTECTED]
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Nick Craig-Wood wrote:
Torsten Bronger [EMAIL PROTECTED] wrote:
The current snapshot
Carl Banks schrieb:
In Python, classes aren't some magical land where the usual rules don't
hold (as they are in many other languages). That's why self. is used
on class variables, for instance. A class is nothing more than a scope
that uses a smittering of magic to turn it into a type.
scope -
Torsten Bronger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
At first, I was very pleased by Python's syntax (and still I am).
Then, after two weeks, I learned about descriptors and metaclasses
and such and understood nothing (for the first time in syntax I felt
totally
Hallchen!
[EMAIL PROTECTED] (Paul Boddie) writes:
Torsten Bronger [EMAIL PROTECTED] wrote:
At first, I was very pleased by Python's syntax (and still I am).
Then, after two weeks, I learned about descriptors and
metaclasses and such and understood nothing (for the first time
in syntax I
Torsten == Torsten Bronger [EMAIL PROTECTED] writes:
There would be keywords for static and class methods, no
distinction between Unicode and non-Unicode
You couldn't do that 15 years ago because there were no Unicode
that time.
Torsten I've never said that Guido was
Fernando wrote:
On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel
[EMAIL PROTECTED]
wrote:
Looks like the BDFL is planning to take lambda, reduce, filter, and
map out of Python in the next big rev of Python (so called Python
3000):
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Torsten Bronger wrote:
[EMAIL PROTECTED] (Paul Boddie) writes:
Well, I've been using Python for almost ten years, and I've
managed to deliberately ignore descriptors and metaclasses quite
successfully. I get the impression that descriptors in particular
are a detail of the low-level implementation
Fernando [EMAIL PROTECTED] wrote:
Peter Seibel [EMAIL PROTECTED] wrote:
Looks like the BDFL is planning to take lambda, reduce, filter, and
map out of Python in the next big rev of Python (so called Python
3000):
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Basically,
James Graves wrote:
So with Python 3000, you're going to end up with a language just as
big as CL, but without the most fundamental building blocks. Ah
well, to each his own.
Preventing people from building things from scratch is probably an
industrial advantage. Look how fragmented the
Fernando wrote:
The real problem with Python is ... Python is
going the C++ way: piling feature upon feature, adding bells
and whistles while ignoring or damaging its core design.
I totally agree.
Look at a recent thread Compile time evaluation (aka eliminating
default argument hacks)
Brandon J. Van Every [EMAIL PROTECTED] wrote:
James Graves wrote:
So with Python 3000, you're going to end up with a language just as
big as CL, but without the most fundamental building blocks. Ah
well, to each his own.
Preventing people from building things from scratch is probably an
James Graves wrote:
If you want to do application development, Common Lisp is where it's
at, no doubt about it. There are more and better libraries for CL
these days, and they are easier to install and manage with tools like
ASDF. Multiple open-source implementations, covering the most
On Tue, 15 Mar 2005 12:25:02 -0800, Brandon J. Van Every wrote:
Last I looked, 2 years ago?, there were no compiled, open source lisps that
ran on Windows. Has this changed?
I don't think so. I recently (about 2 months ago) started to want to learn
Lisp (didn't go far for now) and wanted to
Brandon J. Van Every [EMAIL PROTECTED] wrote:
James Graves wrote:
If you want to do application development, Common Lisp is where it's
at, no doubt about it. There are more and better libraries for CL
these days, and they are easier to install and manage with tools like
ASDF. Multiple
Brandon J. Van Every [EMAIL PROTECTED] writes:
Last I looked, 2 years ago?, there were no compiled, open source
lisps that ran on Windows. Has this changed?
GCL (formerly known as KCL and ACL) has been around since 1984,
and has been available on Windows since 2000.
ECL (another KCL
Valentino Volonghi aka Dialtone a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
It is actually. Ruby's syntax is mostly consistent and coherent, and
there is much less special cases than in Python.
I'd be glad to know which special cases are you referring to.
A few examples:
- A
Martin Franklin a écrit :
Tim Daneliuk wrote:
In-Reply-To: [EMAIL PROTECTED]
(snip)
Of course we users will complain about removals, but we'll knuckle
down and take our medicine eventually ;-)
Except that in this case, removal will also complicate code in some
cases. Consider this fragment of
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
A few examples:
- A statement is different from an expression (2 special cases instead
of one general case).
- You can't use statements in a lambda
Good reason to remove lambda, let's do this asap.
- to get the length of a sequence, you use
James Graves wrote:
But coverage in this area (compiled CL) is a bit thin, I'll admit.
But who really cares? After all, there are the mature commercial
proprietary lisp compilers for those people who insist on using
closedware OSes, and they've already proven they're willing to use
Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Looks like Java.
When was the last time you used Java? It has no support for using
classes as callable objects. __call__ would have
Torsten Bronger [EMAIL PROTECTED] wrote:
I have exactly the same impression, but for me it's the reason why I
feel uncomfortable with them. For example, I fear that a skilled
package writer could create a module with surprising behaviour by
using the magic of these constructs.
If the
Martin Franklin wrote:
Tim Daneliuk wrote:
Except that in this case, removal will also complicate code in some
cases. Consider this fragment of Tkinter logic:
UI.CmdBtn.menu.add_command(label=MyLabel,
command=lambda cmd=cmdkey:
CommandMenuSelection(cmd))
In this case
Steven Bethard wrote:
Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Looks like Java.
When was the last time you used Java? It has no support for using
classes as callable objects.
Bruno Desthuilliers wrote:
A few examples:
[...]
- to get the length of a sequence, you use len(seq) instead of seq.len()
- to call objects attributes by name, you use [get|set]attr(obj, name
[,value]) instead of obj.[get|set]attr(name [,value])
These are both very consistent applications of a
Kent Johnson wrote:
Steven Bethard wrote:
Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Looks like Java.
When was the last time you used Java? It has no support for using
classes
Bruno Desthuilliers wrote:
news.sydney.pipenetworks.com a crit :
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with
Bruno Desthuilliers wrote:
Valentino Volonghi aka Dialtone a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
It is actually. Ruby's syntax is mostly consistent and coherent, and
there is much less special cases than in Python.
I'd be glad to know which special cases are you referring to.
Torsten Bronger wrote:
Hallchen!
[EMAIL PROTECTED] (Paul Boddie) writes:
Torsten Bronger [EMAIL PROTECTED] wrote:
At first, I was very pleased by Python's syntax (and still I am).
Then, after two weeks, I learned about descriptors and
metaclasses and such and understood nothing (for the first
Thomas Bellman wrote:
Torsten Bronger [EMAIL PROTECTED] wrote:
Just to amplify Thomas' statements...
...
And inflexibility will always make some situations horribly
daunting to get out of.
Powerful constructs like these can, in some cases, enable a
skilled package writer to design an API that
On Tue, 15 Mar 2005 03:21:48 -0800, Paul Boddie wrote:
Well, I've been using Python for almost ten years, and I've managed to
deliberately ignore descriptors and metaclasses quite successfully. I get
the impression that descriptors in particular are a detail of the
low-level implementation
On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel [EMAIL PROTECTED]
wrote:
Looks like the BDFL is planning to take lambda, reduce, filter, and
map out of Python in the next big rev of Python (so called Python
3000):
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Basically, it says that
Hallchen!
Fernando [EMAIL PROTECTED] writes:
[...]
[...] Python is going the C++ way: piling feature upon feature,
adding bells and whistles while ignoring or damaging its core
design.
I'm new to Python, but I while I skimmed through the What's new?
of recent versions, I saw the same
On Tue, 15 Mar 2005 00:01:09 +0100, Torsten Bronger
[EMAIL PROTECTED] wrote:
The new 'perlified' syntax for decorators,
Python lost its innocence here: The first really special character,
disturbing the former syntax style. Not important, but irritating.
the new static type bonds
What is
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many
news.sydney.pipenetworks.com a crit :
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with Python, but you can definitely
Torsten Bronger wrote:
Hallchen!
Tach!
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself. It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler.
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
It is actually. Ruby's syntax is mostly consistent and coherent, and
there is much less special cases than in Python.
I'd be glad to know which special cases are you referring to.
Please note that you wrote much less which means there are probably
71 matches
Mail list logo
