Re: [Python-3000] xrange vs. int.__getslice__
Ivan Krstic wrote: > Vladimir 'Yu' Stepanov wrote: > >> - >> for i in xrange(100): pass >> vs. >> for i in int[:100]: pass >> - >> > > I'm a strong -1 on this; it makes it look like float[:100] should also > be legal and reasonable, but I can't see how it could possibly be. In general that I thought to stop only on type int :). But your idea to distribute it on other types seems to me quite good even if it has been resulted as counter-argument. It is how much possible to understand slice in Python language is a reception of a range of values with the certain step. By default this step is equal to 1 for objects of any type. It is possible to assume, that the similar behaviour can be at types float, decimal, long and other. As the method __getslice__ till now is not involved by any image for numbers. Advantage of such approach is that it is not necessary to hold function in space __builtins__. Each numerical object (excepting unless complex) can describe the number of values. It is possible to give an example still. We shall tell, it is necessary to pass on ranges of values with 0 on 1000 numbers with a floating point. Example: - for i in xrange(1000): i = float(i) .. do something .. vs. for i in float[:1000]: .. do something .. - Now for fractional types widely to use this opportunity it will not turn out. C-API as arguments are transferred only ะก-`long' integers. To achieve, that a step of less unit it was now impossible, therefore as all arguments will be approximated. ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] xrange vs. int.__getslice__
> It is how much possible to understand slice in Python language is a > reception of a range of values with the certain step. By default this > step is equal to 1 for objects of any type. It is possible to assume, > that the similar behaviour can be at types float, decimal, long and > other. As the method __getslice__ till now is not involved by any > image for numbers. How the following case should work? class even(int): .. "Only the even integers..." for i in even[:100]: .. do something ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] The main module in Py3k
PEP 299 recently got added to the list of ideas to be reconsidered for Py3k. The motivation seemed to be that the current idiom is both ugly and unintuitive if you haven't drunk enough of the relevant Koolaid. I can't really argue with that assessment, but I think PEP 299 proposes more radical changes to the idiom than are really necessary. My preferred solution would look like this: 1. Determining if the current module is the main module: The boolean value __main__ would be defined in all modules. It would be set to True in the main module, and False everywhere else. The existing "if __name__ == '__main__' idiom would be replaced by a simple "if __main__:" A boolean flag that's true in the main module and false everywhere else should be straightforward to both teach and remember (even simpler than trying to explain a magic function that gets called only when the module is the main module). This part of the proposal is all that most users would ever care about. 2. Accessing the main module from another module: A new attribute in the sys module "main" would always reference the main module of the application. The main module would also be stored in sys.modules under the name "sys.main", so that "import sys.main" and "from sys import main" would correctly retrieve the main module. Usages of the form "import __main__" would be replaced by "import sys.main", and "__main__." would be replaced by "sys.main.". This part of the proposal is to avoid the name conflict between "import __main__" and the proposed boolean flag. An alternative would be to use a different name for the boolean flag (e.g. invert the sense of it, and call it "__imported__"). 3. Relative imports from the main module: Files that are executed directly would have their __name__ attribute set to "". Modules executed using -m would have their __name__ attribute set to their real module name as provided on the command line. The main module would actually be referenced from sys.modules twice (once under the name "sys.main" and once under the value of sys.main.__name__) Relative imports from directly executed modules would continue to behave as for the 2.x series (since the import machinery only cares about the number of dots preceding the module name, "" will behave the same as "__main__"). Relative imports from modules executed with -m, however, would now be able to use the normal relative import mechanism and the __module_name__ workaround proposed for the 2.x series could disappear. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] xrange vs. int.__getslice__
Please don't cross-post python-dev and python-3000. This proposal will not be adopted in Py3k. Instead, range() will become more like xrange(). --Guido On 6/13/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > You were bothered yet with function xrange ? :) I suggest to replace it. > > - > for i in xrange(100): pass > vs. > for i in int[:100]: pass > - > > - > for i in xrange(1000, 1020): pass > vs. > for i in int[1000:1020]: pass > - > > - > for i in xrange(200, 100, -2): pass > vs. > for i in int[200:100:-2]: pass > - > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] The main module in Py3k
On 7/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > PEP 299 recently got added to the list of ideas to be reconsidered for Py3k. > The motivation seemed to be that the current idiom is both ugly and > unintuitive if you haven't drunk enough of the relevant Koolaid. > > I can't really argue with that assessment, but I think PEP 299 proposes more > radical changes to the idiom than are really necessary. > > My preferred solution would look like this: > > 1. Determining if the current module is the main module: > > The boolean value __main__ would be defined in all modules. It would be set to > True in the main module, and False everywhere else. > > The existing "if __name__ == '__main__' idiom would be replaced by a simple > "if __main__:" > > A boolean flag that's true in the main module and false everywhere else should > be straightforward to both teach and remember (even simpler than trying to > explain a magic function that gets called only when the module is the main > module). > > This part of the proposal is all that most users would ever care about. Two comments: - I'm not convinced that it's worth changing this. - *If* we're going to change this, we should reconsider whether it's really necessary to spell this with __underscores__. > 2. Accessing the main module from another module: > > A new attribute in the sys module "main" would always reference the main > module of the application. The main module would also be stored in sys.modules > under the name "sys.main", so that "import sys.main" and "from sys import > main" would correctly retrieve the main module. > > Usages of the form "import __main__" would be replaced by "import sys.main", > and "__main__." would be replaced by "sys.main.". > > This part of the proposal is to avoid the name conflict between "import > __main__" and the proposed boolean flag. An alternative would be to use a > different name for the boolean flag (e.g. invert the sense of it, and call it > "__imported__"). Please consider what the use case is for accessing the main module, and whether we should consider providing a different solution for that use case rather than a different way to access the main module. > 3. Relative imports from the main module: > > Files that are executed directly would have their __name__ attribute set to > "". Modules executed using -m would have their __name__ attribute set to > their real module name as provided on the command line. > > The main module would actually be referenced from sys.modules twice (once > under the name "sys.main" and once under the value of sys.main.__name__) > > Relative imports from directly executed modules would continue to behave as > for the 2.x series (since the import machinery only cares about the number of > dots preceding the module name, "" will behave the same as "__main__"). > > Relative imports from modules executed with -m, however, would now be able to > use the normal relative import mechanism and the __module_name__ workaround > proposed for the 2.x series could disappear. Frankly, I am beginning to regret ever having endorsed the -m option. It seems leads to an ever increasing series of discussions about mundane details that aren't worth the intellectual power devoted to them. I still think that relative import from a main module is a solution in search of a problem, and I am beginning to feel the same about the other issues that you are addressing above. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] The main module in Py3k
Guido van Rossum wrote: >> Relative imports from modules executed with -m, however, would now >> be able to use the normal relative import mechanism and the >> __module_name__ workaround proposed for the 2.x series could >> disappear. > > Frankly, I am beginning to regret ever having endorsed the -m option. In case you mean the -m pkg.mod spelling, I agree. It's bringing a lot of complexity, including the __module_name__ hack, for exactly what gain? So that one doesn't have to write 2 liner wrapper installed as top-level module in the site-packages? -- Giovanni Bajo ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] range vs. int.__getslice__
Diogo Kollross wrote: >> It is how much possible to understand slice in Python language is a >> reception of a range of values with the certain step. By default this >> step is equal to 1 for objects of any type. It is possible to assume, >> that the similar behaviour can be at types float, decimal, long and >> other. As the method __getslice__ till now is not involved by any >> image for numbers. >> > > How the following case should work? > > class even(int): > .. "Only the even integers..." > > for i in even[:100]: > .. do something This method should not be accessible through the inherited classes. Ambiguity from the point of view of the user (you have already resulted an example) will be shown differently. It will be probably necessary to add one more METH_* an option. For example METH_NOEXPORT. Besides optimization should be not worse existing range, that is impossible without adaptation of a method under concrete type of data. The method __getslice__ cannot be set for type with option METH_CLASS or METH_STATIC. I expect occurrence of the syntax, satisfying to needs of the given method. Recently it was discussed parametrization of types. In this connection, how it will be realized __getitem__ for work with classes ? The similar design could be used and for alternative realization of syntax `range': http://mail.python.org/pipermail/python-3000/2006-May/002149.html That it would be possible is high-grade to work and with other types of data, except for int and long, it is required that PEP-357 has been completed: http://www.python.org/dev/peps/pep-0357/ Thanks. -- Vladimir ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] xrange vs. int.__getslice__
Guido van Rossum wrote: > Please don't cross-post python-dev and python-3000. > > This proposal will not be adopted in Py3k. Instead, range() will > become more like xrange(). Added to PEP 3099. Georg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] The main module in Py3k
\On 7/4/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > >> Relative imports from modules executed with -m, however, would now > >> be able to use the normal relative import mechanism and the > >> __module_name__ workaround proposed for the 2.x series could > >> disappear. > > > > Frankly, I am beginning to regret ever having endorsed the -m option. > > In case you mean the -m pkg.mod spelling, I agree. It's bringing a lot of > complexity, including the __module_name__ hack, for exactly what gain? So > that one doesn't have to write 2 liner wrapper installed as top-level module > in the site-packages? And by extension even the -m mod spelling, since its introduction led to the argument that -m pkg.mod should not be left behind... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] The main module in Py3k
Nick Coghlan wrote: > The existing "if __name__ == '__main__' idiom would be replaced by a simple > "if __main__:" That sounds good. > A new attribute in the sys module "main" would always reference the main > module of the application. The main module would also be stored in > sys.modules > under the name "sys.main", Why not just __main__ as the alias name? Is there any need to invent a new name for this? > Files that are executed directly would have their __name__ attribute set to > "". Again, why not leave it as "__main__" in this case? And if it must change, does it really have to be something that's not a valid identifier and/or doesn't correspond to anything in sys.modules? -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
