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

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

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

A nice __repr__ for the ast.* classes?
by Haoyi Li Nov. 19, 2013

Nov. 19, 2013

Wouldn't it be nice if this >>> import ast >>> print repr(ast.parse("(1 + 1)").body[0].value) <_ast.BinOp object at 0x0000000001E94B38> printed something more useful? >>> print repr(ast.parse("(1 + 1)").body[0].value) BinOp(left=Num(n=1), op=Add(), right=Num(n=1)) I've been doing some work on macropy <https://github.com/lihaoyi/macropy>, which uses the ast.* classes extensively, and it's annoying that we have to resort to dirty-tricks like monkey-… [View More]

5 5

Gzip and zip extra field
by Serhiy Storchaka Nov. 17, 2013

Nov. 17, 2013

Gzip files can contains an extra field [1] and some applications use this for extending gzip format. The current GzipFile implementation ignores this field on input and doesn't allow to create a new file with an extra field. ZIP file entries also can contains an extra field [2]. Currently it just saved as bytes in the `extra` attribute of ZipInfo. I propose to save an extra field for gzip file and provide structural access to subfields. f = gzip.GzipFile('somefile.gz', 'rb') f.… [View More]

3 4

Stdlib YAML evolution (Was: PEP 426, YAML in the stdlib and implementation discovery)
by anatoly techtonik Nov. 14, 2013

Nov. 14, 2013

FWIW, I am +1 on for the ability to read YAML based configs Python without dependencies, but waiting for several years is hard. Maybe try an alternative data driven development process as opposed to traditional PEP based all-or-nothing style to speed up the process? It is possible to make users happy incrementally and keep development fun without sacrificing too much on the Zen side. If open source is about scratching your own itches, then the most effective way to implement a spec would be to … [View More]allow people add support for their own flavor without disrupting works of the others. For some reason I think most people don't need full YAML speccy, especially if final implementation will be slow and heavy. So instead of: import yaml I'd start with something more generic and primitive: from datatrans import yamlish Where `datatrans` is data transformation framework taking care of usual text parsing (data partitioning), partition mapping (structure transformation) and conversion (binary to string etc.) trying to be as fast and lightweight as possible, bringing vast field for future optimizations on algorithmic level. `yamlish` is an implementation which is not vastly optimized (datatrans to yamlish is like RPython to PyPy) and can be easily extended to cover more YAML (hopefully). Therefore the name - it doesn't pretend to parse YAML - it parses some supported subset, which is improved over time by different parties (if datatrans is done right to provide readable (maintainable + extensible) code for implementation). There is an exisiting package called `yamlish` on PyPI - I am not talking about it - it is PyYAML based, which is not an option for now as I see it. So I stole its name. Sorry. This PyPI package was used to parse TAP format, which is again, a subset. Subset.. It appears that YAML is good for humans for its subsets. It leaves an impression (maybe it's just an illusion) that development work for subset support can also be partitioned. If `datatrans` "done right" is possible, it will allow incremental addition of new YAML features as the need for them arises (new data examples are added). Or it can help to build parsers for YAML subsets that are intentionally limited to make them performance efficient. Because `datatrans` is a package isolating parsing, mapping and conversion parts of the process to make it modular and extensible, it can serve as a reference point for various kinds of (scientific) papers including the ones that prove that such data transformation framework is impossible. As for `yamlish` submodule, the first important paper covering it will be a reference table matrix of supported features. While it all sounds too complicated, driving development by data and real short term user needs (as opposed to designing everything upfront) will make the process more attractive. In data driven development, there are not many things that can break - you either continue parsing previous data or not. The output from the parsing process may change over time, but it may be controlled by configuring the last step of data transformation phase. `Parsing AppEngine config file` or `reading package meta data` are good starting points. Once package meta data subset is parsed, it is done and won't break. The implementation for meta data parsing may mature in distutils package, for AppEngine in its SDK, and merged in either of those, sending patches for `datastrans` to stdlib. The question is only to design output format for the parse stage. I am not sure everything should be convertible into Python objects using the "best fit" technique. I will be pretty comfortable if target format will not be native Python objects at all. More than that - I will even insist to avoid converting to native Python object from the start. The ideal output for the first version should be generic tree structure with defined names for YAML elements. The tree that can be represented as XML where these names are tags. The tree can be therefore traversed and selected using XPath/JQuery syntax. It will take several years for implementation to mature and in the end there will be a plenty of backward compatibility matters with the API, formatting and serializing. So the first thing I'd do is [abandon serialization]. From the point of view of my self-proclaimed data transformation theory, the input and output formats are data. If output format is not human readable - as some linked Python data structures in memory - it wastes time and hinders development. Serializing Python is a problem of different level, which is an example of binary, abstract, memory-only output format - a lot of properties that you don't want to deal with while working with data. To summarize: 1. full spec support is no goal 2. data driven (using real world examples/stories) 3. incremental (one example/story at a time) 4. research based (beautiful ideas vs ugly real world limitations) 5. maintainable (code is easy to read and understand the structure) 6. extensible (easy to find out the place to be modified) 7. core "generic tree" data structure as an intermediate format and "yaml tree" data structure as a final format from parsing process P.S. I am willing to wok on this "data transformation theory" stuff and prototype implementation, because it is generally useful in many areas. But I need support. -- anatoly t. [View Less]

