Re: [Python-ideas] get() method for list and tuples

[Markus Meskanen]

Hi,

I'm still new here, but if my vote has any value then this gets a heavy -1
from me. It makes no sense to have to access exact i:th element of a list
without knowing if it exists, at least not in a scenario where checking
against the length or using an exception (say CSV row should have index 2
but doesn't) wouldn't be better.

I might've missed a message or two, but unless someone can provide a real
example where get() has an actual use case, I see no reason to argue over
this.

- Markus
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Thank's for your confirmation.

[Yander Martinez]

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Erik]

On 03/03/17 19:02, Alexandre Brault wrote:

I believe what Matthias is hoping for is an equivalent of Java's named
break feature. Breaking out of an outer loop implicitly breaks out of
all inner loops


Yes, and although I think making this a runtime object is an interesting 
thought (in terms of perhaps allowing other funky stuff to be 
implemented by a custom object, in line with Python's general dynamic 
ethos), I think that it should perhaps be considered a lexer/parser 
level thing only.


* Creating a real object at runtime for each loop which needs to be the 
target of a non-inner break or continue is quite a large overhead. How 
would this affect Python variants other than CPython?


* For anything "funky" (my words, not yours ;)), there needs to be a way 
of creating a custom loop object - what would the syntax for that be? A 
callable needs to be invoked as well as the name bound (the current 
suggestion just binds a name to some magical object that appears from 
somewhere).


* If nothing "funky" needs to be done then why not just make the whole 
thing syntax-only and have no real object, by making the 'as' name a 
parser-only token which is only valid as the optional subject of a break 
or continue statement:


for foo in bar as LABEL:
. # (a)
.
for spam in ham:
.
.
if eggs(spam):
continue LABEL
.
.
if not frob(spam):
break LABEL
# (b)

(a) is the code generator's implied 'continue' target for the LABEL loop.
(b) is the code generator's implied 'break' target for the LABEL loop.

I'm not saying that's a great solution either. It's probably not an 
option as there is now something that looks like a bound name but is not 
actually available at runtime - the following would not work:


  for foo in bar as LABEL:
  print(dir(LABEL))

(and presumably that is part of the reason why the proposal is the way 
it is).


I'm generally +0 on the concept (it might be nice, but I'm not sure 
either the original proposal or what I mention above are particularly 
problem-free ;)).


E.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin 
wrote:

> I am serious. It depends on the use case. If the data are an

But that's the all problem isn't it?

Since the start of the discussion, contesters have been offering
numerous solutions, all being contextual and with gotchas, none being
obvious, simple or elegant.


in the context above, I was offering that there were obvious, simple and
elegant solutions, but that which one was dependent on the use case.

EVERY choice in programming is dependent on the use case.

What I haven't seen yet is a compelling use case for a sequence .get() that
does not have an existing simple and elegant solution.

which doesn't mean they don't exist.

(and for the my part, the machinations with or shortcutting are not, in my
book, simple or elegant...)

Plus Sven already estimated the implementation would not be very hard.

...

The proposal is actionable, the cost of it seems low,


This would not simply be adding one method to a class. It would be adding a
method to the Sequence protocol ( ABC, whatever you want call it).

So a much heavier lift and larger impact than you imply.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Matt Gilson]

On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin 
wrote:

>
>
> Le 03/03/2017 à 22:21, Chris Barker a écrit :
> > On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze  > > wrote:
> >
> >> For my part, I think casting a list to a dict is often the RIGHT
> >> way to address these issues.
> >
> > You can't be serious about this. Especially because it would negate
> > your response to Ed "conditional on a len() call is the way to go".
> > Now you tell people to use "convert to dict".
> >
> >
> > I am serious. It depends on the use case. If the data are an
>
> But that's the all problem isn't it?
>
> Since the start of the discussion, contesters have been offering
> numerous solutions, all being contextual and with gotchas, none being
> obvious, simple or elegant.
>
> The best is still try/except.
>

Which really isn't a big deal if you use it in one or two places.  If you
use it everywhere, it's not too hard to roll your own helper function.


>
> "There should be one obvious way to do it" right?
>
> Plus Sven already estimated the implementation would not be very hard.
> So we have one obvious solution to a problem that:
>
> - several professional programmers said they have
> - has a similar API in another built-in
>

You state that like it's a good thing ;-).  I'm not quite so sure.


> - has currently no elegant solutions
>
> The proposal is actionable, the cost of it seems low, and it's not
> remotely controversial.
>

It seems to be pretty controversial to me :-).


>
> Honestly what evil would happen if it's get accepted ?


Lots of things.  For one thing, when scanning a function, if I see
something with a `.get` method I generally think that it is probably a
Mapping.  Obviously that assumption may be wrong, but it's at least a good
place to start.  If this gets accepted, that's no longer a clear starting
assumption.

It breaks backward compatibility (in small ways).  People might be relying
on the presence/absence of a `.get` method in order to make their function
polymorphic in some convoluted way which would break when this change is
introduced.  (I'm not saying that would be a good programming design idea
-- and it might not hold water as an argument when real-world usage is
looked at but it should be at least investigated before we claim that this
change isn't going to hurt anybody).

It's also not clear to me why we should be singling out `tuple` and
`list`.  Why not `str`, `bytes` and other sequences?  Maybe it isn't that
useful on those types, but I'd argue that it's not really useful on `tuple`
either other than to keep the "`tuple` is an immutable `list`" paradigm.


>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 01:35 PM, Michel Desmoulin wrote:


The proposal is actionable, the cost of it seems low, and it's not
remotely controversial.


Several people are against this idea, several of them are core-devs, and you claim it's not *remotely* controversial? 
Really??


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Michel Desmoulin]

Le 03/03/2017 à 22:21, Chris Barker a écrit :
> On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze  > wrote:
> 
>> For my part, I think casting a list to a dict is often the RIGHT
>> way to address these issues.
> 
> You can't be serious about this. Especially because it would negate
> your response to Ed "conditional on a len() call is the way to go".
> Now you tell people to use "convert to dict".
> 
> 
> I am serious. It depends on the use case. If the data are an

But that's the all problem isn't it?

Since the start of the discussion, contesters have been offering
numerous solutions, all being contextual and with gotchas, none being
obvious, simple or elegant.

The best is still try/except.

"There should be one obvious way to do it" right?

Plus Sven already estimated the implementation would not be very hard.
So we have one obvious solution to a problem that:

- several professional programmers said they have
- has a similar API in another built-in
- has currently no elegant solutions

The proposal is actionable, the cost of it seems low, and it's not
remotely controversial.

I get that on Python-idea you get "no" by default, but here we are
having such resistance for a feature that is light to implement, does
not clutter anything, does solve a problem, and is congruent with other
APIs.

Honestly what evil would happen if it's get accepted ?

This is not a "yeah but we can't accept everything that goes in or we
would bloat Python" thing.

If somebody tells me that no one want to spend time to code it, I can
understand. Everybody's has a life, and somebody else's pony can wait.
And since I can't code in C I can't do it. But that doesn't seem to be
the problem here.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 12:33 PM, Sven R. Kunze  wrote:

> Right now, I could not think of an example "non-trivial and simple and
> small enough" especially in the context of JSON. But maybe the other
> proponents have.
>

Always a challenge -- sorry to lack imagination, I tend to need concrete
examples to "get" some things.

And so far the concrete examples in this thread seem to have been
unconvincing...

Which doesn't mean at all that there aren't good and common-enough use
cases..

The part of data series from simulations (so proper datastructures
> available). So, data lists which aren't filled yet or have not filled till
> a certain amount yet I need some special pieces from them like the first, a
> sample, the 300th, etc. This was the case recently.
>

I deal with that a fair bit -- but in that case, if I need, say the 300th
sample, and there are not yet 300 available, then that IS an Exception I
want to handle.

if it didn't need to be the 300th, but rather an random sample, or maybe
one "half way through the data", or  then I would compute that index
from teh length or something...

Though I'm probably misunderstanding this use case.

There was also the case of a refactoring going on in some project, where
> things changed from dicts to lists (upgrade of a third party lib, I think).
> As a consequence, I needed to blow up certain functions from n one-liners
> [a.get] to n four-liners [try/except].
>

well, THAT I would blame on the third party lib. :-)

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze  wrote:

> For my part, I think casting a list to a dict is often the RIGHT way to
> address these issues.
>
>
> You can't be serious about this. Especially because it would negate your
> response to Ed "conditional on a len() call is the way to go". Now you tell
> people to use "convert to dict".
>

I am serious. It depends on the use case. If the data are an arbitrary-size
collection of essentially the same thing, then a sequence is the right data
structure, and examining len() (or catching the IndexError, maybe) is the
right way to handle there being fewer than you expect of them. I think the
key point is there there is nothing particularly different about them -- in
fact, often order isn't important at all.

