In a message of Sat, 31 Dec 2005 15:41:50 +1000, Nick Coghlan writes:
>Ian Bicking wrote:
>> Anyway, another even more expedient option would be setting up a
>> separate bug tracker (something simpler to submit to than SF) and
>> putting a link on the bottom of every page, maybe like:
>> -- heck, we all know SF bug tracking sucks, this is a good chance to
>> experiment with a different tracker, and documentation has softer
>> requirements other parts of Python.
>While I quite like this idea, would it make it more difficult when the bu
>tracking for the main source code is eventually migrated off SF? And what
>would happen to existing documentation bug reports/patches on the SF trac
>Is it possible to do something similar for the online version of the curr
>docs, simply pointing them at the SF tracker? (I know this doesn't help p
>without an SF account. . .)
Not if the problem is that documentation changes are not 'patches' and
'bugs' and the sourceforge bug tracker, which isn't even particularly
good at tracking bugs is particularly ill-suited for the collaborative
sharing of documents.
Grant Crawley wrote:
> no worries....I assume that we will be gaming till somewhat late?
Well, Monday's a public holiday, so. . .
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the question for Python 2.*, but
it would be nice to keep these in mind for Python 3K.
Constants in all caps:
NONE, TRUE, FALSE, ELLIPSIS
Classes in initial-caps:
Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict,
and lots of classes in the standard library, e.g.
anydbm.error, csv.excel, imaplib.error, mutex.mutex...
I know these probably look a little funny now to most of us, as
we're used to looking at today's Python (they even look a little
funny to me) but i'm pretty convinced that consistency will be
better in the long run.
> Constants in all caps:
> NONE, TRUE, FALSE, ELLIPSIS
> Classes in initial-caps:
> Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict,
> and lots of classes in the standard library, e.g.
> anydbm.error, csv.excel, imaplib.error, mutex.mutex...
(All that follows is just my opinion. Feel free to disregard.)
1. PEP 8 is just some recommended conventions, not absolute rules.
2. "None", "True", and "False" are the divinely inspired correct
spellings of these objects. All caps would be incorrect.
3. "object", "int", "float", "str", "unicode", "set", "list",
"tuple", and "dict" all follow the common convention that the
fundamental built-in types are in all lowercase. Note that I
am distinguishing between built-in types and standard library
types. I rather like this convention and would favor keeping
4. I am a big fan of consistancy in naming. I try to follow PEP 8
in my own code, even when I don't think it's as pretty as some
other practice. But I just don't think the consistancy is worth
the cost of breaking existing code. Python 3000 is ALLOWED to
break code, but that doesn't mean it should do so gratuitously
or break more code than necessary.
5. For some of the classes within the standard library I'm much
more open to being convinced. They are less often used, thus
more suitable for a global fix-and-replace or at tweak to the
input statements at the top of the file. Being less frequently
used also means that consistancy in naming is more important
because people don't necessarily use these every day.
-- Michael Chermside
The F-bot writes:
> in reality, some things are carefully thought out and craftily im-
> plemented, some things are engineering tradeoffs made at a certain time,
> and some things are just accidents -- but python-dev will happily defend
> the current solution with the same energy, no matter what it is.
Seriously... I've seen this behavior also, but I haven't ever thought
about it as clearly as Fredrik does here. When we go to answer questions
we ought to pause briefly first and decide which of these categories
applies to a given piece of behavior. I think users will be understanding
if we're honest about what are the accidents -- every language or
software package has some, and just because it's an accident does NOT
mean we should "fix" it.
-- Michael Chermside
We have a bunch of C++ extensions (Boost.Python) that work fine under
Windows when compiled with Visual C++ 7.1. With a few minor tweaks
all extensions also compile with Visual C++ 8.0, but trying to "import"
any of the extensions fails with this message (shown in a pop-up box):
This application has failed to start because MSVCP80.dll was
not found. Re-installing the application may fix this problem.
I am using a Visual Studio 2005 Professional installation. I also ran
vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't
help. However, standalone executables work OK without any gymnastics.
Does anyone know what the problem could be with the extensions?
A quick attempt to compile Python from scratch using Visual C++ 8.0
produced a python.exe, but it doesn't run (the debug / send report /
don't send report box pops up). Has someone tried this before?
someone recently broke floating point literals in a rather spectacular
$ export LANG=sv_SE.utf8
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
While working with Subversion's python API bindings this morning, I
discovered a function in one of their modules illegally named "import"
(svn.client.import, for the curious). Because the extension module in
question is written in C, the interpreter doesn't flag the
otherwise-illegal identifier "import" at compile-time; if you try to
call the function at runtime, however, the interpreter raises a
SyntaxError, since svn.client.import is an illegal name.
My question is this: is there any interest in preventing situations
like this by including checks in Python/modsupport.c:Py_InitModule4 to
make sure that the PyMethodDef contains only valid identifiers, or is
this a case of "if it hurts when you do that, don't do that"? I can
see a case for both sides: on the one hand, it would be nice to
prevent people from accidentally creating inaccessible objects. On the
other hand, perhaps this is a job that should be given to tools like
SWIG, since they're the ones actually generating the bindings (in the
case of SVN).
I've already reported this to the SVN people, but if there's any
interest in a CPython-side solution, I'm more than willing to work up
a patch to modsupport.c.
There's a bug about number coercion about Decimal
The bug appeared after some changes Raymond and I did a few months
ago, solving something else (started to return NotImplemented instead
of raising TypeError, to better work with custom objects that
implements type coercion from Decimal).
The point is that I'm really astonished about the following behaviour,
and don't know where to start searching:
Decimal("1") # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +:
>>> d += 1.2
Thanks for any tip.
Guido sez in
that it is not correct to recommend using ``file()`` instead of
``open()``. However, because ``open()`` currently *is* an alias to
``file()``, we end up with the following problem (verified in current
HEAD) where doing ``help(open)`` brings up the docs for ``file()``:
Help on class file in module __builtin__:
| file(name[, mode[, buffering]]) -> file object
| Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
| Note: open() is an alias for file().
This is confusing. I suggest that we make ``open()`` a factory function
right now. (I'll submit a bug report (and possibly a patch) after I get
Aahz (aahz(a)pythoncraft.com) <*> 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)