9 12

Support os.path.join for Windows paths on Posix
by Ryan Gonzalez Nov. 2, 2013

Nov. 2, 2013

The recent thread/post/whatever on os.path.join has gotten me thinking. Say I wanted to join a Windows path...on Ubuntu. This is what I get: ryan@DevPC-LX:~$ python Python 2.7.3 (default, Sep 26 2013, 20:03:06) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.join('C:\\', 'x.jpg') 'C:\\/x.jpg' >>> Isn't something wrong there? My idea: check for \'s in the path. If there are any, assume \ is the … [View More]

9 14

Where did we go wrong with negative stride?
by Guido van Rossum Nov. 2, 2013

Nov. 2, 2013

In the comments of http://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing… were some complaints about the interpretation of the bounds for negative strides, and I have to admin it feels wrong. Where did we go wrong? For example, "abcde"[::-1] == "edcba" as you'd expect, but there is no number you can put as the second bound to get the same result: "abcde"[:1:-1] == "edc" "abcde"[:0:-1] == "edcb" but "abcde":-1:-1] == "" I'm guessing it all comes from the semantics I … [View More]

33 135

Allow attribute references for decimalinteger
by אלעזר Nov. 1, 2013

Nov. 1, 2013

There's an unnecessary corner case regarding integer literals and attributes: >>> 1..real 1.0 >>> 1.0.real 1.0 >>> 1..real 1.0 >>> 1. .real 1.0 >>> .1.real 0.1 >>> 1 .real 1 >>> (1).real 1 >>> 1.real File "<stdin>", line 1 1.real ^ SyntaxError: invalid syntax Why does it fail? To my human eyes it seems (almost) completely unambiguous. Is it a lexing thing? I couldn't find an explanation (or any … [View More]

8 14

Can you explain me why that is a bad idea?
by neuro Oct. 25, 2013

Oct. 25, 2013

I wrote to Guido on twitter this question Can you add this construction for c in list if condition : suite when suite block very big for list comprehension This is Guido answer: Someone on python-ideas(a)python.org can probably explain why that is a bad idea. Can you explain me why that is a bad idea? with best regards, Abu Sultanov

4 3

A different kind of context manager
by Kristján Valur Jónsson Oct. 25, 2013

Oct. 25, 2013

Hello there! This is a rehash of something that I wrote on stackless-dev recently. Perhaps this has been suggested in the past. If so, please excuse my ignorance. It irks me sometimes how inflexible context managers can be. For example, wouldn't it be nice to be able to write with as_subprocess(): do_stuff() or in StacklessPython: with different_tasklet(): do_stuff() This is currently impossible because context managers are implemented as __enter__()/__exit__() methods running in … [View More]the current scope. There is no callable function site to pass ot a subprocess module, or a tasklet scheduler. I have another favorite pet-peeve, which is that for some things, a pair of context managers are needed, since a single context manager cannot silence it's own exception: with IgnoreError, LockResourceOrRaiseIfBusy(resource): do_stuff cannot be collapsed into: with LockResourceOrPassIfBusy(resource): do_stuff. But another thing is also interesting: Even though context managers are an __enter__() / __exit__() pair, the most common idiom these days is to write: @contextlib.contextmanager def mycontextmanager(): setup() try: yield finally(): teardown() or similar. There are a million reasons for this. Mostly it is because this layout is easier to figure out and plays nicer in the head. It also simplifies error handling, because regular try/except clauses can be used. If you are writing a "raw" context manager, you have to explicitly maintain some state between the __enter__() and __exit__() methods to know what to clean up and how, depending on the error conditions. This quickly becomes tedious. And what does the above code look like? Well, the place of the "yield", could just as well be a call site. I mean, the decorated "contextmanager" function simply looks like a wrapper function around a function call. You write it exactly as you would write a wrapper function ,except where you would call the function, you use the "yield" statement (and you _have_ to call yield. Can't skip it for whatever reason). So, If this is the way people like to think about context managers, like writing wrapper functoins, why don't we turn them into proper wrapper functions? What if a context manager were given a _callable_, representing the code? like this: class NewContextManager(object): # A context manager that locks a resource, then executes the code only if it is not recursing def __init__(self, lock): self.lock = lock def __contextcall__(self, code): with lock: if lock.active: return # This is where @contextmanager will stop you, you can't skip the 'yield' lock.active = True try: return code(None) # optionally pass value to the code as in "with foo() as X" finally: lock.active = False The cool thing here though, is that "code" could, for example, be run on a different tasklet. Or a different thread. Or a different universe: def TaskletContextManager(object): def __contextcall__(self, code): return stacklesslib.run_on_tasklet(code) def ThreadContextManager(object): def __contextcall__(self, code): result = [] def helper(): result.append(code()) t = threading.Thread(target=helper) t.start() t.join() return result[0] This sort of thing would need compiler and syntax support, of course. The compiler would need to create an anonymous function object. The return value out of "code" would be some token that could be special if the code returned.... To illustrate, let's see how this can be done manually: This code here: with foo() as bar : if condition: return stuff do_stuff(bar) can be re-written like this: def _code(_arg): bar = _arg if condition: return True, stuff # early return do_stuff(bar) return False, None # no return token, value = foo(bar).__contextcall__(_code): if token is True return value where: class foo(object): def __init__(self, arg): self.arg = arg def __contextcall__(self, _code): set_up() try: return _code(None) #pass it some value finally: tear_down() Compiler support for this sort of thing would entail the automatic creation of the "_code" function as an anonymous function with special semantics for a "return" value. This function is then passed to the __contextcall__() method of the "new" context manager, where the context manager treats it as any other callable, which' return value it must return. The "early return" can also be done as a special kind of exception, ContextManagerReturn(value). So, anyway. Context manager syntax is really nice for so many reasons, which is why we have it in the language, instead of wrapper functions. But if it _were_ just syntactic sugar for actual wrapper functions, they would be even awesomer. K [View Less]

11 24

Fwd: YAML (yet-another-multiline-lambda)
by Antony Lee Oct. 25, 2013

Oct. 25, 2013

Sorry Stephen, forgot to reply-to-all the first time. Antony 2013/10/24 Stephen J. Turnbull <stephen(a)xemacs.org> > Antony Lee <anntzer.lee(a)gmail.com> writes: > >>>>> 2013/10/24 Stephen J. Turnbull <stephen(a)xemacs.org> > > > I think you've misunderstood the aim of my proposal. > > No, I misunderstood the language in your most recent post, not to > mention the consistent mis-specification of the whole idea in *every* > subject … [View More]line. Python doesn't currently have a notion of "binding" > lambdas to objects, and you here don't specify how a lambda (object) > is being "bound" to what (other kind of) object. Python does have a > notion of binding names to objects. Confusion is natural. > > If you're *primarily* talking about defining functions in the "right > place" in general, what's wrong with using the well-defined Python > terms for those objects? > To me, in the context of Python, the words lambda and function have the same meaning at the object representation level (an object of type types.FunctionType (== types.LambdaType)), the only difference coming at the syntactic level: a lambda is defined in an expression, a function is defined in a statement. Thus the name "multi-line lambda" (and it made a nice acronym in the title, sure). But if you prefer, you can replace "multi-line lambda" by "function defined by multi-line expression" everywhere. > > > Specifically, I was asking his to clarify the relevance of such an > > issue as a locally defined lambda (etc.) already captures "self" > > without the need for a call to a JS-like bind (which is effectively > > spelled __get__ in Python). > > Sure. So there is no "need" in the first place. I don't understand > what you're talking about. IMO Nick's use case, described next, is > compelling. Why not just say "this syntax does the trick for that use > case"? Are you saying anything else? That's what I can't figure out. > I am trying to answer the issue Andrew raised: > I don't think this idea will fit well with Python's OO. > > Partly this is based on JS experience, where you have to write .bind(this) > all over the place because your callback--or, worse, some callback later in > the chain--needs access to this. > Like it or not, to discuss this argument, I need to discuss the need to write ".bind(this)", or, in Python-speak, create bound(!) methods out of "functions defined by multi-line expressions". In fact, if I understood you well, you seem to agree that it doesn't actually apply to this proposal. > > > Just look at the other currently active thread on context manager > > semantics, where Nick Coghlan said > > >> it *also* means that we *don't* currently have a clean syntax for > >> single use callbacks. > > > Another example is when you want to provide a dictionary of > > callbacks (e.g. to be triggered by various command line options), > > say at global scope, without putting the callbacks themselves in > > that scope). > > Eh, "there you go again." That's the same example, isn't it? It's a > good one and stands repeating, but it's not different. In both cases > you have a callback and a desire to put the def in an appropriate > "place" (namespace, and often lexical position in the source). The > dictionary of callbacks idiom is familiar (at least to those of us to > have the misfortune to program with Xt), and I certainly understand > the desire to define callbacks in an appropriate scope. Again, do you > have *more* to say than "I think my syntax does this nicely, > concisely, and precisely"? > If I put my function definition in an expression, the point is of course to use it "in the appropriate place", so this wording more or less covers every use I can think of. But perhaps you can consider the following use case as "different enough". If we had this feature, we could probably have done without the "with" statement: with open(name) as f: ... ===> opening(name, (def func(f): ...)) # define a new "opening" function or open(name, do_and_close=(def func(f): ...)) # add a kwarg to "open" with lock: ... ===> lock.acquiring(def func(): ...) # define a new "acquiring" method While I certainly consider the "with" statement to be extremely useful, and nicer for such use cases, I simply doubt that new syntax would have been added at all if this construct was available. Of course one may consider this as a non-argument as we have the "with" statement now and it's not going away (which is a good thing). > If you have other compelling use cases, that would be useful. But I > think the "defining callbacks in the right place" use case would be > enough to get this proposal in Python 3.5 (if it stands up to issues > like the LL constraint on the languages, and the objection to > YAAP[1]). Mixing this up with "lambda" and "binding" is unhelpful > AFAICS. > I'm certainly no expert on parsing but this proposal was certainly designed to be (relatively) simple to parse: instead of having just having one stack of indentation levels, keep a stack of such stacks. When encountering a "def" token, check that the last token was a parenthesis (or perhaps brackets and curly braces too... although I don't think using lambdas as dict keys in a good idea at all :-)), and if so, start parsing the inline def as if it was at toplevel, using a new stack of indent levels. As for the abuse of parentheses [1], note that in the most common case (I would guess) of passing a single inline function (or whatever you want to call it) to another function, the function call itself already provides these parentheses so there is no need of adding another level of parentheses. > > > I don't think abusing the class statement is particularly elegant > > either (and good luck if you want to preserve order... what, I have > > to provide a metaclass that overrides __prepare__ for doing this?), > > I doubt you need to use a metaclass (storing the callbacks in an > OrderedDict and then defining an appropriate __index__ can probably be > done with a decorator or two), but the alternatives are hardly > prettier I guess. > > > Footnotes: > [1] Yet Another Abuse of Parentheses, also spelled "YAAPMILL" > ("... Making It Like LISP"). > > [View Less]

1 0

YAML (yet-another-multiline-lambda)
by Antony Lee Oct. 25, 2013

Oct. 25, 2013

As the issue has been (indirectly) raised again in the recent context manager thread, I would like to propose yet another syntax for multiline lambdas... I know there has been many but I (foolishly?) hope this one is simpler. I do not wish to focus on the usual arguments for and against the usefulness of such a construct (from the archives of the list, I feel that the lack of an attractive syntax is the bigger barrier). Specifically, I suggest that the "def" (and possibly the "class") … [View More]

11 21

Mini language prototype... possibilities?
by Ron Adam Oct. 23, 2013

Oct. 23, 2013

There was some interest here in the little language experiment I mentioned in another thread, so I'm posting a google project link here for those who might be interested in taking a look at it. http://code.google.com/p/metap/ It's just a toy at this stage written in python, but some people here might be interested in playing around with it. I don't think we should take up too much space on this board until there is at least a proof of concept for anything derived from it. It's way … [View More]too general and preliminary an idea to be a serious suggestion at this stage. It's ok to email me directly. Here's what it's about in general... The idea that prompted this is my feelings that pythons byte code could be a bit higher level, and that there may be some advantages to doing that. The experiment was to see what it might look like if instead of a stack based byte code, it was a list based object code. What I ended up with is very near scheme with better support for programming in a more explicit imperative style (more like python), while still keeping both the parser and eval loop very small and simple. Example python code ... >>> def fact(n): ... r = n ... while n > 1: ... n -= 1 ... r *= n ... return r ... >>> fact(3) 6 The byte code ... >>> dis.dis(fact) 2 0 LOAD_FAST 0 (n) 3 STORE_FAST 1 (r) 3 6 SETUP_LOOP 36 (to 45) >> 9 LOAD_FAST 0 (n) 12 LOAD_CONST 1 (1) 15 COMPARE_OP 4 (>) 18 POP_JUMP_IF_FALSE 44 4 21 LOAD_FAST 0 (n) 24 LOAD_CONST 1 (1) 27 INPLACE_SUBTRACT 28 STORE_FAST 0 (n) 5 31 LOAD_FAST 1 (r) 34 LOAD_FAST 0 (n) 37 INPLACE_MULTIPLY 38 STORE_FAST 1 (r) 41 JUMP_ABSOLUTE 9 >> 44 POP_BLOCK 6 >> 45 LOAD_FAST 1 (r) 48 RETURN_VALUE That's pretty low level. If we go to a list based model where instructions are nested lists of symbols and names, and give it better access to the frames name space, it may look like the following. Example list based code... 1 DEF "fact n" 3 [ 3.1 LET r n 3.4 LOOP 3.5 [ 3.5.1 IF (> n 1) 3.5.3 [ 3.5.3.1 BREAK ] 3.5.4 DEC n 3.5.6 LET n (* r n) ] 4 RETURN r ] That's almost python, but not quite. (Seems like a good thing to me.) It's still very simple and easy to parse by an eval loop. It's just nested sequences of symbols and names. As it turns out, this simple language would be right between python and scheme. Scheme code can be compiled to efficient C code on a wide variety of platforms including android, and i-phone. I think that may offer some interesting possibilities. I just don't want to write applications in scheme. ;-) Cheers, Ron [View Less]

