[Python-ideas] Re: Deferred evaluation (was: PEP 671: Syntax for late-bound function argument defaults)

[Sven R. Kunze]

On 31.10.21 12:34, Chris Angelico wrote:

Google's smarter than that. I've searched for symbols before and found
plenty of good results. For instance, I can search for information
about the @ sign before a function, or independently, for a @ b, and
get information about decorators or matrix multiplication. We don't
need words - especially not words that will break people's code - in
order for people to find information.


It seems we disagree here. :)


It's a completely different feature, and has very different
consequences. It is not a complete replacement for default
expressions. Notably, it can't refer to anything in the caller's
context, without breaking a lot of things about Python's namespacing
model.


People on the threads said that they simply want to initialize an empty 
list [] by a desire to avoid the None scheme.


I would rather solve those kind of issues than help to squeeze 
complicated logic into default parameters. But that's just my take on it 
looking from testing and maintenance perspective here.


Another idea that comes to my mind is that a separate object allows more 
in terms of the open-closed principle than a fixed syntax used for one 
single, hopefully best use-case. Thinking here of the call-by-name and 
call-by-need evaluation. About the namespacing issue: I disagree here 
because it is always possible to interface these kind of variables 
explicitly (like we do with globals, locals, builtins, etc.). So, it 
would be a compatible addition. Still, we talk about default parameters.


Best
Sven


* Trying that searches do not present the word "matrix multiplication"; 
at least not to me.



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MWQDG5S3CSI5Z35QJCHB5G4H6OXRBRMB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deferred evaluation (was: PEP 671: Syntax for late-bound function argument defaults)

[Sven R. Kunze]

Actually, the "defer:"-syntax is really readable and searchable compared 
to the cryptic comparison operator used in the proposal. Just thinking 
towards "googleability".


Furthermore, the concept is even more general than parameter definition 
of functions and methods. I guess a lot of people have already tryied to 
implement this kind of object various times before (proxy objects, 
transparent futures etc.)


It also would fit the current semantics of default parameters of Python.

Cheers
Sven

On 24.10.21 16:37, David Mertz, Ph.D. wrote:

On Sun, Oct 24, 2021, 10:11 AM Chris Angelico

Not sure I understand. Your example was something like:

def fn2(thing):
    a, b = 13, 21
    x = 5
    print("Thing is:", thing)

def f(x=defer: a + b):
    a, b = 3, 5
    fn2(defer: x)
    return x

So inside f(), "defer: a + b" will look in f's scope and use the
variables a and b from there, but passing a "defer: x" to fn2 will
use x from f's scope, and then a and b from fn2's?


Yes, basically as you describe. A "deferred object" is basically just 
a string that knows to wrap itself in eval() when accessed (maybe 
Steven's "thunk" is a better term... But definitely something 
first-class, unlike in Algol).


So within fn2() the parameter 'thing' is bound to an object like 
''.


Indeed this means that the 'defer:' or 'thunk' or special symbol 
spelling, has to decide whether the thing being deferred is already 
itself a deferred object. If so, just pass along the identical object 
rather than treat it as a new expression.


At least that's what would feel most intuitive to me. But I'm 
deliberately not pushing a specific syntax. For example, if we didn't 
want to "reuse" the spelling 'defer:' for both creating and passing a 
deferred object, we could have different spellings.


def f(x=defer: a + b):
    a, b = 3, 5
    fn2(noeval: x)
    return x

... I don't like that spelling, but just showing the concept.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RMHPLSJ3U67I4TCXS4SVSWNDEATHOVDD/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RMFANJ5FAGXP2IFYFFWVDYSNXP7CO2QF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SimpleNamespace vs object

[Sven R. Kunze]

On 18.02.21 05:43, Chris Angelico wrote:


On Thu, Feb 18, 2021 at 1:59 PM Ben Rudiak-Gould  wrote:

It seems to me that all you'd have to do is add a line or two to the add_dict 
logic in type_new so that instances of object get a dict. Then instances of 
object would get a dict, and nothing else would change.


That's actually a pretty neat idea. :-)


What's so hard about using a different type?


Didnt we already discuss it somewhere else? Many programmers and 
computer scientists think in "objects", "object-oriented programming" etc.



Especially since the
vanilla object repr is basically useless, but SimpleNamespace can tell
you what it's carrying.


True but it seems this have never been an issue with "lambda:0".


Orthogonal point: SimpleNamespace could easily be made
JSON-serializable (as a dict), if that would be of value.


Sounds great. :-)


Best,
Sven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ML5IT7GLLCHPZSC5JS4GXGVQ5L43XBMN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] SimpleNamespace vs object

[Sven R. Kunze]

Starting this as a new thread for the interested reader:

On 17.02.21 11:18, Chris Angelico wrote:

On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze  wrote:

Still think that "object()" should be writable since this seems like an
arbitrary restriction (+SimpleNamespace is no builtin and at least I
would use object() for fast PoCs or dirty hackery). But I guess there's
been discussion around this already.


[...]


Using SimpleNamespace is the best way to do this, and maybe there's a
good argument for making it a builtin (or at least giving it a shorter
name), but changing object would be problematic.


I would be skeptical that either those ideas would help a lot. My 
reasoning is the following:



Given the usual terminology in computer science and programming courses, 
we think in "objects". "Namespaces" on the other side are quite static, 
usual representing surroundings or environments which in turn can 
contain "objects". Sadly, the terminology-wise ideal solution is blocked 
by technical reasons.



The thinking in the concepting use-case goes like "I need a blank object 
which I can do random things with" (yes, including attaching new 
attributes to it, maybe other stuff as well).


The thinking "hey I need a (simple) namespace which I can attach 
attributes to" requires quite some thoughts especially when being in a 
more "concepting"/"trying out ideas" mood.


In this phase, one does not simply know what one needs ("could be 
sentinel only", "could be data carrying", "could be signalling", "could 
something else") and things move quickly.



So, just as an example when renaming/aliasing "types.SimpleNamespace" to 
"builtins.thing", my expectation would be that people could be horribly 
confused seeing "object" and "thing" being a builtin when used in a 
project simultaneously. This always leads to questions like "what to use 
now?"



As a conclusion I would say let's leave it like it is since it's a minor 
issue.



Best
Sven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3IICAAKFYPL7JETS26CHPUVRVQS7KW3Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Sven R. Kunze]

On 16.02.21 17:26, Steven D'Aprano wrote:



 >>> from types import SimpleNamespace
 >>> obj = SimpleNamespace()
 >>> obj.spam = 1
 >>> obj
 namespace(spam=1)

Gives you a nice repr so when you are debugging you can actually see
what the object is.



I see that's Python 3 (vs. Python2.7 - yeah I know, legacy code). But 
thanks for the remark! :-)


Still think that "object()" should be writable since this seems like an 
arbitrary restriction (+SimpleNamespace is no builtin and at least I 
would use object() for fast PoCs or dirty hackery). But I guess there's 
been discussion around this already.



Best,
Sven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4BOFWAJUQZ7E5UCP7NWRRBG6YN4CSN23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Arrow functions polyfill

[Sven R. Kunze]

On 15.02.21 22:42, Greg Ewing wrote:

On 16/02/21 6:29 am, Guido van Rossum wrote:
I can sympathize with trying to get a replacement for lambda, because 
many other languages have jumped on the arrow bandwagon, and few 
Python first-time programmers have enough of a CS background to 
recognize the significance of the word lambda.


I think there's also just a desire for brevity. In the situations
where it's appropriate to use a lambda, you want something very
compact, and "lambda" is a rather long and unwieldy thing to have
stuck in there.



I hope I am not saying something outrageous now but we used

>>> obj = lambda: 0

to define an anomyous object without the need to define a class first 
(speaking of brevity).



"Why?", you may ask. The reason is that:

>>> obj = object()

does not create an instance of obj that can be used to add some 
attributes later on.



So, my conclusion is, if "()->0" replaces "lambda:0", this very 
important use-case should still be possible. :-P


Or make "object()" mutable. :-D



[...]
I'm not arguing for or against anything here, just exploring
possible reasons why the idea of lambda-replacement comes up
so often.


I agree the most obvious reason would be that it looks different than in 
other languages (same for me when I discovered it like 10 years ago).


But as Guido said it's fixed already and I don't think it adds much to 
the language IMHO. Maybe, I'm too old to see the benefit of changing it.



I like named functions because, well, they have a name attached to them 
and that makes bug-fixing, debugging, logging, etc. much easier.



Best,
Sven

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YX7F2WM6QFWCKDRCSZHXAZ5HJ3LOSIMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib enhancements

[Sven R. Kunze]

On 31.12.20 15:32, Todd wrote:



5. Stem with no suffixes

The stem property only takes off the last suffix, but even in the
example given ('my/library.tar.gz') it isn't really useful
because the suffix has two parts ('.tar' and '.gz').  I suggest
another property, probably called "rootstem" or "basestem", that
takes off all the suffixes, using the same logic as the
"suffixes" property.  This is another symmetry issue: it is
possible to extract all the suffixes, but not remove them.


+1

Does anybody rely of this behavior of ".stem"? It always seemed
odd to me but that might be because of the use-cases I work with.

So, another possibility would be to fix "stem" to do what makes sense.


This is a backwards compatibility break and I don't want to get into 
the complications of doing that.  There is really no benefit to 
breaking backwards compatibility.  I would strongly suspect renaming a 
method then making a new, completely different method with the same 
name is not going to happen.



I disagree that breaking compatibility has no benefit. The benefit is 
always long-term but I understand that you don't want to go through 
deprecating and re-adding the same name.



One concern I have is that "rootsteam" or "basestem" is not really a 
well-defined concept (as was "stem" when it was added - at least the 
multiple suffix concept was there but has little influence on the naming 
of the stem concept).



We already have concepts like:

basename << rightmost part of a path
root << toplevel node of a tree; also filesystem



The burden is just too high relative to the benefits.


What exactly is the burden?


Best
Sven

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OEATQWHWKD5WLZDBGILLRVLHBKEGE7JE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib enhancements

[Sven R. Kunze]

Last but not least, I tend more towards the "rmtree" method just
to make it crystal clear to everyone. Maybe docs could cross-refer
both methods. Tree manipulations are inherently complicated and a
lot can go wrong. Symmetry is not 100% given as you might delete
more than what you've created (which was a single node path).


We already have tree removal functionality that this can use internally.



I am not much concerned about the internals; shutil.rmtree should work 
fine here.


I am more concerned with the external interface (see also 
root/base/stem) and its impression on developers.



As for the name, one thing to consider is that making a recursive tree 
uses an argument.


And I think the argument would need to be keyword-only to avoid 
accidentally invoking it.



Why not adding a new method?

I am still not convinced from a safety perspective that adding a new 
meaning-changing argument to a removal function is such a good idea. 
Just consider the following example.



When deleting /my/soon/to/be/deleted/dir, you DO NOT delete a simple 
directory as the method name "rmdir" would suggest:


- /my/soon/to/be/deleted/dir

instead you delete something like this:

- /my/soon/to/be/deleted/dir/d1/f1
- /my/soon/to/be/deleted/dir/d1/d3/f1
- /my/soon/to/be/deleted/dir/d1/d3/f2
- /my/soon/to/be/deleted/dir/d1/d3
- /my/soon/to/be/deleted/dir/d1/f2
- /my/soon/to/be/deleted/dir/d1/f3
- /my/soon/to/be/deleted/dir/d1
- /my/soon/to/be/deleted/dir/d2/f1
- /my/soon/to/be/deleted/dir/d2/f2
- /my/soon/to/be/deleted/dir/d2
- /my/soon/to/be/deleted/dir


That is a completely different beast (a complete tree) and there is no 
way back once deleted.


And there are a couple of other reasons when I look as the interface of 
shutil.rmtree and what "recursively" really means for pathlib.



Best
Sven

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IWI6ES76CVZ3XEQMTP6PS2JKJWPCJVO3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib enhancements

[Sven R. Kunze]

I split my answers up to address different issues in different threads.


On 31.12.20 15:32, Todd wrote:

Hi Sven,

Thanks for your support and feedback.


On Thu, Dec 31, 2020, 07:23 Sven R. Kunze <mailto:srku...@mail.de>> wrote:


Hi Todd,

my comments below. Also would offer my time for reviewing/testing
if wanted.


On 22.11.20 20:53, Todd wrote:

I know enhancements to pathlib gets brought up occasionally, but
it doesn't look like anyone has been willing to take the
initiative and see things through to completion.  I am willing to
keep the ball rolling here and even implement these myself.  I
have some suggestions and I would like to discuss them.  I don't
think any of them are significant enough to require a pep.  These
can be split it into independent threads if anyone prefers.

1. copy

The big one people keep bringing up that I strongly agree on is a
"copy" method.  This is really the only common file manipulation
task that currently isn't possible.  You can make files, read
them, move them, delete them, create directories, even do less
common operations like change owners or create symlinks or hard
links.


I really would appreciate that one. If I could through in another
detail which we needed a lot:

- atomic_copy or copy(atomic=True) whatever form you prefer

It is not as easy to achieve as it may look on the first sight.
Especially when it comes to tempfiles and permissions. The use
cases of atomic copy included scenarios for multiple parallel
access of files like caches in web development.


