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

[Martin Panter]

> 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 Serhiy Storchake wants more opinions.

On 2 February 2018 at 07:25, Steven D'Aprano  wrote:
> "the base class of the class heirarchy"
>
> "the root of the class heirarchy"

The RST documentation

says

Object is a base for all classes.

which is better than “the most base type” IMO, although I would write
_the_ base rather than _a_ base; there is only one object class. In my
patch for the RST documentation in
 I proposed

This is the ultimate base class of all other classes.

which I still think is okay (though other parts of my patch doesn’t
seem very good).
___
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] Dataclasses and correct hashability

[Elvis Pranskevichus]

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" (whether by identity or field hash) isn't a
> thing that data classes should be allowing to happen.
> 
> If we did that, then the public "hash" parameter could potentially
> be dropped entirely for the time being - the replacement for
> "hash=True" would be a "def __hash__: ..." in the body of the class
> definition, and the replacement for "hash=False" would be "__hash__
> = None" in the class body.

I think "frozen=True" should just imply hashability (by fields).  You 
can always do "__hash__ = None" to opt out.  I don't see the default 
hashability of an immutable object as a problem.  tuples and 
frozensets are hashable after all.

   Elvis


___
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] Dataclasses and correct hashability

[Eric V. Smith]

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) isn't a
thing that data classes should be allowing to happen.

If we did that, then the public "hash" parameter could potentially be
dropped entirely for the time being - the replacement for "hash=True"
would be a "def __hash__: ..." in the body of the class definition,
and the replacement for "hash=False" would be "__hash__ = None" in the
class body.


attrs has the same behavior (if you ignore how dataclasses handles the 
cases where __hash__ or __eq__ already exist in the class definition). 
Here's what attrs says about adding __hash__ via hash=True:


"Although not recommended, you can decide for yourself and force attrs 
to create one (e.g. if the class is immutable even though you didn’t 
freeze it programmatically) by passing True or not. Both of these cases 
are rather special and should be used carefully."


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. And you'd need to make sure 
it matches the generated __eq__ (if 2 objects are equal, they need to 
have the same hash value).


If we're going to start disallowing things, how about the per-field 
hash=True, eq=False case?


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. And now that we allow 
overriding __hash__ in the class body without setting hash=False, there 
aren't a lot of uses for hash=False, either. But we would need to think 
through how you'd get the behavior of hash=False with multiple 
inheritance, if that's what you wanted. Again, a very, very rare case.


In all, I think we're better off documenting best practices and making 
them the default, like attrs does, and leave it to the programmer to 
follow them. I realize we're handing out footguns, the alternatives seem 
even more complex and are limiting.


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

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

[Christian Heimes]

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 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 crypt(3) glibc function and bad quality of
hashing algorithms, I'd like to raise the motion to revert 3854 and
deprecate the crypt module. The whole module should be rather moved into
3rd party library that wraps xcrypt.

Regards,
Christian

[1] https://github.com/python/cpython/pull/3854
[2]
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-28-libxcrypt-Plans
[3] https://github.com/besser82/libxcrypt
[4] https://bugs.python.org/issue32635
___
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] Is object the most base type? (bpo-20285)

[Barry Warsaw]

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 class hierarchy.  
Sure, the drums type is very important, and the bass type and drums type work 
hand-in-hand to provide you with a solid funky foundation on which to groove, 
er, code.  Don’t let those guitar types tell you anything else."

> "the base class of the class heirarchy"
> 
> "the root of the class heirarchy"

In all seriousness, either one of those works for me.  While the first one does 
repeat the word “class”, it seems the most clear description of what this thing 
is.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Dataclasses and correct hashability

[Elvis Pranskevichus]

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?  The moment you want to use a dataclass a 
a dict key, or put it in a set, you need it to be hashable.  

Just put yourself in the shoes of an average Python developer.  You try 
to put a dataclass in a set, you get a TypeError.  Your immediate 
reaction is to add "hash=True".  Things appear to work.  Then, you, or 
someone else, decides to mutate the dataclass object and then you are 
looking at a very frustrating debug session.

