I say stick to what we have now: 2.6 signed, 3.0 unsigned. The 2.6
behavior is 100% compatible with 2.5 on 32bit boxes. It is 50%
incompatible with 2.5 on 64bit boxes, but it adds 100% compatibility
in 2.6 between 32bit and 64bit boxes (and also in 3.0 of course).
On Wed, Mar 19, 2008 at 11:26 PM,
On 3/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes schrieb:
>
> > In Python 3.0 the unit test for zlib is broken because in 3.0
> > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed
> int.
> >
> > How should the issue be solved? I think the unsigned l
> >> How can this ever work? Aren't there always going to be some
> >> incompatibilities which aren't covered by -3 or 2to3? Those will
> >> require manual code changes which aren't 2.x compatible.
>
> Martin> Like which incompatibilities specifically? I'm not aware of any.
>
>
>> How can this ever work? Aren't there always going to be some
>> incompatibilities which aren't covered by -3 or 2to3? Those will
>> require manual code changes which aren't 2.x compatible.
Martin> Like which incompatibilities specifically? I'm not aware of any.
Nothing speci
Christian Heimes schrieb:
> In Python 3.0 the unit test for zlib is broken because in 3.0
> zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed int.
>
> How should the issue be solved? I think the unsigned long is wrong.
Here at the sprint people agreed that crc32 *obviously*
> Martin> One option that I envision is that you might keep all sources as
> Martin> 2.x, and only convert to 3.x at installation time,
>
> How can this ever work? Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3? Those will require
> manual co
On Mon, Mar 17, 2008 at 3:37 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> ...
> Can you give another rule that you prefer and that I can comprehend and
> that I can explain to Python newcomers? The OP only gave a few examples of
> * usage and (initially) no rule that I saw.
Really, it is as c
Eric Smith schrieb:
> For example, say that 2to3 changes all instances of has_key to an "in"
> expression (I'm not saying it does this or not, I really don't know).
> If you have a Locksmith class that has a has_key method unrelated to
> dicts, then 2to3 would break it. But it's certainly possi
In Python 3.0 the unit test for zlib is broken because in 3.0
zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed int.
How should the issue be solved? I think the unsigned long is wrong.
Christian
___
Python-3000 mailing list
Python-
On Wed, Mar 19, 2008 at 2:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, PEP 3100 (the general Py3k TO-DO list) includes a line item to
> get rid of "from ... import *" at function level because of the merry
> hell it plays with the local variable optimisations. It's possible the
> m
[EMAIL PROTECTED] wrote:
>
> I would be happy to get rid of it in 3.0, but I'm also aware that some
> people use it. I'd like feedback from the Python community about this. If
> I removed it is there someone out there who wants it badly enough to
> maintain it in PyPI?
..
sounds lik
The csv module contains a Sniffer class which is supposed to deduce the
delimiter and quote character as well as the presence or absence of a header
in a sample taken from the start of a purported CSV file. I no longer
remember who wrote it, and I've never been a big fan of it. It determines
the
Eric> The proposed 3to2 also might be a way out.
Will be interesting to see how the round-trip code compares to the original.
Skip
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
> Possible features for 2.6
> New modules in the standard library:
> - JSON implementation
>
Have there been any plans made for which one? All of the
implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
python-json) have serious issues that in my opinion should be fixed
be
-On [20080318 01:52], Barry Warsaw ([EMAIL PROTECTED]) wrote:
>This schedule gives everybody plenty of advanced notice, so you should be
>able to get your code in on time.
In particular the memory related fixes over the last weeks, please. :)
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウ
[EMAIL PROTECTED] wrote:
> Martin> One option that I envision is that you might keep all sources as
> Martin> 2.x, and only convert to 3.x at installation time,
>
> How can this ever work? Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3? Those
>> How soon before the set of warnings it emits stabilizes?
Martin> Define "stabilize". In the sense that existing warnings will not
Martin> be revoked anymore? That should be now already.
Maybe I should have written "stops growing significantly" or "plateaus"
instead of "stabilizes"
> After the next SpamBayes release I plan to branch the code and work on
> porting it to Python 3.0, mostly as an experiment in porting code from
> Python 2.x to 3.x whose results I can feed back to the larger Python
> community. I'm curious about how best to approach the problem. My first
> thou
After the next SpamBayes release I plan to branch the code and work on
porting it to Python 3.0, mostly as an experiment in porting code from
Python 2.x to 3.x whose results I can feed back to the larger Python
community. I'm curious about how best to approach the problem. My first
thought is to
Aahz wrote:
>
> It was part of PEP 328 (Relative Imports) [*] -- and actually, taking a
> quick look at the PEP, it appears that the links within it point to some
> discussion about the "import *" issue.
I found a question from Jack Jansen about it in one of the threads, but
no real answer that
FWIW, I think thread interruption/cancellation deserves a PEP. There
are a bunch of subtle issues like this, several other languages that
we can imitate, and a lot of places in the implementation that will
need to change to support it. I was planning to write the PEP a month
or two from now, but if
On Tue, Mar 18, 2008 at 8:32 PM, <[EMAIL PROTECTED]> wrote:
> Regarding putting some JSON implementation in the standard library...
>
> I suppose anyone who uses JSON is aware of its limitations, but this was a
> bit disconcerting:
>
> >>> simplejson.loads(simplejson.dumps({1: 2}))
> {u'
22 matches
Mail list logo
