«

On 23 Aug 2003 08:18:49 -0700, (Michele Simionato)
wrote:

>Subclass dict, define __add__ and __sub__ and it will work, but NOT
>with the brace syntax. You must use something like
>
>mydict(a=1,b=2)+mydict(c=3,d=4)

Yeah, I got this to work off the bat.

>Python tries hard not to modify its basic syntax, so you must stay
>with the above. Pythonista would argue that this is a strenght of the
>language: "explicit is better than implicit".

I agree with this philosophy too. I'm not sure where the changes I'm
looking to fail to be explicity.

{} + {} makes sense right? You are adding them together. There will
obviously be a possibility of key clobbering, but then you could run
something like {}.intersect() and get the keys that will be clobbered
(if it existed).

len([])

[].len()

Both seem to make sense explicitly to me. Currently we use it through
builtins, but having it as an attribute would also be clear. It's
duplicated, but at the same time it's consistant.

Yes I know it makes one version of [] different than others, but if
you state it is going to happen, then it is known. If it is all new
functionality, then it wont break old functionality. If you change
old functionality, you know you are doing it and risking problems.

Python allows for a lot of different things some people in other
languages claim is dangerous because it's too free-hand. That doesn't
make them right, and often I've read statements in the spirit of
"Python gives you enough rope to let shoot yourself in the foot", and
it's meant as a good thing. We're all adults here, etc.

I still think the above things might be good in the language in
general (not just a specific module change), but I would feel a lot
more certain after using them for a while in the real world.


-Geoff Howland
http://ludumdare.com/

Geoff Howland <> wrote:
> As it stands now, everyone has to do this every time,

I suppose that's true. On the other hand, I can't remember the last
time I ever wanted to add two dictionaries.

On Sat, 23 Aug 2003 13:16:47 -0400, Roy Smith <> wrote:

>Geoff Howland <> wrote:
>> As it stands now, everyone has to do this every time,
>
>I suppose that's true. On the other hand, I can't remember the last
>time I ever wanted to add two dictionaries.

Then you wouldn't be effected one way or the other.


-Geoff Howland
http://ludumdare.com/

Geoff Howland <> wrote:
> Then you wouldn't be effected one way or the other.

Sure I will. It will be one more thing I potentially need to know to
understand somebody else's code.

"Geoff Howland" <> wrote in message
news:...
> For the [].len() type things, this is obviously a matter of taste

There is also history (and backwards compatibility). Once upon a
time, neither strings nor tuples had methods, so neither 'abc'.len()
nor (1,2,3).len() would have been possible.

With respect to {}+{}. An in-place version of this is currently
spelled {}.update({}). Yes, more chars to type, but also more
'honest' in not implying symmetry between the two dicts. As the name
suggests, duplicate key with new value overrides previous value.

Terry J. Reedy

On Sat, 23 Aug 2003 13:29:10 -0400, Roy Smith <> wrote:

>Geoff Howland <> wrote:
>> Then you wouldn't be effected one way or the other.
>
>Sure I will. It will be one more thing I potentially need to know to
>understand somebody else's code.

True. Though, again, as long as it works the same way all the time,
then it shouldn't be a problem.


-Geoff Howland
http://ludumdare.com/

Geoff Howland wrote:

> On Sat, 23 Aug 2003 12:40:05 -0400, Roy Smith <> wrote:
>
>>Geoff Howland <> wrote:
>>
>>>{} + {} is not allowed.
>>
>>What would it mean? What would you do if you had two dicts:
>>
>>d1 = {'a':1, 'b':2}
>>d2 = {'a':42}
>>
>>what would the value of (d1+d2)['a'] be?
>
>
> I dont think it matters. Pick one and make that the standard.

Ah, but I think it matters to Guido, or dict operators like these would have
been added long ago.

The problem here is that, when looking at d1 + d2, it is not obvious what is
going on. If the same key appears in both d1 and d2, what will the resulting
dict have? The value in d1? The value in d2? Or maybe an exception will be
raised? Different people will have different notions here about what is
"obvious" and "natural".

"Pick one and make that the standard" may work in some other languages, but
that is usually not how Python's design works. If there is not "one obvious
way", chances are it won't make it into the language. (Of course, there are
exceptions... but this seems to be a rule-of-thumb.)

Fortunately, you can always roll your own dict with the behavior *you* find
natural and obvious. So you can add a + operator to your custom dict, etc.
However, it is not possible to change the behavior of literals. They will
always behave (and be instances of) like the original, built-in object. As a
result, you'll be forced to write something like

d1 = mydict({'a': 1, 'b': 2})
d2 = mydict({'a': 42})
d3 = d1 + d2

On a side note, I don't think the other poster was trying to be facetious when
he suggested you use Ruby... if this language feature is really important to
you, then maybe Ruby may be a better choice, since that language is more
"malleable" than Python.