> In all, I think we're better off documenting best practices and making 
> them the default, like attrs does, and leave it to the programmer to 
> follow them. I realize we're handing out footguns

I don't think attrs doing the same thing is a valid justification.  This 
is a major footgun that is very easy to trigger, and there's really no 
precedent in standard data types.

> the alternatives seem even more complex and are limiting.

The alternative is simple and follows the design of other standard 
containers: immutable containers are hashable, mutable containers are 
not.  @dataclass(frozen=False) gives you a SimpleNamespace-like and 
@dataclass(frozen=True) gives you a namedtuple-like.  If you _really_ 
know what you are doing, then you can always declare an explicit 
__hash__.  

> The problem with dropping hash=True is: how would you write __hash__ 
> yourself?

Is "def __hash__(self): return hash((self.field1, self.field2))" that 
hard?  It is explicit, and you made a concious choice, i.e you 
understand how __hash__ works.  IMO, the danger of 
"@dataclass(hash=True)" far overweighs whatever convenience it might 
provide.

   Elvis
___
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] Dataclasses and correct hashability

[Eric V. Smith]

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 hashable is a
"very, very rare" requirement?  The moment you want to use a dataclass a
a dict key, or put it in a set, you need it to be hashable.


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 non-frozen, hashable class. 
It's that case that I think is very rare. I'll ask again: what's your 
use case for wanting a non-frozen, hashable class? I'm genuinely interested.


You seem to think that hash=True means "make the class hashable". That's 
not true. It means "add a __hash__" to this class". There are other, 
better ways to make the class hashable, specifically frozen=True. You 
might want to read all of https://bugs.python.org/issue32513 for the 
background on the current behavior.



Just put yourself in the shoes of an average Python developer.  You try
to put a dataclass in a set, you get a TypeError.  Your immediate
reaction is to add "hash=True".  Things appear to work.  Then, you, or
someone else, decides to mutate the dataclass object and then you are
looking at a very frustrating debug session.


I will be documented that the correct way to do this is frozen=True.


In all, I think we're better off documenting best practices and making
them the default, like attrs does, and leave it to the programmer to
follow them. I realize we're handing out footguns


I don't think attrs doing the same thing is a valid justification.  This
is a major footgun that is very easy to trigger, and there's really no
precedent in standard data types.


the alternatives seem even more complex and are limiting.


The alternative is simple and follows the design of other standard
containers: immutable containers are hashable, mutable containers are
not.  @dataclass(frozen=False) gives you a SimpleNamespace-like and
@dataclass(frozen=True) gives you a namedtuple-like.  If you _really_
know what you are doing, then you can always declare an explicit
__hash__.


I'm not sure what you're arguing for here. This is how dataclasses work.


The problem with dropping hash=True is: how would you write __hash__
yourself?


Is "def __hash__(self): return hash((self.field1, self.field2))" that
hard?  It is explicit, and you made a concious choice, i.e you
understand how __hash__ works.


I didn't say it was hard, I said it needed to be kept up to date as you 
add fields. That is, you'd have to duplicate the field list. dataclasses 
is trying to prevent you from repeating the field list anywhere.



IMO, the danger of
"@dataclass(hash=True)" far overweighs whatever convenience it might
provide.


We'll just have to disagree about this. As I said, I don't feel very 
strongly about it, but I lean toward leaving it in and documenting it 
for what it is and does.


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

Re: [Python-Dev] Dataclasses and correct hashability

[Paul Moore]

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 make a dataclass hashable is a
> "very, very rare" requirement?  The moment you want to use a dataclass a
> a dict key, or put it in a set, you need it to be hashable.
>
> Just put yourself in the shoes of an average Python developer.  You try
> to put a dataclass in a set, you get a TypeError.  Your immediate
> reaction is to add "hash=True".  Things appear to work.  Then, you, or
> someone else, decides to mutate the dataclass object and then you are
> looking at a very frustrating debug session.

