On Thu, 29 Sep 2011 11:36:21 +1300, Greg Ewing wrote:
>> I do hope, though, that the chosen name is *not*:
>>
>> - 'interval'
>>
>> - 'interpolate' or similar
>
> Would 'subdivide' be acceptable?
I'm not great at finding names, and I don't totally love it, but I
certainly don't see any probl
Le jeudi 29 septembre 2011 02:07:02, Benjamin Peterson a écrit :
> 2011/9/28 victor.stinner :
> > http://hg.python.org/cpython/rev/36fc514de7f0
> > changeset: 72512:36fc514de7f0
> > user:Victor Stinner
> > date:Thu Sep 29 01:12:24 2011 +0200
> > summary:
> > Enhance Py_ARRAY_LEN
> Resizing
>
>
> Codecs use resizing a lot. Given that PyCompactUnicodeObject
> does not support resizing, most decoders will have to use
> PyUnicodeObject and thus not benefit from the memory footprint
> advantages of e.g. PyASCIIObject.
Wrong. Even if you create a string using the lega
2011/9/28 victor.stinner :
> http://hg.python.org/cpython/rev/36fc514de7f0
> changeset: 72512:36fc514de7f0
> user: Victor Stinner
> date: Thu Sep 29 01:12:24 2011 +0200
> summary:
> Enhance Py_ARRAY_LENGTH(): fail at build time if the argument is not an array
>
> Move other variou
Is there some reason str.format had such major surgery done to it? It
appears parts of it were removed from stringlib. I had not even thought
to look at the code before it was merged, as it never occurred to me
anyone would do that.
I left it in stringlib even in 3.x because there's the occasional
Fernando Perez wrote:
Now, I *suspect* (but don't remember for sure) that the option to have it
right-hand-open-ended was to match the mental model people have for range:
In [5]: linspace(0, 10, 10, endpoint=False)
Out[5]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
In [6]: rang
In article <74f6adfa-874d-4bac-b304-ce8b12d80...@masklinn.net>,
Xavier Morel wrote:
> On 2011-09-28, at 19:49 , Martin v. Löwis wrote:
> >
> > Thanks for the advise - I didn't expect that Apple ships thhree compilers
> Yeah I can understand that, they're in the middle of the transition but Cla
On Tue, 27 Sep 2011 11:25:48 +1000, Steven D'Aprano wrote:
> The audience for numpy is a small minority of Python users, and they
Certainly, though I'd like to mention that scientific computing is a major
success story for Python, so hopefully it's a minority with something to
contribute
> te
Hi,
First of all, I am sincerely sorry if this is wrong mailing list to ask this
question. I checked out definitions of couple other mailing list, and this
one seemed most suitable. Here is my question:
Let's say I want to change a single keyword, let's say import keyword, to be
spelled as someth
On 2011-09-28, at 19:49 , Martin v. Löwis wrote:
>
> Thanks for the advise - I didn't expect that Apple ships thhree compilers…
Yeah I can understand that, they're in the middle of the transition but Clang
is not quite there yet so...
___
Python-Dev mai
> Does Clang also fail to compile this? Clang was updated from 1.6 to 2.0 with
> Xcode 4, worth a try.
clang indeed works fine.
> Also, from your version listing it seems to be llvm-gcc (gcc frontend with
> llvm backend I think),
> is there no more straight gcc (with gcc frontend and backend)?
> Codecs use resizing a lot. Given that PyCompactUnicodeObject
> does not support resizing, most decoders will have to use
> PyUnicodeObject and thus not benefit from the memory footprint
> advantages of e.g. PyASCIIObject.
No, codecs have been rewritten to not use resizing.
> PyASCIIObject has a
2011/9/28 M.-A. Lemburg :
> Guido van Rossum wrote:
>> Given the feedback so far, I am happy to pronounce PEP 393 as
>> accepted. Martin, congratulations! Go ahead and mark ity as Accepted.
>> (But please do fix up the small nits that Victor reported in his
>> earlier message.)
>
> I've been workin
Guido van Rossum wrote:
> Given the feedback so far, I am happy to pronounce PEP 393 as
> accepted. Martin, congratulations! Go ahead and mark ity as Accepted.
> (But please do fix up the small nits that Victor reported in his
> earlier message.)
I've been working on feedback for the last few days
Congrats! Python 3.3 will be better because of this.
On Wed, Sep 28, 2011 at 12:48 AM, "Martin v. Löwis" wrote:
> I have now merged the PEP 393 implementation into default.
> The main missing piece is the documentation; contributions are
> welcome.
--
--Guido van Rossum (python.org/~guido)
Oops, I accidentally hit Reply instead of Reply to All...
On Wed, Sep 28, 2011 at 1:05 PM, Michael Foord wrote:
> On 27/09/2011 19:59, Laurens Van Houtven wrote:
>
> Sure, you just *do* it. The only advantage I see in assertNotRaises is that
> when that exception is raised, you should (and would
On 2011-09-28, at 13:24 , mar...@v.loewis.de wrote:
> The gcc that Apple ships with the Lion SDK (not sure what Xcode version that
> is)
Xcode 4.1
> I'm not aware of a work-around in the code. My work-around is to use gcc-4.0,
> which is still available on my system from an earlier Xcode installa
The gcc that Apple ships with the Lion SDK (not sure what Xcode
version that is)
miscompiles Python now. I've reported this to Apple as bug 10143715;
not sure whether
there is a public link to this bug report.
In essence, the code
typedef struct {
long length;
long hash;
int stat
Ethan Furman wrote:
Well, actually, I'd be using it with dates. ;)
Seems to me that one size isn't going to fit all.
Maybe we really want two functions:
interpolate(start, end, count)
Requires a type supporting addition and division,
designed to work predictably and accurat
On 27/09/2011 19:59, Laurens Van Houtven wrote:
Sure, you just *do* it. The only advantage I see in assertNotRaises is
that when that exception is raised, you should (and would) get a
failure, not an error.
There are some who don't see the distinction between a failure and an
error as a useful
On 27/09/2011 19:46, Wilfred Hughes wrote:
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd
raise it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so
on. So, it seems odd to me that there isn't assertNotRaises. Is there
any pa
On Wed, Sep 28, 2011 at 09:43:13AM +1000, Steven D'Aprano wrote:
> Oleg Broytman wrote:
> >On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
> >>+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
> >>+"""Fail if an exception of class excClass is throw
On 27 September 2011 19:59, Laurens Van Houtven <_...@lvh.cc> wrote:
> Sure, you just *do* it. The only advantage I see in assertNotRaises is that
> when that exception is raised, you should (and would) get a failure, not an
> error.
It's a useful distinction. I have found myself writing code of
I have now merged the PEP 393 implementation into default.
The main missing piece is the documentation; contributions are
welcome.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
> Surely there must be more new APIs and changes that need documenting?
Correct. All documentation still needs to be written.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
25 matches
Mail list logo
