On 28/12/2018 20:34, Avi Gross wrote: > So before I respond, here is a general statement. I am NOT particularly > interested in much of what we discuss here from a specific point of view. > Someone raises a question and I think about it. They want to know of a > better way to get a random key from a dictionary. My thought is that if I > needed that random key, maybe I would not have stored it in a dictionary in > the first place. But, given that the data is in a dictionary, I wonder what > could be done. It is an ACADEMIC discussion with a certain amount of hand > waving.
But you need to apply real world constraints. The choice of data type is intrinsic to the language in use. (The same is true of control structures - loops, decision points etc - but that is less pertinent here.) If you program in C pretty much all you get is the array. Everything else (including struct/union/typedef) is hand crafted by the programmer. If its Lisp then you get the list and anything else is coded (or simulated in code) by hand. In Python we have lists, tuples, dictionaries and sets. Anything else, including subclassing the basic types, is down to the programmer (or finding a module already created by somebody else). In Smalltalk we have over a hundred basic collection types to choose from. And the choice to subclass any of them. So when you address a problem in any given language the available solutions must be constrained by whatever the language in question offers. Wishing for non-existent data structures that may exist elsewhere is simply to request a new feature to be designed and programmed in the language at hand. That may be the best solution depending on the nature of the problem but we need to recognise the nature of the request. It is still a new feature. Of course we can learn a great deal by comparing features on one language against another but in terms of solving a specific request we need specific answers too. > --- > The obvious solution: > > keys = list(mydict.keys()) > random.shuffle(keys) > index = len(keys)*3//4 > training_data = keys[:index] > reserved = keys[index:] > --- > For me, it seems more natural in this case to simply have the data in a data > frame where I have lots of tools and methods available. But only if such a data frame exists. In Python it does not (at least, not in the standard library). So any reference to such a non existent structure is in effect a work request for someone to build one. To do so requires a specification or design that the OP can follow or better still a prototypical template. It also assumes a much higher level of skill than the original request and the "obvious solution". > but if your coding style is more comfortable with another way, why bother > unless you are trying to learn other ways and be flexible. If your current language does not support the structure you desire you have three choices: 1) change your programming language or 2) build the missing feature or 3) find a workaround using the structures available. Most people opt for #3. (Although all may be valid options depending on the circumstance) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor