[Python-ideas] The stdlib++ user experience

[Paul Moore]

On 19 September 2014 13:15, Akira Li <4kir4.1i at gmail.com> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:

>> 3. C extensions aren't a huge problem to me on Windows, although I'm
>> looking forward to the day when everyone distributes wheels (wheel
>> convert is good enough for now though). [1]
>
> I have the opposite impression.
> http://pythonforengineers.com/stop-struggling-with-python-on-windows/

Well yes, but that article is clearly focused on scientific use (a
known "worst case" area) and ends up recommending conda (which is a
perfectly fair solution, and as the author states, works well).

My comment was a bit unfair, though. I have a C compiler installed
(which, although it's not hard to set up VS Express, isn't normal).
And I also treat "find a wininst installer or egg and run wheel
convert on it" as trivial and acceptable, which it isn't for people
who aren't packaging specialists.

But we're working on this, and I stand by the statement that when
projects routinely distribute wheels if they include C extensions,
binary dependencies will be a minor issue.

>> PS I should also note that even in its current state, PyPI is streets
>> ahead of the 3rd party module story I've experienced for any other
>> language - C/C++, Lua, Powershell, and Java are all far worse.
>> Perl/CPAN may be as good or better, it's so long since I used Perl
>> that I don't really know these days.
>
> Opinions may vary:
> http://www.reddit.com/r/Python/comments/1ew4l5/im_giving_a_demo_of_python_to_a_bunch_of_java/

The discussion here is about packaging, not about finding 3rd party
packages to solve a problem. I know of no better way to find a package
to parse an ini file in Java than google, which is no better than
Python. And what I found was packages on sourceforge and other generic
hosting sites.

Maven may be a central repository - I've never used it myself as the
complexity has always scared me off (you could say that about most of
Java, though ;-))

> Or: "The artifact approach is unambiguously better for any production
> deployment. The source-based approach found in Ruby, Perl, and Python is
> a problem for me more often than a solution."
> https://news.ycombinator.com/item?id=7070464

Again, that's deployment rather than discovery.

Paul