Re: [Python-Dev] #ifdef __cplusplus?

[Alexander Belopolsky]

On Fri, Jan 2, 2009 at 2:26 AM, Adam Olsen  wrote:
..
> Compiling as C++ is too obscure of a feature to warrant uglifying the
> code.

Malloc casts may be hard to defend, but most of python code base
already has them, there is little to be gained from having these casts
in some places and not others.  There are other design flaws that a
C++ compiler may help to catch.  Two examples that come to mind are
use of void* where a typed pointer is a better match and declaring
external functions in .c file instead of including an appropriate
header.  In most cases keeping in mind compliance with C++ leads to
better design, not to uglier code.

With respect to the OP's issue, I have added another patch to
http://bugs.python.org/issue4805 .
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Adam Olsen]

On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
 wrote:
> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen  wrote:
> ..
>>
>> As C++ has more specific ways of allocating memory, they impose this
>> restriction to annoy you into using them.
>
> And so does Python API: see PyMem_NEW and PyMem_RESIZE macros.

An optional second API provides convenience, not annoyance.  Besides,
they're not used much anymore.  I am curious what their history is
though.


>>  We won't be using them, and the extra casts and nothing but noise.
>
> A quick grep through the sources shows that these casts are not just nose:
>
> Objects/stringobject.c: op = (PyStringObject *)PyObject_MALLOC(..
> Objects/typeobject.c:   remain = (int *)PyMem_MALLOC(..
> Objects/unicodeobject.c:unicode->str = (Py_UNICODE*) 
> PyObject_MALLOC(..
>
> in many cases the type of object being allocated is not obvious from
> the l.h.s. name.  Redundant cast improves readability in these cases.

Python's malloc wrappers are pretty messy.  Of your examples, only
unicode->str isn't obvious what the result is, as the rest are local
to that function.  Even that is obvious when you glance at the line
above, where the size is calculated using sizeof(Py_UNICODE).

If you're concerned about correctness then you'd do better eliminating
the redundant malloc wrappers and giving them names that directly
match what they can be used for.

If the size calculation bothers you you could include the semantics of
the PyMem_New() API, which includes the cast you want.  I've no
opposition to including casts in a single place like that (and it
would catch errors even with C compilation).


>>  Figure out a way to turn off the warnings instead.
>>
> These are not warnings: these are compile errors in C++.  A compiler
> which allows to suppress them would not be a standard compliant C++
> compiler.

So long as the major compilers allow it I don't particularly care.
Compiling as C++ is too obscure of a feature to warrant uglifying the
code.


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] floatformat vs float_format

[David Cournapeau]

On Thu, Jan 1, 2009 at 6:43 PM, Eric Smith  wrote:
> David Cournapeau wrote:
>>
>> Hi,
>>
>> In python 2.6, there have been some effort to make float formatting
>> more consistent between platforms, which is nice. Unfortunately, there
>> is still one corner case, for example on windows:
>>
>> print a -> print 'inf'
>> print '%f' % a -> print '1.#INF'
>>
>> The difference being that in the second case, the formatting is done
>> in floatformat.c (in stringobject.c), whereas in the first case, it is
>> done in format_float (in floatobject.c). Shouldn't both functions be
>> calling the same underlying implementation, to avoid those
>> inconsistencies ?
>
> Yes, float formatting definitely needs some rationalization.
>
> While this isn't the exact issue discussed in
> http://bugs.python.org/issue3382, it is related, and Windows is the reason I
> had to back my fix out right before the freeze for 2.6 and 3.0. It's on my
> list of things to fix.
>
> http://bugs.python.org/issue4482 might also be related, and I'll fix that,
> too.
>
> If you could either add a comment to 3382 (with this test case) or open
> another bug and assign it to me (eric.smith), I'd appreciate it.

I did open a new bug, with a first not-so-good patch at
http://bugs.python.org/issue4799

I am not so familiar with python core code organization: where should
a function used by several core objects (here floatobjects.c and
stringobject.c, and potentially complexobject.c as well later) go ?
Since the float_format is private, is it OK to change its API (to
return a potential error instead of no return value) ?

thanks,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Alexander Belopolsky]

On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen  wrote:
..
>
> As C++ has more specific ways of allocating memory, they impose this
> restriction to annoy you into using them.

And so does Python API: see PyMem_NEW and PyMem_RESIZE macros.

>  We won't be using them, and the extra casts and nothing but noise.

A quick grep through the sources shows that these casts are not just nose:

Objects/stringobject.c: op = (PyStringObject *)PyObject_MALLOC(..
Objects/typeobject.c:   remain = (int *)PyMem_MALLOC(..
Objects/unicodeobject.c:unicode->str = (Py_UNICODE*) PyObject_MALLOC(..

in many cases the type of object being allocated is not obvious from
the l.h.s. name.  Redundant cast improves readability in these cases.

>  Figure out a way to turn off the warnings instead.
>
These are not warnings: these are compile errors in C++.  A compiler
which allows to suppress them would not be a standard compliant C++
compiler.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Adam Olsen]

On Thu, Jan 1, 2009 at 10:17 PM, Alexander Belopolsky
 wrote:
> On Thu, Jan 1, 2009 at 11:05 PM, Christian Heimes  wrote:
> ..
>> You might be interested in the bug report
>> http://bugs.python.org/issue4665. Skip pointed out that Python 2.6 no
>> longer compiles with a C++ compiler due to missing casts. C++ is more
>> restrict when it comes to implicit casts from (amongst others) void
>> pointers.
>>
> Since that issue is closed, I have created
> http://bugs.python.org/issue4805 with a patch that restores C++
> compilability of the core and a few standard modules.

As C++ has more specific ways of allocating memory, they impose this
restriction to annoy you into using them.  We won't be using them, and
the extra casts and nothing but noise.  Figure out a way to turn off
the warnings instead.

http://www.research.att.com/~bs/bs_faq2.html#void-ptr


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Alexander Belopolsky]

On Thu, Jan 1, 2009 at 11:05 PM, Christian Heimes  wrote:
..
> You might be interested in the bug report
> http://bugs.python.org/issue4665. Skip pointed out that Python 2.6 no
> longer compiles with a C++ compiler due to missing casts. C++ is more
> restrict when it comes to implicit casts from (amongst others) void
> pointers.
>
Since that issue is closed, I have created
http://bugs.python.org/issue4805 with a patch that restores C++
compilability of the core and a few standard modules.

> Martin is against the necessary changes. I don't really care about it.
> If somebody wants to tackle the issue I'm fine with sprinkling some type
> casts over the code.
>
I've listed the following arguments in support maintaining C++
compilability on the bug tracker:

"""
1. It is hard to verify that header files are compilable if source code
is not.  With compilable source code, CC=g++ ./configure; make will
supply an adequate test that does not require anything beyond a standard
distribution.

2. Arguably, C++ compliant code is more consistent and less error prone.
For example, "new" is a really bad choice for a variable name regardless
of being a C++ keyword, especially when used instead of prevailing "res"
for a result of a function producing a PyObject. Even clearly redundant
explicit casts of malloc return values arguably improve readability by
reminding the type of the object that is being allocated.

3. Compiling with C++ may reveal actual coding errors that otherwise
go unnoticed.  For example, use of undefined
PyLong_BASE_TWODIGITS_TYPE in Objects/longobject.c.

4. Stricter type checking may promote use of specific types instead of
void* which in turn may help optimizing compilers.

5. Once achieved, C++ compilability is not that hard to maintain, but
restoring it with patches like this one is hard because it requires
review of changes to many unrelated files.
"""

Note that this discussion has deviated from OP's original question.
While I argue that C++ compilability of source code is good thing, I
agree with OP that wrapping non-header file code in extern "C" {} is
bad practice.  For example, the only reason Objects/fileobject.c does
not compile without extern "C" {} is because fclose is declared inside
PyFile_FromString as follows:

 PyObject *
 PyFile_FromString(char *name, char *mode)
 {
extern int fclose(FILE *);
 ..

I would rather #include  at the top of the file instead.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Christian Heimes]

Alexander Belopolsky schrieb:
> The relevant revision is r45330:
> .
> 
> """
> Author:   anthony.baxter
> Date: Thu Apr 13 02:06:09 2006 UTC (2 years, 8 months ago)
> Log Message:
> spread the extern "C" { } magic pixie dust around. Python itself builds now
> using a C++ compiler. Still lots and lots of errors in the modules built by
> setup.py, and a bunch of warnings from g++ in the core.
> """
> 
> Wrapping code inside .c files in  extern "C" { }  strikes me as a lazy
> solution.  It is likely that g++ warnings that were silenced by that
> change were indicative of either functions not declared in headers
> missing "static" keyword or .c files not including relevant headers.
> 
> If OP has energy to investigate this issue further, it would be
> interesting to revert  r45330 and recompile python with CC=g++.

You might be interested in the bug report
http://bugs.python.org/issue4665. Skip pointed out that Python 2.6 no
longer compiles with a C++ compiler due to missing casts. C++ is more
restrict when it comes to implicit casts from (amongst others) void
pointers.

Martin is against the necessary changes. I don't really care about it.
If somebody wants to tackle the issue I'm fine with sprinkling some type
casts over the code.

This topic is slightly related to small feature request in
http://bugs.python.org/issue4558. It adds a configure option
--with-stdc89 and adds some small fixes to various modules. The
--with-stdc89 is dedicated for our build bots. In the past non ANSI C89
conform pieces of code like 'inline' or '// C++' comments were
committed. The --with-stdc89 options adds a canonical way to detect such
errors at compile time.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Alexander Belopolsky]

The relevant revision is r45330:
.

"""
Author: anthony.baxter
Date:   Thu Apr 13 02:06:09 2006 UTC (2 years, 8 months ago)
Log Message:
spread the extern "C" { } magic pixie dust around. Python itself builds now
using a C++ compiler. Still lots and lots of errors in the modules built by
setup.py, and a bunch of warnings from g++ in the core.
"""

Wrapping code inside .c files in  extern "C" { }  strikes me as a lazy
solution.  It is likely that g++ warnings that were silenced by that
change were indicative of either functions not declared in headers
missing "static" keyword or .c files not including relevant headers.

If OP has energy to investigate this issue further, it would be
interesting to revert  r45330 and recompile python with CC=g++.



On Thu, Jan 1, 2009 at 6:54 PM, Nick Coghlan  wrote:
> Ulrich Eckhardt wrote:
>> Hi!
>>
>> There are lots of files that are framed with an extern "C" stanza when
>> compiled under C++. Now, I appreciate that header files are made suitable for
>> use with C++ with that, but WTF are those doing in .c files???
>
> I believe it is to allow building the Python source as an embedded part
> of an external application that is built with a C++ compiler, even when
> that compiler isn't clever enough to realise that the 'extern "C"'
> should be implied by the '.c' file extension.
>
> I didn't add those lines though - I suggest doing an SVN annotate on
> some of the affected source files, and looking at the associated checkin
> comments.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #ifdef __cplusplus?

[Nick Coghlan]

Ulrich Eckhardt wrote:
> Hi!
> 
> There are lots of files that are framed with an extern "C" stanza when 
> compiled under C++. Now, I appreciate that header files are made suitable for 
> use with C++ with that, but WTF are those doing in .c files???

I believe it is to allow building the Python source as an embedded part
of an external application that is built with a C++ compiler, even when
that compiler isn't clever enough to realise that the 'extern "C"'
should be implied by the '.c' file extension.

I didn't add those lines though - I suggest doing an SVN annotate on
some of the affected source files, and looking at the associated checkin
comments.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_subprocess and sparc buildbots

[Nick Coghlan]

Daniel (ajax) Diniz wrote:
> Georg Brandl  wrote:
>> This only occurs --with-pydebug, I assume?
> 
> For me, on 32 bits Linux, yes, only --with-pydebug*.
> 
>> It is the same basic problem as in http://bugs.python.org/issue3299,
>> which I analysed some time ago.
> 
> Yes, I guess my 'catch' is exactly that. But it might be a red herring
> (sorry if that's the case): is the correlation with sparc and/or
> rev.67888 real?

The correlation with sparc probably isn't real (that was just a
subjective impression on my part based on the buildbot failure emails).
When --with-pydebug is enabled, I can reproduce the fault (as posted by
Alexandre) on 32-bit x86 Linux.

There may be a specific issue with the klose buildbots, but the crash in
the object deallocation is obscuring the original problem.

I'll put further comment on the issue Georg linked.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_subprocess and sparc buildbots

[Daniel (ajax) Diniz]

Georg Brandl  wrote:
>
> This only occurs --with-pydebug, I assume?

For me, on 32 bits Linux, yes, only --with-pydebug*.

> It is the same basic problem as in http://bugs.python.org/issue3299,
> which I analysed some time ago.

Yes, I guess my 'catch' is exactly that. But it might be a red herring
(sorry if that's the case): is the correlation with sparc and/or
rev.67888 real?

Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] #ifdef __cplusplus?

[Ulrich Eckhardt]

Hi!

There are lots of files that are framed with an extern "C" stanza when 
compiled under C++. Now, I appreciate that header files are made suitable for 
use with C++ with that, but WTF are those doing in .c files???

puzzled greetings

Uli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_subprocess and sparc buildbots

[Georg Brandl]

Alexandre Vassalotti schrieb:
> On Tue, Dec 30, 2008 at 10:41 PM, Daniel (ajax) Diniz  
> wrote:
>> A reliable way to get that in a --with-pydebug build seems to be:
>>
>> ~/py3k$ ./python -c "import locale; locale.format_string(1,1)"
>> * ob
>> object  : 
>> type: tuple
>> refcount: 0
>> address : 0x825c76c
>> * op->_ob_prev->_ob_next
>> NULL
>> * op->_ob_next->_ob_prev
>> object  : 
>> type: tuple
>> refcount: 0
>> address : 0x825c76c
>> Fatal Python error: UNREF invalid object
>> TypeError: expected string or buffer
>> Aborted
>>
> 
> Nice catch! I reduced your example to: "import _sre;  _sre.compile(0,
> 0, [])". And, it doesn't seem to be an input validation problem with
> _sre. From what I saw, it's actually a bug in Py_TRACE_REFS's code.
> Now, it's getting interesting!
> 
> It seems something is breaking the refchain. However, I don't know
> what is causing the problem exactly.

This only occurs --with-pydebug, I assume?

It is the same basic problem as in http://bugs.python.org/issue3299,
which I analysed some time ago.  Simply speaking, it is caused by
the object allocation and deallocation scheme that _sre chooses:
if _compile's argument processing raises an error, PyObject_DEL is
called which doesn't remove the object from the refchain.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] patch suggestion for webbrowser

[Oleg Broytmann]

On Thu, Jan 01, 2009 at 02:24:02PM +0200, Yinon Ehrlich wrote:
> enclosed a patch for webbrowser which will find applications/batch files  
> ending with .com or .cmd too.

   Please submit the patch to the issue tracker: http://bugs.python.org/

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] patch suggestion for webbrowser

