Re: [Python-Dev] #ifdef __cplusplus?

[David Cournapeau]

On Fri, Jan 2, 2009 at 4:51 PM, Alexander Belopolsky
 wrote:
> 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.

Can't those errors be found simply using appropriate warning flags in
the C compiler ?  C has stopped being a subset of C++ a long time ago

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?

[Ulrich Eckhardt]

On Friday 02 January 2009 06:17:24 Alexander Belopolsky wrote:
> 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.

Looking at the patch, I see three main changes there:
1. Remove the extern "C" stanza from the .c files.
2. Add explicit casts where necessary for C++.
3. Include headers instead of locally declaring functions and adding some 
declarations to headers.

In particular the third part of above, I personally would definitely vote a 
+1. Since the first one is only necessary because things are declared 
sloppily, I'm also +1 on that one, i.e. #3 makes #1 possible.

As far as the second part is concerned, I personally wouldn't bother getting 
Python to compile with a C++ compiler. I'd also like to point out that a 
missing declaration of e.g. malloc(), and the ensuing implicit declaration 
as "int malloc(int)" will be hidden when there's an explicit cast, which is 
why e.g. the comp.lang.c FAQ is against it.

> 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.

This is change #3 above, and I'm all for it. I'm actually surprised that this 
code has actually escaped the peer review here.

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

[Python-Dev] ParseTuple question

[Ulrich Eckhardt]

Hi!

I'm looking at NullImporter_init in import.c and especially at the call to 
PyArg_ParseTuple there. What I'm wondering is what that call will do when I 
call the function with a Unicode object. Will it convert the Unicode to a 
char string first, will it return the Unicode object in a certain (default) 
encoding, will it fail?

I'm working on the MS Windows CE port, and I don't have stat() there. Also, I 
don't have GetFileAttributesA(char const*) there, so I need a wchar_t 
(UTF-16) string anyway. What would be the best way to get one?

Thanks!

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] opcode dispatch optimization

[Nicolas Trangez]

On Wed, 2008-12-31 at 12:51 -0600, Jason Orendorff wrote:
> On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes  wrote:
> > The patch makes use of a GCC feature where labels can be used as values:
> > http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know
> > about the feature and got confused by the unary && operator.
> 
> Right.  SpiderMonkey (Mozilla's JavaScript interpreter) does this, and
> it was good for a similar win on platforms that use GCC.  (It took me
> a while to figure out why it was so much faster, so I think this patch
> would be better with a few very specific comments!)
> 
> SpiderMonkey calls this optimization "threaded code" too, but this
> isn't the standard meaning of that term. See:
> http://en.wikipedia.org/wiki/Threaded_code

FWIW, it's also explained pretty well in the first pages of [1].
WebKit's SquirrelFish is direct-threaded as well [2].

Nicolas

[1]
http://citeseer.ist.psu.edu/cache/papers/cs/32018/http:zSzzSzwww.jilp.orgzSzvol5zSzv5paper12.pdf/ertl03structure.pdf
[2] http://webkit.org/blog/189/announcing-squirrelfish/

___
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?

[M.-A. Lemburg]

On 2009-01-02 00:54, 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, 

That's the reason, yes.

Mixing .c and .cpp files in a compiler call will not always cause
an implicit extern "C" to be used for the .c files. This causes problems
for cases where you rely on the naming of the exported functions, e.g.
for the module init function. C++ mangles all exported symbols. extern "C"
disables this.

AFAIR, early versions of MS VC++ used to compile everything as C++
file, regardless of the extension.

> even when
> that compiler isn't clever enough to realise that the 'extern "C"'
> should be implied by the '.c' file extension.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 02 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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?

[M.-A. Lemburg]

On 2009-01-02 08:26, Adam Olsen wrote:
> 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.

See Include/pymem.h and objimpl.h for details.

PyMem_MALLOC() et al. provide an abstraction layer on top of the system's
malloc() implementation. PyObject_MALLOC() et al. use the Python
memory allocator instead.

>>>  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.

??? Please read the comments in pymem.h and objimpl.h.

> 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).

