Fred L. Drake, Jr. wrote:
> (the "Python Package Index" says exactly what it is
fwiw, "package index" is the name used on the python.org home page.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-30
On Tuesday 17 October 2006 01:48, Greg Ewing wrote:
> Well, I don't think it's any worse than CPAN, which
> doesn't mean anything unless you already know what
The fact that it doesn't mean anything could just as easily be a point in
favor; it isn't anything else, either.
> As to the alternati
Talin wrote:
> Greg Ewing wrote:
>
>>I've been trying to
>>make something out of SPAM -- Superlative Python
>>Archive of Modules?
>
> Good luck getting that one through people's email filters :)
Well, I figure that real spam isn't going to announce
itself as such, so we should be all right. Besi
Greg Ewing wrote:
> Anyone have any other ideas? I've been trying to
> make something out of SPAM -- Superlative Python
> Archive of Modules?
Good luck getting that one through people's email filters :)
Cheeseshop may be overly cute, however it has at least this mnemonic
benefit is that it sugge
Fred L. Drake, Jr. wrote:
> The "Cheese Shop" name may reflect the
> proper cultural bias toward Monty Python, but it's a sure way to alienate
> people by presenting the hard work of the community under a completely silly
> name that communicates nothing about what it's about.
Well, I don't thi
Martin v. Löwis wrote:
> One would have to study it in more detail. What
> is the processing need of a Pyrex file?
Pretty simple -- just pass the .pyx file through
the Pyrex compiler, then do whatever you would
normally do to the resulting .c file to turn it
into an extension module.
A refinement
Ka-Ping Yee wrote:
> On Mon, 16 Oct 2006, Talin wrote:
>> Agreed - I don't have any problems with Cheeseshop as it exists today.
>
> I think a good search feature is essential -- a big code repository
> is only as useful to the degree that its contents are accessible.
>
> I don't want to hurt any
On Monday 16 October 2006 21:06, Bob Ippolito wrote:
> However I think that many (most?) links on the web have started to
> migrate to http://cheeseshop.python.org/pypi
Which is really, really, REALLY sad. The "Cheese Shop" name may reflect the
proper cultural bias toward Monty Python, but it'
On 10/16/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Oct 2006, Talin wrote:
> > Agreed - I don't have any problems with Cheeseshop as it exists today.
>
> I think a good search feature is essential -- a big code repository
> is only as useful to the degree that its contents are accessib
On Mon, 16 Oct 2006, Talin wrote:
> Agreed - I don't have any problems with Cheeseshop as it exists today.
I think a good search feature is essential -- a big code repository
is only as useful to the degree that its contents are accessible.
I don't want to hurt anyone's feelings, but i think the
Josiah Carlson schrieb:
> In my own experience, I have found that with the packages I usually end
> up having to ship (source files with related data), sdist is the only
> distutils command that gets it right. Any of the bdist commands bork
> the Windows (.msi) Python installation (data files go i
Martin v. Löwis wrote:
> Ivan Krstić schrieb:
>> 1) Having a large, canonical repository of useful Python code that's
>> much more encompassing than Cheeseshop would be a good thing for Python.
>
> It's probably due to deficiencies in my mastering of the English
> language: What do you mean by "en
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The only realistic chance for that to happen is to make the distutils
> less arcane and better.
I've been staying out of the discussion, but I'll toss in a hearty +1 in
support of making distutils "less arcane and better".
In my own experience, I ha
Ivan Krstić schrieb:
> 1) Having a large, canonical repository of useful Python code that's
> much more encompassing than Cheeseshop would be a good thing for Python.
It's probably due to deficiencies in my mastering of the English
language: What do you mean by "encompassing" here?
If you are req
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Marcin 'Qrczak' Kowalczyk schrieb:
>> It is true that it can change the interpretation of file contents.
>> This is unavoidable. Unless someone uses unpaired surrogates for this
>> purpose (or code points above U+10) - I've seen such proposals,
>
On 10/16/06, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > I hope Python won't copy CPAN literally. Every time I used it, it was
> > a big pain, and I happily stopped using it when everything I needed
> > came as a Debian package.
>
> Note my emphasis on `culturally` in the pr
Martin v. Löwis wrote:
> I hope Python won't copy CPAN literally. Every time I used it, it was
> a big pain, and I happily stopped using it when everything I needed
> came as a Debian package.
Note my emphasis on `culturally` in the previous mail. CPAN's largest
value isn't as a package management
Phillip J. Eby wrote:
> I was actually referring to the standardization of the *layout* of the
> contents of a package, and standardization on the interface for
> performing build, install, and test steps.
Right, sorry, I'm running in awake-for-40-hours mode so I didn't
explicitly connect my thoug
Ivan Krstić schrieb:
> I don't think there's much of a 'may' about it. I've often wondered why
> non-Perl languages haven't been able to -- culturally -- create their
> own version of CPAN, and failing that, why they haven't copied CPAN
> outright.
>
> The Perl world has pretty much standardized o
Aahz wrote:
> On Mon, Oct 16, 2006, "Martin v. L?wis" wrote:
>> Greg Ewing schrieb:
>>> Unless the basic structure is so far from what's needed that it can't
>>> be reasonably fixed.
>> See, and I believe this isn't the case for distutils.
>
> Can you suggest a good mechanism for resolving the dea
At 01:02 PM 10/16/2006 -0400, Ivan KrstiÄ wrote:
>Phillip J. Eby wrote:
> > I think that Perl may actually have us beat in terms of having "one
> > way to do it" with respect to package layout, for example.
>
>I don't think there's much of a 'may' about it. I've often wondered why
>non-Perl langua
Phillip J. Eby wrote:
> I think that Perl may actually have us beat in terms of having "one
> way to do it" with respect to package layout, for example.
I don't think there's much of a 'may' about it. I've often wondered why
non-Perl languages haven't been able to -- culturally -- create their
o
At 06:21 PM 10/16/2006 +0200, Martin v. Löwis wrote:
>Ronald Oussoren schrieb:
> >> And indeed, distutils already has support for that:
> >> distutils.dep_util offers a couple of routines that
> >> do time-stamp checking.
> >
> > This points to at least part of the problem: there is very little use
Ronald Oussoren schrieb:
>> And indeed, distutils already has support for that:
>> distutils.dep_util offers a couple of routines that
>> do time-stamp checking.
>
> This points to at least part of the problem: there is very little useful
> documentation on how to extend, or even use, distutils.
On Mon, Oct 16, 2006, "Martin v. L?wis" wrote:
> Greg Ewing schrieb:
>>
>> Unless the basic structure is so far from what's needed that it can't
>> be reasonably fixed.
>
> See, and I believe this isn't the case for distutils.
Can you suggest a good mechanism for resolving the deadlock? We have
25 matches
Mail list logo
