Re: Modifying the {} and [] tokens

Discussion in 'Python' started by Andrew Dalke, Aug 23, 2003.

  1. Andrew Dalke

    Andrew Dalke Guest

    Geoff Howland:
    > I want to modify the {} and [] tokens to contain additional
    > functionality they do not currently contain, such as being able to add
    > dicts to dicts, and other things that would be very helpful for me and
    > my team mates to have.


    You can't. Not without changing the underlying implementation.

    > So I can obviously override dict and it works when I specifically call
    > dict(), but it does not work with the syntax sugar {}.


    That's because you created a new dict. You didn't modify the
    actual type {} uses in the intepreter. {} is not simple syntactic sugar
    for dict() in the local namespace. BTW, if it were, then

    dict = 8
    a = {3: 4}

    would fail.

    > How can I make this work? Can this also work to overload strings with
    > the "" and '' tokens?


    You can't. What's wrong with using your derived dict? Why must you
    use {}?

    You can't modify the fundamental type used by strings either.

    Andrew
     
    Andrew Dalke, Aug 23, 2003
    #1
    1. Advertising

  2. On Sat, 23 Aug 2003 04:41:20 GMT, "Andrew Dalke"
    <> wrote:

    >Geoff Howland:
    >> I want to modify the {} and [] tokens to contain additional
    >> functionality they do not currently contain, such as being able to add
    >> dicts to dicts, and other things that would be very helpful for me and
    >> my team mates to have.

    >
    >You can't. Not without changing the underlying implementation.


    The implementation in the C code, or implementation at the Python
    level?

    As long as this stays in Python, like as a module that can be included
    or not, then I think it would be helpful. I think a lot of the things
    I would like to do might actually be good in the language, but maybe
    they've already been thrown out, or something. For now, I dont have
    an entire list and implementation of everything I would like to see to
    really present as a "possible change list", so I'd just like to be
    able to do this to assist in my own teams work.

    There is history and other info beyond this besides "I think it would
    be neat", but that is team private business so I dont want to drag it
    out here. This would just be helpful.

    >> So I can obviously override dict and it works when I specifically call
    >> dict(), but it does not work with the syntax sugar {}.

    >
    >That's because you created a new dict. You didn't modify the
    >actual type {} uses in the intepreter. {} is not simple syntactic sugar
    >for dict() in the local namespace. BTW, if it were, then
    >
    > dict = 8
    > a = {3: 4}
    >
    >would fail.


    Right, so is there a way to change this? I know the syntax I tried
    doesnt work and for obvious type reasons, since you wouldnt want to do
    this by accident.

    Perhaps something has to be registered in some Python
    variable/class/module-list I am not aware of that would make this
    happen? I am ok with the consequences of potentially introducing
    oddities into my code from the Norm for this flexibility.

    >> How can I make this work? Can this also work to overload strings with
    >> the "" and '' tokens?

    >
    >You can't. What's wrong with using your derived dict? Why must you
    >use {}?


    The reason for using it is that it is easier to code using the default
    containers than having to specify things. IMO, there are some things
    missing from the language, and while maybe they wont be added, I would
    like to have them.

    {} + {}, {} - {}. [] - [], etc

    These operations would be useful, as well as additional functions that
    are commonly performed and have to be put in separate modules.

    I would also like to move all the usual operational functions into
    some of these, such as instead of len([]), you could do [].len().
    More consistent for some of my team to read.

    If it's impossible without creating a new EXE, then I wont have a
    choice. If it is not impossible, then I would like to be able to add
    some things to the standard containers that are already very powerful
    but seem to be missing some basics to complete their operational sets.

    >You can't modify the fundamental type used by strings either.


    I'd have the same questions above for this. :)


    -Geoff Howland
    http://ludumdare.com/
     
    Geoff Howland, Aug 23, 2003
    #2
    1. Advertising

  3. Geoff Howland wrote:

    > IMO, there are some things
    > missing from the language, and while maybe they wont be added, I

    would
    > like to have them.
    >
    > {} + {}, {} - {}. [] - [], etc


    I'm a little puzzled as to why you'd need these, since it seems
    like all they allow you to is hard-code a certain combination of
    statically defined objects. That is, if you're going to do

    { 'a': 1, 'b': 2 } + { 'c': 3, 'd': 4}

    . . .why not just write

    { 'a': 1, 'b': 2, 'c': 3, 'd': 4}

    in the first place?

    --
    --OKB (not okblacke)
    "Do not follow where the path may lead. Go, instead, where there is
    no path, and leave a trail."
    --author unknown
     
    OKB (not okblacke), Aug 23, 2003
    #3
  4. On 23 Aug 2003 07:02:53 GMT, "OKB (not okblacke)" <>
    wrote:

    >> {} + {}, {} - {}. [] - [], etc

    >
    > I'm a little puzzled as to why you'd need these, since it seems
    >like all they allow you to is hard-code a certain combination of
    >statically defined objects. That is, if you're going to do
    >
    >{ 'a': 1, 'b': 2 } + { 'c': 3, 'd': 4}
    >
    > . . .why not just write
    >
    >{ 'a': 1, 'b': 2, 'c': 3, 'd': 4}
    >
    > in the first place?


    Because I wouldn't just be using {} on a line, I would create a
    dictionary with it and then use it around, and then at some point
    later I may want to add another dictionary to it, or find the union or
    differences between two dictionaries.

    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.


    -Geoff Howland
    http://ludumdare.com/
     
    Geoff Howland, Aug 23, 2003
    #4
  5. Andrew Dalke

    Dave Brueck Guest

    On Saturday 23 August 2003 10:12 am, Geoff Howland wrote:
    > On 23 Aug 2003 08:18:49 -0700, (Michele Simionato)
    >
    > >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).


    Does {'a':4} + {'a':6} equal
    (a) {'a':10}
    (b) {'a':[4,6]}
    (c) {'a':4}
    (d) {'a':6}

    ???

    I can think of reasonable & realistic use cases where each one is the
    "obvious" choice.

    > len([])
    >
    > [].len()


    If you can conjure up the right Google Groups query, this has been discussed
    many times in the past (and by that I mean some good points have been raised
    that you might find interesting). In particular, I remember Alex Martelli
    making a good argument for len(obj) over obj.len(). For my part, now that I'm
    used to len(obj), the form obj.len() seems too much like
    OO-just-for-the-sake-of-OO, which isn't very compelling.

    -Dave
     
    Dave Brueck, Aug 23, 2003
    #5
  6. >>> So I can obviously override dict and it works when I specifically call
    >>> dict(), but it does not work with the syntax sugar {}.

    >>
    >>That's because you created a new dict. You didn't modify the
    >>actual type {} uses in the intepreter. {} is not simple syntactic sugar
    >>for dict() in the local namespace. BTW, if it were, then
    >>
    >> dict = 8
    >> a = {3: 4}
    >>
    >>would fail.

    >
    >Right, so is there a way to change this? I know the syntax I tried
    >doesnt work and for obvious type reasons, since you wouldnt want to do
    >this by accident.
    >
    >Perhaps something has to be registered in some Python
    >variable/class/module-list I am not aware of that would make this
    >happen? I am ok with the consequences of potentially introducing
    >oddities into my code from the Norm for this flexibility.


    I've explored all of __builtins__ that I have been able to, and
    replacing dict there does nothing either, so I'm beginning to think
    that {}, [], etc are bound to types in the C code only and not
    available at all through Python to be re-typed.

    Is this correct? Is there no way to change type on these expression
    delimeters?

    I would think that somewhere this is a Python accessable definitely of
    what <type 'dict'> is that could be altered, so far I cant seem to
    find any reference to it through the Python Language Reference, Python
    in a Nutshell, or any google search.

    Python in a Nutshell specifies that dict(d={}) is essentially d = {},
    but I can't find a description of how this token/expression to type
    binding happens.

    It seems like it would be really handy to add features to all
    containers equally though, especially since you should be able to get
    new functionality from any code written even if it didn't know about
    your new features because it could instantiate with the new type.

    BTW, some of the other comments in my team have been for a desire of
    more inclusive OO, such as [].len() instead of len([]), and this sort
    of thing. Having them builtin is obviously great and useful, but it
    feels wrong to some people and I'm trying to work on making things
    smoother instead of just forcing them to adapt (which they may not
    choose to do).


    -Geoff Howland
    http://ludumdare.com/
     
    Geoff Howland, Aug 23, 2003
    #6
  7. 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]

    >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.

    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).

    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.
    --
    TZOTZIOY, I speak England very best,
    Microsoft Security Alert: the Matrix began as open source.
     
    Christos TZOTZIOY Georgiou, Aug 23, 2003
    #7
  8. Andrew Dalke

    Robert Kern Guest

    In article <>,
    Geoff Howland <> writes:

    [snip]

    > I've explored all of __builtins__ that I have been able to, and
    > replacing dict there does nothing either, so I'm beginning to think
    > that {}, [], etc are bound to types in the C code only and not
    > available at all through Python to be re-typed.
    >
    > Is this correct? Is there no way to change type on these expression
    > delimeters?
    >
    > I would think that somewhere this is a Python accessable definitely of
    > what <type 'dict'> is that could be altered, so far I cant seem to
    > find any reference to it through the Python Language Reference, Python
    > in a Nutshell, or any google search.
    >
    > Python in a Nutshell specifies that dict(d={}) is essentially d = {},
    > but I can't find a description of how this token/expression to type
    > binding happens.


    The parser compiles {} into the BUILD_MAP opcode which the eval loop
    interprets by calling PyDict_New(). This creates a dict object
    independently of whatever __builtins__.dict is bound to.

    I discovered this by disassembling some code and looking up the opcode
    in the bytecode interpreter eval loop (Python/ceval.c).

    >>> import dis
    >>> code = compile("{}", "<test>", "single")
    >>> dis.dis(code)

    1 0 BUILD_MAP 0
    3 PRINT_EXPR
    4 LOAD_CONST 0 (None)
    7 RETURN_VALUE

    Reading the Language Reference can help a lot, too.

    > It seems like it would be really handy to add features to all
    > containers equally though, especially since you should be able to get
    > new functionality from any code written even if it didn't know about
    > your new features because it could instantiate with the new type.


    I think that's precisely the reason why this feature will probably
    never make it into Python. I, for one, don't want a module that I import
    to change the meaning of a literal just because that module wants to use
    a funky form of dict internally.

    It's possible it could be encapsulated on a per-file basis, but that
    would probably require adding another opcode for each builtin type.

    In the end, it's just not worth the trouble. 99.9% of the time, I think
    you will find that subclassing the builtin types and giving the new
    classes short names will suffice. I mean, how much of a hardship is it
    to do the following:

    class d(dict):
    def __add__(self, other):
    # stuff

    d({1:2}) + d({3:4})

    It's only 3 extra characters each time; everyone who reads it knows what
    is going on, knows to look for "class d" to find out how it's different
    from a normal dict; it doesn't screw up other people's code; and it even
    allows for you to define "class YetAnotherDict(dict)" which has
    completely different behavior and use both at the same time.

    If you're still not convinced, ask yourself these questions:

    * How would you apply the new subclass?
    - Only on new literals after the subclass definition (and registry of
    the subclass with some special hook)?
    - On every new object that would normally have been the base type?
    - On every previously existing object with the base type?
    - In just the one module? or others which import it? or also in
    modules imported after the one with the subclass?

    * How does your choice above work with code compiled on-the-fly with
    eval, exec or execfile?

    * How do you deal with multiple subclasses being defined and registered?

    * How would you pass in initialization information?
    E.g. say I want to limit the length of lists

    class LimitList(list):
    def __init__(self, maxlength, data=[]):
    self.maxlength = maxlength
    list.__init__(self, data)
    def append(self, value):
    if len(self) == self.maxlength:
    raise ValueError, "list at maximum length"
    else:
    list.append(self, value)

    * Can I get a real dict again if wanted to?

    * Given your choices above, how can you implement it in such a way that
    you don't interfere with other people's code by accident?

    Okay, so the last one isn't really fair, but the answers you give on the
    other questions should help define in your mind the kind of behavior you
    want. Reading up on Python internals with the Language Reference, the
    dis module documentation, and some source code should give you an idea
    of how one might go about an implementation and (more importantly) the
    compromises one would have to make.

    Then compare these specific features with the current way. Which is
    safer? Which is more readable by someone unfamiliar with the code? Which
    is more flexible? Which saves the most typing?

    > BTW, some of the other comments in my team have been for a desire of
    > more inclusive OO, such as [].len() instead of len([]), and this sort
    > of thing. Having them builtin is obviously great and useful, but it
    > feels wrong to some people and I'm trying to work on making things
    > smoother instead of just forcing them to adapt (which they may not
    > choose to do).


    My condolences on having to deal with such a team. It seems a little
    silly to me to equate OO with Everything-Must-Be-a-Method-Call. But if
    they insist, point them at [].__len__(). len([]) just calls [].__len__()
    anyways. After writing code like that for a while, they'll probably get
    over their method fixation.

    > -Geoff Howland
    > http://ludumdare.com/


    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 23, 2003
    #8
  9. Geoff Howland <> wrote in message news:<>...
    > On 23 Aug 2003 07:02:53 GMT, "OKB (not okblacke)" <>
    > wrote:
    >
    > >> {} + {}, {} - {}. [] - [], etc

    > >
    > > I'm a little puzzled as to why you'd need these, since it seems
    > >like all they allow you to is hard-code a certain combination of
    > >statically defined objects. That is, if you're going to do
    > >
    > >{ 'a': 1, 'b': 2 } + { 'c': 3, 'd': 4}
    > >
    > > . . .why not just write
    > >
    > >{ 'a': 1, 'b': 2, 'c': 3, 'd': 4}
    > >
    > > in the first place?

    >
    > Because I wouldn't just be using {} on a line, I would create a
    > dictionary with it and then use it around, and then at some point
    > later I may want to add another dictionary to it, or find the union or
    > differences between two dictionaries.
    >
    > 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.
    >
    >
    > -Geoff Howland
    > http://ludumdare.com/


    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)

    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".

    Michele Simionato, Ph. D.

    http://www.phyast.pitt.edu/~micheles
    --- Currently looking for a job ---
     
    Michele Simionato, Aug 23, 2003
    #9
  10. 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.

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

    >>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.

    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.

    >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.

    >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.

    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.

    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 Howland
    http://ludumdare.com/
     
    Geoff Howland, Aug 23, 2003
    #10
  11. 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, Aug 23, 2003
    #11
  12. Andrew Dalke

    Roy Smith Guest

    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.
     
    Roy Smith, Aug 23, 2003
    #12
  13. 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, Aug 23, 2003
    #13
  14. Andrew Dalke

    Roy Smith Guest

    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.
     
    Roy Smith, Aug 23, 2003
    #14
  15. Andrew Dalke

    Terry Reedy Guest

    "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
     
    Terry Reedy, Aug 23, 2003
    #15
  16. 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, Aug 23, 2003
    #16
  17. Andrew Dalke

    Hans Nowak Guest

    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/
     
    Hans Nowak, Aug 23, 2003
    #17
  18. 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.
     
    Christos TZOTZIOY Georgiou, Aug 23, 2003
    #18
  19. 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, Aug 23, 2003
    #19
  20. 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
     
    Erik Max Francis, Aug 23, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ben Holness
    Replies:
    0
    Views:
    5,472
    Ben Holness
    Jan 6, 2006
  2. =?Utf-8?B?RWx0b24gVw==?=

    RE: string into tokens

    =?Utf-8?B?RWx0b24gVw==?=, Oct 13, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    453
    =?Utf-8?B?RWx0b24gVw==?=
    Oct 13, 2005
  3. =?Utf-8?B?TFc=?=

    string into tokens

    =?Utf-8?B?TFc=?=, Oct 13, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    401
    =?Utf-8?B?TFc=?=
    Oct 13, 2005
  4. Muhammad Adeel
    Replies:
    2
    Views:
    331
    Muhammad Adeel
    Aug 6, 2010
  5. DFS
    Replies:
    92
    Views:
    405
    BartC
    Jun 17, 2014
Loading...

Share This Page