about sort and dictionary

[Mike Meyer]

But how this philosophy influences design is not straight forward.

The ternary operator was thought of to go against the philosopy,

By who?

and now seems to be at least compatible with the philosophy.

So when someone asks why it is not in python, saying "It is not
the python way" still doesn't answer the question, because the
person would probably still like to know what in his proposal
is against the python philosophy and why.

Sometimes, such things are easy to explain, and they'll generally get
that explanation. Sometimes they aren't, so you're reduced to
pointing out similar - but more obvious - things that aren't in the
language, and "import this", and suggesting that they try it for a
while and see how it works

I see nothing wrong with that. But I would apreciate it, should
you be more open about something being your personal vision.
To me something like: "That is not the python way" comes accross
as: "You just don't understand about python, if you ask/propose
something like that"

That's essentially true. In some cases, the reasons can be explained
without understanding about python. In some cases, they can't.

It gives me the feeling the person is saying something like: "Python
is like this, I like it this way, so nobody better suggests this
changes".

You're carrying things a step to far, going from explaining an overly
brief statement to imagining a motive for said statement.

<mike

 

[Mike Meyer]

Well this is, is one thing I have a problem with.

The python people seem to be more concerned with fighting things
that could be used counter the python philosophy, than search for
things that enable working in the python philosophy.

And what's wrong with that?

Well this seems to be the main conflict between those who would
like Python to go a bit further and those that oppose it.

Should the priority be to enable python's philosophy or should
it be the priority to limit python to only allow it's philosophy.

Those two statements say the same thing. Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it. By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.

<mike

 

[Paul Rubin]

Those two statements say the same thing. Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it. By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.

Sometimes there are zero obvious ways to do it, or an obvious way that
doesn't work, so if you want to do it at all, you have to find a
contorted way. At that point it's normal to ask why there isn't an
obvious way that works. All too often, the answer is "that would be
un-Pythonic".

 

[Mike Meyer]

Sometimes there are zero obvious ways to do it, or an obvious way that
doesn't work, so if you want to do it at all, you have to find a
contorted way. At that point it's normal to ask why there isn't an
obvious way that works. All too often, the answer is "that would be
un-Pythonic".

Examples?

<mike

 

[Serge Orlov]

No it wasn't. From what I have picked up, the ternary operator
was finaly introduced after one of the developers tripped over
the commonly used idiom to simulate a ternary operator, which
can fail in certain cases.

Anyway, when I was arguing for a ternary operator in python,
those who opposed me, certainly gave me the impression that
they thought I wanted to mangle the language, the mere idea
of a ternary operator was against the spirit of python.

When I argued for a more general loop construct similar
objections were made and the proposal was fiercely fought.
Someone even started a PEP, with the intention to bury
the idea. (That can be from before I argued for it)

Now I have read about both that they will be introduced in
Python 2.5 without a whisper of protest.

Protesting BDFL is absolutely useless by definition even if you
disagree. Tim Peters wanted generators for 10 years
<http://mail.python.org/pipermail/python-list/2001-June/050146.html>
and he has much more power of convincing Guido than you. Why do you
think your proposal should be immediately accepted?

By the way, I don't see the features you mentioned neither in
<http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802&view=auto>
nor among PEPs. Perhaps they are not final?

 

[Antoon Pardon]

By who?

I would guess in the first place by Guido. Just look at the history
of how it finaly came to be present and IMO the only conclusion
is that Guido doesn't like a ternary operator.

Then there were those who always argued against the ternary
operator. I'm sure you can dig up some names if you go
through google groups.

Sometimes, such things are easy to explain, and they'll generally get
that explanation. Sometimes they aren't,

Well maybe that are not that easy to explain because they aren't.

so you're reduced to
pointing out similar - but more obvious - things that aren't in the
language, and "import this", and suggesting that they try it for a
while and see how it works


That's essentially true. In some cases, the reasons can be explained
without understanding about python. In some cases, they can't.

Which IMO makes python like a cult. The characteristic of certain
things only explainable to those who have seen the light, makes
for a view that never needs to fear being contradicted. Well
I'm sorry that I can't explain it to you, but you just don't
understand Python.

 

[Antoon Pardon]

And what's wrong with that?

It seems a bit intollerant and contraproductive to me.

