Re: [Python-Dev] Visual Studio 2008 compiler option EHsc ?

2008-05-17 Thread Matthieu Brucher 
Hi,

2008/5/17 Jim Kleckner <[EMAIL PROTECTED]>:

> Martin v. Löwis wrote:
>
>> In building a package with several platforms, I
>>> ran across the warning message below from Visual
>>> Studio 2008.  Should we add the /EHsc option to the
>>> compile_options in distutils for MSVC?  Or is it more
>>> complex than that...
>>>
>>
>> Who is "we"? If you have a module that uses C++ exceptions,
>> you should certainly enable compiler support for exceptions,
>> for that module.
>>
>
> In my original email, I referred to the patch for distutils at:
>  http://tinyurl.com/63bqo2
>
> Based on that patch, I made the attached patch in distutils to
> msvc9compiler.py and that made the complaints disappear
> (and presumably made the exceptions work?).
>
> Is there any downside to doing this by default?
> Or should I parameterize my build_ext for that platform
> to include that option?



This option is only for C++ code, and not for every C++ code. Some people
don't want exception to be handled (take a look at Boost for instance that
let the user decide whether its exception handling is done by the compiler
or by the user), as it can add overhead in some places.
With Scons, the problem is the same, you have to add by hand this flag, and
I think it is the correct way of doing things.

Matthieu
-- 
French PhD student
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread M.-A. Lemburg 

I'd like to bring a potential problem to attention that is caused
by the recent module renaming approach:

Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.

They access this module path by looking at the __module__ attribute
of the object classes.

With the renaming, all objects which use classes from the renamed
modules will now refer to the renamed modules in their serialized
form, e.g. queue.Queue instead of Queue.Queue (just to name one
example).

While this is nice for forward compatibility, it causes rather serious
problems for making object serialization backwards compatible, since
the older Python versions can no longer unserialize objects due
to missing modules.

This can happen in client-server setups where e.g. the server
uses Python 2.6 and the clients some other Python version (e.g.
Python 2.5).

It can also happen in storage setups where Python
objects are stored using e.g. pickle, ZODB being a prominent
example. As soon as a Python 2.6 application starts writing to
such storages, Python 2.5 and lower versions will no longer be
able to read back all the data.

Now, I think there's a way to solve this puzzle:

Instead of renaming the modules (e.g. Queue -> queue), we leave
the code in the existing modules and packages and instead add
the new module names and package structure with pointers and
redirects to the existing 2.5 modules.

Code can (and probably should) still be changed to try to import
the new module name. In cases where backwards compatibility is
needed, this can also be done using

try:
import newname
except ImportError:
import oldname

Later on, when porting applications to 3.0, the 2to3 script can
then apply the final renaming in the source code.

Example:

queue.py:
-
import sys, Queue
sys.modules[__name__] = Queue

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 17 2008)
>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread Alexandre Vassalotti 
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'd like to bring a potential problem to attention that is caused
> by the recent module renaming approach:
>
> Object serialization protocols like e.g. pickle usually store the
> complete module path to the object class together with the object.

Thanks for bringing this up. I was aware of the problem myself, but I
hadn't yet worked out a good solution to it.


> It can also happen in storage setups where Python
> objects are stored using e.g. pickle, ZODB being a prominent
> example. As soon as a Python 2.6 application starts writing to
> such storages, Python 2.5 and lower versions will no longer be
> able to read back all the data.
>

The opposite problem exists for Python 3.0, too. Pickle streams
written by Python 2.x applications will not be readable by Python 3.0.
And, one solution to this is to use Python 2.6 to regenerate pickle
stream.

Another solution would be to write a 2to3 pickle converter using the
pickletools module. It is surely not the most elegant or robust
solution, but I could work.

> Now, I think there's a way to solve this puzzle:
>
> Instead of renaming the modules (e.g. Queue -> queue), we leave
> the code in the existing modules and packages and instead add
> the new module names and package structure with pointers and
> redirects to the existing 2.5 modules.

This would certainly work for simple modules, but what about packages?
For packages, you can't use the ``sys.modules[__name__] = Queue`` to
preserve module identity. Therefore, pickle will use the new package
name when writing its streams. So, we are back to the same problem
again.

A possible solution could be writing a compatibility layer for the
Pickler class, which would map new module names to their old at
runtime. Again, this is neither an elegant, nor robust, solution, but
it should work in most cases.

-- Alexandre
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread Alexandre Vassalotti 
Errata:

On Sat, May 17, 2008 at 10:59 AM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> And, one solution to this is to use Python 2.6 to regenerate pickle
> stream.

... to regenerate *the* pickle *streams*.


> It is surely not the most elegant or robust solution, but I could work.

... but *it* could work.


> This would certainly work for simple modules, but what about packages?
> For packages, you can't use the ``sys.modules[__name__] = Queue`` to
> preserve module identity.

... you can't use the ``sys.modules[__name__] = Queue`` *trick* to
preserve module identity.


