[Python-ideas] stdlib crowdsourcing
ironfroggy at gmail.com
Sat Jun 2 19:24:05 CEST 2012
On Fri, Jun 1, 2012 at 11:08 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, May 29, 2012 at 9:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Once again, you're completely ignoring all existing knowledge and
>> expertise on open collaboration and trying to reinvent the world. It's
>> *not going to happen*.
> It's too boring to live in a world of existing knowledge and
Frankly, this one fragment is enough to stop me reading further. Who
wants to learn
from the vast and broad experience when you could simply randomize the rules of
reality through ignorance and stubbornness?
I sound fickle, because I am.
> and yes, I am not aware of any open collaboration stuff
> expertise. Any reading recommendations with concentrated knowledge
> that can fit my brain?
>> The standard library is just the curated core, and *yes*, it's damn
>> hard to get anything added to it (deliberately so). There's a place
>> where anyone can post anything they want, and see if others find it
>> useful: PyPI.
> The major drawbacks of remote packages in general is that it bring
> back project compilation from the old days. The biggest Python
> advantage at all times was "copy and run" ability.
> The drawbacks of PyPI for this proposal are:
> 1. every function you need will require a separate upload to PyPI
> 2. you can't upload function with the same stdlib name, but slightly
> different implementation as it is used in different projects
> 3. you can't find functions that people recommend to be included into stdlib
> 4. it is hard (impossible) to gather feedback on the quality of these proposals
>> The standard library provides tools to upload to PyPI, and, as of 3.3,
>> will even include tools to download and install from it.
> I am glad 3.3 is giving virtualenv and bootstrap stuff. It would
> really rock, if the new feature won't be settled in stone right after
> release and will gain a few UX iterations with allowed break-ability.
> As for PyPI, the major drawback of it is security - DNS attack for a
> couple of minutes, and one of your automatically deployed nodes is
> trojan ready. I remember PyPI password are stored in clear-text on
> developer's machine, but I don't remember if anyone turned off HTTP
> basic authorization on PyPI to protect passwords travelling to PyPI
> with every upload from intercepting. It would be an interesting
> exercise to sniff PyPI passwords over WiFi during next conference
> (i.e. https://ep2012.europython.eu/) and match those to the
> developer's accounts on *.python.org ;)
>> If you don't like our ecosystem (it's hard to tell whether or not you
>> do: everything you post is about how utterly awful and unusable
>> everything is, yet you're still here years later).
> You're absolutely right - I like the Python ecosystem, otherwise I
> wouldn't stick there. It is like a vintage car - awesome, nice
> looking, and there is even this new twisted pyusion engine inside,
> but.. well - it's not for youngsters.
>> If you think the PyPI UI is awful or inadequate, follow the example of
>> crate.io or pythonpackage.com and *create your own*. There's far more
>> to the Python universe than just core development, stop trying to
>> shoehorn everything into a place where it doesn't belong.
> I have absolutely no idea how aforementioned post touches PyPI UI.
> Speaking about PyPI enhancements and ecosystem, instead of reinventing
> bicycles I'd rather patch existing one. The only problem is that
> patches are not accepted.
> Python-ideas mailing list
> Python-ideas at python.org
Read my blog! I depend on your acceptance of my opinion! I am interesting!
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
More information about the Python-ideas