[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

Am 27.03.22 um 18:11 schrieb Christopher Barker: On Sun, Mar 27, 2022 at 3:08 AM Paul Moore wrote: > > 3. Overall, I think the days where "battery included" was a positive argument are over > > I strongly disagree.  Being able to download something and immediately get

[Python-Dev] Re: New PEP website is horrible to read on mobile device

Am 15.03.22 um 19:40 schrieb Zachary Ware: On Tue, Mar 15, 2022 at 1:31 PM Nathan Cook wrote: Please make https://peps.python.org/ more responsive to various form factors See attached screenshot from Chrome version 99.0.4844.58 on my Pixel 3aXL running Android 12 I can't reproduce this

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Am 03.02.22 um 22:41 schrieb Gregory P. Smith: datapoint: an internal code search turns up blender, multidict, and typed_ast as open source users of _Py_IDENTIFIER .  Easy to clean up as PRs.  There are a couple of internal uses as well, all of which are similarly easy to address and are only

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

Am 01.02.22 um 01:31 schrieb Nikita Sobolev: Hi, my name is Nikita and I think that I am the person behind these spammy PRs. Link: https://github.com/python/cpython/pulls/sobolevn As a typeshed maintainer, Nikita also "spams" typeshed with PRs. I highly appreciate those PRs, which I am sure

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

Am 18.01.22 um 22:57 schrieb Victor Stinner: At the end of my first email, I also suggest thinking about incompatible changes differently, try to make affected projects compatible in advance. The problem are not the changes themselves, but how they are introduced in Python, and more globally how

[Python-Dev] Re: The current state of typing PEPs

Am 01.12.21 um 13:36 schrieb Paul Moore: On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau wrote: Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file

[Python-Dev] Re: The current state of typing PEPs

Am 30.11.21 um 13:39 schrieb Oscar Benjamin: Others have mentioned the pressure on libraries to adopt typing and I've certainly noticed this with SymPy. I think type hints could be good for SymPy for internal use but it seems that a lot of users want it for external reasons that I don't always

[Python-Dev] Re: The current state of typing PEPs

Am 26.11.21 um 01:48 schrieb Rob Cliffe via Python-Dev: ISTM that typing/annotations have been allowed to drift without a clear end in view, rather like a ship that is steered in one direction by one person, then in another by someone else, with nobody knowing what the destination port is. I

[Python-Dev] Re: Proposal: Allow non-default after default arguments

Am 09.11.21 um 19:26 schrieb Terry Reedy: The signature of Sebastian's function with honest parameter names is foo(x_or_y, required_y=_NotGiven, /).  It is the 2nd argument, not the first, that is optional, as with range.  If required_y is not given, than x_or_y must be y, and x is given a

[Python-Dev] Re: Proposal: Allow non-default after default arguments

Am 09.11.21 um 13:44 schrieb Petr Viktorin: And for the "encoding" case: IMO, varying the return type based on an optional "encoding" argument" is a holdover from the pre-typing era, when return types were only specified in the documentation -- just like "addch" is a holdover from the days

[Python-Dev] Re: Proposal: Allow non-default after default arguments

Am 09.11.21 um 10:50 schrieb Chris Angelico: On Tue, Nov 9, 2021 at 8:38 PM Sebastian Rittau wrote: Currently, Python doesn't allow non-default arguments after default arguments: >>> def foo(x=None, y): pass File "", line 1 def f

[Python-Dev] Proposal: Allow non-default after default arguments

Currently, Python doesn't allow non-default arguments after default arguments: >>> def foo(x=None, y): pass   File "", line 1     def foo(x=None, y): pass ^ SyntaxError: non-default argument follows default argument I believe that at the time this was introduced, no use

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

I'm sorry, I sent my last mail too early. Here are the rest of my thoughts. Am 20.10.21 um 15:18 schrieb Thomas Wouters: Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

Am 20.10.21 um 15:18 schrieb Thomas Wouters: By and large, the SC views PEP 649 as a better way forward. If PEP 563 had never come along, it would be a fairly easy decision to accept PEP 649. We are still inclined to accept PEP 649. That would leave the consideration about what to do with

[Python-Dev] Re: Roundup to GitHub Issues migration

(For some weird reason, I didn't get this mail via the list, only the private copy, so I might break threading by replying via my private copy.) Am 22.06.21 um 14:01 schrieb Nathaniel Smith: As much as we might wish otherwise, the PSF is also a US entity and has to comply with US laws.

[Python-Dev] Re: Roundup to GitHub Issues migration

Am 22.06.21 um 10:00 schrieb Tiziano Zito: I think it is important to notice that GitHub actively blocks user registration and activity from countries that are sanctioned by the US government. At least in 2019 GitHub was blocking users from IPs located in Cuba, North Corea, Syria, Crimea,

[Python-Dev] Re: Proposal: declare "unstable APIs"

Am 03.06.21 um 20:11 schrieb Gregory P. Smith: The ideal way to declare an API as unstable is to constantly change it in a breaking manner.  With every release and potentially even within some patch releases when the point really needs to be made.  Even when you didn't have a reason to change

[Python-Dev] Re: Origins of iterators and iterables

Am 30.05.21 um 19:08 schrieb Guido van Rossum: Returning "self" as the iterator was originally only intended to paper over the case where you want to write it = iter(a) for x in it:     ... -- basically we wanted 'for x in iter(a)' and 'for x in a' to have the same meaning. The above use

[Python-Dev] Re: Keeping Python a Duck Typed Language.

Am 24.04.2021 um 01:26 schrieb Gregory P. Smith: Practically speaking, one issue I have is how easy it is to write isinstance or issubclass checks. It has historically been much more difficult to write and maintain a check that something looks like a duck.  `if hasattr(foo, 'close') and

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

Am 23.04.21 um 17:38 schrieb Nathaniel Smith: I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list

[Python-Dev] Re: Keeping Python a Duck Typed Language.

Am 22.04.21 um 10:42 schrieb Chris Angelico: File-like objects are used VERY frequently in the stdlib, and actual open file objects have quite a large interface. The use-case is a pretty real one: "if I were to create a simulant file object to pass to json.load(), what methods do I need?".

[Python-Dev] Re: Keeping Python a Duck Typed Language.

Am 20.04.2021 um 19:03 schrieb Mark Shannon: PEP 544 supports structural typing, but to declare a structural type you must inherit from Protocol. That smells a lot like nominal typing to me. I'm not sure what inheriting from Protocol has to do with nominal typing, even though I would

[Python-Dev] Re: Relaxing the annotation syntax

On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw > wrote: [snip] This is something the SC has been musing about, but as it’s not a fully formed idea, I’m a little hesitant to bring it up.  That said, it’s somewhat relevant: We wonder if it may be time to in a

[Python-Dev] Re: Typing syntax and ecosystem

Am 16.04.21 um 03:21 schrieb Barry Warsaw: Actually, I think it’s time for a comprehensive guide to type annotations. Just anecdotally, I was trying to annotate a library of mine and was having an impossible time of it, until a chat with Guido lead me to @typing.overload. That solved my

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Am 26.03.20 um 06:28 schrieb Cameron Simpson: On 24Mar2020 18:49, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". I

[Python-Dev] Re: python3 -bb and hash collisions

Am 11.09.19 um 15:34 schrieb Daniel Holth: It's different. One hint is that there's already an option to disable the feature. The old style of error will occasionally reveal itself with decode errors but the new style error happens silently, you discover it somehow, then enable the -bb

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

Am 21.05.19 um 13:39 schrieb André Malo: So what I hear is, this battery is definitely not dead, which is what the PEP is all about. it's just half charged (or discharged, depending on your POV), so to speak. Substitute: "none" should read pypi then? Every single module on this list will

Re: [Python-Dev] Remove tempfile.mktemp()

Am 20.03.19 um 09:47 schrieb Anders Munch: Greg Ewing: So use NamedTemporaryFile(delete = False) and close it before passing it to the other program. That's effectively the same as calling tempfile.mktemp. While it does waste time opening and closing an unused file, that doesn't help with

Re: [Python-Dev] Remove tempfile.mktemp()

Am 19.03.19 um 17:23 schrieb Giampaolo Rodola': @Sebastian If there are valid use cases for mktemp(), I recommend renaming it to mkname_unsafe() or something equally obvious. I'm -1 about adding an alias (there should be one and preferably only one way to do it). Also mkstemp() and mkdtemp()

Re: [Python-Dev] Remove tempfile.mktemp()

Am 19.03.19 um 14:53 schrieb Victor Stinner: When I write tests, I don't really care of security, but NamedTemporaryFile caused me many troubles on Windows: you cannot delete a file if it's still open in a another program. It's way more convenient to use tempfile.mktemp(). O_EXCL,

Re: [Python-Dev] Question about PEP 484

On 17.07.2018 17:05, Guido van Rossum wrote: This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps

Re: [Python-Dev] Question about PEP 484

On 16.07.2018 19:21, Adam Cataldo via Python-Dev wrote: * * One thing we care about in particular, given the implementation of pytype, is the detailed definition of what goes in a .pyi file. Do folks think this makes sense to include as part of PEP 484, or would this be better

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns with *args and **kwargs. I think we need to find a

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From what I understand, we are suppos

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 25.11.2017 22:06, Eric V. Smith wrote: The updated version should show up at https://www.python.org/dev/peps/pep-0557/ shortly. This PEP looks very promising and will make my life quite a bit easier, since we are using a pattern involving data classes. Currently, we write the constructor

Re: [Python-Dev] PEP 561 rework

Am 14.11.2017 um 02:38 schrieb Guido van Rossum: On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau <srit...@rittau.biz <mailto:srit...@rittau.biz>> wrote: I am really looking forward to the implementation of this PEP and I am glad that it is close to acceptanc

Re: [Python-Dev] PEP 561 rework

Hello everyone, Am 14.11.2017 um 00:29 schrieb Guido van Rossum: This is a nice piece of work. I expect to accept it pretty much verbatim (with some small edits, see https://github.com/python/peps/pull/467). I agree with Nick that we don't have to do anything specifically about control of

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sun, Jan 31, 2010 at 12:44:33PM +0100, Georg Brandl wrote: At least to me, this does not explain why an unwanted (why unwanted? If it's unwanted, set PYTHONDONTWRITEBYTECODE=1) directory is worse than an unwanted file. A directory feels different than. For example, typing ls in my shell

Re: [Python-Dev] conceptual clarity

On Thu, Sep 17, 2009 at 02:04:11PM -0400, R. David Murray wrote: I mean, eg, IPv4Network.fromHostIP('192.168.1.1/24'). I'd actually suggest to use net, host = parse_network_and_host(192.168.111.33/24) (IPv4Network('192.168.111.0/24'), IPv4Address('192.168.111.33')) I think this helps

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 01:16:06PM -0400, Scott Dial wrote: I have to concur with the opinions above. I was very confused by the following error: addr = ipaddr.IPAddress(10.1.2.3/255.255.240.0) ... ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not a valid address

Re: [Python-Dev] Duck-typing self

On Wed, Feb 18, 2009 at 11:32:09PM +0100, Sebastian Rittau wrote: I am curious why the following will not work in Python: class foo(object): def bar(self): print self.attr class duck(object): attr = 3.14 foo.bar(duck()) Thanks to everybody who

[Python-Dev] Duck-typing self

Hi! I am curious why the following will not work in Python: class foo(object): def bar(self): print self.attr class duck(object): attr = 3.14 foo.bar(duck()) Is it a design decision that duck-typing self does not work or is there a technical reason?

[Python-Dev] unittest Suggestions

[I just saw the other post about unit testing, while I was writing this. A strange conincidence.] Hello, since this is the first time I post to this list, I'd like to introduce myself briefly. As you can see my name is Sebastian. I am working as a software developer both as a professional and as