You should always use PyMem_NEW() (capital letters), if you ever
intend to benefit from the memory allocation debug facilities
in the Python memory allocation interfaces.

The difference between using the _NEW() macros and the _MALLOC()
macros is that the first apply overflow checking for you. However,
the added overhead only makes sense if these overflow haven't
already been applied elsewhere.

>>>  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.
> 
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 02 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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]

David Cournapeau schrieb:
> Can't those errors be found simply using appropriate warning flags in
> the C compiler ?  C has stopped being a subset of C++ a long time ago

Python's C code still follow the ANSI C89 standard. The fact puts 'long
time ago' in a different perspective. :)
___
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?

[Curt Hagenlocher]

On Fri, Jan 2, 2009 at 8:35 AM, Christian Heimes  wrote:
>
> David Cournapeau schrieb:
>> Can't those errors be found simply using appropriate warning flags in
>> the C compiler ?  C has stopped being a subset of C++ a long time ago
>
> Python's C code still follow the ANSI C89 standard. The fact puts 'long
> time ago' in a different perspective. :)

...and many of us can still remember when Python's source was "K&R C" :)

--
Curt Hagenlocher
c...@hagenlocher.org
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (12/26/08 - 01/02/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2261 open (+32) / 14372 closed (+27) / 16633 total (+59)

Open issues with patches:   771

Average duration of open issues: 708 days.
Median duration of open issues: 2759 days.

Open Issues Breakdown
   open  2237 (+32)
pending24 ( +0)

Issues Created Or Reopened (60)
___

[distutils] - error when processing the "--formats=tar" option   12/27/08
   http://bugs.python.org/issue1885reopened tarek 
   patch   

Error in SocketServer UDP documentation  12/26/08
CLOSED http://bugs.python.org/issue4752created  shazow
   

Faster opcode dispatch on gcc12/26/08
   http://bugs.python.org/issue4753created  pitrou
   patch   

winsound documentation (about stoping sounds)12/26/08
CLOSED http://bugs.python.org/issue4754created  ocean-city
   patch   

Common path prefix   12/27/08
   http://bugs.python.org/issue4755created  skip.montanaro
   patch, patch, needs review  

zipfile.is_zipfile: added support for file-like objects  12/27/08
CLOSED http://bugs.python.org/issue4756created  gagenellina   
   patch   

reject unicode in zlib   12/27/08
   http://bugs.python.org/issue4757created  haypo 
   patch   

Python 3.0 internet documentation needs work 12/27/08
   http://bugs.python.org/issue4758created  beazley   
   

bytearray.translate() should support None first argument 12/27/08
CLOSED http://bugs.python.org/issue4759created  georg.brandl  
   patch   

cmp gone---What's new in 3.1 12/28/08
   http://bugs.python.org/issue4760created  LambertDW 
   

create Python wrappers for openat() and others   12/28/08
   http://bugs.python.org/issue4761created  pitrou
   

PyFile_FromFd() doesn't set the file name12/28/08
   http://bugs.python.org/issue4762created  haypo 
   

PyErr_GivenExceptionMatches documentation out of date12/28/08
CLOSED http://bugs.python.org/issue4763created  garcia
   

open('existing_dir') -> IOError instance's attr filename is None 12/29/08
CLOSED http://bugs.python.org/issue4764created  zuo   
   

IDLE fails to "Delete Custom Key Set" properly   12/29/08
   http://bugs.python.org/issue4765created  alex_fainshtein   
   

email documentation needs to be precise about strings/bytes  12/29/08
   http://bugs.python.org/issue4766created  beazley   
   

email.mime incorrectly documented (or implemented)   12/29/08
CLOSED http://bugs.python.org/issue4767created  beazley   
   

email.generator.Generator object bytes/str crash - b64encode() b 12/29/08
   http://bugs.python.org/issue4768created  beazley   
   patch   

b64decode should accept strings or bytes 12/29/08
   http://bugs.python.org/issue4769created  beazley   
   

binascii module, crazy error messages, unexpec

Re: [Python-Dev] A wart which should have been repaired in 3.0?

[Martin v. Löwis]

I propose a different solution to this commonprefix mess: eliminate
the function altogether. It is apparently too confusing to get right.

Regards,
Martin

___
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?

[David Cournapeau]

On Sat, Jan 3, 2009 at 1:35 AM, Christian Heimes  wrote:
> David Cournapeau schrieb:
>> Can't those errors be found simply using appropriate warning flags in
>> the C compiler ?  C has stopped being a subset of C++ a long time ago
>
> Python's C code still follow the ANSI C89 standard. The fact puts 'long
> time ago' in a different perspective. :)

In my mind, C++ is largely responsible for C not being a subset of
C++, so the type of C used by the codebase is not that important in
that context.

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] Python 3 - Mac Installer?

[Ronald Oussoren]

On 30 Dec, 2008, at 22:59, Benjamin Peterson wrote:

Seems that there are two ways to go.

Put back the Carbon and MacOS modules into 3.0.
Use Python 2 to build the python 3 package.


I've converted it back to 2.x for the time being. Eventually, I think
some 3.x bindings should be released.


For the record: I was my intention that the build-installer.py script  
works with /usr/bin/python on OSX 10.4 or later. That makes it  
possible to create a usable installer without first having to build a  
bootstrap version of python.


Ronald
___
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] A wart which should have been repaired in 3.0?

[Alexander Belopolsky]

On Fri, Jan 2, 2009 at 12:29 PM, "Martin v. Löwis"  wrote:
> I propose a different solution to this commonprefix mess: eliminate
> the function altogether. It is apparently too confusing to get right.

+1
___
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]

First, by copying c++-sig, let me invite C++ experts to comment on
this thread and the tracker issue:

http://mail.python.org/pipermail/python-dev/2009-January/084685.html
http://bugs.python.org/issue4805

My patch highlights several issues:

1. (OP's issue.)  Do we need  #ifdef __cplusplus wrappers in .c files?
2. Should malloc() calls be prefixed with explicit type casts?
3. Should use of void* pointers be discouraged when typed pointers will work?
4. Should exported symbols be always declared in headers or is it ok
to just declare them as extern in .c files where they are used?
5. Should the use of C++ keywords such as "new" or "class" be discouraged?

On #1, I find it silly to have  #ifdef __cplusplus in the files that
cannot be compiled with C++ in the first place.  Even if the files are
fixed to compile with C++, I have arguments that  wrapping the entire
file in extern "C" is an overkill and hides design flaws.

On #4, Marc-Andre Lemburg commented on the tracker:
"""
Moving declarations into header files is not really in line with the way
Python developers use header files:

We usually only put code into header files that is meant for public use.

Buy putting declarations into the header files without additional
warning, you implicitly document them and make them usable in
non-interpreter code.
""" 

I disagree.  Declaring functions in  .c files breaks dependency
analysis and may lead to subtle bugs.  AFAIK, Python's convention for
global functions that are not meant to be used outside of the
interpreter is the _Py prefix.  If an extra protection is deemed
necessary, non-public global symbols can be declared in separate
header files that are not included by Python.h.

On #3 and #5 arguments can be made that C++ compliant code is better
irrespective of C++.

#2 seems to be the most controversial, but explicit casts seem to be
the current norm and if perceived ugliness will discourage use of
mallocs in favor of higher level APIs, it is probably a good thing.

I believe restricting python core code to an intersection of c89 and
C++ will improve the overall self-consistency and portability of the
code and will allow python to be used in more systems, but since I
don't use C++ myself, I will only argue for changes such as #4 that
are independent of C++.

On Fri, Jan 2, 2009 at 12:31 PM, David Cournapeau  wrote:
> On Sat, Jan 3, 2009 at 1:35 AM, Christian Heimes  wrote:
>> David Cournapeau schrieb:
>>> Can't those errors be found simply using appropriate warning flags in
>>> the C compiler ?  C has stopped being a subset of C++ a long time ago
>>
>> Python's C code still follow the ANSI C89 standard. The fact puts 'long
>> time ago' in a different perspective. :)
>
> In my mind, C++ is largely responsible for C not being a subset of
> C++, so the type of C used by the codebase is not that important in
> that context.
>
> 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?

[Matthieu Brucher]

Hi,

2009/1/2 Alexander Belopolsky :
> First, by copying c++-sig, let me invite C++ experts to comment on
> this thread and the tracker issue:
>
> http://mail.python.org/pipermail/python-dev/2009-January/084685.html
> http://bugs.python.org/issue4805
>
> My patch highlights several issues:
>
> 1. (OP's issue.)  Do we need  #ifdef __cplusplus wrappers in .c files?

It seems that it is a reminiscence of old compilers, perhaps not even
supported anymore, thus it shouldn't be an issue anymore.

> 2. Should malloc() calls be prefixed with explicit type casts?

When I learnt C, I was always told to explicitely cast.

> 3. Should use of void* pointers be discouraged when typed pointers will work?

I think type checking is good in C.

> 4. Should exported symbols be always declared in headers or is it ok
> to just declare them as extern in .c files where they are used?

I agree with you, declaration should be put in headers, to prevent a
signature change for instance. One place is always better than several
places (you have to define them somewhere if you want to call them
without a warning). If we don't do this, we are back to the Fortran 77
days.
Besides, if those functions are not to be advertized, nothing prevents
them for inclusion inside "private" headers that are not included my
Python.h. This way, you can benefit from C checks, without the
advertizement (letting them in C files does not prevent their use,
putting them in headers prevents crashes).
With Visual Studio, you can say which function you want to export in
your library. This can be done with gcc as well, even if it is not the
default behavior.

> 5. Should the use of C++ keywords such as "new" or "class" be discouraged?

As CPython will not be ported to C++, I don't see the point of not
using "new" and "class" for variables names inside a function.

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
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?

[David Cournapeau]

Hi Matthis,

On Sat, Jan 3, 2009 at 3:31 AM, Matthieu Brucher
 wrote:

>
> When I learnt C, I was always told to explicitely cast.

Maybe your professor was  used to old C :) It is discouraged practice
to cast malloc - the only rationale I can think of nowadays is when
you have to compile the source with both a C and  C++ compiler.
Otherwise, it is redundant at best (it was useful when malloc was
defined as returning char*, and C did not allow for automatic void* to
other pointer cast).

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?

[Matthieu Brucher]

>> When I learnt C, I was always told to explicitely cast.
>
> Maybe your professor was  used to old C :)

That's more than likely :D

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
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] Python 3 - Mac Installer?

[Bill Janssen]

Nicko van Someren  wrote:

> On 30 Dec 2008, at 13:45, Barry Scott wrote:
> ...
> > Since I've been building 3.0 for a while now I looked at the script.
> >
> > build-install.py seems to have been half converted to py 3.0.
> > Going full 3.0 was not hard but then there is the problem of
> > the imports.
> >
> > Python 3.0 does not have MacOS or Carbon modules.
> >
> > Seems that there are two ways to go.
> >
> > Put back the Carbon and MacOS modules into 3.0.
> > Use Python 2 to build the python 3 package.
> 
> As far as I can tell the Carbon and MacOS modules are _only_ used in
> the setIcon() function, which is used to give pretty icon to the
> python folder.  Perhaps it might be better to have a fully Python 3
> build system and loose the prettiness for the time being.

+1

Bill
___
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] Python 3 - Mac Installer?

[Martin v. Löwis]

>> As far as I can tell the Carbon and MacOS modules are _only_ used in
>> the setIcon() function, which is used to give pretty icon to the
>> python folder.  Perhaps it might be better to have a fully Python 3
>> build system and loose the prettiness for the time being.
> 
> +1

-1. I think it is a good choice that build-install.py is written in
Python 2.x, and only relies on the system Python. For that matter,
it could have been a shell script. That way, you don't have to build
Python first in order to build it.

Regards,
Martin
___
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] Python 3 - Mac Installer?

