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 a
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.
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
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
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 tr
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 a
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
f
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
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
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 to
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__
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
>>>
12 matches
Mail list logo
