Python-Dev November 2000

python-dev@python.org

56 participants
128 discussions

Re: [Python-checkins] CVS: python/nondist/peps pep-0204.txt,1.4,1.5

by Thomas Wouters

On Wed, Nov 01, 2000 at 02:37:39PM -0800, Thomas Wouters wrote: > Modified Files: > pep-0204.txt > Log Message: > Update this PEP to current, harsh, reality. It's been rejected :) If at all > possible, the reasoning should be extended to include the real reasons it > was rejected -- this is just guesswork from my side. (This means you, Guido, > or anyone who can channel Guido enough to call himself Guido.) In addition to that, PEP 0 also needs to be updated. Shall I do that myself, now that Barry is apparently away ? While I was at it, I also noticed PEP 0200 still says 'Incomplete', though that might be by design. Yay-another-first-for-me---first-rejected-PEP-ly y'rs, ;) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

20 years, 10 months

Re: [Python-Dev] Python Call Mechanism

by Michael Hudson

Michael Hudson <mwh21(a)cam.ac.uk> writes: > Guido van Rossum <guido(a)python.org> writes: > > Then the following could be made essentially equivalent: > > f(a,b,c=d,e=f) > > dict = {c:d,e:f} > f(a,b,**dict) ... except when you have stuff like f(a,b=c,**kw) Gruntle. Maybe Python function calls are just complicated! (Has anyone looked at bytecodehacks.xapply? - and that doesn't even handle *-ed and **-ed arguments...). Hmm - the interaction of "a=b" style args & *-ed args is a bit counter-intuitive, particularly as the "a=b" args syntatically have to come before the *-ed args: >>> def f(a,b,c,d): ... return a,b,c,d ... >>> f(1,c=3,*(2,4)) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: keyword parameter 'c' redefined in call to f() >>> f(1,b=3,*(2,4)) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: keyword parameter 'b' redefined in call to f() >>> f(1,d=4,*(2,3)) (1, 2, 3, 4) I humbly submit that This Is Wrong. I haven't seen anybody complain about it, which suggests to me that noone is using this combination, and I propose either: 1) banning it 2) demanding that the *-ed arg precede the "a=b" args Of course, if noone is using this "feature", then maybe this dusty little corner of the language should be left undisturbed. And I haven't even thought about default arguments yet... about-to-make-an-opcode-called-BODGE_KEYWORD_ARGUMENTS-ly y'rs M. -- nonono, while we're making wild conjectures about the behavior of completely irrelevant tasks, we must not also make serious mistakes, or the data might suddenly become statistically valid. -- Erik Naggum, comp.lang.lisp

20 years, 10 months

PEP-0217

by Moshe Zadka

I need some help: 1) BDFL pronouncement 2) someone to see about the Jython issue. Thank you for your co-operation. -- Moshe Zadka <moshez(a)math.huji.ac.il> -- 95855124 http://advogato.org/person/moshez

20 years, 10 months

Tk news you'll want to read

by Cameron Laird

<URL:http://deja.com/=dnc/getdoc.xp?AN=688816476> Note the clear intention to co-operate with Perl and Python, the ambition to be considerably more portable and superior in performance to GTK+, and so on. I encourage you to e-mail this on to others it might interest. A lot of the Perl people don't receive anything from me because my ISP is ORBS-blacklisted (don't ask).

20 years, 10 months

Re: [Python-Dev] Python Call Mechanism

by Michael Hudson

Guido van Rossum <guido(a)python.org> writes: > > How about dumping the CALL_FUNCTION* opcodes, and replacing them with > > two non-argumented opcodes, called for the sake of argument NCALL_FUNC > > and NCALL_FUNC_KW. > > > > NCALL_FUNC would pop a function object and a tuple off the stack and > > apply the function to the tuple. > > > > NCALL_FUNC_KW would do the same, then pop a dictionary and then do > > the moral equivalent of f(*args,**kw). > > No, this is a bad idea. Long, long ago, all calls requird building a > tuple for the arguments first. This tuple creation turned out to be a > major bottleneck. That's why the current call opcode exists. Yes, I realize this now. I made my suggestion having not actually looked at the code or thought about it very much. I still think there is (or at least might be) value in rewriting the code for the more complex cases, and moving the dictionary creation out of the implementation of CALL_FUNCTION. Then the following could be made essentially equivalent: f(a,b,c=d,e=f) dict = {c:d,e:f} f(a,b,**dict) (modulo evaluation order). (I've made some changes to get BUILD_MAP using it's argument and construct literal dictionaries using it, which I'll whack up onto sf just as soon as I get round to it... ah, it's at https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=102227&gr… ). Cheers, M. -- Those who have deviant punctuation desires should take care of their own perverted needs. -- Erik Naggum, comp.lang.lisp