[Ronald Oussoren]

On 2 Jan, 2009, at 20:51, Bill Janssen wrote:


Nicko van Someren  wrote:


On 30 Dec 2008, at 13:45, Barry Scott wrote:
...

Since I've been building 3.0 for a while now I looked at the script.

build-install.py seems to have been half converted to py 3.0.
Going full 3.0 was not hard but then there is the problem of
the imports.

Python 3.0 does not have MacOS or Carbon modules.

Seems that there are two ways to go.

Put back the Carbon and MacOS modules into 3.0.
Use Python 2 to build the python 3 package.


As far as I can tell the Carbon and MacOS modules are _only_ used in
the setIcon() function, which is used to give pretty icon to the
python folder.  Perhaps it might be better to have a fully Python 3
build system and loose the prettiness for the time being.


+1


-1.  The script exists to make it as easy as possible to build the  
installer. Converting it to python 3 makes that task harder.


BTW. Until a couple of days ago the script had no chance of working at  
all because the Mac-specific Makefiles were broken.


Ronald

___
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] Python 3 - Mac Installer?

[Benjamin Peterson]

On Wed, Dec 31, 2008 at 4:34 PM, Nicko van Someren  wrote:
>
> As far as I can tell the Carbon and MacOS modules are _only_ used in the
> setIcon() function, which is used to give pretty icon to the python folder.
>  Perhaps it might be better to have a fully Python 3 build system and loose
> the prettiness for the time being.

-1 also There's little advantage having it be in Python 3 at the moment.


-- 
Regards,
Benjamin
___
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] PyOS_GetLastModificationTime

[Ulrich Eckhardt]

Hi!

The function PyOS_GetLastModificationTime() is documented in sys.rst as taking 
a "char*". However, in reality, it takes a "char*" and a "FILE*". Actually, 
it should take a "char const*", as it doesn't and shouldn't modify the path. 
Further, the normal version doesn't use the path at all, the RISCOS version 
in 2.7 does however, and for a CE port it would be convenient to have that 
info, too.

There is another issue, and that is that the function isn't declared anywhere, 
and I'm not sure where it should be declared either. Actually, I'm not sure 
if is suitable/intended for public consumption, so I wonder if putting it 
into 'Include' would be right.

Any suggestions how to deal with that issue?

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] Python 3 - Mac Installer?

[Bill Janssen]

Martin v. Löwis  wrote:

> >> As far as I can tell the Carbon and MacOS modules are _only_ used in
> >> the setIcon() function, which is used to give pretty icon to the
> >> python folder.  Perhaps it might be better to have a fully Python 3
> >> build system and loose the prettiness for the time being.
> > 
> > +1
> 
> -1. I think it is a good choice that build-install.py is written in
> Python 2.x, and only relies on the system Python. For that matter,
> it could have been a shell script. That way, you don't have to build
> Python first in order to build it.

Can't argue with that.  But dropping the "setIcon" function and its
associated use of Carbon and MacOS modules from that build script seems
to me a good idea.  Prepare for the future with *very* limited loss of
functionality.

Bill
___
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] Python 3 - Mac Installer?

[Bill Janssen]

Bill Janssen  wrote:

> Martin v. Löwis  wrote:
> 
> > >> As far as I can tell the Carbon and MacOS modules are _only_ used in
> > >> the setIcon() function, which is used to give pretty icon to the
> > >> python folder.  Perhaps it might be better to have a fully Python 3
> > >> build system and loose the prettiness for the time being.
> > > 
> > > +1
> > 
> > -1. I think it is a good choice that build-install.py is written in
> > Python 2.x, and only relies on the system Python. For that matter,
> > it could have been a shell script. That way, you don't have to build
> > Python first in order to build it.
> 
> Can't argue with that.  But dropping the "setIcon" function and its
> associated use of Carbon and MacOS modules from that build script seems
> to me a good idea.  Prepare for the future with *very* limited loss of
> functionality.

At the very least, we could move the imports of Carbon and MacOS into
the setIcon() function, which is called only once, and wrap a try-except
around that call.

