On Sun, Oct 11, 2009 at 12:44 PM, Raymond Hettinger wrote:
> [Mark Dickinson]
>>
>> - string to float *and* float to string conversions are both guaranteed
>> correctly rounded in 3.x: David Gay's code implements the conversion
>> in both directions, and having correctly rounded string -> float
[Glyph Lefkowitz ]
> This reasoning definitely makes sense to me; with all the
> dependency-migration
> issues 3.x could definitely use some carrots. However, I don't think I agree
> with it,
> because this doesn't feel like a big new feature, just some behavior which
> has changed.
The c
On Sun, Oct 11, 2009 at 4:31 PM, Frank Wierzbicki wrote:
> On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" wrote:
>> So I propose that the python.org version is identified as "python".
> I'll add my voice to the group that likes "cpython" and "CPython" as
> the identifier of the python.org imp
On Fri, Oct 9, 2009 at 8:34 PM, "Martin v. Löwis" wrote:
> Also, why is it the name of the JIT compiler, and not the name of the
> source language compiler?
>From the Jython side it is easier to get the VM name compared to the
source language compiler. Although there is a property on
java.lang.Sy
On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" wrote:
> I think it is important to confirm in advance that all the
> implementations listed below agree to implement the PEP "soonish" after
> it's adopted. "Required" sounds like a strong term - however, if an
> implementation chooses not to impl
On Sun, Oct 11, 2009 at 10:41 PM, Antoine Pitrou wrote:
> Michael Sparks gmail.com> writes:
>>
>> I know it's the upteen-thousandth time it's been discussed, but
>> removal of the GIL in 3.x would probably be pretty big carrots for
>> some. I know the arguments [...]
>
> Not before someone produc
Michael Sparks gmail.com> writes:
>
> I know it's the upteen-thousandth time it's been discussed, but
> removal of the GIL in 3.x would probably be pretty big carrots for
> some. I know the arguments [...]
Not before someone produces a patch anyway. It is certainly not as easy as you
seem to thi
2009/10/11 Michael Sparks :
> On Sunday 11 October 2009 21:00:41 Glyph Lefkowitz wrote:
>> with all the
>> dependency-migration issues 3.x could definitely use some carrots.
> ..
>> everybody's favorate bugaboo, multicore parallelism.
>
> I know it's the upteen-thousandth time it's been discussed,
On Sunday 11 October 2009 21:00:41 Glyph Lefkowitz wrote:
> with all the
> dependency-migration issues 3.x could definitely use some carrots.
..
> everybody's favorate bugaboo, multicore parallelism.
I know it's the upteen-thousandth time it's been discussed, but
removal of the GIL in 3.x would pr
On Sun, Oct 11, 2009 at 5:16 PM, Brett Cannon wrote:
> On Sun, Oct 11, 2009 at 13:00, Glyph Lefkowitz wrote:
>
>> The carrots I'm interested in as a user are new possibilties, like new
>> standard library features, a better debugger/profiler, or everybody's
>> favorate bugaboo, multicore parallel
On Sun, Oct 11, 2009 at 13:00, Glyph Lefkowitz wrote:
> On Sun, Oct 11, 2009 at 3:48 PM, Guido van Rossum wrote:
>
>
>> I'm -0 -- mostly because of the 3rd party doctests and perhaps also
>> because I'd like 3.x to have some carrots. (I've heard from at least
>> one author who is very happy with 3
On Sun, Oct 11, 2009 at 7:27 PM, Steven Bethard
wrote:
>> I am working with Tarek to keep Windows issues (and in particular this
>> one) on the agenda. It's quite hard at times, as getting a
>> representative sample of Windows users' preferences/requirements is
>> difficult at best (Windows users
On Thu, Oct 8, 2009 at 2:56 PM, Paul Moore wrote:
> In this context, eggs are "merely" the first (and most important)
[..]
> example of a format extension, and so should drive the development of
> a standard.
>
> To summarise:
>
> I believe that we need a statement of direction on the (zipped) egg
Guido van Rossum schrieb:
> On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl wrote:
>> Which I noticed since it's cited in the BeOpen license we still refer
>> to in LICENSE. Since pythonlabs.com itself is still up, it probably
>> isn't much work to make the logos.html URI work again, but I don't k
Guido van Rossum wrote:
On Sun, Oct 11, 2009 at 11:28 AM, Mark Dickinson wrote:
In a recent #python-dev IRC conversation, it was suggested that we
should consider backporting the new-style float repr from py3k to
trunk. I'd like to get people's opinions on this idea.
[...]
Possible problems:
On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl wrote:
> Which I noticed since it's cited in the BeOpen license we still refer
> to in LICENSE. Since pythonlabs.com itself is still up, it probably
> isn't much work to make the logos.html URI work again, but I don't know
> who maintains that page.
On Sun, Oct 11, 2009 at 3:48 PM, Guido van Rossum wrote:
> I'm -0 -- mostly because of the 3rd party doctests and perhaps also
> because I'd like 3.x to have some carrots. (I've heard from at least
> one author who is very happy with 3.x for the next edition of his
> "programming for beginners"
Which I noticed since it's cited in the BeOpen license we still refer
to in LICENSE. Since pythonlabs.com itself is still up, it probably
isn't much work to make the logos.html URI work again, but I don't know
who maintains that page.
cheer,
Georg
--
Thus spake the Lord: Thou shalt indent with
On Sun, Oct 11, 2009 at 11:28 AM, Mark Dickinson wrote:
> In a recent #python-dev IRC conversation, it was suggested that we
> should consider backporting the new-style float repr from py3k to
> trunk. I'd like to get people's opinions on this idea.
[...]
> Possible problems:
>
> - breaking docs
[Mark Dickinson]
- string to float *and* float to string conversions are both guaranteed
correctly rounded in 3.x: David Gay's code implements the conversion
in both directions, and having correctly rounded string -> float
conversions is essential to ensure that eval(repr(x)) recovers x ex
In a recent #python-dev IRC conversation, it was suggested that we
should consider backporting the new-style float repr from py3k to
trunk. I'd like to get people's opinions on this idea.
To recap quickly, the algorithm for computing the repr of floats changed
between Python 2.x and Python 3.x (w
Benjamin Peterson schrieb:
> 2009/10/11 Jesse Noller :
>> On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull
>> wrote:
>>
>>> If others are willing to play bad cop, as Aahz did, I'd be very happy
>>> to accept the benefit of a cleaned-up list. But I'm not willing to do
>>> it myself.
>>
>> Is
2009/10/11 Jesse Noller :
> On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull
> wrote:
>
>> If others are willing to play bad cop, as Aahz did, I'd be very happy
>> to accept the benefit of a cleaned-up list. But I'm not willing to do
>> it myself.
>
> Is it really that big of an issue that w
Antoine Pitrou pitrou.net> writes:
>
> Daniel Stutzbach stutzbachenterprises.com> writes:
> >
> > -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are
> active iterators, but I don't think there's a clean way to track the
> iterators.
>
> I've started experimenting, and i
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore wrote:
> 2009/10/9 Michael Foord :
>> Many Windows users would be quite happy if the standard mechanism for
>> installing non-source distributions on Windows was via the wininst binaries.
>
> +1 I'm one of those people.
+1 on installing packages on Wind
On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull
wrote:
> If others are willing to play bad cop, as Aahz did, I'd be very happy
> to accept the benefit of a cleaned-up list. But I'm not willing to do
> it myself.
Is it really that big of an issue that we have to discuss it
ad-infinitum and
2009/10/9 Michael Foord :
> Many Windows users would be quite happy if the standard mechanism for
> installing non-source distributions on Windows was via the wininst binaries.
+1 I'm one of those people.
> I wonder if it is going to be possible to make this compatible with the
> upcoming distuti
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > Trimming can be a PITA if you're using a crummy MUA
>
> How so? It merely requires the ability to navigate up and down by lines,
> and to select and delete text. I've used some very crummy MUAs, but the
> ability to trim quoted text
Daniel Stutzbach stutzbachenterprises.com> writes:
>
> -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are
active iterators, but I don't think there's a clean way to track the iterators.
I've started experimenting, and it seems reasonably possible using a simple
guard class
On 11 Oct 2009, at 18:07 , MRAB wrote:
Didn't the iPhone also lack cut-and-paste?
It did, but given text selection is a near-mandatory requirement to
cutting text (and pasting isn't very useful if you can't put anything
into the clipboard) those were implied consequences of the lack of
s
Antoine Pitrou pitrou.net> writes:
>
> 1. Add the safe methods listkeys(), listitems(), listvalues() which would
> behave as the keys(), etc. methods from 2.x
>
> 2. Make it so that keys(), items(), values() atomically build a list of
> items internally, which makes them more costly for large
On Sun, Oct 11, 2009 at 10:50 AM, Antoine Pitrou wrote:
> In py3k, the weak dict methods keys(), values() and items() have been
> changed to return iterators (they returned lists in 2.x).
> However, it turns out that it makes these methods quite fragile, because
> a GC collection can occur wheneve
MRAB mrabarnett.plus.com> writes:
>
[snipped three pages of quoted messages before a one-liner]
> Didn't the iPhone also lack cut-and-paste?
Not to sound harsh, but your quoting was a perfect example of wasted visual
bandwidth...
(are you posting from an iPhone ? ;-))
Antoine.
___
Masklinn wrote:
On 11 Oct 2009, at 13:36 , Tarek Ziadé wrote:
On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney
wrote:
"Stephen J. Turnbull" writes:
Trimming can be a PITA if you're using a crummy MUA
How so? It merely requires the ability to navigate up and down by lines,
and to select and del
Hello,
In py3k, the weak dict methods keys(), values() and items() have been
changed to return iterators (they returned lists in 2.x).
However, it turns out that it makes these methods quite fragile, because
a GC collection can occur whenever during iterating, destroy one of the
weakref'ed obj
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> Benjamin Peterson wrote:
>>> I forgot to ask before: Does this deprecate
>>> platform.python_implementation()?
>>
>> No, platform.py is meant to be portable across multiple Python
>> versions and as such not really suitable for such deprecations.
>>
>>
On 11 Oct 2009, at 13:36 , Tarek Ziadé wrote:
On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney > wrote:
"Stephen J. Turnbull" writes:
Trimming can be a PITA if you're using a crummy MUA
How so? It merely requires the ability to navigate up and down by
lines,
and to select and delete text. I've
Tarek Ziadé writes:
> You just can't do it on some mobile device mail clients. For instance
> Gmail's client on Android.
> It will just top-post and quote the whole mail for you AFAIK.
Wow, that *is* crummy. Perhaps a posse of users of that application can
loudly request this basic feature from
On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney wrote:
> "Stephen J. Turnbull" writes:
>
>> Trimming can be a PITA if you're using a crummy MUA
>
> How so? It merely requires the ability to navigate up and down by lines,
> and to select and delete text. I've used some very crummy MUAs, but the
> abil
Greg Ewing canterbury.ac.nz> writes:
>
> That's no reason to squander it, though. Quoting the entire
> message every time makes the size of the thread grow as
> O(n**2), and makes things harder to read as well. That's
> just senseless.
+1. It's always annoying to skim through a three-page quoted
Fred Drake writes:
> Most importantly, insufficient trimming makes many of us start to
> ignore threads we'd otherwise want to read more carefully or
> participate in, because the tedium of wading through all the quotes to
> make sure we catch all the content.
Absolutely. This is a significant r
"Stephen J. Turnbull" writes:
> Trimming can be a PITA if you're using a crummy MUA
How so? It merely requires the ability to navigate up and down by lines,
and to select and delete text. I've used some very crummy MUAs, but the
ability to trim quoted text has never been absent or difficult. Are
On Sun, 11 Oct 2009 03:26:41 pm Stephen J. Turnbull wrote:
> Indeed, and that's why I thanked Michael. Trimming can be a PITA if
> you're using a crummy MUA, and for reasons I have no intention of
> even trying to remember, let alone understand, a lot of people are
> very attached to their crummm
43 matches
Mail list logo