If I saw someone try to put a dataclass into a set, I'd point out that
dataclasses are *mutable*, and if they want immutable values they
should use "frozen=True". If it were me in that situation, that's what
I'd do as well. Adding hashability to a mutable object would *never*
be my immediate reaction.

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).

Paul
___
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] Dataclasses and correct hashability

[Elvis Pranskevichus]

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 non-frozen, hashable class.
> It's that case that I think is very rare. I'll ask again: what's your
> use case for wanting a non-frozen, hashable class? I'm genuinely
> interested.

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?

   Elvis
___
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] Dataclasses and correct hashability

[Yury Selivanov]

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 is the actual use case of someone *knowingly*
making a mutable collection hashable?  Why can't that advanced user
write their own __hash__ implementation?  It's easy to do so.

For what it's worth I think this argument is being blindly used to
justify the current questionable design of "dataclass(hash=True)"
being the same as "dataclass(hash=True, frozen=False) case.  At least
a few other core developers are concerned with this, but all I see is
"attrs does the same thing".

Eric, in my opinion we shouldn't copy attrs.  It was designed as an
external package with its own backwards-compatibility story.  At some
point it was realized that "attrs(hash=True, frozen=False)" is an
anti-pattern, but it couldn't be removed at that point.  Hence the
warning in the documentation.  We can do better.

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 actual clear
use case?

Yury
___
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] Deprecate crypt module and revert PR 3854

[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 deprecate anything (deprecating things
before the replacement is ready is stressful for everyone involved).

I'm also not sure I agree with removing support for old hashes. By all
means put in the docs that they are unsafe. But if someone has a database
full of old hashes it would be nice to be able to at least read/verify it,
right?

Was a release already made with blowfish, extended DES and NT-Hash? (And
what's so bad with blowfish? It's mentioned in the heading of the xcrypt
project too.)

On Fri, Feb 2, 2018 at 7:23 AM, 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 horribly, horriblye broken beyond any repair.
>
> 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 crypt(3) glibc function and bad quality of
> hashing algorithms, I'd like to raise the motion to revert 3854 and
> deprecate the crypt module. The whole module should be rather moved into
> 3rd party library that wraps xcrypt.
>
> Regards,
> Christian
>
> [1] https://github.com/python/cpython/pull/3854
> [2]
> https://www.phoronix.com/scan.php?page=news_item&px=Fedora-
> 28-libxcrypt-Plans
> [3] https://github.com/besser82/libxcrypt
> [4] https://bugs.python.org/issue32635
> ___
> 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/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Dataclasses and correct hashability

[Elvis Pranskevichus]

> 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's not recommended and is
> useful in advanced cases, I would prefer to leave it in. I understand
> that you disagree with me.

Is there a real world example of such an "advanced case"?  

Eric, have you read https://github.com/python-attrs/attrs/issues/136 ?  
Specifically this comment from Hynek [1]: 

"I never really thought about it, but yeah mutable objects shouldn’t 
have a __hash__ at all." 

It is clear from that thread that "hash=True" was an early design 
mistake, which was left in for compatibility reasons.  Why are we 
copying bad design to the standard library?

  Elvis


[1] https://github.com/python-attrs/attrs/issues/
136#issuecomment-277425421
___
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] Dataclasses and correct hashability

[Eric V. Smith]

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 case you brought up initially is the non-frozen, hashable class.
It's that case that I think is very rare. I'll ask again: what's your
use case for wanting a non-frozen, hashable class? I'm genuinely
interested.


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?


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's not recommended and is useful in advanced 
cases, I would prefer to leave it in. I understand that you disagree 
with me.


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

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

[Serhiy Storchaka]

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 deprecate anything (deprecating things 
before the replacement is ready is stressful for everyone involved).


I'm also not sure I agree with removing support for old hashes. By all 
means put in the docs that they are unsafe. But if someone has a 
database full of old hashes it would be nice to be able to at least 
read/verify it, right?


Was a release already made with blowfish, extended DES and NT-Hash? (And 
what's so bad with blowfish? It's mentioned in the heading of the xcrypt 
project too.)


