Re: [Python-Dev] removing the new and types modules
Redirecting discussion from python-checkins to python-dev. 'new' has now been deprecated for 3.0, GvR suggested it would be nice to get rid of 'types' as well. Christian Heimes wrote: > Georg Brandl wrote: >> I've just looked, and the types you can't get trivially via builtin or >> type(singleton) are >> >> * module >> * function >> * generator >> * code >> * method >> * builtin-function-or-method >> * frame >> * traceback >> * dictproxy >> * getset- and member-descriptor >> >> Where would one put them? > > Python 3.0 has several more types that aren't exposed through types. For > example the views like dict_keys, dict_values and dict_items are not in > types. Most of those 'hard-to-get-at' types are tied pretty tightly to the interpreter internals, and would fit in with Guido's suggestion of a 'pyvm' module. Such a module would let us clean up the 'sys' namespace a little bit by moving some of the more arcane hackery to another module (like the recursion limit and the threading check interval). The only ones I would suggest putting elsewhere are the module type (exposing it through the imp module instead), and the new dict_keys/_values/_items types (exposing them through the collections module, as others have suggested). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing the new and types modules
Nick Coghlan wrote: > 'new' has now been deprecated for 3.0, GvR suggested it would be nice to > get rid of 'types' as well. I've removed the 'new' module from py3k and also removed a lot of types from the 'types' module in py3k. It only contains types that aren't easily available through builtins. > Most of those 'hard-to-get-at' types are tied pretty tightly to the > interpreter internals, and would fit in with Guido's suggestion of a > 'pyvm' module. Such a module would let us clean up the 'sys' namespace a > little bit by moving some of the more arcane hackery to another module > (like the recursion limit and the threading check interval). Can we leave 'pyvm' until the next alpha is out? We are already near the schedule for mid to end of November. > The only ones I would suggest putting elsewhere are the module type > (exposing it through the imp module instead), and the new > dict_keys/_values/_items types (exposing them through the collections > module, as others have suggested). Several other types are used in the Python core, too. The most remarkable is MethodType (to bind functions to instances) but also FunctionType and CodeType. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Google Highly Open Participation Contest
Titus Brown schrieb: > Dear Python-Dev-ers, > > about half of the tasks for the GHOP contest (described below) are > currently on the stdlib, Python core, or Py3K: > > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:stdlib > > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:core > > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:py3k > > We have room for another twenty or so; if you can come up with testing > tasks, documentation updates/review needs, or anything else that you can > write down in a fairly detailed and specific way, we'd love to have > them. To emphasize, coding something specific is also a possible task, as well as solving one or more specific issues in the tracker -- as long as it's doable in a time of 3 to 5 days. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [poll] New name for __builtins__
I'm sending this mail to Python-dev in the hope to reach more developers. GvR likes to rename the __builtin__ to reduce confusing between __builtin__ and __builtins__. He wanted to start a poll on the new name but apparently he forgot. >From http://bugs.python.org/issue1498 --- In http://bugs.python.org/issue1774369 I mentioned that I wanted to rename __builtins__ to __rootns__. Though right now I think something longer and less cryptic might be better. The reason is to avoid for once and for all the confusion between __builtin__, which is a module, and __builtins__, a feature mainly used by sandboxing to pass the set of builtins to be used via the global namespace. This lay at the heart of the referenced bug. I'm still in favor of this but haven't had the time to investigate how much work it would be. [...] OK, then we need to agree on a new name. I find __root__ too short, __rootns__ too cryptic, and __root_namespace__ too long. :-) What else have we got? --- What name do you prefer? I'm +1 with Raymond on __root__ but I'm still open for better suggestions. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > > >From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > +1 for '__root_namespace__' (explicit) +0.5 for '__root__' Michael Foord > Christian > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes schrieb: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. FWIW, +1 for __root__ too. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. My first thought was that __root__ would be the global name space and __builtin(s)__ would be the default module that gets loaded into the __root__ name space. But I see I have that reversed. Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On 28/11/2007, Georg Brandl <[EMAIL PROTECTED]> wrote: > Christian Heimes schrieb: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > > open for better suggestions. > > FWIW, +1 for __root__ too. What about __global__? If that's not an option, I'm OK with __root__. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2007, at 10:20 AM, Christian Heimes wrote: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The only other thing I can suggest is __python__ built __root__ works fine for me too. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR02gvXEjvBPtnXfVAQJ4CQP+MuBSyL13DwLjFPon4l/lSXEBEa2XZ40U LZMB/KF+VpgV8dNz/f1Bv7FA9pc/cIAU7qKKP8/vdAFQkkIPZhKzAgLlpBiOmK47 muNGYT5GsczfgM90/vzNqi2JQ8hWxpR/DIB+/59u2p/2zrADSdhVARt3tmJfivhI 9OY1e4VZkZY= =VGDm -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Paul Moore schrieb: > On 28/11/2007, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Christian Heimes schrieb: >> > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >> > open for better suggestions. >> >> FWIW, +1 for __root__ too. > > What about __global__? If that's not an option, I'm OK with __root__. "global" is already taken for the global namespace, which is module-local. ;) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The namespace should really be called __global__. I doubt this will fly, because it's too radical, and unfortunately would undermine the "global" keyword, used in 2.x to indicate that a name should be sought in the module namespace. I doubt many people would want to replace "global" with "module". What's it being replaced with in 3.x? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Paul Moore wrote: > What about __global__? If that's not an option, I'm OK with __root__. __global__ was also on my list but I've abolished it. It could create confusing with globals(). Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Hello everybody! I really should introduce myself before stating my opinion. But I'll keep this short and sweet -- I have been "trolling" python-dev for a while just to keep up on its development and have never posted but I thought I'd share my opinion on this thread simply because it's a simple topic :) Before finishing the OP I had thought __python__ would be a good name. So +1 to __python__ for me. +0 to __root__ and __rootns__ and +0.5 to __root_namespace__ (prefer explicitness to short/cryptic names). Chuck -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2007, at 10:20 AM, Christian Heimes wrote: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The only other thing I can suggest is __python__ built __root__ works fine for me too. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR02gvXEjvBPtnXfVAQJ4CQP+MuBSyL13DwLjFPon4l/lSXEBEa2XZ40U LZMB/KF+VpgV8dNz/f1Bv7FA9pc/cIAU7qKKP8/vdAFQkkIPZhKzAgLlpBiOmK47 muNGYT5GsczfgM90/vzNqi2JQ8hWxpR/DIB+/59u2p/2zrADSdhVARt3tmJfivhI 9OY1e4VZkZY= =VGDm -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cmason%40vcentertainme nt.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Steve Holden schrieb: >> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >> open for better suggestions. >> > The namespace should really be called __global__. I doubt this will fly, > because it's too radical, and unfortunately would undermine the "global" > keyword, used in 2.x to indicate that a name should be sought in the > module namespace. There are quite a few other places where "globals" is used with that meaning. > I doubt many people would want to replace "global" with "module". > > What's it being replaced with in 3.x? Nothing yet, it's still there, together with "nonlocal". Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 9:39 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Steve Holden schrieb: > > >> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > >> open for better suggestions. > >> > > The namespace should really be called __global__. I doubt this will fly, > > because it's too radical, and unfortunately would undermine the "global" > > keyword, used in 2.x to indicate that a name should be sought in the > > module namespace. > > There are quite a few other places where "globals" is used with that meaning. > > > I doubt many people would want to replace "global" with "module". > > > > What's it being replaced with in 3.x? > > Nothing yet, it's still there, together with "nonlocal". The global statement will not be changed or renamed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 10:46 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > I'm sending this mail to Python-dev in the hope to reach more developers. > > > > GvR likes to rename the __builtin__ to reduce confusing between > > __builtin__ and __builtins__. He wanted to start a poll on the new name > > but apparently he forgot. > > In a recent thread on python-ideas[1] it was suggested that builtins > be added as an argument to eval and exec. I'd prefer to do that and > eliminate the name altogether. > [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html You can do that but the special entry in globals is still required in order to pass it on to all scopes that need it. > If not that I suggest something like __inject_builtins__. This > implies it's a command to eval/exec, and doesn't necessarily reflect > your current builtins (which are canonically accessible as an > attribute of your frame.) You're misunderstanding the reason why __builtins__ exists at all. It is used *everywhere* as the root namespace, not just as a special case to inject different builtins. ATM I'm torn between __root__ and __python__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
2007/11/28, Guido van Rossum <[EMAIL PROTECTED]>: > ATM I'm torn between __root__ and __python__. __root__ gives me the idea of the base of a tree, its primary node. +0 __python__ gives me the idea of something very deep inside python. +1 Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. In a recent thread on python-ideas[1] it was suggested that builtins be added as an argument to eval and exec. I'd prefer to do that and eliminate the name altogether. If not that I suggest something like __inject_builtins__. This implies it's a command to eval/exec, and doesn't necessarily reflect your current builtins (which are canonically accessible as an attribute of your frame.) [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 11:02 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2007/11/28, Guido van Rossum <[EMAIL PROTECTED]>: > > > ATM I'm torn between __root__ and __python__. > > __root__ gives me the idea of the base of a tree, its primary node. +0 Which it is, if you consider nested namespaces as a tree (all modules are children of __root__, all unnested function locals are children of their module's globals, nested functions are children of their containing function's locals). > __python__ gives me the idea of something very deep inside python. +1 But it violates the (never before uttered, but nevertheless existing in my consciousness since day one) rule that we shouldn't start calling things inside Python "Python things" because then *everything* becomes a Python thingie. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Adam Olsen wrote: > -1 on __python__. It seems to be an abbreviation of "python > interpreter core" or the like, but on its own it implies nothing about > what it means. > > Contrast that with __root__ where we all know what a root is, even > though it doesn't imply what kind of root it is or how its used. I don't like __python__ either. It doesn't explain the meaning of the variable at all. If you want to stick to something like __python__ I suggest __pythoncore__ or __pythonroot__, maybe __pythongastric__ (just kidding). Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 11:50 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Nov 28, 2007 10:46 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: > > On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > I'm sending this mail to Python-dev in the hope to reach more developers. > > > > > > GvR likes to rename the __builtin__ to reduce confusing between > > > __builtin__ and __builtins__. He wanted to start a poll on the new name > > > but apparently he forgot. > > > > In a recent thread on python-ideas[1] it was suggested that builtins > > be added as an argument to eval and exec. I'd prefer to do that and > > eliminate the name altogether. > > [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html > > You can do that but the special entry in globals is still required in > order to pass it on to all scopes that need it. > > > If not that I suggest something like __inject_builtins__. This > > implies it's a command to eval/exec, and doesn't necessarily reflect > > your current builtins (which are canonically accessible as an > > attribute of your frame.) > > You're misunderstanding the reason why __builtins__ exists at all. It > is used *everywhere* as the root namespace, not just as a special case > to inject different builtins. Ahh, so only replacing __builtins__ is unsupported (an implementation detail, as it may be cached), not all use of it? It is confusing that something normally unsupported becomes required for eval/exec. > ATM I'm torn between __root__ and __python__. -1 on __python__. It seems to be an abbreviation of "python interpreter core" or the like, but on its own it implies nothing about what it means. Contrast that with __root__ where we all know what a root is, even though it doesn't imply what kind of root it is or how its used. __root_globals__ would be another option, showing clearly how it relates to our existing use of the "globals" term. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
(The lurker awakes...) > > If not that I suggest something like __inject_builtins__. This > > implies it's a command to eval/exec, and doesn't necessarily reflect > > your current builtins (which are canonically accessible as an > > attribute of your frame.) > > You're misunderstanding the reason why __builtins__ exists at all. It > is used *everywhere* as the root namespace, not just as a special case > to inject different builtins. > > ATM I'm torn between __root__ and __python__. Something with the word "global" speaks to it's real effect, except that the word already has an established meaning in Python as being 'global to the module level', and modifying __builtins__ lets you be "global to the entire universe of that instance" So I would humbly suggest __universal__. The names within are available everywhere. 'root' speaks to me too much of trees, and while namespaces may be tree-like, __root__ alone doesn't say "root namespace"... and __root_namespace__ is long. (Then again, long for a feature that should only be used with care isn't a bad thing) --Stephen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes schrieb: > Adam Olsen wrote: >> -1 on __python__. It seems to be an abbreviation of "python >> interpreter core" or the like, but on its own it implies nothing about >> what it means. >> >> Contrast that with __root__ where we all know what a root is, even >> though it doesn't imply what kind of root it is or how its used. > > I don't like __python__ either. It doesn't explain the meaning of the > variable at all. If you want to stick to something like __python__ I > suggest __pythoncore__ or __pythonroot__, maybe __pythongastric__ (just > kidding). __guts__ ? Really, __python__ has not much self-explanatory potential. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
I find __root_namespace__ rather explicit without being unbearably long. If length is an issue, and __root__ not found explicit, I am suggesting __session__. L. 2007/11/28, Stephen Hansen <[EMAIL PROTECTED]>: > (The lurker awakes...) > > > > > > > If not that I suggest something like __inject_builtins__. This > > > implies it's a command to eval/exec, and doesn't necessarily reflect > > > your current builtins (which are canonically accessible as an > > > attribute of your frame.) > > > > You're misunderstanding the reason why __builtins__ exists at all. It > > is used *everywhere* as the root namespace, not just as a special case > > to inject different builtins. > > > > ATM I'm torn between __root__ and __python__. > > > Something with the word "global" speaks to it's real effect, except that the > word already has an established meaning in Python as being 'global to the > module level', and modifying __builtins__ lets you be "global to the entire > universe of that instance" > > So I would humbly suggest __universal__. The names within are available > everywhere. 'root' speaks to me too much of trees, and while namespaces may > be tree-like, __root__ alone doesn't say "root namespace"... and > __root_namespace__ is long. > > (Then again, long for a feature that should only be used with care isn't a > bad thing) > > --Stephen > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins_ _
Hi, Christian Heimes cheimes.de> writes: > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > > >From http://bugs.python.org/issue1498 > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. I lurk around in this list on gmane and I am a Python user. I just wanted to add my shade of color :) As __builtins__ provides identifiers present in python language, I would prefer __py__ or __lang__ over __root__. Thanks for reading, Suraj ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 12:28 PM, Laurent Gautier <[EMAIL PROTECTED]> wrote: > I find __root_namespace__ rather explicit without being unbearably long. Perhaps the length is even an advantage -- this is not something that should be messed with lightly. > If length is an issue, and __root__ not found explicit, I am > suggesting __session__. No, that already has too many unrelated meanings. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Wed, 2007-11-28 at 16:20 +0100, Christian Heimes wrote: > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. My suggestions, in descending degrees of seriousness: __core__ __fixtures__ -- Carsten Haese http://informixdb.sourceforge.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing the new and types modules
Sorry if this is a dumb question, but are there actually good reasons to remove "types"? IMHO the types module helps keeping code readable. For example "if type(obj) == FloatType" is just more readable than "if type(obj) == type(1.0)". Luckily Python does not distinguish float and double like other languages - otherwise it wouldn't be clear for the average programmer if 1.0 is a float or a double constant. Henning ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing the new and types modules
On Nov 28, 2007 2:23 PM, <[EMAIL PROTECTED]> wrote: > Sorry if this is a dumb question, but are there actually good reasons to > remove "types"? > IMHO the types module helps keeping code readable. > For example > "if type(obj) == FloatType" > is just more readable than > "if type(obj) == type(1.0)". But you should really be writing:: if isinstance(obj, float) for most situations, and:: if type(obj) == float if you really *have* to check the exact type. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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] Re: removing the new and types modules
[EMAIL PROTECTED] wrote: > Sorry if this is a dumb question, but are there actually good reasons to > remove "types"? > IMHO the types module helps keeping code readable. > For example > "if type(obj) == FloatType" > is just more readable than > "if type(obj) == type(1.0)". > if isinstance(obj, float) or if type(obj) is float I often use FunctionType though.So long as it moves rather than vanishes... Michael http://www.manning.com/foord > Luckily Python does not distinguish float and double like other languages > - otherwise it wouldn't be clear for the average programmer if 1.0 is a > float or a double constant. > > Henning > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Steve Holden wrote: > The namespace should really be called __global__. I doubt this will fly, > because it's too radical, and unfortunately would undermine the "global" > keyword __uberglobal__ -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Guido van Rossum wrote: > You can do that but the special entry in globals is still required in > order to pass it on to all scopes that need it. Unless you use something other than a plain dict for module namespaces. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
> I tried to write a simple asyncore-based server code, then I used a
> simple client to establish a connection with it.
> Once the client is connected server raises the following exception:
I think this is a bug. Thanks!
The issue is that the internal call to do_handshake() doesn't handle
non-blocking sockets properly.
You can work around the bug like this:
--- snippet ---
import asyncore, asynchat, socket, ssl, select
class Handler(asyncore.dispatcher):
def __init__(self, conn):
asyncore.dispatcher.__init__(self, conn)
self.socket = ssl.wrap_socket(conn, server_side=True,
certfile='keycert.pem',
do_handshake_on_connect=False)
while True:
try:
self.socket.do_handshake()
break
except ssl.SSLError, err:
if err.args[0] == ssl.SSL_ERROR_WANT_READ:
select.select([self.socket], [], [])
elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
select.select([], [self.socket], [])
else:
raise
self.send('hi there')
--- /snippet ---
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Statsvn output for /python/branches/py3k
All, I was looking at statsvn today at work and gave it a test-run on a repo there. I wondered what it would look like for python3k. And... here are the results: http://www.joevial.com/statsvn/ Enjoy, Joseph Armbruster ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
On 29 Nov, 00:26, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I tried to write a simple asyncore-based server code, then I used a
> > simple client to establish a connection with it.
> > Once the client is connected server raises the following exception:
>
> I think this is a bug. Thanks!
You're welcome.
> The issue is that the internal call to do_handshake() doesn't handle
> non-blocking sockets properly.
>
> You can work around the bug like this:
>
> --- snippet ---
> import asyncore, asynchat, socket, ssl, select
>
> class Handler(asyncore.dispatcher):
>
> def __init__(self, conn):
> asyncore.dispatcher.__init__(self, conn)
> self.socket = ssl.wrap_socket(conn, server_side=True,
> certfile='keycert.pem',
> do_handshake_on_connect=False)
> while True:
> try:
> self.socket.do_handshake()
> break
> except ssl.SSLError, err:
> if err.args[0] == ssl.SSL_ERROR_WANT_READ:
> select.select([self.socket], [], [])
> elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
> select.select([], [self.socket], [])
> else:
> raise
> self.send('hi there')
> --- /snippet ---
>
> Bill
It does raise the same exception.
Are there plans for fixing this?
Using that kind of workaround is not acceptable in any case (select
module shouldn't even get imported when using asyncore).
Moreover I think we need at least a minimal test suite to make sure
that non-blocking sockets work properly.
I'm not experienced with ssl module but I know asyncore/asynchat quite
good.
If you need some help I could propose myself for writing a minimal
test suite for asyncore integration with ssl module when the bocking
issues will be fixed.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
> It does raise the same exception.
Hmmm, not in my version.
> Are there plans for fixing this?
Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
I get a chance.
> Using that kind of workaround is not acceptable in any case (select
> module shouldn't even get imported when using asyncore).
Well, that's what the fix in the SSL module will do under the covers,
so if there's a reason not to do it, or a better way of doing it,
speak now. It really has nothing to do with asyncore; it's just a way
of safely handling a socket which may or may not be non-blocking.
A more extended example, more true to the asyncore way of doing
things, would in fact keep track of the connection state in a local
variable, and would consult that in "handle_read_event" and
"handle_write_event", calling do_handshake again if it's still not
completed. That way you could get rid of the select.
Here's my (working) version of your code. Note that I inherit from
dispatcher_with_send to make sure I have a working "handle_write"
method.
Bill
--- snippet ---
import asyncore, asynchat, socket, ssl, select
class Handler(asyncore.dispatcher_with_send):
def __init__(self, conn):
asyncore.dispatcher_with_send.__init__(self, conn)
self.socket = ssl.wrap_socket(conn, server_side=True,
certfile='keycert.pem',
do_handshake_on_connect=False)
while True:
try:
self.socket.do_handshake()
break
except ssl.SSLError, err:
if err.args[0] == ssl.SSL_ERROR_WANT_READ:
select.select([self.socket], [], [])
elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
select.select([], [self.socket], [])
else:
raise
self.send("hello there!")
def readable(self):
if isinstance(self.socket, ssl.SSLSocket):
while self.socket.pending() > 0:
self.handle_read_event()
return True
def handle_read(self):
data = self.recv(1024)
print data
def handle_error(self):
raise
class Server(asyncore.dispatcher):
def __init__(self):
asyncore.dispatcher.__init__(self)
self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
self.bind(('', 54321))
self.listen(5)
def handle_accept(self):
sock_obj, addr = self.accept()
print "[]%s:%s Connected." %addr
Handler(sock_obj)
def handle_error(self):
raise
Server()
asyncore.loop(timeout=1)
--- /snippet ---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Statsvn output for /python/branches/py3k
On Nov 28, 2007 3:25 PM, Joseph Armbruster <[EMAIL PROTECTED]> wrote: > All, > > I was looking at statsvn today at work and gave it a test-run on a repo there. > I wondered what it would look like for python3k. And... here are the > results: > > http://www.joevial.com/statsvn/ Interesting. Unfortunately no one gets credit for ripping out code. =( -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote: > +1 for either __root_namespace__ or __root__. What is it with nutrient extractors for plants that makes sense here? The goal is to make it blindingly obvious to someone reading code they didn't write (or even that they did) what's going on. +1 for __builtin_namespace__. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 12:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Nov 28, 2007 12:28 PM, Laurent Gautier <[EMAIL PROTECTED]> wrote: > > I find __root_namespace__ rather explicit without being unbearably long. > > Perhaps the length is even an advantage -- this is not something that > should be messed with lightly. > I think that is a valid point. This is one of those situations that the fact this is provided is good enough; it does not need to be short and easy to type. +1 for either __root_namespace__ or __root__. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
On 29 Nov, 03:27, Bill Janssen <[EMAIL PROTECTED]> wrote: > > It does raise the same exception. > > Hmmm, not in my version. > > > Are there plans for fixing this? > > Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when > I get a chance. > > > Using that kind of workaround is not acceptable in any case (select > > module shouldn't even get imported when using asyncore). > > Well, that's what the fix in the SSL module will do under the covers, > so if there's a reason not to do it, or a better way of doing it, > speak now. IMO, it's not reasonable since the application could use something different than select.select(), like select.poll() or something else again. I guess that the best thing to have in such case would be having an "ssl-ized" wrap of the socket which follows the same behaviour of a classical non-blocking socket, then it would be up to the application deciding what to do with it. That way the asynchronous application which wants to switch to a secure connection would just need to wrap the socket by using ssl.wrap_socket() without altering the existing code. Note that I'm just talking about end-user API design. Actually I don't know what happens under the hoods so I'm not even sure which are the real implications. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] || | What name do you prefer? I'm +1 with Raymond on __root__ but I'm still | open for better suggestions. Ok with me, or __rootnames__, but __root_namespace__ is too long for me ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
> IMO, it's not reasonable since the application could use something > different than select.select(), like select.poll() or something else > again. As I said before, you can do away with select or poll altogether if you write a state machine for your asyncore dispatcher. Asyncore will tell you when you can read or write the socket; you just need to know what to do with that information. > I guess that the best thing to have in such case would be having an > "ssl-ized" wrap of the socket which follows the same behaviour of a > classical non-blocking socket, then it would be up to the application > deciding what to do with it. That's what you get if you use "do_handshake_on_connect=False". Your application is expected to do the SSL handshake in its own time. You can do it whichever way you want, as long as you keep calling "do_handshake" appropriately until it fails to raise an error. I think it's simpler to let the SSL module do it, even though it comes at the expense of blocking the thread till the handshake is complete. > That way the asynchronous application which wants to switch to a > secure connection would just need to wrap the socket by using > ssl.wrap_socket() without altering the existing code. That's essentially what happens already. The question is whether the SSL setup code is allowed to block the non-blocking socket till the SSL handshake is complete. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Fred Drake wrote: > On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote: >> +1 for either __root_namespace__ or __root__. > > > What is it with nutrient extractors for plants that makes sense here? Root is a word that takes on a specific meaning depending on the context. Root as in tooth root, tree root, to root one self as in self defense, root of all evil, to root out. etc... In the case of python and name spaces, the context of __root__ would be suitably narrow so that the meaning would be clear and familiar with use. Searching for "python __root__" would give good results as well. In the case of a file or module name where it could be viewed out of context, it would be less suitable. I think __builtin__ is fine for that. Or __default_root__, as in the default root module to be placed in the __root__ name space. Keeping __root__ relatively short has the benefit of being able to easily use "__root__.name" in the case where "name" was/is used in the local scope. I don't see any reason to make it harder. There might even be a use case for using all explicit __root__ references. So +1 on __root__ for me for a name space designator. Regards, Ron > The goal is to make it blindingly obvious to someone reading code they > didn't write (or even that they did) what's going on. > > +1 for __builtin_namespace__. > > >-Fred > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On 11/28/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > I think __root__ is a fine name. Anyway, here some suggestions (in no particular order): __top__ __syswide__ __outer__ __telescope__ -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 10:11 PM, Ron Adam <[EMAIL PROTECTED]> wrote: > Keeping __root__ relatively short has the benefit of being able to easily > use "__root__.name" in the case where "name" was/is used in the local > scope. I don't see any reason to make it harder. There might even be a > use case for using all explicit __root__ references. Isn't this an explicit non-goal? We're talking about __builtins__, the implementation hack, not __builtin__ the module-like object you're supposed to use if you want to do things like __builtin__.open. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Wed, 28 Nov 2007 16:20:05 +0100, you wrote: >What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >open for better suggestions. how about making it (a little bit) more explicit with __rootdict__ or __root_dict__ -- Ton ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
