Re: [Python-ideas] Is there any idea about dictionary destructing?

[Nikolas Vanderhoof]

And this should print:

'some data'
1
2
3

On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof <
nikolasrvanderh...@gmail.com> wrote:

> This would be a very handy feature, but Coconut (which is just python with
> some extra functional-style features) also has support for this kind of
> pattern-matching:
> http://coconut-lang.org
>
>
> ​Since Coconut will compile to Python (2 or 3) you can just write in
> Coconut and use the resulting code in your Python.
>
> Using your first example in coconut would be nearly identical, except I
> believe the entire dictionary must be specified (I am not sure about this).
>
> data = {
> 'direct': 'some data',
> 'nested': {
> 'lst_data': [1, 2, 3],
> 'int_data': 1
> }
> }
>
> {
> 'direct': direct,
> 'nested': {
> 'lst_data': [a, b, c],
> 'int_data': _
> }
> } = data
>
> print(direct)
> print(a)
> print(b)
> print(c)
>
>
> And this should print:
>
> On Sat, Apr 7, 2018 at 1:26 PM, thautwarm <yaoxiansa...@gmail.com> wrote:
>
>> We know that Python support the destructing of iterable objects.
>>
>> m_iter = (_ for _ in range(10))
>> a, *b, c = m_iter
>>
>> That's pretty cool! It's really convenient when there're many corner
>> cases to handle with iterable collections.
>> However destructing in Python could be more convenient if we support
>> dictionary destructing.
>>
>> In my opinion, dictionary destructing is not difficult to implement and
>> makes the syntax more expressive. A typical example is data access on
>> nested data structures(just like JSON), destructing a dictionary makes
>> the logic quite clear:
>>
>> data = {
>> "direct": "some data",
>> "nested": {
>> "lst_data": [1, 2, 3],
>> "int_data": 1
>> }
>> }
>> {
>>"direct": direct,
>> "nested": {
>> "lst_data": [a, b, c],
>> }
>> } = data
>>
>>
>> Dictionary destructing might not be very well-known but it really helps.
>> The operations on nested key-value collections are very frequent, and the
>> codes for business logic are not readable enough until now. Moreover Python
>> is now popular in data processing which must be enhanced by the entire
>> support of data destructing.
>>
>> Here are some implementations of other languages:
>> Elixir, which is also a popular dynamic language nowadays.
>>
>> iex> %{} = %{:a => 1, 2 => :b}
>> %{2 => :b, :a => 1}
>> iex> %{:a => a} = %{:a => 1, 2 => :b}
>> %{2 => :b, :a => 1}
>> iex> a
>> 1
>> iex> %{:c => c} = %{:a => 1, 2 => :b}
>> ** (MatchError) no match of right hand side value: %{2 => :b, :a => 1}
>>
>> And in F#, there is something similar to dictionary destructing(actually,
>> this destructs `struct` instead)
>> type MyRecord = { Name: string; ID: int } let IsMatchByName record1
>> (name: string) = match record1 with | { MyRecord.Name = nameFound;
>> MyRecord.ID = _; } when nameFound = name -> true | _ -> false let
>> recordX = { Name = "Parker"; ID = 10 } let isMatched1 = IsMatchByName
>> recordX "Parker" let isMatched2 = IsMatchByName recordX "Hartono"
>>
>> All of them partially destructs(or matches) a dictionary.
>>
>> thautwarm
>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is there any idea about dictionary destructing?

[Nikolas Vanderhoof]

Although that particular example once compiled to python will generate many
many lines of code:

​

On Sat, Apr 7, 2018 at 4:17 PM, Nikolas Vanderhoof <
nikolasrvanderh...@gmail.com> wrote:

