[Python-Dev] patch tracker ping: cross compile and mingw support
Is the patch tracker still the preferred place to present a patch? I had the impression that previous versions of these patches had almost gone in, but for the cleanups that I sought to implement in https://sourceforge.net/tracker/index.php\ ?func=detail&aid=1339673&group_id=5470&atid=305470 Greetings, Jan. Alternatively, see http://lilypond.org/~janneke/software/python-context-cross.patch http://lilypond.org/~janneke/software/python-context-mingw.patch -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.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] PEP 8 updates/clarifications, function/method style
Hi, >>> Too late. I don't think the diversity is all that distracting. >> I disagree. One of the things that Java got very much right was to >> specify, from the very beginning, what the preferred conventions are >> for naming conventions. (Packages in lowercase, Classes in CapWords, >> methods and variables in lowerCapWords, constants optionally in >> ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: >> SimpleHTTPServer.) >> >> The conventions are nearly universally followed, and as a result in >> java I always know how to spell things. I never have to remember >> whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() >> and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain >> convention as part of the language... this prevents breaking the rules >> on purpose (eg: wrapping a library from another language, or using >> an object with attributes to represent an XML node with child nodes). > > I agree completely with this. I might remember the name of a method, > but I don't always remember the capping and the possible use of > underscores. Consistency would be really nice. I am not saying we > should rename everything (at least not until Python 3 =), but at > least we can make sure new stuff that is not preexisting can use a > consistent naming scheme. > > And as for it being contentious, I say Guido can pronounce on this. We are > all grown-ups and can learn to name things in a certain way to > give our memories an easier time. =) Same for me. Most time I can remember the name but stuck with capping of the word. And one of the advantages of Java std lib is that naming is consistent. I hope new stuff will follow only one naming style. And now we should (or one person :-) should) decide which one. And that's the way to go for new stuff in std lib. And it states as an example for external modules. As an example we can check if ElementTree matches this. For Python 3 it's possible to switch to this consistent style. For a new and better world. bye by Wolfgang ___ 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] PEP 8 updates/clarifications
Guido van Rossum wrote: > You *might* want > to separate classes with two blank lines if the methods within them > are separated by single blank lines, but even there it's probably > overkill. Lately I've taken to putting a separator like this between consecutive class definitions of any substantial size: #--- I find it helps a lot when I'm skimming through looking for the beginnings of classes. Not suggesting this should go in PEP 8, though! 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] PEP 8 updates/clarifications
> Lately I've taken to putting a separator like this > between consecutive class definitions of any substantial > size: > > #--- > > I find it helps a lot when I'm skimming through looking > for the beginnings of classes. An editor/IDE with folding support (keyboard shortcuts included) is a more comfortable solution. :-) -- Nicola Larosa - [EMAIL PROTECTED] The only thing the meek inherit is their ass being handed to them. -- Elaine "hfb" Ashton, October 2005 ___ 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] PEP 8 updates/clarifications
On Wed, 2005-12-14 at 17:04 -0800, Guido van Rossum wrote: > > One question: you made the suggestion that a blank line separate the > > last line in a tqs docstring from its closing tqs. I'm wondering why > > that is. Note that python-mode now (or shall we say with the fix I just > > made ;) properly fills paragraphs in those strings, even if there is no > > blank line before the closing tqs line. > > Primarily because I didn't have that fix when I wrote it, and I think > many people don't have it. Actually, the fix just made paragraph filling not throw an error. I'm pretty sure the bug of M-q filling past the closing tqs has been fixed for a long time. > And did you fix it in IDLE too? Nope, I assigned that to Tim . > I can make up another reason too, but this is the main one. (I think > it also visually separates the doc string paragraphs from the code > better.) I'm just trying to suss out whether the reason is linked to the old python-mode bug or whether there's a stylistic motivation here. If it's the former, I think we should remove the recommendation. If it's the latter, I might disagree but we can leave it in. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
Ian Bicking wrote: > Guido van Rossum wrote: >> On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> >>>On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: >>> >>> The only thing I strongly disagree with is the promotion of javaNaming to equal footing with python_naming. >>> >>>Actually, they're not on equal footing atm. I happen to agree with you >>>though. >> >> >> It doesn't matter. Many large projects are adopting the camelCase >> convention, either by choice or by accident. I did a brief review of >> Zope 3 and Chandler, and while neither is consistent, camelCase >> prevails (Chandler also has a lot of CapWords method names, wihch >> suggests they didn't get this from Java -- maybe from C++?). > > Everything that touches wx seems to adopt CapWords method names -- in > part (hopefully) or in whole. Wx's API comes from Windows, and the > Microsoft method conventions. Bad, that. While the Windows API names once made sense when they referred to standalone functions, not methods, they now look ugly in wx or .NET. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 8 updates/clarifications
On Wed, 2005-12-14 at 20:09 -0600, Ian Bicking wrote: > I think it's reasonable to loosen the > phrasing a bit -- it's nearly always better to stay consistent with a > package than follow PEP 8 on this point. I agree, but actually I think there's a wider point to be made. The worst of all possible worlds is a module that is internally inconsistent about any of the guidelines. But I think the text in the introduction makes this point well enough. There should be one clear recommendation for new code, and since we've had this for four years now, I think the underline_words recommendation should stand. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
On Wed, 2005-12-14 at 20:22 -0600, Ian Bicking wrote: > I think the reference to Emacs here is unneeded. "Use 4 spaces per > indentation level" is sufficient instruction on its own. Agreed. I've removed all references to Emacs in the PEP. > I think the reference to PEP 263 tests is kind of obvious. Agreed. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
On Wed, 2005-12-14 at 18:42 -0800, Guido van Rossum wrote: > > Deprecated functions could be listed, too. > > I think that's more proper for a separate PEP -- the style guide > shouldn't have to be updated each time something else is deprecated. +1 to that, although I won't write that PEP. If someone does, we can link to it from PEP 8. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
On Wed, 2005-12-14 at 20:41 -0800, Guido van Rossum wrote: > On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: > > > > > The only thing I strongly disagree with is the promotion of javaNaming > > > to equal footing with python_naming. > > > > Actually, they're not on equal footing atm. I happen to agree with you > > though. > > It doesn't matter. Many large projects are adopting the camelCase > convention, either by choice or by accident. I did a brief review of > Zope 3 and Chandler, and while neither is consistent, camelCase > prevails (Chandler also has a lot of CapWords method names, wihch > suggests they didn't get this from Java -- maybe from C++?). That's fine. As always, projects (especially big framework-y ones like Zope and Chandler) are free to adopt whatever they want. Their internal consistency is more important anyway than adherence to PEP 8. PEP 8 though is primarily about establishing guidelines for the standard library. The underline_words recommendation has been in place for 4+ years now, and modules that have been written in that time frame have been written against to those rules. I see no reason to change now just to be more Java-like. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
[Guido van Rossum]
>In a module where you import 'foo' I don't understand why you would
>name a local variable 'foo'. So I'm not sure how the conflict would
>arise.
It goes the other way around. First suppose, following an example in
a previous message, that I have a lot of variables named 'text', as this
is kind of the default name everywhere for the text being handled in
a function, in a program handling text.
Now, let's presume that Python adds a new standard module named 'text',
containing many things that interest me, enough that I would want to
import the whole module globally in that program. The module would be
shadowed at many places, and whenever I'll have to use it, I'll have to
make some stunts, like changing the local 'text' here and there for
unshadowing the global module, or importing it the global module under
a different name. In the first case, I have inconsistent naming. In
the second case, I impose an indirection in the understanding to whoever
will maintain my program after me. In any case, it looks messed up.
Now, I'm sure I'm not alone, as a programmer, having plenty of habits
or own conventions. What I do in a program, I'm likely doing in many
others. Seeing a module name added in the standard Python library with
a name that I already much use usually means that I have no choice than
to give up on my own choices, because Python will not change his (:-),
and I ought to do tons of changes on my side so programs stay clean in
the long run, and do not finish looking like the remains of battle
field.
'text' is a particularly good example for me, because when I started
using Python 1.5.2 after having done a lot of C and Perl, I already had
the strong habit of using 'string' everywhere for the string under
consideration, and had to change this particular habit so the 'string'
module would be available. This is why I started to use 'text'
everywhere, and would not like changing conventions again.
Let's consider how people name variables. Some people write programs
like they do algebra and stick with one letter variables, merely one of
those habits directly or indirectly inherited from FORTRAN (FORmula
TRANslator). These people like using `k' for counters, and `s' for
string or socket, depending on context. They either want to spare
either the memory required to store the full identifier, or more
probably, their own keystrokes within their editor, unaware of the
modern un-abbreviating facilities. :-) A second set of programmers (I'm
in this set) prefer identifiers written as natural language words fully
written -- my counters are written `counter', and cursors are written
`cursor' --, or agglomeration of a few words tied with underlines. The
remainder of programmers might do clever things like using neologisms
('textwrap' is an example of those), or much, much less clever things
like making their identifiers by random removal of letters from words --
vowels often being the first to go --. By random, I mean that it
constantly and gratuitously strains the memory of people later having to
read their code.
No standard Python module name uses single-letter algebraic-style names,
thanks God, so the FORTRANic programmers are already protected. I would
like if module naming convention was extending its protective wing over
the second set of programmers (the set I'm in, of course!). Programmers
not being in the first two sets do not require so much protection: for
the clever ones, because the probability of clashes between neologisms
is much smaller than the probability of clashes with usual natural
language words; for the randomising programmers, well, because they do
not deserve being protected :-).
--
François Pinard http://pinard.progiciels-bpi.ca
___
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] PEP 8 updates/clarifications
On Thu, Dec 15, 2005, Barry Warsaw wrote: > > PEP 8 though is primarily about establishing guidelines for the standard > library. The underline_words recommendation has been in place for 4+ > years now, and modules that have been written in that time frame have > been written against to those rules. I see no reason to change now just > to be more Java-like. +1 -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck." --USENET schmuck (aka Robert Kern) ___ 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] PEP 8 updates/clarifications
Hi, Barry Warsaw wrote: > That's fine. As always, projects (especially big framework-y ones like > Zope and Chandler) are free to adopt whatever they want. Their internal > consistency is more important anyway than adherence to PEP 8. > > PEP 8 though is primarily about establishing guidelines for the standard > library. The underline_words recommendation has been in place for 4+ > years now, and modules that have been written in that time frame have > been written against to those rules. I see no reason to change now just > to be more Java-like. There is no need to change this, but to follow this. I checked new added modules for last python versions and most modules used lowercase with "_" (foo_bar). But "datetiem" doesn't. There "_" is lost and all is lowercase like "fromtimestamp" or "utcfromtimestamp" or "toordinal". I thought this should be "from_timestamp" or "to_ordinal". But I'm not a native speaker. bye by Wolfgang ___ 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] PEP 8 updates/clarifications
François Pinard wrote: > [Guido van Rossum] > > >>In a module where you import 'foo' I don't understand why you would >>name a local variable 'foo'. So I'm not sure how the conflict would >>arise. > > > It goes the other way around. First suppose, following an example in > a previous message, that I have a lot of variables named 'text', as this > is kind of the default name everywhere for the text being handled in > a function, in a program handling text. > [lots of hypothetical talk about the addition of the 'text' module] Seems to me your solution is obvious: import text as somethingelse regartds Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] Needed tester for patch in urllib.py module
I have written a patch, that will enable urllib.py to use http and https proxies with password authentification, if the password is stored in the corresponding environment variable (e. g. http_proxy=password:[EMAIL PROTECTED]) If a http or https proxy requires authentification, but there was no entry in the environment variable, the password is asked from the user and stored for succeeding attempts. While writing the patch, I recognized, that the old code will give a traceback, if an environment variable for a protocol is set, where proxy support is not (yet) supported in urllib.py (e. g. ftp protocol) My patch will raise a meaningful exception in this case. Finally, I noticed, that the old implementation of the https_proxy code is incorrect, if some page accessed via the https_proxy requires authorization. In this case, the user has to enter the password and then is directly directed to the page where the proxy is skipped. I have fixed this problem too. The patch was intensively tested with squid 2.5 and squid 3.0 (supports https protocol as a proxy) and applies to the trunk in the subversion repository. You can find the patch and its history on https://sourceforge.net/tracker/?func=detail&aid=1349118&group_id=5470&atid=305470 Mr. van Rossum asked me, whether I could find a developer on this list in order to test the patch. Any help would be appreciated. Thanks in advance Johannes Nicolai ___ 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] PEP 8 updates/clarifications
Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > Ian Bicking wrote: > > Guido van Rossum wrote: > >> It doesn't matter. Many large projects are adopting the camelCase > >> convention, either by choice or by accident. I did a brief review of > >> Zope 3 and Chandler, and while neither is consistent, camelCase > >> prevails (Chandler also has a lot of CapWords method names, wihch > >> suggests they didn't get this from Java -- maybe from C++?). > > > > Everything that touches wx seems to adopt CapWords method names -- in > > part (hopefully) or in whole. Wx's API comes from Windows, and the > > Microsoft method conventions. > > Bad, that. While the Windows API names once made sense when they referred to > standalone functions, not methods, they now look ugly in wx or .NET. In regards to naming conventions, I find that CapWords are easier for me to read and remember as a native speaker of english. I've heard statements from non-native english speakers that CapWords are hard to read and/or understand, but in the realm of wxPython, changing literally thousands of CapWords references to lower_underscore during wrapping, along with the hundreds of thousands of references in just a few of the larger wxPython projects is a bit out of line. Or even convincing the hundreds of other packages which use CapWords or lower_underscore to change how their naming conventions work is going to be a tough fight. Personally, I'm of the opinion that as long as a module or package uses consistant naming semantics, whether it is CapWords, camelCase, or lower_underscore (all of which beat lowerwithoutspaces), then users of that module or package should be able to cope. Yeah, consistancy cross-packages would be nice, heck consistancy in the standard library would be nice, but changing the naming in the standard library for a purity argument, I think, is a red herring. - Josiah ___ 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] PEP 8 updates/clarifications, function/method style
Hi, >>> Too late. I don't think the diversity is all that distracting. >> I disagree. One of the things that Java got very much right was to >> specify, from the very beginning, what the preferred conventions are >> for naming conventions. (Packages in lowercase, Classes in CapWords, >> methods and variables in lowerCapWords, constants optionally in >> ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: >> SimpleHTTPServer.) >> >> The conventions are nearly universally followed, and as a result in >> java I always know how to spell things. I never have to remember >> whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() >> and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain >> convention as part of the language... this prevents breaking the rules >> on purpose (eg: wrapping a library from another language, or using >> an object with attributes to represent an XML node with child nodes). > > I agree completely with this. I might remember the name of a method, > but I don't always remember the capping and the possible use of > underscores. Consistency would be really nice. I am not saying we > should rename everything (at least not until Python 3 =), but at > least we can make sure new stuff that is not preexisting can use a > consistent naming scheme. > > And as for it being contentious, I say Guido can pronounce on this. > We are all grown-ups and can learn to name things in a certain way to > give our memories an easier time. =) Same for me. Most time I can remember the name but stuck with capping of the word. And one of the advantages of Java std lib is that naming is consistent. I hope new stuff will follow only one naming style. And now we should (or one person :-) should) decide which one. And that's the way to go for new stuff in std lib. And it states as an example for external modules. As an example we can check if ElementTree matches this. For Python 3 it's possible to switch to this consistent style. For a new and better world. bye by Wolfgang ___ 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] Sharing expat instances
Phillip J. Eby wrote: > I don't know. I can see that the split makes sense for prefix/exec-prefix > distinctions, but then again, the disutils will install an entire > distribution in exec-prefix if it contains "impure" parts, so that's > certainly an option here. > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > directories exist, since it seems to me that that's what exec-prefix is > for. Can you please explain? exec_prefix will point to, say, /usr/i686; it shouldn't be that .so files are directly installed in that location. Instead, Python searches them in EXEC_PREFIX "/lib/python" VERSION "/lib-dynload". > Perhaps somebody can explain why lib-dynload/ and DLLs/ > exist? To have a directory on sys.path where native modules are found. > Perhaps some platforms have to add these directories to some > godforsaken environment variables like LD_LIBRARY_PATH or something? Not to my knowledge, no. lib-dynload was introduced in revision 8976, where it was renamed from "/sharedmodules". This, in turn, was introduced into getpath.c in revision 7775 (and 7776). It was added to Modules/Setup.in in revision 6313, and to Makefile.in in 6321. Unfortunately, the checkin message of 6321 only says More changes to install targets. The notion of a separate makefile variable for shared libraries goes back to Modules/[EMAIL PROTECTED], which first introduced dynamic loading (in 1994). 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] Sharing expat instances
[Fredrik Lundh wrote]
> can anyone with a working windows setup look at building the
> _elementtree module for windows ?
>
> (see the setup.py file for build options; it wants the same defines
> as pyexpat, plus one extra define.).
C:\trentm\src\python\python\PCbuild>python
Python 2.5a0 (#60, Dec 15 2005, 11:17:15) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from _elementtree import Element, ElementTree
>>> root = Element("root")
>>> root.append(Element("one"))
>>> tree = ElementTree(root)
>>> import sys
>>> tree.write(sys.stdout)
>>>
C:\trentm\src\python\python\PCbuild>svn st
A _elementtree.vcproj
M pcbuild.sln
Shall I checkin the build changes?
Trent
--
Trent Mick
[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] Sharing expat instances
Trent Mick wrote: > C:\trentm\src\python\python\PCbuild>svn st > A _elementtree.vcproj > M pcbuild.sln > > Shall I checkin the build changes? Go ahead. A change to Tools/msi/msi.py is also in order. 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] Sharing expat instances
At 09:30 PM 12/15/2005 +0100, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > I don't know. I can see that the split makes sense for prefix/exec-prefix > > distinctions, but then again, the disutils will install an entire > > distribution in exec-prefix if it contains "impure" parts, so that's > > certainly an option here. > > > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > > directories exist, since it seems to me that that's what exec-prefix is > > for. > >Can you please explain? exec_prefix will point to, say, >/usr/i686; it shouldn't be that .so files are directly installed in >that location. Instead, Python searches them in >EXEC_PREFIX "/lib/python" VERSION "/lib-dynload". Right; the question is why not just EXEC_PREFIX "/lib/python" VERSION instead. What benefit does the separate directory offer? Note that the distutils, when installing a package containing C extensions, will install to site-packages under sys.exec_prefix; it does not separate the C extensions into special alternate library directories. ___ 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] Location of .so files (Was: Sharing expat instances)
Phillip J. Eby wrote: > Right; the question is why not just EXEC_PREFIX "/lib/python" VERSION > instead. What benefit does the separate directory offer? I can only guess: it's primarily a matter of tidiness. > Note that the distutils, when installing a package containing C > extensions, will install to site-packages under sys.exec_prefix; it > does not separate the C extensions into special alternate library > directories. Yes, that's inconsistent. One way to make it consistent would be to honor lib-dynload; the other to get rid of lib-dynload. I cannot see how one of these option is better than the other (nor can I see what the relevance for the expat discussion is, so I changed the subject). 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] Sharing expat instances
Trent Mick wrote:
> [Fredrik Lundh wrote]
> > can anyone with a working windows setup look at building the
> > _elementtree module for windows ?
> >
> > (see the setup.py file for build options; it wants the same defines
> > as pyexpat, plus one extra define.).
>
> C:\trentm\src\python\python\PCbuild>python
> Python 2.5a0 (#60, Dec 15 2005, 11:17:15) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from _elementtree import Element, ElementTree
> >>> root = Element("root")
> >>> root.append(Element("one"))
> >>> tree = ElementTree(root)
> >>> import sys
> >>> tree.write(sys.stdout)
> >>>
most excellent!
> C:\trentm\src\python\python\PCbuild>svn st
> A _elementtree.vcproj
> M pcbuild.sln
>
> Shall I checkin the build changes?
I sure won't stop you.
thanks! /F
___
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] Location of .so files (Was: Sharing expat instances)
At 10:14 PM 12/15/2005 +0100, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > Right; the question is why not just EXEC_PREFIX "/lib/python" VERSION > > instead. What benefit does the separate directory offer? > >I can only guess: it's primarily a matter of tidiness. > > > Note that the distutils, when installing a package containing C > > extensions, will install to site-packages under sys.exec_prefix; it > > does not separate the C extensions into special alternate library > > directories. > >Yes, that's inconsistent. One way to make it consistent would be to >honor lib-dynload; the other to get rid of lib-dynload. I cannot see >how one of these option is better than the other (nor can I see >what the relevance for the expat discussion is, so I changed the >subject). The relevance to "sharing expat instances" was Fredrik's original question about placement of the shared library for cElementTree. The question wasn't whether to get rid of lib-dynload in general, but whether there was any reason to do something other than just making ElementTree a distutils-installed package with the C extensions inside, the way normal distutils-installed packages are. In any case the discussion is probably moot by now if ElementTree is now already built as part of the core. ___ 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] Location of .so files (Was: Sharing expat instances)
Phillip J. Eby wrote: > The relevance to "sharing expat instances" was Fredrik's original > question about placement of the shared library for cElementTree. The > question wasn't whether to get rid of lib-dynload in general, but > whether there was any reason to do something other than just making > ElementTree a distutils-installed package with the C extensions inside, > the way normal distutils-installed packages are. I understood the question was whether specifically to place cElementTree into xml.etree; I think such scenarios had been avoided because people want to run Python from the build tree, both on Unix and Windows. This breaks if the extension modules are expected in packages, rather than being toplevel. Whether or not they then end up in lib-dynload is a different issue; as I said, I can't see anything wrong with it. 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] PEP 8 updates/clarifications, function/method style
On Thu, 2005-12-15 at 11:22 +0100, [EMAIL PROTECTED] wrote: > I hope new stuff will follow only one naming style. And now we should > (or one person :-) should) decide which one. I guess my point boils down to, we already did decide 4 years ago. Let's stick with what we've got. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PEP 8 updates/clarifications
On Thu, 2005-12-15 at 11:35 -0800, Josiah Carlson wrote: > In regards to naming conventions, I find that CapWords are easier for me > to read and remember as a native speaker of english. I've heard > statements from non-native english speakers that CapWords are hard to > read and/or understand, but in the realm of wxPython, changing literally > thousands of CapWords references to lower_underscore during wrapping, > along with the hundreds of thousands of references in just a few of the > larger wxPython projects is a bit out of line. Or even convincing the > hundreds of other packages which use CapWords or lower_underscore to > change how their naming conventions work is going to be a tough fight. None of which PEP 8 recommends (in fact, it strongly recommends against massive renames). What PEP 8 is saying is that /new/ code, especially new code intended for the stdlib, should follow the PEP's guidelines. Which is why I think we need one strong recommendation. Over time, as modules are naturally updated or supplanted, we'll get more consistency in the stdlib across packages. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Sharing expat instances
[Martin v. Loewis wrote] > Trent Mick wrote: > > C:\trentm\src\python\python\PCbuild>svn st > > A _elementtree.vcproj > > M pcbuild.sln > > > > Shall I checkin the build changes? > > Go ahead. A change to Tools/msi/msi.py is also in order. Okay, done. I naively added "_elementtree" to the extensions list in msi.py. I'm guessing that that was all that was necessary. Trent -- Trent Mick [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] Sharing expat instances
Trent Mick wrote: > Okay, done. I naively added "_elementtree" to the extensions list in > msi.py. I'm guessing that that was all that was necessary. Right. Thanks! 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
[Python-Dev] Expose Subversion revision number to Python
SF patch # 1382163 is a fairly simple patch to expose the Subversion revision number to Python, both in the Py_GetBuildInfo() text, and in a new Py_GetBuildNumber() C API function, and via a new sys.build_number attribute. This number is calculated from the output of "svn info" at the top of the tree. If not building Python from a Subversion checkout, the old way of calculating buildno is kept. (Of course, this change only gets the right number into the Unix build. Someone else can hopefully add the necessary magic for Windows. Patch tested only on Linux though.) Is there any interest in this patch? I'm happy to commit it if there are no objections. -Barry Python 2.5a0 (#41708, Dec 15 2005, 23:59:14) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.build_number 41708 >>> signature.asc Description: This is a digitally signed message part ___ 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] Expose Subversion revision number to Python
On 12/15/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > SF patch # 1382163 is a fairly simple patch to expose the Subversion > revision number to Python, both in the Py_GetBuildInfo() text, and in a > new Py_GetBuildNumber() C API function, and via a new sys.build_number > attribute. This number is calculated from the output of "svn info" at > the top of the tree. If not building Python from a Subversion checkout, > the old way of calculating buildno is kept. > > (Of course, this change only gets the right number into the Unix build. > Someone else can hopefully add the necessary magic for Windows. Patch > tested only on Linux though.) > > Is there any interest in this patch? I'm happy to commit it if there > are no objections. > > -Barry > > Python 2.5a0 (#41708, Dec 15 2005, 23:59:14) > [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.build_number > 41708 +0 It makes it easy to request the revision number from people who submit patches and bugs. But I also don't find it vital since running ``svn info .``. -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] Expose Subversion revision number to Python
At 12:16 AM 12/16/2005 -0500, Barry Warsaw wrote: >SF patch # 1382163 is a fairly simple patch to expose the Subversion >revision number to Python, both in the Py_GetBuildInfo() text, and in a >new Py_GetBuildNumber() C API function, and via a new sys.build_number >attribute. This number is calculated from the output of "svn info" at >the top of the tree. FYI, this is not the true revision number; it's only the revision number in which the directory was last modified, not the latest revision number within the tree. You probably want to do a bit more processing of "svn info -R", or else parse the .svn/entries files yourself. There's some Python code that does this at: http://svn.python.org/projects/sandbox/trunk/setuptools/setuptools/command/egg_info.py Specifically, see the 'get_svn_revision' method for an example of processing .svn/entries files to find out the highest committed revision number in a source tree. ___ 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
