Re: [Python-Dev] nonlocals() function?
Carl M. Johnson wrote: * It would make "method" in dir(obj) marginally faster Wouldn't hasattr(obj, "method") be a better way to do that? * Even though the order isn’t important for code, it’s convenient at the interactive prompt to see the methods of an item in alphabetical order for quick scanning. Since I suspect this is most people's main use for dir(), I think it's a good enough reason for leaving things as they are. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] nonlocals() function?
Steve Bonner gmail.com> writes: > > What do we think of adding a built-in nonlocals() function that would > be similar to globals() and locals()? Like those functions, it would > return a dictionary of variable names and their values. Since we now > have the nonlocal statement, it would be consistent to keep the > three scopes local/nonlocal/global with parallel capabilities. These scopes don't have parallel capabilities: >>> def f(): ... x = 5 ... locals()['x'] = 6 ... return x ... >>> f() 5 > And it > might sometimes be useful for code inside a nested function to see > what variables are available at the enclosing level. "It might sometimes be useful" translates in my head to "I've never seen an actual use case for this". -1 on an useless complication of the interpreter. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] nonlocals() function?
Greg Ewing wrote: >> * Even though the order isn’t important for code, it’s convenient at >> the interactive prompt to see the methods of an item in alphabetical >> order for quick scanning. > > Since I suspect this is most people's main use for > dir(), I think it's a good enough reason for leaving > things as they are. Yes, I was going to point out that I would personally be *very* annoyed if someone removed the automatic sorting from the output of dir() :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python compiler
for a college project, I proposed to create a compiler for python. I've read something about it and maybe I saw that made a bad choice. I hear everyone's opinion respond. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On 05/04/2010 15:54, will...@ufpa.br wrote: for a college project, I proposed to create a compiler for python. I've read something about it and maybe I saw that made a bad choice. I hear everyone's opinion respond. Python itself is a highly dynamic language and not amenable to direct compilation. Instead modern just-in-time compiler technology is seen as the way to improve Python performance. Projects that are doing this are PyPy and Unladen Swallow. A static subset of Python can be statically compiled, projects that do that include RPython (part of PyPy) and ShedSkin. These are not really Python though, just Python like languages that happen to be valid subsets of Python. All the best, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
Hello. We'are sorry but we cannot help you. This mailing list is to work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/lists/ for other lists/news groups/fora. On Mon, Apr 05, 2010 at 02:54:51PM +, will...@ufpa.br wrote: Thank you for understanding. > for a college project, I proposed to create a compiler for python. I've > read something about it and maybe I saw that made a bad choice. I hear > everyone's opinion respond. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 11:11 AM, Michael Foord wrote: > Python itself is a highly dynamic language and not amenable to direct > compilation. Instead modern just-in-time compiler technology is seen as the > way to improve Python performance. Projects that are doing this are PyPy and > Unladen Swallow. A static subset of Python can be statically compiled, > projects that do that include RPython (part of PyPy) and ShedSkin. These are > not really Python though, just Python like languages that happen to be valid > subsets of Python. I agree. However, if you're doing it as a fun final project and don't care about performance and don't mind generating slow code, then go for it. You'd also want to cut a bunch of corners like exec and eval. Reid ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
>> for a college project, I proposed to create a compiler for python. I've >> read something about it and maybe I saw that made a bad choice. I hear >> everyone's opinion respond. >> I don't think everyone thinks this is a bad idea -- for instance, those of us working on Cython [1], which is itself a descendant of Pyrex [2]. :) > Python itself is a highly dynamic language and not amenable to direct > compilation. Instead modern just-in-time compiler technology is seen as the > way to improve Python performance. Projects that are doing this are PyPy and > Unladen Swallow. A static subset of Python can be statically compiled, > projects that do that include RPython (part of PyPy) and ShedSkin. These are > not really Python though, just Python like languages that happen to be valid > subsets of Python. > It's true that JIT compilation really opens up a whole world of possibilities that Cython currently can't touch. On the other hand, for some kinds of Python code -- especially, for example, things related to scientific computing or mathematics -- Cython's a quick road to massive speedups, because a little bit of static typing can go a *long* way. It's true that Cython doesn't yet support the full Python syntax, but this is considered a bug -- we're working hard on being able to compile all of Python soon. -cc [1] http://www.cython.org/ [2] http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 9:31 AM, Craig Citro wrote: >>> for a college project, I proposed to create a compiler for python. I've >>> read something about it and maybe I saw that made a bad choice. I hear >>> everyone's opinion respond. >>> > > I don't think everyone thinks this is a bad idea -- for instance, > those of us working on Cython [1], which is itself a descendant of > Pyrex [2]. :) > I hate to remind you but Cython is *not* python. It does not even plan to support all of the parts which are considered python semantics (like tracebacks and frames). Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
> I hate to remind you but Cython is *not* python. It does not even plan > to support all of the parts which are considered python semantics > (like tracebacks and frames). > It's true -- we basically compile to C + the Python/C API, depending on CPython being around for runtime support, and I don't see that changing anytime soon. (I don't think I tried to claim that we were a full Python implementation in my original email ...) I'm curious about the bit you mention, though -- is constructing a call frame for every Python call really part of the semantics, and not just a CPython implementation detail? (I've never played with Jython or IronPython to know if they do this.) We actually *do* construct all the call frames when doing profiling, so we could turn this on if we needed to for a "strict" mode, but usually the additional runtime speedup is more desirable. Independent of this, the OP was asking about working on something as part of a school-related project. I think that if you're looking to see how a Python to C compiler works, you could get quite a bit from checking out Cython and/or Pyrex, even if your real goal was to create a Python implementation independent of CPython. -cc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 8:49 AM, Maciej Fijalkowski wrote: >> I hate to remind you but Cython is *not* python. It does not even plan >> to support all of the parts which are considered python semantics >> (like tracebacks and frames). On Mon, Apr 5, 2010 at 10:32 AM, Craig Citro wrote: > It's true -- we basically compile to C + the Python/C API, depending > on CPython being around for runtime support, and I don't see that > changing anytime soon. (I don't think I tried to claim that we were a > full Python implementation in my original email ...) There has been some contentious debate about this in the past, where a Cython developer(s?) insisted Cython be listed among the "Python implementations" somewhere, on a par with IronPython, Jython and PyPy. This does not seem the right place to list Cython to me. (Much though I admire Cython's accomplishments!) Insofar as the OP asked about "a compiler for Python" and you pointed to Cython as an example, your post could easily be misunderstood as an attempt to reopen that debate. > I'm curious about > the bit you mention, though -- is constructing a call frame for every > Python call really part of the semantics, and not just a CPython > implementation detail? (I've never played with Jython or IronPython to > know if they do this.) We actually *do* construct all the call frames > when doing profiling, so we could turn this on if we needed to for a > "strict" mode, but usually the additional runtime speedup is more > desirable. Beign able to access call frames via tracebacks is certainly part of the standard semantics, and a proper Python implementation should go through great lengths to get this interface right (as IronPython, Jython and PyPy indeed do). > Independent of this, the OP was asking about working on something as > part of a school-related project. I think that if you're looking to > see how a Python to C compiler works, you could get quite a bit from > checking out Cython and/or Pyrex, even if your real goal was to create > a Python implementation independent of CPython. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] nonlocals() function?
> globals() and locals() return dicts mapping names to objects. Damn, I totally pulled a *?!* on that one. I should have pulled out my Python reference. I was thinking of dir() and thought that these functions were similar. Apologies for that. However, I still do believe that as a general practice (not necessarily a Python one), return types should be the most specific type which will hold the data. > I'm not sure why you think that the globals() and locals() > You say > they should be properties and attributes, but properties of what? They would be properties of the implicit "main" [function] object. Sorry again for not checking before opening my "mouth". marcos ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
> There has been some contentious debate about this in the past, where a > Cython developer(s?) insisted Cython be listed among the "Python > implementations" somewhere, on a par with IronPython, Jython and PyPy. > This does not seem the right place to list Cython to me. (Much though > I admire Cython's accomplishments!) > > Insofar as the OP asked about "a compiler for Python" and you pointed > to Cython as an example, your post could easily be misunderstood as an > attempt to reopen that debate. > Ahh. Well, I can't speak for the rest of the Cython folks, but let me say: I agree, Cython can't stand on its own without CPython, and there are a ton of other things I'm personally interested in doing long before we try to change that. Sorry if I was accidentally fanning any dying embers. :) > Beign able to access call frames via tracebacks is certainly part of > the standard semantics, and a proper Python implementation should go > through great lengths to get this interface right (as IronPython, > Jython and PyPy indeed do). > Is the requirement just the construction of full tracebacks in the event of an exception? Because Cython does that right now. In the event of an exception, the Python call frames are constructed as the C call stack is unwound. I thought Maciej was suggesting that having full Python frames for any Python call was part of the semantics, which is what we only do in the case of a profiling run. I'm really not trying to belabor the point -- but if there's something Cython should be doing and isn't, it's always good to hear about it. (Feel free to point me to an appropriate section of the docs ...) -cc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On 4/5/2010 10:54 AM, will...@ufpa.br wrote: for a college project, I proposed to create a compiler for python. I've read something about it and maybe I saw that made a bad choice. I hear everyone's opinion respond. If you want to do something useful, pick an existing project (several have already been named) that intrigues you and work on filling in one of the holes. I can imagine that this might be as educational as, for instance, compiling a toy subset of Python. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 1:47 PM, Craig Citro wrote: >> There has been some contentious debate about this in the past, where a >> Cython developer(s?) insisted Cython be listed among the "Python >> implementations" somewhere, on a par with IronPython, Jython and PyPy. >> This does not seem the right place to list Cython to me. (Much though >> I admire Cython's accomplishments!) >> >> Insofar as the OP asked about "a compiler for Python" and you pointed >> to Cython as an example, your post could easily be misunderstood as an >> attempt to reopen that debate. >> > > Ahh. Well, I can't speak for the rest of the Cython folks, but let me > say: I agree, Cython can't stand on its own without CPython, and there > are a ton of other things I'm personally interested in doing long > before we try to change that. Sorry if I was accidentally fanning any > dying embers. :) > >> Beign able to access call frames via tracebacks is certainly part of >> the standard semantics, and a proper Python implementation should go >> through great lengths to get this interface right (as IronPython, >> Jython and PyPy indeed do). >> > > Is the requirement just the construction of full tracebacks in the > event of an exception? Because Cython does that right now. In the > event of an exception, the Python call frames are constructed as the C > call stack is unwound. I thought Maciej was suggesting that having > full Python frames for any Python call was part of the semantics, > which is what we only do in the case of a profiling run. I'm really > not trying to belabor the point -- but if there's something Cython > should be doing and isn't, it's always good to hear about it. (Feel > free to point me to an appropriate section of the docs ...) > However those frames are not completely like Python frames - they don't let you look into locals for example. It's a cool feature though that it exists at all, I did not know that. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On 05/04/2010 21:10, Terry Reedy wrote: On 4/5/2010 10:54 AM, will...@ufpa.br wrote: for a college project, I proposed to create a compiler for python. I've read something about it and maybe I saw that made a bad choice. I hear everyone's opinion respond. If you want to do something useful, pick an existing project (several have already been named) that intrigues you and work on filling in one of the holes. I can imagine that this might be as educational as, for instance, compiling a toy subset of Python. The type inferencing algorithm of ShedSkin might be particularly interesting to study and improve. They also need a Windows maintainer... Michael tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 2:21 PM, Michael Foord wrote: > On 05/04/2010 21:10, Terry Reedy wrote: >> >> On 4/5/2010 10:54 AM, will...@ufpa.br wrote: >>> >>> for a college project, I proposed to create a compiler for python. I've >>> read something about it and maybe I saw that made a bad choice. I hear >>> everyone's opinion respond. >> >> If you want to do something useful, pick an existing project (several have >> already been named) that intrigues you and work on filling in one of the >> holes. I can imagine that this might be as educational as, for instance, >> compiling a toy subset of Python. > > The type inferencing algorithm of ShedSkin might be particularly interesting > to study and improve. They also need a Windows maintainer... > > Michael > Not sure if you went to college Michael, but "Windows maintainer" is not something you can bribe your professors with ;-) Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
> Is the requirement just the construction of full tracebacks in the > event of an exception? Because Cython does that right now. In the > event of an exception, the Python call frames are constructed as the C > call stack is unwound. I thought Maciej was suggesting that having > full Python frames for any Python call was part of the semantics, > which is what we only do in the case of a profiling run. I'm really > not trying to belabor the point -- but if there's something Cython > should be doing and isn't, it's always good to hear about it. (Feel > free to point me to an appropriate section of the docs ...) I guess being able to do inspect.currentframe() is a "SHOULD" requirement for Python implementations. It's clear that it will be difficult to provide, so portable applications SHOULD NOT rely on it working correctly. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 3:03 PM, "Martin v. Löwis" wrote: >> Is the requirement just the construction of full tracebacks in the >> event of an exception? Because Cython does that right now. In the >> event of an exception, the Python call frames are constructed as the C >> call stack is unwound. I thought Maciej was suggesting that having >> full Python frames for any Python call was part of the semantics, >> which is what we only do in the case of a profiling run. I'm really >> not trying to belabor the point -- but if there's something Cython >> should be doing and isn't, it's always good to hear about it. (Feel >> free to point me to an appropriate section of the docs ...) > > I guess being able to do inspect.currentframe() is a "SHOULD" > requirement for Python implementations. It's clear that it will be > difficult to provide, so portable applications SHOULD NOT rely on it > working correctly. > > Regards, > Martin > According to docs sys._getframe() is a impl-specific thing, however sys.exc_info() presenting correct interface of it's 3rd result (a traceback) is not. That's at least how I read those docs. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Scope object (Re: nonlocals() function?)
Antoine Pitrou wrote: Steve Bonner gmail.com> writes: What do we think of adding a built-in nonlocals() function that would be similar to globals() and locals()? These scopes don't have parallel capabilities: Maybe it would be better to deprecate globals() and locals() and replace them with another function called something like scope(). It would return a mapping object that looks up names in the current scope. It could also improve on locals() by being writable. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Scope object (Re: nonlocals() function?)
On 06/04/2010 00:37, Greg Ewing wrote: Antoine Pitrou wrote: Steve Bonner gmail.com> writes: What do we think of adding a built-in nonlocals() function that would be similar to globals() and locals()? These scopes don't have parallel capabilities: Maybe it would be better to deprecate globals() and locals() and replace them with another function called something like scope(). It would return a mapping object that looks up names in the current scope. It could also improve on locals() by being writable. Well, not a bad idea but it belongs on python-ideas and would be covered by the language moratorium. :-) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
will...@ufpa.br wrote: for a college project, I proposed to create a compiler for python. I've read something about it and maybe I saw that made a bad choice. I hear everyone's opinion respond. I don't want to discourage you if you really want to try, but you need to be aware that you'd be taking on a very challenging project -- at least if you intend the compiled code to be substantially faster than interpretation. You should also check out what others have been doing in this area: PyPy, Cython, Unladen Swallow. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Scope object (Re: nonlocals() function?)
Greg Ewing canterbury.ac.nz> writes: > > Maybe it would be better to deprecate globals() and locals() > and replace them with another function called something like > scope(). It is useful to distinguish between globals (i.e., module-level variables) and locals, so replacing them with scope() would not be better IMO. > It would return a mapping object that looks up > names in the current scope. It could also improve on locals() > by being writable. If you can prove that making locals() (or its replacement) writable doesn't complicate the interpreter core too much, then why not. Otherwise -1 :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
Craig Citro wrote: In the event of an exception, the Python call frames are constructed as the C call stack is unwound. Although in Pyrex the frames have just enough info in them to find out the file name and line number -- the rest (f_stack, f_locals, etc.) are filled with dummy values. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Scope object (Re: nonlocals() function?)
On Mon, Apr 5, 2010 at 7:35 PM, Antoine Pitrou wrote: > If you can prove that making locals() (or its replacement) writable doesn't > complicate the interpreter core too much, then why not. Otherwise -1 :-) I think writable locals would significantly complicate the job of people trying to optimize Python. The current situation is that so long as a code object is compiled with certain flags and avoids using exec, then it is impossible to indirectly modify locals in a call frame without resorting to compiled code that mucks with the frame directly. It was very easy for us to check for these conditions, and if they were met, emit faster code. Collin implemented/optimized local variable access for unladen, so he would know more than I. If I remember correctly, the exec statement is going away in py3k, and calling exec() with one argument can modify the local scope. Therefore we'll probably have to do something more sophisticated anyway. :( This would impact PyPy, Jython, and the other implementations, so I would think twice about it. Reid ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python compiler
On Mon, Apr 5, 2010 at 5:44 PM, Greg Ewing wrote: > will...@ufpa.br wrote: >> >> for a college project, I proposed to create a compiler for python. I've >> read something about it and maybe I saw that made a bad choice. I hear >> everyone's opinion respond. > > I don't want to discourage you if you really want to try, > but you need to be aware that you'd be taking on a very > challenging project -- at least if you intend the compiled > code to be substantially faster than interpretation. > > You should also check out what others have been doing in > this area: PyPy, Cython, Unladen Swallow. > Except none of the things mentioned above is actually a "Python compiler". There are however good reasons why not and maybe that's worth checking. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Scope object (Re: nonlocals() function?)
2010/4/6 Antoine Pitrou > Greg Ewing canterbury.ac.nz> writes: > > > > Maybe it would be better to deprecate globals() and locals() > > and replace them with another function called something like > > scope(). > > It is useful to distinguish between globals (i.e., module-level variables) > and > locals, so replacing them with scope() would not be better IMO. > > > It would return a mapping object that looks up > > names in the current scope. It could also improve on locals() > > by being writable. > > If you can prove that making locals() (or its replacement) writable doesn't > complicate the interpreter core too much, then why not. Otherwise -1 :-) > > Regards > > Antoine. > It will certainly. There's MUCH that can be optimized to let CPython squeeze more performance from static analysis (even a gross one) on locals. Example: def f(): a = 1 b = 2 return a + b can be reduced to something similar to: def f(): a = 1 b = 2 return 3 and, more aggressively, like: def f(): return 3 They are just "dummy" examples, but can make it clear how far optimizations can go with static analysis on locals. Python is a language that make it possible to use such analysis at compile time, and I think it is a very good thing. Obviously the last example brings questions regards the language semantic: is it right to suppress "unused" or "not useful" local variables? A "conservative" answer will be clearly NO. But I hope that a future language specification will fix some aspects, putting clear what you can expect from the language itself, and what is closet to the implementation. Cesare ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