1 0

'from os.path import FILE, DIR' or internal structure of filenames
by anatoly techtonik Oct. 22, 2013

Oct. 22, 2013

FILE = os.path.abspath(__file__) DIR = os.path.abspath(os.path.dirname(__file__)) ? Repeated pattern for referencing resources relative to your scripts. Ideas about alternative names / locations are welcome. In PHP these are __FILE__ and __DIR__. For Python 3 adding __dir__ is impossible, because the name clashes with __dir__ method (which is not implemented for module object, but should be [ ] for consistency). Also current __file__ is rarely absolute path, because it is never normalized [ ].… [View More]

8 14

Enum and random.choice
by Antony Lee Oct. 21, 2013

Oct. 21, 2013

random.choice and Enum interact poorly, because indexing an enum class doesn't work as choice expects: >>> import enum, random >>> class C(enum.Enum): a, b = 1, 2 ... >>> random.choice(C) <traceback...> KeyError: 1 Of course one can do `random.choice(list(C.__members__.values()))` but this feels a bit awkward. The source for random.choice is def choice(self, seq): """Choose a random element from a non-empty sequence.""" try: i = self.… [View More]

3 3

Python 3.4 should include docopt as-is
by anatoly techtonik Oct. 21, 2013

Oct. 21, 2013

