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 in
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 python-lis
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, us
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 eq=False settings. A
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
___
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 Pytho
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
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
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
mut
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?
B
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 a
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 the APIs because
>> all these hashing algorit
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 the
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 quality
> ranges from old to
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 light of deprecation of
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 that the requirement
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 w
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 de
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 ca
> 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 it'
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
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 someone clarify what
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 n
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 the requirement to ma
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
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? T
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 part of any band or c
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 ha
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 hash)
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" (whethe
> 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 Serh
31 matches
Mail list logo