[Yinon Ehrlich]

Hi,

enclosed a patch for webbrowser which will find applications/batch files 
ending with .com or .cmd too.

Yinon

Index: Lib/webbrowser.py
===
--- Lib/webbrowser.py(revision 68118)
+++ Lib/webbrowser.py(working copy)
@@ -103,10 +103,11 @@

if sys.platform[:3] == "win":
def _isexecutable(cmd):
+win_exts = (".exe", ".com", ".bat", ".cmd")
cmd = cmd.lower()
-if os.path.isfile(cmd) and cmd.endswith((".exe", ".bat")):
+if os.path.isfile(cmd) and cmd.endswith(win_exts):
return True
-for ext in ".exe", ".bat":
+for ext in win_exts:
if os.path.isfile(cmd + ext):
return True
return False

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] floatformat vs float_format

[Eric Smith]

David Cournapeau wrote:

Hi,

In python 2.6, there have been some effort to make float formatting
more consistent between platforms, which is nice. Unfortunately, there
is still one corner case, for example on windows:

print a -> print 'inf'
print '%f' % a -> print '1.#INF'

The difference being that in the second case, the formatting is done
in floatformat.c (in stringobject.c), whereas in the first case, it is
done in format_float (in floatobject.c). Shouldn't both functions be
calling the same underlying implementation, to avoid those
inconsistencies ?


Yes, float formatting definitely needs some rationalization.

While this isn't the exact issue discussed in 
http://bugs.python.org/issue3382, it is related, and Windows is the 
reason I had to back my fix out right before the freeze for 2.6 and 3.0. 
It's on my list of things to fix.


http://bugs.python.org/issue4482 might also be related, and I'll fix 
that, too.


If you could either add a comment to 3382 (with this test case) or open 
another bug and assign it to me (eric.smith), I'd appreciate it.


Happy New Year, all!

Eric.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com