This - http://docopt.org/ - should be included with Python 3.4 distribution. -- anatoly t.

11 13

PyPi per-file download counters
by Giampaolo Rodola' Oct. 21, 2013

Oct. 21, 2013

I recently moved psutil .tar.gz and .exe files from Google Code to PyPi and noticed it doesn't show total per-file download counters: https://pypi.python.org/pypi?:action=display&name=psutil#downloads Why don't we add them? Thoughts? --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/

2 2

Another "little" combination, permutation, iterator, yield from, example.
by Ron Adam Oct. 18, 2013

Oct. 18, 2013

On 10/13/2013 02:02 PM, Tim Peters wrote:> [MRAB, posts a beautiful solution] > > I don't really have a use for this, but it was a lovely programming > puzzle, so I'll include an elaborate elaboration of MRAB's algorithm > below. And that's the end of my interest in this;-) A what the heck... :-) This is what I came up with which works like MRAB's by removing the first element and using recursion on the rest. (It's how you do it in lisp or scheme.) It's just two … [View More]

4 7

Extremely weird itertools.permutations
by Neil Girdhar Oct. 17, 2013

Oct. 17, 2013

"It is universally agreed that a list of n distinct symbols has n! permutations. However, when the symbols are not distinct, the most common convention, in mathematics and elsewhere, seems to be to count only distinct permutations." — http://stackoverflow.com/questions/6534430/why-does-pythons-itertools-permu…. Should we consider fixing itertools.permutations and to output only unique permutations (if possible, although I realize that would break code). It is completely non-obvious to … [View More]

