from:"James Lu"

> This is already valid in 3.8, so we should forget about overloading := 
> with a second meaning.

def func(x=(a:=expression), y=a+1):
def func(x:=options):

These two syntaxes do not conflict with each other.

> Do we want to encourage callers to pass None to
> indicate default 
> arguments?

> Neither are we going to force function writers to accept None as a 
> default. So the way functions can be called will depend partially on the 
> function itself, and partially on the caller's personal choice for how 
> they prefer to handle defaults.

If it wasn't clear originally, I meant to ask, what is the best practice that
should be encouraged? And we're not 'forcing' anyone, we're just making
an easier syntax for doing something.

There's a thirty year tradition of doing that because there's no
terser way to do it. Out of the 85 instances I found in the STL, only 5 
instances
used "if arg is None: arg = " in one line. The others used a two-line form.
Having to read 2 lines to understand a common language pattern is inefficient.
___
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/VFRYCWBUXRMJFVG6PBCUK5D25M2ZUJOX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

"<:" Does not give the user any intuition about what it does.
"<~" Ok, but same problems as "<:" and precludes the use of "<~~" due to 
Python's parser.
"::" Could be confused with Haskell's type declaration operator.

If we want to avoid confusion with the walrus operator, "options!?=..."  is a 
decent alternative. It can be remembered as "if not there? equal to" [! there? 
=].
___
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/NKJAS22WXD2A6RFKOZP7HO4QCCEZVFHA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

I don't see myself using := for a few years, because support for Python 3.8
is not widespread yet among PyPy. However, that doesn't mean I oppose
evolving the language further so that down the line when Python 3.10
is ready, I'll have juicy new features to use.
___
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/BW2A57QJZ357CYFOZPV5NB6OZSNEGRTH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

> # Looks like an old Py2 repr
> def spam(x, y, ham={}):
> # Way too magical, although it parses currently and might
> # be done with the help of a magic built-in
> def spam(x, y, ham=LATE%{}):
> # wut?
> def spam(x, y, ham=>{}):
> # even worse
> def spam(x, y, ham=->{}):
> etc etc etc. There are lots of bad syntaxes and very few that have any merit.
> I'd love to have this as a feature, though.
> ChrisA

What's wrong with my := proposal?
___
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/MTM4UELULM6NWOCA7X6WLZR5MDDKG2MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

Thank you for raising a good point. I think we should ban referencing variables
not in the nearest outer enclosing scope until best practices regarding
closures emerge. For example:

global_var = 5
class A:
# not ok:
def foo(a:=global_var):
pass
class_var = global_var
# ok:
def foo(a:=class_var):
pass

for a in [1, 2, 3]:
# not ok:
def callback(a:=a):
pass
local = a
# ok:
def callback2(a:=local):
pass

This way, the design space is kept open.
___
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/3VXBWI7ZSYPBEXJJASWZUF5K2L7LDPZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-19 Thread James Lu

The "if arg is None: arg = " pattern occurs in the standard library eighty-five 
(85) times.

This command was used to find the count:
~/cpython/Lib$ perl -wln -e "/(?s)^(\s*)[^\n]if ([a-zA-Z_]+) is 
None:(\n)?\s+\2\s*=\s*/s and print" **
___
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/GWAJ62PZHDIS37NJ6WW4FCGDMDNMLPQK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-18 Thread James Lu

"There should be one-- and preferably only one --obvious way to do it."
___
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/U6OFH6FEWT2274KSRMQXH75TMT653TNO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Optional keyword arguments

2020-05-17 Thread James Lu

Many a python programmer have tired to see code written like:

def bar(a1, a2, options=None):
if options is None:
   options = {}
... # rest of function

syntax if argument is not passed, evaluate {} and store to options
def foo(options:={}): pass
syntax if argument is not passed or is None, evaluate {} and store to options*
def foo(options?={}): pass

The Zen of Python states "there shouldn't be two ways to do the same thing."

Thus, only one of ":=" or "?=" should be adopted. They should be evalued on:
 - Which encourages writing better code?
 - Which catches mistakes easier?

Do we want to encourage callers to pass None to indicate default arguments?

spam = { data: True } if arg else None
bar(a1, a2, param=spam)

versus

bar(a1, a2, { data: True }) if arg else bar(a1, a2)

versus

_ = foo.curry(a1, a2)
_({data: True}) if arg else _(a1, a2)

Since Python is a strongly typed language, it seems more consistent to me that
this code should throw an error:
def getoptions():
... # code to get options
# whoops! missing return statement
#return os.environ
foo(a1, a2, param=getoptions())

:= should be adopted because it catches mistakes more quickly.

On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." idiom.

(I propose adopting only ":=". I show "?=" as a strawman.)
___
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/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pandas rookie

2020-02-20 Thread James Lu

On Wed, Feb 19, 2020 at 5:23 PM FilippoM  wrote:

>
> Hi, I've got a Pandas data frame that looks like this
>
> In [69]: data.head
> Out[69]:
>  0  AndroidVIDEO_OK
> 1 Android 4.2.2   VIDEO_OK
> 2 Android 9   VIDEO_OK
> 3  iOS 13.3   VIDEO_OK
> 4Windows 10   VIDEO_OK
> 5 Android 9   VIDEO_OK
>  ......
> 24   Windows 10   VIDEO_OK
> 25Android 9   VIDEO_OK
> 26Android 6.0.1   VIDEO_OK
> 27   Windows XP   VIDEO_OK
> 28Android 8.0.0  VIDEO_FAILURE
> 29  Android 6.0   VIDEO_OK
>  ......
> 2994iOS 9.1   VIDEO_OK
> 2995  Android 9   VIDEO_OK
> 2996 Windows 10   VIDEO_OK
> 2997  Android 9   VIDEO_OK
> 2998 Windows 10   VIDEO_OK
> 2999   iOS 13.3   VIDEO_OK
>
>
> with 109 possible values of the OS columns and just two possible values
> ()VIDEO_OK and VIDEO_FAILURE) in the status column.
>
> How can I use Pandas' dataframe magic to calculate, for each of the
> possible 109 values, how many have VIDEO_OK, and how many have
> VIDEO_FAILURE I have respectively?
>
> I would like to end up with something like
>
> In[]: num_of_oks{"iOS 13.3"}
> Out:  15
>
> In[]: num_of_not_oks{"iOS 13.3"}
> Out:  3
>
> I am trying to do some matplotlib scatter plotting
>
> Thanks
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list


Have you considered using traditional unix tools, like cut and count? Or
traditional SQL.
___
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/B27PCY7Z7IPCGN4K5UCKOTISBG7DIJCW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python, Be Bold!

2020-01-05 Thread James Lu

I use macOS, and using Python is very confusing.

- Apple's bundled Python 2.7.
- Anaconda (Python scientific stack package manager) Python and conda.
- Homebrew (3rd party package manager for macOS) Python and pip.
I also believe that there is a PSF Python installer, but I am not sure.


Python, Be Bold captures the spirit of it should not be a shame to have the
interpreter/VM installed on end-users machines. It also facilitates the
work of other python devs. You installed it because of one Python program,
other programs benefit from it. It also proposes enhancements to the VM to
better facilitate that.

One big reason the web is a popular platform today among the general public

 is because it offers strong sandboxing,

and privelges are granted per-site, opt out by default.
Another reason the web is popular is because it loads quickly.
I suggest python apps feature sandboxing with a way to opt-in to special
permissions.
Perhaps, like the web, it could have a uniform distribution mechanism. I
suggest DNS.

I am suggesting Python compete with the web by implementing strong language
sandboxing.
I imagine a browser that can load regular web and "PyWeb."

A web browser is both a kernel and a VM for the web. The kernel interfaces
with the underlying OS: Linux, windows, MacOS.
I do not see "PyWeb" as a kernel, but I do see it as a VM. PyWeb would
merely provide a secure gatekeeper to the underlying operating system.
Like the Mac App Store, PyWeb could give each app its own sandboxed file
system.
This would also help introduce young people to Python. Like how the
DevTools console has taught many kids JavaScript.
I imagine being able to run Tensorflow or Calibre inside a Python "browser."

>
>
___
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/4EKYH5T3MZINO2Y7MPH7MTCADEMRE45T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python, Be Bold!

2020-01-02 Thread James Lu

Ideally, we'd have a functional package manager: one that can delete
binaries when disk space is running low, and recompiles from sources when
the binary is needed again. It could store Python 2 as a series of diffs
against Python 3.

On Thu, Jan 2, 2020, 2:22 AM Abdur-Rahmaan Janhangeer 
wrote:

> if not self-updating, at least the ability to update
>
> Yours,
>
> Abdur-Rahmaan Janhangeer
> pythonmembers.club  | github
> 
> Mauritius
> --
> https://mail.python.org/mailman/listinfo/python-list
>
___
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/ZNLX7C52K7LTUDAX4MAMX7GGFCVGYXTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Utilities for easier debugging



Sent from my iPhone

Begin forwarded message:

> From: James Lu 
> Date: July 28, 2019 at 6:22:11 PM EDT
> To: Andrew Barnert 
> Subject: Re: [Python-ideas] Utilities for easier debugging
> 
> 
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert  wrote:
>> 
>> This would break iPython’s improved interactive console, which already uses 
>> this syntax to provide a similar feature.
> If it’s so similar, I doubt it would break anything. This is intended to make 
> it easier to log variables for a complex application (multiple files).
___
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/NZMKXYJ2YCM53KVDPEN57ZMGAGCB5YQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Utilities for easier debugging



Sent from my iPhone

Begin forwarded message:

> From: James Lu 
> Date: July 28, 2019 at 6:21:04 PM EDT
> To: Andrew Barnert 
> Subject: Re: [Python-ideas] Utilities for easier debugging
> 
> 
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert  wrote:
>> 
>> Why not just allow anything that’s valid as a target, like identifier[expr]? 
>> Or even just any expression at all? Is there an advantage to defining and 
>> using a similar but more limited syntax here?
> Hmm, it should support any expression. I limited it at first because it was a 
> minimal strawman.
___
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/4LTFTK5ZPN52CQDPG72DG7BBP43677XM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Utilities for easier debugging



Sent from my iPhone

Begin forwarded message:

> From: James Lu 
> Date: July 28, 2019 at 6:22:11 PM EDT
> To: Andrew Barnert 
> Subject: Re: [Python-ideas] Utilities for easier debugging
> 
> 
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert  wrote:
>> 
>> This would break iPython’s improved interactive console, which already uses 
>> this syntax to provide a similar feature.
> If it’s so similar, I doubt it would break anything. This is intended to make 
> it easier to log variables for a complex application (multiple files).
___
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/ED7Z2YEZHQQLT5FHSHUN27KNITI6HNXO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Utilities for easier debugging



Sent from my iPhone

Begin forwarded message:

> From: James Lu 
> Date: July 28, 2019 at 6:21:04 PM EDT
> To: Andrew Barnert 
> Subject: Re: [Python-ideas] Utilities for easier debugging
> 
> 
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert  wrote:
>> 
>> Why not just allow anything that’s valid as a target, like identifier[expr]? 
>> Or even just any expression at all? Is there an advantage to defining and 
>> using a similar but more limited syntax here?
> Hmm, it should support any expression. I limited it at first because it was a 
> minimal strawman.
___
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/W2M4CX6EVLBHKORB5T6YKA3XQGZFCT26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Utilities for easier debugging



Sent from my iPhone

Begin forwarded message:

> From: James Lu 
> Date: July 28, 2019 at 6:23:06 PM EDT
> To: Andrew Barnert 
> Subject: Re: [Python-ideas] Utilities for easier debugging
> 
> 
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert  wrote:
>> 
>> You want this added to every module’s globals? Why not put it in builtins 
>> instead?
> It’s not a function call, it’s an expression that when evaluated triggers a 
> breakpoint, so you have to add it as a property descriptor.
___
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/EQY2RQMRVQF2IERDNIB6IEAT2KI4RLPI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Utilities for easier debugging

Minimal strawman proposal. New keyword debug. 

