Mailman 3 November 2013 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

Implicit string literal concatenation considered harmful?
by Guido van Rossum March 14, 2018

March 14, 2018

I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b'). This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden). Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' … [View More]

51 165

Re: [Python-ideas] Update the required C compiler for Windows to a supported version.
by Steve Dower March 2, 2014

March 2, 2014

Stephen J. Turnbull wrote: > Vernon D. Cole writes: > >> I cannot compile a Python extension module with any Microsoft compiler >> I can obtain. > > Your pain is understood, but it's not simple to address it. FWIW, I'm working on making the compiler easily obtainable. The VS 2008 link that was posted is unofficial, and could theoretically disappear at any time (I'm not in control of that), but the Windows SDK for Windows 7 and .NET 3.5 SP1 (http://www.microsoft.com/… [View More]en-us/download/details.aspx?id=3138) should be around for as long as Windows 7 is supported. The correct compiler (VC9) is included in this SDK, but unfortunately does not install the vcvarsall.bat file that distutils expects. (Though it's pretty simple to add one that will switch on %1 and call the correct vcvars(86|64|...).bat.) The SDK needed for Python 3.3 and 3.4 (VC10) is even worse - there are many files missing. I'm hoping we'll be able to set up some sort of downloadable package/tool that will fix this. While we'd obviously love to move CPython onto our latest compilers, it's simply not possible (for good reason). Python 3.4 is presumably locked to VC10, but hopefully 3.5 will be able to use whichever version is current when that decision is made. > The basic problem is that the ABI changes. Therefore it's going to require > a complete new set of *all* C extensions for Windows, and the duplication > of download links for all those extensions from quite a few different vendors > is likely to confuse a lot of users. Specifically, the CRT changes. The CRT is an interesting mess of data structures that are exposed in header files, which means while you can have multiple CRTs loaded, they cannot touch each other's data structures at all or things will go bad/crash, and there's no nice way to set it up to avoid this (my colleague who currently owns MSVCRT suggested a not-very-nice way to do it, but I don't think it's going to be reliable enough). Python's stable ABI helps, but does not solve this problem. The file APIs are the worst culprits. The layout of FILE* objects can and do change between CRT versions, and file descriptors are simply indices into an array of these objects that is exposed through macros rather than function calls. As a result, you cannot mix either FILE pointers or file descriptors between CRTs. The only safe option is to build with the matching CRT, and for MSVCRT, this means with the matching compiler. It's unfortunate, and the responsible teams are well aware of the limitation, but it's history at this point, so we have no choice but to work with it. Cheers, Steve [View Less]

4 3

while conditional in list comprehension ??
by Wolfgang Maier Feb. 21, 2014

Feb. 21, 2014

Dear all, I guess this is so obvious that someone must have suggested it before: in list comprehensions you can currently exclude items based on the if conditional, e.g.: [n for n in range(1,1000) if n % 4 == 0] Why not extend this filtering by allowing a while statement in addition to if, as in: [n for n in range(1,1000) while n < 400] Trivial effect, I agree, in this example since you could achieve the same by using range(1,400), but I hope you get the point. This intuitively … [View More]

19 70

Replacing the if __name__ == "__main__" idiom (was Re: making a module callable)
by Eric Snow Dec. 6, 2013

Dec. 6, 2013

On Fri, Nov 22, 2013 at 1:44 PM, Gregory P. Smith <greg(a)krypto.org> wrote: > It'd be nice to formalize a way to get rid of the __name__ == '__main__' > idiom as well in the long long run. Sure everyone's editor types that for > them now but it's still a wart. Anyways, digressing... ;) This has come up before and is the subject of several PEPS. [1][2] The current idiom doesn't bother me too much as I try not to have files that are both scripts and modules. However, Python … [View More]

34 90

string codes & substring equality
by spir Dec. 2, 2013

Dec. 2, 2013

