From nathan12343 at gmail.com Wed Aug 8 18:54:42 2018 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Wed, 8 Aug 2018 17:54:42 -0500 Subject: [Cython] #cython on freenode Message-ID: Hi all, The Freenode IRC network is currently undergoing a spam attack that is affecting the #cython channel there. People definitely do use #cython to ask questions. I and some others try and help them out. It would be a shame to have that community, such as it is, get destroyed by the spam attack. Freenode has a way for a project to take control of the IRC channel associated with their name by mailing projects at freenode.net and working with an admin to prove who you say you are. For matplotlib they asked Tom Caswell to push a branch with a randomly chosen name to github. If someone associated with the project is willing to do something like that, I would be very happy to volunteer to admin the channel and set the channel settings to mitigate the spam attack. I'm currently doing a similar process to get admin powers for #ipython and #matplotlib and already have admin powers in #scipy and #numpy. Thanks for your help, -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Fri Aug 10 05:13:09 2018 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 10 Aug 2018 11:13:09 +0200 Subject: [Cython] #cython on freenode In-Reply-To: References: Message-ID: Thanks for the heads up. I'd be happy to help with this. On Thu, Aug 9, 2018, 12:55 AM Nathan Goldbaum wrote: > Hi all, > > The Freenode IRC network is currently undergoing a spam attack that is > affecting the #cython channel there. > > People definitely do use #cython to ask questions. I and some others try > and help them out. It would be a shame to have that community, such as it > is, get destroyed by the spam attack. > > Freenode has a way for a project to take control of the IRC channel > associated with their name by mailing projects at freenode.net and working > with an admin to prove who you say you are. For matplotlib they asked Tom > Caswell to push a branch with a randomly chosen name to github. If someone > associated with the project is willing to do something like that, I would > be very happy to volunteer to admin the channel and set the channel > settings to mitigate the spam attack. I'm currently doing a similar process > to get admin powers for #ipython and #matplotlib and already have admin > powers in #scipy and #numpy. > > Thanks for your help, > > -Nathan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arj.python at gmail.com Mon Aug 13 04:37:43 2018 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Mon, 13 Aug 2018 12:37:43 +0400 Subject: [Cython] #cython on freenode In-Reply-To: References: Message-ID: the admin of #python-fr sent me this resource, will help : https://nedbatchelder.com/blog/201808/fighting_spam_on_freenode.html Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius On Sat, 11 Aug 2018, 01:43 Robert Bradshaw, wrote: > Thanks for the heads up. I'd be happy to help with this. > > On Thu, Aug 9, 2018, 12:55 AM Nathan Goldbaum > wrote: > >> Hi all, >> >> The Freenode IRC network is currently undergoing a spam attack that is >> affecting the #cython channel there. >> >> People definitely do use #cython to ask questions. I and some others try >> and help them out. It would be a shame to have that community, such as it >> is, get destroyed by the spam attack. >> >> Freenode has a way for a project to take control of the IRC channel >> associated with their name by mailing projects at freenode.net and working >> with an admin to prove who you say you are. For matplotlib they asked Tom >> Caswell to push a branch with a randomly chosen name to github. If someone >> associated with the project is willing to do something like that, I would >> be very happy to volunteer to admin the channel and set the channel >> settings to mitigate the spam attack. I'm currently doing a similar process >> to get admin powers for #ipython and #matplotlib and already have admin >> powers in #scipy and #numpy. >> >> Thanks for your help, >> >> -Nathan >> _______________________________________________ >> cython-devel mailing list >> cython-devel at python.org >> https://mail.python.org/mailman/listinfo/cython-devel >> > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Mon Aug 13 13:42:11 2018 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Mon, 13 Aug 2018 12:42:11 -0500 Subject: [Cython] #cython on freenode In-Reply-To: References: Message-ID: Hi Robert, That?s great. Let me know if you need a hand with anything. Feel free to ping me in #cython. Also in the meantime I managed to get the attention of a freenode admin who changed the channel settings so the spam problem is mostly resolved for now. It would still be good to have the channel registered with the project and to set up admins. Nathan On Mon, Aug 13, 2018 at 12:06 PM Abdur-Rahmaan Janhangeer < arj.python at gmail.com> wrote: > the admin of #python-fr sent me this resource, will help : > > https://nedbatchelder.com/blog/201808/fighting_spam_on_freenode.html > > > Abdur-Rahmaan Janhangeer > https://github.com/Abdur-rahmaanJ > Mauritius > > On Sat, 11 Aug 2018, 01:43 Robert Bradshaw, wrote: > >> Thanks for the heads up. I'd be happy to help with this. >> >> On Thu, Aug 9, 2018, 12:55 AM Nathan Goldbaum >> wrote: >> >>> Hi all, >>> >>> The Freenode IRC network is currently undergoing a spam attack that is >>> affecting the #cython channel there. >>> >>> People definitely do use #cython to ask questions. I and some others try >>> and help them out. It would be a shame to have that community, such as it >>> is, get destroyed by the spam attack. >>> >>> Freenode has a way for a project to take control of the IRC channel >>> associated with their name by mailing projects at freenode.net and working >>> with an admin to prove who you say you are. For matplotlib they asked Tom >>> Caswell to push a branch with a randomly chosen name to github. If someone >>> associated with the project is willing to do something like that, I would >>> be very happy to volunteer to admin the channel and set the channel >>> settings to mitigate the spam attack. I'm currently doing a similar process >>> to get admin powers for #ipython and #matplotlib and already have admin >>> powers in #scipy and #numpy. >>> >>> Thanks for your help, >>> >>> -Nathan >>> _______________________________________________ >>> cython-devel mailing list >>> cython-devel at python.org >>> https://mail.python.org/mailman/listinfo/cython-devel >>> >> _______________________________________________ >> cython-devel mailing list >> cython-devel at python.org >> https://mail.python.org/mailman/listinfo/cython-devel >> > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Wed Aug 15 10:49:58 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 15 Aug 2018 16:49:58 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= Message-ID: <66ad4e44-b2d4-7d3e-0204-781d21af4dc1@behnel.de> Hello everyone, I had a request during my talk at EuroPython this year to help the aspiring Cython users out there convince their managers to accept Cython in their tech stack. Cython has been around for more than a decade now, has been in heavy production use pretty much all of that time, has proven to have everything it needs as a programming language, and still resorts to a 0.x versioning scheme. I think it's time to leave the 0.x behind us and make it clear that it's a reliable programming language that won't easily change in a major code breaking way anymore. Which version should we choose next? Some projects have adopted year based release schemes, e.g. pip recently jumped from 10.x to 18.0. Browsers follow the marketing path and boldly increase their version number by a whole 1 on every feature release. I'd be happy to follow them and release a Cython 29.0 next, mostly to make it clear that we're not really changing anything from the previous release cycles, but really just move the versioning scheme one place to the left to get rid of the uninformative "0." prefix. What do you think? Stefan From julian.rueth at fsfe.org Wed Aug 15 11:17:32 2018 From: julian.rueth at fsfe.org (Julian =?iso-8859-1?Q?R=FCth?=) Date: Wed, 15 Aug 2018 17:17:32 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <66ad4e44-b2d4-7d3e-0204-781d21af4dc1@behnel.de> References: <66ad4e44-b2d4-7d3e-0204-781d21af4dc1@behnel.de> Message-ID: <20180815151732.GA23380@wigwum> Hello Stefan, * Stefan Behnel [2018-08-15 16:49:58 +0200]: > I think it's time to leave the 0.x behind us and make it clear that it's a > reliable programming language that won't easily change in a major code > breaking way anymore. it's true that the 0. prefix gives the impression that cython is not ready for production. So I think it's a great idea to change that. > What do you think? As someone who is involved in packaging for several Linux distros, I really like semantic versioning [1]. In that scheme the next version could be 1.29.0 and I could relatively safely make packages depend on `cython >= 1.29, <2` without having to check with every release if there has been a (major) breaking change. julian [1] https://semver.org/ From J.Demeyer at UGent.be Wed Aug 15 16:40:24 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Wed, 15 Aug 2018 22:40:24 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> Message-ID: <5B748FB8.4020009@UGent.be> I vote for 1.0 Version 29.0 sounds too much like marketing. From robertwb at gmail.com Wed Aug 15 18:48:19 2018 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 16 Aug 2018 00:48:19 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <5B748FB8.4020009@UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> Message-ID: If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of semantic versioning. The primary reasons we kept the 0.x scheme were that * We wanted full compatibility with CPython (we're nearly there, or at least it's safe to say the differences are on par with those between different versions and implementations of Python), and * We wanted the flexibility to possibly jettison archaic features of the language or otherwise clean things up. It's worth revisiting to see if either of these are still relevant (*and* likely to be worked on in the near future). On Wed, Aug 15, 2018 at 10:40 PM, Jeroen Demeyer wrote: > I vote for 1.0 > > Version 29.0 sounds too much like marketing. > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.McPherson at oracle.com Thu Aug 16 21:15:45 2018 From: James.McPherson at oracle.com (James C. McPherson) Date: Fri, 17 Aug 2018 11:15:45 +1000 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> Message-ID: <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> 1.0 runs the risk of hitting "never install a 1.0 release" habits. Jumping to 29.0 would not, imnsho, be such an issue because people are used to the rapid cadence of Firefox, Thunderbird and Chrome releases. The flip side of 29.0 would be the question "when are you announcing your LTS version?" James On 08/16/18 08:48 AM, Robert Bradshaw wrote: > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of > semantic versioning. > > The primary reasons we kept the 0.x scheme were that > > * We wanted full compatibility with CPython (we're nearly there, or at > least it's safe to say the differences are on par with those between > different versions and implementations of Python), and > * We wanted the flexibility to possibly jettison archaic features of the > language or otherwise clean things up. > > It's worth revisiting to see if either of these are still relevant (*and* > likely to be worked on in the near future). > > > > On Wed, Aug 15, 2018 at 10:40 PM, Jeroen Demeyer > wrote: > > I vote for 1.0 > > Version 29.0 sounds too much like marketing. > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > > > > > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -- Oracle Systems / Solaris / Core Solaris WOS Tech Lead https://www.jmcpdotcom.com/blog From dimpase+github at gmail.com Fri Aug 17 04:58:27 2018 From: dimpase+github at gmail.com (Dima Pasechnik) Date: Fri, 17 Aug 2018 11:58:27 +0300 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> Message-ID: I'd vote for sanity over marketing, i.e. 1.0. On Fri, Aug 17, 2018 at 11:53 AM James C. McPherson wrote: > > > 1.0 runs the risk of hitting "never install a 1.0 release" habits. > > Jumping to 29.0 would not, imnsho, be such an issue because people > are used to the rapid cadence of Firefox, Thunderbird and Chrome > releases. The flip side of 29.0 would be the question "when are you > announcing your LTS version?" > > James > > > On 08/16/18 08:48 AM, Robert Bradshaw wrote: > > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of > > semantic versioning. > > > > The primary reasons we kept the 0.x scheme were that > > > > * We wanted full compatibility with CPython (we're nearly there, or at > > least it's safe to say the differences are on par with those between > > different versions and implementations of Python), and > > * We wanted the flexibility to possibly jettison archaic features of the > > language or otherwise clean things up. > > > > It's worth revisiting to see if either of these are still relevant (*and* > > likely to be worked on in the near future). > > > > > > > > On Wed, Aug 15, 2018 at 10:40 PM, Jeroen Demeyer > > wrote: > > > > I vote for 1.0 > > > > Version 29.0 sounds too much like marketing. > > > > _______________________________________________ > > cython-devel mailing list > > cython-devel at python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > > > > > > > > > > > _______________________________________________ > > cython-devel mailing list > > cython-devel at python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > > > > -- > Oracle > Systems / Solaris / Core > Solaris WOS Tech Lead > https://www.jmcpdotcom.com/blog > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel From stefan_ml at behnel.de Fri Aug 17 05:44:50 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 17 Aug 2018 11:44:50 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> Message-ID: <6e003787-21b1-def9-70fa-f5259b8f9473@behnel.de> Robert Bradshaw schrieb am 16.08.2018 um 00:48: > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of > semantic versioning. I'm ok with it, just fear that it might become excessive for Cython (ok, I'm the one who proposed jumping to 29.0, but...). Basically, any time we add something to Includes/ or anything to the language, we'd have to increase the minor version, and any time we fix something that might break some person's code, we'd have to increase the major version? Some changes are simply not important enough to merit shouting out the breakage that almost no-one would otherwise notice. And unless we're adding new syntax that was an error before, almost any change in the compiler bears a tiny risk of breaking something for someone. > The primary reasons we kept the 0.x scheme were that > > * We wanted full compatibility with CPython (we're nearly there, or at > least it's safe to say the differences are on par with those between > different versions and implementations of Python), and I've half-heartedly considered it done for years. The rest are bugs, and we have enough of those, also enough that are worse than incomplete Python semantics. The list of Python related tickets in github is short: https://github.com/cython/cython/issues?q=is%3Aissue+is%3Aopen+label%3A%22Python+Semantics%22 and the most relevant one is certainly #1159, which hasn't seen much attention in years: https://github.com/cython/cython/issues/1159 > * We wanted the flexibility to possibly jettison archaic features of the > language or otherwise clean things up. > > It's worth revisiting to see if either of these are still relevant (*and* > likely to be worked on in the near future). It's true that Cython often offers more than one way to do something, also in terms of syntax. There is a certain level of perpetual request for static typing in PEP-489 notation (which is supported), but I don't see it completely replace Cython's own efficient syntax any time soon, it's not a clear champion. We can think about dropping some of the redundant pure Python syntax when we switch to Py3-by-default, maybe next year. But even then, we'd have to keep the Py2-mode around in order to support existing code bases. Hej, that gives us an alternative for the versioning switch. We could release Cython 3.0 when we change the default language level (and require users to select "language_level=2" for legacy code). Definitely a breaking change that merits inceasing the major version, and 3.0 seems very suitable. Stefan From yury at shurup.com Fri Aug 17 04:59:51 2018 From: yury at shurup.com (Yury V. Zaytsev) Date: Fri, 17 Aug 2018 10:59:51 +0200 (CEST) Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> Message-ID: On Fri, 17 Aug 2018, James C. McPherson wrote: > > 1.0 runs the risk of hitting "never install a 1.0 release" habits. How about 2.9.0 ;-) ? > Jumping to 29.0 would not, imnsho, be such an issue because people are > used to the rapid cadence of Firefox, Thunderbird and Chrome releases. > The flip side of 29.0 would be the question "when are you announcing > your LTS version?" That, and I second that non-semver, and particularly this browser-style versioning is very annoying for the packagers. What's worse though, is when a project moves from semver to browser-style, then to date-based, and then back again >:-| So, whatever you choose, please choose wisely... 0.02 ? -- Sincerely yours, Yury V. Zaytsev From erik.m.bray at gmail.com Fri Aug 17 07:46:51 2018 From: erik.m.bray at gmail.com (Erik Bray) Date: Fri, 17 Aug 2018 13:46:51 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <6e003787-21b1-def9-70fa-f5259b8f9473@behnel.de> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <6e003787-21b1-def9-70fa-f5259b8f9473@behnel.de> Message-ID: On Fri, Aug 17, 2018 at 12:03 PM Stefan Behnel wrote: > > Robert Bradshaw schrieb am 16.08.2018 um 00:48: > > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of > > semantic versioning. > > I'm ok with it, just fear that it might become excessive for Cython (ok, > I'm the one who proposed jumping to 29.0, but...). Basically, any time we > add something to Includes/ or anything to the language, we'd have to > increase the minor version, and any time we fix something that might break > some person's code, we'd have to increase the major version? Some changes > are simply not important enough to merit shouting out the breakage that > almost no-one would otherwise notice. And unless we're adding new syntax > that was an error before, almost any change in the compiler bears a tiny > risk of breaking something for someone. I believe it's okay to make sensical judgment calls on this one. I don't really like how semver.org defines usage of the major version number, because one could easily take it too literally like this. I believe there are other reasons to bump major version numbers, such as yes, marketing. You can also use it like Linux and some other projects do to indicate LTS. Like, an odd version number means "we guarantee not to signficantly break anything in these releases, and to backport bug fixes for X amount of time", versus even major version means "active changes are happening here; API may move around a bit; no bug fixes to these releases after the next LTS release". I'm not saying Cython should necessarily do that. Just giving examples of how I think semver.org's definition of major version is too constrained. From stefan_ml at behnel.de Fri Aug 17 07:43:54 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 17 Aug 2018 13:43:54 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com> Message-ID: Yury V. Zaytsev schrieb am 17.08.2018 um 10:59: > On Fri, 17 Aug 2018, James C. McPherson wrote: >> 1.0 runs the risk of hitting "never install a 1.0 release" habits. > > How about 2.9.0 ;-) ? Sold! :) Proposal: we'll release a 2.9.0 next, which gives a warning that users should explicitly enable "language_level=2" in their setup.py when compiling Py2 code, and then release 3.0 as the next feature release, which requires this option for Py2 code and defaults to compiling with Py3 syntax and semantics. Stefan From julian.rueth at fsfe.org Fri Aug 17 08:42:50 2018 From: julian.rueth at fsfe.org (Julian =?iso-8859-1?Q?R=FCth?=) Date: Fri, 17 Aug 2018 14:42:50 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com>

