On 9/15/05, Neal Becker <[EMAIL PROTECTED]> wrote:
> I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is
> highly readable, making the assumption that the compiler will do good
> things to optimize the code despite the style in which it's written. For
> example, I assume con
Is anyone truly attached to nested tuple function parameters; ``def
fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed
okay with just having them removed when Jeremy asked about ditching
them thanks to the pain they caused in the AST branch. I personally
don't see them being overly
[forgot to CC python-dev]
On 9/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4
> branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we
> should list that as an expected failure on that platform?
On 9/18/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Brett]
> > Is anyone truly attached to nested tuple function parameters; ``def
> > fxn((a,b)): print a,b``?
>
> I am.
>
>
>
> > ditching them thanks to the pain they caused in the AST branch.
>
> Changing the grammar for the convenien
On 9/18/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> François Pinard wrote:
>
> > The only practical reason to like this feature is sparing the need of
> > finding an otherwise useless name for the formal argument.
>
> If the argument represents a coherent enough concept
> to be passed in as a tup
On 9/19/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
>
> > While you're at it, maybe we should switch to && and || as well?
> > That's another thing I always mistype when switching between
> > languages...
>
> Please no! 'and' and 'or' is so
On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.
>
> 1) The construct can be error-prone. When an error occurs it can be
> invisible
On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
[SNIP]
> I _like_ the explanation of 'and' and 'or' as they are now. They are
> basically control flow constructs -- and have to be to get
> short-circuiting to work -- and adding a coercion to bool at the end
> seems to add complexity, not red
On 9/20/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
> >I think I'd prefer (if then else ) i.e. no
> >colons. None of the other expression forms (list comprehensions and
> >generator expressions) involving statement keywords use colons.
>
On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Sep 2005, Florian Weimer wrote:
>
> > The real problem is that you can ditch most extension modules. 8-(
> [...]
>
> *Is* that a showstopper for Python 3.0, though?
Who knows. I bet Guido doesn't even know how much breakage he is
go
On 9/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Brett Cannon <[EMAIL PROTECTED]> writes:
>
> > On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> > [SNIP]
> >> I _like_ the explanation of 'and' and 'or' as they are now
On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[SNIP]
> Flames, pleas to reconsider, etc., to /dev/null.
>
> Congratulations gracefully accepted.
>
And gladly given! All proposals should be resolved this cleanly in the end.
> It's still my language! :-)
>
Yes it is, thank goodness!
-
To answer Nick's email here, I didn't respond to that initial email
because it seemed specifically directed at Guido and not me.
On 10/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Anyway, the question is: What do we want to do with ast
On 10/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Kurt]
> > > Unless I'm missing something, we would need to merge HEAD to the AST
> > > branch once more to pick up the changes in MAIN since the last merge,
> > > and then make sure everything in the AST branch is passing the test
> > > sui
On 10/10/05, Christos Georgiou <[EMAIL PROTECTED]> wrote:
> This might be minor-- but I didn't see anyone mentioning it so far. If
> `exec` functionality is to be provided, then I think it still should be a
> keyword for the parser to know; currently bytecode generation is affected if
> `exec` is
On 10/10/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
>
> > Never created for a reason? lumping things together for having the
> > similar usage semantics, but unrelated purposes, might be something to
> > avoid and maybe that's why it hasn't hap
On 10/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> This might be minor-- but I didn't see anyone mentioning it so far.
> >> If `exec` functionality is to be provided, then I think it still
> >> should be a keyword for the parser to know; currently bytecode
> >> generatio
On 10/10/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>
> > But the better answer is we will just find a way. =)
>
> I think the best answer would be just to dump the idea of
> exec-in-local-namespace altogether. I don't think I've
>
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))
>
> generates "NameError: name 'i' is not defined" when run b
On 10/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Martin> If people want to test the installation before the switch
> Martin> happens, this would be the time to do it.
>
> Martin,
>
> Can you let us know again the magic incantation to check out the source from
> the repository?
On 10/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[SNIP]
> Most of you are probably interested in checking out one of these
> folders:
>
> svn+ssh://[EMAIL PROTECTED]/python/trunk
> svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint
> svn+ssh://[EMAIL PROTECTED]/peps
>
Why the ent
I have started a svn section in the dev FAQ
(http://www.python.org/dev/devfaq.html) pertaining to checking out a
project from the repository and other stuff discussed so far. If
something is not clear or people feel a step is missing, let me know.
I will remove the CVS section once Martin has tos
On 10/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett> I have started a svn section in the dev FAQ
> Brett> (http://www.python.org/dev/devfaq.html) pertaining to checking
> Brett> out a project from the repository and other stuff discussed so
> Brett> far. If somethin
Well, I am at it again, but this time Guido is a co-conspirator. We
wrote a PEP that introduces BaseException and moves KeyboardInterrupt
and SystemExit. Even if you followed the discussion for PEP 348 you
should read the PEP since I am sure there will be something that
someone doesn't like, such
On 10/27/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Thursday 27 October 2005 23:03, Brett Cannon wrote:
> > I guess, but I just don't like wikis personally so I have no
> > inclination to make the conversion. If someone wants to make the
> > convers
On 10/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Brett Cannon wrote:
> > > Anyway, as soon as the cron job posts the PEP to the web site (already
> > > checked into the new svn repos
On 10/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > Why would a
> > > release allow catching something that cannot be raised? I must be
> > > missing something here.
> >
> > So conforming code can catch exceptions raised by not-yet conforming
> code.
>
> That makes sense.
>
> What was
On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > On 10/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Nick got the python-checkins email and then read the PEP from the
> > repository (or at least that is what I assume sinc
On 10/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Trying to cut this short... We have too many threads for this topic. :-( ]
>
> On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [on making args b/w compatible]
> > I agree changing the behaviour is highly unlikely to cause any seriou
On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Interesting point, but I think that chaining should have more concrete
> > support ala PEP 344 or some other mechanism. I think most people
> > agree that exception chaining is impo
On 11/7/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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.
This might make a good spr
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Maybe it makes more sense to deprecate .pyo altogether and instead
> have a post-load optimizer optimize .pyc files according to the
> current optimization settings?
>
But I thought part of the point of .pyo files was that they left out
doc
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/9/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Plus I wouldn't be
> > surprised if we started to move away from bytecode optimization and
> > instead tried to do more AST transformations whi
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > However, this would be a major pain for the standard library and other
> > > shared code -- there it's really nice to have a cache for each of the
> > > optimization levels since usually regular users can't write the
> > > .py[
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I like Phillip's suggestion -- no new opcode, just a conditional jump
> > > that can be easily optimized out.
> >
> > Huh? But Phillip is suggesting a new opcode that is essentially the
> > same as my proposal but naming it differently
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let me know.
-Brett
___
Python-Dev maili
On 11/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > I just finished fleshing out the dev FAQ
> > (http://www.python.org/dev/devfaq.html) with questions covering what
> > someone might need to know for regular usage. If anyone thinks I
> >
On 11/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > I just finished fleshing out the dev FAQ
> > (http://www.python.org/dev/devfaq.html) with questions covering what
> > someone might need to know for regular usage. If anyone thinks I
> >
On 11/13/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Implemented as you suggested and tested. I'll submit the patch to the
> > tracker on sourceforge shortly. Are you guys still after contextual
> > diffs as per the developer pages, or is an svn diff the preferred way to
> >
On 11/15/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> 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
On 11/15/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 11/15/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for the message. I was going to suggest the same thing. I
> > think it's primarily a question of how to add an arena layer. The AST
> > phase has a mixture of malloc/free a
On 11/16/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
>
> > Even if it meant we had just one function call - one, safe function call
> > that deallocated all the memory allocated within a function - that we
> > had to put before each and every return, that's better than what we
On 11/16/05, Thomas Lee <[EMAIL PROTECTED]> wrote:
> Just messing around with some ideas. I was trying to avoid the ugly
> macros (note my earlier whinge about a learning curve) but they're the
> cleanest way I could think of to get around the problem without
> resorting to a mass deallocation righ
Just for everyone's FYI while we are talking about profilers, Floris
Bruynooghe (who I am cc'ing on this so he can contribute to the
conversation), for Google's Summer of Code, wrote a replacement for
'profile' that uses Hotshot directly. Thanks to his direct use of
Hotshot and rewrite of pstats
On 11/21/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Mon, Nov 21, 2005 at 08:12:53AM +0100, "Martin v. L?wis" wrote:
> > If bugs are in the heavily-used parts of the library, like regular
> > expressions, it doesn't matter much if the original author goes
> > away for some period
On 11/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Jeremy> Here's another attempt to disentagle some issues:
> Jeremy> - Should lsprof be added to the standard distribution?
> Jeremy> - Should hotshot be removed from the standard distribution?
>
> Adding another log to the fi
On 11/21/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> Here's another attempt to disentagle some issues:
> - Should lsprof be added to the standard distribution?
> - Should hotshot be removed from the standard distribution?
>
> These two aren't at all related, unless you believe that two is the
>
On 11/21/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Mon, Nov 21, 2005 at 10:29:55PM +0100, "Martin v. L?wis" wrote:
> > > I see no incremental way of fixing some of the downsides of hotshot,
> > > like its huge log file size and loading time.
> >
> > I haven't looked into the det
On 11/21/05, Simon Burton <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Nov 2005 13:36:36 +1300
> Tony Meyer <[EMAIL PROTECTED]> wrote:
>
> >
> > --
> > AST for Python
> > --
> >
> > As of October 21st, Python's compiler now uses a real Abstract Syntax
> > Tree (AST)! This should
On 11/22/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I wrote (in the summary):
> > While there is no interface to the AST yet, one is
> > intended for the not-so-distant future.
>
> Simon Burton wrote:
> > who is doing this ? I am mad keen to get this happenin
On 11/22/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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
&g
On 11/23/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>
> > There are two problems to this topic; how to
> > get the AST structs into Python objects and how to allow Python code
> > to modify the AST before bytecode emission
>
> I'm astou
On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > Then I don't understand why there was discussion of alloca() earlier
> > > on -- surely the lifetime of a node should not be limited by the stack
> > > frame that allocated it?
>
> [Jeremy]
> > Actually this is a pretty good l
On 11/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Here's a somewhat radical idea:
>
> Why not write the parser and bytecode compiler in Python?
>
> A .pyc could be bootstrapped from it and frozen into
> the executable.
>
Is there a specific reason you are leaving out the AST, Greg, or do
you co
On 11/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > [...] My mental model
> > of parsing & compiling in the presence of a parse tree
> > is like this:
> >
> >[source] -> scanner -> [tokens]
> > -> parser -> [AST] -> code_generat
On 11/29/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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 ca
On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I created
>
> http://svn.python.org/projects/python/branches/ast-objects/
>
> You can convert your repository to that branch with
>
> svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects
>
If you would rather do a separate c
On 12/5/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 12/5/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
[SNIP]
> I didn't look at the changes much, but from what I saw I think it may
> be better to move the arenas off the branch and onto the head now. It
> appears to be much easier to get right
On 12/10/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
> > Let's say something like "string-based exceptions are strongly
> > discouraged, and in fact may be deprecated or disappear in a future
> > Python version. Use class-based exceptions."
>
> If I h
On 12/11/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
[SNIP]
> > - I check in an existing elementtree release in a separate location in
> > the svn.python.org source tree. e.g.
> >
> > svn.python.org/kits/elementtree-1.2.6-20050316
> >
> > this will make
On 12/12/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
>
> > 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
>
On 12/12/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-12-12 at 20:43 +0100, Fredrik Lundh wrote:
> > Jeremy Hylton wrote:
> >
> > > The C files are checked into subversion. Perhaps there is some
> > > problem with the timestamps that causes the Makefile to try to rebuild
> > > them
On 12/13/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I wrote:
>
> > 1. add an Include/pyexpat.h header file which contains a structure
> > similar to the following:
>
> > 2. during pyexpat initialization, initialize all members of this structure,
> > and
> > make it available as a PyCObject:
>
On 12/13/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Armin Rigo <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote:
> >> $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
> >> -$(PYTHON) $(ASDLGEN) $(AST_ASDL)
>
> > The same just-ignore-it behav
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> /F writes:
> > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the
> > modules are 99% compatible, but there's always someone that relies
> > on that last % (which is a result of ET being written in Python).
>
> Yes!
>
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Guido writes:
> > Actually this (function, method and ivar names) is such a contentious
> > issue that I think the style guide should explicitly allow all
> > two/three styles and recommend to be consistent within a class, module
> > or pa
On 12/14/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote:
> >On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > > We already know that Python is particularly susceptable to "too slow"
> > &g
On 12/15/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> SF patch # 1382163 is a fairly simple patch to expose the Subversion
> revision number to Python, both in the Py_GetBuildInfo() text, and in a
> new Py_GetBuildNumber() C API function, and via a new sys.build_number
> attribute. This number is
On 12/16/05, Tim Peters <[EMAIL PROTECTED]> wrote:
[SNIP]
> python-dev'ers: I failed to find anything in the trunk's NEWS file
> about this (neither about `hashlib`, nor about any of the specific new
> hash functions). It's not like it isn't newsworthy ;-)
I have fixed the faux pas and added an
On 12/21/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
[SNIP]
> Maybe it's just because I came in late on this thread, but what exactly
> is broken about the current LaTeX documentation?
>
Well, the toolchain is not necessarily installed on everyone's
computer. Plus not everyone knows LaTeX compara
On 12/23/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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
On 12/24/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> FWIW, test_builtin and test_pep263 both passed on WinXP in rev 39757.
> That's the last revision before the AST branch was merged.
>
> I can't build rev 39758 on WinXP (VC complains that pythoncore.vcproj
> can't be loaded -- looks like it got ch
On 12/24/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> FWIW, test_builtin and test_pep263 both passed on WinXP in rev 39757.
> >> That's the last revision before the AST branch was merged.
> >>
> >> I can't build rev 39758 on WinXP (VC complains that pythoncore.vcproj
> >> can't be loaded
On 12/25/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Reinhold,
>
> On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
> > > that nobody fully understands the convoluted code paths of abstract.c
> > > any more :-(
> >
> > Time for a rewrite?
>
Maybe. Also realize we will have
On 12/25/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> Take a look at:
>
> http://buildbot.zope.org/
>
> That runs code from:
>
> http://buildbot.sourceforge.net/
>
> Someone sets up a "buildbot master" (that's what the Zope URL points
> at), and then any number of people can volunteer to set
On 12/25/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> Take a look at:
> >>
> >> http://buildbot.zope.org/
> >>
> >> That runs code from:
> >>
> >> http://buildbot.sourceforge.net/
> >>
> >> Someone sets up a "buildbot master" (that's what the Zope URL points
> >> at), and then any
On 12/26/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> as seen on the doc-sig:
>
> > > > javadoc's
> > > >
> > > > [EMAIL PROTECTED] os.popen}
> > > >
> > > > is even shorter.
> > > >
> > > > hmm. maybe a combination of rest/html/whatever and pythondoc markup
> > > > would be the ultimate too
On 12/27/05, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> It sounds to me like what is being proposed amounts to essentially
> "promote sys.exit to a builtin". So why not do that?
>
> I see two options. Either:
>
> (a) Simply let __builtins__.exit = sys.exit. Then we get:
>
> >>> exit
>
On 12/28/05, Aahz <[EMAIL PROTECTED]> wrote:
> Here's yet a different take on this: why not simply change the startup
> message? Whether we choose "quit" or "exit", someone will get it wrong
> unless there's an alias. Changing the message is free. Currently we
> have
>
> Type "help", "copyri
On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Please let me know what you think.
>
> Regards,
> Martin
>
> PEP: XXX
> Title: Using ssize_t as the index type
[SNIP]
+1 from me. As everyone else is saying, this has to happen at some
point and 2.5 is as good as any.
-Brett
___
On 12/29/05, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In a fair number of cases, Python doesn't follow its own recommended
> naming conventions. Changing these things would break backward
> compatibility, so they are out of the question for Python 2.*, but
> it would be nice to keep these in mind
On 1/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Martin]
> >> But now: who is going to write it? "Guido should write it" clearly won't
> >> work. And no, I'm explicitly not volunteering either.
>
> [Thomas]
> > Well, the PEP will be mostly boilerplate anyway (unless there's a sudden
> > influx o
It is time once again in my educational career to come to python-dev
for help for major project ideas. This time, though, it is for my
Ph.D. dissertation (and thus can have larger scope than my masters
thesis) but there are funding restrictions (and thus only certain
areas I have possible funding
On 1/12/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Brett,
>
> How about building a system that compiles a Python program (possibly
> annotated) to an AJAX program? That is, it analyzes the program to
> determine what's appropriate and possible for client-side and
> server-side, figures out the
On 1/12/06, Dennis Allison <[EMAIL PROTECTED]> wrote:
>
> Brett,
>
> Where are you doing your Phd and who will be your likely supervisor?
> It does make a difference.
>
University of British Columbia under Eric Wohlstadter in the Software
Practices Lab.
> Your dissertation idea list seems to me t
On 1/14/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> If by any chance PyPy continues to be funded beyond 2006, we would
> definitely welcome you around :-) (If our funding model doesn't change,
> it might be difficult for us to give you money oversea, though... just
> asking, just in
On 1/15/06, Dennis Allison <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jan 2006, Brett Cannon wrote:
>
> > It is time once again in my educational career to come to python-dev
> > for help for major project ideas. This time, though, it is for my
> > Ph.D. dissertation (
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
I think you mean ``int('101' 2)``. =)
> gives 5? I'm not sure why str has never allowed this obvious us
On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> > str(5,2) to give '101', just the converse of the way int('101',1)
> [I'm sure you meant int('101', 2) here]
> >
On 1/16/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
>
> > On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
> > [...]
> >> That suggests that it would be better to simply add an int method:
> >>
> >> x.convert_to_base(7)
On 1/17/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
> > Building the readline on OS X 10.4 fails, is this known, or am I doing
> > something wrong?
>
> There are definitely serious issues with readline on OS X 10.4. I've
> hit them too but
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> > There shouldn't be a %B for the same reason there isn't an %O or %D
> > -- they're all just digits, so there's not a need for an uppercase
> > variant.
>
> Right.
>
> > The difference b
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > I'd propose bin() to stay in line with the short abbreviated names.
> >
> > There has been some previous discussion about removing hex()/oct()
> from
> > builtins for Python 3.0, IIRC. I sure don't think bin() belongs
> there.
>
> Perh
On 1/18/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote:
>
> > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>>> I'd propose bin() to stay in line with the short abbreviated names.
> &g
> [Fredrik, later]
> > if we move over to a web-oriented (wiki-ish) maintenance model, we
> > probably have to accept that "X" will, sometimes, be a future release.
>
> This makes me worry that you're thinking of abandoning having separate
> docs per version. That would be a shame; I think the docs
On 2/1/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a student who may be interested in adding syntactic support for
> sets to Python, so that:
>
> x = {1, 2, 3, 4, 5}
>
> and:
>
> y = {z for z in x if (z % 2)}
>
> would be legal. There are of course issues (what's the syntax
On 2/3/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
> > Alex Martelli <[EMAIL PROTECTED]> wrote:
> > > I understand your worry re the syntax issue. So what about Michael
> > > Hudson's "placeholder class" idea, where X[1] returns the callable
> > > that will do x[1] when cal
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and ti
On 2/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > After so many attempts to come up with an alternative for lambda,
> > > perhaps we
On 2/6/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Brett Cannon wrote:
> > > But I know that everyone and their email client is against me on this
> > > one, so I am not
3201 - 3300 of 3314 matches
Mail list logo
