On 18.04.2011 21:39, R. David Murray wrote:
>> > +Policy objects are the mechanism used to provide the email package with
>> > the
>> > +flexibility to handle all these disparate use cases,
>>
>> Looks like something is missing from this sentence :)
>
> Éric thought so too, but it reads fine t
Brett Cannon, 05.04.2011 01:46:
At both the VM and language summits at PyCon this year, the issue of
compatibility of the stdlib amongst the various VMs came up. Two issues came
about in regards to modules that use C code. One is that code that comes in
only as C code sucks for all other VMs that
I just want to say upfront that my personal life has just gotten very hectic
as of late (green card stuff for my wife who is Canadian) and probably will
not let up until June. So if I go a while without replying to points being
made for quite a while, I apologize. Luckily there seem to be others he
R. David Murray, 18.04.2011 14:30:
On Mon, 18 Apr 2011 09:36:20 +0100, Paul Moore wrote:
On 18 April 2011 08:05, Maciej Fijalkowski wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger wrote:
The PEP seems to be predicated on a notion that anything written in C is
bad and that all testin
Raymond Hettinger, 18.04.2011 19:26:
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
* we usually target CPython version that's already frozen, which is
pretty inconvinient to post this changes back. Example would be a
socket module where it has changed enough in 3.x that 2.7 changes ma
On Mon, 18 Apr 2011 20:26:36 +0200, Georg Brandl wrote:
> On 18.04.2011 20:00, r.david.murray wrote:
>
> > diff --git a/Doc/library/email.parser.rst b/Doc/library/email.parser.rst
> > --- a/Doc/library/email.parser.rst
> > +++ b/Doc/library/email.parser.rst
> > @@ -112,8 +118,13 @@
> > :class
Maciej Fijalkowski, 18.04.2011 19:11:
On Mon, Apr 18, 2011 at 6:32 PM, Éric Araujo wrote:
We try very hard to optimize for usual python idioms. They're very
often much better than specific cpython hacks. Unless you mean things
like rebiding a global into default a "pythonic idiom". We had to
rew
On 18.04.2011 20:00, r.david.murray wrote:
> diff --git a/Doc/library/email.parser.rst b/Doc/library/email.parser.rst
> --- a/Doc/library/email.parser.rst
> +++ b/Doc/library/email.parser.rst
> @@ -112,8 +118,13 @@
> :class:`~email.message.Message` (see :mod:`email.message`). The factory
> w
On Mon, 18 Apr 2011 18:34:06 +0200, =?UTF-8?Q?=C3=89ric_Araujo?=
wrote:
> > Perhaps we need a @python_implementation_detail skip decorator?
> Thatâs called test.support.cpython_only (see also
> test.support.check_impl_detail). Youâre welcome.
Nope. That's not what I was talking about.
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
>
> * we usually target CPython version that's already frozen, which is
> pretty inconvinient to post this changes back. Example would be a
> socket module where it has changed enough in 3.x that 2.7 changes make
> no sense.
Do you have an
On Mon, Apr 18, 2011 at 6:32 PM, Éric Araujo wrote:
> Hi,
>
>> We try very hard to optimize for usual python idioms. They're very
>> often much better than specific cpython hacks. Unless you mean things
>> like rebiding a global into default a "pythonic idiom". We had to
>> rewrite places in stand
Hi,
Perhaps we need a @python_implementation_detail skip decorator?
That’s called test.support.cpython_only (see also
test.support.check_impl_detail). You’re welcome.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Hi,
We try very hard to optimize for usual python idioms. They're very
often much better than specific cpython hacks. Unless you mean things
like rebiding a global into default a "pythonic idiom". We had to
rewrite places in standard library which are precisely not very
pythonic.
If I understa
Mark Summerfield responded to Martin's python-announce post. Rather than
approving it I rejected it and forwarded it here. (I suppose I could have
forwarded it directly to Martin, but that would have required that I recall
or look up his email address...)
Skip
___
--- Begin Message ---
Hi Martin,
On Sun, 17 Apr 2011 23:57:05 +0200
"Martin v. Löwis" wrote:
> 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.
With Martin getting ready to release 2.5.6, I think it's time to prepare a
2.6.7 source-only security release.
I'll work my way through the NEWS file and recent commits, but if there is
anything that you know is missing from the 2.6 branch, please let me know. It
would be especially helpful if th
On Mon, 18 Apr 2011 09:36:20 +0100, Paul Moore wrote:
> On 18 April 2011 08:05, Maciej Fijalkowski wrote:
> > On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
> > wrote:
>
> >> The PEP seems to be predicated on a notion that anything written in C is
> >> bad and that all testing is good.
> >
On Mon, 18 Apr 2011 09:36:20 +0100
Paul Moore wrote:
> On 18 April 2011 08:05, Maciej Fijalkowski wrote:
> > On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
> > wrote:
>
> >> Almost none of the concerns that have been raised has been addressed. Does
> >> the PEP only apply to purely algorit
On 18 April 2011 08:05, Maciej Fijalkowski wrote:
> On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
> wrote:
>> Almost none of the concerns that have been raised has been addressed. Does
>> the PEP only apply to purely algorithmic modules such as heapq or does it
>> apply to anything written
Nick Coghlan gmail.com> writes:
> Consider trying:
>
> import sys
> sys.modules["_json"] = 0 # Block the C extension
> import json
>
> in a fresh interpreter.
>
Thanks for the tip. The revised script at
https://gist.github.com/924626
shows more believable numbers vis-à-vis the no-speedups c
On Sun, Apr 17, 2011 at 4:19 AM, 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
>> > this PEP fin
21 matches
Mail list logo