Message-ID: <20180817124250.GH4745@wigwum> * Stefan Behnel [2018-08-17 13:43:54 +0200]: > Yury V. Zaytsev schrieb am 17.08.2018 um 10:59: > > On Fri, 17 Aug 2018, James C. McPherson wrote: > >> 1.0 runs the risk of hitting "never install a 1.0 release" habits. > > > > How about 2.9.0 ;-) ? > > Sold! :) > > Proposal: we'll release a 2.9.0 next, which gives a warning that users > should explicitly enable "language_level=2" in their setup.py when > compiling Py2 code, and then release 3.0 as the next feature release, which > requires this option for Py2 code and defaults to compiling with Py3 syntax > and semantics. +1 Also, I would not be too strict about the major version number in semver. Sometimes bugfixes are breaking changes for the people who worked around that bug with some tricks. I think bumping the major version is really about removing a public documented interface or changes that we know are going to break a lot of existing code. A nice thing about semver is that it makes many people try harder to not do that because they do not want to bump the major version number and rather provide means to support legacy code... Anyway, the proposed 2.9.0 to 3.0.0 jump certainly sounds like the major version number should change there. julian From yury at shurup.com Fri Aug 17 11:42:31 2018 From: yury at shurup.com (Yury V. Zaytsev) Date: Fri, 17 Aug 2018 17:42:31 +0200 (CEST) Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com>

