Re: [Python-Dev] semantics of subclassing things from itertools
On Fri, Sep 11, 2015 at 1:48 AM, Raymond Hettinger wrote: > >> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski wrote: >> >> I would like to know what are the semantics if you subclass something >> from itertools (e.g. islice). >> >> Right now it's allowed and people do it, which is why the >> documentation is incorrect. It states "equivalent to: a function-or a >> generator", but you can't subclass whatever it is equivalent to, which >> is why in PyPy we're unable to make it work in pure python. >> >> I would like some clarification on that. > > The docs should say "roughly equivalent to" not "exactly equivalent to". > The intended purpose of the examples in the itertools docs is to use > pure python code to help people better understand each tool. It is not > is intended to dictate that tool x is a generator or is a function. > > The intended semantics are that the itertools are classes (not functions > and not generators). They are intended to be sub-classable (that is > why they have Py_TPFLAGS_BASETYPE defined). Ok, so what's completely missing from the documentation is what *are* the semantics of subclasses of those classes? Can you override any magic methods? Can you override next (which is or isn't a magic method depending how you look)? Etc. The documentation on this is completely missing and it's left guessing with "whatever cpython happens to be doing". ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement
In a message of Sat, 12 Sep 2015 20:49:12 -0400, Terry Reedy writes: >and, if we are stuck with <-intransitivity, what do we do? If >back-compatibility allowed, I might suggest defining 'lt' or 'less' >rather than '__lt__' so that sort and bisect don't work with DateTimes. >Then document that the function is not transitive. I think it would be better to document what you are supposed to do if you have a list of DateTimes and want to sort them, as a way to get a list of times sorted from the earliest to the latest. Laura ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows x86-64 embeddable zip file, Feedback
Hi, had some time to test the new distributed stuff for Windows especially the embeddable zip. Thanks for this special distribution, it is very useful to generate standalone Python distributions and software based on Python. Very good work. I detected two minor issues only affecting size, opened tickets for them: http://bugs.python.org/issue25085 Windows x86-64 embeddable zip file contains test directorys http://bugs.python.org/issue25086 Windows x86-64 embeddable zip file, lot of big EXE files in distuils Think this can be an improvement in size, targeting for Python 3.5.1. Regards, Wolfgang ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.5.0 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm proud to announce the availability of Python 3.5.0. Python 3.5.0 is the newest version of the Python language, and it contains many exciting new features and optimizations. You can read all about what's new in Python 3.5.0 here: https://docs.python.org/3.5/whatsnew/3.5.html And you can download Python 3.5.0 here: https://www.python.org/downloads/release/python-350/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. We hope you enjoy Python 3.5.0! //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement
On Sun, Sep 13, 2015 at 7:03 PM, Laura Creighton wrote: > In a message of Sat, 12 Sep 2015 20:49:12 -0400, Terry Reedy writes: >>and, if we are stuck with <-intransitivity, what do we do? If >>back-compatibility allowed, I might suggest defining 'lt' or 'less' >>rather than '__lt__' so that sort and bisect don't work with DateTimes. >>Then document that the function is not transitive. > > I think it would be better to document what you are supposed to > do if you have a list of DateTimes and want to sort them, as a > way to get a list of times sorted from the earliest to the latest. What I'd like to hear (but maybe this won't be possible) would be "less-than is transitive if and only if ", where might be something like "all of the datetimes are in the same timezone" or "none of the datetimes fall within a fold" or something. That would at least make sorting possible, but maybe with a first-pass check to ensure transitivity. Vain hope or plausible restriction? ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement
[Chris Angelico ] > What I'd like to hear (but maybe this won't be possible) would be > "less-than is transitive if and only if ", where might be > something like "all of the datetimes are in the same timezone" or > "none of the datetimes fall within a fold" or something. That would at > least make sorting possible, but maybe with a first-pass check to > ensure transitivity. > > Vain hope or plausible restriction? Pragmatically, if someone needs to care about sorting aware datetimes that may include times in folds, the obvious way is to convert them to UTC first (which can be done with sort's `key=` argument). Times in UTC are totally ordered (essentially the same as working with integers). That's a sane & easy sufficient condition. It's a waste of time to worry about minimal necessary conditions. "Convert to UTC' is the obvious way to do darned near everything. Converting to any other fixed-offset zone would do just as well, but _that_ observation is also a waste of time, since "convert to UTC" is just as easy ;-) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] semantics of subclassing things from itertools
> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski wrote: > >> The intended semantics are that the itertools are classes (not functions >> and not generators). They are intended to be sub-classable (that is >> why they have Py_TPFLAGS_BASETYPE defined). > > Ok, so what's completely missing from the documentation is what *are* > the semantics of subclasses of those classes? Can you override any > magic methods? Can you override next (which is or isn't a magic method > depending how you look)? Etc. > > The documentation on this is completely missing and it's left guessing > with "whatever cpython happens to be doing". The reason it is underspecified is that this avenue of development was never explored (not thought about, planned, used, tested, or documented). IIRC, the entire decision process for having Py_TPFLAGS_BASETYPE boiled down to a single question: Was there any reason to close this door and make the itertools not subclassable? For something like NoneType, there was a reason to be unsubclassable; otherwise, the default choice was to give users maximum flexibility (the itertools were intended to be a generic set of building blocks, forming what Guido termed an "iterator algebra"). As an implementor of another version of Python, you are reasonably asking the question, what is the specification for subclassing semantics? The answer is somewhat unsatisfying -- I don't know because I've never thought about it. As far as I can tell, this question has never come up in the 13 years of itertools existence and you may be the first person to have ever cared about this. Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement
On Mon, Sep 14, 2015 at 1:44 AM, Tim Peters wrote: > That's a sane & easy sufficient condition. It's a waste of time to > worry about minimal necessary conditions. "Convert to UTC' is the > obvious way to do darned near everything. Converting to any other > fixed-offset zone would do just as well, but _that_ observation is > also a waste of time, since "convert to UTC" is just as easy ;-) So it isn't sufficient for them all to be in, say, Australia/Melbourne, which observes DST. Fair enough. And yeah, converting to UTC is straightforward enough. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Collecting information about git
On Sep 12, 2015, at 03:54 PM, Oleg Broytman wrote: >This Informational PEP collects information about git. There is, of course, a >lot of documentation for git, so the PEP concentrates on more complex (and >more related to Python development) issues, scenarios and examples. Thanks for this Oleg. git is popular and powerful, but with that power comes a lot of options, command line switches, complexity, and verbose manpages. Boiled down, you don't have to learn all of that to be effective, and you can augment your knowledge as you go, although it's sometimes difficult to find the exact bit of advice you're looking for. A sprinkling of git aliases has definitely made my life easier. :) One of the things I think is missing from most git documentation, is an effective workflow for handling multiple branches. Think about the Python case where we have the default branch for what is now going to be Python 3.6, plus stable release branches for several older Python 3 versions, and even Python 2.7. Now imagine a bug fix which must be applied to many of these active branches. There are lots of different ways to do this, but really no best practices for how it should be done. Do you apply the fix to the highest version branch and then cherry pick to the older version branches? What about if you need to skip one of those branches? Visually, it would be something like this: master -> A -> B ->-> F -> G \/ issue1 -> -> C -> D -> E / releaseX.Y -> H -> I At this point you'd like to take the commits C->E, rebase them onto I and then commit them to the releaseX.Y branch, e.g. releaseX.Y -> H -> I -> J \ / issue1-X.Y -=--> -> C' -> D' -> E' / I do this with several of my projects and personally find git cherry-pick to be useful, but also often non-intuitive, and sometimes it just doesn't do what I want it to do. I haven't found a lot of really good workflow documentation for git, so most of what I do is based on experimentation, with a healthy dose of frustration when my expectations aren't met. Our devguide has some good documentation on how to do this with hg, and even though I so rarely do it (CPython being one of the only projects I use Mercurial on), I can usually get the job done without a lot of cursing. :) So, for this very interesting informational PEP, I'd like to see detailed documentation on best practices for applying patches to multiple active branches using git, in the context of CPython development. Cheers, -Barry pgpNTMqkshF28.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Collecting information about git
Hello! On Sun, Sep 13, 2015 at 02:10:42PM -0400, Barry Warsaw wrote: > One of the things I think is missing from most git documentation, is an > effective workflow for handling multiple branches. Thank you for the good question! I doubt there One True Way, so the core team will choose one of the existing ways or develop their own. I can recommend three sources of information. First, gitworkflows (``git help workflows``): https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html The chapter "MANAGING BRANCHES" describes how the very git developers do that and what they recommend as the best practice. Second, the corresponding chapters in ProGit: https://git-scm.com/book/en/Git-Branching-Branching-Workflows https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project Both gitworkflows and The Book are linked from the PEP and I don't think there is a need to copy texts from the docs to the PEP. The third source of information is not mentioned in the PEP, though. I have to think where to put it. It is well-known git-flow article: http://nvie.com/posts/a-successful-git-branching-model/ It has very detaild rules on creating and managing mainline branches, topic branches and bugfix branches. To support the flow at the software level the author implemented ``git flow`` extension: https://github.com/nvie/gitflow See an example at http://alblue.bandlem.com/2011/11/git-tip-of-week-git-flow.html Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] semantics of subclassing things from itertools
On Sun, Sep 13, 2015 at 5:46 PM, Raymond Hettinger wrote: > >> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski wrote: >> >>> The intended semantics are that the itertools are classes (not functions >>> and not generators). They are intended to be sub-classable (that is >>> why they have Py_TPFLAGS_BASETYPE defined). >> >> Ok, so what's completely missing from the documentation is what *are* >> the semantics of subclasses of those classes? Can you override any >> magic methods? Can you override next (which is or isn't a magic method >> depending how you look)? Etc. >> >> The documentation on this is completely missing and it's left guessing >> with "whatever cpython happens to be doing". > > The reason it is underspecified is that this avenue of development was > never explored (not thought about, planned, used, tested, or documented). > IIRC, the entire decision process for having Py_TPFLAGS_BASETYPE > boiled down to a single question: Was there any reason to close this > door and make the itertools not subclassable? > > For something like NoneType, there was a reason to be unsubclassable; > otherwise, the default choice was to give users maximum flexibility > (the itertools were intended to be a generic set of building blocks, > forming what Guido termed an "iterator algebra"). > > As an implementor of another version of Python, you are reasonably > asking the question, what is the specification for subclassing semantics? > The answer is somewhat unsatisfying -- I don't know because I've > never thought about it. As far as I can tell, this question has never > come up in the 13 years of itertools existence and you may be the > first person to have ever cared about this. > > > Raymond Well, fair enough, but the semantics of "whatever happens to happen because we decided subclassing is a cool idea" is possibly the worst answer to those questions. Ideally, make it non-subclassable. If you want to have it subclassable, then please have defined semantics as opposed to undefined. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x86-64 embeddable zip file, Feedback
Thanks for the kind words, glad you're finding the distribution useful. Feel free to assign me (steve.dower) to the issues. I assume they're referring to the contents of the library.zip file? In which case, you're correct, those are unnecessary. I'll take a closer look when I'm at my PC. Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "[email protected]" Sent: 9/13/2015 6:59 To: "Python-Dev" Subject: [Python-Dev] Windows x86-64 embeddable zip file, Feedback Hi, had some time to test the new distributed stuff for Windows especially the embeddable zip. Thanks for this special distribution, it is very useful to generate standalone Python distributions and software based on Python. Very good work. I detected two minor issues only affecting size, opened tickets for them: http://bugs.python.org/issue25085 Windows x86-64 embeddable zip file contains test directorys http://bugs.python.org/issue25086 Windows x86-64 embeddable zip file, lot of big EXE files in distuils Think this can be an improvement in size, targeting for Python 3.5.1. Regards, Wolfgang ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] congrats on 3.5! Alas, windows 7 users are having problems installing it
webmaster has already heard from 4 people who cannot install it. I sent them to the bug tracker or to python-list but they seem not to have gone either place. Is there some guide I should be sending them to, 'how to debug installation problems'? Laura ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] When is 3.4.4 scheduled?
I could not fine '3.4.4' either in https://www.python.org/dev/peps/pep-0429/ 3.4 schedule or elsewhere on the site. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] semantics of subclassing things from itertools
> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski wrote: > > Well, fair enough, but the semantics of "whatever happens to happen > because we decided subclassing is a cool idea" is possibly the worst > answer to those questions. It's hard to read this in any way that isn't insulting. It was subclassable because a) it was a class, 2) type/class unification was pushing us in the direction of making builtin types more like regular classes (which are subclassable), and 3) because it seemed potentially useful to users (and apparently it has been because users are subclassing it). FWIW, the code was modeled on what was done for enumerate() and reversed() where I got a lot of coaching and review from Tim Peters, Alex Martelli, Fredrik Lundh, and other python luminaries of the day. > Ideally, make it non-subclassable. If you > want to have it subclassable, then please have defined semantics as > opposed to undefined. No, I'm not going to change a 13 year-old API and break existing user code just because you've gotten worked-up about it. FWIW, the semantics wouldn't even be defined in the itertools docs. It is properly in some section that describes what happens to any C type that defines sets the Py_TPFLAGS_BASETYPE flag. In general, all of the exposed dunder methods are overridable or extendable by subclassers. Raymond P.S. Threads like this are why I've developed an aversion to python-dev. I've answered your questions with respect and candor. I've been sympathetic to your unique needs as someone building an implementation of a language that doesn't have a spec. I was apologetic that the docs which have been helpful to users weren't precise enough for your needs. In return, you've suggested that my first contributions to Python were irresponsible and based on doing whatever seemed cool. In fact, the opposite is the case. I spent a full summer researching how similar tools were used in other languages and fitting them into Python in a way that supported known use cases. I raised the standard of the Python docs by including rough python equivalent code, showing sample inputs and outputs, building a quick navigation and summary section as the top of the docs, adding a recipes section, making thorough unittests, and getting input from Alex, Tim, and Fredrik (Guido also gave high level advice on the module design). I'm not inclined to go on with this thread. Your questions have been answered to the extent that I remember the answers. If you have a doc patch you want to submit, please assign it to me on the tracker. I would be happy to review it. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The process I intend to follow for any proposed changes to NumPy
Hey all, I just wanted to clarify, that I am very excited about a few ideas I have --- but I don't have time myself to engage in the community process to get these changes into NumPy. However, those are real processes --- I've been coaching a few people in those processes for the past several years already. So, rather than do nothing, what I'm looking to do is to work with a few people who I can share my ideas with, get excited about the ideas, and then who will work with the community to get them implemented. That's what I was announcing and talking about yesterday --- looking for interested people who want to work on NumPy *with* the NumPy community. In my enthusiasm, I realize that some may have mis-understood my intention. There is no 'imminent' fork, nor am I planning on doing some crazy amount of work that I then try to force on other developers of NumPy. What I'm planning to do is find people to train on NumPy code base (people to increase the diversity of the developers would be ideal -- but hard to accomplish). I plan to train them on NumPy based on my experience, and on what I think should be done --- and then have *them* work through the community process and engage with others to get consensus (hopefully not losing too much in translation in the process --- but instead getting even better). During that process I will engage as a member of the community and help write NEPs and other documents and help clarify where it makes sense as I can. I will be filtering for people that actually want to see NumPy get better.Until I identify the people and work with them, it will be hard to tell how this will best work. So, stay tuned. If all goes well, what you should see in a few weeks time are specific proposals, a branch or two, and the beginnings of some pull requests.If you don't see that, then I will not have found the right people to help me, and we will all continue to go back to searching. While I'm expecting the best, in the worst case, we get additional people who know the NumPy code base and can help squash bugs as well as implement changes that are desired.Three things are needed if you want to participate in this: 1) A willingness to work with the open source community, 2) a deep knowledge of C and in-particular CPython's brand of C, and 3) a willingness to engage with me, do a mind-meld and dump around the NumPy code base, and then improve on what is in my head with the rest of the community. Thanks, -Travis ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When is 3.4.4 scheduled?
It's not. My thinking was, do it in about a month. How's that sound? 3.4.4 should be the last bugfix release of 3.4, after that it'll move into security-fixes-only. //arry/ On 09/13/2015 11:05 PM, Terry Reedy wrote: I could not fine '3.4.4' either in https://www.python.org/dev/peps/pep-0429/ 3.4 schedule or elsewhere on the site. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] semantics of subclassing things from itertools
Hey Raymond I'm sorry you got insulted, that was not my intention. I suppose something like "itertools objects are implemented as classes internally, which means they're subclassable like other builtin types" is an improvement to documentation. On Mon, Sep 14, 2015 at 12:17 AM, Raymond Hettinger wrote: > >> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski wrote: >> >> Well, fair enough, but the semantics of "whatever happens to happen >> because we decided subclassing is a cool idea" is possibly the worst >> answer to those questions. > > It's hard to read this in any way that isn't insulting. > > It was subclassable because a) it was a class, 2) type/class unification was > pushing us in the direction of making builtin types more like regular classes > (which are subclassable), and 3) because it seemed potentially useful > to users (and apparently it has been because users are subclassing it). > > FWIW, the code was modeled on what was done for enumerate() and > reversed() where I got a lot of coaching and review from Tim Peters, > Alex Martelli, Fredrik Lundh, and other python luminaries of the day. > > >> Ideally, make it non-subclassable. If you >> want to have it subclassable, then please have defined semantics as >> opposed to undefined. > > No, I'm not going to change a 13 year-old API and break existing user code > just because you've gotten worked-up about it. > > FWIW, the semantics wouldn't even be defined in the itertools docs. > It is properly in some section that describes what happens to any C type > that defines sets the Py_TPFLAGS_BASETYPE flag. In general, all of > the exposed dunder methods are overridable or extendable by subclassers. > > > Raymond > > > P.S. Threads like this are why I've developed an aversion to python-dev. > I've answered your questions with respect and candor. I've been sympathetic > to your unique needs as someone building an implementation of a language > that doesn't have a spec. I was apologetic that the docs which have been > helpful to users weren't precise enough for your needs. > > In return, you've suggested that my first contributions to Python were > irresponsible and based on doing whatever seemed cool. > > In fact, the opposite is the case. I spent a full summer researching how > similar > tools were used in other languages and fitting them into Python in a way that > supported known use cases. I raised the standard of the Python docs by > including rough python equivalent code, showing sample inputs and outputs, > building a quick navigation and summary section as the top of the docs, > adding a recipes section, making thorough unittests, and getting input from > Alex, > Tim, and Fredrik (Guido also gave high level advice on the module design). > > I'm not inclined to go on with this thread. Your questions have been answered > to the extent that I remember the answers. If you have a doc patch you want > to submit, please assign it to me on the tracker. I would be happy to review > it. > > > > > > > > > > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