To clarify, extended DES and NT-Hash were not added. They were removed 
from my PR after Christians request. Only the Blowfish method was added, 
and it is so strong as SHA-2 methods. It is the only method supported on 
OpenBSD.


This PR is not a single enhancement made in the crypt module recently. I 
also extended tests and added support for configuring SHA-2 methods. 
There is an open PR (not merged before 3.7b1 unfortunately) for using 
crypt_r() instead of crypt(): https://bugs.python.org/issue28503.


If deprecate the crypt module, should modules pwd, grp and spwd be 
deprecated too? The crypt module is needed for checking password hashes 
provided by spwd.


___
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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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 with patches: 2492 


Issues opened (35)
==

#32221: Converting ipv6 address to string representation using getname
https://bugs.python.org/issue32221  reopened by yselivanov

#32622: Implement loop.sendfile
https://bugs.python.org/issue32622  reopened by vstinner

#32683: isinstance is calling ob.__getattribute__ as a fallback instea
https://bugs.python.org/issue32683  opened by bup

#32684: asyncio.gather(..., return_exceptions=True) swallows cancellat
https://bugs.python.org/issue32684  opened by socketpair

#32689: shutil.move raises AttributeError if first argument is a pathl
https://bugs.python.org/issue32689  opened by craigh

#32691: "pdb -m " sets __main__.__package__ incorrectly
https://bugs.python.org/issue32691  opened by ncoghlan

#32692: test_threading.test_set_and_clear fails in AppVeyor CI
https://bugs.python.org/issue32692  opened by xiang.zhang

#32694: Can no longer specify OpenSSL locations with CPPFLAGS / LDFLAG
https://bugs.python.org/issue32694  opened by yselivanov

#32695: tarfile.open() raises TypeError when using compresslevel param
https://bugs.python.org/issue32695  opened by bbayles

#32696: Fix pickling exceptions with multiple arguments
https://bugs.python.org/issue32696  opened by slallum

#32706: test_check_hostname() of test_ftplib started to fail randomly
https://bugs.python.org/issue32706  opened by vstinner

#32708: test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x buildbo
https://bugs.python.org/issue32708  opened by vstinner

#32710: test_asyncio leaked [4, 4, 3] memory blocks, sum=11 on AMD64 W
https://bugs.python.org/issue32710  opened by vstinner

#32713: tarfile.itn breaks if n is a negative float
https://bugs.python.org/issue32713  opened by j0ffrey

#32715: Make create_unix_server for SOCK_DGRAM work
https://bugs.python.org/issue32715  opened by holger+lp

#32716: setup.py register --repository is broken
https://bugs.python.org/issue32716  opened by shimizukawa

#32717: Document PEP 560
https://bugs.python.org/issue32717  opened by levkivskyi

#32718: Install PowerShell activation scripts for venv for all platfor
https://bugs.python.org/issue32718  opened by brett.cannon

#32719: fatal error raised when Ctrl-C print loop
https://bugs.python.org/issue32719  opened by xiang.zhang

#32720: Format mini-language integer definition is incorrect
https://bugs.python.org/issue32720  opened by ncoghlan

#32723: codecs.open silently ignores argument errors
https://bugs.python.org/issue32723  opened by xiang.zhang

#32725: Instance of _multiprocessing.PipeConnection-subtype crash on d
https://bugs.python.org/issue32725  opened by hakril

#32726: macOS installer and framework enhancements and changes for 3.7
https://bugs.python.org/issue32726  opened by ned.deily

#32728: Extend zipfile's compression level support  to LZMA
https://bugs.python.org/issue32728  opened by bbayles

#32729: socket error handling needed
https://bugs.python.org/issue32729  opened by rkdls

#32730: Allow py launcher to launch other registered Pythons
https://bugs.python.org/issue32730  opened by petsu...@gmail.com

#32731: getpass.getuser() raises an unspecified exceptions (ImportErro
https://bugs.python.org/issue32731  opened by gregory.p.smith

#32732: LoggingAdapter ignores extra kwargs of Logger#log()
https://bugs.python.org/issue32732  opened by mcoolive

