I added a patch to SF: http://python.org/sf/1107887
I would like feedback on whether the approach is desirable.
The patch adds a new method type (flags) METH_ARGS that is used in
PyMethodDef. METH_ARGS means the min and max # of arguments are
specified in the PyMethodDef by adding 2 new fields.
On Tue, 25 Jan 2005 06:42:57 -0500, Raymond Hettinger
[EMAIL PROTECTED] wrote:
I think tested a method I changed from METH_O to METH_ARGS and could
not measure a difference.
Something is probably wrong with the measurements. The new call does much
more work than METH_O or METH_NOARGS.
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger [EMAIL PROTECTED] wrote:
I agree that METH_O and METH_NOARGS are near
optimal wrt to performance. But if we could have one METH_UNPACKED
instead of 3 METH_*, I think that would be a win.
. . .
Sorry, I meant eliminated w/3.0.
So,
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger [EMAIL PROTECTED] wrote:
This is what I mean about the patch taking on a life of its own. It's
an optimization patch that slows down METH_O and METH_NOARGS. It's a
incremental change that throws away backwards compatibility. It's a
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro [EMAIL PROTECTED] wrote:
Wouldn't it be better to have the peephole optimizer recognize the throwaway
nature of lists in these contexts:
for elt in [1, 2, 4, 8, 16]:
...
if foo in [list, tuple]:
...
(anywhere
On 6/2/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
Looking at bug #1209880, the following function from threadmodule.c is
referenced. I think the args==NULL case, which can return None
instead of a Boolean value, can never be reached because
PyArg_ParseTuple() will fail if args==NULL.
On 8/31/05, Oren Tirosh [EMAIL PROTECTED] wrote:
Writing programs that run on both 2.x and 3 may require ugly
version-dependent tricks like:
try:
compile
except NameError:
from sys import compile
Note we can ease this process a little by making a copy without
removing, e.g.,
Is there any reason to import exceptions? It's only done in 4 places:
Lib/asyncore.py, Lib/shutil.py, Lib/idlelib/PyShell.py, and
Lib/test/test_exceptions.py. I can understand the one in test, but
should the other 3 be removed since exceptions are builtin?
n
On 9/2/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Nope, but there is a large body of code out there that does use print
statements already. Again, I know you're prepared for breakage, but that
doesn't necessarily mean a completely blank sheet of paper.
Ideally I very much prefer that
break in gdbinit is apparently does not break a loop, but rather sets
a break point. I don't know how to hit the break within lineno with a
simple test case. Debugging pychecker with a C extension (matplotlib)
triggers it.
The only way I could see to fix it was by setting a continue flag and
Tim made me do it!
http://groups.google.com/group/comp.lang.python/msg/9075a3bc59c334c9
For whatever reason, I was just curious how his code could be sped up.
I kept seeing this append method being called and I thought, there's
an opcode for that. What happens if you replace var.append()
Index: test_ioctl.py
===
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_ioctl.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- test_ioctl.py 20 Mar 2003 04:33:16 - 1.2
+++
On 9/15/05, Rich Burridge [EMAIL PROTECTED] wrote:
Hi,
I'm involved with the team that's working towards installing Python 2.4.x
as part of a future release of the Solaris O/S.
Cool. I would like to hear more about what you are doing.
We currently have Python 2.3.x installed. We are
On 9/15/05, Anthony Baxter [EMAIL PROTECTED] wrote:
So we'll be cutting the 2.4.2 release candidate on Wednesday the 21st
(next week). Can people please make sure they are running the test
suite fully for any checkins between now and then? Also, please
consider the release24-maint branch
I ran 2.4.x through valgrind and found two small problems on Linux
that have been fixed. There may be some other issues which could
benefit from more eyes (small, probably one time memory leaks). The
entire run is here:
http://python.org/valgrind-2.4.2.out
(I need to write a lot more
On 9/19/05, Guido van Rossum [EMAIL PROTECTED] wrote:
That patch doesn't make sense to me -- the s code to
PyArg_ParseTuple doesn't return newly allocated memory, it just
returns a pointer into a string object that is owned by the caller
(really by the call machinery I suppose). Compare
On 9/21/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
(I need to write a lot more suppression rules for gentoo.)
This could be due to your using GCC 4. Apparently, gcc 4
is willing to inline Py_ADDRESS_IN_RANGE even though it
appears at the end of the file, at -O3.
I
On 9/29/05, Evan Jones [EMAIL PROTECTED] wrote:
Any chance that someone wants to commit this tiny two line fix?
That's reallly not the question you *want* to be asking. :-)
This might be the kind of fix that might be elegible to be backported to
Python 2.4 as well. It passes make test on
On 10/5/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:50 AM 10/4/2005 +0100, Michael Hudson wrote:
(anyone still thinking about removing the block stack?).
I'm not any more. My thought was that it would be good for performance, by
reducing the memory allocation overhead for frames enough
There's a problem with genexp's that I think really needs to get
fixed. See http://python.org/sf/1167751 the details are below. This
code:
foo(a = i for i in range(10))
generates NameError: name 'i' is not defined when run because:
2 0 LOAD_GLOBAL 0 (foo)
On 10/13/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Indeed. I should've threatened to kill the AST branch long ago! :)
:-)
I decreased a lot of the memory leaks. Here are some more to work on.
I doubt this list is complete, but it's a start:
PyObject_Malloc (obmalloc.c:717)
On 10/14/05, Neal Norwitz [EMAIL PROTECTED] wrote:
I decreased a lot of the memory leaks. Here are some more to work on.
I doubt this list is complete, but it's a start:
Oh and since I fixed the memory leaks in a generated file
Python/Python-ast.c, the changes still need to be implemented
We all know Guido likes Python. But the real question is do pythons like Guido?
http://python.org/neal/
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 10/10/05, Neal Norwitz [EMAIL PROTECTED] wrote:
There's a problem with genexp's that I think really needs to get
fixed. See http://python.org/sf/1167751 the details are below. This
code:
foo(a = i for i in range(10))
I agree with the bug report that the code should either raise
On 10/17/05, Tim Peters [EMAIL PROTECTED] wrote:
[Skip] Like Steve (and unlike Oleg), I get 404s for this page.I also tried www.python.org and ~neal.The original
http://python.org/neal/ worked fine for me, and still does.OTOH, http://www.python.org/neal/gets a 404, and (the original without the
Jeremy,
There are a bunch of mods from the AST branch that got integrated into
head. Hopefully, by doing this on python-dev more people will get
involved. I'll describe high level things first, but there will be a
ton of details later on. If people don't want to see this crap on
python-dev, I
On 11/1/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
I guess this ought to be recorded. :-(
The issue has been beaten to death and my position remains firm:
rather than playing namespace games, consistent renaming is the right
thing to do
We've been having some issues and discussions at work about cross
compiling. There are various people that have tried (are) cross
compiling python. Right now the support kinda sucks due to a couple
of reasons.
First, distutils is required to build all the modules. This means
that python must
There's still more clean up work to go, but the current AST is
hopefully much closer to the behaviour before it was checked in.
There are still a few small memory leaks.
After running the test suite, the total references were around 380k
(down from over 1,000k). I'm not sure exactly what the
On 11/20/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Can somebody please give a quick explanation how valgrind can give
*any* reasonable leak analysis when obmalloc is used? In the current
implementation, obmalloc never ever calls free(3), so all pool memory
should appear to have leaked.
I would really like it if someone could run Purify (or another memory
tool) on Windows. Purify on any another (unix) platform would be
nice, but I doubt it will show much more. By using different tools,
problems not found by one tool may be found by the other. Plus there
is windows specific
On 11/21/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
I don't think there's a shortage of Windows boxes among the python-dev
crowd (I have plenty). Does anyone knows that kind of box you need to
run purify these days ?
Dunno, but it would probably be fine on a reasonably new box with at
least
I just checked in the modification below. I'm not sure if this
behaviour is on purpose or by accident. Do we want to support hex
values in floats?
Do we want to support p, similar to e in floats?
Here are the lines from the test:
+self.assertEqual(float( 0x3.1 ), 3.0625)
+
On 11/22/05, Brett Cannon [EMAIL PROTECTED] wrote:
But if I had my way I think that having all AST objects be PyObjects
and then providing support for all three ways of getting access to the
AST (command-line, sys iterable, function for specific code object)
would be fantastic.
There needs
While running regrtest with -R to find reference leaks I found a usage
issue. When a codec is registered it is stored in the interpreter
state and cannot be removed. Since it is stored as a list, if you
repeated add the same search function, you will get duplicates in the
list and they can't be
On 11/24/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Should users have access to the search path (through a
codecs.unregister())?
Maybe, but why would you want to unregister a search function ?
If so, should it search from the end of the
list to the beginning to remove an item? That
There are still a few reference leaks I've been able to identify. I
didn't see an obvious solution to these (well, I saw one obvious
solution which crashed, so obviously I was wrong).
When running regrtest with -R here are the ref leaks reported:
test_codeccallbacks leaked [2, 2, 2, 2]
On 11/25/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Can you move the call to codecs.register_error() out of test_callbacks()
and retry?
It then leaks 3 refs on each call to test_callbacks().
n
--
import codecs
[24540 refs]
[24541 refs]
def handler(exc):
... l = [u%d %
On 11/28/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
Hope this helps explain a bit. Please speak up with how this can be
improved. Gotta run.
I would rewrite it as
[code snipped]
For those watching, Greg's and Martin's version were almost the same.
However, Greg's
On 11/29/05, Nick Coghlan [EMAIL PROTECTED] wrote:
When working on the CST-AST parser, there were only a few things I found to
be seriously painful about the memory management:
1. Remembering which free_* variant to call for AST nodes
2. Remembering which asdl_seq_*_free variant to
On 12/1/05, Jeremy Hylton [EMAIL PROTECTED] wrote:
Martin,
I'm not sure what your intent for this work is, but I'd like to create
a parallel arena branch and compare the results. I'll start work on
that tomorrow.
I think this is a good thing. It will be much easier to compare
On 12/11/05, Jim Fulton [EMAIL PROTECTED] wrote:
Can we officially mark __private as a mistake. Perhaps:
- Strongly discourage it in the style guide
This may be acceptable.
- Mark it in the language reference as a deprecated feature
- Generate deprecation warnings when it is used?
On 11/21/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I just checked in the modification below. I'm not sure if this
behaviour is on purpose or by accident.
[ /f shows diff on linux and windows ]
I checked in a fix for this so float('0x3') should not work on any platform
I'm not sure where the problem is, but this code leaks a reference:
parser = ET.XMLParser() ; parser.feed('xtext/x')
You need this to set it up:
from xmlcore.etree import cElementTree as ET
This isn't a memory leak according to valgrind.
Also, I noticed several places where errors where
I know this is OT, but I thought y'all might find this interesting. -- n
-- Forwarded message --
From: jack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
I saw in http://www.python.org/download/download_other.html that people notify
python ports to other platforms/devices.
I
On 12/22/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
I had lunch with Fred the other day, and he was worried about whether
anyone would garden the comments to remove spam.
I would help assuming this is easy--meaning a single click to remove a comment.
n
On 12/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So for at least the time being they go up nightly
(http://www.trentm.com/python). I don't know what Trent did to make that
happen, but he did it fairly quickly. I doubt it would be hard to replicate
on the docs server.
I couldn't let
On 12/23/05, Tim Peters [EMAIL PROTECTED] wrote:
http://docs.python.org/dev/results/
Wow! You get no test failures! I guess nobody tests on Windows
anymore. I've been getting test failures for months, and just
Hmmm, I thought others were running the tests on Windows too. There
was
On 12/24/05, Tim Peters [EMAIL PROTECTED] wrote:
You're asking a Windows guy about make: bad career move ;-)
:-)
-uall is helpful in finding bugs. One thing in particular here is
that test_compiler runs only a tiny subset of its full test unless an
appropriate -u flag is given.
Not to
On 1/2/06, Barry Warsaw [EMAIL PROTECTED] wrote:
I think we have a fundamental problem with Python-ast.c and
Python-ast.h. These files should not be both auto-generated and checked
into Subversion.
I agree with the problem statement.
The general rule should be that no file that is ever
Here's some info on setting up buildbot
http://www.python.org/dev/buildbot/. These instructions should be
cleaned up and put in the developers faq. Right now, the only person
that can generate/assign buildbot names/passwords is Martin AFAIK.
We currently have 4 slaves setup:
Linux: x86 and
test_bsddb3 fails for me with BSD DB 4.1 and 4.2 on gentoo Linux. I
think it has for a long time. Is anyone else seeing these failures?
You must use -u bsddb when running regrtest.
4.2 has 2 failures:
test02_associateAfterDB
(bsddb.test.test_associate.ShelveAssociateRecnoTestCase)
I've updated the script that builds python and the docs, runs the
tests, and copies everything up to docs.python.org. Currently, this
only works for the trunk. I'm not sure if there's much of a benefit
to set this up for branch(es) also.
The docs are here:
http://docs.python.org/dev/
The
On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The G5 *was* working. I changed nothing at my end. Got a mail yesterday
from Martin. It looks like PATH lost /usr/local/bin (where the Metissian
installer puts the svn executable). I added a /usr/bin/svn symlink, but
would really
I had a friend run regrtest -L on Mac OSX a while ago. There are
several memory leaks which still appear to be an issue. There are a
bunch of leaks reported from putenv which I'm not sure how to fix
The attached patch should correct one of the problems. Can someone
with a Mac test it? I'll
On 1/3/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I tried to, but couldn't. I'll be sending the mailer.py and mailer.conf
files in a private mail. I can't see anything wrong in that code.
Perhaps mailman is adding the spaces?
I looked into this briefly. I saw something like:
if prefix:
Anyone wanna give bsddb some tlc? Head and 2.4 work with 4.2 on amd64
and x86. Neither python version works when using BSD db 4.1 or 3.2. I
don't know anything about bsddb, so any help fixing this would be
appreciated.
In 4.1 it seems associate doesn't work.
http://python.org/sf/1332873
3.2
On 1/6/06, Michael Urman [EMAIL PROTECTED] wrote:
I put together a non-parsing checker last month to help me feel more
secure after http://python.org/sf/1365916. It's awful code, but the
simple things are easy to change or extend. Fixing the false positives
and other misinterpretations is
[moving to python-dev]
On 1/7/06, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Well, it is not the test that's broken... it's compiler.
[In reference to:
http://mail.python.org/pipermail/python-checkins/2006-January/048715.html]
In the past, we haven't checked in tests which are known to be
On 1/6/06, von Löwis Martin [EMAIL PROTECTED] wrote:
I just found that the intel compiler (icc 9.0)
also supports compiler warnings for portability
problems.
Cool. Thanks for the info. It would be nice if Intel would provide
Python developers with a permanent icc license for Python. Can
On 1/8/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
%f % 1.0
'1.00'
u%f % 1.0
u'1,00'
Is this intended? This breaks test_format on my box when test_builtin
(method
test_float_with_comma) is executed first.
No. %-formatting should always use the C
On 1/8/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I know very little about locale's. /f assigned me a bug
http://python.org/sf/1391872 which suggests I run all the tests in a
different locale than C. I think this is a good idea, but when I set
LANG or LC_ALL
On 1/8/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
import locale
locale.setlocale(locale.LC_NUMERIC, )
'[EMAIL PROTECTED]'
u%f % 1.0
u'1,00'
Is this intended? This breaks test_format on my box when test_builtin
(method
test_float_with_comma) is
On 1/9/06, Tim Peters [EMAIL PROTECTED] wrote:
...
[Tim]
That's no more or less painful than using C99's huge pile of PRId8,
PRId16, PRId32 (etc, etc) macros, defined there for similar purposes.
[Martin]
Right - and I consider them just as painful.
If you believe that this is really
On 1/9/06, Shane Hathaway [EMAIL PROTECTED] wrote:
I'd like to create a patch for the logging package, but before I do, I
need to know whether someone else is working on the package and whether
my patch is likely to be accepted. Is there another group I should talk to?
Vinay (copied)
On 1/9/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would have expected the first call to setlocale() to return de_DE.
No, it shouldn't. We are providing C semantics here, which is that
no locale functionality is activated unless the application explicitly
asks for it.
Thanks (to /f
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote:
centurion:~ python .
Segmentation fault
I fixed that in Oct in head and 2.4 branch. Although Skip filed a bug
since Py_FatalError() is called which generates a core dump in debug
builds at least. http://python.org/sf/1353504
I'm not sure
On 1/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
One concern might be performance. All buildbot slaves are contributed
hardware. I don't mind the load on my Mac (it's a dual processor g5), but
it may be an issue for other people.
I've contributed 2 machines. One is my personal box,
On 1/17/06, Guido van Rossum [EMAIL PROTECTED] wrote:
The difference between hex() and oct() and the proposed binary() is
I'd propose bin() to stay in line with the short abbreviated names.
Are these features used enough to have 3 builtins?
Would format(number, base) suffice?
format(5,
On 1/10/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
We'd also have to make sure that old extensions don't
just import with a warning, since the change will introduce
buffer overflows and seg faults in extensions that are not
aware of the change.
I agree that on 64-bit platforms we should
On 1/18/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Guido, we may be converging on a consensus for my proposal:
base(value, radix=2)
So far no one has shot at it, and it has gathered +1's from Steven,
Alex, Brett, and Nick.
+1 for me too, but I'd also like to deprecate hex() and
I would really like to stabilize a bunch of the current rough edges in
2.5. We are likely to have enough instability with the PEP 353
changes, so it would be better to fix some of these issues sooner
rather than later. There are a bunch of tests that are not stable.
It would really help to get
On 1/11/06, Trent Mick [EMAIL PROTECTED] wrote:
Does that make sense? We would just need /f's script in SVN.
in python/Tools/something or sandbox/something ?
python/Doc/tools/something?
Fredrik were you still working on that? I can make the changes to the
bb master. I thought Trent's
On 1/25/06, Tim Peters [EMAIL PROTECTED] wrote:
Because the server doesn't set listener_ready until after the server
has done listen(), and the client waits for that event, it should
be 100% reliable that the client's connect() succeeds.
Or do you have some other race in mind?
That's what
On 1/26/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
any progress ? does the script work in the buildbot setting, or
does it need tweaking ?
I haven't gotten to it and won't be able to in the next week+. If no
one beats me to it, I will get to it in a few weeks. I've got most of
the buildbot
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
what's the current release plan for Python 2.5, btw? I cannot find a
relevant PEP, and the what's new says late 2005:
but I don't think that anyone followed up on this. what's the current
status ?
Guido and I had a brief discussion
On 2/7/06, Christopher Armstrong [EMAIL PROTECTED] wrote:
Twisted is wonderful, powerful, rich, and very large. Perhaps a small
subset could be carefully extracted
The subject of putting (parts of) Twisted into the standard library
comes up once every 6 months or so, at least on our
On 2/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It looks like we need a Python 2.5 Release Schedule PEP.
Very draft: http://www.python.org/peps/pep-0356.html
Needs lots of work and release managers. Anthony, Martin, Fred, Sean
are all mentioned with TBDs and question marks.
n
On 2/11/06, Tim Peters [EMAIL PROTECTED] wrote:
[Tim telling how I broke pyuthon]
[Martin fixing it]
Sorry for the breakage (I didn't know about the Windows issues).
Thank you Martin for fixing it. I agree with the solution.
I was away from mail, ahem, working.
n
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Next, the schedule. Neal's draft of the schedule has us releasing 2.5
in October. That feels late -- nearly two years after 2.4 (which was
released on Nov 30, 2004). Do people think it's reasonable to strive
for a more aggressive (by a
On 2/10/06, Georg Brandl [EMAIL PROTECTED] wrote:
I am not experienced in releasing, but with the multitude of new things
introduced in Python 2.5, could it be a good idea to release an early alpha
not long after all (most of?) the desired features are in the trunk?
In the past, all new
On 2/13/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Monday 13 February 2006 10:03, Georg Brandl wrote:
The above docs are from August 2005 while docs.python.org/dev is current.
Shouldn't the old docs be removed?
I'm afraid I've generally been too busy to chime in much on this
through PEP 4 and 11 and determine what work needs to be done?
The more we distribute the work, the easier it will be on everyone.
You don't really want to listen to me whine any more do you? ;-)
Thank you,
n
PEP: 356
Title: Python 2.5 Release Schedule
Version: $Revision: 42375 $
Author: Neal Norwitz
On 2/15/06, Barry Warsaw [EMAIL PROTECTED] wrote:
I haven't been following the AST stuff closely enough, but I'm not crazy
about putting access to this in the sys module. It seems like it
clutters that up with a name that will be rarely used by the average
Python programmer.
Agreed. I'm
On 2/15/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
(is the xmlplus/xmlcore issue still an issue, btw?)
What issue are you talking about?
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 2/15/06, Alain Poirier [EMAIL PROTECTED] wrote:
- isn't the current implementation of itertools.tee (cache of previous
generated values) incompatible with the new possibility to feed a
generator (PEP 342) ?
I'm not sure what you are referring to. What is the issue?
n
On 2/15/06, Arkadiusz Miskiewicz [EMAIL PROTECTED] wrote:
Still few questions... one of developers/commiters reviews patch and commit
it? Few developers has to review single patch?
One developer can review and commit a patch. Sometimes we request
more input from other developers or interested
[Moving to python-dev]
I don't have a strong opinion. Any one else have an opinion about
removing --with-wctype-functions from configure?
n
--
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
neal.norwitz wrote:
Author: neal.norwitz
Date: Thu Feb 16 06:25:37 2006
New Revision: 42396
On 2/17/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi,
On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
http://www.python.org/peps/pep-0356.html
There is at least one SF bug, namely #1333982 Bugs of the new AST
compiler, that in my humble opinion absolutely needs to be fixed
On 2/17/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
I'm very sorry for my silliness. I do see the problem I was having now.
Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX
could be used in a pre-processor statement like LONG_MAX and INT_MAX.
In other words
#if
http://www.python.org/dev/buildbot/
Whoever is first to break the build, buys a round of drinks at PyCon!
That's over 400 people and counting:
http://www.python.org/pycon/2006/pycon-attendees.txt
Remember to run the tests *before* checkin. :-)
n
___
On 2/17/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I don't have a strong opinion. Any one else have an opinion about
removing --with-wctype-functions from configure?
FWIW, I announced this plan in Dec 2004:
http://mail.python.org/pipermail/python-dev/2004-December
On 2/21/06, Tim Peters [EMAIL PROTECTED] wrote:
Since the most fruitful variations (IME) for finding code errors are
using -r and running a debug build too, I'd change the current
run-all-the-time recipes to:
- Stop doing the second without deleting .py[co] run.
- Do one run with a release
On 2/21/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Neal IMO compiler warnings should generate emails from buildbot.
It doesn't generate emails for any other condition. I think it should just
turn the compilation section yellow.
It would be easy to run the
On 2/21/06, Neal Norwitz [EMAIL PROTECTED] wrote:
I agree with this, but don't know a clean way to do 2 builds. I
modified buildbot to:
- Stop doing the second without deleting .py[co] run.
- Do one run with a debug build.
- Use -uall -r for both.
I screwed it up, so now it does
On 2/20/06, Jiwon Seo [EMAIL PROTECTED] wrote:
Regarding this Grammar change; (last October)
from argument: [test '=' ] test [gen_for]
to argument: test [gen_for] | test '=' test ['(' gen_for ')']
- to raise error for bar(a = i for i in range(10)) )
I think we should
On 1/24/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 1/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I ran Fredrik's listmodules script in my current sandbox and got a
deprecation warning for the regex module. According to PEP 4 it is already
obsolete. I saw nothing there about
The following code leaks a reference. Original test case from
Lib/test/test_sys.py in test_original_excepthook.
import sys, StringIO
eh = sys.__excepthook__
try:
raise ValueError(42)
except ValueError, exc:
exc_type, exc_value, exc_tb = sys.exc_info()
eh(exc_type, None, None)
Yup. It's fixed.
n
--
On 3/3/06, Matthew Fleming [EMAIL PROTECTED] wrote:
testCompileLibrary (__main__.CompilerTest) ... compiling
/home/splitscreen/src/python/python/Lib/dircache.py
compiling
/home/splitscreen/src/python/python/Lib/smtplib.py
compiling
1 - 100 of 454 matches
Mail list logo