Python-ideas February 2010

python-ideas@python.org

45 participants
14 discussions

by spir

Hello, I recently realized the following, and wonder whether there is a reason for this, which I am unable to figure out. A list comp can both map and filter: [x*x for x in numbers if x%2==1] When it only maps, we can simply get rid of the filter part: [x*x for x in numbers] Meaning we are not forced to write: [x*x for x in numbers if True] But the analog does not apply to filter-only list comps: [x in numbers if x%2==1] # SyntaxError Why? I find this syntax clear, actually clearer than [x for x in numbers if x%2==1] that confusingly repeats the item. Would there be any parsing issue if we let down "<expression> for" when it does nothing? Side note: I find the core part of a comprehension be "<item> in <collection>": [item in collection] would be equivalent to list(collection). (item in collection) would just build an iterator on collection. From this POV, this core can be preceded by a mapping expression and/or followed by a filtering condition. Denis -- ________________________________ la vita e estrany spir.wikidot.com

10 years, 7 months

op-assign in function argument

by wxyarv

has anybody thought the op-assign in function argument is a good idea? now we can use parameter name to specifie argument, like this: def foo(arg1): pass # call foo(arg1 = "bar") but, if function has default parameter, it will be inconvenience: def foo_with_long_defualts(arg1 = we | are | default | flags | set): pass # call foo_with_long_defaults(arg1 = we | are | default | flags | set | another_flags) so, why not add op-assign support in named argument? foo_with_long_defaults(arg1 |= another_flags) are there anybody has the same idea with me?

10 years, 7 months

warnings package might provide an Option or a pre-filled OptionParser

by Masklinn

Currently, `warnings` uses the `-W` interpreter-level option for non-programmatic configuration. While nice, this option isn't available out of the box to scripts where the interpreter is implicit (./script.py, or `script` where it's on $PATH). I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling, without having to define custom option actions every time. What do you think?

10 years, 7 months

Merging a generator's "next" and "send" methods?

by Andrey Fedorov

Since .next() seems to be equivalent to .send(None), why wasn't .next() just given an optional parameter which defaults to None? - Andrey On Thu, Oct 1, 2009 at 1:10 PM, Simon Forman <sajmikins(a)gmail.com> wrote: > On Wed, Sep 30, 2009 at 4:24 PM, Andrey Fedorov <anfedorov(a)gmail.com> > wrote: > > As far as I can tell, a generator's .next() is equivalent to .send(None). > Is > > this true? > > They are equivalent AFAIK. > > > If so, [why] aren't they unified in a method with a single argument which > defaults > > to None? > > - Andrey > > next() predates send(). >

10 years, 7 months

Merge .pyc into .pyo--store multiple code objects in one file?

by Larry Hastings

A .pyc file is made up of these three elements: 4 byte magic number 4 byte timestamp marshaled code object A .pyo file is the same except the code object has been optimized. I ask you: why gunk up the filesystem with two files when one would do? I propose we change the pyc file so it can contain multiple code objects. Or, indeed, multiple arbitrary objects. The .pyc file could become as a general-purpose cache for data relevant to the .py file. For example, perhaps the Unladen Swallow guys could cache post-JITted code. Or the wordcode-based interpreter could cache its wordcode equivalent. Lots of implementation choices suggest themselves. Here's the cheapest approach that seems suitable: 4 byte magic number 4 byte timestamp marshaled array of pairs of ints, alternating "id of object" with "relative offset of object from the end of this marshaled array" marshaled code object 1 marshaled code object 2 ... If you look for your cached object inside and it's not there, you compute your object then rewrite the file adding your id and offset to the end of the array. (Your offset will always be the former size of the file.) If the timestamp has changed, blow away all objects and start over with an empty array. If it'd be too disruptive to change .pyc/.pyo files this way, would switching to a new file extension be better? I suspect this probably isn't actually a good idea, /larry/

10 years, 7 months

Re: [Python-ideas] clear() method for lists

by wxyarv

what about another method clone() (or copy())? i think this maybe useful either. ------------------ Original ------------------ From: "average"<dreamingforward(a)gmail.com>; Date: Mon, Feb 8, 2010 09:14 AM To: "Gerald Britton"<gerald.britton(a)gmail.com>; Cc: "Python-Ideas"<python-ideas(a)python.org>; Subject: Re: [Python-ideas] clear() method for lists On Fri, Feb 5, 2010 at 1:39 PM, Gerald Britton <gerald.britton(a)gmail.com> wrote: > In the list archives, this thread > discusses adding a clear() method to list objects, to complement those > available for sets and dictionaries. Later in the thread: > Christian Heimes provided a patch to do it and R. H. commented that > all it would take is Guido's blessing. > > So, I'm wondering, can we do this? What are the steps needed to ask > this work to be blessed? In the abstract it seems like such a method should be part of the Container ABC. Since the idea of a container would imply a method to clear its contents. mark _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org http://mail.python.org/mailman/listinfo/python-ideas

10 years, 7 months

itertools has starmap but no starreduce?

by Andrey Fedorov

Is that right, or am I missing something obvious?

10 years, 7 months

clear() method for lists

by Gerald Britton

In the list archives, this thread http://mail.python.org/pipermail/python-ideas/2009-April/003897.html discusses adding a clear() method to list objects, to complement those available for sets and dictionaries. Later in the thread: http://mail.python.org/pipermail/python-ideas/2009-April/003933.html Christian Heimes provided a patch to do it and R. H. commented that all it would take is Guido's blessing. So, I'm wondering, can we do this? What are the steps needed to ask this work to be blessed? -- Gerald Britton

10 years, 7 months

Re: [Python-ideas] [Python-Dev] Proposal for the getpass module

by Tarek Ziadé

2010/2/7 Lennart Regebro <regebro(a)gmail.com>: [..] > > Having getpass calling the keyring module seems backwards to me. It > should rather be the keyring module that calls getpass, if needed. I think you are right, the getpass module should be considered as one way to get a password. Regards, Tarek -- Tarek Ziadé | http://ziade.org

10 years, 7 months

Re: [Python-ideas] [Python-Dev] Proposal for the getpass module

by Guido van Rossum

[redirecting to python-ideas] On Sat, Feb 6, 2010 at 4:08 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > Hello, > > I would like to propose a small change in the getpass module so it's > able to get passwords from keyrings (like KWallet, Keychain, etc) > > The idea is to provide a getpass.cfg configuration file where people > can provide the name of a function to use when getpass is called. > Then third-party projects can implement this function. For example the > Python Keyring library.[1] could be installed and configured to be > used by people that wants getpass calls to be handled by this tool. > > That's a backward compatible change, and it avoids adding any new > module in the stdlib. Plus, it offers a greatly improved getpass > module with no risks for the stdlib stability : it becomes a reference > implementation with an interface for third-party implementers. > > A prototype is here : http://bitbucket.org/tarek/getpass/ (work in > progress but you can get the idea) > > [1] http://pypi.python.org/pypi/keyring Don't you usually have to tell the keyring which password to retrieve? The signature for getpass() doesn't have enough info for that. I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function. -- --Guido van Rossum (python.org/~guido)

10 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas February 2010