If the data in question is a bunch of stuff where it matters where they
land in the sequence, and there may be missing values (Like a row in a CSV
file, maybe) then a dict IS the right structure -- even if it has integer
keys.

This reminds me of a discussion by Guido years ago about the "usual" use
cases for lists vs tuples -- lists are often a homogenous sequence of
items, whereas tuples are more likely to be heterogeneos -- more like a
struct

Now that I write that -- maybe the structure you really want is a
namedtuple. and maybe IT should have a get() so as to avoid catching
attribute errors all over teh place...

though getattr() does have a default -- so maybe namedtuple IS the answer
:-)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

Thanks Chris for your idea.

Right now, I could not think of an example "non-trivial and simple and 
small enough" especially in the context of JSON. But maybe the other 
proponents have.



The part of data series from simulations (so proper datastructures 
available). So, data lists which aren't filled yet or have not filled 
till a certain amount yet I need some special pieces from them like the 
first, a sample, the 300th, etc. This was the case recently.



There was also the case of a refactoring going on in some project, where 
things changed from dicts to lists (upgrade of a third party lib, I 
think). As a consequence, I needed to blow up certain functions from n 
one-liners [a.get] to n four-liners [try/except].



If I had know that this would be relevant to this discussion, I would 
have written it down, but it's just the negative memory/experience.



Regards,
Sven


On 03.03.2017 21:16, Chris Barker wrote:

About JSON and schema-less data:

I need to deal with this fairly often as well, but:

JSON has a data model that includes both mappings and sequences:

Sequences (arrays, lists, etc) are the "right" thing to use when an 
object has zero or more of something. Usually, these somethings are 
all the same. So you may need to answer the question: how many 
somethings are there? but rarely: if there are less than this many 
somethings, then I should use  a default value.


Mappings (objects, dicts) are the "right" thing to do when an object 
has a bunch of somethings, and each of them may be different and 
nameable. In this case, the if this name is in there, use its 
associated object, otherwise use a default" is a pretty common action.


so if your JSON is well formed (and I agree, being schema-less does 
not mean it is poorly formed) then it should already be using the 
appropriate data structures, and you are good to go.


That being said, maybe a concrete example would persuade the skeptics 
among us -- though I understand it may be hard to find one that is 
both non-trivial and simple and small enough to post to a mailing list...


-CHB








On Fri, Mar 3, 2017 at 12:09 PM, Chris Barker > wrote:


On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze mailto:srku...@mail.de>> wrote:


For me to think (list/tuple).get() was needed would be if
lots of folk either cast their lists to dicts or made their
own list-dict class to solve that problem.


The easier solution would be to provide list.get ;-)


Exactly -- I think that was the point -- if there is a lot of
custom code out there essentially adding a get() to a list -- then
that would indicate that is is broadly useful.

For my part, I think casting a list to a dict is often the RIGHT
way to address these issues.

-CHB


-- 


Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959voice
7600 Sand Point Way NE (206) 526-6329fax
Seattle, WA  98115 (206) 526-6317   
main reception


chris.bar...@noaa.gov 




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 03.03.2017 21:09, Chris Barker wrote:
On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze > wrote:



For me to think (list/tuple).get() was needed would be if lots of
folk either cast their lists to dicts or made their own list-dict
class to solve that problem.


The easier solution would be to provide list.get ;-)


Exactly -- I think that was the point -- if there is a lot of custom 
code out there essentially adding a get() to a list -- then that would 
indicate that is is broadly useful.


For my part, I think casting a list to a dict is often the RIGHT way 
to address these issues.


You can't be serious about this. Especially because it would negate your 
response to Ed "conditional on a len() call is the way to go". Now you 
tell people to use "convert to dict".



For my part, __getitem__ is the technical argument for this proposal.
My experience and those of other contributors to this thread make for 
the "broadly useful" argument.



Regards,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 12:06 PM, Chris Barker  wrote:

> M.A. Lemberg has been talking about that on this list (in this thread?
> I've lost track...)
>

it was in the "Optional parameters without default value" thread.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

About JSON and schema-less data:

I need to deal with this fairly often as well, but:

JSON has a data model that includes both mappings and sequences:

Sequences (arrays, lists, etc) are the "right" thing to use when an object
has zero or more of something. Usually, these somethings are all the same.
So you may need to answer the question: how many somethings are there? but
rarely: if there are less than this many somethings, then I should use  a
default value.

Mappings (objects, dicts) are the "right" thing to do when an object has a
bunch of somethings, and each of them may be different and nameable. In
this case, the if this name is in there, use its associated object,
otherwise use a default" is a pretty common action.

so if your JSON is well formed (and I agree, being schema-less does not
mean it is poorly formed) then it should already be using the appropriate
data structures, and you are good to go.

That being said, maybe a concrete example would persuade the skeptics among
us -- though I understand it may be hard to find one that is both
non-trivial and simple and small enough to post to a mailing list...

-CHB








On Fri, Mar 3, 2017 at 12:09 PM, Chris Barker  wrote:

> On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze  wrote:
>
>> For me to think (list/tuple).get() was needed would be if lots of folk
>> either cast their lists to dicts or made their own list-dict class to solve
>> that problem.
>>
>>
>> The easier solution would be to provide list.get ;-)
>>
>
> Exactly -- I think that was the point -- if there is a lot of custom code
> out there essentially adding a get() to a list -- then that would indicate
> that is is broadly useful.
>
> For my part, I think casting a list to a dict is often the RIGHT way to
> address these issues.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze  wrote:

> For me to think (list/tuple).get() was needed would be if lots of folk
> either cast their lists to dicts or made their own list-dict class to solve
> that problem.
>
>
> The easier solution would be to provide list.get ;-)
>

Exactly -- I think that was the point -- if there is a lot of custom code
out there essentially adding a get() to a list -- then that would indicate
that is is broadly useful.

For my part, I think casting a list to a dict is often the RIGHT way to
address these issues.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 11:15 AM, Kyle Lahnakoski 
wrote:

>  Python
> has a fundamentally different philosophy about None that conflicts with
> what I need for my domain [2] where I am transforming and interpreting
> data. Using a set of classes that make a different set of assumptions
> about None is not arduous, it keeps the definitions separate, and I
> still get all wonderfulness of Python.
>

not really related to this thread, but you may want to use your own
"sentinal" singletons, rather than special case code to deal with None.

i.e.

BadData
MissingData
UnSpecified

M.A. Lemberg has been talking about that on this list (in this thread? I've
lost track...)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Barker]

On Fri, Mar 3, 2017 at 11:01 AM, Sven R. Kunze  wrote:

> I wonder if those arguing against it also think dicts should not have item
> access:
>
> a[0]
>
> dict or list? Why should it matter?
>

Because a mapping that happens to have an integer key is a fundamentally
different thing than a sequence. It seems to me that in some of the
examples given, the use case really calls for a
mapping-with-integers-as-keys, rather than a sequence -- in which case, you
could use that, and have the get() :-)

And then you could iterate through it the same way, too!

you could get closer to sequence behvior by used a OrderedDict -- or maybe
even write a SortedDict that would keep the keys in order regardless of
when they were added.


> a.get(0, 'oops')
> Doesn't look so different to me.
>

but you are going to have issue with other things anyway, notable:

for thing in a:
# is thing a key or a value?

- Which of the existing things (slice + [default], conditional on a slice,
> conditional on a len() call) do you think is the obvious way to do it?
>
> I think conditional on a len() call is the way to go -- it captures the
concept well -- sequences have a certain number of items -- how many this
one has is the question at hand. mapping, however, also have a certain
number of items, but the number does not indicate which ones are "missing".

I guess that's the key point for me -- in all teh examples I seen posed
(like parsing args) the sequence may contain from n to n+m items, but a
get() doesn' really solve your problem, because the default is probably
different depending on how MANY of the possible items are "missing".

So get(0 is only helpful if:

1) there is only one possible missing item

2) all the missing items have the same default -- unless that default is
sometign like None, in which case you are simply replacing one way to
express missing with another, I can't see that being common.

