Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On Sat, Feb 03, 2018 at 01:01:30AM +0100, asrp asrp wrote: > I've made a small Python interpreter in Python with runtime AST node > semantics and edit-and-continue. I thought it could make prototyping > language changes more easily and visualize usage before writing them > in C. That sounds

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On Sat, Feb 03, 2018 at 12:50:11AM -0500, Terry Reedy wrote: > On 2/2/2018 7:01 PM, asrp asrp wrote: > >I don't know if this is the right place to post this. Please redirect as > >needed. > > This list is for development *of* cpython. Development *with* python in > general belongs on

Re: [Python-Dev] Dataclasses and correct hashability

It appears Eric and I are the only ones in favor of keeping the current behavior. But I still am not convinced by all the worries about "attractive nuisances" and all the other bad names this feature has been called. We don't know that any of the doomsday scenarios will happen. In my experience,

Re: [Python-Dev] Dataclasses and correct hashability

On 3 Feb. 2018 1:09 am, "Eric V. Smith" wrote: The problem with dropping hash=True is: how would you write __hash__ yourself? It seems like a bug magnet if you're adding fields to the class and forget to update __hash__, especially in the presence of per-field hash=False and

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On 2/2/2018 7:01 PM, asrp asrp wrote: I don't know if this is the right place to post this. Please redirect as needed. This list is for development *of* cpython. Development *with* python in general belongs on python-list. -- Terry Jan Reedy

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

Are you aware of pypy? > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of asrp asrp > Sent: Friday, February 2, 2018 7:02 PM > To: python-dev@python.org > Subject: [Python-Dev] A minimal Python interpreter written in

[Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

Hello, I don't know if this is the right place to post this. Please redirect as needed. I've made a small Python interpreter in Python with runtime AST node semantics and edit-and-continue. I thought it could make prototyping language changes more easily and visualize usage before writing them

Re: [Python-Dev] Is object the most base type? (bpo-20285)

On 2/2/2018 1:53 AM, Terry Reedy wrote: >>> object.__doc__ 'The most base type' I and several people on python-list thread "interactive help on the base object" (Dec   2013) thought this could be improved.  On https://bugs.python.org/issue20285 and https://github.com/python/cpython/pull/4759

Re: [Python-Dev] Dataclasses and correct hashability

I agree with Ethan, Elvis, and a few others. I think 'hash=True, frozen=False' should be disabled in 3.7. It's an attractive nuisance. Maybe not so attractive because its obscurity, but still with no clear reason to exist. If many users of of dataclass find themselves defining '__hash__' with

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:09 AM, Eric V. Smith wrote: On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: My point is exactly that there is _no_ valid use case, so (hash=True, frozen=False) should not be a thing! Why are you so insistent on adding a dangerous option which you admit is nearly useless?

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:14 AM, Yury Selivanov wrote: Eric, in my opinion we shouldn't copy attrs. [...] We are designing a new API that is going to be hugely popular. Why can't we ship it with dangerous options prohibited in 3.7 (it's easy to do that!) and then enable them in 3.8 when there's an

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On Fri, Feb 2, 2018 at 12:31 PM, Antoine Pitrou wrote: > On Fri, 2 Feb 2018 16:23:20 +0100 > Christian Heimes wrote: >> Hi, >> >> in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to >> Python's crypt mdodule. I vetoed against addition of

Re: [Python-Dev] Is object the most base type? (bpo-20285)

On 02/02/2018 07:25, Steven D'Aprano wrote: How about: "the base class of the class heirarchy" "the root of the class heirarchy" Java ... now says: "Class Object is the root of the class hierarchy. Every class has Object as a superclass. All objects, including arrays, implement

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On Fri, 2 Feb 2018 16:23:20 +0100 Christian Heimes wrote: > Hi, > > in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to > Python's crypt mdodule. I vetoed against addition of the APIs because > all these hashing algorithms are not state of the art. Their

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On Feb 2, 2018 7:24 AM, "Christian Heimes" wrote: Shortly after the PR has landed, I was made aware that glibc has deprecated crypt(3) API [2] and favor of an external library called libxcrypt [3] from OpenWall Linux. I have patched Python 3.7 [4] to support libxcrypt. In

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 7:38 AM, Elvis Pranskevichus wrote: > On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > > However, I don't feel very strongly about this. As I've said, I expect > > the use cases for hash=True to be very, very rare. > > Why do you think

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2018-01-26 - 2018-02-02) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6411 (-34) closed 38089 (+101) total 44500 (+67) Open issues

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

02.02.18 18:18, Guido van Rossum пише: I'm all for nudging people in the direction of xcrypt. I assume we can't just switch the C-level crypt with xcrypt and leave the Python API unchanged? However until a usable solution exist (either in the stdlib or as 3rd party) I don't think we should

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: I was specifically talking about the case of a non-frozen, hashable class. If you want to make a class frozen and hashable, then: @dataclass(frozen=True) will do just that. The

Re: [Python-Dev] Dataclasses and correct hashability

> Because it's not the default, it will be documented as being an > advanced use case, and it's useful in rare instances. > > And as I've said a number of times, both here and in other > discussions, I'm not arguing strenuously for this. I just think that, > given that it's not the default and

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

I'm all for nudging people in the direction of xcrypt. I assume we can't just switch the C-level crypt with xcrypt and leave the Python API unchanged? However until a usable solution exist (either in the stdlib or as 3rd party) I don't think we should deprecate anything (deprecating things before

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 10:51 AM, Paul Moore wrote: [..] > To put it another way, using your words above, "The moment you want to > use a dataclass a a dict key, or put it in a set, you need it to be > *immutable*" (not hashable, unless you really know what you're doing). Can

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: > I was specifically talking about the case of a non-frozen, hashable > class. If you want to make a class frozen and hashable, then: > > @dataclass(frozen=True) > > will do just that. > > The case you brought up initially is the

Re: [Python-Dev] Dataclasses and correct hashability

On 2 February 2018 at 15:38, Elvis Pranskevichus wrote: > On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: >> However, I don't feel very strongly about this. As I've said, I expect >> the use cases for hash=True to be very, very rare. > > Why do you think that

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:38 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: However, I don't feel very strongly about this. As I've said, I expect the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > However, I don't feel very strongly about this. As I've said, I expect > the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass hashable is a "very, very rare" requirement?

Re: [Python-Dev] Is object the most base type? (bpo-20285)

On Feb 2, 2018, at 02:25, Steven D'Aprano wrote: > > On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote: > object.__doc__ >> 'The most base type’ Clearly that’s a typo. It should be: “The most bass type” as in: "It all starts with the bass, the most important

[Python-Dev] Deprecate crypt module and revert PR 3854

Hi, in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to Python's crypt mdodule. I vetoed against addition of the APIs because all these hashing algorithms are not state of the art. Their quality ranges from old to horribly, horriblye broken beyond any repair. Shortly after the PR

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 12:33 AM, Nick Coghlan wrote: For 3.7, I think we should seriously considered just straight up disallowing the "hash=True, frozen=False" combination, and instead require folks to provide their own hash function in that case. "Accidentally hashable" (whether by identity or field

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 12:33:04 AM EST Nick Coghlan wrote: > For 3.7, I think we should seriously considered just straight up > disallowing the "hash=True, frozen=False" combination, and instead > require folks to provide their own hash function in that case. > "Accidentally hashable"

Re: [Python-Dev] Is object the most base type? (bpo-20285)

> On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote: >> >>> object.__doc__ >> 'The most base type' > [...] >> I have suggested >> "The superclass for all Python classes." >> "The starting base class of all types and classes other than itself." >> >> I intended to pick the second, but