debug EXPRESSION

Executes EXPRESSION when in debug mode. 

debug context

Prints all the variables of the enclosing closure and all the variable names 
accessed within that block. For example, if in foo you access the global 
variable spam, spam would be printed. The format would be:

variableName: value
variableTwo: value

where "value" is the repr() of the variable.
Separated by new lines. The exact output format would not be part of the spec.

?identifier

would print "identifier: value." Repr as before. Using this in non-debug mode 
emits a warning.

?identifier.property.property

is also valid.

A new property descriptor on the global variable, “debugger.” This is an alias 
for importing PDB and causing the debugger to pause there. 

The behavior of this descriptor in non-debug mode is TBD.

Debug mode may be specified per-module at interpreter launch.
___
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/B2FLIPTEFG72HTEA2DHAYBXMDKLNTRVP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] something like sscanf for Python

2019-06-28 Thread James Lu



> On Jun 26, 2019, at 7:13 PM, Chris Angelico  wrote:
> 
> The main advantage of sscanf over a regular expression is that it
> performs a single left-to-right pass over the format string and the
> target string simultaneously, with no backtracking. (This is also its
> main DISadvantage compared to a regular expression.) A tiny amount of
> look-ahead in the format string is the sole exception (for instance,
> format string "%s$%d" would collect a string up until it finds a
> dollar sign, which would otherwise have to be written "%[^$]$%d").
> There is significant value in having an extremely simple parsing tool
> available; the question is, is it worth complicating matters with yet
> another way to parse strings? (We still have fewer ways to parse than
> ways to format strings. I think.)
I agree. Python should have an equivalent of scanf, but perhaps it should have 
some extensions:

%P - read pickled object
%J - read JSON object
%M - read msgpack object
___
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/CDKL3TNJOJYBFJOBMPLXU66LB6EZNR27/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: Using % sign for percentage

2019-06-26 Thread James Lu

What if we had reverse format strings, i.e. reading formatted input?

x = readf("{:.0%}", "50%")
# => x == 0.50
x = readf("{:.0}", "50")
# => x == 0.50

Readf takes the repr() of its second argument and “un-formats” the string.
___
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/DHACYJQLXNXLQCD3STGPQOQVNQ2AUZFE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Make $ a valid identifier and a singleton

2019-06-23 Thread James Lu

Make $ a valid identifier and a singleton. 

$ is a useful placeholder in [].

Possible function partial syntax:

def foo(x, y):
print(x, y)

partialized = foo[$, 10]
partialized(5) 
# => 5 10

___
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/V7ZCLM3RIVB7CM36OOVW7Q5TQLFGOPUA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: Allowing any variable to be used in a 'with... as...' expression

2019-06-23 Thread James Lu

If a function that tends to return a context manager returns None, that should 
not mean an error occurred. If an error or unexpected condition occurred, an 
exception should be thrown. Errors and exceptions should result in the code 
within the with statement not executing.

We could add a new constant to Python, “Dont.” It’s a global falsey Singleton 
and a context manager that causes the code inside “with” not to execute.

> On May 18, 2019, at 10:44 PM, Yonatan Zunger  wrote:
> 
> an
___
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/VJ2ZRJKPNUWQZ3UHJN26X236E5REVUXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] unittest block

2019-06-18 Thread James Lu

# regular code
unittest:
 # test code goes here

This code would be run when the runtime -unittest flag is passed. It would 
function as test usages and example client code. The code within the block 
would remain in .pyc, unless the -O switch is passed. 


Write "" or ## above a unittest to include it in generated documentation.
___
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/WCB4WBK3UPLGX2MZ2QO7DIWW5IOPQQ5F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-18 Thread James Lu

> python is not build for speed

Yes, but it scales to speed, letting you speed up your code easily when you 
need it. Consider Cython and Nuitka. Consider GraalPython. Consider... consider 
that C dylibs can be loaded and used from within Python without any wrappers.

You can create the <- operator in existing plus by overriding __lt__ and the 
unary negative sign. Same goes for <~.

Perhaps you should propose an unary postfix - operator. That would let you 
create the -> operator in user space.
___
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/FBTDXE7GTT7QIA2SEOC4APGT4UXPNJ6V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-17 Thread James Lu

There is probably some existing python API you can hijack to make custom 
locals() and globals() work everywhere. Perhaps pdb and inspect.stack are good 
places to start; maybe there’s a PDB API to break on every new stack frame and 
maybe you can use inspect to do the proper assignment overrides. 

Python is a very layered language.

Sent from my iPhone

> On May 25, 2019, at 4:53 AM, Yanghao Hua  wrote:
> 
>> On Fri, May 24, 2019 at 10:34 PM Ricky Teachey  wrote:
>> 
>> You can do things like this with exec():
>> 
>> class SafeDict(dict):
>>curated_keys = {"a", "b", "c"}
>>def __setitem__(self, k, v):
>>if k not i self.curated_keys:
>>raise Exception(f"{k!r} key not allowed")
>>super().__setitem__(k, v)
>> 
>> locals_dict = SafeDict()
>> globals_dict = SafeDict()
>> 
>> exec("d=1", locals_dict, globals_dict)  # Exception: 'd' key not allowed
>> 
>> You can do all sorts of things using that technique, including the way 
>> assignment to variables is handled.
> 
> I see your point now. In this case user will need to write HDLs
> probably in below fashion:
> 
> class my_module:
>def __init__(self, input, output, ...):
>...
>def process(self):
>exec("signal = 5", locals, globals)
># compare this with: signal <== 5
> 
> I fully agree this can work, but also it doesn't seem to be any better
> looking than signal.next = 5. I think there are two important point
> here, first is to make HDL design feels as natural as possible and as
> pythonic as possible as well as leaving very little room for mistakes,
> second is to make HDL design at least as easy and as intuitive as in
> traditional HDLs. And when I see this can actually be achieved easily
> with less than 100 lines of CPython code changes I am tempted to give
> it a try (I am so in love with python ...).
> 
> The other thing I was thinking about is PEP572 assignment expression
> (a := b), if it could be modified to allow user override (e.g. via
> __assign__()), and allow it to be used without bracket like "y :=
> f(x)" if __assign__ is present in y. Then this is even aligned with
> Chisel's assignment operation and I'd be completely happy with 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
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/QBX47WW5PDA4G77MJ7HPSRMAHIRVXQRW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-17 Thread James Lu

Perhaps you should take a look at Dlang. Using opDispatch and a with statement 
and compile time code generation, you may be able to accomplish what you’re 
trying to do entirely in D.

> On May 24, 2019, at 4:05 AM, Yanghao Hua  wrote:
> 
>> On Fri, May 24, 2019 at 1:59 AM Steven D'Aprano  wrote:
>> 
>>> On Thu, May 23, 2019 at 06:23:31PM +0200, Yanghao Hua wrote:
>>> 
>>> Is this (<== and ==>) something can be made into CPython?
>> 
>> If it goes into CPython, eventually every other Python needs to do the
>> same.
>> 
>> Of course it *could* be put into Python, but you haven't given
>> sufficient justification for why it *should* be put into Python.
>> 
>> Why does your DSL need a seperate assignment operator? How is it
>> different from regular assignment?
>> 
>> Could you use __setitem__ instead?
>> 
>> Instead of this:
>> 
>>variable <== thing  # magic happens here
>> 
>> can you write this?
>> 
>>obj.variable = thing  # magic happens here
>> 
>> 
>> If your DSL is so different from Python that it needs new operators,
>> perhaps you should write an interpreter for your language and run that
>> seperately.
>> 
>>code = """
>>any syntax you like <- thing
>>"""
>>result = interpret(code)
> 
> Well, if python is not envisioned to be able to represent almost
> everything elegantly maybe I should indeed walk away from this idea.
> (This is sad for me ... I have been saying and believing python is
> envisioned that way for more than 20 years now). Your argument could
> be applied on PEP465 as well, where the only justification is to make
> matrix operation prettier. I have explained the problem of use
> descriptors in previous replies, where you cannot have a local signal,
> e.g. obj.signal = thing # works, but local_signal = thing # doesn't
> work.
> ___
> 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
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/5XE3WSGBJN6CTDNG55D3WUJD2BH2PUAC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] `if-unless` expressions in Python

2019-06-03 Thread James Lu

`if-unless` expressions in Python

if condition1 expr unless condition2

is an expression that roughly reduces to

expr if condition1 and not condition2 else EMPTY


This definition means that expr is only evaluated if `condition1 and not
condition2` evaluates to true. It also means `not condition2` is only
evaluated if `condition1` is true.

# EMPTY

EMPTY is not actually a real Python value-- it's a value that collapses
into nothing when used inside a statement expression:

print([
  if False never_called() unless False,
  if False never_called() unless False,
]) # => []

print([
  3,
  if False never_called() unless False,
  if False never_called() unless False,
  2,
  if True 5 unless False,
  4
]) # => [3, 2, 5, 4]


EMPTY is neither a constant exposed to the Python runtime nor a symbol.
It's a compiler-internal value.

# Use cases

Assertions.

assert if condition1 predicate(object) unless condition2

(This would be more readable with assert expressions.)

Macros.

# Equivalent syntax in existing Python

As a statement:

if condition1 and not condition2: predicate(object)

predicate(object) if condition1 and not condition2

# Backward compatibility

The `unless` word is only recognized as special inside `if-unless`
statements. The continued use of the word as a variable name is discouraged.
___
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] Add GraalPython to the list of Python implementations

2019-05-23 Thread James Lu

https://github.com/graalvm/graalpython
https://www.python.org/download/alternatives/

GraalPython is an implementation on the Truffle VM, by Oracle Labs. The
Truffle
VM gives Python high-performance interoperability with other languages-
including JVM, LLVM, Ruby, and JavaScript. The Truffle VM is an "AST
Interpreter," which I think means that it executes an interpreter over AST
nodes, then compiles and inlines those nodes to machine code as necessary.

By default, Truffle VM with the Graal JIT enabled. The Graal JIT compiles
the
AST down to machine code.


My personal experiences with the Truffle JavaScript show that it uses
significantly more memory than V8, while having lower performance on pure
JavaScript. This might be different for GraalPython, however.

Converting a JavaScript data structure into a C struct allowed
computation-intensive JavaScript code to use ~30% less cpu power. I don't
really
know if this is already possible in Python through Python's built-in C
extensions. (Since CPython still has to go through its normal dot attribute
lookup machinery, I'd imagine the performance benefits of converting a
Python
class to a C struct would be little.)

TL;DR: GraalPython is a Python implementation with a JIT, an easy way to
add C
extensions, and an easily extensible AST interpreter.
___
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] Break multiple loop levels

2019-05-12 Thread James Lu

I think a Python version of longjmp() and setjmp() might be easier to
understand.

On Sun, May 12, 2019 at 6:23 PM David Mertz  wrote:

> On Sun, May 12, 2019, 5:36 PM Paul Moore  wrote:
>
>> On Sun, 12 May 2019 at 21:06, David Mertz  wrote:
>> > I thought of 'as' initially, and it reads well as English. But it felt
>> to me like the meaning was too different from the other meanings of 'as' in
>> Python. I might be persuaded otherwise.
>>
>> If you think in terms of "named loops" rather than "labels", "as"
>> makes a lot more sense.
>
>
> Every name created with 'as' currently is a regular Python object, with a
> memory address, and some methods, that can participate in comparison (at
> least equality), that has a type, can be passed as a function argument,
> etc. Actually, all that is true of EVERY name in Python other than keywords.
>
> It seems like none of this would be true of a loop name/label. Hence my
> first thought that a different way of introducing the word is more clear...
> Maybe we can just prefix lines with labels instead, and add a 'goto'
> command :-)
> ___
> 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] Built-in parsing library

2019-03-31 Thread James Lu

Stack-based LL(1) push down automata can be implemented by hand, indeed isn’t 
that that a textmateLanguage file is? There’s also the option of using Iro to 
generate a tmLanguage.
___
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] from future import runtime_default_kwargs

2019-03-11 Thread James Lu