HTH,

--
Hans ()
http://zephyrfalcon.org/

On Sat, 23 Aug 2003 16:04:52 GMT, rumours say that Geoff Howland
<> might have written:

>On Sat, 23 Aug 2003 16:40:17 +0300, Christos "TZOTZIOY" Georgiou
><> wrote:
>
>>On Sat, 23 Aug 2003 09:16:13 GMT, rumours say that Geoff Howland
>><> might have written:
>>
>>[snip of python's by design inability to modify the base C types: dict,
>>str, list etc]
>
>This post begins to read as an insult here, and continues. My
>incredible gall at thinking something may be better if it was changed
>and wanting to try it! I should be pelted with rocks for speaking the
>name Jehova.

I am sorry, Geoff, but I can't understand how you perceived my post as
insulting. If I did understand a way, I would apologise. I just
snipped stuff in order to make my post shorter, according to netiquette.
How can the phrase inside the brackets seem insulting to you? Geoff,
please justify your clause, and I will gladly apologise.

>Is this really the way this group is going to continue?

I don't know, I can speak for myself only. How many people have
responded to you this "way" to make you wonder about the whole group?

>>>Ruby has this built in, it's useful, it's complete. It's obvious what
>>>is happening, so it's not unclean. It's allowed for other containers.
>>
>>It seems that code "terseness" is more important to you than code
>>readability. I can sympathise with that, perhaps I'd like that too, but
>>I believe I fully understand Guido's decisions over the years to
>>disallow that kind of stuff.
>
>[] + [] is allowed. Right?
>
>{} + {} is not allowed.
>
>len([]) is allowed.
>
>[].len() is not allowed.
>
>Why? I respect Guidos decsions, Python needs a strong leader to make
>them and it got where it is (great language) by having him and the
>rest of the community help out in this regard.

This is the deal, indeed; for example, I would enjoy very much generator
comprehensions in the language, and yet they were rejected.

>Is now no one allowed to say "hey, I think this should be done, and
>I'd like to make it happen to give it a try"? It's not like if it
>becomes a problem it couldn't be reverted and lesson learned right?
>Programming is ABOUT experimentation, not dogmatic obedience.

My reply came to your specific feature request, ie Python allowing you
to modify the base types; your asking if *any* feature request is
disallowed is not justified. I consider your question similar to the
following dialog:

- Can I have cherry pie with my meal?
- No, because the cook has decided it does not match with your meal,
which is fish.
- So no one is allowed to ask for dessert here?

I believe that the symbolism is childish, and this indeed you might find
it insulting, although it isn't. I am not as fluent in English as I
would like, so this is my way to express the general feeling I got from
your reply; I call it "black-and-white", or "ping-pong", lacking a
better English word, and describes a two-way communication where a
disagreement on the one side is perceived magnified as total rejection
on the other side.

>>I really don't mind subclassing base types and using MyDict() instead of
>>{}. I want to be able to make my own APIs (MyDict.update *could* blow
>>whistles and roll twice on the floor before resetting the machine), but
>>I also want a steady and well-known API for base types (dict.update
>>*should* update a dictionary from another one).
>
>Why should it matter what you mind? It's my code.

What should it matter what you mind then? It's Guido's language.
Either we both are allowed to say our minds, or not. My opinion is as
important as yours. Keep that in mind, please.

The fact is, the subject has been brought up in the past, and it has
been skipped. I am not sure if has been rejected, so you might have a
chance. If you are as warm about this subject as you seem to be, write
a PEP; my vote will probably be positive. But Guido is the one to
convince, and he listens; my experience so far has shown that he never
replies the way you do, and that is good.

This URL should be useful:
http://www.python.org/peps/pep-0001.html

>>You can always roll off a customised Python interpreter, of course, but
>>it won't be Python anymore.

>>With all due respect, Geoff, if this stuff is really important to you,
>>use Ruby.

>Yes, throw the heathen into another language. I'm not good enough for
>this one.

Your last statement is unjustified too, and "black-and-white", assuming
hidden meanings in my words. Geoff, I am picking my words very
carefully because I don't want to make you jump to the ceiling with
rage. Please read, don't assume.

My sentence was a practical (and respectful!) suggestion; Ruby already
has what you want, and you like it, so why not use it, since the Python
community (and Guido most of all) are against such a modification? Did
you do a research in older newsgroup threads before posting?

>I find this attitude really insulting. I like Python for what it is,
>that doesnt mean I dont think there are some things that could be
>better and want to try them. I wanted to know if it's possible, so I
>asked. I think it's important, so I persisted. Get over it. Stop
>making this place an unpleasant place to ask questions in fear of not
>asking in a Pythonic enough way.