If thet would just concentrated on what they want, they could
have progressed further on that road, then where they are now,
because progress sometimes simple stops because other could
use something for what it was not intended.

Those two statements say the same thing.

They are not.

Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it.

It doesn't say that. It says:

There should be one-- and preferably only one --obvious way to do it.

Here you see the difference on emphasis. You are focussing on the
only one, while the original Python Koan seems to focus on the
there should be one.

So supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it
introduces a second obvious way to solve an other problem
too.

I think we should accept such a proposal. It seems you and
a lot of others seem to think such proposals should be
rejected.

By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.

No it doesn't.

Supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it introduces a
second non pythonic way to solve an other problem.

I don't think there is something wrong with accepting this
change. However it seems you do.

 

[Antoon Pardon]

Protesting BDFL is absolutely useless by definition even if you
disagree. Tim Peters wanted generators for 10 years
<http://mail.python.org/pipermail/python-list/2001-June/050146.html>
and he has much more power of convincing Guido than you. Why do you
think your proposal should be immediately accepted?

I don't think that. I was just illustrating that using:
"That is unpythonic" isn't really an argument, because
things that were thought unpythonic before are now
accepted as the pythonic way.

By the way, I don't see the features you mentioned neither in
<http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802&view=auto>
nor among PEPs. Perhaps they are not final?

There were people who annouced these features in this newsgroup
for version 2.5 with a rather clear titles and those from the
dev-list that frequent this newsgroup didn't protest.

Among the PEP's I see that at least PEP 308 is accepted.
So although it may not be implemented for version 2.5
a ternary operator is now an accepted as being pythonic.

 

[Antoon Pardon]

What is the philosophy? I'm not the one to answer that,
but I do use "import this" for reference, and it seems to
answer some of the points in this thread:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

No, it doesn't answer anything. My impression is that the Zen of
Python gets used a lot by the python people like the bible is
used by the christions: You can always find a verse/Koan that
supports your view.

If someone comes with a pratical proposal that breaks a rule,
the proponents will cite: "practical beats purity" and
the opponents will cite: "Special cases aren't special enough
to break the rules:

And each will be convince that his view is the pythonic one.

I'm even of the impression that what is considered pythonic
or not is more related to who proposes it that to what the
proposal is and that after one has so decided the right
rules are selected to defend that decision.

 

[Mike Meyer]

It seems a bit intollerant and contraproductive to me.

I suspect it seems that way because you belief two falsehoods:

Falsehood #1) There's little or no value in protecting something good.
Anyone who's seen a good thing vanish will tell you this isn't
so.

Falsehood #2) Adding things makes a language better.

This simply isn't so. Anyone who's been around computers for any
length of time has heard of featuritis. It afflicts programming
languages as well. A language with 2n features is not inherently
better than a language with n features - it's just got more
features. The 2n language may actually be less powerful.

You see, you can make languages more powerful by *removing* things
from it. Removing static typing leaves you with dynamic typing or duck
typing, both of which are more powerful than static typing. Removing
the need to explicitly free things - even though explicit is better
than implicit - means programmers don't have to worry about such, and
pretty much eliminates several classes of bugs. Removing restriction
on what you can do to an object - making them "first class" - results
in some very powerful facilities that simply don't exist in languages
where that hasn't happened. Since I've been writing Python, it's
gotten more powerful because of such removals.

If thet would just concentrated on what they want, they could
have progressed further on that road, then where they are now,
because progress sometimes simple stops because other could
use something for what it was not intended.

They know what they want. They want python to remain unbroken. Having
seen languages that have been broken to appeal to a new user
population, to appease a software vendor, and - in an extreme case -
because a drunk developer thought it was amusing, I'm *glad* that new
features are only added to Python after they've been beaten on and
thought about and in general had the implications of adding them
explored in depth by the community.

They are not.

Yes, they are.

It doesn't say that. It says:
There should be one-- and preferably only one --obvious way to do it.
Here you see the difference on emphasis. You are focussing on the
only one, while the original Python Koan seems to focus on the
there should be one.

Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added. We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.

So supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it
introduces a second obvious way to solve an other problem
too.

In other words, they propose a change and come up with a use case,
which is SOP.

I think we should accept such a proposal. It seems you and
a lot of others seem to think such proposals should be
rejected.