When

from __future__ import runtime_default_kwargs


Is run, 

def a(b=1, c=b+2, d=[]):
pass

behaves as (if the peephole optimizer didn’t exist)

def a(b=None, c=None):
if b is None:
b = 1
if c is None:
c = b + 2
if d is None:
d = []

i.e. the keyword expression is evaluated at runtime.

Perhaps a restriction on “literals only” can be made so people don’t abuse this.___
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] The $update operator for dictionaries

2019-03-10 Thread James Lu

This is a horrible idea.

I proposed to Mr. Fine earlier that we adopt a << operator.

d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2
overriding keys from d2.

On Sat, Mar 9, 2019 at 4:50 PM Jonathan Fine  wrote:

> A good starting point for discussing the main idea is:
> PEP 465 -- A dedicated infix operator for matrix multiplication
> https://www.python.org/dev/peps/pep-0465
>
> Matrix multiplication is one of many special binary mathematical
> operators. PEP 465 successfully argues the merits of introducing a
> special operator for matrix multiplication. This thread starts from a
> discussion of the merits of binding dict.update to an operator. (For
> update, '+', '|' and '<<' the leading candidate symbols.)
>
> Matrices and linear algebra are not the only part of mathematics that
> is usually expressed with infix operators. Thus, I suggest that the
> main questions are:
>
> 1. In practice, how important are additional infix operators to the
> Python community?
> 2. Can we harmoniously extend Python to accommodate these new operators?
>
> Here, from PEP 465, are some highlights of the benefits.
>
> 
> Infix @ dramatically improves matrix code usability at all stages of
> programmer interaction.
>
> A large proportion of scientific code is written by people who are
> experts in their domain, but are not experts in programming.
>
> For these kinds of users, whose programming knowledge is fragile, the
> existence of a transparent mapping between formulas and code often
> means the difference between succeeding and failing to write that code
> at all.
> 
>
> Most mathematical and scientific formulas can be written in LaTeX
> notation, which gives standard names for the infix operators
> mathematicians use.
>
> There is no transparent and obvious mapping from the present operators
> to those used in mathematics.
> https://docs.python.org/3/reference/lexical_analysis.html?#operators
>
> Using Unicode symbols for the math operators is probably unwise.
> Better, I suggest, is to use the LaTeX names.
>
> There is some evidence (the wish to bind dict.update to an infix
> operator) that outside of mathematics there is a demand for custom
> infix operators.
>
> --
> Jonathan
> ___
> 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] PEP: Dict addition and subtraction

2019-03-07 Thread James Lu

Now, this belongs as a separate PEP, and I probably will write one, but I 
propose:

d1 << d2 makes a copy of d1 and merges d2 into it, and when the keys conflict, 
d2 takes priority. (Works like copy/update.)

d1 + d2 makes a new dictionary, taking keys from d1 and d2. If d1 and d2 have a 
different value for same key, a KeyError is thrown. 




___
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] Make Python 2.7’s online docs optionally redirect to Python 3 online docs

2019-03-07 Thread James Lu

Rationale: When I use a search engine to google a Python question, I frequently 
get a link to a page of the Python 2.7 documentation that shows before the 
Python 3 documentation link. 

This is annoying and slows down my programming.

I propose: That we add a setting to Python’s online documentation that will 
optionally given that certain conditions are met, we redirect the user to the 
corresponding Python 3 documentation entry. The conditions:
- The Referer header is set to a URL of a major search engine (the Referer is 
the URL of the last page that whose link was clicked on to reach the 
documentation)
- The user has opted-in to this behavior.

(Conceptually this should be user script, but for the collective conscience of 
all python developers, a doc option would be better. )

I understand that some core devs might just have documentation downloaded and 
just use that, but a large portion of Python users  primarily use online 
documentation

James Lu
___
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] PEP: Dict addition and subtraction

By the way, my “no same keys with different values” proposal would not apply to 
+=.
___
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] PEP: Dict addition and subtraction


> On Mar 4, 2019, at 11:25 AM, Steven D'Aprano  wrote:
> 
> The PEP gives a good example of when this "invariant" would be 
> unnecessarily restrictive:
> 
>For example, updating default configuration values with 
>user-supplied values would most often fail under the 
>requirement that keys are unique::
> 
>prefs = site_defaults + user_defaults + document_prefs
> 
> 
> Another example would be when reading command line options, where the 
> most common convention is for "last option seen" to win:
> 
> [steve@ando Lib]$ grep --color=always --color=never "zero" f*.py
> fileinput.py: numbers are zero; nextfile() has no effect.
> fractions.py: # the same way for any finite a, so treat a as zero.
> functools.py: # prevent their ref counts from going to zero during
> 
Indeed, in this case you would want to use {**, **} syntax. 


> and the output is printed without colour.
> 
> (I've slightly edited the above output so it will fit in the email 
> without wrapping.)
> 
> The very name "update" should tell us that the most useful behaviour is 
> the one the devs decided on back in 1.5: have the last seen value win. 
> How can you update values if the operation raises an error if the key 
> already exists? If this behaviour is ever useful, I would expect that it 
> will be very rare.

> An update or merge is effectively just running through a loop setting 
> the value of a key. See the pre-Python 1.5 function above. Having update 
> raise an exception if the key already exists would be about as useful as 
> having ``d[key] = value`` raise an exception if the key already exists.
> 
> Unless someone can demonstrate that the design of dict.update() was a 
> mistake
You’re making a logical mistake here. + isn’t supposed to have .update’s 
behavior and it never was supposed to.

> , and the "require unique keys" behaviour is more common,
I just have. 99% of the time you want to have keys from one dict override 
another, you’d be better off doing it in-place and so would be using .update() 
anyways.

> then 
> I maintain that for the very rare cases you want an exception, you can 
> subclass dict and overload the __add__ method:
Well, yes, the whole point is to define the best default behavior.
___
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] PEP: Dict addition and subtraction

> On Mon, Mar 04, 2019 at 10:01:23AM -0500, James Lu wrote:
> 
> If you want to merge it without a KeyError, learn and use the more explicit 
> {**d1, **d2} syntax.

On Mar 4, 2019, at 10:25 AM, Steven D'Aprano  wrote:

> In your previous email, you said the {**d ...} syntax was implicit:
> 
>In other words, explicit + is better than implicit {**, **#, unless 
>explicitly suppressed.  Here + is explicit whereas {**, **} is 
>implicitly allowing inclusive keys, and the KeyError is expressed 
>suppressed by virtue of not using the {**, **} syntax.
> 
> It is difficult to take your "explicit/implicit" argument seriously when 
> you cannot even decided which is which.
I misspoke. 
> In your previous email, you said the {**d ...} syntax was implicit:
> 
>In other words, explicit + is better than implicit {**, **#, unless 
>explicitly suppressed.  Here + is explicit whereas {**, **} is 
>implicitly allowing inclusive keys, and the KeyError is expressed 
>suppressed by virtue of not using the {**, **} syntax.
> 
> It is difficult to take your "explicit/implicit" argument seriously when 
> you cannot even decided which is which.

Yes, + is explicit. {**, **} is implicit. 

My argument:

We should set the standard that + is for non-conflicting merge and {**, **} is 
for overriding merge. That standard should be so that + explicitly asserts that 
the keys will not conflict whereas {**d1, **d2} is ambiguous on why d2 is 
overriding d1.^

^Presumably you’re making a copy of d1 so why should d3 have d2 take priority? 
The syntax deserves a comment, perhaps explaining that items from d2 are newer 
in time or that the items in d1 are always nonces. 

The + acts as an implicit assertion and an opportunity to catch an invariant 
violation or data input error.

Give me an example of a situation where you need a third dictionary from two 
existing dictionaries and having conflict where a key has a different value in 
both is desirable behavior. 

The situation where non-conflicting merge is what’s desired is more common and 
in that case throwing an exception in the case of a conflicting value is a good 
thing, a way to catch code smell.___
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] PEP: Dict addition and subtraction



> On Mar 4, 2019, at 10:02 AM, Stefan Behnel  wrote:
> 
> INADA Naoki schrieb am 04.03.19 um 11:15:
>> Why statement is not enough?
> 
> I'm not sure I understand why you're asking this, but a statement is "not
> enough" because it's a statement and not an expression. It does not replace
> the convenience of an expression.
> 
> Stefan
There is already an expression for key-overriding merge. Why do we need a new 
one? 
___
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] PEP: Dict addition and subtraction




> On Mar 4, 2019, at 3:41 AM, Stefan Behnel  wrote:
> 
> James Lu schrieb am 04.03.19 um 03:28:
>> I propose that the + sign merge two python dictionaries such that if there 
>> are conflicting keys, a KeyError is thrown.
> 
> Please, no. That would be really annoying.
> 
> If you need that feature, it can become a new method on dicts.
> 
> Stefan
If you want to merge it without a KeyError, learn and use the more explicit 
{**d1, **d2} syntax.
___
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] PEP: Dict addition and subtraction

2019-03-03 Thread James Lu

I propose that the + sign merge two python dictionaries such that if there are 
conflicting keys, a KeyError is thrown. 

This way, d1 + d2 isn’t just another obvious way to do {**d1, **d2}. The second 
syntax makes it clear that a new dictionary is being constructed and that d2 
overrides keys from d1.

One can reasonably expect or imagine a situation where a section of code that 
expects to merge two dictionaries with non-conflicting keys commits a semantic 
error if it merges two dictionaries with conflicting keys.

To better explain, imagine a program where options is a global variable storing 
parsed values from the command line.

def verbose_options():
 if options.quiet
 return {'verbose': True}

def quiet_options():
 if options.quiet:
 return {'verbose': False}

If we were to define an options() function, return {**quiet_options(), 
**verbose_options()} implies that verbose overrules quiet; whereas return 
quiet_options() + verbose_options() implies that verbose and quiet cannot be 
used simultaneously. I am not aware of another easy way in Python to merge 
dictionaries while checking for non-conflicting keys.

Compare:

def settings():
 return {**quiet_options(), **verbose_options()}

def settings():
 try:
 return quiet_options() + verbose_options() 
 except KeyError:
 print('conflicting options used', sys.stderr')
 sys.exit(1)

***

This is a simple scenario, but you can imagine more complex ones as well. Does 
—quiet-stage-1 loosen —verbose? Does —quiet-stage-1 conflict with 
—verbose-stage-1?Does —verbosity=5 override —verbosity=4 or cause an error?

Having {**, **} and + do different things provides a convenient and Pythonic 
way to model such relationships in code. Indeed, you can even combine the two 
syntaxes in the same expression to show a mix of overriding and exclusionary 
behavior.

Anyways, I think it’s a good idea to have this semantic difference in behavior 
so Python developers have a good way to communicate what is expected of the two 
dictionaries being merged inside the language. This is like an assertion 
without 

Again, I propose that the + sign merge two python dictionaries such that if 
there are conflicting keys, a KeyError is thrown, because such “non-conflicting 
merge” behavior would be useful in Python. It gives clarifying power to the + 
sign. The + and the {**, **} should serve different roles. 

In other words, explicit + is better than implicit {**, **#, unless explicitly 
suppressed.  Here + is explicit whereas {**, **} is implicitly allowing 
inclusive keys, and the KeyError is expressed suppressed by virtue of not using 
the {**, **} syntax. People expect the + operator to be commutative, while the 
{**, **} syntax prompts further examination by virtue of its “weird” syntax.
___
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] Dict joining using + and +=

2019-02-28 Thread James Lu

I agree with Storchaka here. The advantage of existing dict merge syntax is 
that it will cause an error if the object is not a dict or dict-like object, 
thus preventing people from doing bad things.


> On Feb 28, 2019, at 2:16 AM, Serhiy Storchaka  wrote:
> 
> 27.02.19 20:48, Guido van Rossum пише:
>> On Wed, Feb 27, 2019 at 10:42 AM Michael Selik > > wrote > The dict subclass collections.Counter 
>> overrides the update method
>>for adding values instead of overwriting values.
>>
>> https://docs.python.org/3/library/collections.html#collections.Counter.update
>>Counter also uses +/__add__ for a similar behavior.
>> >>> c = Counter(a=3, b=1)
>> >>> d = Counter(a=1, b=2)
>> >>> c + d # add two counters together:  c[x] + d[x]
>> Counter({'a': 4, 'b': 3})
>>At first I worried that changing base dict would cause confusion for
>>the subclass, but Counter seems to share the idea that update and +
>>are synonyms.
>> Great, this sounds like a good argument for + over |. The other argument is 
>> that | for sets *is* symmetrical, while + is used for other collections 
>> where it's not symmetrical. So it sounds like + is a winner here.
> 
> Counter uses + for a *different* behavior!
> 
> >>> Counter(a=2) + Counter(a=3)
> Counter({'a': 5})
> 
> I do not understand why we discuss a new syntax for dict merging if we 
> already have a syntax for dict merging: {**d1, **d2} (which works with *all* 
> mappings). Is not this contradicts the Zen?
> 
> ___
> 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] PEP 8 update on line length

