Thank you, Dieter! Bingo.
When I think about it now, it is very logical: There must be another
mechanism besides sys.path, otherwise modules inside packages would not
find their siblings or subpackages.
But whereever the search path is explained, only sys.path was mentioned,
so I took that at
>One idea that seems to work is setting __name__ = '__main__'
Or, del sys.modules[__name__].
--
http://mail.python.org/mailman/listinfo/python-list
Webware 0.9 has been released.
Webware for Python is a suite of Python packages and tools for
developing object-oriented, web-based applications. The suite uses well
known design patterns and includes a fast Application Server, Servlets,
Python Server Pages (PSP), Object-Relational Mapping, Tas
This is probably a FAQ, but I dare to ask it nevertheless since I
haven't found a satisfying answer yet: Why isn't there an "ordered
dictionary" class at least in the standard list? Time and again I am
missing that feature. Maybe there is something wrong with my programming
style, but I rather
> What answers have you received that have not been satisfactory?
I googled a little bit and haven't found many answers at all. Some were
in the posting I mentioned: Stuff should go into the standard lib only
when it is mature and "right" enough. However, we are already at Python
2.4 and there
[EMAIL PROTECTED] schrieb:
> By ordered dict, one usually wants order that is arbitary which cannot
> be derived from the content, say insertion order(most ordered dict I
> saw use this order).
> I am writing a web applications(simple forms) which has a number of
> fields. Each field naturally has
Fredrik Lundh wrote:
> if you restructure the list somewhat
> d = (
> ('pid', ('Employee ID', 'int')),
> ('name', ('Employee name', 'varchar')),
> ('sal', ('Salary', 'float'))
> )
> you can still loop over the list
> ...
> but you can easily generate an index whe
Ben Finney wrote:
> Without an example, it's hard to know what you want to do and whether
> an ordered dictionary is the best way to do it.
I have indicated an example, discussed in more detail in another subthread.
>> There are already enough competing implementations.
> Have they been sufficie
[EMAIL PROTECTED] wrote:
> Personally, I have needs for ordered dict but I don't think it should
> be in standard library though, as different situation called for
> different behaviour for "ordered" and skewing my code to a standard lib
> way is no good.
I have started the thread in the first pla
Ben Finney wrote:
>>> Another possibility: ordered dictionaries are not needed when Python
>>> 2.4 has the 'sorted' builtin.
Christoph Zwerschke wrote:
>> The 'sorted' function does not help in the case I have indicated,
>> where "
Fredrik Lundh wrote:
> (as an example, on my machine, using Foord's OrderedDict class
> on Zwerschke's example, creating the dictionary in the first place
> takes 5 times longer than the index approach, and accessing an
> item takes 3 times longer. you can in fact recreate the index 6
> times befo
Alex Martelli wrote:
> Note the plural in 'insertion orderS': some people care about the FIRST
> time a key was added to a dict, some about the LAST time it was added,
> some about the latest time it was 'first inserted' (added and wasn't
> already there) as long as it's never been deleted since t
Fredrik Lundh wrote:
> I'll repeat this one last time: for the use cases presented by Zwerschke
> and "bonono", using a list as the master data structure, and creating the
> dictionary on demand, is a lot faster than using a ready-made ordered
> dict implementation. if you will access things via t
Alex Martelli schrieb:
> Perl hashes now keep track of 'order of keys'? That's new to me, they
> sure didn't back when I used Perl!
Maybe I shouldn't have talked about Perl when I'm an ignoramus about
that language... You're right, Perl has unordered arrays. That was new
to me since I associate
Bengt Richter schrieb:
> Ok, so if not in the standard library, what is the problem? Can't find what
> you want with google and PyPI etc.? Or haven't really settled on what your
> _requirements_ are? That seems to be the primary problem people who complain
> with "why no sprollificator mode?" quest
Bengt Richter wrote:
> d = OrderedDict(); d[1]='one'; d[2]='two' =>> list(d) => [1, 2]
> ok, now we do d[1]='ein' and what is the order? list(d) => [2, 1] ??
> Or do replacements not count as "insertions"?
If you simply set a value for a key that already exists, the order
should not be change
Paulo Eduardo Neves schrieb:
> I want to run an optimized python using the portable /usr/bin/env, but
> the obvious ways aren't working.
Seems to be a Linux problems others also experienced:
http://blog.ianbicking.org/shebang.html
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-li
Alex Martelli wrote:
> Perl's _arrays_ are a bit like Python _lists_, and ordered; it's the
> _hashes_ that are a bit like Python _dicts_, and unordered. PHP's use
> of "array" for both concepts may indeed be a bit confusing.
Perl's _hashes_ have been also called _associative arrays_ original
Fuzzyman schrieb:
> Of course ours is ordered *and* orderable ! You can explicitly alter
> the sequence attribute to change the ordering.
What I actually wanted to say is that there may be a confusion between a
"sorted dictionary" (one where the keys are automatically sorted) and an
"ordered dic
Bengt Richter wrote:
> I'm mostly friendly ;-)
I'm pretty sure you are :-)
-- Chris
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
> After finally reading that the odict.py in PyPI by Larosa/Foord was what was
> desired,
> but slower in use than what Fredrik posted, I decided to see if I could speed
> up odict.py.
> I now have a version that I think may be generally faster.
Hm, I wouldn't formulate it t
One implementation detail that I think needs further consideration is in
which way to expose the keys and to mix in list methods for ordered
dictionaries.
In http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747
the keys are exposed via the keys() method which is bad. It should be a
co
Magnus Lycka schrieb:
>> I still believe that the concept of an "ordered dictionary" ("behave
>> like dict, only keep the order of the keys") is intuitive and doesn't
>> give you so much scope for ambiguity.
> Sure. Others think so too. The problem is that if you and these other
> people actual
>>def __init__(self, init_val = ()):
>> dict.__init__(self, init_val)
>> self.sequence = [x[0] for x in init_val]
Fuzzyman wrote:
> But that doesn't allow you to create an ordered dict from another
> ordered dict.
Right; I did not want to present a full implementation, just the
rel
Carsten Haese schrieb:
> I don't think it's intuitive if you can't describe it without
> contradicting yourself. If the order of the keys really were the order
> in which they were first seen by the dictionary, deleting and recreating
> a key should maintain its original position.
Admitted that de
Carsten Haese wrote:
> That could easily be fixed by making the sequence a "managed property"
> whose setter raises a ValueError if you try to set it to something
> that's not a permutation of what it was.
Ok, a managed attribute would be an option. You would allow people to do
what they want wi
>>I still believe that the concept of an "ordered dictionary" ("behave
>>like dict, only keep the order of the keys") is intuitive and doesn't
>>give you so much scope for ambiguity. But probably I need to work on an
>>implementation to become more clear about possible hidden subtleties.
Bengt
> d1[0:0] + d1[2:2] ==> OrderedDict( (1, 11), (3, 13) )
Oops, sorry, that was nonsense again. I meant
d1[0:1] + d1[1:2] ==> OrderedDict( (1, 11), (3, 13) )
> Ordered dictionaries could allow slicing and concatenation.
Some operations such as concatenation need of course special
considerations,
Steve Holden schrieb:
> Perhaps now the answer top your question is more obvious: there is by no
> means universal agreement on what an "ordered dictionary" should do.
> Given the ease with which Python allows you to implement your chosen
> functionality it would be presumptuous of the core deve
[EMAIL PROTECTED] schrieb:
> It seems to be though as "ordered dictionary" are slowly to be confined
> to only "ordered on order of change to the dictionary".
"Ordered dictionary" means that the keys are not an ordinary set like in
an ordinary dictionary, but an "ordered set." I think this defini
Bengt Richter wrote:
> I think the concept has converged to a replace-or-append-by-key ordering
> of key:value items with methods approximately like a dict. We're now
> into usability aspects such as syntactic sugar vs essential primitives,
> and default behaviour vs selectable modes, ISTM.
Ye
>>* C++ has a Map template in the STL which is ordered (a "Sorted
>>Associative Container").
Alex Martelli wrote:
> Ordered *by comparisons on keys*, NOT by order of insertion -- an
> utterly and completely different idea.
Shame on me. I talked so much about the difference between "ordered" and
Duncan Booth schrieb:
> In Javascript Object properties (often used as an associative array) are
> defined as unordered although as IE seems to always store them in the order
> of original insertion it wouldn't surprise me if there are a lot of
> websites depending on that behaviour.
You're rig
Alex Martelli wrote:
> However, since Christoph himself just misclassified C++'s std::map as
> "ordered" (it would be "sorted" in this new terminology he's now
> introducing), it seems obvious that the terminological confusion is
> rife. Many requests and offers in the past for "ordered dictionar
Ganesan Rajagopal wrote:
> the definition of "sorted" and "ordered", before we can > go on ? Sorted
> would be ordered by key comparison. Iterating over such a container will
> give you the keys in sorted order. Java calls this a SortedMap. See
> http://java.sun.com/j2se/1.4.2/docs/api/java/uti
Alex Martelli schrieb:
> I detest and abhor almost-sequences which can't be sliced (I consider
> that a defect of collections.deque). If the ordered dictionary records
> by its sequencing the time order of key insertion, being able to ask for
> "the last 5 keys entered" or "the first 3 keys enter
Bengt Richter wrote:
> >>> from odictb import OrderedDict
> >>> d1 = OrderedDict([(1, 11), (2, 12), (3, 13)])
> >>> d1
> {1: 11, 2: 12, 3: 13}
> >>> d1[1:]
> {2: 12, 3: 13}
> >>> d1[0:1] + d1[2:3]
> {1: 11, 3: 13}
> >>> d1.reverse()
> >>> d1
> {3: 13, 2: 12, 1: 11}
> >>> d1.insert(1, (
>> I think it would be probably the best to hide the keys list from the
>> public, but to provide list methods for reordering them (sorting,
>> slicing etc.).
Tom Anderson wrote:
> I'm not too keen on this - there is conceptually a list here, even if
> it's one with unusual constraints, so the
Fuzzyman wrote:
> So what do you want returned when you ask for d1[1] ? The member keyed
> by 1, or the item in position 1 ?
In case of conflict, the ordered dictionary should behave like a
dictionary, not like a list. So d1[1] should be the member keyed by 1,
not the item in position 1. Only i
Fuzzyman wrote:
>>- the internal keys list should be hidden
> I disagree. It is exposed so that you can manually change the order
> (e.g. to create a "sorted" dict, rather than one ordered by key
> insertion). What do you *gain* by hiding it ?
See my other posting. Of course hiding the list can
Fuzzyman wrote:
> That's not the only use case. Other use cases are to have a specific
> order, not based on entry time.
>
> Simple example :
> d1 = OrderedDict(some_dict.items())
> d1.sequence.sort()
> d1 is now an ordered dict with the keys in alphabetic order.
As I said, I would not need to a
Carsten Haese schrieb:
> Thus quoth the Zen of Python:
> "Explicit is better than implicit."
> "In the face of ambiguity, refuse the temptation to guess."
>
> With those in mind, since an odict behaves mostly like a dictionary, []
> should always refer to keys. An odict implementation that wants
Alan Kemp schrieb:
> I have a problem that is half python, half design. I have a
> multithreaded network server working, each client request spawns a new
> thread which deals with that client for as long as it is connected
> (think ftp style rather than http style connections here). Each thread
>
Ok, the answer is easy: For historical reasons - built-in sets exist
only since Python 2.4.
Anyway, I was thinking about whether it would be possible and desirable
to change the old behavior in future Python versions and let dict.keys()
and dict.values() both return sets instead of lists.
If d
Here is another old posting I just found which again gives the same use
cases and semantics:
http://mail.python.org/pipermail/python-dev/2005-March/051974.html
"Keys are iterated over in the order that they are added. Setting a
value using a key that compares equal to one already in the dict
rep
Duncan Booth schrieb:
> On IE this will go through elements in the order 0, 1, 2, 4, 3.
Oops! I bet most people would not expect that, and it is probably not
mentioned in most Javascript tutorials. I think this is a weakpoint of
the ECMA definition, not MSIE.
-- Christoph
--
http://mail.python
Fuzzyman schrieb:
> I'm going to add some of the sequence methods. I'm *not* going to allow
> indexing, but I will allow slicing.
>
> You can also do d[d.keys()[i]]
>
> This provides two ways of fetching values by index, so I don't want to
> add another.
And this would be probably faster than d
Mike Meyer wrote:
> Are you sure dict.values() should be a set? After all, values aren't
> guaranteed to be unique, so dict(a = 1, b = 1).values() currently
> returns [1, 1], but would return set([1]) under your proposal.
Good point. Contrary to the keys, the values are not unique. Still, it
woul
Martin v. Löwis schrieb:
> You answer the question whether it would be possible (no, because of
> backwards compatibility); you don't attempt to answer the question
> whether it would be desirable. Why do you think that would be
> a good idea?
It was meant simply as an open question to be discuss
> Martin v. Löwis wrote:
>> If you want the set of keys of a dictionary d, then do set(d):
>> >>> d={1:2,3:4}
>> >>> set(d)
>> set([1, 3])
>
> I know. But this does not answer the question: If the keys *are* already
> a set according to their semantics, why aren't they returned as a set
> fro
[EMAIL PROTECTED] schrieb:
> You can already get a set from a dictionary's keys in an efficient manner:
l = dict.fromkeys(range(10))
set(l)
> Set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
Good point. I expected that set(l) = set(l.items()) and not
set(l.keys()), but the latter would not work with m
Fuzzyman wrote:
> You will be able to mutate the the keys list through :
>
> d1 = OrderedDict(some_sequence_of_items)
> keys = d1.keys()
> keys.sort() # or other mutation
> d1.keys(keys)
>
> Admittedly this is a lot slower than :
>
> d1 = OrderedDict(some_sequence_of_items)
> d1.sequence.sort()
Bengt Richter schrieb:
>>d.setvalues((13, 14)) ==> d = OrderedDict((1, 13), (2, 14))
> The implication above is that OrderedDict takes an *args argument,
> but really it takes a single argument that is a sequence of k,v pairs,
> (and maybe some keyword options).
Right. Interpret it as a short no
Fuzzyman schrieb:
> d.keys() will still return a copy of the list, so d.keys()[i] will
> still be slower than d.sequence[i]
Right, I forgot that. Bengt suggested to implement __call__ as well as
__getitem__ and __setitem__ for keys, values and items.
In this case, you could very effectively acc
>>- Because sets can only contain immutable values
Mike Meyer wrote:
> Not true. Sets can only contain *hashable* objects, which isn't the
> same thing.
I trusted the doco which defines a set as "an unordered collection of
immutable values" (http://docs.python.org/lib/types-set.html).
Anyway,
Alex Martelli wrote:
> Absolutely not in my use cases. The typical reason I'm asking for
> .values() is because each value is a count (e.g. of how many time the
> key has occurred) and I want the total, so the typical idiom is
> sum(d.values()) -- getting a result set would be an utter disaster,
Mike Meyer schrieb:
> If the hash changes, you've screwed up the set. What it really should
> say is "collection of objects with fixed hashes", or words to that
> effect. Do you want to file a PR on this?
I fear I have not enough understanding of Python's hashing concepts to
make a suggestion fo
Alex Martelli wrote:
> An alternative theory, of course, is "God made the natural numbers; all
> else is the work of man" -- and that one is by a German, too (Kronecker,
> if I recall correctly).
Yes, it was Kronecker. But even natural numbers are usually constructed
with sets using Peano's axio
Mike Meyer wrote:
> Well, I just made a suggestion. You found the problem - you want to do
> the PR, or should I?
Please go ahead if you have the time. By the way, the doco may be also
inexact about the keys of dictionaries.
> # Untested code
> class Hash(object):
>def __new__(cls, obj):
Martin v. Löwis schrieb:
> Your original question was "could it be changed, and should it be
> changed?" As the answer to the first part is already "no", the
> second part really doesn't raise.
Right of course. The second part of the question was rather hypothetical
(in the sense of "if we co
Paul Rubin schrieb:
> Yes, it's not considered terribly troublesome. Set theory (and
> arithmetic) are generally accepted as being consistent but incomplete.
> So there will always be something for mathemeticians to do ;-).
Somehow I found this being comforting. Even in the realm of Mathematics
Martin v. Löwis wrote:
> It follows from what is documented. set() creates a
> set that contains all elements in the iterable object:
> http://docs.python.org/lib/built-in-funcs.html#l2h-63
> Now, is a dictionary an iterable object? Yes, it is:
> http://www.python.org/peps/pep-0234.html
> Together
Le ruego me perdone.
replace('haber', random.choice('tener', 'hacer', 'lograr'))
Mi espanol es peor que mi python.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] schrieb:
> And this, again from the doc(about mapping objects):
> A mapping object maps immutable values to arbitrary objects.
> Seems that is questionable too.
> a=(1,[])
> d={}
> d[a]=1
> again would give TypeError, list object are unhashable.
That's a good example showing tha
As a general note, I think it would be good to place the exact
description in a footnote, since speaking about hashable objects,
__hash__ and __cmp__ will certainly frighten off newbies and make it
hard to read even for experienced users. The main text may lie/simplyfy
a little bit.
Or as Dona
Fuzzyman wrote:
> That means making keys, values, and items custom objects.
> Creating a new instance would have the overhead of creating 4 new
> objects instead of just 1. Is the added convenience worth it ? (Plus
> the extra layers of method calls for each access).
I'm not sure about that eithe
Mike Meyer schrieb:
> Ok, how about this for dictionaries/sets:
>
> Any hashable object can be used as a dictionary key (set member). Immutable
> objects, except for tuples that contain a non-hashable object, are
> hashable. Python classes are normally hashable(1).
I would be even more simple he
Tom Anderson schrieb:
> Maybe we should call it a 'sequenced dictionary' to fit better with
> pythonic terminology?
That's not such a bad idea. Note that it is called like that in the
Python version of the "Programming Language Examples Alike Cookbook":
http://pleac.sourceforge.net/pleac_pytho
It seems everybody is in full agreement here.
I have the same mixed feeling about letting keys/values/items become
both managed list attributes and still returning copies of the lists
when called in the usual way as methods.
I don't know any precedent for doing things that way and i'm unsure
w
Tom Anderson wrote:
> True, but that's not exactly rocket science. I think the rules governing
> when your [] acts like a dict [] and when it acts like a list [] are
> vastly more complex than the name of one attribute.
I think it's not really rocket science either to assume that an ordered
di
Mike Meyer wrote:
> The mutability - or immutability - of an object is irrelevant to
> the question of whether or not they can be a dictionary key/set
> element. The critical property is that they are hashable.
> *Most* immutable builtin types are hashable, and no builtin
> mutable types are
Mike Meyer wrote:
> Ok, how about this for dictionaries/sets:
>
> Any hashable object can be used as a dictionary key (set member). Immutable
> objects, except for tuples that contain a non-hashable object, are
> hashable. Python classes are normally hashable(1).
The problem with the last senten
Mike Meyer wrote:
> I think you're trying to tweak the wrong definition. Types are
> immutable if their instances are immutable.
I'm not trying to tweak it, but to gain more clarity about what is
actually meant when you talk about "mutable" types and objects and
whether it suffices to use the
>>> class mylist1(list):
>>> def __hash__(self): return 0815
>>>
>>> class mylist2(list):
>>> def __hash__(self): return id(self)
>>>
>>> Which of these user-defined types would you call "hashable"?
> Mike Meyer wrote:
>> The latter two, as the given __hash__ meets the specifications for
Martin v. Löwis schrieb:
>> As Mike has written in his last posting, you could easily "fix" that
>> by tweaking the equality relation as well. So technically speaking,
>> Mike is probably right.
>
> No. If you define both __hash__ and __eq__ consistently, then __hash__
> would meet the specific
Bengt Richter wrote:
>>d.keys[:] = newkeyseq
>
> Do you really mean just re-ordering the keys without a corresponding reording
> of values??
> That would be a weird renaming of all values. Or do you means that any key
> should still
> retrieve the same value as before if used as d[key]? In whic
Christoph Zwerschke wrote:
> I will assume that d has is a Foord/Larosa ordered dict with "sequence"
> attribute in the following.
>
> Then, with other words,
>
> d.keys[:] = newkeyseq
>
> should do the same as:
>
> d.sequence = newkeyseq
A
Bengt Richter schrieb:
> OTOH,
> >>> {}[:]
> Traceback (most recent call last):
>File "", line 1, in ?
> TypeError: unhashable type
> I.e., slices are not valid keys for ordinary dicts, and slices tie in
> very well with the ordered aspect of ordered dicts, so that's an
> argument for permi
Martin v. Löwis wrote:
> I long forgot was the original question was (I thought it was
> "Why is dictionary.keys() a list and not a set?" :-)
Er, yes. Probably we should have opened a new thread instead:
"Improvement of the std lib doc concerning keys of sets/dicts".
-- Christoph
--
http://mai
Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.
For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?
>>Let me ask back: Do I really need to bother and justify it with a use
>>case in a case where the language can be easily made more consistent or
>>orthogonal without breaking anything?
Robert Kern wrote:
> Yes. If it's not going to be used, then there's not much point.
> Practicality beats pur
>>For instance, I just wanted to use the index() method on a tuple which
>>does not work. ...
Aahz wrote:
> Because Guido believes that tuples should be primarily used as
> lightweight replacements for C structs. Therefore they have minimal
> functionality.
But the problem is that the tutorial
Mike Meyer wrote:
> Any object for which hash() returns an appropriate value(1) can be
> used as a dictionary key/set element. Lists, sets and dicts are not
> hashable, and can not be used. Tuples can be used if all the things
> they contain are hashable. instances of all other builin types can be
Fredrik Lundh schrieb:
> Christoph Zwerschke wrote:
>>But the problem is that the tutorials and manuals give the impression
>>that the difference between lists and tuples is only mutablity versus
>>immutability.
>
> both the tutorial and the FAQ discusses the difference
Aahz wrote:
>Christoph wrote:
>>Aahz wrote:
>>>Christoph wrote:
For instance, I just wanted to use the index() method on a tuple which
does not work. ...
>>>
>>>Because Guido believes that tuples should be primarily used as
>>>lightweight replacements for C structs. Therefore they have mi
Fredrik Lundh schrieb:
> Christoph Zwerschke wrote:
>
>>What about design goals such as:
>>
>>- orthogonality
>>- coherence, consistency
>>- principle of least astonishment ("Python fits my brain")
>>- simplicity ("kiss" principle)
&
Mike Meyer wrote:
> Christoph Zwerschke wrote:
>>I think that is not so bad. How about this simplification:
>>
>>Any hashable object(1) can be used as a dictionary key/set
>>element. Lists, sets and dicts are not hashable, and can not be
>>used. Tuples can be us
Fuzzyman wrote:
> Sorry for this hurried message - I've done a new implementation of out
> ordered dict. This comes out of the discussion on this newsgroup (see
> blog entry for link to archive of discussion).
Thanks. I'll try to check it out and put my oar in over the next
weekend. One thing I a
Peter Hansen schrieb:
> Christoph Zwerschke wrote:
>
>> Ok, these are nice aphorisms with some truth. But I had to think of
>> the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein
>> Genie überblickt das Chaos." ("Those who try to keep thin
Christoph Zwerschke wrote:
> there should be comma after "ist",
Sorry, *before* "ist". I should probably stop posting for today...
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Mike Meyer wrote:
> Christoph Zwerschke wrote:
>>A programming language is not a "work of art". If you are an artist,
>>you may break symmetry and introduce all kinds of unexpected
>>effects. Actually, as an artist, you purposfully want to provoke
>>astonish
Fredrik Lundh wrote:
> on the other hand, it's also possible that there are perfectly usable ways
> to keep bikes and bike seats dry where Christoph works, but that he prefers
> not to use them because they're violating some design rule.
Depends on how you understand "perfectly usable." My collegu
I had the same idea to create a py.test to verify and compare various
implementations. The doctests in odict.py are nice, but you can't use
them for this purpose and they may not test enough. It would be also
good to have something for testing and comparing performance.
-- Christoph
--
http://
[EMAIL PROTECTED] wrote:
> Paul Rubin wrote:
>>Look at the list.count() example at the start of this thread.
>>Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat
>>Python by an order of magnitude. A suitably factored implementation
>>might handle lists and strings with the exact sa
Donn Cave schrieb:
> As I'm sure everyone still reading has already heard, the natural usage
> of a tuple is as a heterogenous sequence. I would like to explain this
> using the concept of an "application type", by which I mean the set of
> values that would be valid when applied to a particular c
I think this all boils down to the following:
* In their most frequent use case where tuples are used as lightweight
data structures keeping together heterogenous values (values with
different types or meanings), index() and count() do not make much sense.
I completely agree that his is the mos
Chris Mellon schrieb:
> First, remember that while your idea is obvious and practical and
> straightforward to you, everybodys crummy idea is like that to them.
> And while I'm not saying your idea is crummy, bear in mind that not
> everyone is sharing your viewpoint.
That's completely ok. What I
Fredrik Lundh wrote:
> Christoph Zwerschke wrote:
> now, I'm no expert on data structures for chess games, but I find it hard to
> believe that any chess game implementer would use a data structure that re-
> quires linear searches for everything...
Using linear arrays to repre
Steve Holden wrote:
> Christoph Zwerschke wrote:
>> I completely agree that his is the most frequent case. Still there are
>> cases where tuples are used to keep homogenous values together (for
>> instance, RGB values, points in space, rows of a matrix). In these
Fredrik Lundh wrote:
>>>Christoph Zwerschke wrote:
>>Using linear arrays to represent chess boards is pretty common in
>>computer chess. Often, the array is made larger than 64 elements to make
>>sure moves do not go off the board but hit unbeatable pseudo pieces
>>
1 - 100 of 264 matches
Mail list logo