Bill
___
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] PyOS_GetLastModificationTime

[Martin v. Löwis]

> Any suggestions how to deal with that issue?

Correct me if I'm wrong: it seems that the function isn't called
anymore. So I propose to just remove it (and the file it lives
in).

Regards,
Martin
___
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] PyOS_GetLastModificationTime

[Ulrich Eckhardt]

On Friday 02 January 2009 22:30:39 Ulrich Eckhardt wrote:
> The function PyOS_GetLastModificationTime() is documented in sys.rst as
> taking a "char*". However, in reality, it takes a "char*" and a "FILE*".
> Actually, it should take a "char const*", as it doesn't and shouldn't
> modify the path. Further, the normal version doesn't use the path at all,
> the RISCOS version in 2.7 does however, and for a CE port it would be
> convenient to have that info, too.
>
> There is another issue, and that is that the function isn't declared
> anywhere, and I'm not sure where it should be declared either. Actually,
> I'm not sure if is suitable/intended for public consumption, so I wonder if
> putting it into 'Include' would be right.

Actually, the whole thing might be a non-issue. The point is that the function 
is not used anywhere.

> Any suggestions how to deal with that issue?

...of course that question remains. Remove all traces? I'd volunteer to make a 
patch, as it's one less function to port. ;)

cheers

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

[Python-Dev] #ifdef __cplusplus?

[Jim Jewett]

Alexander Belopolsky wrote:
> 4. Should exported symbols be always declared in headers or is it ok
> to just declare them as extern in .c files where they are used?

Is the concern that moving them to a header makes them part of the API?

In other words, does replacing

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

with

   #include 

mean that the  needs to be included from then on, even if
PyFile_FromString stops relying upon it?

-jJ
___
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] I would like an svn account

[Victor Stinner]

Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
> When it comes to commit privs in general, I am of the school that they
> should be handed out carefully. I for one do not want to have to
> babysit other committers to make sure that they did something
> correctly.

Last time I asked if anyone could help me in Python core if I had an svn 
account, and I get this answer: everybody will review the changes. Anyway, 
why do you fear problems? Did I already push buggy commits? I posted many 
patches on Python bug tracker, most of them required many versions until they 
get perfect. But it doesn't mean that with an svn account, I will skip the 
bug tracker to wrote directly in the svn as my personal copy of Python!?

> I also want people who have no agenda. It's okay to have an area you
> care about, but that doesn't mean you should necessarily say "I will
> only work on math, ever, even if something is staring me right in the
> face!", etc.

I wrote that I would like to improve Python quality by fuzzing, but I already 
contributed to many different topics by patches on the bug tracker.

> There is also dedication. I don't like giving commit privileges to
> people who I don't think will definitely stick around. (...)

I don't understand why this is a problem.

> To start, your focus on security, for me at least, goes too
> far sometimes. I have disagreed with some of your decisions in the
> name of security in the past and I am not quite ready to say that if
> you committed something I wouldn't feel compelled to double-check it
> to make sure you didn't go too far.

I'm not sure that I understood correclty: does it mean that some of my issues 
were not reproductible in the real world (far from the real usage of Python)? 
It's true that some issues found by fuzzing are hard to reproduce (require a 
prepared environment), but my goal is to kill all bugs :-) Even if the bug is 
hard to reproduce, it does exist and that's why I'm thinking that it should 
be fixed.

Sorry if I misused the name "security" but I don't remember where I wrote 
that "this issue is very security and related to security". Maybe by the 
imageop issues?

--

About fuzzing: I'm still using my fuzzer Fusil on Python trunk and py3k, and I 
find fewer and fewer bugs ;-) Most of the time I rediscover bugs already 
reported to the tracker, but not fixed yet. So the fuzzing job is mostly 
done ;-)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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]

Jim Jewett schrieb:
> Is the concern that moving them to a header makes them part of the API?
> 
> In other words, does replacing
> 
>PyObject *
>PyFile_FromString(char *name, char *mode)
>{
>   extern int fclose(FILE *);
>...
>}
> 
> with
> 
>#include 
> 
> mean that the  needs to be included from then on, even if
> PyFile_FromString stops relying upon it?