2019-02-22 Thread James Lu

A general rule of thumb is, if Python feels inconvenient or awkward, you’re 
doing something wrong. 
___
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] Vectorization [was Re: Add list.join() please]

2019-02-08 Thread James Lu

Has anyone thought about my proposal yet? I think because it allows chained 
function calls to be stored, which is probably something that is a common; if 
imagine people turning the same series of chained functions into a lambda of 
its own once it’s used more than once in a program.

Arguably, the lambda syntax is more readable and puts on less visual burden.

Sent from my iPhone

> On Feb 8, 2019, at 3:35 PM, David Mertz  wrote:
> 
>> On Fri, Feb 8, 2019 at 3:17 PM Christopher Barker  
>> wrote:
> 
>> >vec_seq = Vector(seq)
>> >(vec_seq * 2).name.upper()
>> ># ... bunch more stuff
>> >seq = vec_seq.unwrap()
>> 
>> what type would .unwrap() return?
> 
> The idea—and the current toy implementation/alpha—has .unwrap return whatever 
> type went into the Vector creation.  Might be a tuple, list, set, deque, or 
> it might be an iterator.  It might even be some custom collection that isn't 
> in the standard library.
> 
> But you can also explicitly make a Vector into something else by using that 
> constructor.  Pretty much as I gave example before:
> 
> set(Vector(a_list)) # Get a set
> Vector(a_list)).unwrap()# Get a list (without needing to know type to 
> call .unwrap())
>  
> -- 
> Keeping medicines from the bloodstreams of the sick; food 
> from the bellies of the hungry; books from the hands of the 
> uneducated; technology from the underdeveloped; and putting 
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> 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] Keeping discussion relevant

2019-02-08 Thread James Lu

Sometimes I see threads briefly go into topics that are unrelated to new 
features in Python. For example: talking about a writer’s use of 
“inhomogeneous” vs “heterogenous” vs “anhomogenous.” We get what the original 
author meant, there is no need to fiddle with the little details of language at 
this point, even if it is fun.

These extra emails, though harmless, impose a visual, time, and navigational 
burden on the readers of the thread. It’s okay if the problem is little but not 
if it’s big.

Two questions:
How often does off-topic discussion occur? Does it need to be find ways to 
reduce the amount?
How can we find ways to reduce the amount?
___
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] Vectorization [was Re: Add list.join() please]

2019-02-07 Thread James Lu

Here are some alternate syntaxes.

These are all equivalent to len(print(list)).

(len | print)(list)
(len |> print)(list)
(print <| len)(list)
print <| len << list
list >> print <| len
list >> len |> print


## Traditional argument order 
print <| len << list

## Stored functions 
print_lengths = len | print
print_lengths = len |> print
print_lengths = print <| len

These can be called using callable syntax.
These can be called using << syntax.
These can be called using >> syntax.
## Lightweight traditional syntax order
(print | len)()

# Explanation
The pipeline operator (|, |>, <|) create an object.

That object implements, depending on the chosen implementation, some 
combination of the __call__ operator, the __rshift__ operator, and/or the 
__lshift__ operator.
—
I am not proposing Python has all these operators at the same time, just 
putting these ideas out there for discussion. 
___
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] Consistency in naming [was Re: ...ALL CAPS] (off-list)

I agree with everything all of you have said in reply to me.

Sent from my iPhone

> On Feb 3, 2019, at 7:34 PM, Ned Batchelder  wrote:
> 
>> On 2/3/19 6:01 PM, Steven D'Aprano wrote:
>> (1) Taking the group discussion off-list should be done rarely, and
>> usually only for personal messages that shouldn't be shared
>> publically, or by mutual agreement for off-topic discussions.
>> 
>> I can't see Ned's original comment in either my inbox, or at the
>> archives, so it seems that he took the discussion off-list. I don't know
>> why. It doesn't strike me as either personal or off-topic, so taking it
>> off-list seems to be both unnecessary and a little rude to the rest of
>> the group -- why were the rest of us excluded?
>> 
>> But since Ned apparently intended to take it off-list, it is only polite
>> to respect that your reply.
>> 
>> 
>> (2) The long-standing tradition is to put "OFFLIST" at the *start* of
>> the subject line, not the end where it is easy to overlook.
>> 
>> To make it even more clear, we should explicitly state that the
>> message is off-list at the top of the message.
>> 
>> (Especially if you intend the message to be confidential.)
> 
> I replied to James privately because I felt that the question of "Python's 
> decline," and James' reasons for believing it to be so, were not on-topic for 
> a list about suggestions for improving Python.  It also seemed to me that it 
> could easily devolve into an unproductive discussion for such a large group.  
> But, it was probably also of interest to the group, many of whom were 
> probably wondering the same things I was, so I can see how it could have 
> stayed in the list (where it now is.)
> 
> It also seemed to me to be a topic which could easily result in James feeling 
> at a disadvantage, being on the other side of a subjective debate from the 
> bulk of the group. I had hoped to discuss it with him in a setting that was 
> less likely to get heated.
> 
> I didn't mean to be rude to anyone.
> 
> --Ned.
> 
> ___
> 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] Mention more alternative implementations on the PSF website

https://www.python.org/download/alternatives/ should possibly mention:

- Cython and Nuitka
- Mention the possibility of compiling Python to WASM
   - WASM allows Web and Mobile use of Python at possibly native speed.
Though not mature yet, Pyodide is a working implementation.
___
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] Clearer communication


>> On Feb 2, 2019, at 7:17 PM, Steven D'Aprano  wrote:
>> 
>> On Sat, Feb 02, 2019 at 11:12:02AM -0500, James Lu wrote:
>> 
>> This list IS hard for newcomers. I wish there was one place where I 
>> could read up on how to not feel like a noob.
> 
> It has become unfashionable to link to this, because it is allegedly too 
> elitest and unfriendly and not welcoming enough, but I still think it is 
> extremely valuable:
> 
> http://www.catb.org/esr/faqs/smart-questions.html
> 
> (Its also somewhat unpopular because the maintainer has become 
> something of a politically Right-wing extremist.)
> 
> If you think of *proposals* as a kind of question:
> 
>   "What are the Pros and Cons of this suggestion?"
> 
> rather than
> 
>   "We must do this. I have spoken, make it so!"
> 
> then the Smart Questions document is relevant. Do your research first. 
> What have you tried? Have you tried to knock holes in your own proposal 
> or are you so excited by the Pros that you are blind to the Cons? What 
> do other languages do? Do they differ from Python in ways which matter 
> to your proposal?
> 
> Did you make even a feeble attempt to search the archives, 
> Stackoverflow, etc, or just post the first ill-formed thought that came 
> to your mind?
> 
> If your proposal been asked before, unless you are bringing something 
> new to the discussion, don't waste everyone's time covering old ground.


That’s some great stuff, can we document it somewhere? I think it would benefit 
future proposers.

I’ve been subconsciously aware of what you said but haven’t been able to 
express 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/

Re: [Python-ideas] Clearer communication

Well, the question wasn’t about any specific proposal but improving 
communication in general. I don’t have a specific straw man.


Sent from my iPhone

> On Feb 2, 2019, at 7:00 PM, Steven D'Aprano  wrote:
> 
>> On Sat, Feb 02, 2019 at 10:59:36AM -0500, James Lu wrote:
>> 
>> I think we need to step away from the egalitarian ideal and have some 
>> way of knowing that Python committees are python committers. It’s 
>> really difficult to know how well your proposal is doing without 
>> having this.
> 
> Speaking of clearer communication (see the subject line), who are you 
> referring to and which proposal do you mean?
> 
> 
> -- 
> Steven
> ___
> 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] Consistency in naming [was Re: ...ALL CAPS] (off-list)

Python’s decline is in not growing. 

Sent from my iPhone

> On Feb 3, 2019, at 11:20 AM, Ned Batchelder  wrote:
> 
> James, you say below, "This kind of readability issue, datetime.now, is an 
> example of what’s contributing to Python’s decline."
> 
> Do you have any evidence of Python's decline?  Lots of metrics (albeit 
> simplistic ones) point to Python growing in popularity:
> 
> https://www.techrepublic.com/article/fastest-growing-programming-language-pythons-popularity-is-still-climbing/
> https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends
> https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
> Are there indicators we are missing?
> 
> --Ned.
> 
>> On 2/2/19 11:56 PM, James Lu wrote:
>> Sent from my iPhone
>> 
>>>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano  wrote:
>>>> 
>>>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote:
>>>>> 
>>>>> - the status quo means "no change", so there is no hassle there;
>>>> Not quite true. There is a constant hassle of "do I need to write 
>>>> datetime.datetime.now() or datetime.now()?"
>>> My point was that there is no hassle from *making a change* if you don't 
>>> actually make a change. (There may, or may not, be other, unrelated 
>>> hassles.)
>>> 
>>> Besides, I'm not seeing that this is any worse than any other import. Do 
>>> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you 
>>> imported, the names don't make much difference.
>>> 
>>> I accept that datetime.datetime reads a bit funny and is a bit annoying. 
>>> If we had the keys to the time machine and could go back a decade to 
>>> version 3.0, or even further back to 1.5 or whenever the datetime module 
>>> was first created, it would be nice to change it so that the class was 
>>> DateTime. But changing it *now* is not free, it has real, serious costs 
>>> which are probably greater than the benefit gained.
>> Why can’t we put “now” as a property of the module itself, reccomend that, 
>> and formally deprecate but never actually remove datetime.datetime.now?
>>>> I solved this at work by changing all imports to follow the "from 
>>>> datetime import datetime" pattern and hard banning the other 
>>>> statically in CI. But before that people suffered for years.
>>> Oh how they must have suffered *wink*
>>> 
>>> I'm surprised that you don't do this:
>>> 
>>> from datetime import datetime as DateTime
>>> 
>>> 
>>>> I have a colleague who likes to point that the future is longer than 
>>>> the past. It's important to keep that perspective.
>>> Actually, no, on average, the projected lifespan of technologies, 
>>> companies and cultural memes is about the same as their current age. It 
>>> might last less, or it might last more, but the statistical expectation 
>>> is about the same as the current age. So on average, "the future" is 
>>> about the same as "the past".
>>> 
>>> Python has been around not quite 30 years now, so we can expect that it 
>>> will probably last another 30 years. But chances are not good that it 
>>> will be around in 300 years.
>> A big reason why projects last as long as you say they last is that the 
>> maintainers get un-ambitious, they get used to relaxing in the language they 
>> know so well, they are no longer keen on change.
>> 
>> This kind of readability issue, datetime.now, is an example of what’s 
>> contributing to Python’s decline.
>> 
>> Bottom line: if someone submits a PR for this, will anyone merge it?
>>> -- 
>>> 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] What factors led Guido to quit?

Are you a moderator or committed?

I disagree with you. This, like the communication thread, is about improving 
the ability of the Python community to work together. If you don’t think others 
can have a respectful discussion about that, that’s the community’s fault, not 
mine.

Again, the goal of this thread is for constructive discussion.

