Re: [Python-ideas] Add a dict with the attribute access capability

[Nick Coghlan]

On 30 November 2017 at 05:11, Barry Warsaw  wrote:
> Serhiy Storchaka wrote:
>> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
>> already was deprecated when the plistlib module was added to the regular
>> stdlib in Python 2.6.
>>
>> Raymond noticed that that capability seemed nice to have.
>
> So nice in fact that I'm sure I've reimplemented something similar
> several times. :)

Note that we do offer a simple namespace type:

>>> from types import SimpleNamespace as ns
>>> data = ns(a=1, b=2, c=3)
>>> data.a
1
>>> vars(data)["a"]
1
>>> vars(data)["a"] = 3
>>> data.a
3

It was added as part of adding sys.implementation, since it's the
storage type used for that:

>>> import sys
>>> type(sys.implementation)


So the only thing we don't currently offer is a type that provides
both attribute access and mapping access on the *same* object - for
SimpleNamespace we require that you request the mapping API with
"vars(ns)".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 447: Adding type.__getdescriptor__

[Nick Coghlan]

On 1 December 2017 at 01:23, Ronald Oussoren  wrote:
> 1) Last time around Mark Shannon worried that this introduces infinite
> recursion in the language itself (in my crummy summary, please read this
> message to get the real concern
> ).  Is
> this truly a problem?  I don’t think there is a problem, but I’m worried
> that I don’t fully understand Mark’s concerns.
>
> 2) PEP 487 introduced __init_subclass__ as a class method to avoid having to
> write a metaclass for a number of use cases.  My PEP currently does require
> a metaclass, but it might be nicer to switch to a regular class method
> instead (like __init_subclass__).

I think the second point there may actually allow you to resolve the
first one, by way of making `__getdescriptor__` an optional override
of the typical lookup algorithm. That is:

def _PyType_Lookup(tp, name):

# New optional override for descriptor lookups
try:
# Ordinary attribute lookup, *NOT* a descriptor lookup
getdesc = tp.__getdescriptor__
except AttributeError:
pass
else:
return getdesc(name)

# Default algorithm used in the absence of an override
mro = tp.mro()
assert isinstance(mro, tuple)

for base in mro:
   assert isinstance(base, type)

   try:
   return base.__dict__[name]
   except KeyError:
   pass

return None

If you did go this way, then we'd want to add a
"types.getdescriptor(cls, name)" API to expose _PyType_Lookup at the
Python layer, since "getattr(type(obj), name)" wouldn't be an accurate
emulation of the algorithm any more.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How assignment should work with generators?

[Greg Ewing]

Steve Barnes wrote:
Since the practical 
difference between remainder being the (partly exhausted) iterator and 
it being a list, (itself an iterator),


A list is *not* an iterator, it's a sequence. There's
a huge difference. Items of a sequence can be accessed
at random, it can be iterated over multiple times,
if it's mutable its contents can be changed, etc.
None of that can be done to an iterator.

Maybe it would have been a defensible design decision
when *-unpacking was introduced, but it's too late to
change it now.

Even if it weren't, there are arguments against it.
It would be inconsistent with the usage of * in an
argument list, where the function always receives a
new tuple, never an iterator over something passed as
a * argument.

--
Greg
___
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] Stub class for Generic to further improve PEP 560

[Ilya Kulakov]

> Anyway, my expectation is that going along this way (i.e. removing all 
> runtime API apart from a necessary minimum)
> will give a minor speed-up as compared to PEP 560 at the cost of a breaking 
> change (even for small number of developers).

I don't think the change will be breaking: usage of this class will be entirely 
voluntarily and does not replace typing.Generic

> PEP 560 already gives overhead of 80% as compared to normal classes in worst 
> case scenario
> (empty body with a single generic base). This is actually less than for ABCs 
> (they can give up to 120% in worst case scenario).

GenericMeta inherits from ABCMeta. Do you mean that it will be removed after 
560 lands?