Is there already support for atomic writes in the standard library?  I 
am not planning on implementing anything new, only exposing existing 
functionality.  Adding atomic operations to the stslib would likely 
require a pep and substantial discussion of API and implementation.  I 
don't really have the background to do that.



So far I didn't find any of this implemented in the stdlib but please 
correct me if I am wrong.



As far as I know, one working pattern would be

1. creating a file or the directory structure using tempfile
2. then setting permissions from the original directory object
3. and finally moving it to its final destination (path and name)

The last part is done atomically at least in Linux (rename) and Windows 
(ReplaceFile).


Especially setting permission an easy oversight which can cause issues 
e.g. with xsendfile.



What would be the steps to do get it done?


Best
Sven

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CKYIXT6XIR4IVYENNW2UBC6SP3PDYAGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib enhancements

[Sven R. Kunze]

Hi Todd,

my comments below. Also would offer my time for reviewing/testing if wanted.


On 22.11.20 20:53, Todd wrote:
I know enhancements to pathlib gets brought up occasionally, but it 
doesn't look like anyone has been willing to take the initiative and 
see things through to completion.  I am willing to keep the ball 
rolling here and even implement these myself.  I have some suggestions 
and I would like to discuss them.  I don't think any of them are 
significant enough to require a pep.  These can be split it into 
independent threads if anyone prefers.


1. copy

The big one people keep bringing up that I strongly agree on is a 
"copy" method.  This is really the only common file manipulation task 
that currently isn't possible.  You can make files, read them, move 
them, delete them, create directories, even do less common operations 
like change owners or create symlinks or hard links.


I really would appreciate that one. If I could through in another detail 
which we needed a lot:


- atomic_copy or copy(atomic=True) whatever form you prefer

It is not as easy to achieve as it may look on the first sight. 
Especially when it comes to tempfiles and permissions. The use cases of 
atomic copy included scenarios for multiple parallel access of files 
like caches in web development.


A common objection is that pathlib doesn't work on multiple paths.  
But that isn't the case.  There are a ton of methods that do that, 
including:


   * symlink_to
   * link_to
   * rename
   * replace
   * glob
   * rglob
   * iterdir
   * is_relative_to
   * relative_to
   * samefile
I think this is really the only common file operation that someone 
would need to switch to a different module to do, and it seems pretty 
strange to me to be able to make symbolic or hard links to a file but 
not straight up copy one.


2. recursive remove

This could be a "recursive" option to "rmdir" or a "rmtree" method (I 
prefer the option).  The main reason for this is symmetry.  It is 
possible to create a tree of folders (using "mkdir(parents=True)"), 
but once you do that you cannot remove it again in a straightforward way.


Importing shutil does not seem to be a big deal but I agree that it's 
somehow weird to be missing.


Correct me if I'm wrong, but os.path somehow is closer to OS-level 
operations whereas shutil basically provides all the missing convenience 
features that sh provided.


So, to me it boils down to the question if pathlib is a completely new 
paradigm. If so, then sure let's add it. Additionally, I like the 
"batteries included" theme of Python.


Last but not least, I tend more towards the "rmtree" method just to make 
it crystal clear to everyone. Maybe docs could cross-refer both methods. 
Tree manipulations are inherently complicated and a lot can go wrong. 
Symmetry is not 100% given as you might delete more than what you've 
created (which was a single node path).




3. newLine for write_text

This is the only relevant option that "Path.open" has but 
"Path.write_text" doesn't, and is a serious omission when dealing with 
multiple operating systems.


+1



4. uid and gid

You can get the owner and group name of a file (with the "owner" and 
"group" methods), but there is no easy way to get the corresponding 
number.

+1


5. Stem with no suffixes

The stem property only takes off the last suffix, but even in the 
example given ('my/library.tar.gz') it isn't really useful because the 
suffix has two parts ('.tar' and '.gz').  I suggest another property, 
probably called "rootstem" or "basestem", that takes off all the 
suffixes, using the same logic as the "suffixes" property.  This is 
another symmetry issue: it is possible to extract all the suffixes, 
but not remove them.


+1

Does anybody rely of this behavior of ".stem"? It always seemed odd to 
me but that might be because of the use-cases I work with.


So, another possibility would be to fix "stem" to do what makes sense.

Maybe also a renaming the concept "suffix" to "final_suffix" (also more 
concurrent to what docs says: "The file extension of the final 
component, if any:").


To me that has always been the weirdest conceptual behavior of the lib. 
Not sure if that's possible to fix before people need time machines.




6. with_suffixes

Equivalent to with_suffix, but replacing all suffixes. Again, this is 
a symmetry issue.  It is hard to manipulate all the suffixes right 
now, as the example show.  You can add them or extract them, but not 
change them without doing several steps.


+1

Same comment like for basestem.



7. exist_ok for is_* methods

Currently all the is_* methods (such as is_file) return False if the 
file doesn't exist or if it is a broken symlink. This can be 
dangerous, since it is not trivially easy to tell if you are dealing 
with the wrong type of file vs. a missing file.  And it isn't obvious 
behavior just from the method name.  I suggest adding an "exist_ok" 
argument to all of these, with the default 

Re: [Python-ideas] Inline assignments using "given" clauses

[Sven R. Kunze]

On 13.05.2018 11:23, Peter O'Connor wrote:

 *Correction: Above code should read:

    outputs = []
state = initial_state
for inp in inputs:
out, state = my_update_func(inp, state)
outputs.append(out)



Question still stands if this type of code needs compaction in the first 
place?


List comprehensions usually have some sort of declarative touch (set 
builder notation).


Even though, striving for a more compacted version, I tend to think that 
using a declarative version of it doesn't serve it well in the long term.



We recently came across the following code snippet in our source base 
(1st answer of 
https://stackoverflow.com/questions/480214/how-do-you-remove-duplicates-from-a-list-whilst-preserving-order). 
It was absolutely not comprehensible.



Your example is inherently imperative because the internal state changes 
from iteration to iteration; something unusual for set builder notation.



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] Inline assignments using "given" clauses

[Sven R. Kunze]

On 11.05.2018 13:43, Nick Coghlan wrote:
I've been thinking about this problem, and I think for the 
If/elif/while cases it's actually possible to allow the "binding is 
the same as the condition" case to be simplified to:


    if command =  pattern.match(the_string):
    ...
    elif command =  other_pattern.match(the_string):
    ...

    while data = read_data():
    ...

Allowing this would be part of the definition of the if/elif/while 
statement headers, rather than a general purpose assignment expression.


I can imagine that this will cover 80 to 90% of the usecases and it's 
readable as well.



A similar enhancement could be made to conditional expressions 
(adjusting their grammar to permit "EXPR if NAME = EXPR else EXPR") 
and filter clauses in comprehensions (allowing "EXPR for TARGET in 
EXPR if NAME = EXPR").


Not sure if that is too much for now. List comprehensions tend to be 
longer than expected, the same goes for the ternary expression.


Maybe, we could start with the 90% case and whether the need for more 
arises.



In essence, "if", "elif", and "while" would all allow for an "implied 
given" clause in order to simplify the 90% case where the desired 
condition and the bound expression are the same.


Exactly. Maybe, even here: let's do just the 90% case. And if a lot of 
people need finer control, we can reconsider :=/given/as.



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] Inline assignments using "given" clauses

[Sven R. Kunze]

On 11.05.2018 09:38, Greg Ewing wrote:

Kirill Balunov wrote:


While for those who are familiar with Pascal, Icon and other 
languages that use this syntax, this - `:=` looks natural.


As someone familiar with Pascal, I think the similarity to
the Pascal assignment operator is actually an argument
*against* it. Knowing what it means in Pascal is confusing,
because Pascal's ":=" is equivalent to Python's "=" (it's
strictly a statement, and can't be used in expressions).


Same here. It means something different.

Also coding in Pascal was annoying from the beginning with its extremely 
verbose syntax like begin/end etc.
So, ":=" also felt like "why the hell do we need a colon in front of the 
equal sign?"

Absolutely unnecessary bloat, like almost everything in Pascal.

Maybe that's also part, why I am -1 on the proposal. Who knows...
___
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] Inline assignments using "given" clauses

[Sven R. Kunze]

On 11.05.2018 09:33, Greg Ewing wrote:

Gustavo Carneiro wrote:
IMHO, all these toy examples don't translate well to the real world 
because they tend to use very short variable names while in real 
world [good written code] tends to select longer more descriptive 
variable names.


I don't believe that's always true. It depends on the context.
Sometimes, using long variable names can make code *harder*
to read.

I don't think there's anything unrealistic about this
example:

   if m given m = pattern.match(the_string):
  nugget = m.group(2)


I gather we don't talk about interactive usage.

So, I grepped through part of our code-base. Like it or not, it's almost 
always called "match" there.


Like Gustavo, I also have the feeling that long-living, real-world code 
tends to have more descriptive names than all those toy examples/arguments.



Cheers,
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] Complicate str methods

[Sven R. Kunze]

Same here.

On 07.02.2018 22:57, Mike Miller wrote:

+1

I have the need for one or two of these in every project (of a certain 
size) and have to come up with solutions each time with the re module 
or a loop.


Not a fan of regex's for trivial tasks, or those that require a real 
parser.


On 2018-02-03 14:04, Franklin? Lee wrote:

___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[Sven R. Kunze]

On 22.11.2017 07:22, Nick Timkovich wrote:

Functions are great. I'm a big fan of functions. However,

1. Once there are several that all have the same thing as an argument: 
thing_operation1(thing, arg), thing_operation2(thing, arg)...it's 
about time to bind them together.
2. And especially for the heap "soft-datatype": once it's heapified, 
naively modifying it with other methods will ruin the heap invariant. 
**The actual list you pass around can't be treated as a list.**


Two important aspects to which I want to add some thoughts.

The reason why I created xheap was because I actually needed a more 
complex datastructure which required more bookkeeping:


1) custom orders on the same data (list)
2) fast removal from within the heap

The plain "Heap" implementation (object wrapper of heapq) was just for 
the sake of completion.


Cheers,
Sven

PS: I tend to think that implementing xheap was easier BECAUSE the 
stdlib provided a function-only heap implementation. Nonetheless, both 
ways do have their merits.
___
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] Should Python have user-defined constants?

[Sven R. Kunze]

On 21.11.2017 19:05, אלעזר wrote:
I don't understand the question. The use case was explained before - 
people want to have better ways to reason about their programs. 
Statically. Why dismiss it as a non-usecase? It's helpful for both 
tools and humans.


Then type annotations are for them.

But please don't clutter the core language with this.

When I read "final int x = 5;" in Java, I don't have to think about it 
anymore - it's 5. When I read "X = 5" in Python, it might be a 
constant, but it might also be a misnomer, or something that used to 
be a constant, or a class reassigned.


What about using real-world names instead of X? That could make the 
intentions crystal clear if you ask me.



Cheers,
Sven


PS: it seems to me that this resembles the typing discussions here. 
Using non-sensical variable names to explain why type annotations are 
sorely needed.

___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[Sven R. Kunze]

Maybe, that suffices: https://pypi.python.org/pypi/xheap


On 21.11.2017 03:46, bunslow wrote:

Perhaps such repetition is a sign that *something* needs to be done...

Thanks for the link though. I'm new enough to the community that it 
didn't even occur to me to search for prior discussions.


On Mon, Nov 20, 2017 at 8:38 PM, Sebastian Kreft > wrote:


This has been brought up multiple times. Last time was on this
thread
https://mail.python.org/pipermail/python-ideas/2016-October/043024.html
.

On Tue, Nov 21, 2017 at 3:13 AM, bunslow > wrote:

Nothing so bombastic this time. The heapq functions are
basically all named "heapsomething", and basically all take a
"heap" for their first argument, with supplementary args
coming after. It's a textbook example of the (hypothetical)
Object Oriented Manifesto™ where defining a class increases
type safety and programmers' conceptual clarity. There're
practically no drawbacks, and the code to be added would be
very simple. Updating the tests and docs would probably be
harder.

In pure Python, such a class would look like this:

class Heap(list):

    def __init__(self, iterable=None):
        if iterable:
            super().__init__(iterable)
        else:
            super().__init__()

        self.heapify()

    push = heapq.heappush
    pop = heapq.heappop
    pushpop = heapq.heappushpop
    replace = heapq.heapreplace
    heapify = heapq.heapify

    # This could be a simple wrapper as well, but I had the
following thoughts anyways, so here they are
    def nsmallest(self, n, key=None):
        # heapq.nsmallest makes a *max* heap of the first n
elements,
        # while we know that self is already a min heap, so we can
        # make the max heap construction faster
        self[:n] = reversed(self[:n])
        return heapq.nsmallest(n, self, key)

    # do we define nlargest on a minheap??


Wrapping around the C builtin functions (which aren't
descriptors) would be a bit harder, but not much so:

from functools import partial

class Heap(list):
    def __init__(self, iterable=None):
        if iterable:
            super().__init__(iterable)
        else:
            super().__init__()

        self.heapify = partial(heapq.heapify, self)
        self.push = partial(heapq.heappush, self)
        ...

        self.heapify()


Thoughts?

___
Python-ideas mailing list
Python-ideas@python.org 
https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/





-- 
Sebastian Kreft





___
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] Adding new lines to "Zen of Python"

[Sven R. Kunze]

