Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Michel Desmoulin]

Having to define objects for scripts or small projects is really adding
a burden. A namedtuple litteral strike the perferfect balance between
expressivity and concision for those cases.

Le 21/07/2017 à 17:18, Guido van Rossum a écrit :
> Honestly I would like to declare the bare (x=1, y=0) proposal dead.
> Let's encourage the use of objects rather than tuples (named or
> otherwise) for most data exchanges. I know of a large codebase that uses
> dicts instead of objects, and it's a mess. I expect the bare ntuple to
> encourage the same chaos.
> 
> -- 
> --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/
> 
___
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] namedtuple literals [Was: RE a new namedtuple]

[Juancarlo Añez]

> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
> encourage the use of objects rather than tuples (named or otherwise) for
> most data exchanges. I know of a large codebase that uses dicts instead of
> objects, and it's a mess. I expect the bare ntuple to encourage the same
> chaos.
>

Languages since the original Pascal have had a way to define types by
structure. If Python did the same, ntuples with the same structure would be
typed "objects" that are not pre-declared.

In Python's case, because typing of fields is not required and thus can't
be used to hint the structures type, the names and order of fields could be
used. Synthesizing a (reserved) type name for (x=1, y=0) should be straight
forward.

I short,

>>> isinstance(x=None, y=None), type((x=1, y=0)))
True

That can be implemented with namedtuple with some ingenious mangling for
the (quasi-anonymous) type name.

Equivalence of types by structure is useful, and is very different from the
mess that using dicts as records can produce.

Cheers,

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

Re: [Python-ideas] Idea : for smarter assignment?

[David Mertz]

On Fri, Jul 21, 2017 at 10:19 AM, Brett Cannon  wrote:

> On Fri, 21 Jul 2017 at 10:08 Jason H  wrote:
>
>> I experimented with Python in college and I've been for close to 20 years
>> now. (Coming and going as needed) I love the language. But there is one
>> annoyance that I continually run into.
>>
>> There are basically two assignment operators, based on context, = and :
>> a = 1
>> { a: 1 }
>>
>
The `=` isn't an assignment operator, it's a *binding*.  The name 'a' gets
bound to the integer object "1" in your example.  Don't confuse this with a
language like C where it really is an assignment.  If I later write:

a = 2

I haven't changed the "cell" that contains the integer object, I've rebound
the NAME `a` to a different object.

But you've left out quite a few binding operations.  I might forget some,
but here are several:

import a   # bind the name `a` to a module object

with open(fname) as a: pass   # bind the name `a` to a file handle

for a in [1]: pass   # bind the name `a` to each of the objects in an
iterable
# ... In this case, the net result is identical to `a=1`

def a(): pass# bind the name `a` to a function object defined in
the body

class a: pass   # bind the name `a` to a class object defined in the
body

With a bit of circuitous code, you *can* use a dictionary to bind a
variable too:

>>> globals().update({'a':1})
>>> a
1

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

Re: [Python-ideas] Idea : for smarter assignment?

[Jelle Zijlstra]

2017-07-21 10:07 GMT-07:00 Jason H :

> I experimented with Python in college and I've been for close to 20 years
> now. (Coming and going as needed) I love the language. But there is one
> annoyance that I continually run into.
>
> There are basically two assignment operators, based on context, = and :
> a = 1
> { a: 1 }
>
> They cannot be used interchangeably:
> a: 1 # error
> {a=1} # error
>
> I don't think I should be this way.
>
> There are times when I have a bunch of variables that I want to collect
> into an object or destructure. This involves adding commas, and swapping
> the :/=. I don't have a good fix for  the adding of commas (maybe a
> newline?)
> but I think : should at least be accepted as = everywhere except in ifs:
> a: 1 # same as a = 1
>
> One area where it might help (although the python parser already catches
> it) is in ifs:
> if a:1 # always error ?
> if a=1 # currently error, but might be accepted shorthand for == ?
>
> Ideally, I could take
> a: 1
> b: 2
>

