Foundation, https://docs.python.org/reference/index.html. Retrieved 16
September 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:
Jere
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, Vic
On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind 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 are allowed (as
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 d
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 co
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 wrote:
> Because clas
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 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 no
> showstopp
(home page: http://www.python.org/~guido/)
>
>
>
> On Thu, Dec 18, 2008 at 5:22 AM, Jeremy Hylton wrote:
>> On Wed, Dec 17, 2008 at 1:05 PM, Guido van Rossum wrote:
>>> The inheritance from io.RawIOBase seems fine.
>>
>> There is a small problem with the interacti
~guido/)
>
>
>
> On Mon, Dec 15, 2008 at 11:19 AM, Jeremy Hylton 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 t
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
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 not
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 ---> release3
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 python-3
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?
>>
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 a
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 u
sily just move over to
> urllib2). The current solution of keeping around urllib's classes was
> a compromise, 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 s
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:
> > >
> > >
> > > >
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 c
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]> wr
On Fri, May 2, 2008 at 1:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Martin v. Löwis wrote:
> >>> This leaves us with a few options:
> >>>
> >>
> >> 5. Reuse/Abuse Num(object) for arbitrary constants.
> >>AFAICT, this should work out of the box.
> >>
> >>
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
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
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 read
ass to locals.
Jeremy
>
> -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 I
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 softwa
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.
http
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.
http
e. The INCREF guarantees 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(
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);
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/)
> ___
> Pyt
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
> >
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 a
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
you're
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. Pyth
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
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 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,
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
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 wi
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 plea
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
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.
>
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 pro
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 arch
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*
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
> Python/c
It's intended as an internal debugging API. I find it very convenient
for adding with a printf() here and there, which is how it got added
long ago. It should really have a comment mentioning that it leaks
the repr object, and starting with an _ wouldn't be bad either.
Jeremy
On 4/11/06, Neal N
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 c
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 b
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
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
> > t
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 standa
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 far
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/27/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Ok, it's time to rock and roll.
>
>The SVN trunk is FROZEN for 2.5a1 from 00:00 UTC on
>Thursday 30th of March.
>
> I'll post again once it's open. Note that new features can keep going
> in during the alpha cycle, the feature freeze o
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 ch
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
> > migh
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, bu
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
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 c
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&#
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
> someti
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 pyar
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-lo
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 closu
On 2/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > I certainly hope that an initiative like this doesn't get stymied by
> > the lack of a good name for such a keyword. Maybe something like
> > "outer"?
>
> Addi
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:
> > >Jer
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 ea
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 otherwis
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 re
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
>
> T
On 2/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Whereas if there weren't any funky coding style in the
> first place, more potential compiler hackers might be
> encouraged to have a go.
I'm trying to make the code simple. The style of code is different
than other parts of Python, but a compil
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 2/15/0
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?
Je
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 transformati
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
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
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, "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 conversio
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 .
Jeremy
On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > [A large head-explodi
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
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
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 literal
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 s
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
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&#x
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* b
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 consi
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
On 1/31/06, Robert Kim Wireless Internet Advisor <[EMAIL PROTECTED]> wrote:
> u guys are way over my head :)
> bob
>
>
> --
> Robert Kim
> 2611s Highway 101
> suite 102
> San diego CA 92007
> 206 984 0880
>
Stop spamming our list.
Jeremy
___
Python-Dev
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
> some
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
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
what the function should not go in a module.
Jeremy
On 1/19/06, Guido van Rossum <[EMAIL PROTECTE
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
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 that
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
1 - 100 of 174 matches
Mail list logo
