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'
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
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
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
> 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
>> 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"
[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
-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
イェルーン ラウ
> 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
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:
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
[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
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
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-
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
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
> 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
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*
>> 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
> >> 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.
>
>
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
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,
22 matches
Mail list logo