I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly? Is it prone to abuse? Etc. These could cause a specific proposal
to be rejected, even if the proposed facility acceptable. Then you
have to consider how it affects the rest of the language. Adding
another way to do something isn't reason to reject it out of hand, but
it's a minus. Consider whether the same end can be achieved in another
way - preferably without changing the language (Python is *very*
powerful, a you can do quite a bit with it that isn't obvious), but
see if there's some way to do this without negative side
effects. Finally, you have to consider the implementation: can it be
implemented efficiently and in such a way that it won't be confusing?
Features have been rejected at this stage - meaning if the answer
changes, they'll show up.

In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that. This process has worked well
so far, and there's no obvious reason to think that things would
improve if it changed. Python isn't the only language that has that
kind of philosophy underlying it, and I find languages built with this
philosophy to in general be languages I enjoy writing in, even if they
have nothing else in common.

<mike

 

[Antoon Pardon]

I suspect it seems that way because you belief two falsehoods:

Falsehood #1) There's little or no value in protecting something good.
Anyone who's seen a good thing vanish will tell you this isn't
so.

I don't beleif this. What I do believe is, that it is better
to produce more good with those who think likewise than to
prevent those who think differently, from doing what you
think is bad.

Falsehood #2) Adding things makes a language better.

I don't believe this either.

This simply isn't so. Anyone who's been around computers for any
length of time has heard of featuritis. It afflicts programming
languages as well. A language with 2n features is not inherently
better than a language with n features - it's just got more
features. The 2n language may actually be less powerful.

You see, you can make languages more powerful by *removing* things
from it.

You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.

Removing static typing leaves you with dynamic typing or duck
typing, both of which are more powerful than static typing.

Static typing allows for some things that dynamic typing can't do.
At least not as python uses it.

Removing
the need to explicitly free things - even though explicit is better
than implicit - means programmers don't have to worry about such, and
pretty much eliminates several classes of bugs. Removing restriction
on what you can do to an object - making them "first class" - results
in some very powerful facilities that simply don't exist in languages
where that hasn't happened. Since I've been writing Python, it's
gotten more powerful because of such removals.

Well if you call eliminating restrictions, removing something from
the language I guess you can say that removing things can make
a language more powerfull. But eliminating restrictions IMO is
adding things to the language, those things that were formerly
unallowed because of the restrictions, not removing things from
the language.

They know what they want. They want python to remain unbroken. Having
seen languages that have been broken to appeal to a new user
population, to appease a software vendor, and - in an extreme case -
because a drunk developer thought it was amusing, I'm *glad* that new
features are only added to Python after they've been beaten on and
thought about and in general had the implications of adding them
explored in depth by the community.


Yes, they are.


Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added.

Then C-extentions shouldn't be allowed.

We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.

Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?

In other words, they propose a change and come up with a use case,
which is SOP.


I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly?

That is a highly subjective question, answering it says more about
the person then about the proposal.

Is it prone to abuse?

I don't see why this is always brought up, given the number of
features that can be abused in python.

Etc. These could cause a specific proposal
to be rejected, even if the proposed facility acceptable. Then you
have to consider how it affects the rest of the language. Adding
another way to do something isn't reason to reject it out of hand, but
it's a minus. Consider whether the same end can be achieved in another
way - preferably without changing the language (Python is *very*
powerful, a you can do quite a bit with it that isn't obvious),

But there should be one obvious way to do things. That there are
lots of unobvious way to do the same thing thus shouldn't count
against a proposal that introduces an obvious way to do it.

but
see if there's some way to do this without negative side
effects. Finally, you have to consider the implementation: can it be
implemented efficiently and in such a way that it won't be confusing?
Features have been rejected at this stage - meaning if the answer
changes, they'll show up.

This is not the kind of rejection I'm talking about. This is a
problem of implementation, not a rejection of an idea.

In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that.

I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.

 

[Mike Meyer]

You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.

The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said, and that's as false as the belief
that adding things always makes a language more powerful.

Then C-extentions shouldn't be allowed.

C-extensions aren't part of Python.

Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?

Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.

That is a highly subjective question, answering it says more about
the person then about the proposal.

True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie.

I don't see why this is always brought up, given the number of
features that can be abused in python.

Just because Python isn't perfect is no reason to make it worse.

But there should be one obvious way to do things. That there are
lots of unobvious way to do the same thing thus shouldn't count
against a proposal that introduces an obvious way to do it.

"Obvious" is also a subjective statement, so adding *any* other way to
do things is a minus.

I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.

The only way this would be good is if "more features" were inherently
better. That's simply not true. So the change in behavior you're
looking for isn't clearly good.

Further, if someone doesn't have a need, trying to make someone elses
need fit is largely a waste of their time, though some people -
language wonks - will do it anyway. On the other hand, pointing out
that something is bad is *not* a waste of their time, as it protects
something good. So basically, you're asking that people waste their
time on something of dubious value. Not a request that's likely to be
get very far.

<mike

 

[Antoon Pardon]

The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said,

I would say it is the common interpretation for such a sentence.

and that's as false as the belief
that adding things always makes a language more powerful.


C-extensions aren't part of Python.

As far as I understand, if you implement a class with a C-extension,
then that class is understood to be part of Python. So if you
think there should be no way to produce a segmentation fault in
python you shouldn't allow such classes.

Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.

I do wonder what they mean with a buffer overflow. Would the following
classify:

buf = range(10)
buf[10] = 10

True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie.


Just because Python isn't perfect is no reason to make it worse.

Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.

We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it.

The only way this would be good is if "more features" were inherently
better. That's simply not true. So the change in behavior you're
looking for isn't clearly good.

No, this is good while there are still possible features that could make
python a better language

 

[Dave Hansen]

I would say it is the common interpretation for such a sentence.

I hope no one ever tells you that you'd be healthier if you ate less
and exercised more. (Perhaps it's not true in your case, but it
certainly is in mine.)

Regards,

-=Dave

 

[Ben Finney]

I would say it is the common interpretation for such a sentence.

You'd be wrong. "you can do X by doing foo" does not exclude "you can
do the opposite of X by doing foo".

Stating "you can make a lot of money by investing in the stock market"
does not imply that is the only possible outcome, nor even the most
likely.

Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.

I see Mike arguing that the debate before adding the hammer is a good
thing. It ensures that only the *really* good tools -- the ones that
are so beneficial that they outweigh complicating the toolset --
actually get added; and only when they are in a form that they
overcome many objections.

No, this is good while there are still possible features that could
make python a better language

Then let's subject those possible features -- with their real use
cases and implementations -- to harsh scrutiny, over an extended time,
before deciding they'll be a net benefit.

 

[Mike Meyer]

I would say it is the common interpretation for such a sentence.

You'd be wrong. "Can" denotes a possibility, not a certainty. If I'd
say "You *will* make languages more powerful by removing features",
then you'd be right. But that isn't what I said.

As far as I understand, if you implement a class with a C-extension,
then that class is understood to be part of Python. So if you
think there should be no way to produce a segmentation fault in
python you shouldn't allow such classes.

You understand wrong.

Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.

I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10

Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.

Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.

Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts. Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful .

We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it.

"Major" is your word, not mine. I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality.

No, this is good while there are still possible features that could make
python a better language

In that case, they're doing exactly what you want: they're making sure
that possible features make python a better language. You seem to
think they should stop doing this. I disagree.

<mike

 

[Antoon Pardon]

I hope no one ever tells you that you'd be healthier if you ate less
and exercised more. (Perhaps it's not true in your case, but it
certainly is in mine.)

But that is IMO not a good analogy. A better analogy would be:

You can make persons healthier by making them eat less
and execise more.

 

[Antoon Pardon]

You'd be wrong. "Can" denotes a possibility, not a certainty.

You didn't write:

Removing things can make a language more powerfull.

You wrote:

You can make a language more powerfull by removing things.


In the first case "can" describes a possible outcome of
removing things.

In the second case "can" describes that this is a decision
you are allowed and able to make. Not the possibility
of the outcomes should you make the decision.

What your sentence states is that you can make this decision and
that if you do so, removing things will accomplish this goal

If I'd
say "You *will* make languages more powerful by removing features",
then you'd be right. But that isn't what I said.

No this states that I don't have a choice in removing features or not.

Anyway that is how I read those sentences.

I just want to add that I'm not interrested in whether your
interpretation is the right one or mine. I understand now
what you meant and that is enough for meu. The above should
be considered as an explanation of how understood, not as
a correction of how yuo should have wrote it.

We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.

I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10

Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.

I find this odd. You seem to argue that you don't want bufferoverflows
allowed in python, but then you don't seem to know what is meant by it.
If you don't know what they mean, how can you decide you don't want it.

And I seem to remember people asking about the possibility of overflow
in Python, but I never understood those inquiries in the sense they
would want it, but more in a sense of how python protects against it.

So I have a bit of a problem understanding the relevance here.

Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts.

I disagree. Having more possibilities doesn't imply more usefull.

One of my nefews has this kind of army swiss knife with tons of
possibilities. But I find the few tools I have that total less
possibilities more usefull.

Now adding a extra possibilty to the army swiss knife may make
it worse, less usefull. Putting an extra tool in my toolbox
doesn't make it worse or less usefull, since I can just ignore
the tools I don't use.

Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful .


"Major" is your word, not mine.

That is the impression I get from the emphasis that is always
put on abuse possibilities of a proposed addition in this
group.

I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality.

Well you said it, that's a reason for looking for another way to add
that functionality. My impression is that few people look at it
that way, but instead seem to think it a reason to simply reject the
functionality.

 

[Ben Finney]

You didn't write:
Removing things can make a language more powerfull.

You wrote:
You can make a language more powerfull by removing things.

In the first case "can" describes a possible outcome of removing
things.

In the second case "can" describes that this is a decision you are
allowed and able to make. Not the possibility of the outcomes should
you make the decision.

That's a distinction that exists. I don't see how it's significant
here.

Do you believe that these two statements are contradictory?

"You can make X more powerful by removing things."
"You can make X less powerful by removing things."

How about these two, do you think they're contradictory?

"You can make X more powerful by removing things."
"You can make X more powerful by adding things."

In fact, neither of those pairs are contradictory. All of them can be
truthful about the same X simultaneously.

What your sentence states is that you can make this decision and
that if you do so, removing things will accomplish this goal

No. The statement says nothing about *which* things need to be removed
to meet the goal. It doesn't say that removing *any* thing from the
language will make it more powerful.

I think this is an understandably subtle linguistic point for someone
who doesn't have English as a first language; it's ambiguous enough
that even native speakers could twist it to read more that it actually
says.

Now that you understand what Mike was trying to say, and Mike has
clarified what his statement meant, can we move on to another
argument?

I just want to add that I'm not interrested in whether your
interpretation is the right one or mine. I understand now what you
meant and that is enough for meu. The above should be considered as
an explanation of how understood, not as a correction of how yuo
should have wrote it.

An object lesson in taking programmers at their word

 

[Mike Meyer]

We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.
I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10

Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.

I find this odd. You seem to argue that you don't want bufferoverflows
allowed in python, but then you don't seem to know what is meant by it.
If you don't know what they mean, how can you decide you don't want it.

I know what *I* mean by it, and I don't want to allow that. You asked
what someone else meant by it - I don't know that. The best I can do
is give you my take on it.

So I have a bit of a problem understanding the relevance here.

It's one of the list of things people ask about an extensions.

FWIW, that list is meant to be examples, not a definition. There are
*lots* of other things to check.

I disagree. Having more possibilities doesn't imply more usefull.

You're right. But I didn't say that.

Now adding a extra possibilty to the army swiss knife may make
it worse, less usefull. Putting an extra tool in my toolbox
doesn't make it worse or less usefull, since I can just ignore
the tools I don't use.

Not true. If I put enough extra tools in your toolbox, it will
eventually get to heavy to lift. A single tool, poorly chosen - like a
band saw - could have the same effect.

That is the impression I get from the emphasis that is always
put on abuse possibilities of a proposed addition in this
group.

Well, if they're bad enough to bring up, they probalby are major.

Well you said it, that's a reason for looking for another way to add
that functionality. My impression is that few people look at it
that way, but instead seem to think it a reason to simply reject the
functionality.

So? If they don't need the functionality, why should they look for
another way to add it? In fact, there's a fair chance they aren't
really qualified to evaluate a proposed solution in terms of adding
the proper functionality. Like I said before (or elsewhere), most
people won't bother with that, but a few language wonks will. If you
want another feature, it's up to you to propose an acceptable
mechanism to add it - or convince someone else to do it for you. If
you expect people to do work for you gratis on a regular basis, I'm
afraid you're in for a lot of dissapointment.

<mike