Mailman 3 December 2005 - Python-Dev

Re: [Python-Dev] [Doc-SIG] that library reference, again
by Laura Creighton 31 Dec '05

31 Dec '05

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: >> http://trac.python.org/trac/newticket?summary=re:+/path/to/doc&componen >t=docs >> -- 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 >g >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 >kers? > >Is it possible to do something similar for the online version of the curr >ent >docs, simply pointing them at the SF tracker? (I know this doesn't help p >eople >without an SF account. . .) > >Cheers, >Nick. 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. Laura

1 0

Re: [Python-Dev] Gaming on Sunday (Jan 1)
by Nick Coghlan 30 Dec '05

30 Dec '05

Grant Crawley wrote: > no worries....I assume that we will be gaming till somewhat late? Well, Monday's a public holiday, so. . . Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

1 1

Naming conventions in Py3K
by Ka-Ping Yee 30 Dec '05

30 Dec '05

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. -- ?!ng

9 14

Re: [Python-Dev] Naming conventions in Py3K
by Michael Chermside 30 Dec '05

30 Dec '05

?!ng proposes: > 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 it. 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

1 0

Re: [Python-Dev] a quit that actually quits
by Michael Chermside 30 Dec '05

30 Dec '05

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. +1 QOTF. 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

5 5

Python + Visual C++ 8.0?
by Ralf W. Grosse-Kunstleve 30 Dec '05

30 Dec '05

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? Cheers, Ralf

3 8

floating point literals don't work in non-US locale in 2.5
by Fredrik Lundh 29 Dec '05

29 Dec '05

someone recently broke floating point literals in a rather spectacular way: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 more here: http://www.python.org/sf/1391872 </F>

2 2

Bug in Py_InitModule4
by Collin Winter 29 Dec '05

29 Dec '05

Hello 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. Thanks, Collin Winter

2 1

NotImplemented reaching top-level
by Facundo Batista 29 Dec '05

29 Dec '05

Folks, There's a bug about number coercion about Decimal (http://www.python.org/sf/1355842). 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: >>> d 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 +: 'Decimal' and 'float' >>> d += 1.2 >>> d NotImplemented >>> Thanks for any tip. . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

7 13

file() vs open(), round 7
by Aahz 29 Dec '05

29 Dec '05

Guido sez in http://mail.python.org/pipermail/python-dev/2004-July/045921.html 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(open) Help on class file in module __builtin__: class file(object) | 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 agreement.) -- 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)

6 14