On 08.09.2017 15:20, M.-A. Lemburg wrote:

On 08.09.2017 14:47, Thomas Güttler wrote:

I curious if there are any plans to update the "Zen of Python".

What could be added to the "Zen of Python"?

What do you think?

Only the Zen Master can decide on this one and it appears there's
only room for one more aphorism, but I guess that's "Less is better
than more." and it was left out for obvious reasons ;-)



My favorite. ;)


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] + operator on generators

[Sven R. Kunze]

On 30.06.2017 00:57, Jan Kaliszewski wrote:

Please, note that it can be upturned: maybe they are not so common as
they could be because of all that burden with importing from separate
module -- after all we are saying about somewhat very simple operation,
so using lists and `+` just wins because of our (programmers')
laziness. :-)


Is it laziness or is it just "the best way to do it"™? ;-)


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] Python 4: Concatenation

[Sven R. Kunze]

On 30.06.2017 13:51, Jamie Willis wrote:
Just as an aside, if a concatenation operator *was* included, a 
suitable operator would be "++", this is the concatenation operator in 
languages like Haskell (for strings) and the majority of Scala cases. 
Alternatively "<>" is an alternative, being the monoidal append 
operator in Haskell, which retains a certain similarly. I suggest 
these purely for their accepted usage, which means they should be more 
reasonable to identify.


'+' is the perfect concat operator. I love Python for this feature.

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] + operator on generators

[Sven R. Kunze]

On 28.06.2017 20:37, Koos Zevenhoven wrote:

Oh, I've been very close to getting one of those. But then I should 
probably get a pair of glasses too ;).


:D

​​That pattern annoys people and negates the benefits of views and 
generators.​


Sure, that's why I am in favor of this proposal. It would remove the 
necessity to do that in various places. :)




Sure, but you may want to turn your unknown sources into something 
predictable as soon as possible. You'll need to deal with the errors 
in the input anyway.


That's a good point.

Very often one doesn't really need a list, but just something that has 
indexing, slicing and/or len(). Wrapping things with list() can be ok, 
but uses memory and is O(n). Generating lists from all kinds of 
iterables all the time is just a whole bunch of unnecessary overhead. 
But yes, it happens, because that's the convenient way of doing it 
now. That's like going back to Python 2, but with additional calls to 
list() required. Maybe you're lucky that your iterables are small and 
not a bottle neck and/or you just don't feel guilty every time you 
call list() where you shouldn't have to ;).


Yep, exactly. That's why I like an easier way of concating them with no 
bells and whistles. Preferably like lists today. ;)



Cheers,
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] Improving Catching Exceptions

[Sven R. Kunze]

On 28.06.2017 21:14, Nathaniel Smith wrote:
With PEP 479 there was a different and better way to generate a 
StopIteration if you wanted one (just 'return'). Here I'm afraid 
existing projects might actually be relying on the implicit exception 
leakage in significant numbers :-/


My concern as well.

More generally, my impression is that this is one of the reasons why 
exceptions have fallen out of favor in more recent languages. They're 
certainly workable, and python's certainly not going to change now, 
but they do have these awkward aspects that weren't as clear 20 years 
ago and that now we have to live with.


I am quite satisfied with the ability of exceptions to expose bugs as 
fast and clear as possible. I still think we can improve on the catching 
side a little bit to narrow down the relevant exceptions.


Other than that, I would be interested to hear what system you have in 
mind. What alternative (borrowed from more recent languages) can you 
imagine?
Checking return values like C or golang? No ability to catch them at 
all? How to handle bugs in the context of UI applications where a crash 
in front of the user should be avoided?


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] Improving Catching Exceptions

[Sven R. Kunze]

On 28.06.2017 15:26, Nick Coghlan wrote:

1. In 3.3+ you can just catch ImportError, check "exc.name", and
re-raise if it's not for the module you care about


I see, didn't know that one. I gave it a try and it's not 100% the 
behavior I have expected, but one could workaround if the valid package 
structure is known. Not sure for certain.


"from foo.bar.baz import abc" can yield to "exc.name" being one of 
"foo", "foo.bar" or "foo.bar.baz". Not perfect but sort of doable.



2. There's a reasonable case to be made that importlib should include
an ImportError -> RuntimeError conversion around the call to
loader.exec_module (in the same spirit as PEP 479). That way, in:

 try:
 import myspeciallib
 except ImportError:
 import fallbacks.MySpecialLib as myspeciallib

any caught ImportError would relate to "myspeciallib", while uncaught
ImportErrors arising from *executing* "myspeciallib" will be converted
to RuntimeError, with the original ImportError as their __cause__.


Generally changing the behavior for ImportError doesn't sound like it 
would work for all projects out there.


For fallback imports, I am on your side, that's a real use case which 
can be solved by changing the behavior of ImportErrors. But for all 
imports? I don't know if that's good idea.



[People should use tools, guard against bugs and try to avoid mistakes.]


Sure, but I don't see who this can help, if I use third-party code. The 
cases, which I described in the original post, were simple cases, where 
we catch too many exception. So, I don't even have the chance to see the 
error, to file a bug report, to issue a pull request, etc. etc.



The cases I'm interested in are the ones where you're either
developing some kind of framework and you need to code that framework
defensively to guard against unexpected failures in the components
you're executing (e.g. exec_module() in the PEP 451 import protocol),
or else you're needing to adapt between two different kinds of
exception reporting protocol (e.g. KeyError to AttributeError and
vice-versa).


I am unsure what you mean by those abstract words "framework" and 
"components". But let me state it in different words: there are 
*raisers* and *catchers* which do the respective thing with exceptions.


If you control the code on both sides, things are easy to change. 
Pre-condition: you know the bug in the first place, which is hard when 
you catch too much.
If you control the raiser only, it doesn't help to say: "don't make 
mistakes, configure systems right, code better, etc." People will make 
mistakes, systems will be misconfigured, linters don't find everything, etc.
If you control the catcher only, you definitely want to narrow down the 
amount of caught exceptions as far as possible. This was the original 
intend of this thread IIRC. This way you help to discover bugs in 
raising code. Addition benefit, you catching code reacts only to the 
right exceptions.



One word about frameworks here. Django, for instance, is on both sides. 
The template engine is mostly on the catchers side, whereas the database 
layer is on the raisers side.



I get the feeling that the solutions presented here are way too 
complicated and error-prone. My opinion on this topic still is that 
catching exceptions is not mandatory. Nobody is forced to do it and it's 
even better to let exceptions bubble up to visualize bugs. If one still 
needs to catch them, he should only catch those he really, really needs 
to catch and nothing more. If this cannot be improved sensibly, well, so 
be it. Although I still don't find the argument presented against 
"catching shallow exception" a little bit too abstract compared to the 
practical benefit. Maybe, there's a better solution, maybe not.



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] + operator on generators

[Sven R. Kunze]

On 28.06.2017 16:01, Koos Zevenhoven wrote:
For a moment, I was wondering what the double emphasis was for, but 
then I realized you are simply calling `statement.__why__()`​ directly 
instead of the recommended `spoiler(statement)`.


Doing this for years now. Sometimes, when 'statement.__why__()' returns 
None, 'spoiler(statement)' returns some thought-terminating cliché. ;)


But sure, I just got on vacation and I even found a power extension 
cord to use my laptop at the pool, so what else would I do ;).


Good man. Today, a colleague of mine showed me a mobile mini-keyboard 
with a phone bracket (not even a dock). So, having his 7'' smartphone, 
he can work from his vacations and answer emails as well. ;) Cheap 
notebook replacement, if you don't prefer large screens and keyboards. :D


It all depends on what you need to do with the result of the 
concatenation. When all you need is something to iterate over, a 
generator-like thingy is fine. But when you need something for 
indexing and slicing or len etc., you want to be sure that that is 
what you're getting. But maybe someone passed you an argument that is 
not a sequence, or you forgot if a function returns a sequence or a 
generator. In that case, you want the error right away, instead of 
from some completely different piece of code somewhere that thinks 
it's getting a sequence. I don't think Python should depend on a 
static type checker to catch the error early. After all, type hints 
are optional.


I understand that. In the end, I remember people on this mailing-list 
recommending me to use "list(...)" to make sure you got one in your 
hands. I remember this being necessary in the conversion process from 
Python2 to 3. The pattern is already here.



PS: I consider this proposal to be like allowing adding floats and
ints together. If I don't know if there was a float in the sum,
don't know if my result will be a float.


​Not to say that the float/int case is never problematic, but the 
situation is still different. Often when a float makes any sense, you 
can work with either floats or ints and it doesn't really matter. But 
if you specifically *need* an int, you usually don't call functions 
that return floats. But if you do use division etc., you probably need 
to think about floor/ceil/closest anyway. And yes, there have probably 
been Python 2->3 porting bugs where / division was not appropriately 
replaced with //.


Division is one thing, numeric input parameters from unknown sources is 
another. In this regard, calling "int(...)" or "list(...)" follows the 
same scheme IMO.


But regarding containers, it often makes just as much sense for a 
function to return a generator as it does to return a sequence. The 
name or purpose of a function may give no hint about whether an 
iterable or sequence is returned, and you can't expect everyone to 
prefix their function names with iter_ and seq_ etc. And it's not just 
function return values, it's also arguments passed into your function.


Exactly. Neither want I those prefixes. And I can tell you they aren't 
necessary in practice at all.


Just my 2 cents on this:
At work, we heavily rely on Django. Django provides a so-called QuerySet 
type, its db-result abstraction. Among those querysets, our functions 
return lists and sets with no indication of whatsoever type it may be. 
It works quite well and we didn't had any issues with that. If we need a 
list, we wrap it with "list(...)". It's as simple as that. The valid 
concern, that it could be confusing which type the return value might 
have, is usually an abstract one. I can tell you that in practice it's 
not really an issue to talk about.


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] + operator on generators

[Sven R. Kunze]

On 28.06.2017 14:00, Koos Zevenhoven wrote:
The programmer needs to be well aware of whether the resulting object 
is a Sequence or 'just' a generator.


Could you elaborate more on **why**?

Regards,
Sven

PS: I consider this proposal to be like allowing adding floats and ints 
together. If I don't know if there was a float in the sum, don't know if 
my result will be a float.
___
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] Improving Catching Exceptions

[Sven R. Kunze]

On 28.06.2017 08:00, Nick Coghlan wrote:

Right, and I'd like us to keep in mind the KeyError -> AttributeError
(and vice-versa) use case as well. Similar to ExitStack, it would be
appropriate to make some additions to the "recipes" section in the
docs that covered things like "Keep AttributeError from being
suppressed in a property implementation".


As it was snipped away, let me ask again:

I don't see how this helps differentiating shallow and nested exceptions 
such as:


try:
with exception_guard(ImportError):
import myspeciallib
except RuntimeError: # catches shallow and nested ones
import fallbacks.MySpecialLib as myspeciallib


At least in my tests, exception_guard works this way and I don't see any 
improvements to current behavior. Moreover, I am somewhat skeptical that 
using this recipe will really improve the situation. It's a lot of code 
where users don't have any stdlib support. I furthermore doubt that all 
Python coders will now wrap their properties using the guard. So, using 
these properties we will have almost no improvement. I still don't see 
it as the responsibility of coder of the property to guard against 
anything. Nobody is forced to catch exceptions when using a property.


If that's the "best" outcome, I will stick to

https://stackoverflow.com/questions/20459166/how-to-catch-an-importerror-non-recursively

because 1) Google finds it for me and 2) we don't have to maintain 100 
lines of code ourself.


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] + operator on generators

[Sven R. Kunze]

On 28.06.2017 11:09, Nick Coghlan wrote:

The other thing to look for would be list() and list.extend() calls. I
know I use those quite a bit in combination with str.join, where I
don't actually *need* a list, it's just currently the most convenient
way to accumulate all the components I'm planning to combine. And if
you're converting from Python 2 code, then adding a few list() calls
in critical places in order to keep the obj.extend() calls working is
likely to be easier in many cases than switching over to using
itertools.chain.


This is exactly the reason why I also doubt that Stephan's Sagemath 
stats are telling anything beyond "chain isn't used that much".


Iterators are only nice to have if you work with simple lists up to 1000 
items. Current hardware is able to fix that for you.


There are simply more readable ways of doing "chaining of sequences" for 
many cases. Even if you are already on Python 3.


In the end, list and "+" operator are the best way of "doing sequences".

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] + operator on generators

[Sven R. Kunze]

On 27.06.2017 21:27, David Mertz wrote:
And I would like a language change that made a number of common 
iterable objects "chainable" without the wrapper.  This wrapper could 
of course be used as a decorator too.


E.g. generator comprehensions, things returned by itertools functions, 
range(), enumerate(), zip(), etc.  This wouldn't promise that EVERY 
iterable or iterator had that "chainable" behavior, but it would cover 
90% of the use cases.  And I wouldn't find it confusing because the 
leftmost object would be the one determining the behavior, which feels 
more intuitive and predictable.


I think that most people in favor of this proposal agree with you here. 
Let's start with something simple which can be extended bit by bit to 
cover more and more use-cases.


I for one would include also right-handed iterators/generator because I 
definitely know real-world usage (just recently) but that can wait until 
you feel comfortable with it as well.