stdio.h is included by the Python.h header file anyway. There is simply
on point in declaring fclose() a second time here.

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?

[Adam Olsen]

On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg  wrote:
> On 2009-01-02 08:26, Adam Olsen wrote:
>> 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.
>
> ??? Please read the comments in pymem.h and objimpl.h.

I count 7 versions of malloc.  Despite the names, none of them are
specific to PyObjects.  It's pretty much impossible to know what
different ones do without a great deal of experience.

Only very specialized uses need to allocate PyObjects directly anyway.
 Normally PyObject_{New,NewVar,GC_New,GC_NewVar} are better.


>> 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).
>
> You should always use PyMem_NEW() (capital letters), if you ever
> intend to benefit from the memory allocation debug facilities
> in the Python memory allocation interfaces.

I don't see why such debugging should require a full recompile, rather
than having a hook inside the PyMem_Malloc (or even providing a
different PyMem_Malloc).


> The difference between using the _NEW() macros and the _MALLOC()
> macros is that the first apply overflow checking for you. However,
> the added overhead only makes sense if these overflow haven't
> already been applied elsewhere.

They provide assertions.  There's no overflow checking in release builds.


-- 
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

[Python-Dev] Bytes for the command line, process arguments and environment variables

[Victor Stinner]

Hi,

Python 3.0 is released and supports unicode everywhere, great! But as pointed 
by different people, bytes are required on non-Windows OS for backward 
compatibility. This email is just a sum up all many issues/email threads.

Problems with Python 3.0:

 (1) Invalid unicode string on the command line
   => some people wants to get the command line arguments as bytes
  and so start even if non decodable unicode strings are present
  on the command line
   => http://bugs.python.org/issue3023

 (2) Non decodable environment variables are skipped in os.environ
   => Create os.environb (or anything else) to get these variables
  as bytes (and be able to setup new variables as bytes)
   => Read the email thread "Python-3.0, unicode, and os.environ" 
  (Decembre 2008) opened by Toshio Kuratomi

 (3) Support bytes for os.exec*() and subprocess.Popen(): process arguments 
   and the environment variables
   => http://bugs.python.org/issue4035: my patch for os.exec*()
   => http://bugs.python.org/issue4036: my patch for subprocess.Popen()


Command line


I like the curent behaviour and I don't want to change it. Be free to propose 
a solution to solve the issue ;-)


Environment
===

I already proposed "os.environb" which will have the similar API 
than "os.environ" but with bytes. Relations between os.environb and 
os.environ:

  - for an undecodable variable value in os.environb, os.environ will raise
a KeyError. Example with utf8 charset and os.environb[b'PATH'] = '\xff':
path=os.environ['PATH'] will raise a KeyError to keep the current
behaviour.

  - os.environ raises an UnicodeDecodeError if the key or value can not be
encoded in the current charset. Example with ASCII charset:
os.environ['PATH'] = '/home/hayp\xf4'

  - except undecodable variable values in os.environb, os.environ and
os.environb will be consistent. Example: delete a variable in 
os.environb will also delete the key in os.environ.

I think that most of these points (or all points) are ok for everyone 
(especially ok for Toshio Kuratomi and me :-)).

Now I have to try to write an implementation of this, but it's complex, 
especially to keep os.environ and os.environb consistents!


Processes
=

I proposed patches to fix non-Windows OS, but Antoine Pitrou wants also bytes 
on Windows. Amaury wrote that it's possible using the ANSI version of the 
Windows API. I don't know this API and so I can not contribute to this point.

---

Rejected idea
=

Use a private Unicode block causes interoperability problems:
 - the block may be already used by other programs/libraires
 - 3rd party programs/libraries don't understand this block and may
   have problems this display/process the data

(Is the idea really rejected? It has at least many problems)

---

