Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[INADA Naoki]

> Earlier versions of PEP 538 thus included "en_US.UTF-8" on the
> candidate target locale list, but that turned out to cause assorted
> problems due to the "C -> en_US" part of the coercion.

Hm, but PEP 538 says:

> this PEP instead proposes to extend the "surrogateescape" default for stdin 
> and stderr error handling to also apply to the three potential coercion 
> target locales.

https://www.python.org/dev/peps/pep-0538/#defaulting-to-surrogateescape-error-handling-on-the-standard-io-streams

I don't think en_US.UTF-8 should use surrogateescape error handler.

Regards,

INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[INADA Naoki]

Now I'm OK to accept the PEP, except one nitpick.

>
> Locale coercion only impacts non-Python code like C libraries, whereas
> the Python UTF-8 Mode only impacts Python code: the two PEPs are
> complementary.
>

This sentence seems bit misleading.
If UTF-8 mode is disabled explicitly, locale coercion affects Python code too.
locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8,
and stdio is UTF-8/surrogateescape.

So shouldn't this sentence is: "Locale coercion impacts both of Python code
and non-Python code like C libraries, whereas ..."?

INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Nick Coghlan]

On 9 December 2017 at 12:14, Nathaniel Smith  wrote:
> You'd have to ask Hynek to get the full rationale, but I believe it was both
> for consistency with slot classes, and for consistency with regular class
> definition. For example, type.__new__ actually does different things
> depending on whether it sees an __eq__ method, so adding a method after the
> fact led to weird bugs with hashing. That class of bug goes away if you
> always set up the autogenerated methods and then call type.__new__.

The main case I'm aware of where we do method inference in
type.__new__ is setting "__hash__ = None" if "__eq__" is set.

The main *problem* that arises with type replacement is that it
currently interacts pretty badly with zero-argument super, since we
don't make it easy to find and remap all the "__class__" references to
the new class object.

So right now, I think this trade-off tilts heavily in favour of "Keep
the same class, but reimplement any required method inference logic
when injecting methods".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Aaron Hall via Python-Dev]

 I'm not a typing expert, but I want to second Raymond's concerns, and perhaps 
I'm qualified to do so as I gave the PyCon USA __slots__ talk this year and I 
have a highly voted answer describing them on Stack Overflow.
Beautiful thing we're doing here with the dataclasses, by the way. I think 
addressing the slots issue could be a killer feature of dataclasses.

I hope this doesn't muddy the water:

If I could change a couple of things about __slots__ it would be 1. to allow 
multiple inheritance with multiple parents with nonempty slots (raises 
"TypeError: multiple bases have instance lay-out conflict"), and
2. to avoid creating redundant slots if extant in a parent (but maybe we should 
do this in the C level for all classes?).

It seems to me that Dataclasses could (and should) help us avoid the second 
issue regardless (should be trivial to look in the bases for preexisting slots, 
right?).

My workaround for the first issue is to inherit from ABCs with empty slots, but 
you need cooperative multiple inheritance for this - and you need to track the 
expected attributes (easy if you use abstract properties, which slots provide 
for. Maybe not all users of Dataclasses are advanced enough to do this?

So, maybe this is crazy (please don't call the nice men in white coats on me), 
came to me as I was responding, and definitely outside the box here, but 
perhaps we could make decorated dataclass be the abstract parent of the 
instantiated class?

Thanks,
Aaron Hall

On Friday, December 8, 2017, 1:31:44 PM EST, Raymond Hettinger 
 wrote:  
 The way __slots__ works is that the type() metaclass automatically assigns 
member-objects to the class variables 'x' and 'y'.  Member objects are 
descriptors that do the actual lookup.

So, I don't think the language limitation can be "fixed".  Essentially, we're 
wanting to use the class variables 'x' and 'y' to hold both member objects and 
a default value.

I recommend that you follow the path taken by attrs and return a new class.  
Otherwise, we're leaving users with a devil's choice.  You can have default 
values or you can have slots, but you can't have both.

The slots are pretty important.  With slots, a three attribute instance is only 
64 bytes.  Without slots, it is 296 bytes.

I'm hoping the typing experts will chime in here.  The question is 
straight-forward.  Where should we look for the signature and docstring for 
constructing instances?  Should they be attached to the class, to __init__(), 
or to __new__() when it used.

It would be nice to have an official position on that before, it gets set in 
stone through arbitrary choices made by pycharm, pydoc, mypy, 
typing.NamedTuple, and dataclasses.dataclass.


Raymond




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/aaronchall%40yahoo.com
  ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Ivan Levkivskyi]

On 8 December 2017 at 19:28, Raymond Hettinger 
wrote:

>
> I'm hoping the typing experts will chime in here.  The question is
> straight-forward.  Where should we look for the signature and docstring for
> constructing instances?  Should they be attached to the class, to
> __init__(), or to __new__() when it used.
>
> It would be nice to have an official position on that before, it gets set
> in stone through arbitrary choices made by pycharm, pydoc, mypy,
> typing.NamedTuple, and dataclasses.dataclass.
>
>
Here are some thoughts about this:

1. Instance variables are given very little attention in pydoc. Consider
this example:

>>> class C:
... x: int = 1
... def meth(self, y: int) -> None:
... ...
>>> help(C)

Help on class C in module __main__:

class C(builtins.object)
 |  Methods defined here:
 |
 |  meth(self, y: int) -> None
 |
 |  --
 |  Data descriptors defined here:
 |
 |  __dict__
 |  dictionary for instance variables (if defined)
 |
 |  __weakref__
 |  list of weak references to the object (if defined)
 |
 |  --
 |  Data and other attributes defined here:
 |
 |  __annotations__ = {'x': }
 |
 |  x = 1

The methods defined are listed first and are nicely formatted, while
variables together with __annotations__ are
left at the very end. I think that a line like

x: int = 1

should appear for every instance variable should appear first, even before
methods, since this is how people write (and read) classes.
See also https://bugs.python.org/issue28519 for another problem with pydoc.

2. pydoc already extracts the signature of class from __init__ and __new__
(giving the preference to later if both are present) including
the type annotations. I think this can be kept as is, but the special
constructs like NamedTuple and dataclass that auto-generate methods should
add annotations to them. For example, there is an issue to add annotations
to __new__ by NamedTuple, see https://bugs.python.org/issue31006
and https://github.com/python/typing/issues/454

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Eric V. Smith]

On 12/8/2017 9:14 PM, Nathaniel Smith wrote:
On Dec 7, 2017 12:49, "Eric V. Smith" > wrote:


The reason I didn't include it (as @dataclass(slots=True)) is
because it has to return a new class, and the rest of the dataclass
features just modifies the given class in place. I wanted to
maintain that conceptual simplicity. But this might be a reason to
abandon that. For what it's worth, attrs does have an
@attr.s(slots=True) that returns a new class with __slots__ set.


They actually switched to always returning a new class, regardless of 
whether slots is set:


https://github.com/python-attrs/attrs/pull/260


In the end, it looks like that PR ended up just refactoring things, and 
the decision to always return a new class was deferred. I still haven't 
finished evaluating exactly what the refactoring does, though.


Eric.

You'd have to ask Hynek to get the full rationale, but I believe it was 
both for consistency with slot classes, and for consistency with regular 
class definition. For example, type.__new__ actually does different 
things depending on whether it sees an __eq__ method, so adding a method 
after the fact led to weird bugs with hashing. That class of bug goes 
away if you always set up the autogenerated methods and then call 
type.__new__.


They have a bunch of test cases that I'll have to review, too.

Eric.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com