If it's a language change, I would like the plus operator to be it as it 
integrated well with lists, such as


generator + (list1 + list2)

It can be sometimes necessary to group things up like this. Using a 
different operator symbol here, I would find confusing. Plus looks like 
concat to me.


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] Improving Catching Exceptions

[Sven R. Kunze]

On 27.06.2017 13:41, Nick Coghlan wrote:

The shallow exception notion breaks a fairly fundamental refactoring
principle in Python: you should be able to replace an arbitrary
expression with a subfunction or subgenerator that produces the same
result without any of the surrounding code being able to tell the
difference.


I would agree with you here but this "refactoring principle in Python" 
doesn't work for control flow.


Just look at "return", "break", "continue" etc. Exceptions are another 
way of handling control flow. So, this doesn't apply here IMO.



By contrast, Steven's exception_guard recipe just takes the existing
"raise X from Y" feature, and makes it available as a context manager
and function decorator.


I don't see how this helps differentiating shallow and nested exceptions 
such as:


try:
with exception_guard(ImportError):
import myspeciallib
except RuntimeError: # catches shallow and nested ones
import fallbacks.MySpecialLib as myspeciallib


Regards,
Sven

PS: this has nothing to do with cyclic imports. It can be a 
misconfiguration of the system which fails nested imports. In those 
cases, we fallback silently.

___
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] + operator on generators

[Sven R. Kunze]

Personally, I find syntactic sugar for concating interators would come 
in handy.


The purpose of iterators and generators is performance and efficiency.  
So, lowering the bar of using them is a good idea IMO. Also hoping back 
and forth a generator/iterator-based solution and a, say, 
list-based/materialized solution would become a lot easier.



On 25.06.2017 16:04, Stephan Houben wrote:

I would like to add that for example numpy ndarrays are iterables, but
they have an __add__ with completely different semantics, namely 
element-wise ( numerical) addition.


So this proposal would conflict with existing libraries with iterable 
objects.


I don't see a conflict.



Op 25 jun. 2017 2:51 p.m. schreef "Serhiy Storchaka" 
>:


It would be weird if the addition is only supported for instances
of the generator class, but not for other iterators. Why (n for n
in range(2)) + (n for n in range(2, 4)) works, but iter(range(2))
+ iter(range(2, 4)) and iter([0, 1]) + iter((2, 3)) don't?
itertools.chain() supports arbitrary iterators. Therefore you will
need to implement the __add__ method for *all* iterators in the world.



I don't think it's necessary to start with *all* iterators in the world.

So, adding iterators and/or generators, should be possible without any 
problems. It's a start and could already help a lot if I have my 
use-cases correctly.



However itertools.chain() accepts not just *iterators*. It works
with *iterables*. Therefore you will need to implement the __add__
method also for all iterables in the world. But __add__ already is
implemented for list and tuple, and many other sequences, and your
definition conflicts with this.



As above, I don't see a conflict.


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] Language proposal: variable assignment in functional context

[Sven R. Kunze]

On 17.06.2017 17:51, Nick Coghlan wrote:

You've pretty much hit on why that PEP's been deferred for ~5 years or
so - I'm waiting to see use cases where we can genuinely say "this
would be so much easier and more readable if we had a given
construct!" :)


This PEP accepted, we would have 3 ways of doing 1 thing (imperative 
programming):

1) flat inline execution namespace
2) structured inline execution namespace
3) named code used in 1) oder 2)


Is that simple enough for Python?


Just one side thought: internally, we have a guideline which says: 
"please reduce the number of indentations" -> less else, less if, less 
while, etc. The goal is more compact, less complex code.

Our code is already complex enough due to its sher amount.

"given" would fall under the same rule here: keep it flat and simple; 
otherwise, give it a name.



Then asyncio (and variants like
curio and trio) came along and asked the question: what if we built on
the concepts explored by Twisted's inlineDeferred's, and instead made
it easier to write asynchronous code without explicitly constructing
callback chains?


Does it relate? I can imagine having both "given" and "async given".


However, in my own work,
having to come up with a sensible name for the encapsulated operation
generally comes with a readability benefit as well, so...


Well said. In the end (when it comes to professional code), you need to 
test those little things anyway. So addressing them is necessary.
In interactive code, well, honestly, I don't care so much about spoiling 
namespaces and using variables names such as 'a' or 'bb' is quite common 
to try things out.


@Steven
Good post, thanks for explaining it. :)

Might be too much for the simple Python I know and value but hey if it 
helps. Maybe it will enable a lot of cool stuff and we cannot imagine 
right now just because David Beazley cannot try it out in practice.


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] Language proposal: variable assignment in functional context

[Sven R. Kunze]

On 17.06.2017 02:27, Steven D'Aprano wrote:

I think this is somewhat similar to a suggestion of Nick Coghlan's. One
possible syntax as a statement might be:

y = b + 2 given:
 b = a + 1


Just to get this right:this proposal is about reversing the order of 
chaining expressions?


Instead of:

b = a + 1
c = b + 2

we could write it in reverse order:

c = b + 2 given/for:
b = a + 1


If so, I don't know if it just complicates the language with a feature 
which does not save writing nor reading nor cpu cycles nor memory and 
which adds a functionality which is already there (but in reverse order).


Maybe there are more benefits I don't see right now.

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] π = math.pi

[Sven R. Kunze]

On 01.06.2017 08:47, Serhiy Storchaka wrote:
What you are think about adding Unicode aliases for some mathematic 
names in the math module? ;-)


math.π = math.pi
math.τ = math.tau
math.Γ = math.gamma
math.ℯ = math.e

Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(

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


No, thank you. :)

One way to do it is perfectly fine.

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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

On 20.05.2017 18:06, Nick Coghlan wrote:

That's fine for someone that's already comfortable writing those
behaviours by hand and just wants to automate the boilerplate away
(which is exactly the problem that attrs was written to solve), but
it's significantly more problematic once we assume people will be
using a feature like this *before* learning how to write out all the
corresponding boilerplate themselves (which is the key additional
complication that a language level version of this will have to
account for).


That's a good point. At least, Python does a very good job at reducing 
boilerplate in many cases in the first case.


One usually starts small instead of big.


[API sketch]

In this particular API sketch, data_record is just a class decorator
factory, and data_field is a declarative helper type for use with that
factory, so if you wanted to factor out particular combinations, you'd
just write ordinary helper functions.


I might weigh in that decorating classes seems to be a bit awkward. 
Especially because I know that there are many people and frameworks out 
there telling you to decorate your classes with their decorators.


If you don't pay enough attention, you end up having something like this:

@nice_decoration(para1, para2)
@decorate_somehow
@important_decoration(para3)
@please_use_me()
class MyClass(Mixin2, Mixin1, BaseClass):
para4 = 'foo'
para5 = 'bar'
para6 = 'boo'
para7 = 'baz'


So, there's a region with decorations (decorators + params) OUTSIDE the 
class and there's a region with declarations (mixins + params) INSIDE 
the class; BOTH doing some sort of configuration of the class.


I honestly cannot tell which API style would be better but it seems we 
(at least internally) decided for the latter version: "If it belongs to 
the class, it should be inside the class."


Maybe, Python standard declarative class construction could be an 
exception because it's the default. But I am not sure. Technically, I 
think, both approaches can achieve the same result.



Database object-relational-mapping layers like those in SQL Alchemy
and Django would be the most famous precursors for this, but there are
also things like Django Form definitions, and APIs like JSL (which
uses Python classes to declaratively define JSON Schema documents).

For folks already familiar with ORMs, declarative classes are just a
matter of making in memory data structures as easy to work with as
database backed ones. For folks that *aren't* familiar with ORMs yet,
then declarative classes provide a potentially smoother learning
curve, since the "declarative class" aspects can be better separated
from the "object-relational mapping" aspects.


Well said.

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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

Just one additional word about mixins:

we've been inspired by Django's extensive usage of mixins for their 
class-based views, forms and model classes. For one, we defined more 
mixins for those classes (like UrlMixin for view classes), and for 
another we developed our own mixin infrastructure for domain-specific 
classes.


In the end, a lot of our top-level classes (the ones actually used as 
API etc.) look like plug'n'play + configuration:


class MyImportantThing(Mixin1, Mixin2, Base):
url = 'blaa/asdf'
next_foo = 234
special_model = User

For example in this case, "url" might be the config parameter for 
"Mixin1", "next_foo" for "Mixin2" and "special_model" is 
required/recognized by "Base".


As you can imagine, testing is also easier.


Regards,
Sven


On 19.05.2017 06:31, Eric V. Smith wrote:

On 5/18/17 2:26 PM, Sven R. Kunze wrote:

On 17.05.2017 23:29, Ivan Levkivskyi wrote:

On 17 May 2017 at 20:09, Sven R. Kunze <srku...@mail.de
<mailto:srku...@mail.de>> wrote:

class Foo(dictlike, tuplelike, simpleobject):
attribute1: User
attribute2: Blog
attribute3: list

 def __my_dunder__(self):
...


As I understand this is more or less what is proposed,


Are you sure? Could you point me to the relevant messages where mixins
are mentioned as a key part of the proposal? All I could find are
message using the @decorator syntaxes.

We've been working with mixins successfully for years now and I can tell
you that it's "just" a clever way of refactoring existing code in order
to make it more accessible to other modules *based on use-cases*.


So, the best person to tell what pieces to factor out would be Stephan
using his 4-point list.
And of course other people using NamedTuple but frequently refactoring
to "attr" or own class because NamedTuple just is too much (defines too
much implicitly).


Could you point me to this 4-point list of Stephan's? I couldn't find 
anything in the archive that you might be referring to.


Eric.



___
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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

On 17.05.2017 23:29, Ivan Levkivskyi wrote:
On 17 May 2017 at 20:09, Sven R. Kunze <srku...@mail.de 
<mailto:srku...@mail.de>> wrote:


class Foo(dictlike, tuplelike, simpleobject):
attribute1: User
attribute2: Blog
attribute3: list

 def __my_dunder__(self):
...


As I understand this is more or less what is proposed,


Are you sure? Could you point me to the relevant messages where mixins 
are mentioned as a key part of the proposal? All I could find are 
message using the @decorator syntaxes.


We've been working with mixins successfully for years now and I can tell 
you that it's "just" a clever way of refactoring existing code in order 
to make it more accessible to other modules *based on use-cases*.



So, the best person to tell what pieces to factor out would be Stephan 
using his 4-point list.
And of course other people using NamedTuple but frequently refactoring 
to "attr" or own class because NamedTuple just is too much (defines too 
much implicitly).



Another benefit is that NamedTuple itself would become a mere set of 
base class and mixins.



the idea is to write it into a PEP and consider API/corner 
cases/implementation/etc.


Who's writing it?


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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

Hi Stephan,

On 17.05.2017 08:49, Stephan Houben wrote:

2. Not subclassed from tuple. I have been bitten by this subclassing
when trying to set up
singledispatch on sequences and also on my classes.


Would it make sense to have a 'simpleobject'? Which basically implements 
a NamedTuple constructor but nothing more?


class Foo(simpleobject):
attribute1: User
attribute2: Blog
attribute3: list


And if you need more __dunder__ magic, have it provided by some mixins?


class Foo(dictlike, tuplelike, simpleobject):
attribute1: User
attribute2: Blog
attribute3: list

 def __my_dunder__(self):
...


I don't know exactly if some of those dictlike, tuplelike mixins are 
already available in the stdlib under a different name, but at least to 
me this looks like plug'n'play __dunder__ magic.



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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

On 17.05.2017 19:55, Stephan Houben wrote:

So attrs and attrib can be used as alternatives for attr.s and attr.ib .
Personally, I like the playful names.


Ah, now I understand their documentation. :D I read this passage and 
thought: "where is the difference. Maybe, they meant omitting x=, y= in 
the constructor?"


"There should be one-- and preferably only one --obvious way to do it." 
<<< That's why I didn't even thought there's an alternative. I feel 
that's a bit not-Python. ;)


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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

Hi Stephan,
hi Ivan,

On 17.05.2017 18:48, Ivan Levkivskyi wrote:

from typing import NamedTuple

class Foo(NamedTuple):
"""Foo is a very important class and
you should totally use it.
"""
bar: int
baz: int = 0

def grand_total(self):
return self.bar + self.baz

typing.NamedTuple supports docstrings, user-defined methods, and 
default values.


I hope the second ': int' can be omitted because 0 already is an int.