Sent from my iPhone

> On Feb 3, 2019, at 9:44 AM, Antoine Pitrou  wrote:
> 
> 
> James, please don't post such topics on python-ideas.  This is
> completely off-topic and has strong flamebait potential.  You may write
> on your own blog or Facebook account if you feel so strongly about it.
> 
> Regards
> 
> Antoine.
> 
> 
> On Sat, 2 Feb 2019 11:04:40 -0500
> James Lu  wrote:
>> I want y’all to think about this very carefully. What factors led Guido to 
>> quit? And I don’t want you to just reply with the first thing that comes off 
>> your head. The purpose of this question/discussion is to identify problems 
>> with the Python community so we can fix them.
>> 
>> That is the only real chance of having a successful Python language that 
>> doesn’t get left behind by other languages, or of getting Guido to come back.
>> ___
>> 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] Vectorization [was Re: Add list.join() please]

There is no need for any of you to argue over this small point. Tolerate each 
other’s language.

Sent from my iPhone

> On Feb 2, 2019, at 3:58 AM, Steven D'Aprano  wrote:
> 
>> On Sat, Feb 02, 2019 at 05:10:14AM +, MRAB wrote:
>>> On 2019-02-02 04:32, Steven D'Aprano wrote:
>>> [snip]
>>> 
>>> Of course it makes sense. Even numpy supports inhomogeneous data:
>>> 
>> [snip]
>> 
>> "inhomogeneous"? Who came up with that?
> 
> I don't know, but it has been used since at least the early 1920s
> 
> https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous
> 
> and the Oxford dictionary describes "inhomogenity" as being used from 
> the late 19th century. So my guess is, probably people who were more 
> familiar with Latin and Greek than we are.
> 
> There are many words that are derived from both Latin and Greek. There's 
> no rule that says that because a word was derived from Greek, we must 
> use Greek grammatical forms for it. We are speaking English, not Greek, 
> and in English, we can negate words using the "in" prefix.
> 
> 
> 
> -- 
> Steven
> ___
> 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] Consistency in naming [was Re: ...ALL CAPS]



Sent from my iPhone

> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano  wrote:
> 
>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote:
>> 
>>> - the status quo means "no change", so there is no hassle there;
>> 
>> Not quite true. There is a constant hassle of "do I need to write 
>> datetime.datetime.now() or datetime.now()?"
> 
> My point was that there is no hassle from *making a change* if you don't 
> actually make a change. (There may, or may not, be other, unrelated 
> hassles.)
> 
> Besides, I'm not seeing that this is any worse than any other import. Do 
> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you 
> imported, the names don't make much difference.
> 
> I accept that datetime.datetime reads a bit funny and is a bit annoying. 
> If we had the keys to the time machine and could go back a decade to 
> version 3.0, or even further back to 1.5 or whenever the datetime module 
> was first created, it would be nice to change it so that the class was 
> DateTime. But changing it *now* is not free, it has real, serious costs 
> which are probably greater than the benefit gained.
Why can’t we put “now” as a property of the module itself, reccomend that, and 
formally deprecate but never actually remove datetime.datetime.now?
> 
>> I solved this at work by changing all imports to follow the "from 
>> datetime import datetime" pattern and hard banning the other 
>> statically in CI. But before that people suffered for years.
> 
> Oh how they must have suffered *wink*
> 
> I'm surprised that you don't do this:
> 
> from datetime import datetime as DateTime
> 
> 
>> I have a colleague who likes to point that the future is longer than 
>> the past. It's important to keep that perspective.
> 
> Actually, no, on average, the projected lifespan of technologies, 
> companies and cultural memes is about the same as their current age. It 
> might last less, or it might last more, but the statistical expectation 
> is about the same as the current age. So on average, "the future" is 
> about the same as "the past".
> 
> Python has been around not quite 30 years now, so we can expect that it 
> will probably last another 30 years. But chances are not good that it 
> will be around in 300 years.

A big reason why projects last as long as you say they last is that the 
maintainers get un-ambitious, they get used to relaxing in the language they 
know so well, they are no longer keen on change.

This kind of readability issue, datetime.now, is an example of what’s 
contributing to Python’s decline.

Bottom line: if someone submits a PR for this, will anyone merge it?
> 
> -- 
> 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/

Re: [Python-ideas] Clearer communication

I think we need to step away from the egalitarian ideal and have some way of 
knowing that Python committees are python committers. It’s really difficult to 
know how well your proposal is doing without having this.
___
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] Clearer communication

This list IS hard for newcomers. I wish there was one place where I could read 
up on how to not feel like a noob. 
___
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] What factors led Guido to quit?

I want y’all to think about this very carefully. What factors led Guido to 
quit? And I don’t want you to just reply with the first thing that comes off 
your head. The purpose of this question/discussion is to identify problems with 
the Python community so we can fix them.

That is the only real chance of having a successful Python language that 
doesn’t get left behind by other languages, or of getting Guido to come back.
___
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] Clearer communication

It’s very demotivating to hear just negative feedback on this list.

Was starting this thread useful for y’all?
___
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] Clearer communication

> I want the discussion to focus not only on technical solutions like +1 or 
> Mailman 3, but also social ones and how to better express oneself.
___
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] Option of running shell/console commands inside the REPL

It’s difficult to learn anything with a body (such as a loop or a class or a 
function) with the built in REPL because you can’t edit lines you’ve already 
written.

Sent from my iPhone

> On Feb 1, 2019, at 1:44 PM, Steven D'Aprano  wrote:
> 
>> On Fri, Feb 01, 2019 at 09:07:14AM -0500, James Lu wrote:
>> 
>> I always use ptipython (ptpython shell over the ipython console) for my
>> REPLs. The built-in python repl is not *batteries included* in the sense
>> that it already has what you need to explore the language.
> 
> What part of the Python language do you think cannot be used in the 
> standard Python REPL?
> 
> 
> 
> -- 
> 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] How do ideas on this mailing list turn into features?

How do ideas on this mailing list turn into features? What is the typical 
roadmap? Can this process be documented somewhere?___
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] Clearer communication

A lot of the traffic on this email list is people saying “I don’t understand” 
or “that’s not what I meant” or trying to re-explain. A lot of “-1”s are really 
“I don’t see the usefulness of this”.


So I want an open discussion on: How can we communicate clearer?


___
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] Option of running shell/console commands inside the REPL

I always use ptipython (ptpython shell over the ipython console) for my
REPLs. The built-in python repl is not *batteries included* in the sense
that it already has what you need to explore the language.

I wonder, what do the python committers think about including a
stripped-down version of ipython and ptpython in the built-in python?

On Fri, Feb 1, 2019 at 6:15 AM Lele Gaifax  wrote:

> Further magic comes with https://pypi.org/project/xonsh/
>
> ciao, lele.
> --
> nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
> real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
> l...@metapensiero.it  | -- Fortunato Depero, 1929.
>
> ___
> 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] Backtick expression: similar to a shorter lambda syntax

2019-01-23 Thread James Lu

Backtick expressions (now) use the same scoping and same binding rules as
other functions. The only difference is that
class Class:
  stacticmethod = `...`
  staticmethod = lambda: ...
  def instancemethod = `...` # an instancemethod that's called with self
passed in
  def property = property(`...`) # an instancemethod that's called with
self passed in

> The only thing that I can think of is that you want `foo + ^bar` to be
another way of writing lambda bar: foo + bar with some under-specified behavior
for evaluating foo and different under-specified behavior for evaluating bar
.

That is what `lambda bar: foo + ^bar` means.

A caret in a backtick expression indicates that the name after the caret is
a parameter. All names with the same name must have a caret before them.
Mandatory parameters can be passed in as keyword arguments or as positional
ones.

As for the under-specification, I've been working on an example
implementation I'll send soon for backtick expressions.

I've also been doing the "look for use cases in stdlib" thing that
Johnathan and Steve mentioned.


On Wed, Jan 23, 2019 at 3:02 AM Bruce Leban  wrote:

> On Sun, Jan 20, 2019 at 6:43 PM James Lu  wrote:
>
>> Backtick expressions work exactly like lambdas, except that they are
>> bound to the instance they are created in every time that class is used to
>> create one. To illustrate, ...
>
>
> First, if there is a useful procedure I am strongly against using
> backticks because (1) it's been used in the past with an entirely different
> meaning and (2) it looks ugly and is not visually suggestive at all of what
> it does, especially not the subtle difference between other function
> definitions.
>
> Second, I don't understand exactly what this difference or why it would be
> useful. It would help for you to give examples comparing lambda and this
> variation.
>
> Third, you mention using ^ in "explicit" expressions to refer to
> parameters of the "created function" and I do not know what function you
> are referring to or what the exact semantics of this are. Again, a
> comparison of two expressions with and without that ^ would help. An
> expression is not a function and not all expressions are written inside
> functions. (And as to the specific proposed syntax, there already is the ^
> xor operator and the most expected meaning of ^value is ~value. just as
> the unary + and - operators corresponds to the binary operators.
>
> The only thing that I can think of is that you want `foo + ^bar` to be
> another way of writing lambda bar: foo + bar with some under-specified 
> behavior
> for evaluating foo and different under-specified behavior for evaluating
> bar.
>
> Finally, if there is some other useful semantics for references inside a
> function definition, then I would think the best way to do that is to
> implement that, not add a new function difference. For example,
>
> lambda foo: foo + $bar
>
> def sample(foo):
>
> return foo + $foo
>
>
> where I'm arbitrarily using $ to represent the new semantics whatever they
> are (no point in bikeshedding syntax when semantics are yet to be defined).
>
> --- Bruce
>
___
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] Backtick expression: similar to a shorter lambda syntax

I’m a little busy recently, so I’ll reply to as much as I can now and reply to 
the rest later.

Scratch the stuff I said about scope. Backtick expressions should inherit the 
scope normally like any other nested function.

> That's different behaviour from regular functions, where names are only 
> resolved when the function is called.

What benefits are there to the late name lookup of normal functions? I’m 
looking to have backtick expressions raise early, not late. 

We can relax the names to be optional if a ternary expression is used within 
the backtick expression.

I realized that the behavior of Backtick Expressions can be silently affected 
by global variables. Example:

x = 1 
def increment_each(l):
 return map(`x+1`, l)

## Explicit expression, implicit usage
Explicit backtick expressions are ones that, for all parameters that the 
created function produces, it uses a caret before the name of the parameter. 
The other names must exist when the backtick expression is evaluated. Example:

parameter = 0
is_integer = `int(^parameter) == ^parameter` # arity: 1 despite the global 
definition

self = 'James'
str = `^self.__class__.__str__(^self)` # arity: 1 despite the global definition
str(type(lambda: 1)) # use our custom str function on the function type; 
output: 

## Implicitly Created Backtick Expression
Implicit baktick expressions, ones that mention undefined parameters without 
using the caret mark are generally discouraged. However they create 
UncastBacktickExpression, which must be cast using the .to_safe(*names) method 
to be used, which takes in a list of parameter names and outputs a normal 
backtick expression.

Even if the variable is defined on a global level, it can be explicitly 
overridden in to_safe.

Example 1
`x+1`.to_safe('x')(1)  # output: 2

Example 2
x = 0
`x+1`.to_safe('x')(1)  # output: 2

If a backtick expression has no unspecified names and has no carets, it is an 
implicit backtick expression.

This allows developers to safely omit the ^ when the code that is using the 
resulting backtick expression is aware of the parameters to be used, given that 
it's obvious to the developer which names are parameters.

> On Jan 21, 2019, at 1:56 AM, Steven D'Aprano  wrote:
> 
> That's different behaviour from regular functions, where names are only 
> resolved when the function is called.
___
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] Backtick expression: similar to a shorter lambda syntax

Later today I will send a working implementation of backtick expressions as a 
function call.
___
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] Backtick expression: similar to a shorter lambda syntax

> On Jan 21, 2019, at 1:56 AM, Steven D'Aprano  wrote:
> 
> It disturbs me that you believe you get to tell everyone what syntax 
> highlighting they should use for this feature. That's pretty 
> dictatorial, and not in a good BDFL way.