I don't have new solutions, it's just an email to restart the discussion about 
bytes ;-) Martin also asked for a PEP to change the posix module API to 
support bytes.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] I would like an svn account

[Brett Cannon]

On Fri, Jan 2, 2009 at 18:53, Victor Stinner
 wrote:
> Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
>> When it comes to commit privs in general, I am of the school that they
>> should be handed out carefully. I for one do not want to have to
>> babysit other committers to make sure that they did something
>> correctly.
>
> Last time I asked if anyone could help me in Python core if I had an svn
> account, and I get this answer: everybody will review the changes. Anyway,
> why do you fear problems? Did I already push buggy commits? I posted many
> patches on Python bug tracker, most of them required many versions until they
> get perfect. But it doesn't mean that with an svn account, I will skip the
> bug tracker to wrote directly in the svn as my personal copy of Python!?
>

I know people will review your commits, but I prefer to have that be a
safety precaution than any feeling that it is really required.

And if you really do plan to continue to use the tracker heavily, that
does help alleviate this worry. Once you have the ability to check in
directly the temptation to skip having to wait for reviews becomes
rather strong.

>> I also want people who have no agenda. It's okay to have an area you
>> care about, but that doesn't mean you should necessarily say "I will
>> only work on math, ever, even if something is staring me right in the
>> face!", etc.
>
> I wrote that I would like to improve Python quality by fuzzing, but I already
> contributed to many different topics by patches on the bug tracker.
>
>> There is also dedication. I don't like giving commit privileges to
>> people who I don't think will definitely stick around. (...)
>
> I don't understand why this is a problem.
>

Because when people contribute large bodies of code and then disappear
someone then eventually has to step in and take up maintenance. That
means more stuff for someone to have to keep up with and having to
learn how the code works.

>> To start, your focus on security, for me at least, goes too
>> far sometimes. I have disagreed with some of your decisions in the
>> name of security in the past and I am not quite ready to say that if
>> you committed something I wouldn't feel compelled to double-check it
>> to make sure you didn't go too far.
>
> I'm not sure that I understood correclty: does it mean that some of my issues
> were not reproductible in the real world (far from the real usage of Python)?
> It's true that some issues found by fuzzing are hard to reproduce (require a
> prepared environment), but my goal is to kill all bugs :-) Even if the bug is
> hard to reproduce, it does exist and that's why I'm thinking that it should
> be fixed.
>
> Sorry if I misused the name "security" but I don't remember where I wrote
> that "this issue is very security and related to security". Maybe by the
> imageop issues?
>

What I mean is that I remember an instance or two where you found
something that seemed like a security issue but that is otherwise not
critical and wanting to make a change for it that I disagreed with
based on it being security-related. Python is basically secure, but we
have never claimed we are perfect. And I understand wanting to squash
all bugs, but there have to be priorities, and sometimes security is
not the highest priority for really obscure stuff. Or at least that's
my opinion.

> --
>
> About fuzzing: I'm still using my fuzzer Fusil on Python trunk and py3k, and I
> find fewer and fewer bugs ;-) Most of the time I rediscover bugs already
> reported to the tracker, but not fixed yet. So the fuzzing job is mostly
> done ;-)
>

That's good to hear!

As I said, you are on your way, but I personally just am not ready to
give you a +1 for commit privs. As Raymond said and you admitted to
above, your patches still go through several revisions. Having commit
privileges means you can skip that step and I am just not feeling
comfortable with that to happen yet.

But if another core developer or three are willing to say they will
act as probationary officers on ALL of your commits for a while and
you at least initially continue to use the issue tracker until the
people watching your commits are willing to say you don't need to be
watched, then I am fine with you getting commit privs.

And I hope everyone realizes that they can speak up (publicly or
privately) about *anyone* in regards to whether they think they need
to lose their commit privileges for personal or coding reasons. I know
it's tough to speak out publicly about someone and their coding
abilities which is why I am trying to rationalize this for Victor
instead of just sitting quietly while he does or does not get
responses from people on whether he should get commit privileges.
Every time commit privileges are given out it is a leap of faith and
sometime the leap comes up short.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc