[Python-Dev] infinities
i found several places in my code where i use positive infinity (posinf) for various things, i.e., def readline(self, limit = -1): if limit < 0: limit = 1e1 # posinf chars = [] while limit > 0: ch = self.read(1) chars.append(ch) if not ch or ch == "\n": break limit -= 1 return "".join(chars) i like the concept, but i hate the "1e1" stuff... why not add posint, neginf, and nan to the float type? i find it much more readable as: if limit < 0: limit = float.posinf posinf, neginf and nan are singletons, so there's no problem with adding as members to the type. -tomer ___ 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] infinities
On 11/26/06, tomer filiba <[EMAIL PROTECTED]> wrote: > i found several places in my code where i use positive infinity > (posinf) for various things, i.e., > > def readline(self, limit = -1): > if limit < 0: > limit = 1e1 # posinf > chars = [] > while limit > 0: > ch = self.read(1) > chars.append(ch) > if not ch or ch == "\n": > break > limit -= 1 > return "".join(chars) > > i like the concept, but i hate the "1e1" stuff... why not add > posint, neginf, and nan to the float type? i find it much more readable as: > > if limit < 0: > limit = float.posinf > > posinf, neginf and nan are singletons, so there's no problem with > adding as members to the type. sys.maxint makes more sense there. Or you could change it to "while limit != 0" and set it to -1 (though I probably wouldn't actually do that)... There is already a PEP 754 for float constants, which is implemented in the fpconst module (see CheeseShop). It's not (yet) part of the stdlib though. -bob ___ 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] infinities
> sys.maxint makes more sense there. no, it requires *infinity* to accomplish x - y == x; y != 0, for example: while limit > 0: limit -= len(chunk) with limit = posinf, the above code should be equivalent to "while True". > There is already a PEP 754 for float constants okay, that would suffice. but why isn't it part of stdlib already? the pep is three years old... it should either be rejected or accepted. meanwhile, there are lots of missing API functions in the floating-point implementation... besides, all the suggested APIs should be part of the float type, not a separate module. here's what i want: >>> f = 5.0 >>> f.is_infinity() False >>> float.PosInf 1.#INF -tomer On 11/26/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > On 11/26/06, tomer filiba <[EMAIL PROTECTED]> wrote: > > i found several places in my code where i use positive infinity > > (posinf) for various things, i.e., > > > > def readline(self, limit = -1): > > if limit < 0: > > limit = 1e1 # posinf > > chars = [] > > while limit > 0: > > ch = self.read(1) > > chars.append(ch) > > if not ch or ch == "\n": > > break > > limit -= 1 > > return "".join(chars) > > > > i like the concept, but i hate the "1e1" stuff... why not add > > posint, neginf, and nan to the float type? i find it much more readable as: > > > > if limit < 0: > > limit = float.posinf > > > > posinf, neginf and nan are singletons, so there's no problem with > > adding as members to the type. > > sys.maxint makes more sense there. Or you could change it to "while > limit != 0" and set it to -1 (though I probably wouldn't actually do > that)... > > There is already a PEP 754 for float constants, which is implemented > in the fpconst module (see CheeseShop). It's not (yet) part of the > stdlib though. > > -bob > ___ 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] infinities
tomer filiba wrote: > no, it requires *infinity* to accomplish x - y == x; y != 0, for example: > > while limit > 0: > limit -= len(chunk) > > with limit = posinf, the above code should be equivalent to "while True". that's a remarkably stupid way to count bytes. if you want to argue for additions to the language, you could at least bother to come up with a sane use case. ___ 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] infinities
At 07:07 PM 11/26/2006 +0200, tomer filiba wrote: > > sys.maxint makes more sense there. >no, it requires *infinity* to accomplish x - y == x; y != 0, for example: > >while limit > 0: > limit -= len(chunk) Um, you do realize that you're not going to be able to fit sys.maxint strings into a list, right? That's over 2 billion *pointers* worth of memory, so at least 8 gigabytes on a 32-bit machine... that probably can't address more than 4 gigabytes of memory to start with. The code will fail with MemoryError long before you exhaust sys.maxint, even in the case where you're using only 1-character strings. ___ 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] Suggestion/ feature request
> -Original Message- > From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 21, 2006 12:01 AM > To: Julian > Cc: [email protected] > Subject: Re: [Python-Dev] Suggestion/ feature request > > Julian schrieb: > > I am using python with swig and I get a lot of macro redefinition > > warnings like so: > > warning C4005: '_CRT_SECURE_NO_DEPRECATE' : macro redefinition > > > > In the file - pyconfig.h - rather than the following lines, I was > > wondering if it would be more reasonable to use #ifdef > statements as > > shown in the bottom of the email... > > While I agree that would be reasonable, I also wonder why you > are getting these errors. Where is the first definition of > these macros, and how is the macro defined at the first definition? > > Regards, > Martin In my specific case, the order of the definitions in any wrapper file created by SWIG (I am using Version 1.3.30) looks like this: //example_wrap.cxx //snipped code /* Deal with Microsoft's attempt at deprecating C standard runtime functions */ #if !defined(SWIG_NO_CRT_SECURE_NO_DEPRECATE) && defined(_MSC_VER) && !defined(_CRT_SECURE_NO_DEPRECATE) # define _CRT_SECURE_NO_DEPRECATE #endif /* Python.h has to appear first */ #include //snipped code SWIG seems to have done it properly by checking to see if it has been defined already (which, I think, is how python should do it as well) Now, even if I am not using SWIG, I could imagine these being defined elsewhere (by other headers/libraries) or even by setting them in the VS2005 IDE project settings (which I actually do sometimes). While these are *just* warnings and not errors, it would look cleaner if pyconfig.h would check if they were defined already. Julian. ___ 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] Suggestion/ feature request
> -Original Message- > From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 21, 2006 12:22 PM > To: Julian > Cc: [email protected] > Subject: Re: [Python-Dev] Suggestion/ feature request > > Julian schrieb: > > SWIG seems to have done it properly by checking to see if > it has been > > defined already (which, I think, is how python should do it > as well) > > Now, even if I am not using SWIG, I could imagine these > being defined > > elsewhere (by other headers/libraries) or even by setting > them in the > > VS2005 IDE project settings (which I actually do sometimes). While > > these are *just* warnings and not errors, it would look cleaner if > > pyconfig.h would check if they were defined already. > > Sure; I have fixed this now in r52817 and r52818 > > I just wondered why you get the warning: you shouldn't get > one if the redefinition is the same as the original one. In > this case, it wasn't the same redefinition, as SWIG was > merely defining them, and Python was defining them to 1. > > Regards, > Martin > Thanks! you are right... I didn't know that ! I have two questions though... Is there any reason why Python is defining them to 1? In pyconfig.h, there is: #ifndef _CRT_SECURE_NO_DEPRECATE #define _CRT_SECURE_NO_DEPRECATE 1 #endif And then later on in the same file: /* Turn off warnings about deprecated C runtime functions in VisualStudio .NET 2005 */ #if _MSC_VER >= 1400 && !defined _CRT_SECURE_NO_DEPRECATE #define _CRT_SECURE_NO_DEPRECATE #endif Isn't that redundant? I don't think that second block will ever get executed. Moreover, in the second block, it is not being defined to 1. why is that ? Julian. ___ 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
[Python-Dev] Python and the Linux Standard Base (LSB)
Hi everyone, Guido van Rossum suggested I send this email here. I'm CTO of the Free Standards Group and chair of the Linux Standard Base (LSB), the interoperability standard for the Linux distributions. We're wanting to add Python to the next version of the LSB (LSB 3.2) [1] and are looking for someone (or, better, a few folks) in the Python community to help us lead the effort to do that. The basic goal is to standardize the Python environment compliant Linux distributions (Red Hat, SUSE, Debian, Ubuntu, etc.) provide so that application developers can write LSB compliant applications in Python. [1] http://www.freestandards.org/en/LSB_Roadmap The first question we have to answer is: What does it mean to "add Python to the LSB"? Is it enough to say that Python is present at a certain version and above, or do we need to do more than that (e.g., many distros ship numerous Python add-ons which apps may or may not rely on--do we need to specific some of these too)? What would be the least common denominator version? Answering this question will require us to look at the major Linux distros (RHEL, SLES, Debian, Ubuntu, etc.) to see what versions they ship. And so on. Once we've decided how best to specify that Python is present, how do we test that it is indeed present? Of course, there's the existing Python test suites, so there shouldn't be a lot of work to do here. Another question is how to handle binary modules. The LSB provides strict backward compatibility at the binary level, even across major versions, and that may or may not be appropriate for Python. The LSB is mostly concerned with backward compatibility from an application developer's point of view, and this would seem to mean largely 100% Python, whereas C extensions would seem to be largely the domain of component developers, such as Python access to Gtk or other OS services (here, we'd probably look to add those components to the LSB directly rather than specifying the Python ABI so they can be maintained separately). Of course I could be wrong about this. Anyway, as you can see, there are numerous issues to work out here. If anyone is interested in getting involved, please drop me a line, and I'd be happy to answer any questions (discussion on any of the topics above would be welcomed as well). Finally, for any Python developers in and around Berlin, the LSB is holding its next face to face meeting in Berlin December 4-6, where the LSB 3.2 roadmap will be finalized. If you could find some time to stop by and talk with us, we would deeply appreciate it: http://www.freestandards.org/en/LSB_face-to-face_%28December_2006%29 Thanks, -ian -- Ian Murdock 317-863-2590 http://ianmurdock.com/ "Don't look back--something might be gaining on you." --Satchel Paige ___ 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
[Python-Dev] (no subject)
Mr. Rossum, I saw an old post you made about the Google Internships (Jan 25,2006). As a prospective for next summer, you mention that it would be in my best interest to contact brett Cannon. I have many questions I'd love to have answered, how do I go about contacting him? I look forward to your reply. Chris Farwell [EMAIL PROTECTED] ___ 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] infinities
tomer filiba schrieb: > okay, that would suffice. but why isn't it part of stdlib already? > the pep is three years old... it should either be rejected or accepted. > meanwhile, there are lots of missing API functions in the floating-point > implementation... It's not rejected because people keep requesting the feature, and not accepted because it's not implementable in general (i.e. it is difficult to implement on platforms where the double type is not IEEE-754). 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] Python and the Linux Standard Base (LSB)
Ian Murdock schrieb: > I'm CTO of the Free Standards Group and chair of the Linux Standard > Base (LSB), the interoperability standard for the Linux distributions. > We're wanting to add Python to the next version of the LSB (LSB 3.2) [1] > and are looking for someone (or, better, a few folks) in the Python > community to help us lead the effort to do that. The basic goal > is to standardize the Python environment compliant Linux distributions > (Red Hat, SUSE, Debian, Ubuntu, etc.) provide so that > application developers can write LSB compliant applications in Python. I wrote to Ian that I would be interested; participating in the meeting in Berlin is quite convenient. I can try to keep python-dev updated. 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] Python and the Linux Standard Base (LSB)
On Sun, Nov 26, 2006, "Martin v. L?wis" wrote: > > I wrote to Ian that I would be interested; participating in the meeting > in Berlin is quite convenient. I can try to keep python-dev updated. Please do -- it's not something I have a lot of cycles for but am interested in. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. ___ 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] Python and the Linux Standard Base (LSB)
At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote: >The first question we have to answer is: What does it mean to "add >Python to the LSB"? Is it enough to say that Python is present >at a certain version and above, or do we need to do more than that >(e.g., many distros ship numerous Python add-ons which apps >may or may not rely on--do we need to specific some of these too)? Just a suggestion, but one issue that I think needs addressing is the FHS language that leads some Linux distros to believe that they should change Python's normal installation layout (sometimes in bizarre ways) or that they should remove and separately package different portions of the standard library. Other vendors apparently also patch Python in various ways to support their FHS-based theories of how Python should install files. These changes are detrimental to compatibility. Another issue is specifying dependencies. The existence of the Cheeseshop as a central registry of Python project names has not been taken into account in vendor packaging practices, for example. (Python 2.5 also introduced the ability to install metadata alongside installed Python packages, supporting runtime checking for package presence and versions.) I don't know how closely these issues tie into what the LSB is tying to do, as I've only observed these issues in the breach, where certain distribution policies require e.g. that project names be replaced with internal package names, demand separation of package data files from their packages, or other procrustean chopping that makes mincemeat of any attempt at multi-distribution compatibility for an application or multi-dependency library. Some clarification at the LSB level of what is actually considered standard for Python might perhaps be helpful in motivating updates to some of these policies. ___ 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] infinities
> Um, you do realize that you're not going to be able to fit sys.maxint > strings into a list, right? i can multiply by four, thank you. of course i don't expect anyone to read a string *that* long. besides, this *particular example* isn't important, it was just meant to show why someone might want to use it. why are people being so picky about the details of an example code? first of all, a "while True" loop is not limited by sys.maxint, so i see no reason why i couldn't get the same result by subtracting from infinity. that may seem blunt, but it's a good way have the same code handle both cases (limited and unlimited reading). all i was asking for was a better way to express and handle infinity (and nan), instead of the poor-man's version of "nan = 2e/3e". float.posinf or float.isinf(5.0) seem the right way to me. for some reference, it seemed the right way to other people too: http://msdn2.microsoft.com/en-gb/library/system.double_methods.aspx http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Float.html the third-party fp module is nice, but it ought to be part of the float type, or at least part of stdlib. - - - - - - if it were up to me, *literals* producing infinity would be a syntax error (of course i would allow computations to result in infinity). for the reason why, consider this: >>> 1e1 == 2e2 True -tomer ___ 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
[Python-Dev] Distribution tools: What I would like to see
I've been looking once again over the docs for distutils and setuptools, and thinking to myself "this seems a lot more complicated than it ought to be". Before I get into detail, however, I want to explain carefully the scope of my critique - in particular, why I am talking about setuptools on the python-dev list. You see, in my mind, the process of assembling, distributing, and downloading a package is, or at least ought to be, a unified process. It ought to be a fundamental part of the system, and not split into separate tools with separate docs that have to be mentally assembled in order to understand it. Moreover, setuptools is the defacto standard these days - a novice programmer who googles for 'python install tools' will encounter setuptools long before they learn about distutils; and if you read the various mailing lists and blogs, you'll sense a subtle aura of deprecation and decay that surrounds distutils. I would claim, then, that regardless of whether setuptools is officially blessed or not, it is an intrinstic part of the "Python experience". (I'd also like to put forward the disclaimer that there are probably factual errors in this post, or errors of misunderstanding; All I can claim as an excuse is that it's not for lack of trying, and corrections are welcome as always.) Think about the idea of module distribution from a pedagogical standpoint - when does a newbie Python programmer start learning about module distribution and what do they learn first? A novice Python user will begin by writing scripts for themselves, and not thinking about distribution at all. However, once they reach the point where they begin to think about packaging up their module, the Python documentation ought to be able to lead them, step by step, towards a goal of making a distributable package: -- It should teach them how to organize their code into packages and modules -- It should show them how to write the proper setup scripts -- If there is C code involved, it should explain how that fits into the picture. -- It should explain how to write unit tests and where they should go. So how does the current system fail in this regard? The docs for each component - distutils, setuptools, unit test frameworks, and so on, only talk about that specific module - not how it all fits together. For example, the docs for distutils start by telling you how to build a setup script. It never explains why you need a setup script, or why Python programs need to be "installed" in the first place. [1] The distutils docs never describe how your directory structure ought to look. In fact, they never tell you how to *write* a distributable package; rather, it seems to be more oriented towards taking an already-working package and modifying it to be distributable. The setuptools docs are even worse in this regard. If you look carefully at the docs for setuptools, you'll notice that each subsection is effectively a 'diff', describing how setuputils is different from distutils. One section talks about the "new and changed keywords", without explaining what the old keywords were or how to find them. Thus, for the novice programmer, learning how to write a setup script ends up being a process of flipping back and forth between the distutils and setuptools docs, trying to hold in their minds enough of each to be able to achieve some sort of understanding. What we have now does a good job of explaining how the individual tools work, but it doesn't do a good job of answering the question "Starting from an empty directory, how do I create a distributable Python package?" A novice programmer wants to know what to create first, what to create next, and so on. This is especially true if the novice programmer is creating an extension module. Suppose I have a C library that I need to wrap. In order to even compile and test it, I'm going to need a setup script. That means I need to understand distutils before I even think about distribution, before I even begin writing the code! (Sure, I could write a Makefile, but I'd only end up throwing it away later -- so why not cut to the chase and *start* with a setup script? Ans: Because it's too hard!) But it isn't just the docs that are at fault here - otherwise, I'd be posting this on a different mailing list. It seems like the whole architecture is 'diff'-based, a series of patches on top of patches, which are in need of some serious refactoring. Except that nobody can do this refactoring, because there's no formal list of requirements. I look at distutils, and while some parts are obvious, there are other parts where I go "what problem were they trying to solve here?" In my experience, you *don't* go mucking with someone's code and trying to fix it unless you understand what problem they were trying to solve - otherwise you'll botch it and make a mess. Since few people ever bother to write down what problem they were trying to
Re: [Python-Dev] Distribution tools: What I would like to see
Talin wrote: > But it isn't just the docs that are at fault here - otherwise, I'd be > posting this on a different mailing list. It seems like the whole > architecture is 'diff'-based, a series of patches on top of patches, > which are in need of some serious refactoring. so to summarize, you want someone to rewrite the code and write new documentation, and since you didn't even have time to make your post shorter, that someone will obviously not be you ? ___ 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] Distribution tools: What I would like to see
Fredrik Lundh wrote: > Talin wrote: > >> But it isn't just the docs that are at fault here - otherwise, I'd be >> posting this on a different mailing list. It seems like the whole >> architecture is 'diff'-based, a series of patches on top of patches, >> which are in need of some serious refactoring. > > so to summarize, you want someone to rewrite the code and write new > documentation, and since you didn't even have time to make your post > shorter, that someone will obviously not be you ? Oh, it was a lot longer when I started :) As far as rewriting it goes - I can only rewrite things that I understand. > ___ 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] Distribution tools: What I would like to see
On 11/26/06, Talin <[EMAIL PROTECTED]> wrote: > I've been looking once again over the docs for distutils and setuptools, > and thinking to myself "this seems a lot more complicated than it ought > to be". > > Before I get into detail, however, I want to explain carefully the scope > of my critique - in particular, why I am talking about setuptools on the > python-dev list. You see, in my mind, the process of assembling, > distributing, and downloading a package is, or at least ought to be, a > unified process. It ought to be a fundamental part of the system, and > not split into separate tools with separate docs that have to be > mentally assembled in order to understand it. > > Moreover, setuptools is the defacto standard these days - a novice > programmer who googles for 'python install tools' will encounter > setuptools long before they learn about distutils; and if you read the > various mailing lists and blogs, you'll sense a subtle aura of > deprecation and decay that surrounds distutils. Look at the current situation as more of an evoluntionary point than a finished product. There's widespread support for integrating setuptools into Python as you suggest. I've heard it discussed at Pycon the past two years. The reason it hasn't been done yet is technical, from what I've heard. Distutils is apparently difficult to patch correctly and could stand a rewrite. I'm currently studying the Pylons implementation and thus having to learn more about entry points, resources, ini files used by eggs, etc. This requires studying three different pages on the peak.telecommunity.com site -- exactly the problem you're describing. A comprehensive third-party manual that integrates the documentation would be a good place to start. Even the outline of such a manual would be a good. That would give a common baseline of understanding for package users, package developers, and core developers. I wonder if one of the Python books already has this written down somewhere. >From the manual one could then distill a spec for "what's needed in a package manager, what features a distutils upgrade would provide, and what a package should/may contain". That would be a basis for one or more PEPs. The "diff" approach is understandable at the beginning, because that's how the developers think of it, and how most users will approach it initially. We also needed real-world experience to see if the setuptools approach was even feasable large-scale or whether it needed major changes. Now we have more experience, and more Pythoneers are appearing who are unfamiliar with the "distutils-only" approach. So requests like Talin's will become more frequent. It's such a big job and Python 2.6 is slated as "minimal features" release, so it may be better to target this for Python 3 and backport it if possible. -- Mike Orr <[EMAIL PROTECTED]> ___ 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] Distribution tools: What I would like to see
At 01:21 PM 11/26/2006 -0800, Mike Orr wrote: >A comprehensive third-party manual that integrates the documentation >would be a good place to start. Even the outline of such a manual >would be a good. That would give a common baseline of understanding >for package users, package developers, and core developers. A number of people have written quick-start or how-to guides for setuptools, although I haven't been keeping track. I have noticed, however, that a signficant number of help requests for setuptools can be answered by internal links to one of its manuals -- and when a topic comes up that isn't in the manual, I usually add it. The "diff" issue is certainly there, of course, as is the fact that there are multiple manuals. However, I don't think the answer is fewer manuals, in fact it's likely to be having *more*. What exists right now is a developer's guide and reference for setuptools, a reference for the pkg_resources API, and an all-purpose handbook for easy_install. Each of these could use beginner's introductions or tutorials that are deliberately short on details, but which provide links to the relevant sections of the comprehensive manuals. My emphasis on the existing manuals was aimed at early adopters, who were likely to be familiar with at least some of distutils' hazards and difficulties, and thus would learn most quickly (and be most motivated) by seeing what was different. Obviously, nearly everybody in that camp has either already switched or decided they're not switching due to investment in other distutils-wrapping technologies and/or incompatible philosophies. So, the manuals are no longer adequate for the next wave of developers. Anyway, I would be happy to link from the manuals and Cheeseshop page to quality tutorials that focus on one or more aspects of developing, packaging, or distributing Python projects using setuptools. ___ 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] Python and the Linux Standard Base (LSB)
Excellent! Like Aahz, I have no cycles, but I think it's a worthy goal. --Guido On 11/26/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Ian Murdock schrieb: > > I'm CTO of the Free Standards Group and chair of the Linux Standard > > Base (LSB), the interoperability standard for the Linux distributions. > > We're wanting to add Python to the next version of the LSB (LSB 3.2) [1] > > and are looking for someone (or, better, a few folks) in the Python > > community to help us lead the effort to do that. The basic goal > > is to standardize the Python environment compliant Linux distributions > > (Red Hat, SUSE, Debian, Ubuntu, etc.) provide so that > > application developers can write LSB compliant applications in Python. > > I wrote to Ian that I would be interested; participating in the meeting > in Berlin is quite convenient. I can try to keep python-dev updated. > > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Distribution tools: What I would like to see
On 11/26/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I have noticed, however, that a signficant number of help requests for > setuptools can be answered by internal links to one of its manuals -- and > when a topic comes up that isn't in the manual, I usually add it. Hmm, I may have a couple topics for you after I check my notes. > The "diff" issue is certainly there, of course, as is the fact that there > are multiple manuals. However, I don't think the answer is fewer manuals, > in fact it's likely to be having *more*. What exists right now is a > developer's guide and reference for setuptools, a reference for the > pkg_resources API, and an all-purpose handbook for easy_install. Each of > these could use beginner's introductions or tutorials that are deliberately > short on details, but which provide links to the relevant sections of the > comprehensive manuals. I could see a comprehensive manual running forty pages, and most readers only caring about a small fraction of it. So you have a point. Maybe more impotant than one book is having "one place to go", a TOC of articles that are all independent yet written to complement each other. But Talin's point is still valid. Users have questions like, "How do I structure my package so it takes advantage of all the gee-whiz cheeseshop features? Where do I put my tests? Should I use unittest, py.test, or nose? How will users see my README and my docs if they easy_install my package? What are all those files in the EGG-INFO directory? What's that word 'distribution' in some of the function signatures? How do I use entry points, they look pretty complicated?" Some of these questions are multi-tool or are outside the scope of setuptools; some span both the Peak docs and the Python docs. People need an answer that starts with their question, rather than an answer that's a section in a manual describing a particular tool. -- Mike Orr <[EMAIL PROTECTED]> ___ 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] Distribution tools: What I would like to see
Mike Orr wrote: > On 11/26/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> I have noticed, however, that a signficant number of help requests for >> setuptools can be answered by internal links to one of its manuals -- and >> when a topic comes up that isn't in the manual, I usually add it. > > Hmm, I may have a couple topics for you after I check my notes. > >> The "diff" issue is certainly there, of course, as is the fact that there >> are multiple manuals. However, I don't think the answer is fewer manuals, >> in fact it's likely to be having *more*. What exists right now is a >> developer's guide and reference for setuptools, a reference for the >> pkg_resources API, and an all-purpose handbook for easy_install. Each of >> these could use beginner's introductions or tutorials that are deliberately >> short on details, but which provide links to the relevant sections of the >> comprehensive manuals. > > I could see a comprehensive manual running forty pages, and most > readers only caring about a small fraction of it. So you have a > point. Maybe more impotant than one book is having "one place to go", > a TOC of articles that are all independent yet written to complement > each other. > > But Talin's point is still valid. Users have questions like, "How do > I structure my package so it takes advantage of all the gee-whiz > cheeseshop features? Where do I put my tests? Should I use unittest, > py.test, or nose? How will users see my README and my docs if they > easy_install my package? What are all those files in the EGG-INFO > directory? What's that word 'distribution' in some of the function > signatures? How do I use entry points, they look pretty complicated?" > Some of these questions are multi-tool or are outside the scope of > setuptools; some span both the Peak docs and the Python docs. People > need an answer that starts with their question, rather than an answer > that's a section in a manual describing a particular tool. You said it way better than I did - I feel totally validated now :) -- Talin ___ 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
