I had tough time finding a connection to internet :)
@Arnaud + Terry
Thx, code corrected to have the right terminology.
at least my code really test for the good rules :)
But being precise matter, so that I changed all the terms to fit in.
<< is a symbol indicating an asymetry for left and right value, and I
carefully tried to have a symetrical behaviour with left & right :
associativity, distribution, commutativity.
The whole point about using a symbol, is that it follow rules.
That is the reason why consistent_addition class is all about testing
linear algebraic rules (hopefully the right way, and now, I hope with
the right terminology).
But I have reason to think that there are more than way to do
addition. Linear algebrae is the most used and intuitive one for non
developer, and developer think of sets operations as more intuitive.
I guess, it all come down to one point. Which is what is a dict as a
mathematical object. If there is more than one choice, which has the
most benefits. Should there be more than one definition ?
@Guido & Eric
In my book there are rules for sets.
The question is a dict the same as a vector or as a set ?
since sets are using logical operators for operations that are roughly
sets operations why not use & ^ | for sets operation on dict ?
it would be pretty consistent with sets operations.
( @jakkob )
In this case I would expect inconsistencies error when doing
dict( a = 1 ) | dict( a = 2 , b = 2 ) (thus key-> value are seen like
an atomic element of the set, unless a "value collision" operator is
given, and this collision operator would recursively and naturely
apply to the descendants)
because I expect both a | b == b | a and a + b = b + a
The problem would be indeed
list + list
vectorish behaviour is my prefered of course.
but if we shift the record algebrae addition to another symbol (let's
assume << ) we resolve the conflict. But then we have a problem of
We then may be tempted to use & | ^ (since it would be used for dict)
and then we have a problem :
should [ 1 , 2 ] & [ 3 , 2 ] mean set addition or applying & to all
the element of the same rank ?
I'm pretty stucked myself in trying to be consistent.
Just for the record, why dit you not use "." (dot) for concatenation ?
I know it is typographically unreadable on a messy screen, but is
there a better reason ?
@terry & Nathan Regarding Counter.
you may notice that I do have all the property of counter, but counter
does not as -this dict- aggregate values and (sub) totals at the same
It is very convenient for map reduce since it does some re-reduce
operations at reduce time. smart, no ? <:o)
Sorry for making assertive and carefree statements regarding strong
resentment. My bad.
truth is aim at similarity cosinus for dict, and I imagine a map
reduce on dict representing values of a model you want ideal = dict(
blue = 1 , height = 180, weight = 70, wage = 500 )
in the filter before the map reduce you would want to filter all
records close to this one by using similarity cosinus in this way :
filter( lambda model : cos( ideal, model) > .7 , all_model )
of course I will try to advocate dot product, and metrics.
As a result my real goal is to make people consider dict as vectors of
path to value => value not sets of key => value
To solve issues such as weighted decisions and non linear choices
(based on trigger or a value belonging to a set) I can fairly easily
concevie a projector (which would be a class transforming a vector in
a vector, but not with a a matrix, but with computed rules ).
+1 are you telepath ?
Yes a key collision operator would be nice :
given for instance an apache log, I will have segments of path, and I
may want keys to be the accumulated graph of a user on a website. so
my collision rule might be :
(key being the referer value the page visited afterwards)
dict( a = b, a = c ) + dict( b = e ) = dict( a = dict( b = e ), a = c)
I thought of it, but I really loved the conservation rule. And I
feared people would think of it as too complicated. Keep It Simple I
Wrapping everything to logicial sense.
I was thinking of supersets of object (thus out of the stdlib) that
would have different algebrae and could be used as casts on object to
redifine + - * / cos & | ^
and for different objects would behave consistently ex :
vector( dict ) vector( list ) vector( string )
would make dict & list & string behave like vectors thus mainly
supporting elementwise operations
sets( dict ) , sets( string ) ...
would make dict string be sets of elements ... (with the original dict
addition design of GvR et al)
Each superset would have a unit test for the operation verifying that
behaviour is consistent. (associativity, distributivity, ...) what
about this solution ?
On Wed, Jan 4, 2012 at 4:34 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On Wed, Jan 4, 2012 at 1:47 AM, anatoly techtonik <techtonik(a)gmail.com>
> > Before attempting any library refactoring or addition, I would first
> > about placing a feedback mechanism in place to collect public response
> > satisfaction with current stdlib contents, and collecting proposals about
> > parts that should be included into stdlib (or another bundle shipped with
> > Python).
> Sorry anatoly, you're not going to win that one. We're well aware you
> don't like the use of mailing lists, the issue tracker, IRC, blogs,
> Reddit, Hacker News, Stack Overflow, etc for feedback and want
> something else that is formal and structured, but isn't the issue
> tracker (since you object to that for reasons I don't really
I want something that will accumulate and summarize the outcome of all
these informal activities in a structured way. With a tight time limits it
is impossible to read and follow all discussions, so there should be an
easy way to say +1 or -1 to filter useful stuff. There is nothing wrong
with Reddit, Stack Overflow and etc., except that it is very hard to figure
out trends in Python development.
Without visible trends (or Roadmap FWIW) - you can't see what is going to
be changed and how can you help (in accordance with your own skills and
motivations). Even if you don't want to (or can't) help, you at least want
to place your +1, -1 and see what other people think is right or wrong
about Python. At least you will learn something new that will help to
change things you've become aware of in the future.
If you want to set up your own feedback mechanism,
> encourage people to use it, and act as a conduit between your new
> mechanism and the channels the current core devs are already paying
> attention to, feel free.
If only I could finish anything alone..