> And this should print:
>
> 'some data'
> 1
> 2
> 3
>
> On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof <
> nikolasrvanderh...@gmail.com> wrote:
>
>> This would be a very handy feature, but Coconut (which is just python
>> with some extra functional-style features) also has support for this kind
>> of pattern-matching:
>> http://coconut-lang.org
>>
>>
>> ​Since Coconut will compile to Python (2 or 3) you can just write in
>> Coconut and use the resulting code in your Python.
>>
>> Using your first example in coconut would be nearly identical, except I
>> believe the entire dictionary must be specified (I am not sure about this).
>>
>> data = {
>> 'direct': 'some data',
>> 'nested': {
>> 'lst_data': [1, 2, 3],
>> 'int_data': 1
>> }
>> }
>>
>> {
>> 'direct': direct,
>> 'nested': {
>> 'lst_data': [a, b, c],
>> 'int_data': _
>> }
>> } = data
>>
>> print(direct)
>> print(a)
>> print(b)
>> print(c)
>>
>>
>> And this should print:
>>
>> On Sat, Apr 7, 2018 at 1:26 PM, thautwarm <yaoxiansa...@gmail.com> wrote:
>>
>>> We know that Python support the destructing of iterable objects.
>>>
>>> m_iter = (_ for _ in range(10))
>>> a, *b, c = m_iter
>>>
>>> That's pretty cool! It's really convenient when there're many corner
>>> cases to handle with iterable collections.
>>> However destructing in Python could be more convenient if we support
>>> dictionary destructing.
>>>
>>> In my opinion, dictionary destructing is not difficult to implement and
>>> makes the syntax more expressive. A typical example is data access on
>>> nested data structures(just like JSON), destructing a dictionary makes
>>> the logic quite clear:
>>>
>>> data = {
>>> "direct": "some data",
>>> "nested": {
>>> "lst_data": [1, 2, 3],
>>> "int_data": 1
>>> }
>>> }
>>> {
>>>"direct": direct,
>>> "nested": {
>>> "lst_data": [a, b, c],
>>> }
>>> } = data
>>>
>>>
>>> Dictionary destructing might not be very well-known but it really helps.
>>> The operations on nested key-value collections are very frequent, and the
>>> codes for business logic are not readable enough until now. Moreover Python
>>> is now popular in data processing which must be enhanced by the entire
>>> support of data destructing.
>>>
>>> Here are some implementations of other languages:
>>> Elixir, which is also a popular dynamic language nowadays.
>>>
>>> iex> %{} = %{:a => 1, 2 => :b}
>>> %{2 => :b, :a => 1}
>>> iex> %{:a => a} = %{:a => 1, 2 => :b}
>>> %{2 => :b, :a => 1}
>>> iex> a
>>> 1
>>> iex> %{:c => c} = %{:a => 1, 2 => :b}
>>> ** (MatchError) no match of right hand side value: %{2 => :b, :a => 1}
>>>
>>> And in F#, there is something similar to dictionary
>>> destructing(actually, this destructs `struct` instead)
>>> type MyRecord = { Name: string; ID: int } let IsMatchByName record1
>>> (name: string) = match record1 with | { MyRecord.Name = nameFound;
>>> MyRecord.ID = _; } when nameFound = name -> true | _ -> false let
>>> recordX = { Name = "Parker"; ID = 10 } let isMatched1 = IsMatchByName
>>> recordX "Parker" let isMatched2 = IsMatchByName recordX "Hartono"
>>>
>>> All of them partially destructs(or matches) a dictionary.
>>>
>>> thautwarm
>>>
>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>>
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is there any idea about dictionary destructing?

[Nikolas Vanderhoof]

This would be a very handy feature, but Coconut (which is just python with
some extra functional-style features) also has support for this kind of
pattern-matching:
http://coconut-lang.org


​Since Coconut will compile to Python (2 or 3) you can just write in
Coconut and use the resulting code in your Python.

Using your first example in coconut would be nearly identical, except I
believe the entire dictionary must be specified (I am not sure about this).

data = {
'direct': 'some data',
'nested': {
'lst_data': [1, 2, 3],
'int_data': 1
}
}

{
'direct': direct,
'nested': {
'lst_data': [a, b, c],
'int_data': _
}
} = data

print(direct)
print(a)
print(b)
print(c)


And this should print:

On Sat, Apr 7, 2018 at 1:26 PM, thautwarm  wrote:

> We know that Python support the destructing of iterable objects.
>
> m_iter = (_ for _ in range(10))
> a, *b, c = m_iter
>
> That's pretty cool! It's really convenient when there're many corner cases
> to handle with iterable collections.
> However destructing in Python could be more convenient if we support
> dictionary destructing.
>
> In my opinion, dictionary destructing is not difficult to implement and
> makes the syntax more expressive. A typical example is data access on
> nested data structures(just like JSON), destructing a dictionary makes
> the logic quite clear:
>
> data = {
> "direct": "some data",
> "nested": {
> "lst_data": [1, 2, 3],
> "int_data": 1
> }
> }
> {
>"direct": direct,
> "nested": {
> "lst_data": [a, b, c],
> }
> } = data
>
>
> Dictionary destructing might not be very well-known but it really helps.
> The operations on nested key-value collections are very frequent, and the
> codes for business logic are not readable enough until now. Moreover Python
> is now popular in data processing which must be enhanced by the entire
> support of data destructing.
>
> Here are some implementations of other languages:
> Elixir, which is also a popular dynamic language nowadays.
>
> iex> %{} = %{:a => 1, 2 => :b}
> %{2 => :b, :a => 1}
> iex> %{:a => a} = %{:a => 1, 2 => :b}
> %{2 => :b, :a => 1}
> iex> a
> 1
> iex> %{:c => c} = %{:a => 1, 2 => :b}
> ** (MatchError) no match of right hand side value: %{2 => :b, :a => 1}
>
> And in F#, there is something similar to dictionary destructing(actually,
> this destructs `struct` instead)
> type MyRecord = { Name: string; ID: int } let IsMatchByName record1
> (name: string) = match record1 with | { MyRecord.Name = nameFound;
> MyRecord.ID = _; } when nameFound = name -> true | _ -> false let recordX
> = { Name = "Parker"; ID = 10 } let isMatched1 = IsMatchByName recordX
> "Parker" let isMatched2 = IsMatchByName recordX "Hartono"
>
> All of them partially destructs(or matches) a dictionary.
>
> thautwarm
>
>
> ___
> 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] Repurpose `assert' into a general-purpose check

[Nikolas Vanderhoof]

Thank you for your explanation!
ᐧ

On Thu, Jan 18, 2018 at 11:00 PM, Guido van Rossum <gu...@python.org> wrote:

> On Thu, Jan 18, 2018 at 7:51 PM, Nikolas Vanderhoof <
> nikolasrvanderh...@gmail.com> wrote:
>
>> I sometimes wish that Python included a richer set of assertions rather
>>> than just a single `assert` keyword. Something like Eiffel's concept of
>>> pre-conditions, post-conditions and invariants, where each can be
>>> enabled or disabled independently.
>>
>>
>> Has something like this been proposed for Python before?
>> This seems to align more with the intended use of assert that's been
>> pointed out in this thread.
>> In what case though would one want to disable some but not all of these
>> pre, post, or invariant assertions?
>>
>
> Oh, many times, starting in the late '90s IIRC (Paul Dubois was a big fan).
>
> The problems are twofold: (a) it would require a lot of new keywords or
> ugly syntax; and (b) there would have to be a way to enable each form
> separately *per module or package*. Eiffel solves that (AFAIC) through
> separate compilation -- e.g. a stable version of a library might disable
> invariants and post-conditions but keep pre-conditions, since those could
> be violated by less mature application code; or a mature application could
> disable all checks and link with optimized library binaries that also have
> disabled all checks. I'm sure other scenarios are also viable.
>
> But that solution isn't available in Python, where command line flags
> apply to *all* modules being imported.
>
> (Note: even if you have a solution for (b), getting past (a) isn't so
> easy. So don't get nerd-sniped by the solution for (b) alone.)
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
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] Repurpose `assert' into a general-purpose check

