> I think the release date of 2.5.6c1 should be 17-Apr-2011, instead of
> 17-Apr-2010
> http://www.python.org/download/releases/2.5.6/NEWS.txt
Thanks, fixed.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
Hi,
I think the release date of 2.5.6c1 should be 17-Apr-2011, instead of
17-Apr-2010
http://www.python.org/download/releases/2.5.6/NEWS.txt
On Mon, Apr 18, 2011 at 5:57 AM, "Martin v. Löwis" wrote:
>
> On behalf of the Python development team and the Python community, I'm
> happy to announce th
On Mon, Apr 18, 2011 at 10:19 AM, Vinay Sajip wrote:
> It's quite likely that I've failed to turn off the stdlib json speedups
> (though
> I attempted to turn them off for both encoding and decoding), which would
> explain the big disparity in the non-speedup case. Perhaps someone with more
> fam
On Mon, Apr 18, 2011 at 3:50 AM, R. David Murray wrote:
> Thanks, your explanation seems to me to make a good case for making the
> decimal.py implementation less permissive.
Indeed. Since the current handling of Context in decimal.py violates
"Errors should never pass silently, unless explicitly
Stefan Behnel behnel.de> writes:
> Is this using the C accelerated version in both cases? What about the pure
> Python versions? Could you provide numbers for both?
What I posted earlier were C-accelerated timings. I'm not sure exactly how to
turn off the speedups for stdlib json. With some ass
Mark Janssen wrote:
I have to say it is quite strange to
me that there is no distinction made between IS-A relationship and
HAS-A relationships with regard to the issue of Inheritence.
I'm not sure what you mean by that. Inheritance is (or
should be) used only for is-a relationships. Misusing i
On behalf of the Python development team and the Python community, I'm
happy to announce the release candidate 1 of Python 2.5.6.
This is a source-only release that only includes security fixes. The
last full bug-fix release of Python 2.5 was Python 2.5.4. Users are
encouraged to upgrade to the la
> Of course, people might find other workloads which show bigger disparity in
> performance, or might find something in my 3.x port of simplejson which
> invalidates my finding of a 2% difference.
Thanks a lot for doing this research, by the way.
Regards,
Martin
__
On Sun, 17 Apr 2011 17:09:17 +0100
Michael Foord wrote:
> On 17/04/2011 07:28, "Martin v. Löwis" wrote:
> >> Well, there was a 5x speedup demonstrated comparing simplejson to the
> >> standard library json module.
> > Can you kindly point to that demonstration?
> >
> Hmm... according to a later em
16.04.2011 03:38, Greg Ewing пишет:
Michael Foord wrote:
consider the "recently" introduced problem caused by object.__init__
> not taking arguments. This makes it impossible to use super correctly
> in various circumstances.
>
> ...
>
It is impossible to inherit from both C and A and have all
Nick Coghlan writes:
> I'd personally like to see a couple of adjustments to
> http://www.python.org/news/security/:
For another thing, it needs to be more discoverable.
For yet another thing, it has two ancient entries on it. Surely there
are more than that?
Gustavo Narea writes:
> Well, that's a long shot. I doubt the people/organizations affected are
> all aware.
That's really not Python's responsibility. That's theirs. Caveats:
Python should have a single place where security patches are announced
*first*, before developer blogs and the like.
On Sun, 17 Apr 2011 19:17:11 +0200, Stefan Krah wrote:
> R. David Murray wrote:
> [snip a lot]
>
> Thank you, this cleared up many things.
Heh. Keep in mind that this is my viewpoint. I *think* Brett agrees
with me. I'm sure he'll speak up if he doesn't.
> The technical reason is that the c
R. David Murray wrote:
[snip a lot]
Thank you, this cleared up many things.
> > In the case of duck typing, the only solution I see is to lock down the
> > types in decimal.py, thus changing the API. This is one of the things that
> > should be decided *before* the PEP is accepted.
>
> Here yo
On 17/04/2011 17:05, Michael Foord wrote:
On 17/04/2011 00:16, Antoine Pitrou wrote:
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 ne
On 17/04/2011 07:28, "Martin v. Löwis" wrote:
Well, there was a 5x speedup demonstrated comparing simplejson to the
standard library json module.
Can you kindly point to that demonstration?
Hmm... according to a later email in this thread it is 350ms vs 250ms
for an 11kb sample. That's a nice
On 17/04/2011 00:16, Antoine Pitrou wrote:
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
On Sun, 17 Apr 2011 00:30:22 -0700, Raymond Hettinger
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 said, yes this is a well thought-out
> >> proposa
On Sun, 17 Apr 2011 12:14:51 +0200, Stefan Krah wrote:
> I'm not sure that I understand the duplication of effort: If there
> is a C module without a Python implementation in the stdlib, then
> the PyPy, Jython, and IronPython developers are free to cooperate
> and implement a single Python versio
On 17 April 2011 02:48, Steven D'Aprano wrote:
> 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
On Mon, Apr 18, 2011 at 12:03 AM, Jacob Kaplan-Moss wrote:
> Just to fill in a bit of missing detail about our process since the
> doc doesn't perfectly describe what happens:
>
> * Our pre-announce list is *really* short. It consists of release
> managers for various distributions that distribute
On Sun, 17 Apr 2011 09:30:17 -0400, Jesse Noller wrote:
> On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> > On Sat, 16 Apr 2011 21:32:48 -0500 Brian Curtin
> > wrote:
> >> > Three weeks after this security vulnerability was *publicly* reported on
> >> > bugs.python.org, and two days af
On Sat, Apr 16, 2011 at 9:23 AM, Nick Coghlan wrote:
> On Sat, Apr 16, 2011 at 9:45 PM, Gustavo Narea wrote:
>> May I suggest that you adopt a policy for handling security issues like
>> Django's?
>> http://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-security-issues
>
> When t
On Sun, Apr 17, 2011 at 9:42 AM, Antoine Pitrou wrote:
> Le dimanche 17 avril 2011 à 09:30 -0400, Jesse Noller a écrit :
>> >
>> > If we want to make official announcements (like releases or security
>> > warnings), I don't think the blog is appropriate. A separate
>> > announcement channel (maili
On 17 April 2011 06:32, R. David Murray wrote:
> I don't think the PEP is asking this either (or if it is I agree it
> shouldn't be). The way to get full branch coverage (and yes Exarkun is
> right, this is about individual branches; see coverage.py --branch)
One thing I'm definitely uncomfortab
On Sun, 17 Apr 2011 08:30:33 -0400
Fred Drake wrote:
> On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> > A separate announcement channel (mailing-list or newsgroup) would be better,
> > where people can subscribe knowing they will only get a couple of e-mails a
> > year.
>
> Sounds like
Vinay Sajip, 17.04.2011 12:33:
Antoine Pitrou writes:
Feel free to share your numbers.
I've now got my fork working on Python 3.2 with speedups. According to a
non-scientific simple test:
Python 2.7
==
Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2]
11.21484375
Le dimanche 17 avril 2011 à 09:30 -0400, Jesse Noller a écrit :
> >
> > If we want to make official announcements (like releases or security
> > warnings), I don't think the blog is appropriate. A separate
> > announcement channel (mailing-list or newsgroup) would be better, where
> > people can su
On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> On Sat, 16 Apr 2011 21:32:48 -0500
> Brian Curtin wrote:
>> > Three weeks after this security vulnerability was *publicly* reported on
>> > bugs.python.org, and two days after it was semi-officially announced,
>> > I'm still waiting for sec
On Sun, 17 Apr 2011 01:32:15 -0400
"R. David Murray" wrote:
>
> I personally have no problem with the 100% coverage being made a
> recommendation in the PEP rather than a requirement. It sounds like
> that might be acceptable to Antoine. Actually, I would also be fine with
> saying "comprehensi
On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> A separate announcement channel (mailing-list or newsgroup) would be better,
> where people can subscribe knowing they will only get a couple of e-mails a
> year.
Sounds like python-announce to me, with a matching entry on the front
of www.
On Sat, 16 Apr 2011 21:32:48 -0500
Brian Curtin wrote:
> > Three weeks after this security vulnerability was *publicly* reported on
> > bugs.python.org, and two days after it was semi-officially announced,
> > I'm still waiting for security updates for my Ubuntu and Debian systems!
> >
> > I recko
On Sun, 17 Apr 2011 09:21:32 +0200
Stefan Behnel wrote:
> Antoine Pitrou, 16.04.2011 19:27:
> > On Sat, 16 Apr 2011 16:47:49 + (UTC)
> > Vinay Sajip wrote:
> >> Bob made a comment in passing that simplejson (Python) is about as fast as
> >> stdlib json (C extension), on 2.x.
> >
> > I think Bo
R. David Murray wrote:
> > The PEP seems to be predicated on a notion that anything written in C is
> > bad and
> > that all testing is good. AFAICT, it doesn't provide any practical advice
> > to
> > someone pursuing a non-trivial project (such as decimal or threading). The
> > PEP
>
> Deci
Brett Cannon wrote:
> Now if people would actually support simply not accepting any more C modules
> into the Python stdlib (this does not apply to CPython's stdlib), then I'm all
> for that. I only went with the "accelerator modules are okay" route to help
> get
> acceptance for the PEP. But if
Stefan Behnel behnel.de> writes:
> 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
> piece of code. Not in the se
Antoine Pitrou pitrou.net> writes:
> Feel free to share your numbers.
I've now got my fork working on Python 3.2 with speedups. According to a
non-scientific simple test:
Python 2.7
==
Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2]
11.21484375 KiB read
Timing si
Brett Cannon wrote:
> Since they do not typically support the entire `C API of Python`_ they
> are unable to use the code used to create the module. Often times this
> leads these other VMs to either re-implement the modules in pure
> Python or in the programming language used to i
On Sun, Apr 17, 2011 at 08:22:20AM +0200, Stefan Behnel wrote:
> 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 q
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 said, yes this is a well thought-out
>> proposal
>> that will actually benefit any of the various implementations.
>
> In tha
Antoine Pitrou, 16.04.2011 19:27:
On Sat, 16 Apr 2011 16:47:49 + (UTC)
Vinay Sajip wrote:
Bob made a comment in passing that simplejson (Python) is about as fast as
stdlib json (C extension), on 2.x.
I think Bob tested with an outdated version of the stdlib json module
(2.6 or 2.7, perhaps
41 matches
Mail list logo