> Moreover, performance is not a single motivation for PEP 560, there are other 
> arguments such as metaclass conflicts which will
> not be solved without the machinery proposed by the PEP.

Perhaps you can consider designing Generic / GenericMeta in a way that will 
allow end user to create GenericStub-alike class without much trouble?___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How assignment should work with generators?

[Steve Barnes]

On 30/11/2017 22:26, Greg Ewing wrote:
> Steven D'Aprano wrote:
>> On Wed, Nov 29, 2017 at 07:33:54PM +, Steve Barnes wrote:
>>
>>> Just a thought but what about a syntax something along the lines of:
>>>
>>> a, b, *remainder = iterable
>>>
>>> Where remainder becomes the iterable with the first two values 
>>> consumed by assigning to a & b. 
>>
>> Guido's time machine strikes again. That has worked since 3.3 if not 
>> older.
> 
> This is not quite the same thing -- the rest of the items
> are extracted and put in a new list. I think Steve Barnes is
> suggesting that the iterator should be left alone and
> bound to the * target instead.
> 
> That would be an incompatible change.
> 
That is what I was thinking of but surely it would be more efficient way 
to do this for generators and large iterators. Since the practical 
difference between remainder being the (partly exhausted) iterator and 
it being a list, (itself an iterator), containing the results of 
expanding the remainder of the original iterator is slight.

The only limitation would be that the syntax a, b, *remainder, c, d = 
iterator would be illegal.
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Re: [Python-ideas] How assignment should work with generators?

[Greg Ewing]

Steven D'Aprano wrote:

On Wed, Nov 29, 2017 at 07:33:54PM +, Steve Barnes wrote:


Just a thought but what about a syntax something along the lines of:

a, b, *remainder = iterable

Where remainder becomes the iterable with the first two values consumed 
by assigning to a & b. 


Guido's time machine strikes again. That has worked since 3.3 if not 
older.


This is not quite the same thing -- the rest of the items
are extracted and put in a new list. I think Steve Barnes is
suggesting that the iterator should be left alone and
bound to the * target instead.

That would be an incompatible change.

--
Greg
___
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] Stub class for Generic to further improve PEP 560

[Ivan Levkivskyi]

On 30 November 2017 at 22:38, Ilya Kulakov  wrote:

> A very rough implementation:
>
> typing.py:
>
> class _GenericMetaNoop(type):
> def __getitem__(self, params):
> return self
>
> class _GenericNoop(metaclass=_GenericMetaNoop)
> pass
>
> GenericStub = Generic if TYPE_CHECKING else _GenericNoop
>
> elsewhere.py:
>
> import typing
>
> T = typing.TypeVar('T')
>
> class MyClass(typing.GenericStub[T]):
> pass
>
>
OK, I see.

Note that all type checkers known to me never actually read content of
typing.py (it is always heavily special cased).
Therefore, one can safely write `GenericStub = _GenericNoop`.

Anyway, my expectation is that going along this way (i.e. removing all
runtime API apart from a necessary minimum)
will give a minor speed-up as compared to PEP 560 at the cost of a breaking
change (even for small number of developers).
PEP 560 already gives overhead of 80% as compared to normal classes in
worst case scenario
(empty body with a single generic base). This is actually less than for
ABCs (they can give up to 120% in worst case scenario).

Moreover, performance is not a single motivation for PEP 560, there are
other arguments such as metaclass conflicts which will
not be solved without the machinery proposed by the PEP.

--
Ivan
___
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] Add a dict with the attribute access capability

[Greg Ewing]

Ivan Pozdeev via Python-ideas wrote:
I needed to hold an external function 
reference in an object instance (if I assigned it to an attribute, it 
was converted into an instance method).


No, that only happens to functions stored in *class* attributes,
not instance attributes.

>>> class A:
...pass
...
>>> a = A()
>>>
>>> def f():
...print("I'm just a function")
...
>>> a.x = f
>>> a.x()
I'm just a function

--
Greg
___
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] Stub class for Generic to further improve PEP 560

