Re: [Python-Dev] Update to Python Documentation Website Request
2009/7/25 David Lyon : >> It would, in fact, be best to work with the team performing ongoing >> active standardisation of distutils functionality. > > I am already doing that. > > But there is a bias against windows development and a bias > against native applications. That's fine because I know they > are using python on different platforms. ??? I see no bias as you describe in the distutils enhancement work. Everything so far has been carefully platform-neutral (ie, *not* biased against Windows, but equally not biased against other operating systems). Native applications are by definition not platform neutral. How does your proposal help Linux users? Mac OS? Solaris? I think you are seeing bias against Windows where non exists. What *does* exist is - A concern that tools work for everyone, regardless of OS - A limited number of people willing to explain Windows issues so that they get considered > I'm working on a proposal to make setup.py object oriented > and "modern". > > http://wiki.python.org/moin/Distutils/Proposals And that looks interesting, and potentially useful (although perhaps more radical than will end up being possible). > So I'm doing as much as I can - really. If your concern is to make things easier for Windows users, then your application is worthwhile, but it should probably remain an external project. If it gets overwhelming support, maybe providing a standardised version with a simplified UI in the core would be an option. How many users do you have currently? Paul. PS Does your application work with the large existing base of bdist_msi and bdist_wininst installers? Unless it will manage pywin32, cx_Oracle, PIL, wxPython, pyQT, pygame, numpy etc (all of which are available in binary form but not as eggs as far as I know, and have too complex a set of dependencies for me to build locally) it's useless to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
> It's my intention to get a Package Manager included in standard > python - yes. In addition to the other constraints you'll have to meet for this to happen, you also have to wait a rather long time (several years) before inclusion becomes possible. This time is necessary for the community to accept your tool, and evaluate it. Ideally, the request for inclusion should not come from you, but from your users. > Not at all. In source form the pythonpkgmgr requires wx package. In > executable form it does not. If we include it, we *only* include it in source form. Inclusion in executable form is not acceptable. We also require that it works on all major systems, not just windows. >> No, it's a bias against adding things to Python that depend on things >> not already in Python. > > That implies that nothing new can be added then. No. It implies that any addition could only depend on Python (and OS API) - so things *can* be added. For example, setuptools could be added by this principle. OTOH, if your tool depends on setuptools, you'll have to wait for setuptools to get included before inclusion of your tool can be considered. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting HTTPS via Proxy Support in urllib2
> This is fixed in the trunk (Revision 72880), but there has been number > of valid requests to backport it Python 2.6. While I agree and ready > to backport to Python 2.6, I would like to ask here if there are any > objections in this front. In msg76855 Greg ruled that it is a new feature, and thus cannot be backported. I trust his judgement - so to convince me, you would need to convince Greg first :-) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
> To Martin: So I disagree. The gc header is not responsible for > alignment in the first place, but to propagate it, correctly. I think we are in agreement in this respect. That's the whole point of the long double: to make the gc head's alignment the maximum alignment on that platform > And this fails miserably (in principle) since years. Here I agree. In principle, it works fine - it is just perhaps incomplete. > Proposal: We should use a simple construct that makes the > gc header size simply a multiple of 8 or 16, whatever needed. > Even a byte array would be ok. How would you implement that? In particular, how do you determine what is needed? > But please no long double :-) Well, the long double needs to stay, as for some platforms, long double is indeed the type with the maximum alignment. I propose to add another (regular) double into the union. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
>> This may not be recognized so far, because there is no builtin >> GC-enabled type that embeds a double. >> But if you create such a type, then the double will be correctly >> aligned in your object's structure, but then, when the object >> gets allocated, it is misaligned, because the header size is not a >> multiple of 8. > > I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 > CPU. That's not really the point. The question is whether the double is misaligned wrt. the compiler's ABI. The compiler (or the operating system) specifies the alignment for all primitive types, and guarantees that everything is properly aligned. > Alignment is primarily important to avoid access violations on CPUs and > datatypes which don't support arbitrary alignment, although it can also be > useful for performance reasons. Alignment may also have propagated into other aspects. For example, if you have double foo; intptr_t bar = (intptr_t)&foo; then it may be guaranteed (by the ABI) that bar&7 == 0. So we really need to keep all promises wrt. alignment intact. > In any case, you seem to be right on this particular point: the PyGC_Head > union > should probably contain a "double" alternative in addition to the "long > double" > (and perhaps even a "long long" one). I agree. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
> Antoine Pitrou pitrou.net> writes: >> In any case, you seem to be right on this particular point: the PyGC_Head >> union >> should probably contain a "double" alternative in addition to the "long >> double" >> (and perhaps even a "long long" one). > > Sorry, I realize that this doesn't really address the point. I don't realize that. Why is your first proposal bad? > In addition to that union, we should also have a particular mechanism to > compute > what the proper offset should be between the PyGC_Head and the PyObject. Why is that difficult? It's sizeof(PyGC_Head). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
> For that reason, I don't like the addition of the opaque header > too much. If there were an option to make the header explicit, > we would not have to round up the object size to a multiple > of (8, 16), but could arrange embedded doubles as they fit the best. We could add the gc head *after* the object head. However, this will require manual changes to all types that support GC, so we can't do that before Python 4. >> (I disagree, however, that we should remove the "long double". After >> all, we >> also want alignment of PyObjects to allow inclusion of a "long double" >> in them) > > Well, I doubt that a 12 byte long double causes any other > alignment but 4. What you apparently fail to understand is this: On some platforms, sizeof(long double) == 16, and alignof(long double) == 16. It is these platforms why we need to keep the long double. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Martin v. Löwis v.loewis.de> writes: > > > In addition to that union, we should also have a particular mechanism to compute > > what the proper offset should be between the PyGC_Head and the PyObject. > > Why is that difficult? It's sizeof(PyGC_Head). Is it enough to correctly propagate the alignment for, say, a long double in the following PyObject? I'm sorry, I'm not enough of a C lawyer. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 16:00:13 +1000, Ben Finney wrote: > I think you know quite well what “depend on” means in this instance, > so this is taking it to silly extremes. haha - yes - no offence. It was just bad humour. Have a nice weekend David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 10:28:51 +0100, Paul Moore wrote: > ??? I see no bias as you describe in the distutils enhancement work. ok > Native applications are by definition not platform neutral. How does > your proposal help Linux users? Mac OS? Solaris? I'm doing a Linux/Solaris version. But I find issues every day that must be addressed. > If your concern is to make things easier for Windows users, then your > application is worthwhile, but it should probably remain an external > project. If it gets overwhelming support, maybe providing a > standardised version with a simplified UI in the core would be an > option. That sounds ok. > How many users do you have currently? Approx 250 downloads this (first) month for the windows version. I need to extend coverage to Linux and the Mac. Given that I'm relatively new to all this there's a learning curve. But so far so good. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Martin v. Löwis:
> I propose to add another (regular) double into the union.
Adding a regular double as a second dummy gives the same sizes and
alignments with Mingw or MSVC as the original definition with MSVC:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
double dummy2; /* in case long double doesn't trigger worst-case */
} PyGC_Head;
In regard to alignment penalties, a simple copy loop for doubles
runs about 20% slower when misaligned on an my AMD processor. Other
x86 processors can be much worse. As much as 2 to 3.25 times according
to
http://msdn.microsoft.com/en-us/library/aa290049%28VS.71%29.aspx
Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Neil Hodgson gmail.com> writes:
>
> typedef union _gc_head {
>struct {
>union _gc_head *gc_next;
>union _gc_head *gc_prev;
>Py_ssize_t gc_refs;
>} gc;
>long double dummy; /* force worst-case alignment */
>double dummy2; /* in case long double doesn't trigger worst-case */
> } PyGC_Head;
We could add a PY_LONG_LONG to the mix just in case.
By the way, will this kind of thing be frozen by the PEP ABI?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou pitrou.net> writes: > > We could add a PY_LONG_LONG to the mix just in case. > By the way, will this kind of thing be frozen by the PEP ABI? (I meant the ABI PEP, sorry) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
>> Why is that difficult? It's sizeof(PyGC_Head). > > Is it enough to correctly propagate the alignment for, say, a long double in > the following PyObject? I'm sorry, I'm not enough of a C lawyer. Yes, sizeof must always be a multiple of the alignment. Otherwise, array elements would be misaligned. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
> We could add a PY_LONG_LONG to the mix just in case. > By the way, will this kind of thing be frozen by the PEP ABI? Yes: alignof(PyGC_HEAD) would be specified as being the maximum alignment on a platform; sizeof(PyGC_HEAD) would be frozen. The actual content would not be frozen, i.e. it could be changed in principle as long as the change would be guaranteed not to affect the structure size. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
David Lyon wrote: The Python Package Manager can be written to work in console mode. I think this would be best. Haha - I'm glad somebody took this seriously... It was a sort of a joke comment but it's a serious possibility. I took it seriously too ;-). It seems to me that you project can have at least 3 components. 1) the core library module, which might or might not be targeted at eventual stdlib inclusion. 2) a small console driver script. 3) one or more GUI scripts. A TK version would be good from my viewpoint as it does not require download and installation of any other binaries. Removal of TK from the Windows distribution will be extremely contentious if seriously proposed, so it could not happen for a while. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting HTTPS via Proxy Support in urllib2
On Sat, Jul 25, 2009 at 2:53 AM, "Martin v. Löwis" wrote: >> This is fixed in the trunk (Revision 72880), but there has been number >> of valid requests to backport it Python 2.6. While I agree and ready >> to backport to Python 2.6, I would like to ask here if there are any >> objections in this front. > > In msg76855 Greg ruled that it is a new feature, and thus cannot be > backported. I trust his judgement - so to convince me, you would need > to convince Greg first :-) > > Regards, > Martin So long as the new set_tunnel() method is hidden in the backport I'm fine with the patch. It fixes urllib2 do the right thing with https and a proxy without any public API change. -Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pthreads, fork, import, and execvp
On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote: > > So attached (and at http://codereview.appspot.com/96125/show ) is a > preliminary fix, correcting the problem with os.fork(), os.forkpty() and > os.fork1(). This doesn't expose a general API for C code to use, for two > reasons: it's not easy, and I need this fix more than I need the API change > :-) (I actually need this fix myself for Python 2.4, but it applies fairly > cleanly.) This looks good to me. Your idea of making this an API called a 'fork lock' or something sounds good (though I think it needs a better name. PyBeforeFork & PyAfterFork?). The subprocess module, for example, disables garbage collection before forking and restores it afterwards to avoid http://bugs.python.org/issue1336. That type of thing could also be done in such a function. Related to the above subprocess fork + gc bug.. It'd be nice for CPython to have code that does the fork+misc twiddling+exec all in one C call without needing to execute Python code in the child process prior to the exec(). Most of the inner body of subprocess's _execute_child() method could be done that way. (with the obvious exception of the preexec_fn) > > To fix the mutex-across-fork problem correctly we should really acquire > three locks (the import lock, the GIL and the TLS lock, in that order.) The > import lock is re-entrant, and the TLS lock is tightly confined to the > thread-local-storage lookup functions, but the GIL is neither re-entrant nor > inspectable. That means we can't use pthread_atfork (we can't tell whether > we have the GIL already or not, right before the fork), nor can we provide a > convenient API for extension modules to use, really. The best we can do is > provide three functions, pthread_atfork-style: a 'prepare' function, an > 'after-fork-in-child' function, and an 'after-fork-in-parent' function. The > 'prepare' function would start by releasing the GIL, then acquire the import > lock, the GIL and the TLS lock in that order. It would also record > *somewhere* the thread_ident of the current thread. The 'in-parent' function > would simply release the TLS lock and the import lock, and the 'in-child' > would release those locks, call the threading._at_fork() function, and fix > up the TLS data, using the recorded thread ident to do lookups. The > 'in-child' function would replace the current PyOS_AfterFork() function > (which blindly reinitializes the GIL and the TLS lock, and calls > threading._at_fork().) > > Alternatively we could do what we do now, which is to ignore the fact that > thread idents may change by fork() and thus that thread-local data may > disappear, in which case the 'in-child' function could do a little less > work. I'm suitably scared and disgusted of the TLS implementation, the > threading implementations we support (including the pthread one) and the way > we blindly type-pun a pthread_t to a long, that I'm not sure I want to try > and build something correct and reliable on top of it. > > -- > Thomas Wouters > > Hi! I'm a .signature virus! copy me into your .signature file to help me > spread! > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone wrote: > On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney > > > wrote: > >> [snip] >> >> If that is not your intent, then your application shouldn't be mentioned >> in standard Python documentation. >> >> > Hm. But docutils isn't part of the standard library, and the documentation > refers to it. Why do you think distutils is not part of the standard library? The official code location is Lib/distutils within the standard library. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, Jul 25, 2009 at 15:28, Brett Cannon wrote: > > > On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone wrote: > >> On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney < >> [email protected] > wrote: >> >>> [snip] >>> >>> If that is not your intent, then your application shouldn't be mentioned >>> in standard Python documentation. >>> >>> >> Hm. But docutils isn't part of the standard library, and the >> documentation >> refers to it. > > > Why do you think distutils is not part of the standard library? The > official code location is Lib/distutils within the standard library. > Oops, I misread the project JP mentioned. Ignore me. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On 2009-07-25 17:28, Brett Cannon wrote: On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone mailto:[email protected]>> wrote: On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney mailto:ben%[email protected]>> wrote: [snip] If that is not your intent, then your application shouldn't be mentioned in standard Python documentation. Hm. But docutils isn't part of the standard library, and the documentation refers to it. Why do you think distutils is not part of the standard library? The official code location is Lib/distutils within the standard library. He said "docutils", not "distutils". -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Martin v. Löwis: > Yes: alignof(PyGC_HEAD) would be specified as being the maximum > alignment on a platform; sizeof(PyGC_HEAD) would be frozen. Maximum alignment currently on x86 is 16 bytes for SSE vector types. Next year AVX will add 32 byte types and while they are supposed to work OK with 16 byte alignment, performance will be better with 32 byte alignment. It is possible that some use could be found for vector instructions in core Python but it is more likely that they will only be used in specialized extensions that can take care of alignment issues for their own cases. http://en.wikipedia.org/wiki/Advanced_Vector_Extensions http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/61891/ Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
>Maximum alignment currently on x86 is 16 bytes for SSE vector > types. Next year AVX will add 32 byte types and while they are > supposed to work OK with 16 byte alignment, performance will be better > with 32 byte alignment. That doesn't really matter. What matters is the platform's ABI, i.e. what the maximum alignment is that the compiler gives, and what the alignment of a malloc() result is. That is unlikely to change even if x86 evolves. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 12:47:21 -0400, Terry Reedy wrote: The Python Package Manager can be written to work in console mode. >>> I think this would be best. >> >> Haha - I'm glad somebody took this seriously... It was a sort of a joke >> comment but it's a serious possibility. > > I took it seriously too ;-). It seems to me that you project can have at > least 3 components. It's logical and plausible. > 1) the core library module, which might or might not be targeted at eventual stdlib inclusion. I'm sure they'll fix distutils someday, and if they do, then I'll use that. > 2) a small console driver script. 3) one or more GUI scripts. It's possible. I'll give it serious consideration. > A TK version would be good from my > viewpoint as it does not require download and installation of any other > binaries. Sure. Who cares if it's not as slick as something else. I'll try when I have time. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 11:42:13 +0200, "Martin v. Löwis" wrote: >> It's my intention to get a Package Manager included in standard >> python - yes. > > In addition to the other constraints you'll have to meet for this > to happen, you also have to wait a rather long time (several years) > before inclusion becomes possible. This time is necessary for the > community to accept your tool, and evaluate it. Ideally, the request > for inclusion should not come from you, but from your users. Yes. But users have been asking for a tool and complaining loudly about the lack of such a tool. I know you're an extremely competent and those emails you perphaps floss over. But the pleas are many and when we compare python to other languages, python rates towards at the low end of the spectrum its third party-package management facilities. You can't seriously expect users to wait for years for an integrated package management tool. Especially on Windows - that's cruel :-) To date, there just hasn't been any movement on the building of such a tool due to whatever reasons. A Package Manager isn't a frivolous "nice-to-have" tool. It's essential for a new user. (if you want I can sift the last twelve months worth of ML archives and report on how many times easier package management has been asked for. And how difficult people are finding it) > No. It implies that any addition could only depend on Python (and > OS API) - so things *can* be added. For example, setuptools could > be added by this principle. OTOH, if your tool depends on setuptools, > you'll have to wait for setuptools to get included before inclusion > of your tool can be considered. Let's get precise. It doesn't "depend" on setuptools. But it will install setuptools if the user requests to use setuptools/easy_install. So we should only be back to the lack of a TK interface and the fact that the Package Manager Project is a new project, and needs to be working properly on more platforms. Thanks for your email. I appreciate the feedback, from everyone. Take care. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
> You can't seriously expect users to wait for years for an integrated > package management tool. Especially on Windows - that's cruel :-) Hmm. I'm -0 on providing a tool whose only purpose is to download files from a web server. I always use a web browser for that... > A Package Manager isn't a frivolous "nice-to-have" tool. It's > essential for a new user. Hmm. I would expect that a new user is faced with the challenge of finding out what packages to install more so than with actually installing them. If they read examples, they will see import statements, and then they have to find out how to make those work. Does your tool help with that? When the user is not so new anymore, I seriously doubt that they still ask for a package management tool - except perhaps for dependencies, and here they use easy_install. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
