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
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?
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?
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().
>
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/
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
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
[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)