Perhaps you are irritated by earlier discussions, whom I'm not in the
mood to look for; this might explain your misinterpretation of my
message. Geoff, my attitude was not insulting. It was practical.

>Not the first time I've seen this here, I'm sure it wont be the last.
>Not sure how many people never picked it up because they were smacked
>down before they found their groove in Python.

>I'm sorry this sounds heavy and upset, but I would like this place to
>not feel so bitter against exploratory questions. Bounds are set in
>Python, it's good. It doesn't mean people shouldn't ask and explore
>and find out for themselves what is best if it is possible. I could
>even go and change all the Python C source to make this work, who is
>it going to hurt but myself? It may even bring me valuable insight
>that I can then share as an _opinion_ with others who ask later (note,
>not telling them to use another language because they want to do
>something I dont agree with).

Geoff, please. Your last statement inside the parentheses is based on
false assumptions, which is bad, because you already had the data. From
my previous post I said I'd possibly like what you suggest, and I meant
it --and still do. If you don't believe me, if you feel that I am
bullying you, lying to you, using sarcasm or irony on you, then I'll
have to give up.

Don't spend your energy fighting with me (one-side fights: only on
USENET , write a PEP and find good arguments for it.
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.

On Sat, 23 Aug 2003 21:56:08 +0300, Christos "TZOTZIOY" Georgiou
<> wrote:

>>>[snip of python's by design inability to modify the base C types: dict,
>>>str, list etc]
>>
>>This post begins to read as an insult here, and continues. My
>>incredible gall at thinking something may be better if it was changed
>>and wanting to try it! I should be pelted with rocks for speaking the
>>name Jehova.
>
>I am sorry, Geoff, but I can't understand how you perceived my post as
>insulting. If I did understand a way, I would apologise. I just
>snipped stuff in order to make my post shorter, according to netiquette.
>How can the phrase inside the brackets seem insulting to you? Geoff,
>please justify your clause, and I will gladly apologise.

If you didn't mean it as insulting, than I am very sorry for taking it
so and responding in the way I did.

I saw it as I was being told that I am ignoring the good design
philosophies of Python, and as such I should move on to another
language. I have been told exactly this thing before (without being
mistaking) so I suppose I am more sensitive to it than I would have
been had I not had it said before.

Sorry for misunderstanding you and becoming upset about it.

>>Is this really the way this group is going to continue?
>
>I don't know, I can speak for myself only. How many people have
>responded to you this "way" to make you wonder about the whole group?

Maybe 2 here, to more or lesser degrees. Probably about 5 times on
python IRC channels.

>>Why? I respect Guidos decsions, Python needs a strong leader to make
>>them and it got where it is (great language) by having him and the
>>rest of the community help out in this regard.
>
>This is the deal, indeed; for example, I would enjoy very much generator
>comprehensions in the language, and yet they were rejected.

Exactly, and as long as it's ok to bring them up, then all is well. I
was just feeling like I was being rebuked for doing so. In
retrospect, I probably should have just not responded at all to the
thread portion that I felt that way about, as other people were giving
me answers I thought were completely even.

I do appreciate Python's design decisions. It's what keeps it from
becomming the things I dont like about Perl, where that does not seem
to be the case. However, I still like having the rope to shoot myself
in the foot if I so desire, but if it doesnt exist I'll get by without
it.

>>Is now no one allowed to say "hey, I think this should be done, and
>>I'd like to make it happen to give it a try"? It's not like if it
>>becomes a problem it couldn't be reverted and lesson learned right?
>>Programming is ABOUT experimentation, not dogmatic obedience.
>
>My reply came to your specific feature request, ie Python allowing you
>to modify the base types; your asking if *any* feature request is
>disallowed is not justified. I consider your question similar to the
>following dialog:
>
>- Can I have cherry pie with my meal?
>- No, because the cook has decided it does not match with your meal,
>which is fish.
>- So no one is allowed to ask for dessert here?

Well, this was because I took your post as hostility. I'm not sure I
was out there in interpretting this way, as usually telling someone to
"go somewhere else" when they inquire about things is meant that way.

>I believe that the symbolism is childish, and this indeed you might find
>it insulting, although it isn't. I am not as fluent in English as I
>would like, so this is my way to express the general feeling I got from
>your reply; I call it "black-and-white", or "ping-pong", lacking a
>better English word, and describes a two-way communication where a
>disagreement on the one side is perceived magnified as total rejection
>on the other side.

Im fine with the things being one way or another, no problems at all
with it. I understand why base types arent allowed to be modified,
cause while you could do it without damaing things, it would be a lot
more likely that things would be damaged over time and you might never
know you're including a module that changes behavior. It makes sense.