This conflicts with PEP 526 variable annotations: "a: int" already means "a
is of type int", but with your syntax there would be no way to distinguish
between "a = int" and "a: int".


> then in 3 edits:
> 1. first line prepend 'x: {'
> 2. last line append '}'
> 3. indent between { }
>
> I guess his would imply that { open up an assignment scope, where newlines
> are commas if the last line did not end with an operator or the next line
> did not start with an operator:
> x: {
>   a: x -  # - operator
> f(x)
>   b:  # : operator
> 5487234728394720348988734574357
>   c: 7# c is 13, no trailing operator but next line has a preceding
> operator
> + 6
> }
>
> The only issue then is how do we address a?
> x.a# looks fine to me
> x['a'] # as a dict, but the conversion of a to string 'a' could be
> confusing.
>
>
> Additionally, I was also thinking about : as an implied await:
> a = await f() # await generator
> a: f()# await generator, or direct assignment if return type is
> not a generator/async func
>
> Thoughts? Please be gentle :-)
> ___
> 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] Idea : for smarter assignment?

[Brett Cannon]

On Fri, 21 Jul 2017 at 10:08 Jason H  wrote:

> I experimented with Python in college and I've been for close to 20 years
> now. (Coming and going as needed) I love the language. But there is one
> annoyance that I continually run into.
>
> There are basically two assignment operators, based on context, = and :
> a = 1
> { a: 1 }
>

So the latter is not an assignment. `=` is an assignment as it creates a
new entry in a namespace, while the later just associates a key with a
value in a dictionary.


>
> They cannot be used interchangeably:
> a: 1 # error
> {a=1} # error
>
> I don't think I should be this way.
>

But it's on purpose as they do different things. Thanks for sharing the
idea but I don't see this changing.

-Brett


>
> There are times when I have a bunch of variables that I want to collect
> into an object or destructure. This involves adding commas, and swapping
> the :/=. I don't have a good fix for  the adding of commas (maybe a
> newline?)
> but I think : should at least be accepted as = everywhere except in ifs:
> a: 1 # same as a = 1
>
> One area where it might help (although the python parser already catches
> it) is in ifs:
> if a:1 # always error ?
> if a=1 # currently error, but might be accepted shorthand for == ?
>
> Ideally, I could take
> a: 1
> b: 2
> then in 3 edits:
> 1. first line prepend 'x: {'
> 2. last line append '}'
> 3. indent between { }
>
> I guess his would imply that { open up an assignment scope, where newlines
> are commas if the last line did not end with an operator or the next line
> did not start with an operator:
> x: {
>   a: x -  # - operator
> f(x)
>   b:  # : operator
> 5487234728394720348988734574357
>   c: 7# c is 13, no trailing operator but next line has a preceding
> operator
> + 6
> }
>
> The only issue then is how do we address a?
> x.a# looks fine to me
> x['a'] # as a dict, but the conversion of a to string 'a' could be
> confusing.
>
>
> Additionally, I was also thinking about : as an implied await:
> a = await f() # await generator
> a: f()# await generator, or direct assignment if return type is
> not a generator/async func
>
> Thoughts? Please be gentle :-)
> ___
> 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] Idea : for smarter assignment?

[Rhodri James]

On 21/07/17 18:07, Jason H wrote:

There are basically two assignment operators, based on context, = and :
a = 1
{ a: 1 }


No there aren't.  The colon isn't assigning at all, it's separating a 
key from a corresponding value.  The object referenced by 'a' is 
unchanged by being part of a dictionary literal.  From that point on 
your whole argument falls apart.


--
Rhodri James *-* Kynesim Ltd
___
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] Idea : for smarter assignment?

[Jason H]

I experimented with Python in college and I've been for close to 20 years now. 
(Coming and going as needed) I love the language. But there is one annoyance 
that I continually run into. 