This makes me wonder three things:
1) Michel, can newcomers differentiate between when to use ' : ' and 
when to use ' = ' and a combination thereof?
2) There must be a lot of cornercases where people rewrite Foo to be a 
normal class in the end, right?
3) If one doesn't need tuple-__dunder__ methods, a "normal" class would 
even need 1 line less. (+ Stephan's second point)



So, this still leaves those missing __dunder__ magic methods doing the 
right thing at the right time.



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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

On 17.05.2017 19:30, Ethan Furman wrote:
Given that one of Python's great strengths is its readability, I would 
not use the attr library in teaching because it is not.  Having a dot 
in the middle of words is confusing, especially when you don't already 
have a basis for which abbreviations are common.  Is it attr.ib or 
att.rib or at.trib?


It took me 5 days to see "foo = attrib()" in "foo = attr.ib()" What 
the hell means "ib"? ...


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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

On 17.05.2017 13:37, Michel Desmoulin wrote:

Having a cleaner, faster solution to declare a class would be awesome,
both for dev and for teaching. That's why we all love attrs.

But we are talking here about a nice-to-have feature. Python works
perfectly fine without it. But since we are at it, let's make something
great.



Same for me. IMHO the biggest benefit using attr is an (almost?) 
feature-complete and bug-free set of pre-defined __dunder__ methods as 
described in [1].


Defining state-variables (aka instance variables accessible via 'self.') 
wouldn't be enough for me to make it a valuable feature. So, one could 
imagine a __dunder__-method generator of some sort.



But even given that (and I am only speaking for my team), I haven't even 
seen a use-case for namedtuples in a year. Every time we considered it, 
people said: "please make it its own class for documentary purposes; 
this thing will tend to grow faster than we can imagine".



2. Is it really that complicated? attr.s is just a normal Python
function, which adds some members to a class.
   You don't even have to use the decorator @ syntax, that is just a 
convenience.
  To me this seems easier to teach than yet another dedicated syntax.

My guess is that, without the decorator, the attributes don't do
anything. They are just declarative hints for the decorator to do the magic.

But even then, it's already an additional burden to have to explain the
difference between this magic and the regular class attribute.


It might also have something to do with this. IMO this feature should 
integrate naturally in a way that nobody notice.




Sven

[1] https://attrs.readthedocs.io/en/stable/why.html#hand-written-classes


___
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] Discourage operator.__dunder__ functions

[Sven R. Kunze]

On 13.04.2017 20:20, Steven D'Aprano wrote:

- And finally, I fail to see how having to type an extra four characters
is a "convenience".


Just for the sake of completeness:

Re-usage of names is always a convenience. Developers can use a string 
variable to access dynamically both the real dunder method and the 
operator one. It's a frequently used pattern. Whether it's necessary 
here, is different matter.


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] Augmented assignment syntax for objects.

[Sven R. Kunze]

On 26.04.2017 23:50, Mark Lawrence via Python-ideas wrote:

On 26/04/2017 21:50, Chris Angelico wrote:

On Thu, Apr 27, 2017 at 6:24 AM, Erik  wrote:

The background is that what I find myself doing a lot of for private
projects is importing data from databases into a structured 
collection of
objects and then grouping and analyzing the data in different ways 
before

graphing the results.

So yes, I tend to have classes that accept their entire object state as
parameters to the __init__ method (from the database values) and 
then any
other methods in the class are generally to do with the subsequent 
analysis

(including dunder methods for iteration, rendering and comparison etc).


You may want to try designing your objects as namedtuples. That gives
you a lot of what you're looking for.

ChrisA



Something like 
https://docs.python.org/3/library/sqlite3.html#row-objects ?




Or something like https://docs.djangoproject.com/en/1.11/topics/db/models/

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

[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 <chris.bar...@noaa.gov 
<mailto:chris.bar...@noaa.gov>> wrote:


    On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze <srku...@mail.de
<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 (206) 526-6959 <tel:%28206%29%20526-6959>   voice
7600 Sand Point Way NE (206) 526-6329 <tel:%28206%29%20526-6329>   fax
Seattle, WA  98115 (206) 526-6317 <tel:%28206%29%20526-6317>  
main reception


chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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 <mailto: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 <srku...@mail.de 
<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.


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

[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] 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] 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] 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] 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] 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] 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/

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

[Sven R. Kunze]

On 28.02.2017 18:18, David Mertz wrote:


Yes, and easily written as above.  What significant advantage would it 
have to spell the above as:


x = alist.get(pos, default_val)

It's a couple characters shorter in the proposed version.  I guess 
I'll concede that needing the odd indexing at the end to get the 
scalar is slightly ugly.


1. advantage: it looks like dict access -> allows duck typing (oh how 
often I'd missed that)

2. advantage: no try except
3. advantage: no weird workaround with slices and additional item access


Thanks for bringing this up, Michel. First point would be most important 
to me.



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] if in for-loop statement

[Sven R. Kunze]

Hey Steven,

On 23.02.2017 19:25, Steven D'Aprano wrote:

Indeed not. The Pythonic solution is exactly the one you used: DON'T
combine the for-loop and if-statement.

for x in range(100):
 if is_prime(x):
 ...

If the use of two lines and two indents is truly a problem, to the point
that you really need to refactor to a single line, that's a code smell:
your function is probably too big, too complex and does too much, and
should be refactored.


May I disagree with you here? I write many functions with a single for 
loop + a single if+continue on a daily basis (usually generators).

They don't seem to look like code-smell to me.

Not saying they justify this feature but it's easier to read a positive 
(including) if than a negative one (skipping).



Deeply nested for...for...for...if...if...if...for... blocks look ugly
because they are ugly. Allowing them all on one line makes the Python
language worse, not better. It is unfortunate that comprehensions, by
their nature, must allow that sort of thing, but that doesn't mean we
have to allow it elsewhere.


Another disagreement here. Just because it's possible to do ugly stuff 
with a hammer shouldn't mean we cannot allow hammers. It's an argument 
neither in favor of nor against the proposal.


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] if in for-loop statement

[Sven R. Kunze]

Hi Henk-Jaap,

thanks for your "if in for" proposal.

Paul's comments are all "motherhood statements" against a generic 
proposal. It's nothing that would prevent your specific proposal from 
being accepted or not. And there's no rejected PEP for this feature as 
far as I can see.


Skimming through the other thread about this topic, I remember me not 
being very offensive against it. I would use it often.


IIRC, one result of former discussions were that it would be technically 
possible. But the other proposer did not convince most thread 
participants back then. I for one, though, didn't buy the 
counter-arguments and still don't. They still sound to me like abstract 
fears.



On 23.02.2017 16:18, Henk-Jaap Wagenaar wrote:
I did find https://docs.python.org/devguide/langchanges.html and 
http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html 
but the things you wrote would be useful to add the former (or be 
linked from there). It would also be good if there was a counter-point 
to that blog post of changes (like this one) that are not sufficiently 
thought through or significant enough to be accepted: it is always 
good to have examples on both sides.


In terms of your "it keeps coming up", maybe there should be a general 
PEP (or something else) that simply outlines a bunch of ideas (and 
will be kept adding to) that keep cropping up but have been 
rejected/received unsympathetically many times? Including maybe links 
to these threads?


Recently, we had a similar discussion about writing an "official" 
document which might prevent proposal such as yours. I wasn't the only 
one being offended by this kind of thinking. There are, as you noted, 
two sides of the table and just because "it keeps coming up" and "was 
received unsympathetically many times" doesn't mean we shouldn't 
consider it. Point is, it actually seems sympathetic to many people and 
this is why it keeps coming up.



Nevertheless, a proposal needs consensus.

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] More classical for-loop

[Sven R. Kunze]

On 17.02.2017 04:59, Chris Angelico wrote:

On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V  wrote:

Common use case:

L = [1,3,5,7]

for i over len(L):
e = L[i]

or:

length = len(L)
for i over length:
e = L[i]

Better use case:

for i, e in enumerate(L):


I totally agree with Chris here.

For me, there's no need for another for loop syntax. It would be better 
to learn Python idioms instead.


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] Efficient debug logging

[Sven R. Kunze]

On 15.02.2017 12:55, Barry Scott wrote:

The lazy eval sound like a generator.



Exactly my thought.


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] Fwd: Define a method or function attributeoutside of a class with the dot operator

[Sven R. Kunze]

Another point of view:

Some call it monkeypatching. Others call it configuration.


There's room for both views and I don't see anything wrong with 
configuration using this kind of feature.



Sven

On 10.02.2017 17:17, Markus Meskanen wrote:
Well yes, but I think you're a bit too fast on labeling it a mistake 
to use monkey patching...



On Feb 10, 2017 18:15, "Paul Moore" > wrote:


On 10 February 2017 at 16:09, Markus Meskanen
> wrote:
> But if people are gonna do it anyways with the tools provided
(monkey
> patching), why not provide them with better tools?

Because encouraging and making it easier for people to make mistakes
is the wrong thing to do, surely?

Paul




___
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] Is it Python 3 yet?

[Sven R. Kunze]

Agree with all of this. That's state of the art for many projects.


On 07.02.2017 07:35, Mike Miller wrote:
Hmm, agreed.  BTW, I think the current download page is *way* too 
complicated for new comers.


There should be a giant button for the latest 3.x/64 (platform sniffed),
and below it a more subtle button for the "LTS" 2.X/32.

The rest of the choices and text should be pushed to another page 
marked "advanced," including the PGP (boggle) section.


The Licenses through History section could be moved to About.

-Mike


On 2017-01-26 08:11, Victor Stinner wrote:

The download button of https://www.python.org/ currently gives the

___
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] A more readable way to nest functions

[Sven R. Kunze]

On 31.01.2017 00:54, Mikhail V wrote:
Great idea :)  But actually that was my idea initially, so just 
breaking it into two lines solves the readability issue perfectly with 
long expressions. Although if one is chasing some kind of 
optimisations... I don't know, I see very often people want to stick 
everything in one big expression.


Because it's natural.

It's *sometimes* the best way to convey the data processing pipeline. 
It's the connection between separate parts that needs to be conveyed.


Furthermore, inventing artificial names is sometimes not the best way. 
So, I think the behavior you've described can be explained quite easily.


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] A decorator to call super()

[Sven R. Kunze]

Hi Roberto,

On 31.01.2017 08:13, Roberto Martínez wrote:

class MyOverridedClass(MyBaseClass):
def mymethod(self, foo, **kwargs):
# Do something
return super().mymethod(**kwargs)

What about creating a decorator to call super() after/before the 
overrided method? Something like that:


class MyOverridedClass(MyBaseClass):
@extendsuper
def mymethod(self, foo):
# Do something


I could find this useful. There's just on bikeshedding issue:

When should "super().mymethod(**kwargs)" be called: *before*, *after* or 
inbetween my specialized code?


Depending on the baseclass either of those three is necessary. As far as 
I can tell, we encounter all of them regularly.


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] Fused multiply-add (FMA)

[Sven R. Kunze]

On 16.01.2017 20:28, Gregory P. Smith wrote:


Is there a good reason not to detect single expression multiply adds 
and just emit a new FMA bytecode?




Same question 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] How to respond to trolling (Guido van Rossum)

[Sven R. Kunze]

Moreover, when I read "explicit self" is a wart, then I think, "you have 
absolutely no idea how fantastic 'explicit self' is".


Thus, inferring from a single data-point these seems to be personal 
"dislike lists".


In this regard, I tend to prefer Guido's one before any others if there 
is even one.


On 13.01.2017 03:40, Stephen J. Turnbull wrote:

Guido van Rossum writes:

  > AFAIK the term comes from a piece by Andrew Kuchling titled "Python warts".
  > The topic now has its own wiki page:
  > https://wiki.python.org/moin/PythonWarts
  >
  > I believe that most of the warts are not even design missteps -- they are
  > emergent misfeatures, meaning nobody could have predicted how things would
  > work out.

More like surgical scars than warts, as I see it.

___
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] Things that won't change (proposed PEP)

[Sven R. Kunze]

Good evening to everybody,

On 12.01.2017 03:37, Steven D'Aprano wrote:

I have a proposal for an Informational PEP that lists things which will

not change in Python. If accepted, it could be linked to from the signup

page for the mailing list, and be the one obvious place to point

newcomers to if they propose the same old cliches.



Thoughts?



Let me first express my general thoughts on this topic.

First of all, I am anti-censor and pro-change.

So you can imagine that I am not overly excited to see such a document 
form for Python in general. If it's just to prevent spam on this mailing 
list and to reduce the signal/noise ratio here, I tend to agree with you 
if this document were to be attached to this mailing list only.


I don't think Python as the umbrella term for a language, an ecosystem, 
etc. will benefit from preventing change and from banning thoughts no 
matter how strange they may seem first and to some people.



Alright, after that's sorted out, I took my time to go through the list 
below in case the document will be accepted or made official in any form.
So, please find my comment inserted there and some general thoughts at 
the very end.




PEP: XXX

Title: Things that won't change in Python


This a very absolute-sounding title. Maybe inserting a "(most likely)" 
between "that" and "won't" will give it the right nudge.




Version: $Revision$

Last-Modified: $Date$

Author: Steven D'Aprano 

Status: Draft

Type: Informational

Content-Type: text/x-rst

Created: 11-Jan-2017

Post-History: 12-Jan-2017





Abstract





This PEP documents things which will not change in future versions of Python.


Same "(most likely)" here.







Rationale

=



This PEP hopes to reduce the noise on `Python-Ideas 
`_

and other mailing lists.  If you have a proposal for future Python

development, and it requires changing one of the things listed here, it

is dead in the water and has **no chance of being accepted**, either because

the benefit is too little, the cost of changing the language (including

backwards compatibility) is too high, or simply because it goes against

the design preferred by the BDFL.



Many of these things are already listed in the `FAQs 
`_.

You should be familiar with both Python and the FAQs before proposing

changes to the language.



Just because something is not listed here does not necessarily mean that

it will be changed.  Each proposal will be weighed on its merits, costs

compared to benefits.  Sometimes the decision will come down to a matter

of subjective taste, in which case the BDFL has the final say.



I like these paragraphs.





Language Direction

==