That doesn't mean it wouldnt be useful, which is why I was inquiring.
If it was possible, I'd probably do it because of it's usefulness. If
it became a problem later, I could correct that. I am flexible that
way, it is probably a good thing Guido and the Python community that
helps design Python is not. Checks and balances.

As long as it's still ok to inquire.

I think the last thing that was really brought up in this "how dare
you" type style was someone inquiring about protecting their code from
people reading it. Some people near-flamed the guy for asking how to
do this, and I think it is ridiculous. Everyone has their own
purposes for tools, so my ire was up.

>>>I really don't mind subclassing base types and using MyDict() instead of
>>>{}. I want to be able to make my own APIs (MyDict.update *could* blow
>>>whistles and roll twice on the floor before resetting the machine), but
>>>I also want a steady and well-known API for base types (dict.update
>>>*should* update a dictionary from another one).
>>
>>Why should it matter what you mind? It's my code.
>
>What should it matter what you mind then? It's Guido's language.
>Either we both are allowed to say our minds, or not. My opinion is as
>important as yours. Keep that in mind, please.

Sure, but you were answering a question and saying "no" based on your
opinions. That's tangential to the question, which is that I want to
do something. That it's not possible is topical. That
Guido/PythonLabs doesnt approve is topical, in the sense of a style
guide. That you don't approve is topical on an advice level, but not
on a "how do I do this" level.

Thats my view of it, and since I was thinking you were saying I should
"move on to another language for not liking everything exactly as it
is now", then I took it as a judgement placement, rather than advise.

Again, my misunderstanding and my appology.

>The fact is, the subject has been brought up in the past, and it has
>been skipped. I am not sure if has been rejected, so you might have a
>chance. If you are as warm about this subject as you seem to be, write
>a PEP; my vote will probably be positive. But Guido is the one to
>convince, and he listens; my experience so far has shown that he never
>replies the way you do, and that is good.
>
>This URL should be useful:
>http://www.python.org/peps/pep-0001.html

I actually wanted to do a proof of concept and try it before writing a
PEP. Cause if it turns out to suck in practice, why bother with the
PEP? I think now I would have to change the Python C code in order to
try it, and that isnt acceptable to me as I wouldnt be able to really
put it into effect in the real world and see if it works.

I'm all for putting in the time to write and push a PEP if I think
something is really worth it and I have proof in my own eyes. I'm
also accepting if it gets rejected because it doesn't fit with the
language. So far I haven't gotten to a point where I am confident
enough about something I think should work a different way to do this.
Maybe someday it will happen, maybe it wont. I'd like to help, but
dont want to make suggestions that aren't really helpful until I'm
convinced myself that they are.

>>>With all due respect, Geoff, if this stuff is really important to you,
>>>use Ruby.
>
>>Yes, throw the heathen into another language. I'm not good enough for
>>this one.
>
>Your last statement is unjustified too, and "black-and-white", assuming
>hidden meanings in my words. Geoff, I am picking my words very
>carefully because I don't want to make you jump to the ceiling with
>rage. Please read, don't assume.

The difficulties of reading text. I showed this message to 2 other
people, and they also thought it was telling me off instead of just
explaining something to me. However, I still appologize for
misreading your intentions and my response.

>My sentence was a practical (and respectful!) suggestion; Ruby already
>has what you want, and you like it, so why not use it, since the Python
>community (and Guido most of all) are against such a modification? Did
>you do a research in older newsgroup threads before posting?

Yeah, I searched around for about 6 hours before posting this, also
poking around in different books and the python interpretter. I
didn't find this topic covered, but sometimes it's very hard to find
things with common words like: python, dict, modification/override,
etc.

Ruby is a great language, but there are a couple reasons it wont be
used in this circumstance. If it was possible and practical, then I
would use it.

>Don't spend your energy fighting with me (one-side fights: only on
>USENET , write a PEP and find good arguments for it.

I dont intend to, I'm glad there was a misunderstanding and sorry I
misunderstood (hope thats parseable).

Maybe there will be a PEP on this someday, but it'll be harder to do
without evidence that it works well in the real world first.


-Geoff Howland
http://ludumdare.com/

Geoff Howland wrote:

> On 23 Aug 2003 08:18:49 -0700, (Michele Simionato)
> wrote:
>
> >Subclass dict, define __add__ and __sub__ and it will work, but NOT
> >with the brace syntax. You must use something like
> >
> >mydict(a=1,b=2)+mydict(c=3,d=4)
>
> Yeah, I got this to work off the bat.

So what's the problem? If you got it to do what you wanted, why would
you possibly want your personal changes reflected officially in the
language? Sit back for a moment and think what would happen if
_everybody_ proceeded this way.

--
Erik Max Francis && && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Wars may be fought with weapons, but they are won by men.
\__/ Gen. George S. Patton