On Fri, Apr 22, 2016 at 1:19 AM, justin walters
wrote:
> I agree with the others that the new syntax is not needed.
>
> I would also like to point out that I believe any new added syntax or
> functionality should avoid the use of '*' and '**' as both of these
> characters are already used for many
I agree with the others that the new syntax is not needed.
I would also like to point out that I believe any new added syntax or
functionality should avoid the use of '*' and '**' as both of these
characters are already used for many things such as optional arguments and
mathematical operators. Ad
On Thu, 21 Apr 2016 05:34 am, Ken Seehart wrote:
> Currently the common pattern for yielding the elements in a sequence is as
> follows:
>
> for x in sequence: yield x
>
> I propose the following replacement (the result would be identical):
>
> yield *sequence
Others have already pointed o
On Thu, Apr 21, 2016 at 8:26 AM, wrote:
> Anyway, thanks for the link. And I suppose checking Python 3 for
> implementation would be a good prior step as well! Sadly, "yield from" is not
> in python 2.7, but it's presence in python 3.3 renders my proposal dead as a
> parrot without a liver.
>
On Wednesday, April 20, 2016 at 1:00:45 PM UTC-7, Ethan Furman wrote:
> On 04/20/2016 12:34 PM, Ken Seehart wrote:
>
> New ideas for Python are typically vetted on Python Ideas. [1]
>
> > Currently the common pattern for yielding the elements in a sequence
> > is as follows:
> >
> >for x in
Currently the common pattern for yielding the elements in a sequence is as
follows:
for x in sequence: yield x
I propose the following replacement (the result would be identical):
yield *sequence
imho the current syntax is much more intuitive, it is obvious to infer what it
does
by
On 04/20/2016 12:34 PM, Ken Seehart wrote:
New ideas for Python are typically vetted on Python Ideas. [1]
Currently the common pattern for yielding the elements in a sequence
> is as follows:
for x in sequence: yield x
I propose the following replacement (the result would be identical):
On Wed, Apr 20, 2016, at 15:34, Ken Seehart wrote:
> Currently the common pattern for yielding the elements in a sequence is
> as follows:
>
> for x in sequence: yield x
>
> I propose the following replacement (the result would be identical):
>
> yield *sequence
yield from sequence
--
http
On Sep 25, 2:24 pm, [EMAIL PROTECTED] wrote:
> Hi,
>
> sorry, I have these ideas for longer than 10 years, please have a look on it
> and comment on it. Thx.
>
>
>
> This is another proposal for introducing types into Python.
>
> There are many reasons for incorporating types into Python, but
On Fri, Sep 26, 2008 at 6:14 AM, <[EMAIL PROTECTED]> wrote:
> Typed parameters. Method-Declaration-filtered-typed parameters. That's what
> I'm thinking of.
Why do we need this (rubbish) ?
Seriously. The use-case is far too small.
And don't invent use-cases either.
Instead of coming up with idea
On Sep 25, 4:04 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió:
>
> > sorry, I have these ideas for longer than 10 years, please have a look
> > on it
> > and comment on it. Thx.
>
> > This is another proposal for introducing
[EMAIL PROTECTED] schrieb:
Gabriel Genellina wrote:
En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió:
sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.
This is another proposal for introducing types into Python.
You got the
[EMAIL PROTECTED] a écrit :
Gabriel Genellina wrote:
En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió:
sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.
This is another proposal for introducing types into Python.
You got the
On Sep 25, 12:24 pm, [EMAIL PROTECTED] wrote:
> def whoisthethief("List" x):
> return iknowit(x)
>
> def whoisthethief("String" x, "String" y):
> return iknowit([x,y])
>
I dunno if this is very Pythonic in nature, but I've done things like
rebinding methods dynamically.
ex:
>>> def test(a):
Gabriel Genellina wrote:
> En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió:
>
>> sorry, I have these ideas for longer than 10 years, please have a look
>> on it
>> and comment on it. Thx.
>>
>> This is another proposal for introducing types into Python.
>
> You got the terminolo
En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió:
sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.
This is another proposal for introducing types into Python.
You got the terminology wrong. Python had "types" from the very
James <[EMAIL PROTECTED]> writes:
> I would like to know your thoughts on a proposed change to optparse
> that I have planned. It is possible to add default values to
> multiple options using the set_defaults. However, when adding
> descriptions to options the developer has to specify it in ea
On Thu, Sep 18, 2008 at 9:02 PM, James Nicolson <[EMAIL PROTECTED]> wrote:
> Perhaps it is better to keep descriptions short and store longer
> descriptions elsewhere, but there are many programs that have long
> descriptions, for example try: ls --help (at least on my machine a lot
> of these desc
On 2008-09-18, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote:
>
>> While we're making suggestions, I've always wished that the --help
>> output displayed the default values for options in addition to the help
>> text specified by the u
On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote:
> While we're making suggestions, I've always wished that the --help
> output displayed the default values for options in addition to the help
> text specified by the user. I end up having to enter the default values
> twice -- once as a ke
Grant Edwards wrote:
While we're making suggestions, I've always wished that the
--help output displayed the default values for options in
addition to the help text specified by the user. I end up
having to enter the default values twice -- once as a keyword
argument and again in the help text.
While we're making suggestions, I've always wished that the
--help output displayed the default values for options in
addition to the help text specified by the user. I end up
having to enter the default values twice -- once as a keyword
argument and again in the help text. Then later when I deci
On Thu, 18 Sep 2008 03:37:54 -0700, James wrote:
> Hi,
>
> I would like to know your thoughts on a proposed change to optparse that
> I have planned. It is possible to add default values to multiple options
> using the set_defaults. However, when adding descriptions to options the
> developer has
James Mills wrote:
As you can see (as long as you're
reading this in fixed-width fonts)
it _is_ very readable.
given that it only relies on indentation from the left margin, it's no
less readable in a proportional font (unless you're using an font with
variable-width spaces, that is ;-).
Perhaps it is better to keep descriptions short and store longer
descriptions elsewhere, but there are many programs that have long
descriptions, for example try: ls --help (at least on my machine a lot
of these descriptions are quite long).
2008/9/18 James Mills <[EMAIL PROTECTED]>:
> Hi James,
>
Hi James,
I can't say I really agree with your
proposal. I tend to keep the help
descriptions of my options short
and concise and to the point.
Also, one must use the language's
features (indentation) to your advantage,
as doing so ensure readability.
For example (from my bhimport tool):
def p
26 matches
Mail list logo