#32734: Asyncio Lock safety issue (unlimited acquire)
https://bugs.python.org/issue32734  opened by bar.harel

#32739: collections.deque rotate(n=1) default value not documented
https://bugs.python.org/issue32739  opened by yuy

#32742: zipfile extractall needlessly re-wraps ZipInfo instances
https://bugs.python.org/issue32742  opened by peterbe

#32743: Typo in hamt.c comments
https://bugs.python.org/issue32743  opened by delimitry

#32745: ctypes string pointer fields should accept embedded null chara
https://bugs.python.org/issue32745  opened by theller

#32746: More misspellings, mostly in source code.
https://bugs.python.org/issue32746  opened by terry.reedy

#32749: Remove dbm.dumb behavior deprecated in 3.6
https://bugs.python.org/issue32749  opened by serhiy.storchaka



Most recent 15 issues with no replies (15)
==

#32749: Remove dbm.dumb behavior deprecated in 3.6
https://bugs.python.org/issue32749

#32746: More misspellings, mostly in source code.
https://bugs.python.org/issue32746

#32728: Extend zipfile's compression level support  to LZMA
https://bugs.python.org/issue32728

#32718: Install PowerShell activation scripts for venv for all platfor
https://bugs.python.org/issue32718

#32717: Document PEP 560
https://bugs.python.org/issue32717

#32716: setup.py register --repository

Re: [Python-Dev] Dataclasses and correct hashability

[Chris Barker]

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 to make a dataclass hashable is a
> "very, very rare" requirement?


I think what's rare is wanting hashability without it being frozen.


> Just put yourself in the shoes of an average Python developer.  You try
> to put a dataclass in a set, you get a TypeError.  Your immediate
> reaction is to add "hash=True".  Things appear to work.


agreed, the easy and obvious way should be to make it frozen -- if it's
hard to make it hashable and not frozen, then that's good.

But it is nice to have the __hash__ generated more you so maybe a flag
for "unfrozen_hashable" -- really klunky, but if that is a rare need, then
there you go.

Or maybe:

If either hash or frozen is specified, it become both frozen and hashable.

If both are specified, then it does what the user is asking for.

-CHB
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Deprecate crypt module and revert PR 3854

[Nathaniel Smith]

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 crypt(3) glibc function and bad quality of
hashing algorithms, I'd like to raise the motion to revert 3854 and
deprecate the crypt module. The whole module should be rather moved into
3rd party library that wraps xcrypt.


If the crypt module can just as well use libxcrypt, and that's how the
distros are going to build it, then what's the advantage of deprecating it?
Won't it just continue to work indefinitely?

-n
___
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] Deprecate crypt module and revert PR 3854

[Antoine Pitrou]

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 horribly, horriblye broken beyond any repair.
> 
> 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 crypt(3) glibc function and bad quality of
> hashing algorithms, I'd like to raise the motion to revert 3854 and
> deprecate the crypt module.

Those are two separate proposals.

On the topic of reverting PR #3854, I don't see the point.  Is Blowfish
more fragile than the other algorithms?  If not, it sounds ok to add it.

On the topic of deprecating the crypt module, that doesn't sound like a
good idea right now.  People may need to generate crypt()-compatible
output for various reasons, such as being able to automate system
administration tasks.

Regards

Antoine.


___
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] Is object the most base type? (bpo-20285)

[Jeff Allen]

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
 methods of this class."


Either for me, but I feel I should draw attention to the spelling. (Java 
is right.)


Ironically, the word derives from priesthood (hieratic), not from 
inheritance (heir).


Jeff Allen

___
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] Deprecate crypt module and revert PR 3854

[Dan Stromberg]

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 algorithms are not state of the art. Their quality
>> ranges from old to horribly, horriblye broken beyond any repair.
>>
>> 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 crypt(3) glibc function and bad quality of
>> hashing algorithms, I'd like to raise the motion to revert 3854 and
>> deprecate the crypt module.
>
> Those are two separate proposals.
>
> On the topic of reverting PR #3854, I don't see the point.  Is Blowfish
> more fragile than the other algorithms?  If not, it sounds ok to add it.

