[Python-Dev] hello, new dict addition for new eve ?

2011-12-30 Thread julien tayon
Hello,
Sorry to annoy the very busy core devs :) out of the blue

I quite noticed people were
1) wanting to have a new dict for Xmas
2) strongly resenting dict addition.

Even though I am not a good developper, I have come to a definition of
addition that would follow algebraic rules, and not something of a
dutch logic. (it is a jest, not a troll)

I propose the following code to validate my point of view regarding
the dictionnatry addition as a proof of concept :
https://github.com/jul/ADictAdd_iction/blob/master/test.py

It follows all my dusty math books regarding addition + it has the
amability to have rules of conservation.

I pretty much see a real advantage in this behaviour in functional
programming (map/reduce). (see the demonstrate.py), and it has a sense
(if dict can be seen has vectors).

I have been told to be a troll, but I am pretty serious.

Since, I coded with luck, no internet, intuition, and a complete
ignorance of the real meaning of the magic methods most of the time,
thus the actual implementation of the addition surely needs a complete
refactoring.

Sheers,
Bonne fĂȘtes
Julien
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Code reviews

2012-01-02 Thread julien tayon
@francis
Like indent ?
http://www.linuxmanpages.com/man1/indent.1.php

@brian
> I don't think this is a problem to the point that it needs to be fixed
> via automation. The code I write is the code I build and test, so I'd
> rather not have some script that goes in and modifies it to some
> accepted format, then have to go through the build/test dance again.


Well, it breaks committing since it adds non significative symbols,
therefore bloats the diffs.
But as far as I am concerned for using it a long time ago, it did not
break anything, it was pretty reliable.

my 2c * 0.1
-- 
jul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-14 Thread julien tayon
Hello,

2012/3/13 Guido van Rossum :
> On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin  wrote:
>> Downloads don't mean the code is good. Voting is gamed. I really don't
>> think there's a good automated solution to tell us what the
>> high-quality replacement projects are.
>
> Sure, these are imperfect metrics. But not having any metrics at all
> is flawed too. Despite the huge flamewar we had 1-2 years ago about
> PyPI comments, I think we should follow the lead of the many app
> stores that pop up on the web -- users will recognize the pattern and
> will tune their skepticism sensors as needed.
>

unittest and functional testing are obctive metrics.

It it passes a unittest, and it has the same API, therefore it is a
legitimate replacement for the stdlib. If a benchmark is also given
that can be considered **not biased** and faster it is pretty neat.
(but why not contribute to stdlib then?)

Functional testing is however a little more tricky, subjective and
interesting. Since stdlib replacements are mostl functionnaly
equivalent (like requests) of one or more stdlib module and that is
what people are searching for.
People willing to be considered compliant with some functionalities of
a stdlib would have to give example of porting from libA to libB plus
the given *functionnal tests*.

An interesting point may also be PEP compliance. (it is sometimes a
tedious tasks when playing with SA to know if a python package of a
DBDriver is DB-API 2.0 compliant).

This would make pypi even greater if package maintainers added these
metadata (implements, functions_like, pep_compliance) in their
setup.py given they comply with the logic. And it would pretty much
automate the search for alternative to stdlib.

The huge problem is how to trust that maintainers are self disciplined
enough, willing,  and have enough knowledge to tag their packages
properly, plus what is the extra strain on code and infrastructure to
automate this ?

Without these informations we may become like senior java developpers
whose greatests skills are not coding, but knowing in a wide
ecosystems of packages which one are
revelant/reliable/compatible/stable. (needle in a haystack)

Maybe the answer is not one of code but one of trend setting and Noise
Signal Ratio on python hubs. (http://www.pythonmeme.com/,
http://planet.python.org/, http://pypi.org (and still in a lesser way
of classification)).



Cheers,
-- 
Julien Tayon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com