Mailman 3 October 2015 - 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

proposal: "python -m foo" should bind sys.modules['foo']
by Cameron Simpson Jan. 18, 2017

Jan. 18, 2017

Hello all, This is a writeup of a proposal I floated here: https://mail.python.org/pipermail/python-list/2015-August/694905.html last Sunday. If the response is positive I wish to write a PEP. Briefly, it is a natural expectation in users that the command: python -m module_name ... used to invoke modules in "main program" mode on the command line imported the module as "module_name". It does not, it imports it as "__main__". An import within the program of "module_name" makes a new … [View More]instance of the module, which causes cognitive dissonance and has the side effect that now the program has two instances of the module. What I propose is that the above command line _should_ bind sys.modules['module_name'] as well as binding '__main__' as it does currently. I'm proposing that the python -m option have this effect (python pseudocode): % python -m module.name ... runs: # pseudocode, with values hardwired for clarity import sys M = new_empty_module(name='__main__', qualname='module.name') sys.modules['__main__'] = M sys.modules['module.name'] = M # load the module code from wherever (not necessarily a file - CPython # already must do this phase) M.execfile('/path/to/module/name.py') Specificly, this would have the following two changes to current practice: 1) the module is imported _once_, and bound to both its canonical name and also to __main__. 2) imported modules acquire a new attribute __qualname__ (analogous to the recent __qualname__ on functions). This is always the conanoical name of the module as resolved by the importer. For most modules __name__ will be the same as __qualname__, but for the "main" module __name__ will be '__main__'. This change has the following advantages: The current standard boilerplate: if __name__ == '__main__': ... invoke "main program" here ... continues to work unchanged. Importantly, if the program then issues "import module_name", it is already there and the existing instance is found and used. The thread referenced above outlines my most recent encounter with this and the trouble it caused me. Followup messages include some support for this proposed change, and some criticism. The critiquing article included some workarounds for this multiple module situation, but they were (1) somewhat dependent on modules coming from a file pathname and (2) cumbersome and require every end user to adopt these changes if affected by the situation. I'd like to avoid that. Cheers, Cameron Simpson <cs(a)zip.com.au> The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw [View Less]

5 13

solving multi-core Python
by Eric Snow June 3, 2016

June 3, 2016

