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 calcul
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
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 t
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
Python-Dev@python.org
http://mail.python.org/mailman/
[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 "_elem
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, b
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
signatu
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
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 distutil
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\
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 in
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
>
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
[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
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 n
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 an
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
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
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,
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
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 rule
[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 'tex
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.
> >
>
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 s
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 ob
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 poss
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
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 ;) pro
> 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 fol
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 substant
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 an
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
Gre
32 matches
Mail list logo
