[Terry Reedy]
On reading PEP3141 some months ago and again today, I thought and still do
that all the methods that depend on a 2s-complement representation and
implementation really belong to an implentation-defined subclass of
Integral. But I am not sure of the purpose of the class and of inc
On Thu, Jun 5, 2008 at 11:18 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 10:14 PM, Mark Hammond <[EMAIL PROTECTED]> wrote:
>> Set an error if the 'arg' tuple doesn't have a length of zero?
>>
>
> Oh, that isn't a bad idea at all. I will try this. Thanks!
>
Worked f
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
"{num} occurs {num} times in this format string".format(dict(num=2))
If named arguments were to become mandatory, I'd want
to be able to write tha
Nick Coghlan wrote:
%r is about the worst case for the new syntax relative to the old - two
characters become 5. It's worth looking at what those extra characters
buy us though:
However, those benefits are only realised some of the
time, and it's only in rare cases that they're all
realised at
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Keeping %-formatting but breaking a large
proportion of its uses doesn't seem like a goo
Guido van Rossum wrote:
> I consider multiprocessing a new API -- while it bears
> a superficial resemblance with the threading API the
> similarities are just that, and it should not be
> constrained by mistakes in that API.
The justification for including it is precisely that it is *not* a new
On Thu, Jun 5, 2008 at 10:06 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
>>
>> I meant a cleaned version of the PEP - I still have docs and tests to redo
>>
> It would also be good if you could check Benjamin's patch on issue 3402 to
> give threading a PEP 8 compliant API and
On Thu, Jun 5, 2008 at 2:54 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 12:48 PM, Jesse Noller <[EMAIL PROTECTED]> wrote:
>> I'll have a cleaned version to you by end of day, and by day, I mean
>> by 10:00 EST :)
>
> Great! Please post that on the bug tracker when you'
Lisandro Dalcin schrieb:
> On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Thomas, Iff this helps, you have attached the backport but as an
> extension module. Sorry, I do not have time for the full backport.
> But at least, I've found that the Py3K implementation works
Thanks for the effor
> Agreed. %(something)s is quirky - you are bound to forget the final "s"
> (or whatever other specifier) from time to time.
But that gives a ValueError the first time you try it, no?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Thu, Jun 5, 2008 at 12:48 PM, Jesse Noller <[EMAIL PROTECTED]> wrote:
> I'll have a cleaned version to you by end of day, and by day, I mean
> by 10:00 EST :)
Great! Please post that on the bug tracker when you're ready.
--
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
I'll have a cleaned version to you by end of day, and by day, I mean
by 10:00 EST :)
On Thu, Jun 5, 2008 at 1:22 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've accepted your PEP. I think it still needs some clean-up and
> perhaps clarification of the agreement reached about API style, but
On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote:
Thomas, Iff this helps, you have attached the backport but as an
extension module. Sorry, I do not have time for the full backport.
But at least, I've found that the Py3K implementation works
You will need to build it with 'python2.6 setup.py bu
I've accepted your PEP. I think it still needs some clean-up and
perhaps clarification of the agreement reached about API style, but
there is nothing now that keeps you from implementing it! Hopefully
you'll make the beta release early next week.
--Guido
On Thu, Jun 5, 2008 at 8:10 AM, Jesse Noll
On Thu, Jun 05, 2008 at 09:41:44AM -0700, Bill Janssen wrote:
> > I think I agree with Raymond on the basic principle that simple ABC's
> > are easier to use than simple ones.
>
> I don't think he was saying that. He was saying that simple ABC's are
> easier to implement to.
Sorry; I used the wr
> I think I agree with Raymond on the basic principle that simple ABC's
> are easier to use than simple ones.
I don't think he was saying that. He was saying that simple ABC's are
easier to implement to.
It's not at all clear to me that simple ABC's are good in and of
themselves. I think a Stri
On Thu, Jun 5, 2008 at 6:23 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Hi,
> This summer, I am going to be revamping Python's test suite. Major
> things I plan to do include
> - rewriting regrtest.py to be a simple test driver
> - implementing CPython only decorators
> - moving skipping dat
Hi,
This summer, I am going to be revamping Python's test suite. Major
things I plan to do include
- rewriting regrtest.py to be a simple test driver
- implementing CPython only decorators
- moving skipping data to the tests themselves (perhaps with decorators)
- completing the transition to unitte
Thomas Heller schrieb:
> I'm currently trying to port the pep3118 ctypes changes which are already in
> the py3k branch to the trunk.
>
> In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use
> the memoryview object which exposes attributes like .format, .shape, .strides
> and
On Thu, 5 Jun 2008 10:43:20 pm Nick Coghlan wrote:
> I'm really starting to wonder if supporting positional arguments to
> str.format() *at all* is a mistake. Maybe we should ditch support for
> positional arguments and just accept a single dictionary as the sole
> parameter to format().
>
> For d
On Thu, Jun 5, 2008 at 9:53 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
>>
>> However, the flip side of this is that no one really "likes" the
>> threading API as-is, so putting the module into the standard library
>> with the matching API simply adds another "broken" API.
>
>
Hi Travis,
I'm currently trying to port the pep3118 ctypes changes which are already in
the py3k branch to the trunk.
In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use
the memoryview object which exposes attributes like .format, .shape, .strides
and so on for objects imple
On Thu, Jun 5, 2008 at 6:20 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>>
>> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> | From: "Guido van Rossum" <[EMAIL PROTECTED]>
>> | > Unless more folks actually say they agree I don't want to go
Nick Coghlan gmail.com> writes:
>
> %r is about the worst case for the new syntax relative to the old - two
> characters become 5.
Well there are other very common "worst cases" - namely %d, %f (and probably
a few less commonly used ones such as %X).
> For dictionary formatting, str.format() i
On Thu, 5 Jun 2008 08:50:32 pm Paul Moore wrote:
> On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > Yes, I don't particularly see the advantage of writing:
> >
> > "spam %s spam" % (value,)
> >
> > over
> >
> > "spam %s spam" % value
> >
> > Why require the first version?
>
> Because t
Jesse Noller wrote:
However, the flip side of this is that no one really "likes" the
threading API as-is, so putting the module into the standard library
with the matching API simply adds another "broken" API.
Provided threading gets a PEP 8 style API in 2.6 (which it looks like it
is going to
Terry Reedy wrote:
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| From: "Guido van Rossum" <[EMAIL PROTECTED]>
| > Unless more folks actually say they agree I don't want to go forward
| > with this. There was quite a bit of discussion about PEP 3141 and it
| >
On Thu, Jun 5, 2008 at 8:59 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>
>> Sounds good. (Maybe you want to contribute a patch to threading.py?
>> Your implementation notes are important. It could be quite independent
>> from PEP 371.)
>
> I created issue 3042 as an RFE
Guido van Rossum wrote:
Sounds good. (Maybe you want to contribute a patch to threading.py?
Your implementation notes are important. It could be quite independent
from PEP 371.)
I created issue 3042 as an RFE to add PEP 8 compliant aliases to the
threading module (including the notes about how
Raymond Hettinger wrote:
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to
Nick Coghlan wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string
without wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the propo
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string without
wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the proposal that allows *any*
On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Yes, I don't particularly see the advantage of writing:
>
> "spam %s spam" % (value,)
>
> over
>
> "spam %s spam" % value
>
> Why require the first version?
Because the second breaks if value is a tuple:
Python 2.5 (r25:51908, Sep 19 200
33 matches
Mail list logo
