Different types of dicts with letter before the curly braces.
I am sure people have thought of this before, but I cant find where.
I think that python should adapt a way of defining different types of
mapping functions by proceeding a letter before the curly brackets.
i.e ordered = o{}, multidict = m{} (like paste multidict). So you
could define an ordered dict by newordered = o{"llvm" : "ptyhon",
"parrot" : "perl"} . (they should also probably have there own
comprehensions as well o{foo for bar in foobar}).
People nowadays think in terms of hashes and lists (especially with
jsons and javascript not going away} and most of my time seems to be
spent in different ways to store bits of data in memory in this way.
It also seems to be the way to think in python (an object or a class
object are just mappings themselves) Most packages that I have seen re-
implement these different container types at one point anyway. It
seems a shame they are not brought up to the top level, with
potentially new, cleverer ones that have not been thought of yet.
There will be potential to add different letters to the start when it
seems that a certain mapping pattern seems in popular use.
Am I crazy to think this is a good idea? I have not looked deeply
pythons grammer to see if it conflicts with anything, but on the
surface it looks fine.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Different types of dicts with letter before the curly braces.
On Jun 14, 12:25 pm, Mike Kazantsev wrote: > On Sun, 14 Jun 2009 04:02:47 -0700 (PDT) > > kindly wrote: > > Am I crazy to think this is a good idea? I have not looked deeply > > pythons grammer to see if it conflicts with anything, but on the > > surface it looks fine. > > I'd say "on the surface it looks like perl" ;) > I'd prefer to use dict() to declare a dict, not some mix of letters and > incomprehensible symbols, thank you. > > -- > Mike Kazantsev // fraggod.net > > signature.asc > < 1KViewDownload Python already has it for strings r"foo" or u"bar". So I do not think its going against the grain. -- http://mail.python.org/mailman/listinfo/python-list
Re: Different types of dicts with letter before the curly braces.
On Jun 14, 1:59 pm, Steven D'Aprano
wrote:
> Stefan Behnel wrote:
> > Hi,
>
> > this kind of stuff is commonly discussed on the python-ideas mailing list.
> > You might want to search that list and/or repost this over there.
>
> Please don't top-post here.
>
> If the OP takes this idea to python-ideas, chances are he'll be told to take
> the concept here first, for feedback, before python-ideas.
>
> More comments below:
>
> > kindly wrote:
> >> I am sure people have thought of this before, but I cant find where.
> >> I think that python should adapt a way of defining different types of
> >> mapping functions by proceeding a letter before the curly brackets.
> >> i.e ordered = o{}, multidict = m{} (like paste multidict). So you
> >> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
> >> "parrot" : "perl"} . (they should also probably have there own
> >> comprehensions as well o{foo for bar in foobar}).
>
> You can do that more readably:
>
> data = OrderedDict()
> data = SortedDict()
> data = MultiDict() etc.
>
> The advantages are:
>
> * no new syntax is needed;
>
> * you can have as many different types of mappings as needed, without
> needing to change the compiler or worry about clashes between letters;
>
> * not all mapping types necessarily have the same initialiser signature;
>
> * the mapping type doesn't need to be a built-in type.
>
> The analogy with raw strings is faulty: r"" changes the way the compiler
> interprets the characters between the quotes, it doesn't create a different
> type of object.
>
> There's nothing explicitly *wrong* with the idea of o{} m{} etc for a
> *small* number of built-in mapping types. If ordered dicts (say) ever
> become built-ins, rather than a type that you have to import from a module,
> then maybe we'll be looking for syntax for them, in which case there's
> worse ideas than o{}. But even then, a disadvantage would be that it's
> awfully perlish. There's already two uses for {}, namely dicts and sets,
> and I don't know that adding a third or more is a good idea.
>
> --
> Steven
Thank you all for your feedback. I have never actually used perl, but
I imagine if I did, I imagine I would have more disgust at the suger.
I think my point is more that I think python should consider having
more useful top level data structures and less to do with how they are
created. There has been a big shift in the way people pass around
structures and this is mainly due to the dict(hash) type, that python
uses so well. I am glad the ordered dict will be in 2.7 and 3.1. I
was just imagining what would be the next step in definition of
structures. New languages like clojure have adopted the dict as top
level. I imagine immutable/thread safe/transactional dicts to be
around soon in other languages to help with concurrency. It would be
nice if python was ahead of the game in this.
--
http://mail.python.org/mailman/listinfo/python-list
Re: persistent composites
On Jun 14, 3:27 pm, Aaron Brady wrote: > Hi, please forgive the multi-posting on this general topic. > > Some time ago, I recommended a pursuit of keeping 'persistent > composite' types on disk, to be read and updated at other times by > other processes. Databases provide this functionality, with the > exception that field types in any given table are required to be > uniform. Python has no such restriction. > > I tried out an implementation of composite collections, specifically > lists, sets, and dicts, using 'sqlite3' as a persistence back-end. > It's significantly slower, but we might argue that attempting to do it > by hand classifies as a premature optimization; it is easy to optimize > debugged code. > > The essentials of the implementation are: > - each 'object' gets its own table. > = this includes immutable types > - a reference count table > = when an object's ref. count reaches zero, its table is dropped > - a type-map table > = maps object's table ID to a string of its type > - a single 'entry point' table, with the table ID of the entry-point > object > = the entry point is the only data structure available to new > connections. (I imagine it will usually be a list or dict.) > > I will be sure to kill any interest you might have by now, by > "revealing" a snippet of code. > > The object creation procedure: > > def new_table( self, type ): > ''' 'type' is a string, the name of the class the object is an > instance of ''' > cur= self.conn.cursor( ) > recs= cur.execute( '''SELECT max( tableid ) FROM refcounts''' ) > rec= cur.fetchone( ) > if rec[ 0 ] is None: > obid= 0 > else: > obid= rec[ 0 ]+ 1 > cur.execute( '''INSERT INTO types VALUES( ?, ? )''', ( obid, > type ) ) > cur.execute( '''INSERT INTO refcounts VALUES( ?, ? )''', ( obid, > 1 ) ) > > The increment ref. count procedure: > > def incref( self, obid ): > cur= self.conn.cursor( ) > recs= cur.execute( '''SELECT count FROM refcounts WHERE tableid > = ?''', ( obid, ) ) > rec= recs.fetchone( ) > newct= rec[ 0 ]+ 1 > cur.execute( '''UPDATE refcounts SET count = ? WHERE tableid = ?''', > ( newct, obid ) ) > > The top-level structure contains these two procedures, as well as > 'setentry', 'getentry', and 'revive' procedures. > > Most notably, user-defined types are possible. The dict is merely a > persistent dict. 'revive' checks the global namespace by name for the > original type, subject to the same restrictions that we all know and > love that 'pickle' has. > > As usual, deadlocks and cyclic garbage pose the usual problems. The > approach I used last time was to maintain a graph of acquired locks, > and merely check for cycles to avert deadlocks, which would go in a > separate table. For garbage, I can't find a better solution than > Python already uses. > > From the 3.0 docs: > gc.garbage > > A list of objects which the collector found to be unreachable but > could not be freed (uncollectable objects). > ... > Python doesn’t collect such [garbage] cycles automatically because, in > general, it isn’t possible for Python to guess a safe order in which > to run the __del__() methods. If you know a safe order, you can force > the issue by examining the garbage list, and explicitly breaking > cycles due to your objects within the list. > > Before I go and flesh out the entire interfaces for the provided > types, does anyone have a use for it? I like it as a concept, have not got any use for it this minute, but I am sure it will be useful someday. -- http://mail.python.org/mailman/listinfo/python-list
