Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 02:32:55 pm David Lyon wrote: > > 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 :-) Life is cruel and hard. Anyone who tells you different is selling something. Nobody is saying that users have to wait for years for such a tool. They can download it from wherever you host it. But you shouldn't expect the Python dev team to accept an unproven tool into the official library before demonstrating both the need and the solution. (Just because users say they want something, doesn't mean they'll actually use the tool you provide -- perhaps they don't know what they really need, and perhaps your tool doesn't match their needs.) I'm a user, and personally I don't want Yet Another Integrated Package Management Tool. What I really want is the ability to install Python packages using the PM tool I already use, namely yum. (And I'd like a pony.) Failing that, I want the Python standard library to be stable and reliable. With the greatest of respect, fast-tracking unproven tools into the library based on the author's say-so is the first step to instability and unreliability. Putting your software on the Cheeseshop, and making regular announcements to the Python community (e.g. on comp.lang.python) will be a good way to publicise the tool, and if does meet a need, people will use it, and then, if it's good enough and popular enough and supported, it may be blessed by inclusion in the standard library. Although I'm not a Windows user, let me say thank you for your efforts on behalf of Python users. Good luck! -- Steven D'Aprano ___ 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] Update to Python Documentation Website Request
Steven D'Aprano wrote: > I'm a user, and personally I don't want Yet Another Integrated Package > Management Tool. What I really want is the ability to install Python > packages using the PM tool I already use, namely yum. (And I'd like a > pony.) Picking up on this point... out of curiousity, I threw a couple of package names at "apt-get -s" on my main (Ubuntu 8.04) PC to see what worked. The first two names I tried (numpy, scipy) didn't work, but the next four (python-numpy, python-scipy, python-django, python-turbogears) all had hits. Because Turbo Gears incorporates so many other projects, the simulated run at installing it provided a nice overview of a variety of other Python packages in the Ubuntu repositories as well. No doubt a search in Adept would reveal a whole lot more "python-*" packages that are just a few clicks away for me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 08:43:07 +0200, "Martin v. Löwis" wrote: > 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... It does a lot more than that. Firstly it shows what packages you already have installed and lets you manage them. Namely, deinstall, (manually) upgrade, view documentation and examples. In any case, even if it were only a tool to download packages it's still consistant with modern appliance design (mobile phones, programming languages, dedicated hardware) to have an internal application where a user can pretty easily download "checked" apps to their device/system. Nobody gives people just a browser to do that... and tell them "go browse". It isn't being done like that - except in python. > 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. Yes. That's exactly the point. You're 100% right. That's why the pythonpkgmgr provides a useful search capability for pypi packages. It's faster and more natural to use a native app than do it all in the browser. That's true in Perl (cpan) as in Python and I'm honestly saying that I can't find any noteable faults in pypi the way I find it. > 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? Yes. It will open the website or homepage to the project/package in question. And find any documentation that might be stored in the package directory. If you only have "import interbasedb" it's a complicated process for a new user to located the home page or project documentation without pythonpkgmgr. Using pythonpkgmgr, they look on their list of installed packages, find the "interbasedb" or whatever module, and can get quick access to the pypi page or the package homepage. It's much easier. Much faster.. especially if the new user doesn't know the internals of package storage, pypi and the like. > 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. Well, that might be one use-case. It's true that many python programmers will just want to stick to their own "known" packages. However, this tool aids people with more curiosity. Because users can so easily (and safely) install and deinstall anything. It's only a click to install a package, and another to deinstall. At the moment, pythonpkgmgr doesn't handle dependencies except that which is provided internally by easy_install/pip. I'm hoping to change this as my experience and understanding grows. David ___ 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] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 18:05:07 +1000, Steven D'Aprano wrote: > But you shouldn't expect the > Python dev team to accept an unproven tool into the official library > before demonstrating both the need and the solution. Of course... that's why I started off by asking what the process is. I am accepting that the current status of pythonpkgmgr is "unproven" so it will need some time for things to run their course. > (Just because > users say they want something, doesn't mean they'll actually use the > tool you provide -- perhaps they don't know what they really need, and > perhaps your tool doesn't match their needs.) Conversely, the process of satisfying needs is to discuss them. And people have been ever so helpful in that regard. > I'm a user, and personally I don't want Yet Another Integrated Package > Management Tool. What I really want is the ability to install Python > packages using the PM tool I already use, namely yum. ok - but no alternative to that is available on windows. pythonpkgmgr is not so different to that. And the idea behind it is to bring consistancy in package management across the different platforms. It does have configuration that are specific to python, and will continue to do so. Like being able to specify where one wants the package installed. > Putting your software on the Cheeseshop, and making regular > announcements to the Python community (e.g. on comp.lang.python) will > be a good way to publicise the tool, and if does meet a need, people > will use it, and then, if it's good enough and popular enough and > supported, it may be blessed by inclusion in the standard library. Thanks very much. Take care. David ___ 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] Update to Python Documentation Website Request
David Lyon wrote: On Sun, 26 Jul 2009 18:05:07 +1000, Steven D'Aprano wrote: But you shouldn't expect the Python dev team to accept an unproven tool into the official library before demonstrating both the need and the solution. Of course... that's why I started off by asking what the process is. I am accepting that the current status of pythonpkgmgr is "unproven" so it will need some time for things to run their course. It would be great to have a decent visual package manager for Python. It needs to be built on top of the work that Tarek is doing with distutils (and be compatible with his Distribute fork of setuptools) and it also needs to be established. The good news is that there is time for both... Aren't there other tools that have similar goals? PyPI browser, Yolk etc It is a shame that it needs to be built on Tk if it is to stand a chance of ever being included in the standard library - but with the right expertise it is *possible* to create decent looking UIs with Tk. Michael (Just because users say they want something, doesn't mean they'll actually use the tool you provide -- perhaps they don't know what they really need, and perhaps your tool doesn't match their needs.) Conversely, the process of satisfying needs is to discuss them. And people have been ever so helpful in that regard. I'm a user, and personally I don't want Yet Another Integrated Package Management Tool. What I really want is the ability to install Python packages using the PM tool I already use, namely yum. ok - but no alternative to that is available on windows. pythonpkgmgr is not so different to that. And the idea behind it is to bring consistancy in package management across the different platforms. It does have configuration that are specific to python, and will continue to do so. Like being able to specify where one wants the package installed. Putting your software on the Cheeseshop, and making regular announcements to the Python community (e.g. on comp.lang.python) will be a good way to publicise the tool, and if does meet a need, people will use it, and then, if it's good enough and popular enough and supported, it may be blessed by inclusion in the standard library. Thanks very much. Take care. David ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Update to Python Documentation Website Request
>> 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? > > Yes. It will open the website or homepage to the project/package > in question. How does it know the project in question? > Using pythonpkgmgr, they look on their list of installed packages, > find the "interbasedb" or whatever module, and can get quick > access to the pypi page or the package homepage. It's much easier. How do they find interbasedb in the list of installed packages if they haven't installed interbasedb yet? Regards, Martin ___ 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] Update to Python Documentation Website Request
>> I'm a user, and personally I don't want Yet Another Integrated Package >> Management Tool. What I really want is the ability to install Python >> packages using the PM tool I already use, namely yum. > > ok - but no alternative to that is available on windows. For removal of packages, an alternative *is* available: APR. > pythonpkgmgr is not so different to that. And the idea behind it is > to bring consistancy in package management across the different > platforms. At the cost of being inconsistent within a platform. Regards, Martin ___ 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
[Python-Dev] Py_TPFLAGS_HEAPTYPE too overloaded
I'm writing a C Python extension that needs to generate PyTypeObjects dynamically. Unfortunately, the Py_TPFLAGS_HEAPTYPE flag is overloaded in a way that makes it difficult to achieve this goal. The documentation for Pt_TPFLAGS_HEAPTYPE says: Py_TPFLAGS_HEAPTYPE This bit is set when the type object itself is allocated on the heap. In this case, the ob_type field of its instances is considered a reference to the type, and the type object is INCREF’ed when a new instance is created, and DECREF’ed when an instance is destroyed (this does not apply to instances of subtypes; only the type referenced by the instance’s ob_type gets INCREF’ed or DECREF’ed). This sounds like exactly what I want. I want my type object INCREF'd and DECREF'd by its instances so it doesn't leak or get deleted prematurely. If this were all that Py_TPFLAGS_HEAPTYPE did, it would work great for me. Unfortunately, Py_TPFLAGS_HEAPTYPE is also overloaded to mean "user-defined type" (as opposed to a built-in type). It controls numerous subtle behaviors such as: - whether the type's name is module.type or just type. - whether you're allowed to set __name__, __module__, or __bases__ on the type. - whether you're allowed to set __class__ on instances of this type. - whether the module name comes from the type name or the __module__ attribute. - whether it will use type->tp_doc as the docstring - whether its repr() calls it a "class" or a "type". - whether you can set attributes of the type. - whether someone is attempting the Carlo Verre hack. So I'm stuck with an unenviable choice. I think the lesser of two evils is to *not* specify Py_TPFLAGS_HEAPTYPE, because the worst that will happen is that my types will leak. This is not as bad as having someone set __class__ on one of my instances, or set attributes on my type, etc. Ideally the interpreter would have a separate flag like Py_TPFLAGS_BUILTIN that would trigger all of the above behaviors, but still make it possible to have dynamically generated built-in types get garbage collected appropriately. At the very least, the documentation I cited above should make it clear that Py_TPFLAGS_HEAPTYPE controls more than just whether the type gets INCREF'd and DECREF'd. Based on the list of behaviors I discovered above, it is almost certainly not correct for a C exension type to be declared with Py_TPFLAGS_HEAPTYPE. Josh ___ 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] Py_TPFLAGS_HEAPTYPE too overloaded
Joshua Haberman wrote: This is not as bad as having someone set __class__ on one of my instances, or set attributes on my type, etc. Is there any real need to prevent someone from doing those things? Note that even when you are allowed to change the __class__ of an instance, you're still prevented from changing it to something that has a different C layout, so you can't crash the intepreter that way. Similarly, built-in methods check that they're given an object of appropriate type at the C level. My suggestion is to just let it be a full heap type and accept whatever consequences follow. -- Greg ___ 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] Update to Python Documentation Website Request
"Martin v. Löwis" writes:
> > pythonpkgmgr is not so different to that. And the idea behind it is
> > to bring consistancy in package management across the different
> > platforms.
>
> At the cost of being inconsistent within a platform.
Indeed, and that seems to be one of the really big sticking points in
all efforts to improve Python's package management: the conflict
between user goals ("something that works for me without any effort[1] on
my part") and sysadmin goals ("something that works and plays nicely
with the rest of the system").
pythonpkgmgr seems entirely oblivious to the latter issue, and not
particularly compatible with the way package management works in *nix
OSS distros (including Linux distros, but also *BSD, MacPorts, and
Fink). I think that will probably kill uptake on those platforms --
could be wrong, but caution is suggested.
BTW, I think Tarek's efforts strike a good balance between these
goals, and the whole PEP 376 process has demonstrated how difficult it
is to serve these two masters at the same time.
Footnotes:
[1] I'm a professional economist: in my lexicon, effort minimization
is a positive goal, not laziness. Zero is just an extreme case.
___
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