[Ilya Kulakov]

A very rough implementation:

typing.py:

class _GenericMetaNoop(type):
def __getitem__(self, params):
return self

class _GenericNoop(metaclass=_GenericMetaNoop)
pass

GenericStub = Generic if TYPE_CHECKING else _GenericNoop

elsewhere.py:

import typing

T = typing.TypeVar('T')

class MyClass(typing.GenericStub[T]):
pass

Now when run under type checkers MyClass will inherit typing.Generic with all 
runtime complexity.
However when run outside of them code will just work.


> On Nov 30, 2017, at 1:35 PM, Ivan Levkivskyi  wrote:
> 
> Could you please give some examples for these statements? They still look to 
> abstract for me.

___
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] Stub class for Generic to further improve PEP 560

[Ivan Levkivskyi]

On 30 November 2017 at 22:25, Ilya Kulakov  wrote:

> My point is to have a class with public interface identical to
> typing.Generic, but without all runtime overhead.
> It's based on the assumption that few developers benefit with
> typing.Generic addition during production application execution.
>
> Those who do, can subclass typing.Generic directly


Could you please give some examples for these statements? They still look
to abstract for me.

--
Ivan
___
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] Stub class for Generic to further improve PEP 560

[Ilya Kulakov]

My point is to have a class with public interface identical to typing.Generic, 
but without all runtime overhead.
It's based on the assumption that few developers benefit with typing.Generic 
addition during production application execution.

Those who do, can subclass typing.Generic directly.

> On Nov 30, 2017, at 1:22 PM, Ivan Levkivskyi  wrote:
> 
> FWIW, with PEP 560 generic classes will stay generic at runtime. I am not 
> sure what you mean by this, but
> practically all existing runtime APIs (with few exceptions, see PEP 560) for 
> generics will stay.

___
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] Stub class for Generic to further improve PEP 560

[Ilya Kulakov]

As explained in PEP 560, creation of Generic subclasses is much slower (~7x on 
my machine).
My guess is that a limited number of applications actually need Generic classes 
at "production" runtime (i.e. when not under analysis of mypy or IDE).

I propose a special class that will alias typing.Generic whenever 
typing.TYPE_CHECKING == True and a no-op stub otherwise.


Best Regards,
Ilya Kulakov

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

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

[Chris Angelico]

On Fri, Dec 1, 2017 at 5:45 AM, Tres Seaver  wrote:
>> I would *not* add any spelling for an explicit bare-except equivalent.
>> You would have to write:
>>
>>   val = name.strip()[4:].upper() except Exception as -1
>
>
> Wouldn't that really need to be this instead, for a true 'except:' 
> equivalence:
>
>   val = name.strip()[4:].upper() except BaseException as -1
>

Read the rejected PEP 463 for all the details and arguments. All this
has been gone into.

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

Re: [Python-ideas] What's the status of PEP 505: None-aware operators?

[Tres Seaver]

On 11/29/2017 01:02 PM, Barry Warsaw wrote:

> I don’t know whether I like any of this  but I think a more
> natural spelling would be:
> 
>   val = name.strip()[4:].upper() except (AttributeError, KeyError) as -1
> 
> which could devolve into:
> 
>   val = name.strip()[4:].upper() except KeyError as -1
> 
> or:
> 
>   val = name.strip()[4:].upper() except KeyError # Implicit `as None`