I don’t want to tell anyone how to make their syntax highlighter- just to point 
out that there are good ways to make the code within backtick expressions 
visually distinct from the surrounding code. I told the list because it’s 
helpful for the readability discussion.
___
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] Backtick expression: similar to a shorter lambda syntax

> On Jan 21, 2019, at 1:56 AM, Steven D'Aprano  wrote:
> 
> It disturbs me that you believe you get to tell everyone what syntax 
> highlighting they should use for this feature. That's pretty 
> dictatorial, and not in a good BDFL way.

I don’t want to tell anyone how to make their syntax highlighter- just to point 
out that there are good ways to make the code within backtick expressions 
visually distinct from the surrounding code. I told the list because it’s 
helpful for the readability discussion.
___
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] Discussion: Duck typing with “concepts”

So here’s an interesting idea, not a proposal yet. 

In C++20, a Concept is a list of Boolean expressions with a name that can be 
used in place of a type in a templated (ie type-generic) function.

from typing import Concept
Iterator = Concept(lambda o: hasattr(o, "__iter__", lambda o: iter(o) != 
NotImplemented)
# Concept inheritance
Iterable = Concept(lambda o: hasattr(o, "__next__"), Iterator)

You could use concepts to define many practical “real-world” duck types.

A concept is like an opt-in duck typing type assertion. Since it’s a part of 
type annotation syntax, assertions can be generated automatically by looking at 
assertions.

You would use a Concept like any other type in type annotations.

Marko, how do you think Concepts might integrate with icontract? (I’m imagining 
overriding an import hook to automatically add contracts to functions with 
concepts.) How frequently do you use duck typing at Parquery? How might 
Concepts affect how often you used duck typing?
___
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] Support parsing stream with `re`

2018-10-12 Thread James Lu

The file system is really just a b-tree. If you’re concerned about using memory, you can implement a O(log n) map using the file system, where the entires are the different critical sections.Every node is a folder and every file is a leaf. Many package managers implement maps like this. I’d like to propose a second alternative. You can use a script that’s responsible for creating the file of commands. The file is actually a FIFO pipe. The script streams data to the file, but to save resources it stops when the file/buffer reaches a certain size. The command-running code works in a different process. Python has good capability for handling streams. On Oct 10, 2018, at 1:27 AM, Stephen J. Turnbull wrote:Chris Angelico writes:On Wed, Oct 10, 2018 at 5:09 AM Stephen J. Turnbull wrote:Chris Angelico writes:Both processes are using the virtual memory. Either or both could beusing physical memory. Assuming they haven't written to the pages(which is the case with executables - the system mmaps the binary intoyour memory space as read-only), and assuming that those pages arebacked by physical memory, which process is using that memory?One doesn't know. Clever side-channel attacks aside, I don't care,and I don't see how it could matter.It matters a lot when you're trying to figure out what your systemis doing.Sure, but knowing how your system works is far more important. Eg,create a 1TB file on a POSIX system, delete it while a process stillhas it opened, and it doesn't matter how you process the output of duor ls, you still have 1TB of used file space not accounted for. Thesame applies to swapfiles. But "df" knows and will tell you.In fact, "ps" will tell you how much shared memory a process is using.I just don't see a problem here, on the "I'm not getting the data Ineed" side. You do have access to the data you need.Tell me, which process is responsible for libc being in memory?Other than, like, all of them?Yes. Why would you want a different answer?Because that would mean that I have way more *physical* memory in usethan I actually have chips on the motherboard for.No, that's like saying that because you have multiple links to a fileon disk you're using more physical disk than you have.Actually, that's exactly the same problem, with exactly the sameconsequences. How do you figure out why your disk is full? How do youenforce disk quotas? How can you get any sort of reasonable metricsabout anything when the sum of everything vastly exceeds the actualusage?You add up the right things, of course, and avoid paradoxes.The disk quota enforcement problem is indeed hard. This sounds to melike a special problem studied in cost accounting, a problem which wassolved (a computation that satisfies certain axioms was shown to existand be unique) in a sense by Aumann and Shapley in the 1970s. The A-Sprices have been used by telephone carriers to allocate costs of fixedassets with capacity constraints to individual calls, though I don'tknow if the method is still in use. I'm not sure if the disk quotaproblem fits the A-S theorem (which imposes certain monotonicityconditions), but the general paradigm does.However, the quota problem (and in general, the problem of allocationof overhead) is "hard" even if you have complete information about thesystem, because it's a values problem: what events are bad? whatevents are worse? what events are unacceptable (result in bankruptcyand abandonment of the system)? Getting very complete, accurateinformation about the physical consequences of individual events inthe system (linking to a file on disk, allocating a large quantity ofviritual memory) is not difficult, in the sense that you throw moneyand engineers at it, and you get "df". Getting very complete,accurate information about the values you're trying to satisfy ispossible only for an omniscient god, even if, as in business, they canbe measured in currency units.Steve___Python-ideas mailing listPython-ideas@python.orghttps://mail.python.org/mailman/listinfo/python-ideasCode 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] Renaming icontract to pcontract

2018-10-01 Thread James Lu

I think the confusion would be minimal and not worth the hassle of renaming to 
pcontract. People would just say “Python icontract” when it’s ambiguous.

Sent from my iPhone

> On Oct 1, 2018, at 3:28 AM, Marko Ristin-Kaufmann  
> wrote:
> 
> Hi Cameron,
> A nerdy way to make it sound like a sentence: "I contract that ...".
> 
> Pcontract would stand for python contract. Pycontract is already taken.
> 
> Cheers,
> Marko
> 
>> Le lun. 1 oct. 2018 à 09:15, Cameron Simpson  a écrit :
>> On 01Oct2018 07:25, Marko Ristin-Kaufmann  wrote:
>> >I'd like to rename icontract into pcontract to avoid name conflict with
>> >java's icontract library.
>> >
>> >Do you have any better suggestion?
>> 
>> No, sounds ok to me. What was the "i" for in the old name?
>> 
>> Cheers,
>> Cameron Simpson 
>> ___
>> 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] Transpiling contracts

2018-10-01 Thread James Lu

Hi Marko,

I’m going to refer to the transpiler syntax as “block syntax.”

1. How does Eiffel do formal contracts?
2. What’s the use case for preferring block syntax over lambda syntax? Is the 
block syntax only better when multiple statements are needed to test a single 
contract condition? 
2. If the last proposition is true, how often do we need multiple statements to 
test or specify a single contract condition?
3. When we do need multiple statements to formally verify/specify, is it 
usually a better idea to factor out major functionality of the contract testing 
to an external function? (So other contracts can use the same external function 
and the intent of the contract is clear trough the function name)
4. If this is true, is it a good idea to include a contracts/ folder at the 
same folder level or a .contracts.py file to list “helper” or verification 
functions for a contract?

I think we should answer questions two and three by looking at real code.
—

If MockP is supported, it could be used for all the contract decorators:
@snapshot(var=P.self.name)
@post(var=R.attr == P.old.var)

The decorator can also check the type of the returned object, and if it’s MockP 
it will use MockP protocol and otherwise it will check the object is callable 
and treat it as a lambda.

Your approach has better type hinting, but I’m not sure if type hinting would 
be that useful if you’re adding a contract whilst writing the function. 

James Lu

> On Oct 1, 2018, at 1:01 AM, Marko Ristin-Kaufmann  
> wrote:
> 
> Hi James,
> 
>> Regarding the “transpile into Python” syntax with with statements: Can I see 
>> an example of this syntax when used in pathlib? I’m a bit worried this 
>> syntax is too long and “in the way”, unlike decorators which are before the 
>> function body. Or do you mean that both MockP and your syntax should be 
>> supported?
>> 
>> Would
>> 
>> with requiring: assert arg1 < arg2, “message”
>> 
>> Be the code you type or the code that’s actually run?
> 
> 
> That's the code you would type. Let me make a full example (I'm omitting 
> "with contracts" since we actually don't need it).
> 
> You would read/write this:
> def some_func(arg1: List[int])->int:
>   with requiring:
> assert len(arg1) > 3, "some description"
> 
>   with oldie as O, resultie as result, ensuring:
> if SLOW:
>   O.var1 = sum(arg1)
>   assert result > sum(arg1) > O.var1
> 
> assert len(result) > 5
> 
> This would run:
> @requires(lambda P: len(P.arg1) > 3, "some description")
> @snapshot(lambda P, var1: sum(P.arg1), enabled=SLOW)
> @ensures(lambda O, P, result: result > sum(arg1) > O.var1, enabled=SLOW)
> @ensures(lambda result: len(result) > 5)
> 
> I omitted in the example how to specify a custom exception to avoid confusion.
> 
> If we decide that transpiler is the way to go, I'd say it's easier to just 
> stick with lambdas and allow no mock-based approach in transpilation.
> 
> Cheers,
> Marko
>  
> 
> 
___
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] "old" values in postconditions

Hi Marko,

Regarding switching over to GitHub issues:
* I copy-pasted the MockP original code to GitHub issues.
* There's a clunky way to view the discussion at
https://mail.python.org/pipermail/python-ideas/2018-September/subject.html#start
.
* The less clunky way to view the discussion is to subscribe to the mailing
list and use Gmail to move all the messages from python-ideas to python
ideas list and all the messages from the discussions we have to a
"contracts" label and view the discussion with your email client.
* A week earlier I didn't think I'd be saying this, but I like email for
discussion better. It works on mobile and I can send messages offline, and
I send 90% of my messages on my phone and when I'm offline. Unless you know
an alternative (WhatsApp, maybe?) that fits my use cases off the top of
your head, I think we should stick to email.
* My proposal: We split the discussion into a new email thread, we keep the
latest agreed upon proposal on GitHub issues.

On Sun, Sep 30, 2018 at 4:32 PM Marko Ristin-Kaufmann <
marko.ris...@gmail.com> wrote:

> Hi James,
> (I'm just about to go to sleep, so I'll answer the other messages
> tomorrow.)
>
> Should we keep some kind of document to keep track of all the different
>> proposals? I’m thinking an editable document like HackMD where we can label
>> all the different ideas to keep them straight in our head.
>>
>
> I thought github issues would be a suitable place for that:
> https://github.com/Parquery/icontract/issues
>
> It reads a bit easier as a discussion rather than a single document -- if
> anybody else needs to follow. What do you think?
>
> On Sun, 30 Sep 2018 at 22:07, James Lu  wrote:
>
>> Hi Marko,
>>
>> Going back to your proposal on repeating lambda P as a convention.
>>
>> I do find
>>
>> @snapshot(some_identifier=P -> P.self(P.arg1),
>> some_identifier2=P -> P.arg1 + P.arg2)
>>
>> acceptable.
>>
>> Should we keep some kind of document to keep track of all the different
>> proposals? I’m thinking an editable document like HackMD where we can label
>> all the different ideas to keep them straight in our head.
>>
>> James Lu
>
>
___
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] Upgrade to Mailman 3

It has a nice GUI for people who spectate a discussion to read emails
without having to subscribe to the list.

http://docs.mailman3.org/en/latest/migration.html
___
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] "old" values in postconditions

Hi Marko,

I just found the time to reply to these.
> I reread the proposal with MockP. I still don't get the details, but if I 
> think I understand the basic idea. You put a placeholder and whenever one of 
> its methods is called (including dunders), you record it and finally assemble 
> an AST and compile a lambda function to be executed at actual call later.
Precisely.

> But that would still fail if you want to have:
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))
> , right? Or there is a way to record that?

This would still fail. You would record it like this:
@snapshot(var1=thunk(some_func)(MockP.arg1, MockP.arg2))

thunk stores the function for later and produces another MockP object that 
listens for __call__.

By the way, MockP is the class while P is a virgin instance of MockP. MockP 
instances are immutable, so any operation on a MockP instance creates a new 
object or MockP instance. 

I’m also beginning to lean towards
@snapshot(var1=...)
@snapshot(var2=...)

I suspect this would deal better with VCS.