I'm no cryptographer, but I believe Blowfish's author recommends using
Twofish instead now.

> On the topic of deprecating the crypt module, that doesn't sound like a
> good idea right now.  People may need to generate crypt()-compatible
> output for various reasons, such as being able to automate system
> administration tasks.

Encryption algorithms continue to be needed even after the time at
which they should no longer be used in new code.  But they probably
should be documented as deprecated and warned about at runtime - after
there are suitable alternatives.
___
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] Dataclasses and correct hashability

[Ethan Furman]

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 actual clear
use case?


+1

--
~Ethan~

___
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] Dataclasses and correct hashability

[Ethan Furman]

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?


Because it's not the default, it will be documented as being an advanced use 
case, and it's useful in rare instances.


Personally, I don't think advanced use-cases need to be supported by flags as they can be supported by just writing the 
__dunder__ methods.


--
~Ethan~
___
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] Dataclasses and correct hashability

[David Mertz]

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
mutable dataclass, it's perfectly possible to allow the switch combination
later. But taking it out after previously allowing it—even if every use in
the wild is actually a bug in waiting—is harder.

On Feb 2, 2018 2:10 PM, "Ethan Furman"  wrote:

> 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?
>>>
>>
>> Because it's not the default, it will be documented as being an advanced
>> use case, and it's useful in rare instances.
>>
>
> Personally, I don't think advanced use-cases need to be supported by flags
> as they can be supported by just writing the __dunder__ methods.
>
> --
> ~Ethan~
> ___
> 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/mertz%
> 40gnosis.cx
>
___
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] Is object the most base type? (bpo-20285)

[Terry Reedy]

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

After some research, I believe the following, which is wrote on the 
issue, explains the uneasiness many feel.


'Base' is actually two words.  As a noun (or verb), it comes from 
Ancient Greek βάσις (básis), a foundation from which other things extend 
or derive.  As an adjective, it comes from Late Latin bassus (“low”).


In computer science and Python, the couplet 'base class' is being used, 
it seems to me and apparently others, as a noun-noun compound, meaning, 
'foundation class', not as an adjective-noun phrase meaning 'low class' 
(let along 'depraved class').  However, 'most base class' must be parsed 
as '(most base) class', with 'base' re-interpreted as the adjective 
meaning 'low' (or worse).  The switch in meaning of 'base' is similar in 
'baseball' versus  'most base ball'.

---

I have suggested
"The superclass for all Python classes."
"The starting base class of all types and classes other than itself."


"a base for all classes." object entry in lib ref, function
"the ultimate base class of all other classes."  Martin Panter

object is neither a base or superclass of itself, so the first of each 
pair above is not quite right.


"the base class of the class heirarchy ['hierarchy']"  Steven D'Aprano
"the root of the class heirarchy"  ditto
+ quotes from Java and Ruby

Jeff Allen and Barry Warsaw like either, with BW slightly referring the 
first.


I was thinking about 'tree' instead of 'hierachy', but 'class tree' is 
wrong and 'directed acyclic graph of classes' a bit wordy.  While 
hierarchies are often thought of as trees, it is possible for someone to 
report to more than one person.


No one (yet) supported the status quo.

Martin also suggested a continuation:  "When called, it accepts no
arguments and returns a new unique and featureless object."

Even though object, unlike any other class, is primarily used as a base 
class rather than instance source, the latter should be included.  For 
other built-in classes, the summary line describes instances. I would 
leave out 'unique' as that could be confused with 'singleton'.


Provisional replacement, following the format of other class docstrings 
except for describing the class instead of instances, and intended to be 
helpful to beginners.


"The base class of the class hierarchy.

When called, it accepts no arguments and returns a new featureless 
instance that has no instance attributes and cannot be given any."


Passing arguments and adding attributes are two common mistakes.


--
Terry Jan Reedy


___
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

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

[asrp asrp]

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 in C.