Of all the proposed spellings for the idea, this one feels most "normal" to
me, too (I'm -0 on the idea as a whole).


> I would *not* add any spelling for an explicit bare-except equivalent.
> You would have to write:
> 
>   val = name.strip()[4:].upper() except Exception as -1


Wouldn't that really need to be this instead, for a true 'except:' equivalence:

  val = name.strip()[4:].upper() except BaseException as -1



Tres.
-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com

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

Re: [Python-ideas] How assignment should work with generators?

[Paul Moore]

On 30 November 2017 at 16:16, Steve Barnes  wrote:
> I had a sneaky feeling that it did, which raises the question of what
> the bleep this enormous thread is about, since the fundamental syntax
> currently exists

Essentially, it's about the fact that to build remainder you need to
copy all of the remaining items out of the RHS. And for an infinite
iterator like count() this is an infinite loop.

There's also the point that if the RHS is an iterator, reading *any*
values out of it changes its state - and
1. a, b, *remainder = rhs therefore exhausts rhs
2. a.b = rhs reads "one too many" values from rhs to check if
there are extra values (which the programmer has asserted shouldn't be
there by not including *remainder).

Mostly corner cases, and I don't believe there have been any
non-artificial examples posted in this thread. Certainly no-one has
offered a real-life code example that is made significantly worse by
the current semantics, and/or which couldn't be easily worked around
without needing a language change.

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

[Python-ideas] PEP 505 vs matrix multiplication

[Antoine Pitrou]

On Wed, 29 Nov 2017 18:14:36 +1000
Nick Coghlan  wrote:
> 
> As far as utility goes, I put it in a similar category to matrix
> multiplication: if you don't need it, you don't need it, but when you
> do need it, you need it a *lot*.

As someone who appreciates both the matrix multiplication operator and
"async/await", I really don't think PEP 505-style operators (regardless
of their spellings) fall into the same conceptual bucket.

There's no risk of matrix multiplication operators bleeding into
non-domain specific code, and the readers of domain specific code
already know about the matrix multiplication operator and what it
does (or they should anyway, since it's so damn useful).  It's like
"async/await": you won't find them in regular non-async code, so the
mental burden only falls on specialists who write and read event-driven
networking code (mostly, even though Guido would like to see parsers
based on the idiom too :-)). Conversely, PEP 505-style operators may
appear in everyday code regardless of their application domain or
target.  This in turn increases the mental burden for *everyone*.

Regards

Antoine.


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

Re: [Python-ideas] How assignment should work with generators?

[Steve Barnes]

On 30/11/2017 15:50, Steven D'Aprano wrote:
> On Wed, Nov 29, 2017 at 07:33:54PM +, Steve Barnes wrote:
> 
>> Just a thought but what about a syntax something along the lines of:
>>
>> a, b, *remainder = iterable
>>
>> Where remainder becomes the iterable with the first two values consumed
>> by assigning to a & b.
> 
> Guido's time machine strikes again. That has worked since 3.3 if not
> older. (Probably 3.0 or so, but I don't have that on this computer to
> test it.)
> 
> py> a, b, *remainder = range(10)
> py> a
> 0
> py> b
> 1
> py> remainder
> [2, 3, 4, 5, 6, 7, 8, 9]
> 
> 
> 
> 

I had a sneaky feeling that it did, which raises the question of what 
the bleep this enormous thread is about, since the fundamental syntax 
currently exists
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

[Brett Cannon]

On Wed, 29 Nov 2017 at 13:28 Greg Ewing  wrote:

> Nick Coghlan wrote:
>
> >>What about more English-like syntax:
> >>
> >>X or else Y
> >
> > The problem with constructs like this is that they look like they
> > should mean the same thing as "X or Y".
>
> How about:
>
> x otherwise y
>
> It looks different enough from "or" that you're not going
> to accidentally read it that way when skimming.
>
> The meaning is something you'll have to learn if you don't
> know, but at least it's a word that can be googled for.
>

 In terms of syntax, this is my favourite one so far.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

[Ivan Pozdeev via Python-ideas]

On 29.11.2017 9:08, Steven D'Aprano wrote:

On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote:

I also cc python-dev to see if anybody here is strongly in favor or against 
this inclusion.

Put me down for a strong -1.  The proposal would occasionally save a
few keystokes but comes at the expense of giving Python a more Perlish
look and a more arcane feel.

I think that's an unfair characterisation of the benefits of the PEP.
It's not just "a few keystrokes".

