On 4/17/2011 1:32 AM, R. David Murray wrote:
As Brett said, people do come to depend on the details of the
implementation. But IMO the PEP should be clarified to say that the
tests we are talking about should be tests *of the published API*.
That is, blackbox tests, not whitebox tests.
I thin
> Well, there was a 5x speedup demonstrated comparing simplejson to the
> standard library json module.
Can you kindly point to that demonstration?
> That sound like *very* worth pursuing (and
> crazy not to pursue). I've had json serialisation be the bottleneck in
> web applications generating s
Matt Billenstein, 17.04.2011 00:47:
On Sat, Apr 16, 2011 at 01:30:13PM +0200, Antoine Pitrou wrote:
On Sat, 16 Apr 2011 00:41:03 +
Matt Billenstein wrote:
Slightly less crude benchmark showing simplejson is quite a bit faster:
http://pastebin.com/g1WqUPwm
250ms vs 5.5s encoding and decod
On Sat, 16 Apr 2011 19:19:32 -0700, Raymond Hettinger
wrote:
> On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
> >
> >
> > On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> > Brett Cannon wrote:
> > > In the grand python-dev tradition of "silence means acceptance", I
> > > consider
> > >
Argh! Sorry list. I meant to discard the post that was just sent.
Please accept my humblest apologies...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner
wrote:
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all classes
On Sat, Apr 16, 2011 at 06:45, Gustavo Narea wrote:
> Hello,
>
> On 15/04/11 13:30, Brian Curtin wrote:
> > To me, the fix *was* released.
>
> No, it wasn't. It was *committed* to the repository.
>
Yep, and that's enough for me. If you have a vulnerable system, you can now
patch it with an accep
On 16 Apr, 11:03 pm, st...@pearwood.info wrote:
Brett Cannon wrote:
In the grand python-dev tradition of "silence means acceptance", I
consider
this PEP finalized and implicitly accepted.
How long does that silence have to last?
I didn't notice a definition of what counts as "100% branch cov
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
>
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> Brett Cannon wrote:
> > In the grand python-dev tradition of "silence means acceptance", I consider
> > this PEP finalized and implicitly accepted.
I haven't seen any responses that sai
Michael Foord wrote:
On 15/04/2011 02:23, Steven D'Aprano wrote:
[...]
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is true, however consi
On Sat, Apr 16, 2011 at 01:30:13PM +0200, Antoine Pitrou wrote:
> On Sat, 16 Apr 2011 00:41:03 +
> Matt Billenstein wrote:
> >
> > Slightly less crude benchmark showing simplejson is quite a bit faster:
> >
> > http://pastebin.com/g1WqUPwm
> >
> > 250ms vs 5.5s encoding and decoding an 11KB
On Sat, 16 Apr 2011 23:48:45 +0100
Michael Foord wrote:
> On 16/04/2011 22:28, "Martin v. Löwis" wrote:
> > Am 16.04.2011 21:13, schrieb Vinay Sajip:
> >> Martin v. Löwis v.loewis.de> writes:
> >>
> >>> Does it actually need improvement?
> >> I can't actually say, but I assume it keeps changing
Brett Cannon wrote:
In the grand python-dev tradition of "silence means acceptance", I consider
this PEP finalized and implicitly accepted.
How long does that silence have to last?
I didn't notice a definition of what counts as "100% branch coverage".
Apologies if I merely failed to notice it
On 16/04/2011 22:28, "Martin v. Löwis" wrote:
Am 16.04.2011 21:13, schrieb Vinay Sajip:
Martin v. Löwis v.loewis.de> writes:
Does it actually need improvement?
I can't actually say, but I assume it keeps changing for the better - albeit
slowly. I wasn't thinking of specific improvements, ju
On Sat, Apr 16, 2011 at 3:54 PM, Antoine Pitrou wrote:
>
> Hmm, what's the difference between "the Python stdlib" and "CPython's
> stdlib"?
>
> I'm also not sure how you would enforce that anyway. If it means
> using ctypes to interface with system C libraries, I'm -10 on it :)
>
>
Sounds like Br
Martin v. Löwis v.loewis.de> writes:
> I can see three possible areas of improvment:
> 1. Bugs: if there are any, they should clearly be fixed. However, JSON
>is a simple format, so the implementation should be able to converge
>to something fairly correct quickly.
> 2. Performance: there
On Sat, 16 Apr 2011 14:45:52 -0700
Brett Cannon wrote:
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
>
> > Brett Cannon wrote:
> > > In the grand python-dev tradition of "silence means acceptance", I
> > consider
> > > this PEP finalized and implicitly accepted.
> >
> > I did not really s
On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> Brett Cannon wrote:
> > In the grand python-dev tradition of "silence means acceptance", I
> consider
> > this PEP finalized and implicitly accepted.
>
> I did not really see an answer to these concerns:
>
> http://mail.python.org/pipermail/pyt
Am 16.04.2011 21:13, schrieb Vinay Sajip:
> Martin v. Löwis v.loewis.de> writes:
>
>> Does it actually need improvement?
>
> I can't actually say, but I assume it keeps changing for the better - albeit
> slowly. I wasn't thinking of specific improvements, just the idea of
> continuous
> improve
Brett Cannon wrote:
> In the grand python-dev tradition of "silence means acceptance", I consider
> this PEP finalized and implicitly accepted.
I did not really see an answer to these concerns:
http://mail.python.org/pipermail/python-dev/2011-April/110672.html
http://mail.python.org/pipermail/py
In the grand python-dev tradition of "silence means acceptance", I consider
this PEP finalized and implicitly accepted.
On Tue, Apr 12, 2011 at 15:07, Brett Cannon wrote:
> Here is the next draft of the PEP. I changed the semantics requirement to
> state that 100% branch coverage is required for
Martin v. Löwis v.loewis.de> writes:
> Does it actually need improvement?
I can't actually say, but I assume it keeps changing for the better - albeit
slowly. I wasn't thinking of specific improvements, just the idea of continuous
improvement in general...
Regards,
Vinay Sajip
_
> I agree, my suggestion is orthogonal to the question of who maintains stdlib
> json. But if the json module is languishing in comparison to simplejson, then
> bringing the code bases closer together may be worthwhile.
Right: *if* the module is languishing. But it's not. It just diverges.
> It m
On Sat, 16 Apr 2011 16:47:49 + (UTC)
Vinay Sajip wrote:
>
> > What you're proposing doesn't address the question of who is going to
> > do the ongoing maintenance.
>
> I agree, my suggestion is orthogonal to the question of who maintains stdlib
> json.
No, that's not what I'm talking about.
> > I've contributed a couple of patches myself after they were integrated
> > to CPython (they are part of the performance improvements Bob is talking
> > about), but that was exceptional. Backporting a patch to another project
> > with a different directory structure, a slightly different code,
Hi Antoine,
Antoine Pitrou pitrou.net> writes:
> What you're proposing doesn't address the question of who is going to
> do the ongoing maintenance.
I agree, my suggestion is orthogonal to the question of who maintains stdlib
json. But if the json module is languishing in comparison to simplejs
On 2011-04-16, at 17:25 , Antoine Pitrou wrote:
> Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit :
>> On 2011-04-16, at 16:52 , Antoine Pitrou wrote:
>>> Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
> Wh
On Sat, 16 Apr 2011 18:04:53 +0200
Stefan Behnel wrote:
>
> Well, if that is not possible, then the CPython devs will have a hard time
> maintaining the json accelerator module in the long run. I quickly skipped
> through the github version in simplejson, and it truly is some complicated
> pie
On Saturday, April 16, 2011, Antoine Pitrou wrote:
> Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit :
>> On 2011-04-16, at 16:52 , Antoine Pitrou wrote:
>> > Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
>> >> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
>>
Antoine Pitrou, 16.04.2011 16:19:
On Sat, 16 Apr 2011 09:50:25 + (UTC)
Vinay Sajip wrote:
If it is generally considered desirable to maintain some synchrony between
simplejson and stdlib json, then since Bob has stated that he no interest in
Python 3, it may be better to:
1. Convert the si
Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit :
> On 2011-04-16, at 16:52 , Antoine Pitrou wrote:
> > Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
> >> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
> >>> What you're proposing doesn't address the question of
On 2011-04-16, at 16:52 , Antoine Pitrou wrote:
> Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
>> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
>>> What you're proposing doesn't address the question of who is going to
>>> do the ongoing maintenance. Bob apparently isn't
Hello all,
This is an invite to all core-python developers, and developers of
alternative implementations, to attend the Python Language Summit at
EuroPython. The summit will be on June 19th and EuroPython this year
will be held at the beautiful city of Florence in Italy.
http://ep2011.e
Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
> > What you're proposing doesn't address the question of who is going to
> > do the ongoing maintenance. Bob apparently isn't interested in
> > maintaining stdlib code, and pyth
On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
> What you're proposing doesn't address the question of who is going to
> do the ongoing maintenance. Bob apparently isn't interested in
> maintaining stdlib code, and python-dev members aren't interested in
> maintaining simplejson (assuming it
On Sat, Apr 16, 2011 at 9:45 PM, Gustavo Narea wrote:
> I reckon if this had been handled differently (i.e., making new releases
> and communicating it via the relevant channels [1]), we wouldn't have
> the situation we have right now.
Nope, we would have a situation where the security team were
Hello Vinay,
On Sat, 16 Apr 2011 09:50:25 + (UTC)
Vinay Sajip wrote:
>
> If it is generally considered desirable to maintain some synchrony between
> simplejson and stdlib json, then since Bob has stated that he no interest in
> Python 3, it may be better to:
>
> 1. Convert the simplejson
Sandro Tosi gmail.com> writes:
> Luckily, upstream is receptive for patches, so part of the job is to
> forward patches written for cpython not already in the upstream code.
Further to my earlier response to your post, I should mention that my fork of
simplejson at
https://github.com/vsajip/sim
Hello,
On 15/04/11 13:30, Brian Curtin wrote:
> To me, the fix *was* released.
No, it wasn't. It was *committed* to the repository.
> Sure, no fancy installers were generated yet, but people who are
> susceptible to this issue 1) now know about it, and 2) have a way to
> patch their system *if n
On Sat, 16 Apr 2011 00:41:03 +
Matt Billenstein wrote:
>
> Slightly less crude benchmark showing simplejson is quite a bit faster:
>
> http://pastebin.com/g1WqUPwm
>
> 250ms vs 5.5s encoding and decoding an 11KB json object 1000 times...
This doesn't have much value if you don't say which
Sandro Tosi gmail.com> writes:
> The version we have in cpython of json is simplejson 2.0.9 highly
> patched (either because it was converted to py3k, and because of the
> normal flow of issues/bugfixes) while upstream have already released
> 2.1.13 .
I think you mean 2.1.3?
> Their 2 roads ha
Am 15.04.2011 15:47, schrieb Victor Stinner:
> Le vendredi 15 avril 2011 à 13:34 +0200, Jesus Cea a écrit :
>> http://docs.python.org/py3k/ takes you to 2.7, by default.
>>
>> Should we update it to point to 3.2?. If the point is to promote Python 3...
>>
>> I would point it to 3.2, with a big "a
42 matches
Mail list logo