This syntax does have a a nice visual alignment. I’m not entirely sure what 
kind of indentation PEP 8 recommends and editors give, so the point may be moot 
if the natural indentation also gives the same visual alignment.

Though both should be supported so the best syntax may win.

James Lu

> On Sep 29, 2018, at 3:22 PM, Marko Ristin-Kaufmann  
> wrote:
> 
> I reread the proposal with MockP. I still don't get the details, but if I 
> think I understand the basic idea. You put a placeholder and whenever one of 
> its methods is called (including dunders), you record it and finally assemble 
> an AST and compile a lambda function to be executed at actual call later.
> 
> But that would still fail if you want to have:
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))
> , right? Or there is a way to record that?
___
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] "old" values in postconditions

Hi Marko,

Regarding the “transpile into Python” syntax with with statements: Can I see an 
example of this syntax when used in pathlib? I’m a bit worried this syntax is 
too long and “in the way”, unlike decorators which are before the function 
body. Or do you mean that both MockP and your syntax should be supported?

Would

with requiring: assert arg1 < arg2, “message”

Be the code you type or the code that’s actually run?

James Lu

> On Sep 29, 2018, at 2:56 PM, Marko Ristin-Kaufmann  
> wrote:
> 
> Just
___
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] "old" values in postconditions

Hi Marko,

> If the documentation is clear, I'd expect the user to be able to distinguish 
> the two. The first approach is shorter, and uses magic, but fails in some 
> rare situations. The other method is more verbose, but always works.
I like this idea. 

James Lu
> On Sep 29, 2018, at 1:36 AM, Marko Ristin-Kaufmann  
> wrote:
> 
> If the documentation is clear, I'd expect the user to be able to distinguish 
> the two. The first approach is shorter, and uses magic, but fails in some 
> rare situations. The other method is more verbose, but always works.
___
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] "old" values in postconditions

Hi Marko,

Going back to your proposal on repeating lambda P as a convention.

I do find 

@snapshot(some_identifier=P -> P.self(P.arg1),
some_identifier2=P -> P.arg1 + P.arg2)

acceptable. 

Should we keep some kind of document to keep track of all the different 
proposals? I’m thinking an editable document like HackMD where we can label all 
the different ideas to keep them straight in our head.

James Lu
___
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] Why is design-by-contracts not widely adopted?

Many editors highlight decorators in a different color that makes it easier to 
ignore and can also fold decorators. 

Contracts can also sometimes actively improve the flow of code. 

I personally find a formal contract easier to read than informal documentation.

It also reduces the times where you need to spend time figuring out if 
documentation actually accurate and up to date
___
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] Exception handling in contracts

Let’s get some ideas for how icontract can say “it should throw an exception if 
this happens.”
___
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] "old" values in postconditions

> The problem with readability might be easier to solve than I thought, and 
> your pointer to coconut gave me the idea. What if we make a utility that 
> takes the python source code, examines the decorators pre/post/inv (or 
> whatever we call them) and transforms them back and forth from/to valid 
> python code?
> 
> Pretty much any IDE has after load / before save handlers. When you load a 
> python file, you'd transform it from less readable python code, write using a 
> concise form and when you save it, it's transformed back to valid python.
Hmm yes. Look at my previous email- the proposed syntax there does not require 
changing or transforming Python code. It’s missing many magic methods, but it 
would work something like this:

@snapshot(some_identifier=P.self.another_property + 10)

would internally turn into something like this: lambda P: 
P.self.another_property + 10

Maybe it’s possible to modify PyCharm parsing by altering its Python grammar 
file?

Sent from my iPhone

> On Sep 28, 2018, at 10:27 AM, Marko Ristin-Kaufmann  
> wrote:
> 
> Hi James,
> 
> The problem with readability might be easier to solve than I thought, and 
> your pointer to coconut gave me the idea. What if we make a utility that 
> takes the python source code, examines the decorators pre/post/inv (or 
> whatever we call them) and transforms them back and forth from/to valid 
> python code?
> 
> Pretty much any IDE has after load / before save handlers. When you load a 
> python file, you'd transform it from less readable python code, write using a 
> concise form and when you save it, it's transformed back to valid python.
> 
> Then we need to pick the python form that is easiest to implement (and still 
> readable enough for, say, code reviews on github), but writing and reading 
> the contracts in the code would be much more pleasant.
> 
> As long as the "readable" form has also valid python syntax, the tool can be 
> implemented with ast module.
> 
> For example:
> @snapshot(some_identifier=self.another_property + 10)
> @post(self.some_property => old.some_identifier > 100)
> 
> would transform into 
> @snapshot(lambda P, some_identifier: P.self.another_property + 10)
> @post(lambda O, P: not self.some_property and O.some_identifier > 100)
> 
> Cheers,
> Marko
> 
>> On Fri, 28 Sep 2018 at 03:49, Marko Ristin-Kaufmann  
>> wrote:
>> Hi James,
>> 
>> I still have a feeling that most developers would like to store the state in 
>> many different custom ways. I see also thunk and snapshot with wrapper 
>> objects to be much more complicated to implement and maintain; I'm thinking 
>> mostly about all the edge cases which we would not be able to cover (and how 
>> complex that would be to cover them). Then the linters need also to work 
>> around such wrappers... It might also scare users off since it looks like 
>> too much magic. Another concern I also have is that it's probably very hard 
>> to integrate these wrappers with mypy later -- but I don't really have a 
>> clue about that, only my gut feeling?
>> 
>> What about we accepted to repeat "lambda P, " prefix, and have something 
>> like this:
>> 
>> @snapshot(
>>   lambda P, some_name: len(P.some_property),
>>   lambda P, another_name: hash(P.another_property)
>> )
>> 
>> It's not too verbose for me and you can still explain in three-four 
>> sentences what happens below the hub in the library's docs.  A 
>> pycharm/pydev/vim/emacs plugins could hide the verbose parts. 
>> 
>> I performed a small experiment to test how this solution plays with pylint 
>> and it seems OK that arguments are not used in lambdas.
>> 
>> Cheers,
>> Marko
>> 
>> 
>>> On Thu, 27 Sep 2018 at 12:27, James Lu  wrote:
>>> Why couldn’t we record the operations  done to a special object and replay 
>>> them?
>>> 
>>>>>> Actually, I think there is probably no way around a decorator that 
>>>>>> captures/snapshots the data before the function call with a lambda (or 
>>>>>> even a separate function). "Old" construct, if we are to parse it 
>>>>>> somehow from the condition function, would limit us only to shallow 
>>>>>> copies (and be complex to implement as soon as we are capturing 
>>>>>> out-of-argument values such as globals etc.). Moreove, what if we don't 
>>>>>> need shallow copies? I could imagine a dozen of cases where shallow copy 
>>>>>> is not what the programmer wants: for example, s/he might need to make 
>>>>>> deep copies, ha

Re: [Python-ideas] "old" values in postconditions

I am fine with your proposed syntax. It’s certainly lucid. Perhaps it would be 
a good idea to get people accustomed to “non-magic” syntax.

> I still have a feeling that most developers would like to store the state in 
> many different custom ways. 
Please explain. (Expressions like thunk(all)(a == b for a, b in P.arg.meth()) 
would be valid.)
> I'm thinking mostly about all the edge cases which we would not be able to 
> cover (and how complex that would be to cover them).

Except for a > b > c being one flat expression with 5 members, it seems fairly 
easy to recreate an AST, which can then be compiled down to a code object. The 
code object can be fun with a custom “locals()”

Below is my concept code for such a P object.

from ast import *
# not done: enforce Singleton property on EmptySymbolType
class EmptySymbolType(object): ...
EmptySymbol = EmptySymbolType() # empty symbols are placeholders
class MockP(object):
# "^" is xor
@icontract.pre(lambda symbol, astnode: (symbol is None) ^ (astnode is None))
def __init__(self, symbol=None, value=EmptySymbol, astnode=None, 
initsymtable=(,)):
self.symtable = dict(initsymtable)
if symbol:
self.expr = Expr(value=Name(id=symbol, ctx=Load()))
self.symtable = {symbol: value}
else:
self.expr = astnode
self.frozen = False
def __add__(self, other):
wrapped = MockP.wrap_value(other)
return MockP(astnode=Expr(value=BinOp(self.expr, Add(), wrapped.expr), 
initsymtable={**self.symtable, **wrapped.symtable})
def compile(self): ...
def freeze(self):
# frozen objects wouldn’t have an overrided getattr, allowing for 
icontract to manipulate the MockP object using its public interface
self.frozen = True
@classmethod
def wrap_value(cls, obj):
   # create a MockP object from a value. Generate a random identifier and 
set that as the key in symtable, the AST node is the name of that identifier, 
retrieving its value through simple expression evaluation.
   ...

thunk = MockP.wrap_value
P = MockP('P')
# elsewhere: ensure P is only accessed via valid “dot attribute access” inside 
@snapshot so contracts fail early, or don’t and allow Magic like __dict__ to 
occur on P.

> On Sep 27, 2018, at 9:49 PM, Marko Ristin-Kaufmann  
> wrote:
> 
> Hi James,
> 
> I still have a feeling that most developers would like to store the state in 
> many different custom ways. I see also thunk and snapshot with wrapper 
> objects to be much more complicated to implement and maintain; I'm thinking 
> mostly about all the edge cases which we would not be able to cover (and how 
> complex that would be to cover them). Then the linters need also to work 
> around such wrappers... It might also scare users off since it looks like too 
> much magic. Another concern I also have is that it's probably very hard to 
> integrate these wrappers with mypy later -- but I don't really have a clue 
> about that, only my gut feeling?
> 
> What about we accepted to repeat "lambda P, " prefix, and have something like 
> this:
> 
> @snapshot(
>   lambda P, some_name: len(P.some_property),
>   lambda P, another_name: hash(P.another_property)
> )
> 
> It's not too verbose for me and you can still explain in three-four sentences 
> what happens below the hub in the library's docs.  A pycharm/pydev/vim/emacs 
> plugins could hide the verbose parts. 
> 
> I performed a small experiment to test how this solution plays with pylint 
> and it seems OK that arguments are not used in lambdas.
> 
> Cheers,
> Marko
> 
> 
>> On Thu, 27 Sep 2018 at 12:27, James Lu  wrote:
>> Why couldn’t we record the operations  done to a special object and replay 
>> them?
>> 
>>>>> Actually, I think there is probably no way around a decorator that 
>>>>> captures/snapshots the data before the function call with a lambda (or 
>>>>> even a separate function). "Old" construct, if we are to parse it somehow 
>>>>> from the condition function, would limit us only to shallow copies (and 
>>>>> be complex to implement as soon as we are capturing out-of-argument 
>>>>> values such as globals etc.). Moreove, what if we don't need shallow 
>>>>> copies? I could imagine a dozen of cases where shallow copy is not what 
>>>>> the programmer wants: for example, s/he might need to make deep copies, 
>>>>> hash or otherwise transform the input data to hold only part of it 
>>>>> instead of copying (e.g., so as to allow equality check without a double 
>>>>> copy of the data, or capture only the value of certain property 
>>>>> transformed in some way).
>> 
&

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-27 Thread James Lu

> As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are exceptions, for example all immutable types or some promotions
between numbers.

Yep.

>>> a = (5, 2)
>>> a += (3, )
>>> a
(5, 2, 3)

> In your examples some cases imply that you are working on names, others
that you are working on objects. And as for me this ambiguity is not
solvable.

example please? Show an ambiguous case. To me, it's always working on
names.

On Thu, Sep 27, 2018 at 5:32 PM Kirill Balunov 
wrote:

> As I see it, you are mixing very different things. Augmented operators in
> Python work on objects, generally trying to mutate them in-place. So
> usually after these operations you have the same object (with the same
> type, with the same name and etc.) as before these operations. Of course
> there are exceptions, for example all immutable types or some promotions
> between numbers.
>
> In your examples some cases imply that you are working on names, others
> that you are working on objects. And as for me this ambiguity is not
> solvable.
>
> With kind regards,
> -gdg
>
> ср, 26 сент. 2018 г. в 14:14, Jasper Rebane :
>
>> Hi,
>>
>> When using Python, I find myself often using assignment operators, like
>> 'a += 1' instead of 'a = a + 1', which saves me a lot of time and hassle
>>
>> Unfortunately, this doesn't apply to methods, thus we have to write code
>> like this:
>> text = "foo"
>> text = text.replace("foo","bar")
>> # "bar"
>>
>> I propose that we should add '.=' as a method return value assignment
>> operator so we could write the code like this instead:
>> text = "foo"
>> text .= replace("foo","bar")
>> # "bar"
>> This looks cleaner, saves time and makes debugging easier
>>
>> Here are a few more examples:
>> text = " foo "
>> text .= strip()
>> # "foo"
>>
>> text = "foo bar"
>> text .= split(" ")
>> # ['foo', 'bar']
>>
>> text = b'foo'
>> text .= decode("UTF-8")
>> # "foo"
>>
>> foo =  {1,2,3}
>> bar = {2,3,4}
>> foo .= difference(bar)
>> # {1}
>>
>>
>> Rebane
>> ___
>> 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/

[Python-ideas] Add .= as a method return value assignment operator

2018-09-27 Thread James Lu

> items = ["foo", "bar", "quux"]
> items[randrange(3)] .= upper()
>
> Is this equivalent to:
>
> items[randrange(3)] = items[randrange(3)].upper()
>
> ? That would call randrange twice, potentially grabbing one element
> and dropping it into another slot. If it isn't equivalent to that, how
> is it defined?


It would not call randrange twice. Consider existing Python behavior:

def foo():
print("foo")
return 0
l = [7]
l[foo()] += 1
# output: "foo", but only once
print(l)  # l == [8]

Sent from my iPhone

> On Sep 27, 2018, at 4:13 PM, Chris Angelico  wrote:
>
> That would call randrange twice, potentially grabbing one element
> and dropping it into another slot. If it isn't equivalent to that, how
> is it defined?
___
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] "old" values in postconditions