Ironically, the equivalent in Perl is // which Python has used for
truncating division since version 2.4 or so. So if we're in danger of
looking "Perlish", that ship has sailed a long time ago.

Perl is hardly the only language with null-coalescing operators -- we
might better describe ?? as being familiar to C#, PHP, Swift and Dart.
That's two mature, well-known languages and two up-and-coming languages.

My experience with these operators in C# says:
* They do save "more than a few keystrokes". Even more importantly, they 
allow to avoid double evaluation or the need for a temporary variable 
workaround that are inherent in " if  else "
    * (An alternative solution for the latter problem would be an 
assignment expression, another regularly rejected proposal.)

* They make it temptingly easy and implicit to ignore errors.
* They are alien to Python's standard semantics on search failure which 
is to raise an exception rather than return None


[...]

 timeout ?? local_timeout ?? global_timeout

As opposed to the status quo:

 timeout if timeout is not None else (local_timeout if local_timeout is not 
None else global_timeout)

Or shorter, but even harder to understand:

 (global_timeout if local_timeout is None else local_timeout) if timeout is 
None else timeout

I'd much prefer to teach the version with ?? -- it has a simple
explanation: "the first of the three given values which isn't None". The
?? itself needs to be memorized, but that's no different from any other
operator. The first time I saw ** I was perplexed and couldn't imagine
what it meaned.

Here ?? doesn't merely save a few keystrokes, it significantly reduces
the length and complexity of the expression and entirely cuts out the
duplication of names.

If you can teach

 timeout or local_timeout or global_timeout

then you ought to be able to teach ??, as it is simpler: it only
compares to None, and avoids needing to explain or justify Python's
truthiness model.



 'foo' in (None ?? ['foo', 'bar'])

If you can understand

 'foo' in (False or ['foo', 'bar'])

then surely you can understand the version with ??.



 requested_quantity ?? default_quantity * price

Again:

 (default_quantity if requested_quantity is None else requested_quantity) * 
price


I'd much prefer to read, write and teach the version with ?? over the
status quo.




--
Regards,
Ivan

___
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] PEP 447: Adding type.__getdescriptor__

[Ronald Oussoren]

Hi,

I’m trying to get up to speed again w.r.t. PEP 447 (and to be honest, with 
CPython’s development workflow as its been too long since I’ve actually done 
work on the CPython codebase…).

Let me start by recapping the PEP (>) is about: The problem I’m trying 
to solve is that super.__getattribute__ basicy assumes looking at the __dict__ 
of classes on the MRO is all that’s needed to check if those classes provide an 
attribute.  The core of both object.__getattribute__ and super.__getattribute__ 
for finding a descriptor on the class is basically (from the PEP):

def _PyType_Lookup(tp, name):
mro = tp.mro()
assert isinstance(mro, tuple)

for base in mro:
   assert isinstance(base, type)

   try:
   return base.__dict__[name]
   except KeyError:
   pass

return None

Note that the real implementation in in C, and accesses base.__dict__ directly 
instead of through Python’s attribute lookup (which would lead to infinite 
recursion).

This is problematic when the class is dynamically populated, as the descriptor 
may not yet be present in the class __dict__.  This is not a problem for normal 
attribute lookup, as you can replace the __getattribute__ method of the class 
to do the additional work (at the cost of having to reimplement all of 
__getattribute__).  This is a problem for super() calls though, as super will 
unconditionally use the lookup code above.

The PEP proposed to replace “base.__dict__[name]” by 
“base.__class__.__getdescriptor__(name)” (once again, in C with direct access 
to the two slots instead of accessing them through normal attribute lookup).

I have two open questions about this PEP:

1) Last time around Mark Shannon worried that this introduces infinite 
recursion in the language itself (in my crummy summary, please read this 
message to get the real concern 
>).  Is 
this truly a problem?  I don’t think there is a problem, but I’m worried that I 
don’t fully understand Mark’s concerns.

2) PEP 487 introduced __init_subclass__ as a class method to avoid having to 
write a metaclass for a number of use cases.  My PEP currently does require a 
metaclass, but it might be nicer to switch to a regular class method instead 
(like __init_subclass__). 