So I would expect to see a Sequence /get(0 be used to slightly clean up the
code that adds a bunch of Nones to sequences to make them all the same
length -- which is actually pretty easy to do anyway:

seq = seq + [None] * full_len - len(seq)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 03.03.2017 20:35, Ethan Furman wrote:

On 03/03/2017 11:01 AM, Sven R. Kunze wrote:

On 03.03.2017 19:29, Ed Kellett wrote:


The reasons already stated boil down to "lists aren't dicts so they 
shouldn't share methods", which seems ill-advised

at best, and "I wouldn't use this".


I wonder if those arguing against it also think dicts should not have 
item access:


dicts don't have item access -- they have key access.  :wink:


Python doesn't make a difference here. :wink:

https://docs.python.org/3/reference/datamodel.html#object.__getitem__




a[0]

dict or list? Why should it matter?


Because they are different data types with different purposes.

- Which of the existing things (slice + [default], conditional on a 
slice, conditional on a len() call) do you think

is the obvious way to do it?


None of them are. Try/except is the most obvious way. But it's tedious.


[my_value] = some_list[offset:offset+1] or [default_value]

No, it's not terribly pretty, but accessing invalid locations on a 
list on purpose shouldn't be that common.


When generating data series / running a simulation, at the beginning 
there is no data in many lists. Recently, had those issues.


dicts went fine, lists just sucked with all those try/except blocks.



- Are there any examples where list.get would be applicable and not 
the obviously best way to do it?


I don't think so. I already have given many examples/ideas of when I 
would love to have had this ability. Let me

re-state those and more:

- refactoring (dicts <-> lists and their comprehension counterparts)


dict and list comprehensions are not the same, and adding .get to list 
won't make them the same.


Never said they are the same. I said refactoring is easier.


- easier to teach


Having `print` be a statement instead of a function made it easier to 
teach but that didn't make it a good idea.


Many people disagree with you on this.

For me to think (list/tuple).get() was needed would be if lots of folk 
either cast their lists to dicts or made their own list-dict class to 
solve that problem.


The easier solution would be to provide list.get ;-)


Regards,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 10:29 AM, Ed Kellett wrote:


- Which of the existing things (slice + [default], conditional on a slice, 
conditional on a len() call) do you think is
the obvious way to do it?


[my_value] = some_list[offset:offset+1] or [default_value]

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 11:01 AM, Sven R. Kunze wrote:

On 03.03.2017 19:29, Ed Kellett wrote:



The reasons already stated boil down to "lists aren't dicts so they shouldn't share 
methods", which seems ill-advised
at best, and "I wouldn't use this".


I wonder if those arguing against it also think dicts should not have item 
access:


dicts don't have item access -- they have key access.  :wink:


a[0]

dict or list? Why should it matter?


Because they are different data types with different purposes.


- Which of the existing things (slice + [default], conditional on a slice, 
conditional on a len() call) do you think
is the obvious way to do it?


None of them are. Try/except is the most obvious way. But it's tedious.


[my_value] = some_list[offset:offset+1] or [default_value]

No, it's not terribly pretty, but accessing invalid locations on a list on 
purpose shouldn't be that common.


- Are there any examples where list.get would be applicable and not the 
obviously best way to do it?


I don't think so. I already have given many examples/ideas of when I would love 
to have had this ability. Let me
re-state those and more:

- refactoring (dicts <-> lists and their comprehension counterparts)


dict and list comprehensions are not the same, and adding .get to list won't 
make them the same.


- easier to teach


Having `print` be a statement instead of a function made it easier to teach but 
that didn't make it a good idea.

For me to think (list/tuple).get() was needed would be if lots of folk either cast their lists to dicts or made their 
own list-dict class to solve that problem.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Kyle Lahnakoski]

I must mention a get() method for lists and tuples would be very useful
for me too. It is so useful, that I spent too much time making my own
module to handle this case, plus many of the other dealing-with-None
subjects found on this list.  Michel is correct to point out that this
is domain specific problem; a domain where you deal with many varied,
and schema-free, data formats. I deal with JSON emitted from multiple
systems of often-changing schemas.  In my experience, this is not a
result of bad or buggy programming, rather, it is about representing
facts and annotating them with a multitude of optional properties and
descriptive structures.

Now, in the specific case of list.get(), I would be disappointed that it
is used to extract parameters from an arg list: Parameters should be
named; packing them into an ordered list looses that important
information, but it happens[1], and list.get() would help. For the args
scenario, I do like Ed's solution: dict(enumerate(args)).

In conclusion, I may have talked myself out of liking list.get(): Python
has a fundamentally different philosophy about None that conflicts with
what I need for my domain [2] where I am transforming and interpreting
data. Using a set of classes that make a different set of assumptions
about None is not arduous, it keeps the definitions separate, and I
still get all wonderfulness of Python.

[1] also happens when reading csv files: Missing values indicate
default, or variable number of columns indicate that the missing
rightmost columns are all null.
[2] For Python, None is a missing value, or a special case. For data
transformation, None means "the operation you performed does not apply
to this datatype" which avoids exceptions, which gives you an algebra
over data (with [], dot and slice as operators), which allows you to
build complex list comprehensions (data transformation queries) without
the exception catching logic. Databases query languages do this.

On 2017-02-28 21:02, Michel Desmoulin wrote:
>
> Le 01/03/2017 à 02:23, Ethan Furman a écrit :
>> On 02/28/2017 05:18 PM, Michel Desmoulin wrote:
>>
>>> I love this proposal but Guido rejected it. Fighting for it right now
>>> would probably be detrimental to the current proposed feature which
>>> could potentially be more easily accepted.
>> PEP 463 has a better chance of being accepted than this one does, for
>> reasons that D'Aprano succinctly summarized.
>>
>> -- 
>> ~Ethan~
> The debate is not even over and you are already declaring a winner.
> That's not really fair. Give the idea a chance and read until the end.
>
> D'Aprano's argument is mostly "I don't encounter IndexError really often
> and when I do I have this twisted one liner to get away it".
>
> Well, that's not really a good reason to reject things for Python
> because it's a language with a very diverse user base. Some bankers,
> some web dev, some geographers, some mathematicians, some students, some
> 3D graphists, etc. And the language value obvious, readable, predictable
> code for all.
>
> Most people on this list have a specialty, because their speciality
> don't see a use for the feature doesn't mean there is not one.
>
> So I provided on my last answer an explanation of what I would use it for.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 10:48 AM, Sven R. Kunze wrote:

On 03.03.2017 18:06, Ethan Furman wrote:

On 03/02/2017 12:36 PM, Sven R. Kunze wrote:



It then would make sense to remove .get() on dicts.  ;-)

and to remove parameter "default" of max().
and to remove parameter "default" of getattr().


Backwards compatibility, and performance, says no.  ;)

try/except expressions are not a silver bullet any more than try/except blocks. 
 But they can still be very useful.


Totally true. I think both proposals have their merit.

IIRC, Guido rightfully declared that try/except expressions aren't a good idea. 
It's better to find more concrete
patterns instead of it. And I still agree with him.

The "default parameter" pattern is such a pattern, and it's vastly used in the 
stdlib.



$ grep "def get(" *.py */*.py */*/*.py

queue.py:def get(self, block=True, timeout=None):
pickle.py:def get(self, i):
shelve.py:def get(self, key, default=None):
doctest.py:def get(self):
mailbox.py:def get(self, key, default=None):
weakref.py:def get(self, key, default=None):
weakref.py:def get(self, key, default=None):
sre_parse.py:def get(self):
webbrowser.py:def get(using=None):
tkinter/ttk.py:def get(self, x=None, y=None):
configparser.py:def get(self, section, option, *, raw=False, vars=None, 
fallback=_UNSET):
configparser.py:def get(self, option, fallback=None, *, raw=False, 
vars=None, _impl=None, **kwargs):
email/message.py:def get(self, name, failobj=None):
asyncio/queues.py:def get(self):
logging/config.py:def get(self, key, default=None):
idlelib/pyparse.py:def get(self, key, default=None):
wsgiref/headers.py:def get(self,name,default=None):
xml/dom/minidom.py:def get(self, name, value=None):
_collections_abc.py:def get(self, key, default=None):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self, first, last=None):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self, index1, index2=None):
tkinter/__init__.py:def get(self, x, y):
tkinter/__init__.py:def get(self):
xml/sax/xmlreader.py:def get(self, name, alternative=None):
collections/__init__.py:def get(self, key, default=None):
idlelib/scrolledlist.py:def get(self, index):
idlelib/searchengine.py:def get(root):
multiprocessing/pool.py:def get(self, timeout=None):
xml/etree/ElementTree.py:def get(self, key, default=None):
multiprocessing/queues.py:def get(self, block=True, timeout=None):
multiprocessing/queues.py:def get(self):
multiprocessing/managers.py:def get(self):
multiprocessing/managers.py:def get(self):
idlelib/idle_test/mock_tk.py:def get(self):
idlelib/idle_test/mock_tk.py:def get(self, index1, index2=None):

I wouldn't consider 10 out of 43 "vastly" (11 out of 46 if one includes dict, list, and tuple).  The numbers are even 
worse if one considers the "get_something_or_other" methods which do not have a default parameter.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Alexandre Brault]

On 2017-03-03 01:52 PM, Chris Angelico wrote:
> On Sat, Mar 4, 2017 at 5:50 AM, Matthias Bussonnier
>  wrote:
>> Thanks, I think it does make sens, I'm going to guess,
>> outerloop.brk(inners=True) might also be helpful if you have more
>> inners loops. I think that implicitely breaking inner ones might
>> not always be the right thing to do so having a way to not break
>> inner ones does make sens.
>>
> *scratches head* How do you break an outer loop without breaking the
> inner loop? What happens?
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
I believe what Matthias is hoping for is an equivalent of Java's named
break feature. Breaking out of an outer loop implicitly breaks out of
all inner loops
Alex
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Sven R. Kunze]

On 03.03.2017 16:24, Yury Selivanov wrote:

TBH I think that optional parameters isn't a problem requiring new
syntax. We probably do need syntax for positional-only arguments
(since we already have  them in a way), but optional parameters
can be solved easily without a new syntax.

Syntax like:

1. def a(?foo),
2. def a(foo=pass),
3. def a([foo]),

will complicate the language too much IMO.

Yury


I never really encountered a real-world use where I would have needed 
this kind of parameter declaration ability.


It's like the ++ operator of C which comes in pre- and postfix notation.
It's really cool to teach the nuances of it. And to create exam 
questions using it. And to confuse students. But completely unnecessary 
in real-life code.


Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Chris Angelico]

On Sat, Mar 4, 2017 at 5:56 AM, Matthias Bussonnier
 wrote:
>> *scratches head* How do you break an outer loop without breaking the
>> inner loop? What happens?
>
> Finish running the inner, then breaking the outer. Instead of breaking
> inner and outer.
>
> for i in outer:
> bk = False
> for j in inner:
>  if cond:
>  bk = True
> if bk:
>break
>
>
> vs
>
> for i in outer:
> bk = False
> for j in inner:
>  if cond:
>  bk = True
>  break # this.
> if bk:
>break
>
> Sorry if I'm mis expressing myself.

Oh, I see what you mean.

So "breaking the outer loop" really means "flag the outer loop such
that, on next iteration, it will terminate". The trouble is that
that's not exactly what "break" means. Consider:

for i in outer:
print("Top of outer")
for j in inner:
print("Top of inner")
if cond1:
break
if cond2:
break_outer(inner=False)
if cond3:
break_outer(inner=True)
print("Bottom of inner")
print("Bottom of outer")

cond1 would print "bottom of outer" and keep loping. cond2 and cond3
should presumably _not_ print "bottom of outer". Should they print
"bottom of inner", though?

Seems like an odd use, though. If I want a multi-step break, I want to
break every step, not just the last one.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Matthias Bussonnier]

> *scratches head* How do you break an outer loop without breaking the
> inner loop? What happens?

Finish running the inner, then breaking the outer. Instead of breaking
inner and outer.

for i in outer:
bk = False
for j in inner:
 if cond:
 bk = True
if bk:
   break


vs

for i in outer:
bk = False
for j in inner:
 if cond:
 bk = True
 break # this.
if bk:
   break

Sorry if I'm mis expressing myself.

-- 
M

On Fri, Mar 3, 2017 at 10:52 AM, Chris Angelico  wrote:
> On Sat, Mar 4, 2017 at 5:50 AM, Matthias Bussonnier
>  wrote:
>> Thanks, I think it does make sens, I'm going to guess,
>> outerloop.brk(inners=True) might also be helpful if you have more
>> inners loops. I think that implicitely breaking inner ones might
>> not always be the right thing to do so having a way to not break
>> inner ones does make sens.
>>
>
> *scratches head* How do you break an outer loop without breaking the
> inner loop? What happens?
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 03.03.2017 19:29, Ed Kellett wrote:
The reasons already stated boil down to "lists aren't dicts so they 
shouldn't share methods", which seems ill-advised at best, and "I 
wouldn't use this".


I wonder if those arguing against it also think dicts should not have 
item access:


a[0]

dict or list? Why should it matter?

a.get(0, 'oops')

Doesn't look so different to me.

I'm not convinced that the latter is generally true; I've often looked 
for something like a list.get, been frustrated, and used one (chosen 
pretty much at random) of the ugly hacks presented in this thread. I'd 
be surprised if I'm the only one.


You are not the only one. I share your sentiment.

I guess I don't have any hope of convincing people who think there's 
no need to ever do this, but I have a couple of questions for the 
people who think the existing solutions are fine:


- Which of the existing things (slice + [default], conditional on a 
slice, conditional on a len() call) do you think is the obvious way to 
do it?


None of them are. Try/except is the most obvious way. But it's tedious.

- Are there any examples where list.get would be applicable and not 
the obviously best way to do it?


I don't think so. I already have given many examples/ideas of when I 
would love to have had this ability. Let me re-state those and more:


- refactoring (dicts <-> lists and their comprehension counterparts)
- error-free accessing list comprehensions
- duck typing
- increased consistency of item access between dicts and lists
- the one obvious way to do it
- easier to teach

Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Chris Angelico]

On Sat, Mar 4, 2017 at 5:50 AM, Matthias Bussonnier
 wrote:
> Thanks, I think it does make sens, I'm going to guess,
> outerloop.brk(inners=True) might also be helpful if you have more
> inners loops. I think that implicitely breaking inner ones might
> not always be the right thing to do so having a way to not break
> inner ones does make sens.
>

*scratches head* How do you break an outer loop without breaking the
inner loop? What happens?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Matthias Bussonnier]

Hi Brice,

On Fri, Mar 3, 2017 at 10:00 AM, Brice PARENT  wrote:
> Thanks Matthias for taking the time to give your opinion about it.
>
> Just to set the focus where I may have failed to point it:
> the main purpose of this proposal is the creation of the object itself, an
> object representing the loop. What we can do with it is still a sub-level of
> this proposal, as the presence of this object is what allows all these
> simplifications, and offers a lot of possibilities.
> A 2 level breaking would have to be used this way :
>
> for outerloop, i in Loop(range(4)):
> for innerloop, j in Loop(range(3)):
> if i==2 and j==1:
> outerloop.brk()
> break  # this

Thanks, I think it does make sens, I'm going to guess,
outerloop.brk(inners=True) might also be helpful if you have more
inners loops. I think that implicitely breaking inner ones might
not always be the right thing to do so having a way to not break
inner ones does make sens.

The other possibility would be to allow the Loop object to catch
raised exceptions and potentially continue running loops.
Then you could "just" use raise to break multiple loops, but
that might be a weird Loop/ContextManager hybrid.

-- 
M
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 03.03.2017 18:06, Ethan Furman wrote:

On 03/02/2017 12:36 PM, Sven R. Kunze wrote:

On 01.03.2017 06:34, Ethan Furman wrote:


On the bright side, if enough use-cases of this type come up (pesky 
try/except for a simple situation), we may be able
to get Guido to reconsider PEP 463.  I certainly think PEP 463 makes 
a lot more sense that adding list.get().


It then would make sense to remove .get() on dicts.  ;-)

and to remove parameter "default" of max().
and to remove parameter "default" of getattr().


Backwards compatibility, and performance, says no.  ;)

try/except expressions are not a silver bullet any more than 
try/except blocks.  But they can still be very useful.


Totally true. I think both proposals have their merit.

IIRC, Guido rightfully declared that try/except expressions aren't a 
good idea. It's better to find more concrete patterns instead of it. And 
I still agree with him.



The "default parameter" pattern is such a pattern, and it's vastly used 
in the stdlib.



Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Chris Angelico]

On Sat, Mar 4, 2017 at 5:29 AM, Ed Kellett  wrote:
> I've often looked for something like a list.get, been frustrated, and used
> one (chosen pretty much at random) of the ugly hacks presented in this
> thread. I'd be surprised if I'm the only one.

Can you show us some real-world code that would benefit from
list.get()? That would make the discussion more productive, I think.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ed Kellett]

On Fri, 3 Mar 2017 at 17:03 Ethan Furman  wrote:

> On 03/03/2017 08:09 AM, Ed Kellett wrote:
>
> > P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO
> solve) this problem doesn't mean it should supersede
> > this discussion.
>
> The advantage of PEP 463 is that issues like this would be less pressing,
> and it's much more general purpose.
>

PEP 463 won't solve this problem for me because its solution is as ugly as
the thing it's replacing. Conceptually, I'd even argue that it's uglier.
Also, if you want a general-purpose solution to everything, propose
with-expressions, but that's another discussion. The existence of
general-purpose things doesn't mean specific issues aren't worth talking
about.


> Personally, I don't think `get` belongs on list/tuple for reasons already
> stated.
>

The reasons already stated boil down to "lists aren't dicts so they
shouldn't share methods", which seems ill-advised at best, and "I wouldn't
use this". I'm not convinced that the latter is generally true; I've often
looked for something like a list.get, been frustrated, and used one (chosen
pretty much at random) of the ugly hacks presented in this thread. I'd be
surprised if I'm the only one.

I guess I don't have any hope of convincing people who think there's no
need to ever do this, but I have a couple of questions for the people who
think the existing solutions are fine:

- Which of the existing things (slice + [default], conditional on a slice,
conditional on a len() call) do you think is the obvious way to do it?
- Are there any examples where list.get would be applicable and not the
obviously best way to do it?

Ed
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Brice PARENT]

Thanks Matthias for taking the time to give your opinion about it.

Just to set the focus where I may have failed to point it:
the main purpose of this proposal is the creation of the object itself, 
an object representing the loop. What we can do with it is still a 
sub-level of this proposal, as the presence of this object is what 
allows all these simplifications, and offers a lot of possibilities.


Le 03/03/17 à 17:21, Matthias Bussonnier a écrit :



A word about compatibility and understandability before:
"as" is already a keyword, so it is already reserved and easy to parse. It
couldn't be taken for its other uses (context managers, import statements
and
exceptions) as they all start with a specific and different keyword. It
would
have a really similar meaning, so be easy to understand. It doesn't imply
any
incompatibility with previous code, as current syntax would of course still
be
supported, and it doesn't change anything anywhere else (no change in
indentation levels for example, no deprecation).

That still would make it usable only on Python 3.7+ It seem to me you ca already
do that now with helper object/function:
Yes, what I meant is that it wouldn't break any code from previous 
versions. But as with any new keyword or syntax evolution, newer code 
wouldn't get well in older versions.

In  [1]: class Loop:
 ...:
 ...: def __init__(self, iterable):
 ...: self._it = iter(iterable)
 ...: self._break = False
 ...:
 ...: def __next__(self):
 ...: if self._break:
 ...: raise StopIteration
 ...: return (self, next(self._it))
 ...:
 ...: def __iter__(self):
 ...: return self
 ...:
 ...: def brk(self):
 ...: self._break = True
 ...:
 ...:

In  [2]: for loop,i in Loop(range(10)):
 ...: if i==5:
 ...: loop.brk()
 ...: print(i)
1
2
3
4
5

A 2 level breaking would have to be used this way :

for outerloop, i in Loop(range(4)):
for innerloop, j in Loop(range(3)):
if i==2 and j==1:
outerloop.brk()
break  # this

print(i, j)

if outerloop.broken:
break  # or continue. For the code following this line not to 
be executed


break() and continue() methods (which I named this way to reflect the 
behaviour of the statements, but I'm not sure whether it could or should 
be kept this way) are only an improvement on the keywords in nested 
loops or complex situations where explicitly exiting a certain loop 
helps readability by removing a bunch of conditions and assignments. 
It's also allowing to pass this function as a callback to something 
else, but I'm not sure it would be that useful.



Syntax:
for element in elements as elements_loop:
 assert type(elements_loop) is ForLoopIterationObject

Properties and methods (non exhaustive list, really open to discussion and
suggestions):
for element in elements as elements_loop:
 elements_loop.length: int  # len ? count ?
 elements_loop.counter: int  # Add a counter0, as in Django? a counter1 ?
 elements_loop.completed: bool
 elements_loop.break()
 elements_loop.continue()
 elements_loop.skip(count=1)

I did not implement these, but they are as feasible. (break is keyword
though, so you need to rename it)
Length, counter and completed (and .skip() in some ways) are just 
helping the readability while allowing a more concise code, as they 
don't force to create temporary variables. But they belong here as a 
part of the whole thing. If the object had to be integrated, for 
.break(), .continue(), .skip() and any other useful method, those little 
improvements would be nice to have and help to keep your code look more 
like the design in your head.
.break() and .continue() help as they modify the flow. They roughly do 
this :


LOOP1
LOOP2
if something:
LOOP1.break()  # similar to calling break repeatedly once 
for every loop until LOOP1 included, so going straight to 
"something_after_every_loop"


something_else

yet_another_thing

something_after_every_loop

The same goes for .continue(), calling break in every inner loop, and 
continue in the one the method is called from.



Examples of every presented element (I didn't execute the code, it's just to
explain the proposal):

##
# forloop.counter and forloop.length

for num, dog in enumerate(dogs):
 print(num, dog)

print("That's a total of {} dogs !".format(len(dogs)))

# would be equivalent to

for dog in dogs as dogs_loop:
 print(dogs_loop.counter, dog)

I find it less readable than enumerate.
Well, I find both readable, but the second only requires to focus on the 
loop itself, not on how enumerate and unpacking work.
The second syntax however allows the exact same syntax when you work 
with dicts, lists or tuples. Here, dogs may be of any type of iterable, 
while in fi

Re: [Python-ideas] For/in/as syntax

[Ethan Furman]

On 03/03/2017 01:14 AM, Brice PARENT wrote:


Sorry for the very long message, I hope it will get your interest. And I also
hope my English was clear enough.


Long messages that explain the idea are welcome!

I think it looks interesting.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Ethan Furman]

On 03/03/2017 08:21 AM, Matthias Bussonnier wrote:


##
# forloop.break(), to break out of nested loops (or explicitly out of
current
#loop) - a little like pep-3136's first proposal

has_dog_named_rex = False
for owner in owners:
 for dog in dogs:
 if dog.name == "Rex":
 has_dog_named_rex = True
 break

 if has_dog_named_rex:
 break

# would be equivalent to

for owner in owners as owners_loop:
 for dog in dogs:  # syntax without "as" is off course still supported
 if dog.name == "Rex":
 owners_loop.break()


See my above proposal, you would still need to break the inner loop
here as well. So i'm guessing you miss a `break` afrer owner_loop.break() ?


No, he's not -- part of implementing this change includes not needing to 
specify the inner breaks.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/02/2017 12:36 PM, Sven R. Kunze wrote:

On 01.03.2017 06:34, Ethan Furman wrote:



On the bright side, if enough use-cases of this type come up (pesky try/except 
for a simple situation), we may be able
to get Guido to reconsider PEP 463.  I certainly think PEP 463 makes a lot more 
sense that adding list.get().


It then would make sense to remove .get() on dicts.  ;-)

and to remove parameter "default" of max().
and to remove parameter "default" of getattr().


Backwards compatibility, and performance, says no.  ;)

try/except expressions are not a silver bullet any more than try/except blocks. 
 But they can still be very useful.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 08:09 AM, Ed Kellett wrote:


P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO solve) this 
problem doesn't mean it should supersede
this discussion.


The advantage of PEP 463 is that issues like this would be less pressing, and 
it's much more general purpose.

Personally, I don't think `get` belongs on list/tuple for reasons already 
stated.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Ethan Furman]

On 03/03/2017 06:29 AM, Victor Stinner wrote:


An alternative for generated signature of multiple optional arguments
is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan
of nested [...],


But that's not the same thing.

  bytearry([source,] [encoding,] [errors])

says that each argument can be passed without passing any others.

  bytearray([source [, encoding [,errors]]])

says that in order to pass encoding, source must also be specified.

At least, that's what it says to me.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] For/in/as syntax

[Matt Gilson]

Thanks for the idea and prior research.

I'm not convinced that this warrants new syntax.  Most of what you propose
(skipping, counting, exposing a length if available, tracking if completed)
could be solved already by creating your own wrapper around an iterable:

elements_loop = ForLoopIterationObject(elements)
for element in elements_loop:
...

Some of your proposal simply can't be done perfectly (e.g. length) since
iterables can have infinite length.  There is `__length_hint__` IIRC which
might (or might not) give a rough estimate.

You also couldn't do `elements_loop.continue()` or `elements_loop.break()`
in a python-based wrapper without special interpreter magic (at least now
as far as I can imagine...).  I realize that is the point of this proposal
as it would allow breaking/continuing nested loops, however, that proposal
was already rejected because Guido didn't think that the use-cases were
compelling enough to add new syntax/complexity to the python language and
most of the time you can address that case by adding a function here or
there.  In this proposal, you're adding significantly _more_ complexity
than was proposed in PEP-3136.  Also, you're creating an object for every
loop -- and that object needs to do stuff when iterating (e.g. increment a
counter).  It's very unlikely that this could be anything but a performance
drain compared to existing solutions (only use `enumerate` when you need
it).  I suppose that the interpreter could be smart enough to only create a
ForLoopIterationObject when it actually needs it (e.g. when there is an
`as` statement), but that shifts a lot more complexity onto the language
implementors -- again for perhaps little benefit.



On Fri, Mar 3, 2017 at 1:14 AM, Brice PARENT  wrote:

> Object: Creation of a ForLoopIterationObject object (name open to
> suggestions)
> using a "For/in/as" syntax.
>
> Disclaimer:
> I've read PEP-3136 which was refused. The present proposal includes a
> solution
> to what it tried to solve (multi-level breaking out of loops), but is a
> more
> general proposal and it offers many unrelated advantages and
> simplifications.
> It also gives another clean way of making a kind of for/except/else syntax
> of
> another active conversation.
>
> What it tries to solve:
> During the iteration process, we often need to create temporary variables
> (like
>  counters or states) or tests that don't correspond to the logic of the
> algo,
> but are required to make it work. This proposal aims at removing these
> unnecessary and hard to understand parts and help write simpler, cleaner,
> more
> maintainable and more logical code.
> So, more PEP-8 compliant code.
>
> How does it solve it:
> By instanciating a new object when starting a loop, which contains some
> data
> about the iteration process and some methods to act on it. The list of
> available properties and methods are yet to be defined, but here are a
> subset
> of what could be really helpful.
>
> A word about compatibility and understandability before:
> "as" is already a keyword, so it is already reserved and easy to parse. It
> couldn't be taken for its other uses (context managers, import statements
> and
> exceptions) as they all start with a specific and different keyword. It
> would
> have a really similar meaning, so be easy to understand. It doesn't imply
> any
> incompatibility with previous code, as current syntax would of course
> still be
> supported, and it doesn't change anything anywhere else (no change in
> indentation levels for example, no deprecation).
>
> Syntax:
> for element in elements as elements_loop:
> assert type(elements_loop) is ForLoopIterationObject
>
> Properties and methods (non exhaustive list, really open to discussion and
> suggestions):
> for element in elements as elements_loop:
> elements_loop.length: int  # len ? count ?
> elements_loop.counter: int  # Add a counter0, as in Django? a counter1
> ?
> elements_loop.completed: bool
> elements_loop.break()
> elements_loop.continue()
> elements_loop.skip(count=1)
>
> Examples of every presented element (I didn't execute the code, it's just
> to
> explain the proposal):
>
> ##
> # forloop.counter and forloop.length
>
> for num, dog in enumerate(dogs):
> print(num, dog)
>
> print("That's a total of {} dogs !".format(len(dogs)))
>
> # would be equivalent to
>
> for dog in dogs as dogs_loop:
> print(dogs_loop.counter, dog)
>
> print("That's a total of {} dogs !".format(dogs_loop.length))
>
> # -> cleaner, and probably faster as it won't have to call len() or
> enumerate()
> #(but I could easily be wrong on that)
>
>
> ##
> # forloop.length when we broke out of the list
>
> small_and_medium_dogs_count = 0
> for dog in generate_dogs_list_by_size():
> if dog.size >= medium_dog_size:
> break
>
> small_and_medium_dogs_count += 1
>
> print("That's a total of {} smal

Re: [Python-ideas] For/in/as syntax

[Matthias Bussonnier]

Hi Brice,

On Fri, Mar 3, 2017 at 1:14 AM, Brice PARENT  wrote:

>
> A word about compatibility and understandability before:
> "as" is already a keyword, so it is already reserved and easy to parse. It
> couldn't be taken for its other uses (context managers, import statements
> and
> exceptions) as they all start with a specific and different keyword. It
> would
> have a really similar meaning, so be easy to understand. It doesn't imply
> any
> incompatibility with previous code, as current syntax would of course still
> be
> supported, and it doesn't change anything anywhere else (no change in
> indentation levels for example, no deprecation).

That still would make it usable only on Python 3.7+ It seem to me you ca already
do that now with helper object/function:

In  [1]: class Loop:
...:
...: def __init__(self, iterable):
...: self._it = iter(iterable)
...: self._break = False
...:
...: def __next__(self):
...: if self._break:
...: raise StopIteration
...: return (self, next(self._it))
...:
...: def __iter__(self):
...: return self
...:
...: def brk(self):
...: self._break = True
...:
...:

In  [2]: for loop,i in Loop(range(10)):
...: if i==5:
...: loop.brk()
...: print(i)
1
2
3
4
5

>
> Syntax:
> for element in elements as elements_loop:
> assert type(elements_loop) is ForLoopIterationObject
>
> Properties and methods (non exhaustive list, really open to discussion and
> suggestions):
> for element in elements as elements_loop:
> elements_loop.length: int  # len ? count ?
> elements_loop.counter: int  # Add a counter0, as in Django? a counter1 ?
> elements_loop.completed: bool
> elements_loop.break()
> elements_loop.continue()
> elements_loop.skip(count=1)

I did not implement these, but they are as feasible. (break is keyword
though, so you need to rename it)

>
> Examples of every presented element (I didn't execute the code, it's just to
> explain the proposal):
>
> ##
> # forloop.counter and forloop.length
>
> for num, dog in enumerate(dogs):
> print(num, dog)
>
> print("That's a total of {} dogs !".format(len(dogs)))
>
> # would be equivalent to
>
> for dog in dogs as dogs_loop:
> print(dogs_loop.counter, dog)

I find it less readable than enumerate.

>
> print("That's a total of {} dogs !".format(dogs_loop.length))
>
> # -> cleaner, and probably faster as it won't have to call len() or
> enumerate()
> #(but I could easily be wrong on that)

Though I can see how accumulating the length while iterating may make sens.

>
>
> ##
> # forloop.length when we broke out of the list
>
> small_and_medium_dogs_count = 0
> for dog in generate_dogs_list_by_size():
> if dog.size >= medium_dog_size:
> break
>
> small_and_medium_dogs_count += 1
>
> print("That's a total of {} small to medium dogs !".format(
> small_and_medium_dogs_count))
>
> # would be equivalent to
>
> for dog in generate_dogs_list_by_size() as dogs_loop:
> if dog.size >= medium_dog_size:
> break
>
> print("That's a total of {} small to medium dogs !".format(
> dogs_loop.length - 1))
>
> # -> easier to read, less temporary variables
>
> ##
> # forloop.break(), to break out of nested loops (or explicitly out of
> current
> #loop) - a little like pep-3136's first proposal
>
> has_dog_named_rex = False
> for owner in owners:
> for dog in dogs:
> if dog.name == "Rex":
> has_dog_named_rex = True
> break
>
> if has_dog_named_rex:
> break
>
> # would be equivalent to
>
> for owner in owners as owners_loop:
> for dog in dogs:  # syntax without "as" is off course still supported
> if dog.name == "Rex":
> owners_loop.break()

See my above proposal, you would still need to break the inner loop
here as well. So i'm guessing you miss a `break` afrer owner_loop.break() ?

>
> # -> way easier to read and understand, less temporary variables
>
> ##
> # forloop.continue(), to call "continue" from any nested loops (or
> explicitly
> #in active loop)
>
> has_dog_named_rex = False
> for owner in owners:
> for dog in owner.dogs:
> if dog.name == "Rex":
> has_dog_named_rex = True
> break
>
> if has_dog_named_rex:
> continue
>
> # do something
>
> # would be equivalent to
>
> for owner in owners as owners_loop:
> for dog in owner.dogs:
> if dog.name == "Rex":
> owners_loop.continue()

you are missing a break as well here you need to break out of
owner.dogs, but fair.
I think though that having to `.continue()` the outer loop before
breaking the inner (you have to right ?)
can make things com

Re: [Python-ideas] get() method for list and tuples

[Ed Kellett]

On Tue, 28 Feb 2017 at 17:19 David Mertz  wrote:

> On Tue, Feb 28, 2017 at 7:16 AM, Michel Desmoulin <
> desmoulinmic...@gmail.com> wrote:
>
> Le 28/02/2017 à 15:45, Steven D'Aprano a écrit :
> > No you don't. You can use slicing.
> > alist = [1, 2, 3]
> > print(alist[99:100])  # get the item at position 99
>
> No this gives you a list of one item or an empty list.
>
> dict.get('key', default_value) let you get a SCALAR value, OR a default
> value if it doesn't exist.
>
>
> x = (alist[pos:pos+1] or [default_val])[0]
>
>
> How so ? "get the element x or a default value if it doesn't exist" seem
> at the contrary, a very robust approach.
>
>
> Yes, and easily written as above.  What significant advantage would it
> have to spell the above as:
>

I think code like that is convoluted and confusing and I'm surprised to see
anyone at all advocating it.

IMO, the sane thing to compare this with is a conditional expression. There
aren't any spellings of that that aren't ugly either:

>>> stuff[x] if len(stuff) > x else default
>>> stuff[x] if stuff[x:x+1] else default

As for a reasonable use of list.get (or tuple.get), I often end up with
lists of arguments and would like to take values from the list if they
exist or take a default if not. This looks particularly horrible if the
index isn't a variable (so most of the time):

something = args[1] if len(args) > 1 else "cheese"
something_else = args[2] if len(args) > 2 else "eggs"

(you could make it more horrible by using the slicing trick, but I don't
see much point in demonstrating that.)

I don't often want to use dicts and lists in the same code in this way, but
I think the crucial point about the comparison with dicts is that code like
this is simpler and clearer if you do something horrible like this, just to
get .get():

>>> argdict = dict(enumerate(args))

Ed

P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO solve)
this problem doesn't mean it should supersede this discussion. Personally,
I don't think I'd use except-expressions, but I would use list.get.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Joao S. O. Bueno]

I see no reason to introduce clutter like this at this point in time -
 code needing to run in both Py 2 nd 3, if not using something like
"six" could do:

compat.py
try:
 unicode
except NameError:
 unicode = basestring = str

elsewhere:
from compat import unicode, basestring


Or rather:

try:
unicode
else:
str = basestring = unicode

and
from compat import str
# therefore having Python3 valid and clear code from here.

On 3 March 2017 at 11:37, Ryan Birmingham  wrote:
> The thread is here in the archive
> (https://mail.python.org/pipermail/python-ideas/2016-June/040761.html) if
> anyone's wondering context, as I was.
>
> In short, someone wanted an alias from string to basestring.
>  This is addressed in the "What's new in Python 3.0"
> (https://docs.python.org/3/whatsnew/3.0.html) page:
>>
>> The built-in basestring abstract type was removed. Use str instead. The
>> strand bytes types don’t have functionality enough in common to warrant a
>> shared base class. The 2to3 tool (see below) replaces every occurrence of
>> basestring with str.
>
> Personally, I have no issue with leaving an alias like this in 2to3, since
> adding it to the language feels more like forced backwards compatibility to
> me.
>
> That said, there are more related subtleties on the "What's new in Python
> 3.0" page, some of which seem less intuitive, so I understand where a desire
> like this would come from. Would more specific and succinct documentation on
> this change alone help?
>
> -Ryan Birmingham
>
> On 3 March 2017 at 06:44, Thomas Güttler 
> wrote:
>>
>> I found this in an old post:
>>
>> > Maybe too late now but there should have been 'unicode',
>> > 'basestring' as aliases for 'str'.
>>
>> I guess it is too late to think about it again ...
>>
>> Regards,
>>   Thomas Güttler
>>
>>
>> --
>> Thomas Guettler http://www.thomas-guettler.de/
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Yury Selivanov]

TBH I think that optional parameters isn't a problem requiring new
syntax. We probably do need syntax for positional-only arguments
(since we already have  them in a way), but optional parameters
can be solved easily without a new syntax.

Syntax like:

1. def a(?foo),
2. def a(foo=pass),
3. def a([foo]),

will complicate the language too much IMO.

Yury

On 2017-03-03 9:29 AM, Victor Stinner wrote:

Since yet another sentinel singleton sounds like a dead end, I suggest
to use [arg=value] syntax and require a default value in the
prototype, as currently required for *optional keyword* arguments.

"[...]" syntax for optional parameter is commonly used in Python
documentation (but the exact syntax for multiple optional arguments is
different than what I propose, see below). I already saw this syntax
for optional parameters in C and PHP languages at least.

Python prototype of the standard library and their generated signature:

 def bool([x=False])
 => bool([x])

 def bytearray([source=None], [encoding=None], errors="strict")
 => bytearray([source], [encoding], [errors])

 # in practice, default value of 'default' parameter (and maybe also 'key'?)
 # will more likely be a custom sentinel
 def sum(iterable, *args, [key=None], [default=None])
 => sum(iterable, *args, [key], [default])

 # "/" is an hypothetical marker for positional-only arguments
 def str.replace(old, new, [count=-1], /)
 => str.replace(old, new, [count], /)

 def pickle.dump(obj, file, [protocol=3], *, fix_imports=True)
 => pickle.dump(obj, file, [protocol], *, fix_imports=True)

An alternative for generated signature of multiple optional arguments
is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan
of nested [...], IMHO it's harder to read. And I like the idea of
having a signature closer to the actual Python code.


Invalid syntaxes raising SyntaxError:

* no default value: "def func([x]): ..."
* optional arguments before *args: "def func(arg, [opt=None], *args):"

In practice, calling a function without an optional argument or pass
the (private?) sentinel as the optional argument should have the same
behaviour. Each module is free to decide how the sentinel is exposed
or not. For example, the inspect module has 2 sentinels: _empty is
exposed as Signature.empty and Parameter.empty, whereas _void is
private.

If I understood correctly, Argument Clinic already supports optional
positional arguments, and so doesn't need to be changed.


I'm not sure that it's useful for optional keyword-only arguments:

def func(*, [arg=None])
=> func(*, [arg])

The only difference with optional keyword-only arguments with a
default value is the signature:

def func(*, arg=None)
=> func(*, arg=None)

See also the discussion on converting the bisect functions to Argument
Clinic and issues with the generated signature:
http://bugs.python.org/issue28754

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Ryan Birmingham]

The thread is here in the archive (https://mail.python.org/
pipermail/python-ideas/2016-June/040761.html) if anyone's wondering
context, as I was.

In short, someone wanted an alias from string to basestring.
 This is addressed in the "What's new in Python 3.0" (
https://docs.python.org/3/whatsnew/3.0.html) page:

>
>- The built-in basestring abstract type was removed. Use str
> instead. The str
>and bytes
> types don’t
>have functionality enough in common to warrant a shared base class. The
>2to3 tool (see below) replaces every occurrence of basestring with str
>.
>
> Personally, I have no issue with leaving an alias like this in 2to3, since
adding it to the language feels more like forced backwards compatibility to
me.

That said, there are more related subtleties on the "What's new in Python
3.0" page, some of which seem less intuitive, so I understand where a
desire like this would come from. Would more specific and succinct
documentation on this change alone help?

-Ryan Birmingham

On 3 March 2017 at 06:44, Thomas Güttler 
wrote:

> I found this in an old post:
>
> > Maybe too late now but there should have been 'unicode',
> > 'basestring' as aliases for 'str'.
>
> I guess it is too late to think about it again ...
>
> Regards,
>   Thomas Güttler
>
>
> --
> Thomas Guettler http://www.thomas-guettler.de/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Victor Stinner]

Since yet another sentinel singleton sounds like a dead end, I suggest
to use [arg=value] syntax and require a default value in the
prototype, as currently required for *optional keyword* arguments.

"[...]" syntax for optional parameter is commonly used in Python
documentation (but the exact syntax for multiple optional arguments is
different than what I propose, see below). I already saw this syntax
for optional parameters in C and PHP languages at least.

Python prototype of the standard library and their generated signature:

def bool([x=False])
=> bool([x])

def bytearray([source=None], [encoding=None], errors="strict")
=> bytearray([source], [encoding], [errors])

# in practice, default value of 'default' parameter (and maybe also 'key'?)
# will more likely be a custom sentinel
def sum(iterable, *args, [key=None], [default=None])
=> sum(iterable, *args, [key], [default])

# "/" is an hypothetical marker for positional-only arguments
def str.replace(old, new, [count=-1], /)
=> str.replace(old, new, [count], /)

def pickle.dump(obj, file, [protocol=3], *, fix_imports=True)
=> pickle.dump(obj, file, [protocol], *, fix_imports=True)

An alternative for generated signature of multiple optional arguments
is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan
of nested [...], IMHO it's harder to read. And I like the idea of
having a signature closer to the actual Python code.


Invalid syntaxes raising SyntaxError:

* no default value: "def func([x]): ..."
* optional arguments before *args: "def func(arg, [opt=None], *args):"

In practice, calling a function without an optional argument or pass
the (private?) sentinel as the optional argument should have the same
behaviour. Each module is free to decide how the sentinel is exposed
or not. For example, the inspect module has 2 sentinels: _empty is
exposed as Signature.empty and Parameter.empty, whereas _void is
private.

If I understood correctly, Argument Clinic already supports optional
positional arguments, and so doesn't need to be changed.


I'm not sure that it's useful for optional keyword-only arguments:

def func(*, [arg=None])
=> func(*, [arg])

The only difference with optional keyword-only arguments with a
default value is the signature:

def func(*, arg=None)
=> func(*, arg=None)

See also the discussion on converting the bisect functions to Argument
Clinic and issues with the generated signature:
http://bugs.python.org/issue28754

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Sven R. Kunze]

On 03.03.2017 14:06, Victor Stinner wrote:

2017-03-03 6:13 GMT+01:00 Mike Miller :

Agreed, I've rarely found a need for a "second None" or sentinel either, but
once every few years I do.  So, this use case doesn't seem to be common
enough to devote special syntax or a keyword to from my perspective.

The question here is how to have an official support of this feature
in inspect.signature().

If we go to the special value (singleton) way, Ellispis doesn't work
neither since a few modules use Ellipsis for legit use case. Recent
user: the typing module for "Callable[[arg, ...], result]".


Exactly.

So, it should be obvious to you, that introducing "official" support 
leads yet to an endless chain of "but I would need yet another None" 
because we already use [None, Undefined, NotUsed, Ellipsis, , 
pypi project] in our projects.


Having every project rolling their own "NotDefined" makes it completely 
incompatible to each other. So, it's not possible to plug in return 
values to other functions and gets bitten.



Not providing an "official" solution, solves the matter.


Best,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Optional parameters without default value

[Victor Stinner]

2017-03-03 6:13 GMT+01:00 Mike Miller :
> Agreed, I've rarely found a need for a "second None" or sentinel either, but
> once every few years I do.  So, this use case doesn't seem to be common
> enough to devote special syntax or a keyword to from my perspective.

The question here is how to have an official support of this feature
in inspect.signature().

If we go to the special value (singleton) way, Ellispis doesn't work
neither since a few modules use Ellipsis for legit use case. Recent
user: the typing module for "Callable[[arg, ...], result]".

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Thomas Güttler]

I found this in an old post:

> Maybe too late now but there should have been 'unicode',
> 'basestring' as aliases for 'str'.

I guess it is too late to think about it again ...

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 01.03.2017 06:34, Ethan Furman wrote:
On the bright side, if enough use-cases of this type come up (pesky 
try/except for a simple situation), we may be able to get Guido to 
reconsider PEP 463.  I certainly think PEP 463 makes a lot more sense 
that adding list.get().


It then would make sense to remove .get() on dicts.  ;-)


Regards,
Sven


...
and to remove parameter "default" of max().
and to remove parameter "default" of getattr().
...

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] for/except/else

[Sven R. Kunze]

On 03.03.2017 09:47, Wolfgang Maier wrote:
However, the fact that else exists generates a regrettable asymmetry 
in that there is direct language support for detecting one outcome, 
but not the other.


Stressing the analogy to try/except/else one more time, it's as if 
"else" wasn't available for try blocks. You could always use a flag to 
substitute for it:


dealt_with_exception = False
try:
do_stuff()
except:
deal_with_exception()
dealt_with_exception = True
if dealt_with_exception:
do_stuff_you_would_do_in_an_else_block()


Even worse when we think about the "finally" clause.

Regards,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] for/except/else

[Wolfgang Maier]

On 03/03/2017 04:36 AM, Nick Coghlan wrote:

On 2 March 2017 at 21:06, Wolfgang Maier
mailto:wolfgang.ma...@biologie.uni-freiburg.de>> wrote:


- overall I looked at 114 code blocks that contain one or more breaks



Thanks for doing that research :)



Of the remaining 19 non-trivial cases

- 9 are variations of your classical search idiom above, i.e.,
there's an else clause there and nothing more is needed

- 6 are variations of your "nested side-effects" form presented
above with debatable (see above) benefit from except break

- 2 do not use an else clause currently, but have multiple breaks
that do partly redundant things that could be combined in a single
except break clause



Those 8 cases could also be reviewed to see whether a flag variable
might be clearer than relying on nested side effects or code repetition.



[...]



This is a case where a flag variable may be easier to read than loop
state manipulations:

may_have_common_prefix = True
while may_have_common_prefix:
prefix = None
for item in items:
if not item:
may_have_common_prefix = False
break
if prefix is None:
prefix = item[0]
elif item[0] != prefix:
may_have_common_prefix = False
break
else:
# all subitems start with a common "prefix".
# move it out of the branch
for item in items:
del item[0]
subpatternappend(prefix)

Although the whole thing could likely be cleaned up even more via
itertools.zip_longest:

for first_uncommon_idx, aligned_entries in
enumerate(itertools.zip_longest(*items)):
if not all_true_and_same(aligned_entries):
break
else:
# Everything was common, so clear all entries
first_uncommon_idx = None
for item in items:
del item[:first_uncommon_idx]

(Batching the deletes like that may even be slightly faster than
deleting common entries one at a time)

Given the following helper function:

def all_true_and_same(entries):
itr = iter(entries)
try:
first_entry = next(itr)
except StopIteration:
return False
if not first_entry:
return False
for entry in itr:
if not entry or entry != first_entry:
return False
return True


- finally, 1 is a complicated break dance to achieve sth that
clearly would have been easier with except break; from typing.py:




[...]



I think is another case that is asking for the inner loop to be factored
out to a named function, not for reasons of re-use, but for reasons of
making the code more readable and self-documenting :)



It's true that using a flag or factoring out redundant code is always a 
possibility. Having the except clause would clearly not let people do 
anything they couldn't have done before.
On the other hand, the same is true for the else clause - it's only 
advantage here is that it's existing already - because a single flag 
could always distinguish between a break having occurred or not:


brk = False
for item in iterable:
if some_condition:
brk = True
break
if brk:
do_stuff_upon_breaking_out()
else:
do_alternative_stuff()

is a general pattern that would always work without except *and* else.

However, the fact that else exists generates a regrettable asymmetry in 
that there is direct language support for detecting one outcome, but not 
the other.


Stressing the analogy to try/except/else one more time, it's as if 
"else" wasn't available for try blocks. You could always use a flag to 
substitute for it:


dealt_with_exception = False
try:
do_stuff()
except:
deal_with_exception()
dealt_with_exception = True
if dealt_with_exception:
do_stuff_you_would_do_in_an_else_block()

So IMO the real difference here is that the except clause after for 
would require adding it to the language, while the else clauses are 
there already. With that we're back at the high bar for adding new syntax :(
A somewhat similar case that comes to mind here is PEP 315 -- Enhanced 
While Loop, which got rejected for two reasons, the first one being 
pretty much the same as the argument here, i.e., that instead of the 
proposed do .. while it's always possible to factor out or duplicate a 
line of code. However, the second reason was that it required the new 
"do" keyword, something not necessary for the current suggestion.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] for/except/else

[Wolfgang Maier]

On 03/02/2017 07:05 PM, Brett Cannon wrote:


- overall I looked at 114 code blocks that contain one or more breaks


I wanted to say thanks for taking the time to go through the stdlib and
doing such a thorough analysis of the impact of your suggestion! It
always helps to have real-world numbers to know whether an idea will be
useful (or not).



- 84 of these are trivial use cases that simply break out of a while
True block or terminate a while/for loop prematurely (no use for any
follow-up clause there)

- 8 more are causing a side-effect before a single break, and it would
be pointless to put this into an except break clause

- 3 more cause different, non-redundant side-effects before different
breaks from the same loop and, obviously, an except break clause would
not help them either

=> So the vast majority of breaks does *not* need an except break *nor*
an else clause, but that's just as expected.


Of the remaining 19 non-trivial cases

- 9 are variations of your classical search idiom above, i.e., there's
an else clause there and nothing more is needed

- 6 are variations of your "nested side-effects" form presented above
with debatable (see above) benefit from except break

- 2 do not use an else clause currently, but have multiple breaks that
do partly redundant things that could be combined in a single except
break clause

- 1 is an example of breaking out of two loops; from
sre_parse._parse_sub:



[...]


- finally, 1 is a complicated break dance to achieve sth that clearly
would have been easier with except break; from typing.py:

My summary: I do see use-cases for the except break clause, but,
admittedly, they are relatively rare and may be not worth the hassle of
introducing new syntax.


IOW out of 114 cases, 4 may benefit from an 'except' block? If I'm
reading those numbers correctly then ~3.5% of cases would benefit which
isn't high enough to add the syntax and related complexity IMO.


Hmm, I'm not sure how much sense it makes to express this in percent 
since the total your comparing to is rather arbitrary.
The 114 cases include *any* for/while loop I could find that contains at 
least a single break. More than 90 of these loops do not use an "else" 
clause either showing that even this currently supported syntax is used 
rarely.
I found only 19 cases that are complex enough to be candidates for an 
except clause (17 of these use the else clause). For 9 of these 19 (the 
ones using the classical search idiom) an except clause would not be 
applicable, but it could be used in the 10 remaining cases (though all 
of them could also make use of a flag or could be refactored instead). 
So depending on what you want to emphasize you could also say that the 
proposal could affect as much as 10/19 or 52.6% of cases.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] get() method for list and tuples

[Sven R. Kunze]

On 02.03.2017 04:41, Chris Barker wrote:
Maybe someone else will chime in with more "I'd really have a use for 
this" examples.


It also makes refactoring easier.


Regards,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/