Message-ID: On Fri, 17 Aug 2018, Stefan Behnel wrote: > Proposal: we'll release a 2.9.0 next, which gives a warning that users > should explicitly enable "language_level=2" in their setup.py when > compiling Py2 code, and then release 3.0 as the next feature release, > which requires this option for Py2 code and defaults to compiling with > Py3 syntax and semantics. Sounds like an excellent plan, I like it! -- Sincerely yours, Yury V. Zaytsev From robertwb at gmail.com Fri Aug 17 12:19:21 2018 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 17 Aug 2018 09:19:21 -0700 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com>

Message-ID: I like the jump to 3.0 to to change the language level. It still might be safer to *require* this flag for a period though, and 3.0 would make it optional (with the opposite default than it has now). (I'm honestly on the fence with this one, as it may be a major pain to make this required...) Letting the next version be 2.9 feels like it risks typos and confusion (e.g. people who are used to the current numbering will call it 0.29). Jumping to 29.0 makes it feel like we'll be updating the major version often (or we'll be at an arbitrary 29.x for a long time). As for semantic versioning, I'm with Julian that it's more about communicating intent. Patch releases should be safe no-brainers, minor versions should be safe by default, but make sure you think about them, and major changes will likely require code changes. Not unlike how Python has handled numbers (though hopefully we'll release with more frequency). We may want to reserve a major version bump for issues like https://github.com/cython/cython/issues/1382 which are simply not done for fear of breaking users code, before 3.0. So, I might release the next release by default (0.29.6? Or is it too major. I guess going 0.30 would be bad.), get a short list of breaking changes we're actually going to change by the next major release (such as requiring a language level, double-underscore mangling, ??? called 1.x or 2.x) and go from there. I like a plan to get out of the 0.x naming scheme, but it's hard to argue it must be done *now* vs. in a release or two. - Robert On Fri, Aug 17, 2018 at 8:42 AM, Yury V. Zaytsev wrote: > On Fri, 17 Aug 2018, Stefan Behnel wrote: > > Proposal: we'll release a 2.9.0 next, which gives a warning that users >> should explicitly enable "language_level=2" in their setup.py when >> compiling Py2 code, and then release 3.0 as the next feature release, which >> requires this option for Py2 code and defaults to compiling with Py3 syntax >> and semantics. >> > > Sounds like an excellent plan, I like it! > > -- > Sincerely yours, > Yury V. Zaytsev > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Fri Aug 17 15:51:10 2018 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 17 Aug 2018 12:51:10 -0700 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com>

Message-ID: It'd be nice to change the default of cython.binding as well (breaking change). On Fri, Aug 17, 2018 at 9:19 AM, Robert Bradshaw wrote: > I like the jump to 3.0 to to change the language level. It still might be > safer to *require* this flag for a period though, and 3.0 would make it > optional (with the opposite default than it has now). (I'm honestly on the > fence with this one, as it may be a major pain to make this required...) > > Letting the next version be 2.9 feels like it risks typos and confusion > (e.g. people who are used to the current numbering will call it 0.29). > Jumping to 29.0 makes it feel like we'll be updating the major version > often (or we'll be at an arbitrary 29.x for a long time). > > As for semantic versioning, I'm with Julian that it's more about > communicating intent. Patch releases should be safe no-brainers, minor > versions should be safe by default, but make sure you think about them, and > major changes will likely require code changes. Not unlike how Python has > handled numbers (though hopefully we'll release with more frequency). > > We may want to reserve a major version bump for issues like > https://github.com/cython/cython/issues/1382 which are simply not done > for fear of breaking users code, before 3.0. > > So, I might release the next release by default (0.29.6? Or is it too > major. I guess going 0.30 would be bad.), get a short list of breaking > changes we're actually going to change by the next major release (such as > requiring a language level, double-underscore mangling, ??? called 1.x or > 2.x) and go from there. > > I like a plan to get out of the 0.x naming scheme, but it's hard to argue > it must be done *now* vs. in a release or two. > > - Robert > > > > On Fri, Aug 17, 2018 at 8:42 AM, Yury V. Zaytsev wrote: > >> On Fri, 17 Aug 2018, Stefan Behnel wrote: >> >> Proposal: we'll release a 2.9.0 next, which gives a warning that users >>> should explicitly enable "language_level=2" in their setup.py when >>> compiling Py2 code, and then release 3.0 as the next feature release, which >>> requires this option for Py2 code and defaults to compiling with Py3 syntax >>> and semantics. >>> >> >> Sounds like an excellent plan, I like it! >> >> -- >> Sincerely yours, >> Yury V. Zaytsev >> _______________________________________________ >> cython-devel mailing list >> cython-devel at python.org >> https://mail.python.org/mailman/listinfo/cython-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Sat Aug 18 03:13:03 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 18 Aug 2018 09:13:03 +0200 Subject: [Cython] Preparing Cython 3.0 with breaking changes Message-ID: <301ca985-6e05-80fb-7a6b-7ca2d0dd0143@behnel.de> Hi all, following the versioning discussion, I created a milestone to collect (breaking) changes that should go into the future Cython 3.0 release. https://github.com/cython/cython/milestone/58 While a major version change is a good time to fix things that, in retrospect, have led us too far in the wrong direction, we are not planning to remove the support for existing code any time soon that relies on the current semantics. For now, it looks like the major breaking changes will be to directive defaults, which means that setting them explicitly to their current configuration (e.g. in setup.py) should keep code working across Cython releases. Feedback welcome. Stefan From J.Demeyer at UGent.be Sat Aug 18 04:17:26 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Sat, 18 Aug 2018 10:17:26 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <68579f8a85134a6cb5fd1a348ed484b6@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <2e825cc2-732c-d75f-ef7c-afa2ef1df2bb@oracle.com>

<68579f8a85134a6cb5fd1a348ed484b6@xmail103.UGent.be> Message-ID: <5B77D616.9060805@UGent.be> On 2018-08-17 21:51, Robert Bradshaw wrote: > It'd be nice to change the default of cython.binding as well (breaking > change). Ideally, after PEP 580 is accepted :-) From J.Demeyer at UGent.be Sat Aug 18 04:24:45 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Sat, 18 Aug 2018 10:24:45 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> Message-ID: <5B77D7CD.6000008@UGent.be> On 2018-08-17 11:44, Stefan Behnel wrote: > Hej, that gives us an alternative for the versioning switch. We could > release Cython 3.0 when we change the default language level (and require > users to select "language_level=2" for legacy code). Definitely a breaking > change that merits inceasing the major version, and 3.0 seems very suitable. One annoying point with language_level=3 is that all string literals become unicode (like from __future__ import unicode_literals). Unlike the other changes that language_level=3 makes, this is a major breaking change on Python 2. So I would very much prefer enabling everything that language_level=3 does, but keeping strings of type "str" on Python 2. Maybe you could invent a new option for that, say "language_level=3str"? Jeroen. From J.Demeyer at UGent.be Sat Aug 18 04:27:08 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Sat, 18 Aug 2018 10:27:08 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> Message-ID: <5B77D85C.3020408@UGent.be> On 2018-08-17 11:44, Stefan Behnel wrote: > https://github.com/cython/cython/issues?q=is%3Aissue+is%3Aopen+label%3A%22Python+Semantics%22 Please add https://github.com/cython/cython/issues/1635 From robertwb at gmail.com Sat Aug 18 04:52:58 2018 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 18 Aug 2018 10:52:58 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <5B77D7CD.6000008@UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> Message-ID: On Sat, Aug 18, 2018 at 10:24 AM, Jeroen Demeyer wrote: > On 2018-08-17 11:44, Stefan Behnel wrote: >> >> Hej, that gives us an alternative for the versioning switch. We could >> release Cython 3.0 when we change the default language level (and require >> users to select "language_level=2" for legacy code). Definitely a breaking >> change that merits inceasing the major version, and 3.0 seems very >> suitable. > > > One annoying point with language_level=3 is that all string literals become > unicode (like from __future__ import unicode_literals). Unlike the other > changes that language_level=3 makes, this is a major breaking change on > Python 2. > > So I would very much prefer enabling everything that language_level=3 does, > but keeping strings of type "str" on Python 2. Maybe you could invent a new > option for that, say "language_level=3str"? Do the existing c_string_type and c_string_encoding directives not cover this usecase? I suppose what you're asking for is str being the str of the runtime, even if language_level=3 is set. From J.Demeyer at UGent.be Sat Aug 18 06:06:15 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Sat, 18 Aug 2018 12:06:15 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> Message-ID: <5B77EF97.5070109@UGent.be> On 2018-08-18 10:52, Robert Bradshaw wrote: > Do the existing c_string_type and c_string_encoding directives not > cover this usecase? Those seem to refer to C strings, I am talking about the Python type of string literals. > I suppose what you're asking for is str being the > str of the runtime, even if language_level=3 is set. Basically I am asking for type("foo") is str both on Python 2 and Python 3. From stefan_ml at behnel.de Sat Aug 18 12:09:26 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 18 Aug 2018 18:09:26 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <5B77EF97.5070109@UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> <5B77EF97.5070109@UGent.be> Message-ID: Am 18. August 2018 12:06:15 MESZ schrieb Jeroen Demeyer: >On 2018-08-18 10:52, Robert Bradshaw wrote: >> Do the existing c_string_type and c_string_encoding directives not >> cover this usecase? > >Those seem to refer to C strings, I am talking about the Python type of >string literals. > >> I suppose what you're asking for is str being the >> str of the runtime, even if language_level=3 is set. > >Basically I am asking for > >type("foo") is str > >both on Python 2 and Python 3. That's another breaking change, and might suggest some other adaptations, e.g. for the type of f-strings. But it does sound like a reasonable request. And, fingers crossed, it won't be relevant forever. Stefan From J.Demeyer at UGent.be Sat Aug 18 15:11:14 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Sat, 18 Aug 2018 21:11:14 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <65306f30381646b680ff75b862d08345@xmail103.UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> <5B77EF97.5070109@UGent.be> <65306f30381646b680ff75b862d08345@xmail103.UGent.be> Message-ID: <5B786F52.4020207@UGent.be> >> Basically I am asking for >> >> type("foo") is str >> >> both on Python 2 and Python 3. > > That's another breaking change I'm not following here... what I'm asking is how Cython behaves currently (with language_level=2). From stefan_ml at behnel.de Sun Aug 19 02:26:04 2018 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 19 Aug 2018 08:26:04 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: <5B786F52.4020207@UGent.be> References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> <5B77EF97.5070109@UGent.be> <65306f30381646b680ff75b862d08345@xmail103.UGent.be> <5B786F52.4020207@UGent.be> Message-ID: Am 18. August 2018 21:11:14 MESZ schrieb Jeroen Demeyer: >>> Basically I am asking for >>> >>> type("foo") is str >>> >>> both on Python 2 and Python 3. >> >> That's another breaking change > >I'm not following here... what I'm asking is how Cython behaves >currently (with language_level=2). But only for one specific feature. The combination of features that you want does not exist yet. And enabling it for language_level=3 would break existing Py3 code. Meaning, we'd need a new setting here to make this non-breaking, but in any case, we'd create a new language subset that code would have to be adapted to. You removed the part where I said that I consider it a reasonable request, and I think this would help users to make a migration step towards Py3, while continuing to support Py2 as long as necessary. Should we make that a new directive rather than a language level? Like "py2_str=str"? That would allow its use together with language_level=3 already in the next release. Stefan From erik.m.bray at gmail.com Mon Aug 20 07:03:39 2018 From: erik.m.bray at gmail.com (Erik Bray) Date: Mon, 20 Aug 2018 13:03:39 +0200 Subject: [Cython] Preparing Cython 3.0 with breaking changes In-Reply-To: <301ca985-6e05-80fb-7a6b-7ca2d0dd0143@behnel.de> References: <301ca985-6e05-80fb-7a6b-7ca2d0dd0143@behnel.de> Message-ID: On Sat, Aug 18, 2018 at 9:19 AM Stefan Behnel wrote: > > Hi all, > > following the versioning discussion, I created a milestone to collect > (breaking) changes that should go into the future Cython 3.0 release. > > https://github.com/cython/cython/milestone/58 > > While a major version change is a good time to fix things that, in > retrospect, have led us too far in the wrong direction, we are not planning > to remove the support for existing code any time soon that relies on the > current semantics. For now, it looks like the major breaking changes will > be to directive defaults, which means that setting them explicitly to their > current configuration (e.g. in setup.py) should keep code working across > Cython releases. > > Feedback welcome. Hi Stefan, Not related to the Cython language itself, but it would be good, as related to issues like #1514 [1] and #2531 [2] to rip out a lot of the old disutils-related code, which would be a breaking change. Perhaps this could be done in a way that isn't *too* breaking, such as leaving behind some stubs, as this might also require some changes to setuptools (which I can help make happen). Of course, none of this should happen without something better to replace it, along the lines that we discussed in Cernay. I still have my notes from our talk about that and will try to write up a summary (which I should have done back then, but oh well). Just thought I'd mention that a another potential "breaking change" that might be worth adding to the list, and I don't think it will break much if handled with a bit of care. [1] https://github.com/cython/cython/issues/1514 [2] https://github.com/cython/cython/issues/2531 From J.Demeyer at UGent.be Wed Aug 22 07:10:27 2018 From: J.Demeyer at UGent.be (Jeroen Demeyer) Date: Wed, 22 Aug 2018 13:10:27 +0200 Subject: [Cython] =?utf-8?b?Q3l0aG9uIDAuMjkg4oCTIG9yIDI5LjAgPw==?= In-Reply-To: References: <9f1ab4d53359429596ca9eb7c28e5f08@xmail103.UGent.be> <5B748FB8.4020009@UGent.be> <0bf385ab9c2242ecad5ab2af6c9f778b@xmail103.UGent.be> <5B77D7CD.6000008@UGent.be> <9d39d9ade7c24c008d1a370a01a669ac@xmail103.UGent.be> <5B77EF97.5070109@UGent.be> <65306f30381646b680ff75b862d08345@xmail103.UGent.be> <5B786F52.4020207@UGent.be> Message-ID: <5B7D44A3.6040404@UGent.be> On 2018-08-19 08:26, Stefan Behnel wrote: > Should we make that a new directive rather than a language level? Like "py2_str=str"? That would allow its use together with language_level=3 already in the next release. With a new new directive, you also run into compatibility problems. What should the default be? py2_str=str or py2_str=unicode? The former breaks code assuming that it's unicode and the latter doesn't really solve anything: stuff will still break when language_level=3 becomes the default. My proposal is a new setting language_level=3str (meaning: everything that language_level=3 does, except unicode_literals) and make that the default. That way, you keep full compatibility with code already setting the language_level. You also have reasonably good chances that code that currently uses the implicit language_level=2 will continue to work with language_level=3str. From nathan12343 at gmail.com Fri Aug 31 10:51:00 2018 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Fri, 31 Aug 2018 09:51:00 -0500 Subject: [Cython] OpenMP 4.5 array reductions Message-ID: Hi all, I'm curious if there would be any interest in adding support for OpenMP 4.5 array reduction in the cython compiler or alternatively detecting these cases and raising a cython compiler error. Currently cython is generating code that will compile but might lead to race conditions. See: https://github.com/cython/cython/issues/2316 https://github.com/cython/cython/issues/1504 The trouble with fixing this in the cython compiler is that adding the appropriate OpenMP pragmas might generate code that will no longer compile on compilers that don't support OpenMP 4.5. However perhaps that's a better alternative than the status quo, which is generating code that might produce random results. I'd very much appreciate any feedback or advice here as this is currently blocking our ability to easily add OpenMP to our cython code in places where we'd like threads to do parallel reductions on large arrays. I would also not be surprised if there is code in the wild that is racy and silently producing incorrect results. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: