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=detailaid=1339673group_id=5470atid=305470
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
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
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
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
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
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
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
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
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,
[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
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.
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
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
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
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
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
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
[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\PCbuildpython
Python 2.5a0 (#60,
Trent Mick wrote:
C:\trentm\src\python\python\PCbuildsvn 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
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
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
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
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
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
[Martin v. Loewis wrote]
Trent Mick wrote:
C:\trentm\src\python\python\PCbuildsvn 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
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
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
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
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
30 matches
Mail list logo