Its here: https://github.com/asrp/python_terp

So, for example, redefining the for_stmt function in the right scope changes 
the behaviour of future for loops at runtime.

Although from discussion I've read in PEPs, actual implementation always look 
like a non-issue (which seems like magic to me) so maybe no-one here actually 
needs this.

(I really needed edit-and-continue for one of my projects but of course, 
running it in this extra interpreter is much too slow.)

asrp
___
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] A minimal Python interpreter written in Python for experimenting with language changes

[Alex Walters]

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 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 in C.
> 
> Its here: https://github.com/asrp/python_terp
> 
> So, for example, redefining the for_stmt function in the right scope
changes
> the behaviour of future for loops at runtime.
> 
> Although from discussion I've read in PEPs, actual implementation always
> look like a non-issue (which seems like magic to me) so maybe no-one here
> actually needs this.
> 
> (I really needed edit-and-continue for one of my projects but of course,
> running it in this extra interpreter is much too slow.)
> 
> asrp
> ___
> 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/tritium-
> list%40sdamon.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] A minimal Python interpreter written in Python for experimenting with language changes

[Terry Reedy]

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

___
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] Dataclasses and correct hashability

[Nick Coghlan]

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. And you'd need to make sure it matches
the generated __eq__ (if 2 objects are equal, they need to have the same
hash value).


I think anyone that does this needs to think *very* carefully about how
they do it, and offering both "hash=True" and "frozen=True" is an
attractive nuisance that means people will write "hash=True" when what they
wanted was "frozen=True".

In particular, having to work out how write a maintainable "__hash__" will
encourage folks to separate out the hashed fields as a separate frozen
subrecord or base class.

If this proves to be an intolerable burden then the short hand spelling
could be added back in 3.8, but once we ship it we're going to be stuck
with explaining the interactions indefinitely.

Cheers,
Nick.
___
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] Dataclasses and correct hashability

[Guido van Rossum]

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, usually once something is rolled out the set of issues that are
*actually* raised is entirely different from the things its designers were
worried about.

Please don't commit a change to roll this back without checking in with me;
I have some misgivings about the problem being raised here that I still
need to think through more carefully. In the meantime, please try to use
dataclasses with 3.7b1!

On Fri, Feb 2, 2018 at 10:25 PM, Nick Coghlan  wrote:

>
>
> 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. And you'd need to make sure it matches
> the generated __eq__ (if 2 objects are equal, they need to have the same
> hash value).
>
>
> I think anyone that does this needs to think *very* carefully about how
> they do it, and offering both "hash=True" and "frozen=True" is an
> attractive nuisance that means people will write "hash=True" when what they
> wanted was "frozen=True".
>
> In particular, having to work out how write a maintainable "__hash__" will
> encourage folks to separate out the hashed fields as a separate frozen
> subrecord or base class.
>
> If this proves to be an intolerable burden then the short hand spelling
> could be added back in 3.8, but once we ship it we're going to be stuck
> with explaining the interactions indefinitely.
>
> Cheers,
> Nick.
>
> ___
> 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/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] A minimal Python interpreter written in Python for experimenting with language changes

[Steven D'Aprano]

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-list.

This list is for development of Python the language, not just CPython 
the interpreter. It seems to me that announcing a new Python 
interpreter, especially one designed for the purpose of allowing rapid 
experimentation with the language, is on topic for this list.


-- 
Steve
___
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] A minimal Python interpreter written in Python for experimenting with language changes

[Steven D'Aprano]

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 interesting.


> Its here: https://github.com/asrp/python_terp
> 
> So, for example, redefining the for_stmt function in the right scope 
> changes the behaviour of future for loops at runtime.

Can you give an example of how you would do that? I don't mean the 
mechanism used, I mean how would a developer implement a new syntactic 
feature. Suppose I wanted to add a new clause to for...else, let's say:

for ... :
   block
otherwise:
   # runs only if the for-loop was empty

How would do I do that?

(I've read the example on your github page, and it doesn't have much 
detail.)



-- 
Steve
___
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