2018-09-27 Thread James Lu

Why couldn’t we record the operations  done to a special object and replay them?

>>> Actually, I think there is probably no way around a decorator that 
>>> captures/snapshots the data before the function call with a lambda (or even 
>>> a separate function). "Old" construct, if we are to parse it somehow from 
>>> the condition function, would limit us only to shallow copies (and be 
>>> complex to implement as soon as we are capturing out-of-argument values 
>>> such as globals etc.). Moreove, what if we don't need shallow copies? I 
>>> could imagine a dozen of cases where shallow copy is not what the 
>>> programmer wants: for example, s/he might need to make deep copies, hash or 
>>> otherwise transform the input data to hold only part of it instead of 
>>> copying (e.g., so as to allow equality check without a double copy of the 
>>> data, or capture only the value of certain property transformed in some 
>>> way).

from icontract import snapshot, P, thunk
@snapshot(some_identifier=P.self.some_method(P.some_argument.some_attr))

P is an object of our own type, let’s call the type MockP. MockP returns new 
MockP objects when any operation is done to it. MockP * MockP = MockP. 
MockP.attr = MockP. MockP objects remember all the operations done to them, and 
allow the owner of a MockP object to re-apply the same operations 

“thunk” converts a function or object or class to a MockP object, storing the 
function or object for when the operation is done. 

thunk(function)()

Of course, you could also thunk objects like so: thunk(3) * P.number. (Though 
it might be better to keep the 3 after P.number in this case so P.number’s 
__mult__ would be invoked before 3’s __mult__ is invokes.

In most cases, you’d save any operations that can be done on a copy of the data 
as generated by @snapshot in @postcondiion. thunk is for rare scenarios where 
1) it’s hard to capture the state, for example an object that manages network 
state (or database connectivity etc) and whose stage can only be read by an 
external classmethod  2) you want to avoid using copy.deepcopy.

I’m sure there’s some way to override isinstance through a meta class or dunder 
subclasshook.

I suppose this mocking method could be a shorthand for when you don’t need the 
full power of a lambda. It’s arguably more succinct and readable, though YMMV.

I look forward to reading your opinion on this and any ideas you might have.

> On Sep 26, 2018, at 3:56 PM, James Lu  wrote:
> 
> Hi Marko,
> 
>> Actually, following on #A4, you could also write those as multiple 
>> decorators:
>> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr)
>> @snpashot(lambda _, other_identifier: other_func(_.self))
> 
> Yes, though if we’re talking syntax using kwargs would probably be better.
> Using “P” instead of “_”: (I agree that _ smells of ignored arguments)
> 
> @snapshot(some_identifier=lambda P: ..., some_identifier2=lambda P: ...)
> 
> Kwargs has the advantage that you can extend multiple lines without repeating 
> @snapshot, though many lines of @capture would probably be more intuitive 
> since each decorator captures one variable.
> 
>> Why uppercase "P" and not lowercase (uppercase implies a constant for me)?
> 
> To me, the capital letters are more prominent and explicit- easier to see 
> when reading code. It also implies its a constant for you- you shouldn’t be 
> modifying it, because then you’d be interfering with the function itself.
> 
> Side node: maybe it would be good to have an @icontract.nomutate (probably 
> use a different name, maybe @icontract.readonly) that makes sure a method 
> doesn’t mutate its own __dict__ (and maybe the __dict__ of the members of its 
> __dict__). It wouldn’t be necessary to put the decorator on every read only 
> function, just the ones your worried might mutate.
> 
> Maybe a @icontract.nomutate(param=“paramname”) that ensures the __dict__ of 
> all members of the param name have the same equality or identity before and 
> after. The semantics would need to be worked out.
> 
>> On Sep 26, 2018, at 8:58 AM, Marko Ristin-Kaufmann  
>> wrote:
>> 
>> Hi James,
>> 
>> Actually, following on #A4, you could also write those as multiple 
>> decorators:
>> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr)
>> @snpashot(lambda _, other_identifier: other_func(_.self))
>> 
>> Am I correct?
>> 
>> "_" looks a bit hard to read for me (implying ignored arguments).
>> 
>> Why uppercase "P" and not lowercase (uppercase implies a constant for me)? 
>> Then "O" for "old" and "P" for parameter

Re: [Python-ideas] "old" values in postconditions

Hi Marko,

> Actually, following on #A4, you could also write those as multiple decorators:
> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr)
> @snpashot(lambda _, other_identifier: other_func(_.self))

Yes, though if we’re talking syntax using kwargs would probably be better.
Using “P” instead of “_”: (I agree that _ smells of ignored arguments)

@snapshot(some_identifier=lambda P: ..., some_identifier2=lambda P: ...)

Kwargs has the advantage that you can extend multiple lines without repeating 
@snapshot, though many lines of @capture would probably be more intuitive since 
each decorator captures one variable.

> Why uppercase "P" and not lowercase (uppercase implies a constant for me)?

To me, the capital letters are more prominent and explicit- easier to see when 
reading code. It also implies its a constant for you- you shouldn’t be 
modifying it, because then you’d be interfering with the function itself.

Side node: maybe it would be good to have an @icontract.nomutate (probably use 
a different name, maybe @icontract.readonly) that makes sure a method doesn’t 
mutate its own __dict__ (and maybe the __dict__ of the members of its 
__dict__). It wouldn’t be necessary to put the decorator on every read only 
function, just the ones your worried might mutate.

Maybe a @icontract.nomutate(param=“paramname”) that ensures the __dict__ of all 
members of the param name have the same equality or identity before and after. 
The semantics would need to be worked out.

> On Sep 26, 2018, at 8:58 AM, Marko Ristin-Kaufmann  
> wrote:
> 
> Hi James,
> 
> Actually, following on #A4, you could also write those as multiple decorators:
> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr)
> @snpashot(lambda _, other_identifier: other_func(_.self))
> 
> Am I correct?
> 
> "_" looks a bit hard to read for me (implying ignored arguments).
> 
> Why uppercase "P" and not lowercase (uppercase implies a constant for me)? 
> Then "O" for "old" and "P" for parameters in a condition:
> @post(lambda O, P: ...)
> ?
> 
> It also has the nice property that it follows both the temporal and the 
> alphabet order :)
> 
>> On Wed, 26 Sep 2018 at 14:30, James Lu  wrote:
>> I still prefer snapshot, though capture is a good name too. We could use 
>> generator syntax and inspect the argument names.
>> 
>> Instead of “a”, perhaps use “_”. Or maybe use “A.”, for arguments. Some 
>> people might prefer “P” for parameters, since parameters sometimes means the 
>> value received while the argument means the value passed.
>> 
>> (#A1)
>> 
>> from icontract import snapshot, __
>> @snapshot(some_func(_.some_argument.some_attr) for some_identifier, _ in __)
>> 
>> Or (#A2)
>> 
>> @snapshot(some_func(some_argument.some_attr) for some_identifier, _, 
>> some_argument in __)
>> 
>> —
>> Or (#A3)
>> 
>> @snapshot(lambda some_argument,_,some_identifier: 
>> some_func(some_argument.some_attr))
>> 
>> Or (#A4)
>> 
>> @snapshot(lambda _,some_identifier: some_func(_.some_argument.some_attr))
>> @snapshot(lambda _,some_identifier, other_identifier: 
>> some_func(_.some_argument.some_attr), other_func(_.self))
>> 
>> I like #A4 the most because it’s fairly DRY and avoids the extra punctuation 
>> of 
>> 
>> @capture(lambda a: {"some_identifier": some_func(a.some_argument.some_attr)})
>> 
>> On Sep 26, 2018, at 12:23 AM, Marko Ristin-Kaufmann  
>> wrote:
>> 
>>> Hi,
>>> 
>>> Franklin wrote:
>>>> The name "before" is a confusing name. It's not just something that
>>>> happens before. It's really a pre-`let`, adding names to the scope of
>>>> things after it, but with values taken before the function call. Based
>>>> on that description, other possible names are `prelet`, `letbefore`,
>>>> `predef`, `defpre`, `beforescope`. Better a name that is clearly
>>>> confusing than one that is obvious but misleading.
>>> 
>>> James wrote:
>>>> I suggest that instead of “@before” it’s “@snapshot” and instead of “old” 
>>>> it’s “snapshot”.
>>> 
>>> 
>>> I like "snapshot", it's a bit clearer than prefixing/postfixing verbs with 
>>> "pre" which might be misread (e.g., "prelet" has a meaning in Slavic 
>>> languages and could be subconsciously misread, "predef" implies to me a 
>>> pre-definition rather than prior-to-definition , "beforescope" is very 
>>> clear for me, but it might be confusi

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

> It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to unit testing is not "boolean expressions", it's a
> language that can usefully describe what it is we're testing.
> Contracts aren't just boolean expressions - they're a language (or a
> mini-language) that lets you define WHAT the contract entails.
Please read the earlier discussion from Marko. Contracts are like unit tests 
but acts as documentation that is right next to the function definition. It’s 
also much shorter in number of lines to define. You can write a simple unit 
smoke test to turn a contract into a unit test. Contracts serve unit testing 
and documentation at the same time.

Sent from my iPhone

> On Sep 26, 2018, at 3:18 AM, Chris Angelico  wrote:
> 
> It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to unit testing is not "boolean expressions", it's a
> language that can usefully describe what it is we're testing.
> Contracts aren't just boolean expressions - they're a language (or a
> mini-language) that lets you define WHAT the contract entails.
___
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] "while:" for the loop

repeat could be only considered a keyword when it’s used as a loop

Sent from my iPhone

> On Sep 26, 2018, at 8:46 AM, Brice Parent  wrote:
> 
>> Le 26/09/2018 à 14:33, James Lu a écrit :
>> what about “repeat:”?
>> 
>> Sent from my iPhone
> I'm not sure it was on purpose, but you replied to me only, and not the 
> entire list.
> I believe the adding of a new keyword to do something that is already 
> straightforward (`while True:`), and that doesn't add any new functionality, 
> won't probably ever be accepted.
___
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] "old" values in postconditions