On Mon, 20 Dec 2004 15:03:13 -0500, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
+1
Nothing wrong with an incremental release, but none of these sound
like critical bugs to me.
Jeremy
On Mon, 20 Dec 2004 18:25:39 -0500, Aahz [EMAIL PROTECTED] wrote:
On Mon, Dec 20, 2004, Jeremy Hylton wrote:
On Mon, 20 Dec 2004 15:03:13 -0500, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order
The list archives look like they are mostly full of spam, but it's
also the only list we've used to discuss the ast work. I haven't
really worried whether the sig was active, as long as the list was
around. I don't mind if you want to resurrect it. Is there some way
to delete the spam from the
On Fri, 4 Feb 2005 10:46:52 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]
Log Message:
Add NEWS item about future parser bug.
Give back the time machine!
I already will have by the time you needed it.
Jeremy
___
Python-Dev
Maybe some ambitious PSF activitst could contact Roskind and Steve
Kirsch and see if they know who at Disney to talk to... Or maybe the
Disney guys who were at PyCon last year could help.
Jeremy
On Tue, 8 Feb 2005 15:37:50 -0500, Tim Peters [EMAIL PROTECTED] wrote:
[Matthias Klose]
A Debian
On Fri, 11 Feb 2005 12:55:02 +0100, Matthias Klose [EMAIL PROTECTED] wrote:
Currently md5c.c is included in the python sources. The libmd
implementation has a drop in replacement for md5c.c. The openssl
implementation is a complicated tangle of Makefile expanded template
code that would be
I seem to have a problem with the install on XP SP1. Python itself is
installed, but IDLE won't start. The error says: IDLE's subprocess
didn't make connection. Either IDLE can't start a subprocess or
personal firewall software is blocking the connection. I believe the
problem is the firewall,
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write are atomic by virtue of fread
and fwrite being atomic.
I'm less sure what guarantees, if any, the other methods attempt
On Thu, 17 Mar 2005 16:25:44 -0500, Aahz [EMAIL PROTECTED] wrote:
On Thu, Mar 17, 2005, Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write
On Thu, 17 Mar 2005 23:04:16 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere? I
don't see anything in the library manual, which is where I expected to
find it. It looks like read and write are atomic by virtue
On Thu, 17 Mar 2005 17:13:05 -0500, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy Hylton]
Are the thread semantics for file objecst documented anywhere?
No. At base level, they're inherited from the C stdio implementation.
Since the C standard doesn't even mention threads, that's all
On Thu, 17 Mar 2005 23:57:52 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Remember, you were asking what behaviour is *documented*, not what
behaviour is guaranteed by the implementation (in a specific version
of the implementation).
Martin,
I think you're trying to find more finesse in my
On Fri, 18 Mar 2005 07:57:25 +0100, Martin v. Löwis
[EMAIL PROTECTED] wrote:
Writing down all these properties does little good, IMO. This includes
your proposed property of file reads: anybody reading your statement
will think of course it works this way - why even mention it.
The thingsa
On Mon, 21 Mar 2005 16:08:57 +0100, Thomas Heller [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
PEP 314 implementation (client side):
I'm not sure where I should post this, but shouldn't there be a way to
specify the encoding of the metadata? There are people (not me,
fortunately),
For filter and map, list comprehensions and generator expressions are
the answer.
numbers = [5, 9, 56, 34, 1, 24, 37, 89]
[x for x in numbers if x 30]
[5, 9, 1, 24]
(x for x in numbers if x 30)
generator object at 0x00B1FCD8
list(_)
[5, 9, 1, 24]
Jeremy
On Wed, 23 Mar 2005 10:33:53 -0600
On Apr 8, 2005 9:31 AM, Fred Drake [EMAIL PROTECTED] wrote:
On Thursday 07 April 2005 10:58, Raymond Hettinger wrote:
Eric Price
Eric Price was an intern at CNRI; I think it's safe to remove him from the
list, as I've not seen anything from him in a *long* time.
Eric Price did some of
On 5/24/05, Ka-Ping Yee [EMAIL PROTECTED] wrote:
Would there be any interest in extending the compiler package with tools
for AST transformations and for emitting Python source code from ASTs?
Sure. Eventually, we'll have to figure out how to unify the compiler
package AST and the ast-branch
On 5/26/05, Chad Whitacre [EMAIL PROTECTED] wrote:
Would there be any interest in extending the compiler package with tools
for AST transformations and for emitting Python source code from ASTs?
Heh, so I guess the answer is yes.
BTW, how does the concept of AST transformations relate to
On 5/26/05, Chad Whitacre [EMAIL PROTECTED] wrote:
chad: Hmmm ... I don't follow python-dev closely but hasn't there been
resistance to macros in Python? Are we saying macros may be a good idea
after all?
?!ng: resistance - Yes.
?!ng: good idea - Not really. AST transformations are useful
On 7/7/05, Brett Cannon [EMAIL PROTECTED] wrote:
Floris is working on wrapping Hotshot to replace 'profile' and
replacing pstats so that there will be no more need for 'profile' and
thus take care of the licensing problem. He also hopes to make pstats
faster to use. And if we are really
I'd like to see the builtin id() removed so that I can use it as a
local variable name without clashing with the builtin name. I
certainly use the id() function, but not as often as I have a local
variable I'd like to name id. The sys module seems like a natural
place to put id(), since it is
On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote:
If you _really_ want to call a local variable 'id' you can (but shouldn't).
Disagreed. The built-in namespace is searched last for a reason -- the
design is such that if you don't care
On 10/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/6/05, Neil Schemenauer [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
If we kill the branch for now, then anyone that wants to bring up the idea
again can write a PEP first
I still have some (very) small hope
On 10/6/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 07:34 PM 10/6/2005 -0700, Guido van Rossum wrote:
How does this sound to the non-AST-branch developers who have to
suffer the inevitable post-merge instability? I think it's now or
never -- waiting longer isn't going to make this thing
On 10/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Neal Norwitz 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:
I agree with the bug report that the code should either raise a
SyntaxError
Neil and I have been working on the AST branch for the last week.
We're nearly ready to merge the changes to the head. I imagine we'll
do it this weekend, barring last minute glitches.
There are a few open issues that remain. I'd like to merge the branch
before resolving them. Please let me
I just merged the head back to the AST branch for what I hope is the
last time. I plan to merge the branch to the head on Sunday evening.
I'd appreciate it if folks could hold off on making changes on the
trunk until that merge happens.
If this is a non-trivial inconvenience for anyone, go
On 10/16/05, Jeremy Hylton [EMAIL PROTECTED] wrote:
Real life interfered with the planned merge tonight. I hope you'll
all excuse and wait until tomorrow night.
Jeremy
On 10/16/05, Jeremy Hylton [EMAIL PROTECTED] wrote:
I just merged the head back to the AST branch for what I hope
On 10/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
implemented (did it survive the AST-branch merge?), and already you
are talking about adding more stuff.
On 10/21/05, Neal Norwitz [EMAIL PROTECTED] wrote:
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
On 10/20/05, Neal Norwitz [EMAIL PROTECTED] wrote:
On 10/20/05, Anthony Baxter [EMAIL PROTECTED] wrote:
Could someone involved give a short email laying out what concrete (no
pun intended) advantages this new compiler gives us? Does it just
allow us to do new and interesting manipulations
On 10/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/20/05, Anthony Baxter [EMAIL PROTECTED] wrote:
So it looks like the AST branch has landed. Wooo! Well done to all who
were involved - it seems like it's been a huge amount of work.
Hear, hear. Great news! Thanks to Jeremy, Neil
On 10/21/05, Jim Jewett [EMAIL PROTECTED] wrote:
(In http://mail.python.org/pipermail/python-dev/2005-October/057501.html)
Neil Schemenauer suggested PEP 267 as an example of something that
might be easier with the AST compiler.
As written, PEP 267 does propose a slight semantics change --
Can anyone point an old CVS/Perforce-Luddite at instructions for how
to use the new SVN repository?
Jeremy
On 10/23/05, Michael Hudson [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] writes:
I'd like to start the subversion switchover this coming Wednesday,
with a total commit
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 to come
up with something new for this year's conference
On 11/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
About using distutils to build the extensions, this is because some
extensions require quite a bit of logic to determine the build
commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils
way of building extensions using
On 11/15/05, Niko Matsakis [EMAIL PROTECTED] wrote:
As Neal pointed out, it's tricky to write code for the AST parser
and compiler
without accidentally letting memory leak when the parser or
compiler runs into
a problem and has to bail out on whatever it was doing. Thomas's
patch got
Sure. If they're immutable sharing is fine, but you end up making a
copy anyway if you want to make changes, right?
Jeremy
On 11/30/05, Greg Ewing [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I still think passing copies is better than sharing live
objects between Python and C,
Even
On 12/1/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
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 certainly want the PyObject* branch to become life at some
On 12/5/05, James Y Knight [EMAIL PROTECTED] wrote:
On Dec 5, 2005, at 8:46 AM, Jeremy Hylton wrote:
I can see that problem occurring with an all-or-nothing solution, but
not if you have the freedom to allocate from an arena or from some
other mechanism. If there are multiple ways
On 12/7/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Nick Coghlan wrote:
As Fredrik pointed out a while back, the PyObject approach doesn't
*have* to involve manual decref operations - PyObject's come with a
ready made arena structure, in the form of PyList.
On 12/11/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Overall, sounds like a good plan.
Just say go, and I'll start working on this.
Are you still waiting for someone to say go? I'm not sure what
responsible party should say it; if I'm not the right person, would
the right person please say
On 12/12/05, Scott David Daniels [EMAIL PROTECTED] wrote:
Jim Fulton wrote:
Ian Bicking wrote:
Jim Fulton wrote:
Ian Bicking wrote:
Private attributes should have two leading underscores, no
trailing underscores.
This conflicts with a previous suggestion Generally,
The C files are checked into subversion. Perhaps there is some
problem with the timestamps that causes the Makefile to try to rebuild
them anyway? I have a modern Python and I've been doing a fair amount
of development on these files; as a result, I haven't noticed a
problem.
Jeremy
On
On 12/14/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
we also need to figure out how to import the bundled version; should it be
cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree
(which would then fallback on the Python version if cElementTree isn't
built) ?
If the
Python 2.5 will include sha-256 and sha-512. It will be released
sometime next year.
Jeremy
On 12/16/05, Ronald L. Rivest [EMAIL PROTECTED] wrote:
Hi --
I'm curious as to the status of upgrading cryptographic
hash function support in Python, now that md5 and sha1 are
both clearly broken
Yup. I just went through a similar exercise with urllib2. It wasn't
too hard to plumb through a different HTTPHandler that set the
timeout, but it would be much nicer as a default option. It seems
like a 30 minute project; might fit in an odds and ends sprint.
Jeremy
On 12/22/05, Jim Fulton
On 1/2/06, Neal Norwitz [EMAIL PROTECTED] wrote:
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 intent was to provide binary compatibility, but redirect all newly
linked code to the newer variants. We did this correctly for
PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do
it for the rest of the changed functions. Can you file a bug report?
(Or just fix the ones
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases? str([1, 2], 4) doesn't make any sense.
You might argue
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
I think it shouldn't be changed, because the second positional
argument only works for a small number of the panoply types that can
be passed to str().
Identically the same situation
On 1/19/06, Aahz [EMAIL PROTECTED] wrote:
On Thu, Jan 19, 2006, Jeremy Hylton wrote:
I'm not sure I believe this should be a builtin. I think the
threshold for new builtins ought to be nearly as high as the threshold
for new keywords. Or the proposer ought to make an argument about
On 1/24/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Sorry for the plug.
Google is looking to fill an unprecedented number of student intern
positions this summer, at several US locations (Mountain View, Santa
Monica, Kirkland (Wash.), and New York). If you're interested or know
someone
It looks like we need a Python 2.5 Release Schedule PEP.
Jeremy
On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote:
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:
Hint seems like the standard terminology in the field. I don't think
it makes sense to invent our own terminology without some compelling
reason.
Jeremy
On 2/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[Andrew Koenig]
Might I suggest that at least you consider using
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
I added some const to several API functions that take char* but
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
Jeremy
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I added some const to several API functions that take char* but
typically called by passing string literals. In C++, a string literal
is a const char* so you need to add a const_cast to every call site,
That's
On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
No. It doesn't work. I'm not sure about this one either, but some
searching suggests that you can pass a char
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
If he had _stuck_ to that, we wouldn't be having this
On 2/10/06, Fabiano Sidler [EMAIL PROTECTED] wrote:
Do I see things as they are and compiler.pyassem generates bytecode
straight without involve any C code, i.e. code from the VM or the
compiler? How is this achieved? I took a look at Python/compile.c as
mentioned in compiler.pyassem and I'm
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules wink.
Jeremy
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
[A large head-exploding
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
Ok. I reviewed the original problem and you're right, the problem was
not that it failed outright but that it produced a warning about the
deprecated conversion:
warning: deprecated conversion from string constant
On 2/13/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Monday 13 February 2006 15:40, Guido van Rossum wrote:
Shouldn't docs.python.org be removed? It seems to add mroe confusion
than anything, especially since most links on python.org continue to
point to python.org/doc/.
On 2/14/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's
On 2/14/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
The compiler in question is gcc and the warning can be turned off with
-Wno-write-strings. I think we'd be better off leaving that option
on, though. This warning will help me find places where I'm passing
I am still -1 on the ast-objects branch. It adds a lot of boilerplate
code and its makes complicated what is now simple. I'll see if I can
get a rough cut of the marshal code ready today, so there will be a
complete implementation of my original plan.
I also think we should keep the
As I said in an earlier message, there's no need to have a separate
domain to restrict queries to just the doc/current part of python.org.
Just type
site:python.org/doc/current your query here
If there isn't any other rationale, maybe we can redirects
docs.python.org back to www.python.org?
I don't think this message is on-topic for python-dev. There are lots
of great places to discuss the design of the python web site, but the
list for developers doesn't seem like a good place for it. Do we need
a different list for people to gripe^H^H^H^H^H discuss the web site?
Jeremy
On
It is critical, but I hadn't seen the bug report. Feel free to assign
AST bugs to me and assign them a 5 priority.
Jeremy
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
Actually, it might be easier to assign separate bugs. A number of the
old bugs appear to have been fixed. It's hard to track individual
items within a bug report.
Jeremy
On 2/17/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It is critical, but I hadn't seen the bug report. Feel free to assign
Almann,
The lack of support for rebinding names in enclosing scopes is
certainly a wart. I think option one is a better fit for Python,
because it more closely matches the existing naming semantics. Namely
that assignment in a block creates a new name unless a global
statement indicates
I had to lookup top-post :-).
On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED] wrote:
Jeremy
Hey, only Guido is allowed to top-post. He said so ;-)
The Gmail UI makes it really easy to forget where the q
But to the topic
On 2/21/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
I had to lookup top-post :-).
On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED]
wrote:
Jeremy
Hey, only Guido is allowed to top-post. He said so ;-)
The Gmail UI
On 2/22/06, Greg Ewing [EMAIL PROTECTED] wrote:
Mark Russell wrote:
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures.
Well, anything that facilitates rebinding in outer scopes
is going to encourage the use of closures, so I
On 2/24/06, James Y Knight [EMAIL PROTECTED] wrote:
On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
Thomas Wouters wrote:
On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
As an aside, is there any chance that this could be
changed in 3.0? I.e. have the for-loop create a new
I made a few more minor revisions to the AST on the plane this
afternoon. I'll check them in tomorrow when I get a chance to do a
full test run.
* Remove asdl_seq_APPEND. All uses replaced with set
* Fix set_context() comments and check return value every where.
* Reimplement real arena for
On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly. The next() method
is
differenct because it is a mixed case, sometimes called magically and
sometimes
On 3/3/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores
On 3/6/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 3/6/06, Barry Warsaw [EMAIL PROTECTED] wrote:
Didn't we set up a security swat team some time ago? If not, we
should. Regardless, since I have more free time these days, I'd like
to be on it.
Yep, it's called [EMAIL
On 3/6/06, Alex Martelli [EMAIL PROTECTED] wrote:
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
...
I think that adding parentheses would help, by at least signalling
that the logic is longer than just the next (single) expression.
level = (0 if absolute_import in self.futures
On 3/8/06, Georg Brandl [EMAIL PROTECTED] wrote:
I know, PyCon's just been, but not many bugs were closed and
there really ought to be some issues resolved before 2.4.3 happens.
The number of open bugs is again crawling to 900.
I myself are looking at many bugs and patches over time, but with
On 3/15/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, absolute imports without the future statement will not use the
5th argument, so they won't break, right? That's what MAL also says.
Someone please fix this.
I'd much rather see us change imports to use absolute imports than to
use
On 3/15/06, Georg Brandl [EMAIL PROTECTED] wrote:
Neil Schemenauer wrote:
I think it would be a good idea to follow the Plone project and try
to encourage new developers by offering assistance to get them up
and running. AFAIK, we've done that for the other bug days but it
might help to
On 3/21/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Don't you think developers are capable enough to judge for
themselves ?
They might also want to change their extensions to make use
of the new possibilities, so a list of APIs taking Py_ssize_t
parameters on input would be handy to check
On 3/1/06, Neal Norwitz [EMAIL PROTECTED] wrote:
test_bsddb3
Exception in thread reader 4:
Traceback (most recent call last):
File /home/neal/python/trunk/Lib/threading.py, line 473, in __bootstrap
self.run()
File /home/neal/python/trunk/Lib/threading.py, line 453, in run
There are several test cases in test_trace that are commented out. We
did this when we merged the ast-branch and promised to come back to
them. I'm coming back to them now, but the test aren't documented
well and the feature they test isn't specified well.
The failing tests I've looked at so
On 4/4/06, Alex Martelli [EMAIL PROTECTED] wrote:
import collections
def tally(seq):
d = collections.defaultdict(int)
for item in seq:
d[item] += 1
return dict(d)
Nevertheless, simplicity and generality make it advisable to supply
it as part of the standard library
On 4/2/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/1/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
There are several test cases in test_trace that are commented out. We
did this when we merged the ast-branch and promised to come back to
them. I'm coming back to them now, but the test
On 4/5/06, Benji York [EMAIL PROTECTED] wrote:
Realizing that early releases don't normally perform as well as final
releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had
handy). 2.5a1 got slightly more than 30k, while 2.4.2 gets slightly
more than 35k (1.4 GHz, Pentium M, 1
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here at the moment. If there is a bug, though, it's likely
to be
4On 4/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here
On 4/12/06, Anthony Baxter [EMAIL PROTECTED] wrote:
The code is _nearly_ building fine. there's an issue in _sre.c with
some code that either returns a Py_UNICODE* or an SRE_CHAR* (unsigned
char*) in a void*. The code probably needs a refactoring to deal with
that. There's also
Looks good to me. Why don't you check it in.
Jeremy
On 4/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jeremy The code in compile.c is pretty dodgy. I'd like to think of a
Jeremy better way to represent an array of cmpop_ty objects than
Jeremy casting ints to void* and then
On 4/18/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Anthony Baxter wrote:
On Thursday 06 April 2006 04:10, Benji York wrote:
On a related note: it might be nice to put a pystone run in the
buildbot so it'd be easier to compare pystones across different
releases, different architectures,
On 5/23/06, Andrew Dalke [EMAIL PROTECTED] wrote:
Me [Andrew Dalke] said:
The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq,
i),
which likely doesn't know about my derived __getitem__.
Oops, I didn't know what the code was doing well enough. The
relevant problem is
On 6/6/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
For pkgutil in particular, the change is that instead of writing to
stderr (which can scroll off and get lost), it will write to the
errorlog. In a truly default setup, that still ends up writing to
stderr.
umm. if
On 6/7/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
for users, it's actually quite simple to figure out what's in the _
variable: it's the most recently *printed* result. if you cannot see
it, it's not in there.
Of course, there's a pattern to it. The question is whether it is the
1 - 100 of 142 matches
Mail list logo
