Re: [Python-Dev] This isn't a question
While I'm a part of the community, that wasn't always the case and it's very large, so I'll take this opportunity to come in and say a big thank you as well! From: br...@python.org Date: Tue, 10 Nov 2015 18:09:37 + To: a.r.ka...@gmail.com; python-dev@python.org Subject: Re: [Python-Dev] This isn't a question You're quite welcome! And thanks for taking the time to say "thanks". :) On Tue, 10 Nov 2015, 11:35 Alec Kaija wrote: Sorry to bother anyone, but I just wanted to thank the Python community for being awesome and for all of the ways you have all inspired/supported me (mostly without even knowing it). Thanks! a ___ 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/brett%40python.org ___ 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/vgr255%40live.ca ___ 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] Help with a book
As someone who plays around a *lot* with descriptors, I would be interested in reviewing it. I may not have the same knowledge as a core developer, but I can still help. Date: Wed, 25 Nov 2015 14:31:09 -0600 From: sad2proj...@gmail.com To: python-dev@python.org Subject: [Python-Dev] Help with a book Hello Python Developers! I'm writing a book about descriptors, and I'm hoping to make it a comprehensive guide, covering just about everything there is to know about descriptors, including many tips to get past certain knowledge barriers and how to avoid certain pitfalls. I'm hoping for it to become the definitive guide for those who want to really understand descriptors. Raymond's Descriptor HowTo Guide is great, but focused. I want to expand on what that guide teaches. Anyway, I am currently reading through my initial rough draft and making corrections for a revised draft. Once I'm done with that, I'd like a few volunteers to read through it. First, to find spelling, grammatical, or consistency mistakes, though those should be few in number, but also to give input as to whether something seems too repetitive, if some more information should be given in a spot, and if I'm even blatantly wrong about anything (hopefully not). Anyone who helps will be able to receive a free ebook of the final copy as well as mention in the Special Thanks. I appreciate any help anyone can give to assist in making this book as great as it can be. Thanks,Jacob Zimmerman Twitter: @jacobz_20Blog: http://programmingideaswithjake.wordpress.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] Deleting with setting C API functions
> From: victor.stin...@gmail.com > Date: Wed, 2 Dec 2015 15:46:37 +0100 > To: random...@fastmail.com > Subject: Re: [Python-Dev] Deleting with setting C API functions > CC: python-dev@python.org > > 2015-12-02 15:40 GMT+01:00 Random832 : > > Are there plans for a Python 4? > > No. Don't. Don't schedule any "removal" or *any* kind of "break > backward compatibility" anymore, or you will definetly kill the Python > community. Nick Coghlan made a pretty elaborated blog post about that here: http://opensource.com/life/14/9/why-python-4-wont-be-python-3 ___ 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] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
From: gu...@python.org Date: Sun, 20 Dec 2015 14:33:46 -0800 To: ros...@gmail.com Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) CC: python-dev@python.org > I'm just curious on the backward compatibility impact. I'm just curious on the number of programs depending on the repr() of any object at all in production (not counting tests). I could be wrong, but it seems foolish to rely on that, especially since this is something that we *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to aid the programmer - not specifying keyword arguments here does quite the opposite of that :) > > -- > --Guido van Rossum (python.org/~guido) -Emanuel ___ 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/vgr255%40live.ca ___ 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] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
Half-rhetorical half-genuine; you know better than me the history of breakage due to such changes, anyway. I can't really think of anything you haven't, so I'll just sit back. From: gu...@python.org Date: Sun, 20 Dec 2015 15:15:25 -0800 Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) To: vgr...@live.ca CC: ros...@gmail.com; python-dev@python.org On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry wrote: From: gu...@python.org > I'm just curious on the backward compatibility impact. I'm just curious on the number of programs depending on the repr() of any object at all in production (not counting tests). I could be wrong, but it seems foolish to rely on that, especially since this is something that we *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to aid the programmer - not specifying keyword arguments here does quite the opposite of that :) Not sure if you meant that as a rhetorical question or sarcastically. While you're right that ideally changing the repr() of an object shouldn't affect production work, in practice it can break any number of things, for example over-specified unit tests or poor integrations that end up parsing the string (perhaps in a different language than Python). We've encountered such issues many times in the past (for example, massive doctest breakage when we randomized the string hash) so we have to at least consider the possibility. In this case I expect there will be little effect, but it doesn't hurt asking around -- who knows what someone reading this remembers (besides asking pedantic questions :-). -- --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] Proposal: explicitly disallow function/class mismatches in accelerator modules
Hello all, and thanks Nick for starting the discussion! Long wall of text ahead, whoops! TL;DR - everyone seems to agree, let's do it. I think the main issue that we're hitting is that we (whatever you want "we" to mean) prefer to make Python code in the standard library as easily understandable and readable as possible (a point Raymond raised in the issue, which could be a discussion on its own too, but I won't get into that). People new to Python will sometimes look into the code to try and understand how it works, while only contributors and core devs (read: people who know C) will look at the C code, so keeping the code simple isn't as baked in the design as the Python versions. As such, making closures might be TOOWTDI in Python, but it can quickly become annoying to reimplement in C - either you hide away some of the implementation details behind C level variables and pretend like you're a closure, or you change the Python version to something else. It's much less consequential to change a closure into a class than it is to change a class into a function. In this particular case, we lose the descriptorness(?) of the Python version, but I'd rather think of this as fixing a bug rather than removing a feature, especially when partialmethod literally lies right below in the source. (Side-note: I noticed the source says "Purely functional, no descriptor behaviour" but functions exhibit descriptor behaviour) I think the change is worth it (well, there'd be a problem if I didn't ;), but I'm much more concerned about ensuring that: - Someone at some point finding a bunch of bugs^Wdiscrepancies between the Python and C versions of a feature to have some concise rules on the changes they can and cannot make; - Python implementation of existing C features, of C implementations of existing Python features to know exactly the liberty they can and cannot take; - New features implemented both in C and Python, to know offhand their limits and make sure someone further down the line doesn't have to fix it when they realize e.g. PyPy behaves differently. > On Saturday, July 09, 2016 8:16 PM, Nick Coghlan wrote: > > That's the proposed policy change and the reason I figured it needed a > python-dev discussion, as currently it's up to folks adding the Python > equivalents (or the C accelerators) to decide on a case by case basis > whether or not to care about compatibility for: > > - string representations > - pickling (and hence multiprocessing support) > - subclassing > - isinstance checks > - descriptor behaviour That's quite an exhaustive list for "let the person making the patch decide what to do with that;" quite the more reason to make this concise (also see my reply to Brett below). > The main way for such discrepancies to arise is for the Python > implementation to be a function (or closure), while the C > implementation is a custom stateful callable. Maybe closures are "too complicated" to be a proper design if something is to be written in both Python and C ;) > The problem with the current "those are just technical implementation > details" approach is that a lot of Pythonistas learn standard library > API behaviour and capabilities through a mix of experimentation and > introspection rather than reading the documentation, so if CPython > uses the accelerated version by default, then most folks aren't going > to notice the discrepancies until they (or their users) are trying to > debug a problem like "my library works fine in CPython, but breaks > when used with multiprocessing on PyPy" or "my doctests fail when > running under MicroPython". I noticed that Python's standard library takes a very "duck-typed" approach to the accelerator modules: "I have this thing which is a function, and I [expose it as a global/use it privately], but before I do so, let's see if there's something with the same name in that other module, then use it." In practice, this doesn't create much of an issue, except this thread exists. (I'm not proposing to change how accelerator modules are handled, merely pointing out that making designs identical was never a hard requirement and depended on the developer(s)) > One example of a practical consequence of the change in policy would > be to say that if you don't want to support subclassing, then don't > give the *type* a public name - hide it behind a factory function [...] It's a mixed bag though. How do you disallow subclassing but still allow isinstance() checks? Now let's try it in Python and without metaclasses, and the documented vs undocumented (and unguaranteed) API differences become much more important. But you have to be a consenting adult if you're working your way around the rules, so there's that I guess. > On Saturday, July 09, 2016 9:16 PM, Brett Cannon wrote: > I think flat-out prohibiting won't work in the Python -> C case as you can do things such as closures and such that I don't know if we provide the APIs to mimic through the C API. I'm fine saying
Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules
Hello,
> From: Steven D'Aprano
> Sent: Monday, July 11, 2016 9:11 AM
>
> This isn't an actual problem that occurred in real code, it's a
> theoretical issue that Emanuel discovered, and by his own admission
> feels that he was doing something dubious ("It may not be the best idea
> to subclass something that is meant to be final" -- ya think?). Raymond
> Hettinger makes some good points about the costs of feature creep needed
> to support these accidental implementation features, and is against it.
Yes, this hasn't actually happened; hypothetic bugs make for the best
discussions though ;)
> But on the other hand, Serhiy also makes some good points about the
> usefulness of pickling partial objects. So as far as this *specific*
> issue goes, perhaps it is justified to make sure the Python
> implementation supports pickling.
>
> But generalising this to all possibly mismatches between a C class
> implementation and a Python function implementation doesn't necessarily
> follow. Raymond's general point about simplicity versus feature creep
> still stands, even if in this case adding pickling is useful.
I'm not sure about feature creep in this particular case; pickling for
instance is no accident, even if it's not documented. Is there a particular
stance on non-accidental, undocumented features (if that makes any sense)?
> [1] If I'm wrong about this, and these features are supported, then
> Emanuel has found a hole in the functools test suite and a weakness in
> our testing: it's too hard to ensure that *both* the Python and C code
> is tested.
As far as tests go, there's a large common set of tests for either version
(which is the entirety of the Python version's tests), and the C version
extends those with the tests for repr(), pickling and copying, and does all
the tests again for a subclass. This probably doesn't mean much as far as
guaranteed API is concerned, but it does mean that it's (at least
internally) supported.
-Emanuel
___
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] Deprecating invalid escape sequences: review request
Hello Python-dev, some time ago I went ahead and implemented a patch to deprecate the invalid escape sequences (e.g. \c, \g, \h, etc.) in str and bytes literals. The change itself is pretty straightforward, and shouldn't be hard to review. The change was split in two patches; one which does the actual deprecation and adds relevant tests, and the other fixes all invalid escape sequences in the entire CPython distribution (this resulted in a substantial patch file of over 2000 lines). I'd like to get this reviewed and merged in time, so I'm asking here. Thanks in advance! http://bugs.python.org/issue27364 -Emanuel ___ 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] Commits to migrated repos no longer sent to Python-checkins
The repos which used to send to Python-checkins no longer do so since their respective migrations (devguide, peps). I don't know who's responsible for that, so I figured I'd post here. -Emanuel ___ 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] Commits to migrated repos no longer sent to Python-checkins
Fair enough. I never really bothered to set up any complicated design to get commits, and my emails all get automatically sorted into folders so it doesn’t matter which list it goes to. Although now that you mention it, I could simply subscribe to the GitHub repos and get the notifications for free :) -Emanuel From: Brett Cannon [mailto:br...@python.org] Sent: Wednesday, September 07, 2016 5:40 PM To: Emanuel Barry; python-dev@python.org Subject: Re: [Python-Dev] Commits to migrated repos no longer sent to Python-checkins On Wed, 7 Sep 2016 at 14:24 Emanuel Barry mailto:vgr...@live.ca>> wrote: The repos which used to send to Python-checkins no longer do so since their respective migrations (devguide, peps). I don't know who's responsible for that, so I figured I'd post here. If people want those back on then that could be arranged. I'm not sure, though, if it still makes sense having emails for every commit from three separate repositories going to the same mailing list. You can follow the commits through an atom feed, e.g https://github.com/python/peps/commits.atom. That means you could use something like IFTTT on your own to send you an email for each commit so you can track only the repositories you care about. That makes me think that it's worth even less for peps since those all have to be posted here anyway and the devguide doesn't affect people's future production deployments. ___ 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] single dispatch for instance methods
Just one reply seems pretty weak of a push. However, you lose nothing by submitting it on the issue tracker: https://bugs.python.org I don’t have a use case for this myself, but we’ll see :) -Emanuel From: Python-Dev [mailto:python-dev-bounces+vgr255=live...@python.org] On Behalf Of Tim Mitchell Sent: Thursday, October 13, 2016 9:11 PM To: python-dev@python.org Subject: [Python-Dev] single dispatch for instance methods Hi All, It would be nice if the @singledispatch decorator worked on instance methods. I have a reference implementation on pypi that does this (https://pypi.python.org/pypi/methoddispatch). I posted this message to python ideas a month ago (https://mail.python.org/pipermail/python-ideas/2016-September/042466.html) and got 100% support from 1 response. Not sure if I should proceed with writing a PEP. I am happy to do all the work if I know it will be accepted. Cheers Tim ___ 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