18 56

pytaint: taint tracking in python
by Felix Gröbert Oct. 17, 2013

Oct. 17, 2013

Hi, I'd like to start a discussion on adding a security feature: taint tracking. As part of his internship, Marcin (cc) has been working on a patch to cpython-2.7.5 which is available online. We also published a design document and slides. https://github.com/felixgr/pytaint The idea behind taint tracking (or taint checking) is that we mark ('taint') untrusted data and prevent the programmer from using it in sensitive places (called sinks). A standard use case would be in a web application, … [View More]

9 15

Fwd: Extremely weird itertools.permutations
by David Mertz Oct. 15, 2013

Oct. 15, 2013

What would you like this hypothetical function to output here: >>> from itertools import permutations >>> from decimal import Decimal as D >>> from fractions import Fraction as F >>> items = (3, 3.0, D(3), F(3,1), "aa", "AA".lower(), "a"+"a") >>> list(permutations(items)) It's neither QUITE equality nor identity you are looking for, I think, in nonredundant_permutation(): >> "aa" == "AA".lower(), "aa" is "AA".lower() (True, False) >>&… [View More]

9 36

An exhaust() function for iterators
by Clay Sweetser Oct. 12, 2013

Oct. 12, 2013

Currently, several strategies exist for exhausting an iterable when one does not care about what the iterable returns (such as when one merely wants a side effect of the iteration process). One can either use an empty for loop: for x in side_effect_iterable: pass A throwaway list comprehension: [x for x in side_effect_iterable] A try/except and a while: next = side_effect_iterable.next try: while True: next() except StopIteration: pass Or a number of other methods. The … [View More]

6 6