> A possible solution could be writing a compatibility layer for the

... could be *to write* a compatibility layer...


I guess I should start proofreading my emails before sending them, not after...

-- Alexandre
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] platform module testing

2008-05-17 Thread Steve Holden 

Christian Heimes wrote:

Benjamin Peterson schrieb:

At the moment, the test for the platform module merely calls each
function. I realize that this is a hard module to test well, but are
there some assumptions we can make? For example, if sys.platform is
'java', can it be assumed that java_ver is going to return something
which is not empty. When sys.platform is 'darwin' and the gestalt
module is present, is it reasonable to require that a empty tuple not
be returned?


A student has created a patch during the GHOP contest which adds some
features and tests for Linux. AFAIK the patch hasn't been applied yet.
See http://bugs.python.org/issue1322


Contributor agreement?

regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

[Python-Dev] Possible problem that may be caused by Tkinter renaming

2008-05-17 Thread Guilherme Polo 
Hello,

I smell a problem caused by this line at tkinter/__init__.py:

tkinter = _tkinter # b/w compat for export

This was fine when tkinter was a Tkinter module, but I believe it
would be better to rename this to something else.
Given that python has a lot of users, I'm sure you will be able to
find all sort of crazy things over the internet and one of them could
be:

import tkinter
from tkinter import *

something = tkinter._default_root

Which is not that crazy at all, for some values of crazy, but will fail now.


Regards,

-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] platform module testing

2008-05-17 Thread Georg Brandl 

Steve Holden schrieb:

Christian Heimes wrote:

Benjamin Peterson schrieb:

At the moment, the test for the platform module merely calls each
function. I realize that this is a hard module to test well, but are
there some assumptions we can make? For example, if sys.platform is
'java', can it be assumed that java_ver is going to return something
which is not empty. When sys.platform is 'darwin' and the gestalt
module is present, is it reasonable to require that a empty tuple not
be returned?


A student has created a patch during the GHOP contest which adds some
features and tests for Linux. AFAIK the patch hasn't been applied yet.
See http://bugs.python.org/issue1322


Contributor agreement?


Is present, see 
.


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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread Gregory P. Smith 
On Sat, May 17, 2008 at 7:59 AM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:

> Another solution would be to write a 2to3 pickle converter using the
> pickletools module. It is surely not the most elegant or robust
> solution, but I could work.

This could be done even for 2.x <--> 2.6 to be translate module names
at unpickling and pickling time.  IMHO thats preferable to leaving
stub modules with the old names around.  Anyways I'm not a heavy user
of pickle so people who are should decide.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible problem that may be caused by Tkinter renaming

2008-05-17 Thread Guilherme Polo 
2008/5/17 Guilherme Polo <[EMAIL PROTECTED]>:
> Hello,
>
> I smell a problem caused by this line at tkinter/__init__.py:
>
> tkinter = _tkinter # b/w compat for export

Georg and me decided to remove that line as a solution to this problem.

>
> This was fine when tkinter was a Tkinter module, but I believe it
> would be better to rename this to something else.
> Given that python has a lot of users, I'm sure you will be able to
> find all sort of crazy things over the internet and one of them could
> be:
>
> import tkinter
> from tkinter import *
>
> something = tkinter._default_root
>
> Which is not that crazy at all, for some values of crazy, but will fail now.
>
>
> Regards,
>
> --
> -- Guilherme H. Polo Goncalves
>



-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread Greg Ewing 

Alexandre Vassalotti wrote:

On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:


Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.


The opposite problem exists for Python 3.0, too.


This is just one manifestation of what I consider a
serious shortcoming of the pickle format for long-term
storage: it ties the data to implementation details
of the program.

When I brought this up earlier, various people assured
me that it wasn't a problem in practice. I think we're
seeing one situation here where it *is* a problem.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module renaming and pickle mechanisms

2008-05-17 Thread glyph 


On 10:22 pm, [EMAIL PROTECTED] wrote:

When I brought this up earlier, various people assured
me that it wasn't a problem in practice. I think we're
seeing one situation here where it *is* a problem.


Just my two cents here - experience has taught me that it's definitely a 
problem in practice.  One big problem with pickle is that it's even 
difficult to tell when or how much your persistence format depends on 
your application code.  For example, if you're pickling a dict that is 
supposed to map strings to integers, but you have a bug which 
accidentally ends up using a string subclass instead, it can be very 
difficult to figure out that this ever happened.


pickletools is really neat, and can help with this problem once you're 
stuck, but it's a better idea to use a more explicit persistence 
mechanism in the first place if you can.

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

[Python-Dev] oct and hex Py3k warnings

2008-05-17 Thread Benjamin Peterson 
I know Guido has opposed adding Py3k warnings to oct and hex for
"practical reasons," but I would like to make the case again.

future_buitlins oct and hex will give you the correct Py3k behavior,
but 2to3 can't convert old hex and oct usage to the new ones. That's
why is would be helpful to warn about it and encourage people to
import from future_builtins.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com