Python 3





This shouldn't need saying, but Python 3 will not be abandoned.




Don't think this section is necessary. It's more like a project 
management decision not a real change.





Python 2.8

--



There will be `no official Python 2.8 
`_ ,

although third parties are welcome to fork the language, backport Python

3 features, and maintain the hybrid themselves.  Just don't call it

"Python 2.8", or any other name which gives the impression that it

is maintained by the official Python core developers.



Same here.


Type checking

-
[...]


Okay.


Syntax

==



Braces

--

[...]


Okay but a bit long. Especially the loophole description plays against 
the intention of the document; which is natural because we talk about 
change here. So, nobody knows; and neither do the authors of this 
document. Not saying, the loophole description should be removed. It's a 
perfect summary of the current situation but shifts the focus of the 
document and dilutes its core message.



Colons after statements that introduce a block

--



[...]


Okay.


End statements

--

[...]


Okay.


Explicit self

-

[...]


Okay.


Print function

--

[...]


Works for me, although the newbies I know of definitely disagree here. ;-)


Significant indentation

---

[...]


Okay.


Other syntax



[...]


Okay.


Built-in Functions And Types



Strings

---


[...]


Okay.


Bools

-

[...]


Okay.


Built-in functions

--



Python is an object-oriented language, but it is not *purely*

object-oriented. Not everything needs to be `a method of some object  
`_,

and functions have their advantages.  See the

`FAQ 
`_

for more detail.


This is about questioning built-in functions in general, right? 

Re: [Python-ideas] Generator-based context managers can't skip __exit__

[Sven R. Kunze]

On 06.11.2016 09:07, Steven D'Aprano wrote:
I'm having a lot of difficulty in understanding your use-case here, 
and so maybe I've completely misunderstood something. 


Although, this thread is dead for a week or so, I am still curious to 
hear the real-world use-case. I am equally puzzled by the fact that 
somebody really wants to use a context manager not to work like a 
context manager; without even considering not to use context managers at 
all and using regular functions instead.


Cheers,
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] Built-in function to run coroutines

[Sven R. Kunze]

What about making "run" an instance method of coroutines?


On 14.11.2016 19:30, Yury Selivanov wrote:

Hi Guido,


On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which 
would be

something akin to

def run(coro):
 return get_event_loop().run_until_complete(coro)

(but perhaps with better cleanup).


Please see https://github.com/python/asyncio/pull/465.



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] Null coalescing operator

[Sven R. Kunze]

On 02.11.2016 17:17, Nick Coghlan wrote:

The gist is that rather than writing the bare:

target = expr1 ?? expr2 ?? expr3

You'd instead write None-coalescing as:

target = exists(expr1) ?? exists(expr2) ?? expr3

and None-propagating as:

target = missing(expr1) ?? missing(expr2) ?? expr3

with ?? being a protocol-driven short-circuiting binary operator
controlled by the left operand rather than defining any particular
semantics of its own.


I am sorry that I had to read this twice to get what you mean.



The "obj?." and "obj?[]" would then be shorthand for particular uses
of "missing(obj) ?? ..." that avoid duplicate evaluation of the left
operand (as well as bypassing the overhead of actually creating a
"missing" instance).



That could work if we accept that ?. and ?[] is only about the left 
hand-side. However, as the ? visually applies also to the 
attribute/index access on the right, which means it could be a more 
readable way of doing


getattr(x, 'attr', None)
or
x[0] if len(x) > 0 else None

Imagine you need to work with incomplete data and do some chaining with 
the new syntax. As soon as one single attribute isn't there, we hit an 
exception. The same for index.


If the ?. and ?[] are introduced, I think applying the "non-existence" 
property also the right hand make sense here as well for a wide range of 
applications.



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] Showing qualified names when a function call fails

[Sven R. Kunze]

Great idea!


Another issue I encounter regularly are things like:

>>> func(mylist[i], mylist2[j])

IndexError: list index out of range


So, which are the list and index that cause the error?


On 25.10.2016 00:07, Ryan Gonzalez wrote:

I personally find it kind of annoying when you have code like this:


x = A(1, B(2, 3))


and Python's error message looks like this:


TypeError: __init__() takes 1 positional argument but 2 were given


It doesn't give much of a clue to which `__init__` is being called. At all.

The idea: when showing the function name in an error like this, show the
fully qualified name, like:


TypeError: A.__init__() takes 1 positional argument but 2 were given


This would be MUCH more helpful!


Another related change would be to do the same thing in tracebacks:


Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in __init__
AssertionError


to:


Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in MyClass.__init__
AssertionError


which could make it easier to find where exactly an error originated.

--
Ryan (ライアン)
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/



___
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] Marking keyword arguments (was: f-string, for dictionaries)

[Sven R. Kunze]

Hi Michel,
hi Paul,

sorry for hijacking this thread somewhat. I would like to extend this 
proposal a bit in order make it useful for a broader audience and to 
provide a real-word use-case. So, this post is just to gather general 
acceptance and utility of it.



Michel, you specifically mentioned dicts as the place where to start 
with this kind of syntax. I have to tell you one could easily extend 
this thought process to function calls as well.


Keyword arguments cannot be simply passed like positional arguments. 
They always require the parameter name to be mentioned.



In production we have masses of code that goes like this:

>>> do_thing(important_stuff=important_stuff, request=request)
>>> make_any(config=123, important_stuff=important_stuff, 
other_form=other_form)



Causes:
- verbose names of variables
- extended usage of kwargs
- passing the same data over and over again down the calling hierarchy


So, instead providing this kind of syntax for dicts only, why not also 
providing them for kwargs? Basically marking arguments as keyword arguments:



my_func(:param1, :param2)


":param" equals "param=param" again but as already said that might just 
be placeholder syntax.



What do you think?



On 25.10.2016 23:18, Michel Desmoulin wrote:



Le 25/10/2016 à 22:27, Paul Moore a écrit :

On 25 October 2016 at 20:11, Michel Desmoulin
 wrote:

Similarly, I'd like to suggest a similar feature for building
dictionaries:


foo = 1
bar = 2
{:bar, :foo}

{'bar': 1, 'foo', 2}


I don't see a huge advantage over


dict(foo=foo, bar=bar)


Avoiding having to repeat the variable names doesn't feel like a
killer advantage here, certainly not sufficient to warrant adding yet
another dictionary construction syntax. Do you have examples of code
that would be substantially improved with this syntax (over using an
existing approach)?


{:bar, :foo}
vs
dict(foo=foo, bar=bar)

has the same benefit that would have

f"hello {foo} {bar}"
vs
"hello {} {}".format(foo, bar)




And a similar way to get the content from the dictionary into variables:


values = {'bar': 1, 'foo', 2}
{:bar, :foo} = values
bar

1

foo

2


There aren't as many obvious alternative approaches here, but it's not
clear why you'd want to do this. So in this case, I'd want to see
real-life use cases. Most of the ones I can think of are just to allow
a shorter form for values['foo']. For those uses

>>> from types import SimpleNamespace
>>> o = SimpleNamespace(**values)
>> o.foo
1

works pretty well.


This is just unpacking for dicts really.

As you would do:

a, b = iterable

you do:

{:a, :b} = mapping




The syntaxes used here are of course just to illustrate the concept
and I'm
suggesting we must use those.


Well, if we ignore the syntax for a second, what is your proposal
exactly? It seems to be in 2 parts:

1. "We should have a dictionary building feature that uses keys based
on variables from the local namespace". OK, that's not something I've
needed much, and when I have, there have usually been existing ways to
do the job (such as dict(foo=foo) noted above) that are perfectly
sufficient. Sometimes the existing alternatives look a little clumsy
and repetitive, but that's a very subjective judgement, and any new
syntax could easily look worse to me (your specific proposal, for
example, does). So I can see a small potential benefit in (subjective)
readability, but that's offset by the proposal being another way of
doing something that's already pretty well covered in the language.
Add to that all of the "normal" objections to new syntax (more to
teach/learn, hard to google, difficulty finding a form that suits
everyone, etc) and it's hard to see this getting accepted.

2. "We should have a way of unpacking a dictionary into local
variables". That's not something that I can immediately think of a way
of doing currently - so that's a point in its favour. But honestly,
I've never seen the need to do this outside of interactive use (for
which see below). If all you want is to avoid the d['name'] syntax,
which is quite punctuation-heavy, the SimpleNamespace trick above does
that. So there's almost no use case that I can see for this. Can you
give examples of real-world code where this would be useful?

On the other hand, your proposal, like many that have come up
recently, seems to be driven (if it's OK for me to guess at your
motivations) by an interest in being able to write relatively terse
one-liners, or at least to avoid some of the syntactic overheads of
existing constructs. It seems to me that the environment I'd most want
to do this in is the interactive interpreter. So I wonder if this (and
similar) proposals are driven by a feeling that it's "clumsy" writing
code at the interactive prompt. That may well be so. The standard
interactive prompt is pretty basic, and yet it's a *huge* part of the
unique experience working with Python to be able to work at the prompt
as you develop. So maybe 

Re: [Python-ideas] PEP 531: Existence checking operators

[Sven R. Kunze]

Hi Nick,

thanks for writing all of this down and composing a PEP.

On 28.10.2016 10:30, Nick Coghlan wrote:

1. Do we collectively agree that "existence checking" is a useful
general concept that exists in software development and is distinct
from the concept of "truth checking"?


Right to your first question:

If I were to answer this in a world of black and white, I need to say 
yes. In the real-world it's more probably more like: you can map 
existence-checking to truth checking in most practical cases without any 
harm. So, it's usefulness and distinctness is quite reduced.




2. Do we collectively agree that the Python ecosystem would benefit
from an existence checking protocol that permits generalisation of
algorithms (especially short circuiting ones) across different "data
missing" indicators, including those defined in the language
definition, the standard library, and custom user code?


I cannot speak for stdlib.

For custom user code, I may repeat what I already said: it might be 
useful the outer code working on the boundaries of systems as incoming 
data is hardly perfect. It might harm inner working of software if bad 
datastructure design permeates it and requires constant checking for 
existence (or other things).


Language definition-wise, I would say that if we can curb the issue 
described in the former paragraph, we'll be fine. Then it will shine 
through to all user code and the stdlib as well.


However, I don't think we are going to achieve this. The current 
language design does indeed favor clean datastructure design since messy 
datastructures are hard to handle in current Python. So, this naturally 
minimizes the usage of messy datastructures which is not a bad thing IMHO.


From my experience, clean datastructure design leads to easy-to-read 
clean code naturally. If people get their datastructures right in the 
inner parts of their software that's the most important step. If they 
subsequently would like to provide some convenience to their consumers 
(API, UI, etc.), that's a good cause. Still, it keeps the mess/checking 
in check plus it keeps it in a small amount of places (the boundary 
code). And it guides consumers also to clean usage (which is also not a 
bad thing IMHO).




3. Do we collectively agree that it would be easier to use such a
protocol effectively if existence-checking equivalents to the
truth-checking "and" and "or" control flow operators were available?


It's "just" shortcuts. So, yes.

However, as truth checking already is available, it might even increase 
confusion of what checking is to use. I think most developers need less 
but powerful tools to achieve their full potential.




Only if we have at least some level of consensus on the above
questions regarding whether or not this is a conceptual modeling
problem worth addressing at the language level does it then make sense
to move on to the more detailed questions regarding the specific
proposed *solution* to the problem in the PEP:


All in one, you can imagine that I am -1 on this.



6a. Do we collectively agree that 'obj?.attr' would be a reasonable
spelling for "access this attribute only if the object exists"?
6b. Do we collectively agree that 'obj?[expr]' would be a reasonable
spelling for "access this subscript only if the object exists"?


I know, I don't need to mention this because question 1 to 3 are already 
problematic, but just my two cents here. To me it's unclear what the ? 
would refer to anyway: is it the obj that needs checking or is it the 
attribute/subscript access? I get the feeling that this is totally 
unclear from the syntax (also confirmed by Paul's post).



Still, thanks a lot for your work, Nice. :)

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] SI scale factors alone, without units or dimensional analysis

[Sven R. Kunze]

On 28.10.2016 22:06, MRAB wrote:

On 2016-08-26 13:47, Steven D'Aprano wrote:

Ken has made what I consider a very reasonable suggestion, to introduce
SI prefixes to Python syntax for numbers. For example, typing 1K will be
equivalent to 1000.


Just for the record, this is what you can now do in C++:

User-Defined Literals
http://arne-mertz.de/2016/10/modern-c-features-user-defined-literals/


Nice to hear. :)

They now have 5 years of experience with that. Are there any surveys, 
experience reports, etc.?



Cheers,
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] Smart/Curly Quote Marks and cPython

[Sven R. Kunze]

+1 from me for the idea of a more useful error message (if possible).


On 22.10.2016 09:36, Ryan Birmingham wrote:

Per the comments in this thread, I believe that a better error message
for this case would be a reasonable way to fix the use case around this
issue.
It can be difficult to notice that your quotes are curved if you don't
know that's what you're looking for.

-Ryan Birmingham

On 22 October 2016 at 03:16, Steven D'Aprano > wrote:

On Sat, Oct 22, 2016 at 06:13:35AM +, Jonathan Goble wrote:
> Interesting idea. +1 from me; probably can be as simple as just having the
> tokenizer interpret curly quotes as the ASCII (straight) version of itself
> (in other words, " and the two curly versions of that would all produce 
the
> same token, and same for single quotes, eliminating any need for 
additional
> changes further down the chain).

There's a lot more than two. At least nineteen (including the ASCII
ones): 〝〞〟＂＇"'«»‘’‚‛“”„‟‹›


> This would help with copying and pasting
> code snippets from a source that may have auto-formatted the quotes 
without
> the original author realizing it.

Personally, I think that we should not encourage programmers to take a
lazy, slap-dash attitude to coding. Precision is important to
programmers, and there is no limit to how imprecise users can be. Should
we also guard against people accidentally using prime marks or ornaments
(dingbats):

′″‴‵‶‷ ❛❜❝❞❮❯

as well? If not, what makes them different from other accidents of
careless programmers?

I don't think we should be trying to guess what programmers mean, nor do
I think that we should be encouraging programmers to use word processors
for coding. Use the right tool for the right job, and even Notepad is
better for the occasional programmer than Microsoft Office or
LibreOffice. Programming is hard, requiring precision and care, and we
don't do beginners any favours by making it easy for them to be
imprecise and careless.

I would be happy to see improved error messages for smart quotes:

py> s = ‘abcd’
  File "", line 1
s = ‘abcd’
 ^
SyntaxError: invalid character in identifier

(especially in IDLE), but I'm very dubious about the idea of using
typographical quote marks for strings. At the very least, Python should
not lead the way here. Let some other language experiment with this
first, and see what happens. Python is a mature, established language,
not an experimental language.

Of course, there's nothing wrong with doing an experimental branch of
Python supporting this feature, to see what happens. But that doesn't
mean we should impose it as an official language rule.



--
Steve
___
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] Order of loops in list comprehension

[Sven R. Kunze]

On 22.10.2016 09:50, Alexander Heger wrote:
Well, an argument that was often brought up on this forum is that 
Python should do things consistently, and not in one way in one place 
and in another way in another place, for the same thing.


Like * in list displays? ;-)

Here it is about the order of loop execution.  The current behaviour 
in comprehension is that is ts being done the same way as in nested 
for loops.


It still would. Just read it from right to left. The order stays the same.


Which is easy enough to remember.  Same way, everywhere.


I am sorry but many disagree with you on this thread.

I still don't understand why the order needs to be one-way anyway. 
Comprehensions are a declarative construct, so it should be possible to 
mix those "for .. in .."s up in an arbitrary order.


Cheers,
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] Conditional Assignment in If Statement

[Sven R. Kunze]

On 18.10.2016 00:11, Michael duPont wrote:

What does everyone think about:

if foo = get_foo():
 bar(foo)

as a means to replace:

foo = get_foo()
if not foo:
 bar(foo)
del foo

Might there be some better syntax or a different keyword? I constantly run into 
this sort of use case.


Before really understanding what you need here I have some questions:

1) What does real-world code look like here exactly?
2) Why do you need foo to be deleted after the if?
3) Do you need this in interactive sessions, short-lived code or 
maintained code?



Cheers,
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] Multiple level sorting in python where the order of some levels may or may not be reversed

[Sven R. Kunze]

On 17.10.2016 23:53, Paul Moore wrote:

On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas
 wrote:

How about changing https://wiki.python.org/moin/HowTo/Sorting ?

Good point. Better still, https://docs.python.org/3.6/howto/sorting.html


Don't know what the real difference between those two are and how to 
change them but yes.


I think tweaking "Sort Stability and Complex Sorts" and/or adding some 
topic ("Multisort") in between is a good idea.



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] Order of loops in list comprehension

[Sven R. Kunze]

On 21.10.2016 01:43, Greg Ewing wrote:

Alexander Heger wrote:
For me the current behaviour does not seem unreasonable as it 
resembles the order in which you write out loops outside a comprehension


That's true, but the main reason for having comprehensions
syntax in the first place is so that it can be read
declaratively -- as a description of the list you want,
rather than a step-by-step sequence of instructions for
building it up.

If you have to stop and mentally transform it into nested
for-statements, that very purpose is undermined.



Exactly.


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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 18.10.2016 08:23, Greg Ewing wrote:

If it were a namedtuple, for example, you could write

  [*t for t in fulltext_tuples if t.language == 'english']

or

  [x for t in fulltext_tuples if t.language == 'english' for x in t]

The latter is a bit unsatisfying, because we are having to
make up an arbitrary name 'x' to stand for an element of t.
Even though the two elements of t have quite different roles,
we can't use names that reflect those roles.


It's an intriguing idea to use namedtuples but in this case one should 
not over-engineer.


What I dislike most are the names of "fulltext_tuple", "x", "t". If I 
were to use it, I think my coworkers would tar and feather me. ;) This 
is one of the cases where it makes absolutely no sense to invent 
artificial names for the sake of naming. I can name a lot of (internal) 
examples where we tried really hard at inventing named concepts which 
make absolutely no sense half a year later even to those who invented 
them. Repeatedly, in the same part of the code.


Each newly named concept introduces another indirection. Thus, we always 
need to find a middle ground between naming and using language features, 
so I (personally) would be grateful for this particular feature. :)



Because of that, to my eyes the version with * makes it easier
to see what is going on.


That's a very nice phrase: "makes it easier to see what is going on". I 
need to remember that.


Cheers,
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] Order of loops in list comprehension

[Sven R. Kunze]

On 19.10.2016 00:08, Rob Cliffe wrote:



But it's far too late to change it now, sadly.
Indeed. :-(  But if I were ruler of the world and could have my own 
wish-list for Python 4, this (as per the first example) would be on it.


I don't see no reason why we can't make it.

Personally, I also dislike this behavior.


Cheers,
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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 18.10.2016 10:01, Daniel Moisset wrote:
So, for me, this feature is something that could be covered with a 
(new) function with no new syntax required. All you have to learn is 
that instead of [*...] you use flatten(...)


The main motivation is not "hey we need yet another way for xyz" but 
"could we remove that inconsistency?". You wrote "[*...]"; which already 
works. It just that it does not work for all kinds of "..." . I hope 
that makes the motivation clearer.



I for one don't need yet another function or function cascade to make 
things work. "list(itertools.chain.from_iterable(...))" just works fine 
for all kinds of "...".



Cheers,
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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 17.10.2016 22:26, Paul Moore wrote:

Certainly having to add an import statement is extra typing. But
terseness was *never* a feature of Python. In many ways, a resistance
to overly terse (I could say "Perl-like") constructs is one of the
defining features of the language - and certainly, it's one that drew
me to Python, and one that I value.

I am completely with you on this one, Paul.

The statement about "cumbersomeness" was specific to this whole issue. 
Of course, importing feature-rich pieces from the stdlib is really cool. 
It was more the missed ability to do the same with list comprehensions 
of what is possible with list displays today. List displays feature * 
without importing anything fancy from the stdlib.


Nevermind, it seems we need to wait longer for this issue to come up 
again and maybe again to solve it eventually.


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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 17.10.2016 20:38, David Mertz wrote:
Under my proposed "more flexible recursion levels" idea, it could even 
be:


  [f(x) for x in flatten(it, levels=3)]

There would simply be NO WAY to get that out of the * comprehension 
syntax at all.  But a decent flatten() function gets all the flexibility.


I see what you are trying to do here and I appreciate it. Just one 
thought from my practical experience: I haven't had a single usage for 
levels > 1. levels==1 is basically * which I have at least one example 
for. Maybe, that relates to the fact that we asked our devs to use names 
(as in attributes or dicts) instead of deeply nested list/tuple structures.


Do you think it would make sense to start a new thread just for the sake 
of readability?



Honestly, it goes beyond just being "wrong". The repeated refusal to
even acknowledge any equivalence between [...x... for x in [a, b, c]]
and [...a..., ...b..., ...c...] truly makes it difficult for me to
accept some people's _sincerity_.


I am absolutely sincere in disliking and finding hard-to-teach this 
novel use of * in comprehensions.


You are consistent at least. You don't teach * in list displays, no 
matter if regular lists or comprehensions. +1


 P.S. It's very artificial to assume user are unable to use 'from 
itertools import chain' to try to make chain() seem more cumbersome 
than it is.


I am sorry but it is cumbersome.


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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 16.10.2016 07:08, David Mertz wrote:


In case it wasn't entirely clear, I strongly and vehemently opposed 
this unnecessary new syntax. It is confusing, bug prone, and would be 
difficult to teach.




As this discussion won't come to an end, I decided to consult my girlfriend.

I started with (btw. she learned basic Python to solve some math quizzes):
"""
Let's install a list in another one.

>>> meine_liste
[2, 3, 4, 5]
>>> ['a', meine_liste, 'b']
['a', [2, 3, 4, 5], 'b']

Maybe, we want to remove the brackets.

>>> ['a', *meine_liste, 'b']
['a', 2, 3, 4, 5, 'b']

Now, the problem of the discussion is the following:

>>> [(i,i,i) for i in range(4)]
[(0, 0, 0), (1, 1, 1), (2, 2, 2), (3, 3, 3)]

Let's remove these inner parentheses again.

>>> [*(i,i,i) for i in range(4)]
  File "", line 1
SyntaxError: iterable unpacking cannot be used in comprehension

Some guy wanted to remove that restriction.
"""

I said a teacher contributed to the discussion and he finds this too 
complicated and confusing and does not even teach * in list displays at 
all. Her reaction was hilarious:


"Whom does he teach? Children?"
Me: "What? No, everybody I think. Why?"
She: "It's easy enough to remember what the star does."


She also asked what would the alternative would look like. I wrote:
"""
>>> from itertools import chain
>>> list(chain.from_iterable((i,i,i) for i in range(4)))
[0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3]
"""
Her reaction was like: "That's supposed to be easy to remember? I find 
the star easier."


In the end, she also added: "Not everybody drives a car but they still 
exist."


Cheers,
Sven

PS: off to the weekend. She's already complaint that I should spend less 
time inside my mailbox and more with her. ;)

___
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] Heap data type, the revival

[Sven R. Kunze]

On 15.10.2016 23:19, Nick Timkovich wrote:

Features and speed are good, but I'm interested in getting something
with the basic features into the Standard Library so it's just there.
Not having done that before and bit clueless, I'm wanting to learn
that slightly less-technical procedure. What are the steps to make
that happen?


As I said, it has been discussed and the consensus so far was: "not 
everything needs to be a class if it does not provide substantial 
benefit" + "functions are more flexible" + "if it's slower that the 
original it won't happen".


Cheers,
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] Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 13.10.2016 16:10, Steven D'Aprano wrote:

On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote:
Multiplication with only a single argument? Come on. 

You didn't say anything about a single argument. Your exact words are
shown above: "where have I seen * so far?". I'm pretty sure you've seen
* used for multiplication. I also could have mentioned regexes, globs,
and exponentiation.

I cannot respond to your intended meaning, only to what you actually
write. Don't blame the reader if you failed to communicate clearly and
were misunderstood.


Steven, please. You seemed to struggle to understand the notion of the 
[*] construct and many people (not just me) here tried their best to 
explain their intuition to you. But now it seems you don't even try to 
come behind the idea and instead try hard not to understand the help 
offered. If you don't want help or don't really want to understand the 
proposal, that's fine but please, do us a favor and don't divert the 
thread with nitpicking nonsensical details (like multiplication) and 
waste everybody's time.