tl;dr Let's exploit multiple cores by fixing up subinterpreters, exposing them in Python, and adding a mechanism to safely share objects between them. This proposal is meant to be a shot over the bow, so to speak. I plan on putting together a more complete PEP some time in the future, with content that is more refined along with references to the appropriate online resources. Feedback appreciated! Offers to help even more so! :) -eric -------- Python's multi-core story is murky at best. … [View More]Not only can we be more clear on the matter, we can improve Python's support. The result of any effort must make multi-core (i.e. parallelism) support in Python obvious, unmistakable, and undeniable (and keep it Pythonic). Currently we have several concurrency models represented via threading, multiprocessing, asyncio, concurrent.futures (plus others in the cheeseshop). However, in CPython the GIL means that we don't have parallelism, except through multiprocessing which requires trade-offs. (See Dave Beazley's talk at PyCon US 2015.) This is a situation I'd like us to solve once and for all for a couple of reasons. Firstly, it is a technical roadblock for some Python developers, though I don't see that as a huge factor. Regardless, secondly, it is especially a turnoff to folks looking into Python and ultimately a PR issue. The solution boils down to natively supporting multiple cores in Python code. This is not a new topic. For a long time many have clamored for death to the GIL. Several attempts have been made over the years and failed to do it without sacrificing single-threaded performance. Furthermore, removing the GIL is perhaps an obvious solution but not the only one. Others include Trent Nelson's PyParallels, STM, and other Python implementations.. Proposal ======= In some personal correspondence Nick Coghlan, he summarized my preferred approach as "the data storage separation of multiprocessing, with the low message passing overhead of threading". For Python 3.6: * expose subinterpreters to Python in a new stdlib module: "subinterpreters" * add a new SubinterpreterExecutor to concurrent.futures * add a queue.Queue-like type that will be used to explicitly share objects between subinterpreters This is less simple than it might sound, but presents what I consider the best option for getting a meaningful improvement into Python 3.6. Also, I'm not convinced that the word "subinterpreter" properly conveys the intent, for which subinterpreters is only part of the picture. So I'm open to a better name. Influences ======== Note that I'm drawing quite a bit of inspiration from elsewhere. The idea of using subinterpreters to get this (more) efficient isolated execution is not my own (I heard it from Nick). I have also spent quite a bit of time and effort researching for this proposal. As part of that, a number of people have provided invaluable insight and encouragement as I've prepared, including Guido, Nick, Brett Cannon, Barry Warsaw, and Larry Hastings. Additionally, Hoare's "Communicating Sequential Processes" (CSP) has been a big influence on this proposal. FYI, CSP is also the inspiration for Go's concurrency model (e.g. goroutines, channels, select). Dr. Sarah Mount, who has expertise in this area, has been kind enough to agree to collaborate and even co-author the PEP that I hope comes out of this proposal. My interest in this improvement has been building for several years. Recent events, including this year's language summit, have driven me to push for something concrete in Python 3.6. The subinterpreter Module ===================== The subinterpreters module would look something like this (a la threading/multiprocessing): settrace() setprofile() stack_size() active_count() enumerate() get_ident() current_subinterpreter() Subinterpreter(...) id is_alive() running() -> Task or None run(...) -> Task # wrapper around PyRun_*, auto-calls Task.start() destroy() Task(...) # analogous to a CSP process id exception() # other stuff? # for compatibility with threading.Thread: name ident is_alive() start() run() join() Channel(...) # shared by passing as an arg to the subinterpreter-running func # this API is a bit uncooked still... pop() push() poison() # maybe select() # maybe Note that Channel objects will necessarily be shared in common between subinterpreters (where bound). This sharing will happen when the one or more of the parameters to the function passed to Task() is a Channel. Thus the channel would be open to the (sub)interpreter calling Task() (or Subinterpreter.run()) and to the new subinterpreter. Also, other channels could be fed into such a shared channel, whereby those channels would then likewise be shared between the interpreters. I don't know yet if this module should include *all* the essential pieces to implement a complete CSP library. Given the inspiration that CSP is providing, it may make sense to support it fully. It would be interesting then if the implementation here allowed the (complete?) formalisms provided by CSP (thus, e.g. rigorous proofs of concurrent system models). I expect there will also be a _subinterpreters module with low-level implementation-specific details. Related Ideas and Details Under Consideration ==================================== Some of these are details that need to be sorted out. Some are secondary ideas that may be appropriate to address in this proposal or may need to be tabled. I have some others but these should be sufficient to demonstrate the range of points to consider. * further coalesce the (concurrency/parallelism) abstractions between threading, multiprocessing, asyncio, and this proposal * only allow one running Task at a time per subinterpreter * disallow threading within subinterpreters (with legacy support in C) + ignore/remove the GIL within subinterpreters (since they would be single-threaded) * use the GIL only in the main interpreter and for interaction between subinterpreters (and a "Local Interpreter Lock" for within a subinterpreter) * disallow forking within subinterpreters * only allow passing plain functions to Task() and Subinterpreter.run() (exclude closures, other callables) * object ownership model + read-only in all but 1 subinterpreter + RW in all subinterpreters + only allow 1 subinterpreter to have any refcounts to an object (except for channels) * only allow immutable objects to be shared between subinterpreters * for better immutability, move object ref counts into a separate table * freeze (new machinery or memcopy or something) objects to make them (at least temporarily) immutable * expose a more complete CSP implementation in the stdlib (or make the subinterpreters module more compliant) * treat the main interpreter differently than subinterpreters (or treat it exactly the same) * add subinterpreter support to asyncio (the interplay between them could be interesting) Key Dependencies ================ There are a few related tasks/projects that will likely need to be resolved before subinterpreters in CPython can be used in the proposed manner. The proposal could implemented either way, but it will help the multi-core effort if these are addressed first. * fixes to subinterpreter support (there are a couple individuals who should be able to provide the necessary insight) * PEP 432 (will simplify several key implementation details) * improvements to isolation between subinterpreters (file descriptors, env vars, others) Beyond those, the scale and technical scope of this project means that I am unlikely to be able to do all the work myself to land this in Python 3.6 (though I'd still give it my best shot). That will require the involvement of various experts. I expect that the project is divisible into multiple mostly independent pieces, so that will help. Python Implementations =================== They can correct me if I'm wrong, but from what I understand both Jython and IronPython already have subinterpreter support. I'll be soliciting feedback from the different Python implementors about subinterpreter support. C Extension Modules ================= Subinterpreters already isolate extension modules (and built-in modules, including sys). PEP 384 provides some help too. However, global state in C can easily leak data between subinterpreters, breaking the desired data isolation. This is something that will need to be addressed as part of the effort. [View Less]

26 130

OrderedCounter and OrderedDefaultDict
by Ian Foote Feb. 12, 2016

Feb. 12, 2016

I recently wanted to use an OrderedCounter and an OrderedDefaultDict. After a bit of googling I discovered that OrderedCounter is quite easy to implement: from collections import Counter, OrderedDict class OrderedCounter(Counter, OrderedDict): 'Counter that remembers the order elements are first seen' def __repr__(self): return '%s(%r)' % (self.__class__.__name__, OrderedDict(self)) def __reduce__(self): return self.… [View More]

14 23

Add 'module' module, similar to 'keyword' module
by Terry Reedy Nov. 2, 2015

Nov. 2, 2015

This idea results from issue of user files shadowing stdlib files on import. There was a thread on pydev about this yesterday. There is also an opposite issue of builtin modules shadowing user files. The keyword module provides kwlist and iskeyword function. One use of kwlist is used in some other stdlib modules and can be used by syntax highlighters (as in IDLE). Kwlist is updated by the main function. A module module would have at least liblist and islibmodule function. Liblist … [View More]

6 10

ssl module: validated certificate chain
by Cory Benfield Oct. 29, 2015

Oct. 29, 2015

All, I’m currently working on adding support for HPKP to the Requests and urllib3 modules. HPKP (HTTP Public Key Pinning), specified in RFC 7469, is an extension to HTTP that allows a web server to specify a whitelist of public keys that are valid for TLS certificates on that domain. This prevents a rogue certificate authority from issuing a certificate that would be trusted by a browser and would allow a man-in-the-middle attack on a domain (as happened to Google in 2013[0]). Right now, the … [View More]

2 1

Specifying constants for functions
by Serhiy Storchaka Oct. 28, 2015

Oct. 28, 2015

There is known trick to optimize a function: def foo(x, y=0, len=len, pack=struct.pack, maxsize=1<<BPF): ... It has a side effect: change function's signature. Would be nice to have a way to set function's local variables at creation time without affecting a signature. Possible syntax (I'm not sure what is better): 1. Similar to "global" and "nonlocal" declarations with optional initializer. def foo(x, y=0): const len const pack=struct.pack, … [View More]

12 18

Re: [Python-ideas] PEP 8: raw strings & regular expressions
by Ned Batchelder Oct. 27, 2015

Oct. 27, 2015

On 10/22/15 6:56 PM, Yury Selivanov wrote: > In principle, there is no reason why *both* of these groups > of users can't use one tool and be happy. I propose to > establish a convention in PEP 8, explaining that, while both > literals are semantically equivalent, > > - r'..' strings *should* be used for regexps, > > - R'..' strings *should* be used for unstyled raw strings, > > and tools *should* treat them as such. > > All of this is merely about codifying … [View More]

9 12

Allowing def to assign to anything
by Alexander Walters Oct. 27, 2015

Oct. 27, 2015

In my code, I write a lot of dispatch dictionaries (for lack of a switch statement, but I will not hold my breath for that). In trying to make writing these dictionaries less annoying, I tend to use many lambdas. I can let you guess at what problems that has resulted in. Of course, the preferred way to write such dictionaries is by using a regular function, and adding that function to a dictionary. This isn't exactly a problem - it works, and works well, but it is annoying to write, … [View More]

9 22

Re: [Python-ideas] PEP 8: raw strings & regular expressions
by Yury Selivanov Oct. 26, 2015

Oct. 26, 2015

On 2015-10-22 9:42 PM, Steven D'Aprano wrote: > If you want my advice, it would be to either just pick whichever style > of formatting you like, and people will either like your code > highlighter and use it, or they won't, or you should consider a plug-in > architecture where your users can choose the string-highlighter style > they want, and even extend it to other DSLs. Yeah, I finally figured out a way to make the highlighter easily configurable, so that users can turn on/… [View More]

1 0

"else if" as equivalent for "elif"
by Ian Kelly Oct. 26, 2015

Oct. 26, 2015

Parse the sequence "else if" equivalently to "elif". This would be 100% backward compatible. It wouldn't require adding any new keywords to the language. It shouldn't be burdensome to maintain, since "elif" only appears in one place in the grammar. And it solves a minor readability complaint. Thoughts?

14 25

Re: [Python-ideas] Allowing def to assign to anything
by Alexander Heger Oct. 26, 2015

Oct. 26, 2015

how about class Dispatch(object): @staticmethod def foo(bar): return bar * bar def __getitem__(self, key): return self.__getattribute__(key) dispatch = Dispatch() >>> test.dispatch['foo'](2) 4 this leaves the module namespace less polluted. -Alexander On 26 October 2015 at 18:27, Ian Kelly <ian.g.kelly(a)gmail.com> wrote: >> On Sun, Oct 25, 2015 at 11:02 PM, Alexander Walters >> <tritium-list(a)sdamon.com> wrote: >>> &… [View More]

1 0

Re: [Python-ideas] PEP 8: raw strings & regular expressions
by Barry Warsaw Oct. 26, 2015

Oct. 26, 2015

On Oct 22, 2015, at 06:56 PM, Yury Selivanov wrote: >In principle, there is no reason why *both* of these groups >of users can't use one tool and be happy. I propose to >establish a convention in PEP 8, explaining that, while both >literals are semantically equivalent, > >- r'..' strings *should* be used for regexps, > >- R'..' strings *should* be used for unstyled raw strings, > >and tools *should* treat them as such. > >All of this is merely about … [View More]

2 1

Re: [Python-ideas] PEP 8: raw strings & regular expressions
by Eric V. Smith Oct. 25, 2015

Oct. 25, 2015

On 10/22/2015 06:56 PM, Yury Selivanov wrote: > On the other hand, *a lot* of users are annoyed, when their > raw strings are highlighted as regexps (why \n is highlighted > as escaped?). Often that results not in just wrongly > highlighted raw strings, but in broken highlighting of > the whole source file [1]. ... > [1] https://gist.github.com/1st1/d3da5d69a9b6c088c26f I don't see how this matters to the subject at hand. No matter what you think an r or R string contains, … [View More]

1 0

PEP 8: raw strings & regular expressions
by Yury Selivanov Oct. 23, 2015

Oct. 23, 2015

Hi, I was a little bit frustrated that Sublime Text and Atom didn't support all Python 3 features (mainly annotations & async/await syntax), so I decided to write a new highlighter: https://github.com/MagicStack/MagicPython In the process, we had to make a decision on how to highlight raw string literals -- r''. Many existing highlighters assume that all raw strings are regexps, and highlight them as such, i.e. '\s' and '\n' will be highlighted. I think that it might be a good … [View More]

12 18

Re: [Python-ideas] PEP 8: raw strings & regular expressions
by Sven R. Kunze Oct. 23, 2015

Oct. 23, 2015

I think you shouldn't push it, Yury. Most people here seem not to like it that much for many reasons. Best, Sven On 23.10.2015 00:56, Yury Selivanov wrote: > Hi Barry, > > On 2015-10-22 5:17 PM, Barry Warsaw wrote: >>> I think that it might be a good idea to state the following in PEP 8: >>> > >>> >- use r'...' strings for raw strings that describe regular >>> expressions; >>> >these strings might be highlighted specially in … [View More]

1 0

Add specialized bytecode with guards to functions
by Victor Stinner Oct. 22, 2015

Oct. 22, 2015

Hi, I would like to share with you an idea to try to optimize CPython. My previous attempts to optimize CPython failed because they changed the language semantic. For example, it's not possible to replace len('abc') with 3 because it is technically possible to override the builtin len() function. I propose to add a new "FAT" mode to Python to allow to add specialized bytecode to function with guards. Example: >>> import builtins >>> def f(): return len("abc") ..… [View More]. >>> f() 3 >>> def g(): return 3 ... >>> i=f.add(g) # i is the index of the new specialized bytecode >>> f.add_dict_key_guard(i, builtins.__dict__, 'len') >>> f() 3 >>> builtins.len = lambda obj: "len" >>> f() 'len' In this example, the f() function gets a fast version (g()) returning directly 3 instead of calling len("abc"). The optimization is disabled when the builtin len() function is modified (when builtins.__dict__['len'] is modified). (The example is not complete, we need a second guard on the current global namespace, but I wanted to write a short example.) With such machinery, it becomes possible to implement interesting optimizations. Some examples: * inline a function instead of calling it: calling a Python function is "expensive". For example, if you inline the _get_sep() call in posixpath.isabs(), the function becomes 20% faster. * move invariant out of the loop: classic micro-optimization done manually. For example, set "append = obj.append" before the loop and then call "append(item)" instead of "obj.append(item)" in the loop body. On a microbenchmark, it's between 5% (1 item) and 30% faster (10 items or more) * call pure functions at the compilation. A pure function has no side effect. Example: len(str). Technical Challenges ==================== The problem is the cost of "guards". A guard is a check done before calling a specialized function. Example of guards: * Type of a function parameter * Watch a dictionary key * Watch a function (especially it's __code__ attribute) Watching a dictionary key is a very important guard to disable an optimization when a builtin function is modified, when a function is replaced in a namespace, etc. The problem is that a dictionary lookup is not cheap: we have to get the hash value of the key, browse the hash table to find the bucket which may require multiple iterations, then we have to compare the key value, etc. To have faster guard, I propose to create a subtype of dict which provides a global "version" of the dictionary, incremented at each modification (create a new key, modify a key, delete a key) and a "version" per key=>value mapping, incremented each time that the mapping is modified. The lookup can be avoided when the dictionary is not modified. If a different key is modified, we need a lookup, but only once (we store the new global version to avoid a lookup at the next guard check). Limitations =========== Specialized bytecode is build at compilation, *not* at runtime: it's not a just-in-time (JIT) compiler. A JIT can implement even more efficient optimizations and can use better guards. Please continue to use PyPy for best performances! ;-) The name "FAT" comes from the fact that multiple bytecode versions of a function are stored in the memory, so a larger memory footprint and larger .pyc files on disk can be expected. Checking guards can also be more expensive than the optimization of the specialized bytecode. The optimizer should use an heuristic to decide if it's worth to use a specialized bytecode or not depending on the theoric speeup and the cost of guards. My motivation to write FAT Python is that CPython remains the reference implementation where new features are implemented, and other Python implementations still have issues with C extensions. JIT also has some issues, like longer startup time, slow warmup and memory footprint (this one may also be an issue of FAT Python!). Implementation ============== I wrote a proof-of-concept of my idea: https://hg.python.org/sandbox/fatpython/ It's a fork of CPython 3.6. Try it with: hg clone https://hg.python.org/sandbox/fatpython/ cd fatpython ./configure && make ./python -F See bench.py, Lib/posixpath.py (isabs) and Lib/test/test_fat.py for examples of optimizations. The command line -F flag enables the FAT mode. By default, *all* optimizations are disabled, there is a negligible overhead when the FAT mode is not used. In the FAT mode, the dictionary for modules, classes and instances becomes "versionned". Functions gets new methods to support adding specialized bytecode with guards. You can add manually a specialized bytecode for microbenchmarks, but functions are *not* optimized automatically. (See the Roadmap below.) How to write an optimizer? ========================== Currently, my proof-of-oncept is only the machinery to support adding specialized bytecodes with guards. The next step is to generate automatically these specialized versions. IMHO an optimizer should be implemented in Python and not in C, it's easier to write Python code. We can begin with simple optimizations on AST. See for example my astoptimizer which implements basic optimizations: https://bitbucket.org/haypo/astoptimizer/ At the beginning, we may use type hints (PEP 484) and other manual hints to help the optimizer. Later, a profiler learning the most common types of function parameters can be written for automatic optimizations. Example of hints: a list of constants which should not be modified in the application. A global "DEBUG" flag is common in applications, relying on DEBUG=False helps to remove dead code. Roadmap ======= * Finish the proof-of-concept: implement new guards, optimize method calls. For example, guards on module imports are required. Checking if a module is the expected mode can be tricky. * Write an optimizer based on manual hints * Write a profiler to generate hints Right now, my main question is if it will be possible and efficient to optimize classes, not only simple functions, especially classes defined in two different modules. I wrote a proof-of-concept of optimized method (with inlining), but I'm not sure yet that it's safe (don't change Python semantic). For more information on FAT Python, read: https://hg.python.org/sandbox/fatpython/file/tip/FATPYTHON.rst So, what do you think? Do you expect real speedup on applications, not only on microbechmarks? Do you know similar optimizations in other scripting languages? Victor Stinner [View Less]

11 23

PEP-505: Draft (Coalescing Operators)
by Mark E. Haase Oct. 22, 2015

Oct. 22, 2015

I've finally finished a reasonably complete draft of PEP-505. It's taken me longer than I expected due to work and also a new addition to our family :) I tried to keep the PEP humorous; but please don't mistake silliness for a lack of seriousness. Let's try to keep separate two different debates: (1) the utility of the proposed operators (2) how to spell them. Arguing about #2 is a waste of time if #1 is a non-starter. If we can achieve some consensus on #1, then with Guido's consent, I think … [View More]

2 2

Discussion about a 'xor' keyword?
by Emanuel Barry Oct. 18, 2015

Oct. 18, 2015

You've probably read this title with skepticism. I know I would. As the title says. I am curious as to engage in the discussion, and see what everyone's thoughts are on it. I know this has been discussed in the past several years ago ( https://mail.python.org/pipermail/python-3000/2007-December/011560.html ) and on various websites already. I've found myself writing code that would be simpler with a xor keyword or similar syntax, and this is why I'm suggesting this. Here are my thoughts: Since '… [View More]

7 12

Add appdirs module to stdlib
by Philipp A. Oct. 18, 2015

Oct. 18, 2015

When defining a place for config files, cache files, and so on, people usually hack around in a OS-dependent, misinformed, and therefore wrong way. Thanks to the tempfile API we at least don’t see people hardcoding /tmp/ too much. There is a beautiful little module that does things right and is easy to use: appdirs <https://pypi.python.org/pypi/appdirs> TI think this is a *really* good candidate for the stdlib since this functionality is useful for everything that needs a cache or … [View More]

21 31

Rosetta Code on Python.org site?
by Paddy3118 Oct. 16, 2015

Oct. 16, 2015

Just saw what the Perl 6 site does to punt the curious to their entries on the Rosetta Code site here: http://perl6.org/community/rosettacode and I thought maybe we could do something similar on Python.org? I know that the core development team of Perl 6 have put a lot of effort into their RC entries, and over the years I have seen evidence of tasks being used to highlight areas for subsequent improvement in Perl 6. I don't *recognise *such a contribution from core development … [View More]

8 8

Simpler syntax for basic iterations
by Andre Roberge Oct. 15, 2015

Oct. 15, 2015

Summary: Visual environments based on using simple functions without using variables have been found to be useful to introduce programming concepts to young learners. While Python is an ideal language for beginners, the Python construct for iterations, namely for var in range(n): # block # of # code does require a variable and is needlessly complicated for beginners. A simpler construct like: repeat n: # n is a specific integer # block # of # code would be … [View More]useful to have in such contexts. Other keywords could be chosen instead of "repeat" used above. ==== For young (and perhaps not so young) students visual environments are an ideal choice to learn programming. A well-known example of a visual environment for beginners is Karel the Robot, invented by Richard Pattis in 1981. In this environment, a robot can perform a limited number of basic functions which can be combined to create complex tasks. In the original Karel the Robot, variables were not allowed. However, new procedures could be created. One essential concept that can be demonstrated in such worlds is that of iterations. In the original Karel, this was done using the following syntax: ITERATE n TIMES single_instruction or ITERATE n TIMES BEGIN single_instruction; other_instruction; END where "n" is a specific integer. In the above, indentation has been introduced only to make the code easier to read. A popular Python-like implementation of Pattis' idea is Guido van Robot [1], also known as GvR. In GvR, iteration is done as follows: do n: # block # of # code indented like Python To do something equivalent in Python requires to use: for var in range(n): # block # of # code which requires to use variables, which are not part of the original Karel the Robot philosophy, as well as an additional builtin function. I would argue that, for beginners, this is needlessly complicated. A better alternative would be to use a similar syntax to that used by Guido van Robot for this case. This would require to either introduce a new keyword (such as "do", "repeat", "iterate", or "loop") repeat n: # block # of # code An advantage of using one of these keywords would be for easier readability (for English speakers). The disadvantage is that some existing Python programs might use variables with the names suggested above. An alternative would be to reuse the "for" keyword by adding this new construct to the grammar: for n: # block # of # code This last choice, while perhaps not as immediately readable to English speakers as some of the previous ones, would have the advantage of not requiring any change to any existing Python programs; it could thus be implemented rather quickly without needing some transition time and the use of the __future__ module. There exists at least 4 different pure Python implementations of Karel the Robot where this new construct could, in principle, be immediately put to use: RUR-PLE [2], Rurple NG [3], both of which are desktop versions, Reeborg's World [4], a web version using Brython as a Python interpreter, and Monty Karel [5], an Eclipse plugin which is targeted at older students as it uses a not so simple OOP syntax even for the simplest programs. Young learners using any of the first three such implementations would likely benefit if they could learn programming first using this simpler construct. André Roberge [1] Guido van Robot: http://gvr.sourceforge.net/documents/languageRef/gvr.html [2] RUR-PLE: https://code.google.com/p/rur-ple/ [3] Rurple NG: http://www.lshift.net/downloads/dev.lshift.net/paul/rurple/manual.html [4] Reeborg's World documentation: http://reeborg.ca/docs/en/index.html World itself: http://reeborg.ca/world.html Python tutorial: http://reeborg.ca/docs/begin_py_en/ [5] Monty Karel: http://www.csis.pace.edu/~bergin/MontyKarel/MontyInEclipse.html [View Less]

16 41

Proposal how to remove all occurrences of a value from a Python list
by Eduard Bondarenko Oct. 10, 2015

Oct. 10, 2015

Hello everyone, the main idea of this proposal is to create convenient, maybe more Pythonic way to remove all occurrences of a value from a Python list. Suppose we have list 'arr': arr = [1, 2, 3, 1] and we want to remove all 1 from this list. The most Pythonic way to do it is: arr[:] = (x for x in arr if x != 1) Looks good, at least for experienced developer, but for Python's newcomers solution will look like this: >>> while True: ... try: ... a.remove(1) ... … [View More]

11 15