Eric Smith wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built, at which time the encoding has
Hi,
I would like to make request for a review of three patches:
#2385: fixes a run_setup bug, and adds a test_core module, that can be used
later to improve core.py coverage (http://bugs.python.org/issue2385)
#2461: adds a test_util.py to distutils, to cover util.py. It does not cover
On Sun, Mar 23, 2008 at 8:37 AM, Lennart Regebro [EMAIL PROTECTED] wrote:
Eric Smith wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import
+## triangular
+
+def triangular(self, low, high, mode):
+Triangular distribution.
+
+Continuous distribution bounded by given lower and upper limits,
+and having a given mode value in-between.
+
+
On Sat, Mar 22, 2008 at 09:13:24PM +0100, Martin v. L?wis wrote:
Unfortunately no. I was looking for it, but couldn't find it. He
mentioned a website with a call for action, but I couldn't find
that, either :-(
We're working on the video, but I think it'll be a few weeks before
things start to
Hi Mike.
Travis is the best person to discuss the status of the buffer APIs.
Cheers,
n
On Sat, Mar 22, 2008 at 2:50 PM, Mike Sullivan [EMAIL PROTECTED] wrote:
What is the current state of the N-D Array Interface proposal
(http://numpy.scipy.org/array_interface.shtml). Some work was done on
On Mar 22, 5:13 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
Unfortunately no. I was looking for it, but couldn't find it. He
mentioned a website with a call for action, but I couldn't find
that, either :-(
As I tried to reply (in a message that is waiting for moderation), the
site seems to be
On Sun, Mar 23, 2008 at 2:13 PM, Thomas Wouters [EMAIL PROTECTED] wrote:
That was always the assumption, and also the idea for 2.6 and 2.7. I would
much rather 3.0 isn't widely accepted for a few years longer than that it be
cluttered with backward compatibility crap, and even rather than that
On Sat, Mar 22, 2008 at 2:58 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run.
For the
Would turning the -3 flag on make it too hard to diagnose problems?
Yes. I don't think it should be turned on regularly in the tests until
they regularly are quiet under -3.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Hello!
I've successfully back ported the bytearray type and the io module from
3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm
down to four failing byte tests and one failing io test. The failing
byte tests are all related to pickling and subclassing.
I like to get the
On Sun, Mar 23, 2008 at 3:02 PM, Martin v. Löwis wrote:
[talking about running the buildbots using the -3 flag to issue Py3K warnings]
Yes. I don't think it should be turned on regularly in the tests until
they regularly are quiet under -3.
So the plan is to silence all Py3K warnings in the
So the question is rather: Do you want to disk a community split, or
add forwards compatibility?
I don't think the risk is big. As far as people start saying I will
only support Python 3, or saying I will not support Python 3 - that's
fine.
In the former case, people can still continue to use
Steven Bethard wrote:
On Sun, Mar 23, 2008 at 3:02 PM, Martin v. Löwis wrote:
[talking about running the buildbots using the -3 flag to issue Py3K warnings]
Yes. I don't think it should be turned on regularly in the tests until
they regularly are quiet under -3.
So the plan is to silence
Would turning the -3 flag on make it too hard to diagnose problems?
Martin Yes. I don't think it should be turned on regularly in the tests
Martin until they regularly are quiet under -3.
Maybe regrtest should gain a -3 flag. All it would have to do is restart
itself moving the -3
skip Maybe regrtest should gain a -3 flag. All it would have to do is
skip restart itself moving the -3 from after regrtest to before it.
Ehh... That didn't seem like such a great idea about 10 seconds after I hit
send. Adding a test3 target to Makefile.pre.in is a lot easier.
Skip
On Sun, Mar 23, 2008 at 10:45 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
So the question is rather: Do you want to disk a community split, or
add forwards compatibility?
I don't think the risk is big. As far as people start saying I will
only support Python 3, or saying I will not
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about looks.
Can you give me examples of such software? Are you perhaps talking
about closed source software?
So, regarding -3 warnings in the 2.6 test code, should they be fixed or not?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Sun, Mar 23, 2008 at 6:21 PM, [EMAIL PROTECTED] wrote:
So, regarding -3 warnings in the 2.6 test code, should they be fixed or
not?
I think we should introduce a decorator and/or a context manager in
test_support like this:
def silence_py3k(func):
def decorator(*args, **kwargs):
What is the precise specification of the builtin print function.
Does it call str, or does it just behave as if the builtin str had
been called?
In 2.5, the print statement ignores any overrides of the str builtin,
but I'm not sure whether a _function_ should -- and I do think it
should be
On Mon, 24 Mar 2008 00:14:13 +0100, \Martin v. Löwis\ [EMAIL PROTECTED]
wrote:
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about looks.
Can you give me
Terry Reedy
The standard (and to me, preferable) way of dealing
with such things is to have an 'installation manager'
that can reinstall as well as delete and that has a
check box for various things to delete. This is what
Python needs.
Paul Moore:
I'd dispute strongly that this is a
23 matches
Mail list logo