20 years, 10 months

Move idle PEPs to status deferred

by Jeremy Hylton

Barry, We should start working on any PEPs that are going to be considered for Python 2.1. There are a bunch of old PEPs that have been assigned and then ignored. You have marked many of them as deferred. We should assign new authors for the PEPs we care about and move all the other deferred PEPs somewhere else in the index. The following PEPs have been inactive for at least two months: I 2 pep-0002.txt Procedure for Adding New Modules Raymond S 202 pep-0202.txt List Comprehensions Peters SD 205 pep-0205.txt Weak References Drake I 206 pep-0206.txt 2.0 Batteries Included Zadka SD 207 pep-0207.txt Rich Comparisons Ascher SD 208 pep-0208.txt Reworking the Coercion Model Ascher SD 209 pep-0209.txt Adding Multidimensional Arrays Ascher SD 210 pep-0210.txt Decoupling the Interpreter Loop Ascher SD 211 pep-0211.txt Adding New Linear Algebra Operators Wilson SD 212 pep-0212.txt Loop Counter Iteration Schneider-Kamp SD 213 pep-0213.txt Attribute Access Handlers Prescod SD 215 pep-0215.txt String Interpolation Yee I 216 pep-0216.txt Docstring Format Zadka SD 217 pep-0217.txt Display Hook for Interactive Use Zadka SD 218 pep-0218.txt Adding a Built-In Set Object Type Wilson SD 219 pep-0219.txt Stackless Python McMillan I 220 pep-0220.txt Coroutines, Generators, Continuations McMillan S 224 pep-0224.txt Attribute Docstrings Lemburg I think we should find new authors for PEPs 207 and 208 and work on them for 2.1. I imagine David would be happy to pass the torch on these issues. I assume Gordon will be working on the stackless PEPs, but we should confirm this. For all of the other PEPs, authors who want to have them considered for 2.1 should provide some updates to their PEPs. We should also simplfy the PEP index so that deferred PEPs are collected at the bottom or something like that. Jeremy

20 years, 10 months

Re: [Python-Dev] Python Call Mechanism

by Michael Hudson

Jeremy Hylton <jeremy(a)alum.mit.edu> writes: > >>>>> "MAL" == M -A Lemburg <mal(a)lemburg.com> writes: > > MAL> Jeremy Hylton wrote: > >> > >> Update of /cvsroot/python/python/dist/src/Python In directory > >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python > >> > >> Modified Files: ceval.c ... N.B. The CALL_FUNCTION > >> implementation is getting really hairy; should review it to see > >> if it can be simplified. > > MAL> How about a complete redesign of the whole call mechanism ?! > [chomp] > > I'd be interested in looking at it. Random idea that occurred while answering a post on comp.lang.python: How about dumping the CALL_FUNCTION* opcodes, and replacing them with two non-argumented opcodes, called for the sake of argument NCALL_FUNC and NCALL_FUNC_KW. NCALL_FUNC would pop a function object and a tuple off the stack and apply the function to the tuple. NCALL_FUNC_KW would do the same, then pop a dictionary and then do the moral equivalent of f(*args,**kw). As a preliminary it would be sensible to rework BUILD_MAP so that it built dictionaries off the stack (a bit like BUILD_LIST, and like CALL_FUNCTION now does with keyword arguments...) (and extend the compiler to use this for literal dictionaries). This would add an opcode or so per function call, but would probably make life much simpler. No time for implementation tonight, but could probably knock something up tomorrow (depending how hard it turns out to be). Thoughts? Is that like what you did, Marc? M. -- Those who have deviant punctuation desires should take care of their own perverted needs. -- Erik Naggum, comp.lang.lisp

20 years, 10 months

Bug Changes

by Moshe Zadka

I've noticed the SF-FAQ still has the old "Use Jitterbug" thing about bugs, even though we've moved to SourceForge bug manager. Attached is a patch to correct everything. I haven't checked it in, because I'm not sure I my explanations are clear at all. I'd be happy if someone went over it and saw if it's all right. -- Moshe Zadka <moshez(a)math.huji.ac.il> -- 95855124 http://advogato.org/person/moshez

20 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev November 2000