[Nikolas Vanderhoof]

>
> I sometimes wish that Python included a richer set of assertions rather
> than just a single `assert` keyword. Something like Eiffel's concept of
> pre-conditions, post-conditions and invariants, where each can be
> enabled or disabled independently.


Has something like this been proposed for Python before?
This seems to align more with the intended use of assert that's been
pointed out in this thread.
In what case though would one want to disable some but not all of these
pre, post, or invariant assertions?

On Thu, Jan 18, 2018 at 2:12 AM, Ethan Furman  wrote:

> On 01/17/2018 10:59 PM, Steven D'Aprano wrote:
>
>> On Thu, Jan 18, 2018 at 05:22:06PM +1100, Chris Angelico wrote:
>>
>> I haven't yet seen any justification for syntax here. The nearest I've
>>> seen is that this "ensure" action is more like:
>>>
>>> try:
>>>  cond = x >= 0
>>> except BaseException:
>>>  raise AssertionError("x must be positive")
>>> else:
>>>  if not cond:
>>>  raise AssertionError("x must be positive")
>>>
>>> Which, IMO, is a bad idea, and I'm not sure anyone was actually
>>> advocating it anyway.
>>>
>>
>> My understanding is that Sylvain was advocating for that.
>>
>
> Agreed.  Which, as has been pointed out, is an incredibly bad idea.
>
> --
> ~Ethan~
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>

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

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

[Nikolas Vanderhoof]

I think having a means for such validations separate from assertions would
be helpful.
However, I agree with Steven that 'validate' would be a bad keyword choice.
Besides breaking compatibility with programs that use 'validate', it would
break
wsgiref.validate

in the standard library.

ᐧ

On Tue, Jan 16, 2018 at 2:22 PM, Juancarlo Añez  wrote:

> Perhaps the OP can look into Python macro libraries to get the wanted
> syntax?
>
> https://github.com/lihaoyi/macropy
>
> On Tue, Jan 16, 2018 at 2:35 PM, Paul Moore  wrote:
>
>> On 16 January 2018 at 17:36, Sylvain MARIE
>>  wrote:
>> > (trying with direct reply this time)
>> >
>> >> Why do you do this? What's the requirement for delaying evaluation of
>> the condition?
>> >
>> > Thanks for challenging my poorly chosen examples :)
>> >
>> > The primary requirement is about *catching*
>> unwanted/uncontrolled/heterogenous exceptions happening in the
>> underlying functions that are combined together to provide the validation
>> means, so as to provide a uniform/consistent outcome however diverse the
>> underlying functions are (they can return booleans or raise exceptions, or
>> both).
>> >
>> > In your proposal, if 'is_foo_compliant' raises an exception, it will
>> not be caught by 'assert_valid', therefore the ValidationError will not be
>> raised. So this is not what I want as an application developer.
>>
>> Ah, OK. But nothing in your proposal for a new statement suggests you
>> wanted that, and assert doesn't work like that, so I hadn't realised
>> that's what you were after.
>>
>> You could of course simply do:
>>
>> def assert_valid(expr, help_msg):
>> # Catch exceptions in expr() as you see fit
>> if not expr():
>> raise ValidationError(help_msg)
>>
>> assert_valid(lambda: 0 <= surf < 1 and is_foo_compliant(surf),
>> help_msg="surface should be 0=>
>> No need for a whole expression language :-)
>>
>> Paul
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
> Juancarlo *Añez*
>
> ___
> 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/