There are basically two assignment operators, based on context, = and : 
a = 1 
{ a: 1 } 

They cannot be used interchangeably:
a: 1 # error
{a=1} # error

I don't think I should be this way.

There are times when I have a bunch of variables that I want to collect into an 
object or destructure. This involves adding commas, and swapping the :/=. I 
don't have a good fix for  the adding of commas (maybe a newline?)
but I think : should at least be accepted as = everywhere except in ifs:
a: 1 # same as a = 1

One area where it might help (although the python parser already catches it) is 
in ifs:
if a:1 # always error ?
if a=1 # currently error, but might be accepted shorthand for == ?

Ideally, I could take
a: 1
b: 2
then in 3 edits:
1. first line prepend 'x: {'
2. last line append '}'
3. indent between { }

I guess his would imply that { open up an assignment scope, where newlines are 
commas if the last line did not end with an operator or the next line did not 
start with an operator:
x: { 
  a: x -  # - operator
f(x) 
  b:  # : operator
5487234728394720348988734574357
  c: 7# c is 13, no trailing operator but next line has a preceding operator
+ 6 
}

The only issue then is how do we address a?
x.a# looks fine to me
x['a'] # as a dict, but the conversion of a to string 'a' could be confusing.


Additionally, I was also thinking about : as an implied await:
a = await f() # await generator
a: f()# await generator, or direct assignment if return type is not a 
generator/async func

Thoughts? Please be gentle :-)
___
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] namedtuple literals [Was: RE a new namedtuple]

[Guido van Rossum]

Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
encourage the use of objects rather than tuples (named or otherwise) for
most data exchanges. I know of a large codebase that uses dicts instead of
objects, and it's a mess. I expect the bare ntuple to encourage the same
chaos.

-- 
--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] namedtuple literals [Was: RE a new namedtuple]

[Koos Zevenhoven]

On Fri, Jul 21, 2017 at 8:49 AM, Serhiy Storchaka 
wrote:

> 20.07.17 04:35, Alexander Belopolsky пише:
>
>> On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum 
>> wrote:
>>
>>> The proposal in your email seems incomplete
>>>
>>
>> The proposal does not say anything about type((x=1, y=2)).  I assume
>> it will be the same as the type currently returned by namedtuple(?, 'x
>> y'), but will these types be cached? Will type((x=1, y=2)) is
>> type((x=3, y=4)) be True?.
>>
>
> Yes, this is the key problem with this idea.
>
> If the type of every namedtuple literal is unique, this is a waste of
> memory and CPU time. Creating a new type is much more slower than
> instantiating it, even without compiling. If support the global cache of
> types, we have problems with mutability and life time. If types are mutable
> (namedtuple classes are), setting the __doc__ or __name__ attributes of
> type((x=1, y=2)) will affect type((x=3, y=4)). How to create two different
> named tuple types with different names and docstrings?


How about just making a named namedtuple if you want to mutate the type? Or
perhaps make help() work better for __doc__ attributes on instances.
Currently,

>>> class Foo: pass
...
>>> f = Foo()
>>> f.__doc__ = "Hello"
>>> help(f)

does not show "Hello" at all.


In Python 2 all types are immortal, in python 3 they can be collected as
> ordinary objects, and you can create types dynamically without a fear of
> spent too much memory. If types are cached, we should take care about
> collecting unused types, this will significantly complicate the
> implementation.
>
>
Hmm. Good point. Even if making large amounts of arbitrary disposable
anonymous namedtuples is probably not a great idea, someone might do it.
Maybe having a separate type for each anonymous named tuple is not worth
it. After all, keeping references to the attribute names in the object
shouldn't take up that much memory. And the tuples are probably often
short-lived.

Given all this, the syntax for creating anonymous namedtuples efficiently
probably does not really need to be super convenient on the Python side,
but having it available and unified with that structseq thing would seem
useful.

-- Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/