The context of the proposal is about lists/dicts and the */** unpacking 
syntax. So, I actually expect you to put every post here into this very 
context. Discussions without context don't make much sense. So, I won't 
reply further.



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] Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 13.10.2016 01:29, Steven D'Aprano wrote:

On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote:


So, my reasoning would tell me: where have I seen * so far? *args and
**kwargs!

And multiplication.


Multiplication with only a single argument? Come on.



And sequence unpacking.


We are on the right side of the = if any and not no the left side.




[...] is just the list constructor.

Also indexing: dict[key] or sequence[item or slice].


There's no name in front of [. So, I cannot be an index either.


Nothing else matches (in my head) and I also don't see any ambiguities. 
YMMV.


I remember a new co-worker, I taught how to use *args and **kwargs. It 
was unintuitive to him on the first time as well.


About the list constructor: we construct a list by writing [a,b,c] or by 
writing [b for b in bs]. The end result is a list and that matters from 
the end developer's point of view, no matter how fancy words you choose 
for it.


Cheers,
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] Fwd: unpacking generalisations for list comprehension

[Sven R. Kunze]

On 12.10.2016 21:38, אלעזר wrote:


What is the intuition behind [1, *x, 5]? The starred expression is 
replaced with a comma-separated sequence of its elements.


The trailing comma Nick referred to is there, with the rule that [1,, 
5] is the same as [1, 5].




I have to admit that I have my problems with this "comma-separated 
sequence" idea. For me, lists are just collections of items. There are 
no commas involved. I also think that thinking about commas here 
complicates the matter.



What * does, it basically plugs in the items from the starred expression 
into its surroundings:


[*[1,2,3]] = [1,2,3]

Let's plug in two lists into its surrounding list:

[*[1,2,3], *[1,2,3]] = [1,2,3,1,2,3]

So, as the thing goes, it looks like as if * could just work anywhere 
inside those brackets:


[*[1,2,3] for _ in range(3)] = [*[1,2,3], *[1,2,3], *[1,2,3]] = 
[1,2,3,1,2,3,1,2,3]



I have difficulties to understand the problem of understanding the 
syntax. The * and ** variants just flow naturally whereas the "chain" 
equivalent is bit "meh".


Cheers,
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] [Python-Dev] Optimizing list.sort() by checking type in advance

[Sven R. Kunze]

On 11.10.2016 05:02, Tim Peters wrote:
Let's not get hung up on meta-discussion here - I always thought 
"massive clusterf**k" was a precise technical term anyway ;-)


I thought so as well. ;)

http://www.urbandictionary.com/define.php?term=clusterfuck

Cheers,
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] xfork [was Re: async objects]

[Sven R. Kunze]

On 05.10.2016 06:11, Ethan Furman wrote:

On 10/04/2016 09:40 AM, Sven R. Kunze wrote:


As a result of past discussions, I wrote the module "xfork"
 which basically does this "golang goroutine" stuff. It's just
 a thin wrapper around "futures" but it allows to avoid that
 what René and Anthony objects about.


Looks cool!  Thanks! 


You're welcome. :)


Cheers,
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] async objects

[Sven R. Kunze]

On 05.10.2016 20:23, Michel Desmoulin wrote:
On the other hand, await / async is a fantastic interface to unify all 
concurrent paradigms and asyncio already provide a bridge with threads 
and subprocess. So it kinda make sense. 


Almost if it would not require duplicate pieces of code. But maybe, we 
are wrong and there won't be any duplications.


Cheers,
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] async objects

[Sven R. Kunze]

On 05.10.2016 08:49, Rene Nejsum wrote:



As a result of past discussions, I wrote the module "xfork" which basically does this "golang 
goroutine" stuff. It's just a thin wrapper around "futures" but it allows to avoid that what 
René and Anthony objects about.

I had a look at xfork, and really like it. It is implemented much like the 
lower level of PYWORKS and PYWORKS could build on xfork instead.


Thanks. :)


I think that the “model” of doing async should be defined in the Python 
language/runtime (like in Go, Erlang, ABCL) . I the ideal case it should be up 
to the runtime implementation (CPython, PyPy, Jython, IronPython etc.) how the 
asynchronous behaviour is implemented (greenlets, threads, roll-it-own, etc)


That's the way I see it as well. The Python language is extremely 
high-level. So, I guess in most cases, most people would just use the 
default implementation.


Cheers,
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] async objects

[Sven R. Kunze]

On 04.10.2016 13:30, Nick Coghlan wrote:

What it *doesn't* do, and what you need greenlet for, is making that
common interface look like you're using plain old synchronous C
threads.

If folks really want to do that, that's fine - they just need to add
gevent/greenlet as a dependency, just as the folks that don't like the
visibly object-oriented nature of the default unittest and logging
APIs will often opt for third party alternative APIs that share some
of the same underlying infrastructure.


Maybe, this is all a big misunderstanding.

asyncio is incompatible with regular execution flow and it's **always 
blocking**. However, asyncio is perceived by some of us (including me) 
as a shiny alternative to processes and threads but really isn't. I 
remember doing this survey on python-ideas (results here: 
https://srkunze.blogspot.de/2016/02/concurrency-in-python.html) but I 
get the feeling that we still miss something.


My impression is that asyncio shall be used for something completely 
different than dropping off things into a background worker. But looking 
at the cooking example given by Steve Dower (cf. blog post), at other 
explanations, at examples in the PEPs, it just seems to me that his 
analogy could have been made with threads and processes as well.


At its core (the ASYNC part), asyncio is quite similar to threads and 
processes. But its IO-part seem to drive some (design) decisions that 
don't go well with the existing mental model of many developers. Even 
PEP-reviewers are fooled by simple asyncio examples. Why? Because they 
forget to spawn an eventloop. "async def and await" are just useless 
without an eventloop. And maybe that's what's people frustration is 
about. They want the ASYNC part without worrying about the IO part.


Furthermore, adding 2 (TWO) new keywords to a language has such an 
immense impact. Especially when those people are told "the barrier for 
new keywords is quite high!!". So, these new keywords must mean something.



I think what would help here are concrete answers to:

0) Is asyncio a niche feature only be used for better IO?
1) What is the right way of integrating asyncio into existing code?
2) How do we intend to solve the DRY-principle issue?

If the answer is "don't use asyncio", that's a fine result but honestly 
I think it would be just insane to assume that we got all these 
features, all this work and all those duplicated functions all for 
nothing. I can't believe that. So, I am still looking for a reasonable 
use-case of asyncio in our environment.


Cheers,
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] if-statement in for-loop

[Sven R. Kunze]

On 04.10.2016 15:20, Random832 wrote:

The *real* question is what "break" should do. I think it should
likewise break from the outermost for-loop (but "continue" should still
continue the innermost one), but this does mean that it's not
mechanically identical to the "equivalent" nested loops [it would,
however, make it mechanically identical to the "generator and single
loop" form]


To me, a for loop starts with a "for" and ends with a ":". I wouldn't 
mind the ability of more "for"s or "if"s in between. I would skip over 
them anyway while reading. Technically, I agree with you as it matches 
my intuition:


for blaa foo blah bl blubber babble:
break# go outside
continue # go to next item
else:
# no break

Cheers,
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] from __pip__ import

[Sven R. Kunze]

I can definitely understand your point.

The only issue with it (besides that it doesn't seem to be a good way 
for dependency management) is how do you manage the syntax involved here?


Pip provides distributions. Each distribution contains a set of packages 
and modules. The latter can be imported, the former not. That's also due 
to the fact that the name of distribution can contain minuses:



from __pip__ import nova-lxd   # would this work?

What about versions?

from __pip__ import run-lambda>=0.1.0   # would this work?


Maybe, I thinking too complicated here but if it works for, say, 
"requests" people tend to want it for special cases as well. :)



Cheers,

Sven


On 19.09.2016 18:55, אלעזר wrote:
A library in PyPi  still requires installing it, which undermine many 
of the benefits. It won't help me with my gist/activestate recipe, 
code that I send to a friend, etc. I want to lower the barrier of 
inexperienced users.


As a documentation of dependencies it will suffice indeed.

Elazar

On Mon, Sep 19, 2016 at 7:38 PM Ethan Furman > wrote:


On 09/19/2016 09:25 AM, אלעזר wrote:

> Many proposals to add something to stdlib are rejected here with
the suggestion to add such library to pypi first. As noted by
someone, pypi is not as reachable as stdlib, and one should
install that package first, which many people don't know how.
Additionally, there is no natural distinction between 3rd party
dependencies and in-project imports (at least in tiny projects).
>
> This can be made easier if the first line of the program will
declare the required library, and executing it will try to
download and install that library if it is not installed yet.
Additionally, the 3rd party dependencies will be more explicit,
and editors can then allow you to search for them as you type.
>
> Of course it is *not* an alternative for real dependency
management, but it will ease the burden on small scripts and tiny
projects - which today simply break with errors that many users
does not understand, instead of simply asking permission to
install the dependency.

This should start out as a library on PyPI.  (Sorry, couldn't
resist. ;)

Actually, it should.  Perhaps a name of "import_pip" would make
sense?  Any hurdles faced by this library would be (mostly) the
same as a stdlib version.

--
~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/



___
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] if-statement in for-loop

[Sven R. Kunze]

On 11.09.2016 22:15, C Anthony Risinger wrote:


On Sep 11, 2016 7:11 AM, "Chris Angelico" > wrote:

>
> That said, though, filtered iteration isn't common enough to demand
> its own syntax IMO. I do it fairly often,

I do it often enough to want this.



Same here.

Most of the time it's just a single condition which disturbs the 
coherence of the loop body.


When I first started writing Python this struck me as an 
inconsistency... if it's useful in comprehensions, why not regular 
loops? I realize comprehensions are all about construction of the list 
itself, but the parallel still exists.


Also feels similar to guard statements. I'd love to see Python gain 
more pattern matching and destructuring features because they are 
wonderful in Erlang/Elixir.


> but it's usually fine to
> just have a condition on a separate line. (I do use ": continue"
> rather than making it two lines.)

FWIW, code I write or review would mandate this be two lines followed 
by a blank line, so 3 total. I require any abrupt change or 
termination in the current flow of control to be followed by a blank 
line so the reader clearly sees the possible jump (continue, break, 
and return especially).




___
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] Null coalescing operator

[Sven R. Kunze]

On 10.09.2016 19:14, Random832 wrote:

As I remember the discussion, I thought he'd more or less conceded on
the use of ? but there was disagreement on how to implement it that
never got resolved. Concerns like, you can't have a?.b return None
because then a?.b() isn't callable, unless you want to use a?.b?() for
this case, or some people wanted to have "a?" [where a is None] return a
magic object whose attribute/call/getitem would give no error, but that
would have to keep returning itself and never actually return None for
chained operators.

That appeared to be one solution to make the ?-syntax class useful.

But in the end, there were too many possibilities (operator?, nomad 
objects?, syntax expansion?, something else?), issues with all those "?" 
all over the place, hiding errors this way (which was the most serious 
one), and uncertainty about the overall benefit of this syntax compared 
to better designs like "how to not use None in the first place" didn't 
lead to a result so far.



Let's see those can be resolved.


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] Inconsistencies (was: Shuffled)

[Sven R. Kunze]

On 08.09.2016 04:00, Steven D'Aprano wrote:

On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:


>BUT experienced devs also need to recognize and respect the fact that
>younger/unexperienced developers are just better in detecting
>inconsistencies and bloody work-arounds.

That is not a fact. It is the opposite of a fact


You might have heard of: "There are no such things as facts, just 
opinions. Everything, we see is a perspective not the truth." See below, 
why this applies here as well.



  -- inexperienced
developers are WORSE at spotting inconsistencies, because they don't
recognise deep consistencies.


Your example (default arguments) might make sense when going one or two 
level deeper. However:



Is going deep really necessary at all?


People program for different reasons, to have fun, to create value for 
others, to educate, or for reasons we both cannot even think of. Why 
should they leave their level? Because of you or me? Because they need 
to know what Turing-completeness means? What calling conventions are? I 
don't think so. They wanna solve problems and get things done whether or 
not they know every single bit of the language they use. If they decide 
to go deeper, that's wonderful, but if they don't, don't force them.


So, an inconsistency at level 1 might be a **result of a consistency at 
level 0** BUT it nevertheless is and stays an inconsistency at level 1 
no matter how sophisticated the consistency at level 0 is.



And please note, some even want to go on level up, so inconsistencies at 
level 1 just plain suck then. People then simply don't care about how 
the current flows at cpu level or about your carefully handcrafted bits 
and pieces on level 0 which you are so proud of and which are so 
consistent there.


Cheers.
___
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] Typecheckers: there can be only one

[Sven R. Kunze]

On 08.09.2016 00:00, Paul Moore wrote:

On 7 September 2016 at 22:31, Hugh Fisher  wrote:

The average programmer such as myself will expect that if I write code
specifying the type of a variable or whatever it should *do
something*. It's code, I wrote it, it should be interpreted.

Reading the documentation should correct that mistaken expectation.


If you need to read the documentation in order to understand a product, 
something's wrong. Especially given the simplicity of the examples.


Some smartphones are delivered without a manual because they are 
considered to be as intuitive as breathing or walking.



Type annotations are code, not tests.

Not in Python they aren't.


Unfortunately, that's not true. :)


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] Shuffled

[Sven R. Kunze]

On 07.09.2016 02:49, Chris Kaynor wrote:
I'll weigh in and say that I've had a few cases where I've wanted a 
shuffled function, but not many. The vast majority are interactive 
uses, where I want to get a sampling of data, and in those cases I'm 
normally just printing the output (often, by letting the REPL handle it).


I'm fairly sure I've never wanted a shuffled in the actual code, and 
shuffle is almost always what I want (or just pulling items at random).


Probably the most common case is to produce a list of random numbers 
in a (small) range. The current code looks roughly like:


import random
items = list(range(10))
random.shuffle(items)
items # this is interactive, so this prints it for me

As this does not come up often, I almost invariably write the 
following first:

import random
random.shuffle(range(10))

Then get no output and write the first form. It is not a major 
difference, and only comes up maybe a few times a year at most for me.




That sounds extremely familiar. I would say the interactive session is 
the clear use-case here. But don't ask me why I need a shuffled list of 
somethings (probably for some highly vicious and immoral reasons ;-) ).


@David
Your idea of a PyPI package could almost work. However, in an 
interactive python console, I expect as much batteries included as 
possible to make it as quick as possible. And considering how simple 
such wrapper would be, it almost does not warrant the download of a 
third-party package.


@Tim
Of course it's easy to write a wrapper function. But from what I gather 
here, this is not the point. In interactive sessions, I find it highly 
annoying when I need to define my own functions. Especially because I 
need to do it again in a new python session.


Somebody provided a one-line hack using "sorted" to emulate "shuffled". 
The statement basically is: shuffling is a special kind of sorting. So, 
I would expect the interface to work the same. That at least suffices 
for me to understand Arek's point of view.


I would even go so far as to say:

shuffled(my_list) # returns a new shuffled list
my_list.shuffle() # shuffles in-place

Allowing to plug-in the RNG, when needed.

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/