Am 28.09.2011 08:35, schrieb martin.v.loewis:
http://hg.python.org/cpython/rev/8beaa9a37387
changeset: 72475:8beaa9a37387
user:Martin v. Löwis mar...@v.loewis.de
date:Wed Sep 28 07:41:54 2011 +0200
summary:
Implement PEP 393.
[...]
diff --git a/Doc/c-api/unicode.rst
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
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
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 the
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 thrown by
+
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
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
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
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
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
Oops, I accidentally hit Reply instead of Reply to All...
On Wed, Sep 28, 2011 at 1:05 PM, Michael Foord fuzzy...@voidspace.org.ukwrote:
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,
Congrats! Python 3.3 will be better because of this.
On Wed, Sep 28, 2011 at 12:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I have now merged the PEP 393 implementation into default.
The main missing piece is the documentation; contributions are
welcome.
--
--Guido van Rossum
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,
2011/9/28 M.-A. Lemburg m...@egenix.com:
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
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
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)?
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
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
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 wink
In article 74f6adfa-874d-4bac-b304-ce8b12d80...@masklinn.net,
Xavier Morel catch-...@masklinn.net 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
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]:
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
2011/9/28 victor.stinner python-check...@python.org:
http://hg.python.org/cpython/rev/36fc514de7f0
changeset: 72512:36fc514de7f0
user: Victor Stinner victor.stin...@haypocalc.com
date: Thu Sep 29 01:12:24 2011 +0200
summary:
Enhance Py_ARRAY_LENGTH(): fail at build time if
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 legacy API
Le jeudi 29 septembre 2011 02:07:02, Benjamin Peterson a écrit :
2011/9/28 victor.stinner python-check...@python.org:
http://hg.python.org/cpython/rev/36fc514de7f0
changeset: 72512:36fc514de7f0
user:Victor Stinner victor.stin...@haypocalc.com
date:Thu Sep 29 01:12:24
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 problems with
26 matches
Mail list logo