Hello, Coming back to python after a long time. My present project is about (yet another) top-down matching / parsing lib. There are 2 issues that, I guess, may be rather easily solved by simple string methods. The core point is that any scanning / parsing process ends up, a the lowest level, constantly comparing either single-char (rather single-code) substrings or constant (literal) substrings of the source string. This is the only operation which, when successful, actually advances in … [View More]the source. Thus, it is certainly worth having it efficient, or at the minimum not having it needlessly inefficient. I suppose the same functionalities can be highly useful in various other use cases of text processing. Note again that I'm rediscovering Python (with some pleasure :-), thus may miss known solutions -- but I asked on the tutor mailing list. In both cases, I guess ordinary idiomatic Python code actually _creates_ a new string object, as a substring of length 1 or more, which is otherwise useless; for instance: if s[i] == char: # match ok -- object s[i] unneeded if s[i:j] == substr: # match ok -- object s[i:j] unneeded What is actually needed is just to check for equality (or another check about a code, see below). The case of single-code checking appears when (1) a substring happens to hold a single code (meaning it represents a simple or precomposed unicode char) (2) when matching a char from a given set, range, or more complex class (eg in regex [a-zA-Z0-9_-']). In all cases, what we want is tocheck the code: compare it to a constant value, check whether it belongs to a set of value, or lies inside a given range. We need the code --not a single-code string. Ideally, I'd like expressions like: c = s.code(i) # or s.ord(i) or s.ucode(i) [3] # and then one of: if c = code: # match ok if c in codes: # match ok if c >= code1 and c <= code2: # match ok The builtin function ord(char) does not do the job, since it only works for a single-char string. We would again need to create a new string, with ord(s[i]). The right solution apparently is a string method like code(self, i) giving the code at an arbitrary index. I guess this is trivial. I'm surprised it does not exist; maybe some may think this is a symptom there is no strong need for it; instead, I guess people routinely use a typical Python idiom without even noticing it creates a unneeded string object. [2] [3] What do you think? A second need is checking substring equality against constant substrings of arbitrary sizes. This is similar to startswith & endswith, except at any code index in the source string; a generalisation. In C implementation, it would probably delegate to memcomp, with a start pointer set to p_source+i. On the Python side, it may be a string method like sub_equals(self, substr, i). Choose you preferred name ;-). [1] [4] if s.sub_equals(substr, i): # match ok What do you think? (bis) Thank you, Denis [1] I am unsure whether an end index is useful, actually I don't really understand its usage for startswith & endswith neither. [2] Actually, the compiler, if smart enough, may eliminate this object construction and just check the code; does it? Anyway, I think it is not that easy in the cases of ranges & sets. [3] As a side-note, 'ord' is in my view a misnomer, since character codes are not ordinals, with significant order, but nominals, plain numerical codes which only need to be all distinct; they are kinds of id's. For unicode, I call them 'ucodes', an idea I stole somewhere. But I would be happy is the method is called 'ord' anyway, since the term is established in the Python community. [4] Would such a new method make startswith & endswith unneeded? [View Less]

15 73

string.Template v2
by anatoly techtonik Nov. 30, 2013

Nov. 30, 2013

http://docs.python.org/2/library/string.html#template-strings ## Original Idea stdlib lacks the most popular basic variable extension syntax "{{ variable }}" that can be found in Django [1], Jinja2 [2] and other templating engines [3]. ## stdlib Analysis string.Template syntax is ancient (dates back to Python 2.4 from 9 years ago). I haven't seen a template like this for a long time. ## Scope of Enhancement st = 'Hello {{world}}.' world = 'is not enough' t = Template(string, style='brace')… [View More]

10 15

Refactor Assertions Out of unittest.TestCase
by Daniel Watkins Nov. 30, 2013

Nov. 30, 2013

Hello all, I would like to propose refactoring the assertions out of unittest.TestCase. As code speaks louder than words, you can see my initial work at https://github.com/OddBloke/cpython. The aim of the refactor is: (a) to reduce the amount of repeated code in the assertions, (b) to provide a clearer framework for third-party assertions to follow, and (c) to make it easier to split gnarly assertions in to an easier-to-digest form. My proposed implementation (as seen in the code above) is … [View More]

3 3

os.path.join
by anatoly techtonik Nov. 29, 2013

Nov. 29, 2013

>>> os.path.join('/static', '/styles/largestyles.css') '/styles/largestyles.css' Is it only me who thinks that the code above is wrong?

16 31