My primary usecase for this PEP is PyObjC, which does populate the class 
dictionary on demand for performance and correctness reasons and PyObC 
therefore currently includes a replacement for super.  For PyObjC’s 
implementation making __getdescriptor__ a classmethod would be a win as this 
would avoid creating yet another level of metaclasses in C code (PyObjC already 
has a Python class and metaclass for every Objective-C class, PEP 447 would 
require the introduction of a metaclass for those metaclasses). 

BTW. Two other open issues w.r.t. this PEP are forward porting the patch (in 
issue 18181) and performing benchmarks. The patch doesn’t apply cleanly to the 
current tip of the tree, I’ll try to update it tomorrow.  And with some luck 
will manage to update PyObjC’s implementation as well to validate the design.

Ronald___
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] Add a dict with the attribute access capability

[Ivan Pozdeev via Python-ideas]

I use argparse.Namespace whenever I need this.

In reply to Chris Barker's concern of "is this code or is this data", 
the last time I used it is when I needed to hold an external function 
reference in an object instance (if I assigned it to an attribute, it 
was converted into an instance method). It just didn't feel right to 
invoke it via a container lookup.


A telling name for the object also clears doubts about what it's 
supposed to hold.


On 29.11.2017 11:52, Serhiy Storchaka wrote:
In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it 
already was deprecated when the plistlib module was added to the 
regular stdlib in Python 2.6.


This is a dict subclass which allows to access items as attributes.

d = plistlib.Dict()
d['a'] = 1
assert d.a == 1
d.b = 2
assert d['b'] == 2

Raymond noticed that that capability seemed nice to have.

What do you think about reviving this type as general purpose type in 
collections or types? Perhaps it can be convenient for working with 
JSON, plists, configuration files, databases and in other cases that 
need a dict with string keys.


If reintroduce it, there are open questions.

1. The name of the type.

2. The location of the type. collections or types? Or other variants?

3. How it will collaborate with OrderedDict, defaultdict, etc?

4. Should it be a dict subclass, or a mixin, or a proxy? Or add 
several types?



[1] https://bugs.python.org/issue29196

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


--
Regards,
Ivan

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

Re: [Python-ideas] How assignment should work with generators?

[Steven D'Aprano]

On Wed, Nov 29, 2017 at 07:33:54PM +, Steve Barnes wrote:

> Just a thought but what about a syntax something along the lines of:
> 
> a, b, *remainder = iterable
> 
> Where remainder becomes the iterable with the first two values consumed 
> by assigning to a & b. 

Guido's time machine strikes again. That has worked since 3.3 if not 
older. (Probably 3.0 or so, but I don't have that on this computer to 
test it.)

py> a, b, *remainder = range(10)
py> a
0
py> b
1
py> remainder
[2, 3, 4, 5, 6, 7, 8, 9]




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

Re: [Python-ideas] Immutable dictionaries

[Stephan Houben]

2017-11-30 2:16 GMT+01:00 Rob Cliffe :

> This is sort of a subset of an idea I once posted on Python-Ideas:
> Dictionaries, sets and lists (etc. ?) could have a mutable flag, and once
> it was set to False you could neither change it back nor change the
> object.  (OK there might be some backdoor hacks, this is Python.)  This
> would avoid having to explain to beginners "Why does Python have lists and
> tuples?" because instead of a tuple, all you need is an immutable list.
> (Or if you prefer, instead of a list, all you need is a mutable tuple.)
>


Here is a concept implementation of a freeze() function which does
something similar.
Rather than mutating the mutable object to become immutable, it
makes an immutable copy.

>>> freeze({"x": [1,2,{3,4}]})
mappingproxy({'x': (1, 2, frozenset({3, 4}))})

https://gist.github.com/stephanh42/d277170dd8a3a2f026c272a4fda15396

Stephan


> Rob Cliffe
>
> ___
> 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/