ber 2018.
I'd say that's all settled. If anyone asks you, "How can you be sure that
settles it?" You can answer, "Some guy said it on a mailing list." And then
you can site the message:
Jeremy Hylton. "[Python-Dev] Official citation for Python." Sep. 17, 2018.
python-de
I don't think there's any need to keep this feature. I hope we have better
ways to profile function and method calls now than we did when this code
was submitted.
Jeremy
On Sat, Nov 26, 2016 at 3:34 AM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Nov 25, 2016, at 1:28 AM,
On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind gregg.l...@gmail.com wrote:
Python-devs,
I'm writing to you for some help in understanding the Python grammar. As an
excuse to deep dive into Python's tokenizer / grammar, I decided (as a
hideous, hideous joke) to want to allow braces where colons
A question came up at work about docstring formatting. It relates to
the description of the summary line in PEP 257.
http://www.python.org/dev/peps/pep-0257/
Multi-line docstrings consist of a summary line just like a
one-line docstring, followed by a blank line, followed by a more
elaborate
I posted in the bug report, but repeating here: I don't remember why
exec in a nested function changed either. It would help if someone
could summarize why we made the change. (I hope I didn't do it 0.2
wink.)
Jeremy
On Tue, Mar 31, 2009 at 11:36 PM, Maciej Fijalkowski fij...@gmail.com wrote:
Eeek, I think it was me. Part of the AST changes involved raising a
SyntaxError when exec was used in a scope that had a free variable,
since the behavior is pretty much undefined. If the compiler decides
a variable is free, then it can't be assigned to in the function body.
The compiled exec
4631 should be a release blocker. I'll have a bit of time on Monday
and Tuesday to wrap it up.
Jeremy
On Fri, Dec 19, 2008 at 5:28 PM, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to get Python 3.0.1 out before the end of the year. There are
, Dec 15, 2008 at 11:19 AM, Jeremy Hylton jer...@alum.mit.edu wrote:
I have a patch that appears to fix this bug
http://bugs.python.org/file12361/urllib-chunked.diff
but I'm not sure about its interaction with the io module and
RawIOBase. Is there a new IO expert who could take a look
/~guido/)
On Thu, Dec 18, 2008 at 5:22 AM, Jeremy Hylton jer...@alum.mit.edu wrote:
On Wed, Dec 17, 2008 at 1:05 PM, Guido van Rossum gu...@python.org wrote:
The inheritance from io.RawIOBase seems fine.
There is a small problem with the interaction between HTTPResponse and
RawIOBase, but I
I have a patch that appears to fix this bug
http://bugs.python.org/file12361/urllib-chunked.diff
but I'm not sure about its interaction with the io module and
RawIOBase. Is there a new IO expert who could take a look at it for
me?
Jeremy
On Sun, Dec 14, 2008 at 11:06 PM, Jeremy Hylton jer
This bug is pretty serious, because urllib will insert garbage into
the application-visible data for a chunked response. It simply
ignores the fact that it's reading a chunked response and includes the
chunked header data is payload data. The original bug was reported in
September, but no one
On Thu, Dec 4, 2008 at 2:36 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would like to merge mailing lists, now that the design and first
implementation of Python 3000 is complete. In particular, I would
like to merge the python-3000 mailing list back into python-dev,
and the
On Thu, Dec 4, 2008 at 10:12 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Several people have asked about the patch and merge flow. Now that Python
3.0 is out it's a bit more complicated.
Flow diagram
trunk --- release26-maint
\- py3k --- release30-maint
I wanted to ask a policy question on the bug tracker. What are we
doing with bugs filed against Python 2.4?
This bug http://bugs.python.org/issue1208304 reports a fd leak in
Python 2.4, which doesn't exist in the head. Since Python 2.4 is in
security-fix only mode, is it fair to close this with
On Mon, Nov 24, 2008 at 12:54 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Mon, Nov 24, 2008 at 08:58, Jeremy Hylton [EMAIL PROTECTED] wrote:
I wanted to ask a policy question on the bug tracker. What are we
doing with bugs filed against Python 2.4?
This bug http://bugs.python.org
Does anyone have a clue about why this test fails only on this
platform? The test is question is verifying that URLError gets
raised. From the traceback, it appears that there is an uncaught
exception (URLError) but it fails in an assertRaises() check for
URLError. That doesn't make much sense
, but I had not thought out the transition yet (and Jeremy
Hylton will be running into this as he has volunteered to handle
this).
What do people think we should do?
I am migrating all the stdlib code to use urllib2 APIs when possible.
It seems straightforward enough to keep the old urllib
On Thu, May 8, 2008 at 8:00 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
On Wed, May 7, 2008 at 11:43 AM, Thomas Lee [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
As Thomas mentions in a later message, making it possible to annotate
nodes would permit
On Wed, May 7, 2008 at 11:43 AM, Thomas Lee [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
As Thomas mentions in a later message, making it possible to annotate
nodes would permit Functions to be annotated as being a generator at the AST
stage (currently it is left to the bytecode compiler's
I'm not sure I understand the problem exactly. If we have one pass
converting the concrete syntax to the AST, we can mark functions as
generators as part of that pass. In a later pass, you can remove the
unreachable code.
Jeremy
On Sat, May 3, 2008 at 12:51 AM, Thomas Lee [EMAIL PROTECTED]
On 10/1/07, Justin Tulloss [EMAIL PROTECTED] wrote:
Hello,
I've been doing some tests on removing the GIL, and it's becoming clear that
some basic changes to the garbage collector may be needed in order for this
to happen efficiently. Reference counting as it stands today is not very
On 4/10/07, Facundo Batista [EMAIL PROTECTED] wrote:
Facundo Batista wrote:
Martin v. Löwis wrote:
...
think it should treat all 2xx responses as success. Callers can
then still check the response code themselves if they need to.
The same I think. If nobody has a conflic with this
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 05:51 pm, [EMAIL PROTECTED] wrote:
At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote:
I apparently took the same position that you now take back then,
whereas I'm now leaning towards (or going beyond) the position
Tim had back then,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van
Rossum
Sent: Monday, March 05, 2007 2:14 PM
To: Dino Viehland
Cc: python-dev@python.org
Subject: Re: [Python-Dev] locals(), closures, and IronPython...
Jeremy Hylton has been asking questions
On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote:
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people
I'm organizing a trip to Standard in downtown Dallas for dinner
tonight (Sunday night). It's about a 10 minute cab ride to Standard.
We can share cabs and get there without too much trouble. The
restaurant is on the expensive side. I'm thinking we should leave
from the hotal around 6:30pm.
I'm organizing a trip to Standard in downtown Dallas for dinner
tonight (Sunday night). It's about a 10 minute cab ride to Standard.
We can share cabs and get there without too much trouble. The
restaurant is on the expensive side. I'm thinking we should leave
from the hotal around 6:30pm.
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
In #1626545, Anton Tropashko requests that object.h should be
renamed, because it causes conflicts with other software.
I would like to comply with this requests for 2.6, assuming there
shouldn't be many problems with existing software as
I was wondering today how I could convince myself that a sequence of
Py_CLEAR() calls in a tp_clear function was safe. Take for example a
really trivial sequence of code on frame_clear():
Py_CLEAR(f-f_exc_type);
Py_CLEAR(f-f_exc_value);
Py_CLEAR(f-f_exc_traceback);
that the object can't be
collected until the tp_clear() returns. Thanks.
Jeremy
--Guido
On 2/12/07, Jeremy Hylton [EMAIL PROTECTED] wrote:
I was wondering today how I could convince myself that a sequence of
Py_CLEAR() calls in a tp_clear function was safe. Take for example a
really trivial
On 12/19/06, tomer filiba [EMAIL PROTECTED] wrote:
to my understanding of the object model, the code of snippet 1
and snippet 2 should be equivalent. a class is just a special function
that returns its locals automatically and passes them to the metaclass
constructor:
--- snippet 1 ---
On 10/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
You are all wasting your time on this. It won't go in.
+1 from me. Should you mark PEP 315 as rejected?
Jeremy
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
On 9/23/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
compile() get the same guarantee in maintenance branches as the bytecode
format - that is, unless it's absolutely necessary, we'll keep it the same.
Otherwise anyone
On 9/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Friday 29 September 2006 00:30, Jeremy Hylton wrote:
On 9/23/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST
to compile() get the same guarantee in maintenance
I'd like to repeat my invitation to spend a week at Google in
California or New York for a Python sprint. We are hosting sprints at
our offices in Mountain View and New York City the week of Aug. 21,
Monday through Thursday.
We're planning to work broadly on Python 2.6 and Python 3000. If
On 7/14/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Friday 14 July 2006 16:39, Neal Norwitz wrote:
Remember I also tried to push for more features to go in early?
That would have given more time for external testing. Still
features are coming in. Python developers weren't happy about
On 7/14/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Anthony Baxter wrote:
On Friday 14 July 2006 16:39, Neal Norwitz wrote:
Remember I also tried to push for more features to go in early?
That would have given more time for external testing. Still
features are coming in. Python developers
On 7/12/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Boris Borcic wrote:
note that most examples of this type already work, if the target type is
mutable, and implement the right operations:
def counter(num):
num = mutable_int(num)
def inc():
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
On Mon, 10 Jul 2006, Jeremy Hylton wrote:
It's a made-up word. You won't find
We'd like to invite you to attend a Python development sprint at
Google the week of Aug. 21. We will be hosting sprints on two
coasts--at Google HQ in Mountain View CA and at our New York City
office. You can find more information here:
http://wiki.python.org/moin/GoogleSprint
The sprint
I will be looking at the open AST issues today.
Jeremy
On 6/9/06, Neal Norwitz [EMAIL PROTECTED] wrote:
The most important outstanding issue is the xmlplus/xmlcore issue.
It's not going to get fixed unless someone works on it. There's only
a few days left before beta 1. Can someone please
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
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 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 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 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/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/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/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
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 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
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/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/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/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/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/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/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
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 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
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
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
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
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
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
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/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
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
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:
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
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
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
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
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.
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
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
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
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
1 - 100 of 142 matches
Mail list logo
