From stefan_ml at behnel.de Sun Oct 1 13:12:00 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 1 Oct 2017 19:12:00 +0200 Subject: [Cython] Cython 0.27.1 released Message-ID: <3890254d-4cd9-728a-c22e-b0b0dadd32a7@behnel.de> Hi all, the new features in 0.27 introduced a couple of regressions that Robert and I have been hunting down during the last days. Thanks everyone for reporting bugs and helping to isolate them. I just released 0.27.1 with quite a number of fixes. The biggest change is that PEP-489 support (multi-step module initialisation) has been disabled due to incompatibilities with existing code. This should resolve many of the import issues that other projects have run into with the last release. https://pypi.python.org/pypi/Cython/0.27.1 Changelog: https://github.com/cython/cython/blob/0.27.1/CHANGES.rst Have fun, Stefan From dalcinl at gmail.com Fri Oct 13 15:42:04 2017 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Fri, 13 Oct 2017 22:42:04 +0300 Subject: [Cython] Issues with CYTHON_FALLTHROUGH Message-ID: This is from a conda-forge build of petsc4py on Travis-CI with "osx_image: xcode6.4" https://travis-ci.org/conda-forge/petsc4py-feedstock/jobs/287563030 Maybe a better definition is the one below? #ifndef CYTHON_FALLTHROUGH #if defined(__clang__) && __has_attribute(fallthrough) #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) #elif defined(__GNUC__) && defined(__attribute__) #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) #else #define CYTHON_FALLTHROUGH #endif #endif -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 From jdemeyer at cage.ugent.be Fri Oct 13 15:58:41 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Fri, 13 Oct 2017 21:58:41 +0200 Subject: [Cython] Issues with CYTHON_FALLTHROUGH In-Reply-To: References: Message-ID: <59E11AF1.4040204@cage.ugent.be> See also https://github.com/cython/cython/pull/1930 (which may be a different issue) From stefan_ml at behnel.de Fri Oct 13 18:22:10 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 14 Oct 2017 00:22:10 +0200 Subject: [Cython] Issues with CYTHON_FALLTHROUGH In-Reply-To: References: Message-ID: Lisandro Dalcin schrieb am 13.10.2017 um 21:42: > This is from a conda-forge build of petsc4py on Travis-CI with > "osx_image: xcode6.4" > > https://travis-ci.org/conda-forge/petsc4py-feedstock/jobs/287563030 > > > Maybe a better definition is the one below? > > #ifndef CYTHON_FALLTHROUGH > #if defined(__clang__) && __has_attribute(fallthrough) > #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) > #elif defined(__GNUC__) && defined(__attribute__) > #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) > #else > #define CYTHON_FALLTHROUGH > #endif > #endif Applied it here: https://github.com/cython/cython/commit/207d694ac2a580f02b28e216d0843308f5ad129b Stefan From dalcinl at gmail.com Sat Oct 14 09:03:05 2017 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Sat, 14 Oct 2017 16:03:05 +0300 Subject: [Cython] Issues with CYTHON_FALLTHROUGH In-Reply-To: References: Message-ID: Folks, let me fix the the CYTHON_FALLTHROUGH the right way. Additionally, I'll extend the Travis-CI build matrix with python 2/3 and a couple of xcode images. On 14 October 2017 at 01:22, Stefan Behnel wrote: > Lisandro Dalcin schrieb am 13.10.2017 um 21:42: >> This is from a conda-forge build of petsc4py on Travis-CI with >> "osx_image: xcode6.4" >> >> https://travis-ci.org/conda-forge/petsc4py-feedstock/jobs/287563030 >> >> >> Maybe a better definition is the one below? >> >> #ifndef CYTHON_FALLTHROUGH >> #if defined(__clang__) && __has_attribute(fallthrough) >> #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) >> #elif defined(__GNUC__) && defined(__attribute__) >> #define CYTHON_FALLTHROUGH __attribute__((fallthrough)) >> #else >> #define CYTHON_FALLTHROUGH >> #endif >> #endif > > Applied it here: > > https://github.com/cython/cython/commit/207d694ac2a580f02b28e216d0843308f5ad129b > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459 From stefan_ml at behnel.de Sat Oct 14 10:53:49 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 14 Oct 2017 16:53:49 +0200 Subject: [Cython] Issues with CYTHON_FALLTHROUGH In-Reply-To: References: Message-ID: <459eb176-7aca-f600-2760-ffb3925594d4@behnel.de> Lisandro Dalcin schrieb am 14.10.2017 um 15:03: > Folks, let me fix the the CYTHON_FALLTHROUGH the right way. > Additionally, I'll extend the Travis-CI build matrix with python 2/3 > and a couple of xcode images. Go for it. I was planning to release 0.27.2 shortly, so I'll just wait for your PR and then get it out. Stefan From stefan_ml at behnel.de Sun Oct 22 11:31:14 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 22 Oct 2017 17:31:14 +0200 Subject: [Cython] Cython 0.27.2 released Message-ID: Hi all, I just released 0.27.2 with some more bug fixes. Upgrading from 0.27.[01] is recommended. https://pypi.python.org/pypi/Cython/0.27.2 Changelog: https://github.com/cython/cython/blob/0.27.2/CHANGES.rst Have fun, Stefan From jdemeyer at cage.ugent.be Wed Oct 25 08:24:48 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Wed, 25 Oct 2017 14:24:48 +0200 Subject: [Cython] Why does embed-position use relative filenames? Message-ID: <59F08290.9040506@cage.ugent.be> When Cython is run with the --embed-position option (or when Cython.Compiler.Options.embed_pos_in_docstring is true), Cython writes headers in the docstring like File: sage/rings/integer.pyx (starting at line 358) The filenames that Cython uses here are always made relative to the current working directory. This is annoying for tools which extract this information for introspection. It would be more useful to just write the path as-is instead of making it relative. It would be easy to change this behaviour in Cython but I was wondering if there is a specific reason for these relative paths. From erik.m.bray at gmail.com Wed Oct 25 08:42:27 2017 From: erik.m.bray at gmail.com (Erik Bray) Date: Wed, 25 Oct 2017 14:42:27 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: <59F08290.9040506@cage.ugent.be> References: <59F08290.9040506@cage.ugent.be> Message-ID: On Wed, Oct 25, 2017 at 2:24 PM, Jeroen Demeyer wrote: > When Cython is run with the --embed-position option (or when > Cython.Compiler.Options.embed_pos_in_docstring is true), Cython writes > headers in the docstring like > > File: sage/rings/integer.pyx (starting at line 358) > > The filenames that Cython uses here are always made relative to the current > working directory. This is annoying for tools which extract this information > for introspection. It would be more useful to just write the path as-is > instead of making it relative. > > It would be easy to change this behaviour in Cython but I was wondering if > there is a specific reason for these relative paths. IMO the relative paths make more sense in a way, because when the module is installed the path is relative to the file's location relative to its `sys.path` entry. If it defaulted to absolute paths then it would get `/path/to/my/source/code/package/module.py` baked into it, which is deceptive if the module is then installed, say, to `site-packages`. That's just my guess as to why it's a relative path by default. I'm not saying it's always necessarily the best choice--it would be nice if there were a compiler directive to change this. Erik From jdemeyer at cage.ugent.be Wed Oct 25 08:50:43 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Wed, 25 Oct 2017 14:50:43 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: References: <59F08290.9040506@cage.ugent.be> Message-ID: <59F088A3.3070302@cage.ugent.be> On 2017-10-25 14:42, Erik Bray wrote: > IMO the relative paths make more sense in a way, because when the > module is installed the path is relative to the file's location > relative to its `sys.path` entry. > > If it defaulted to absolute paths I didn't say that it should default to absolute paths. I am saying that it should take the path how it received from the caller. Don't make it relative or absolute. From erik.m.bray at gmail.com Wed Oct 25 09:36:15 2017 From: erik.m.bray at gmail.com (Erik Bray) Date: Wed, 25 Oct 2017 15:36:15 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: <59F088A3.3070302@cage.ugent.be> References: <59F08290.9040506@cage.ugent.be> <59F088A3.3070302@cage.ugent.be> Message-ID: On Wed, Oct 25, 2017 at 2:50 PM, Jeroen Demeyer wrote: > On 2017-10-25 14:42, Erik Bray wrote: >> >> IMO the relative paths make more sense in a way, because when the >> module is installed the path is relative to the file's location >> relative to its `sys.path` entry. >> >> If it defaulted to absolute paths > > > I didn't say that it should default to absolute paths. I am saying that it > should take the path how it received from the caller. Don't make it relative > or absolute. I see--I agree, that would make the most sense. I was implying you thought the default should be absolute; just giving a reason it might make sense in the common case to use relative paths. Agreed that ideally it should *not* convert a given absolute path to relative. From erik.m.bray at gmail.com Wed Oct 25 09:36:16 2017 From: erik.m.bray at gmail.com (Erik Bray) Date: Wed, 25 Oct 2017 15:36:16 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: <59F088A3.3070302@cage.ugent.be> References: <59F08290.9040506@cage.ugent.be> <59F088A3.3070302@cage.ugent.be> Message-ID: On Wed, Oct 25, 2017 at 2:50 PM, Jeroen Demeyer wrote: > On 2017-10-25 14:42, Erik Bray wrote: >> >> IMO the relative paths make more sense in a way, because when the >> module is installed the path is relative to the file's location >> relative to its `sys.path` entry. >> >> If it defaulted to absolute paths > > > I didn't say that it should default to absolute paths. I am saying that it > should take the path how it received from the caller. Don't make it relative > or absolute. I see--I agree, that would make the most sense. I was implying you thought the default should be absolute; just giving a reason it might make sense in the common case to use relative paths. Agreed that ideally it should *not* convert a given absolute path to relative. From stefan_ml at behnel.de Wed Oct 25 10:45:14 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 25 Oct 2017 16:45:14 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: <59F088A3.3070302@cage.ugent.be> References: <59F08290.9040506@cage.ugent.be> <59F088A3.3070302@cage.ugent.be> Message-ID: Jeroen Demeyer schrieb am 25.10.2017 um 14:50: > On 2017-10-25 14:42, Erik Bray wrote: >> IMO the relative paths make more sense in a way, because when the >> module is installed the path is relative to the file's location >> relative to its `sys.path` entry. >> >> If it defaulted to absolute paths > > I didn't say that it should default to absolute paths. I am saying that it > should take the path how it received from the caller. Don't make it > relative or absolute. There is usually a mix of absolute *and* relative paths in the compilation, e.g. for files that are included, found via include/pythonpath, referenced relative to the current file, etc. That makes it 'difficult' to put anything consistent into the files. As Erik mentioned, absolute file paths are also somewhere between useless and misleading after installation. Plus, it's usually not a good idea to leak information about the developers' home directory structure into the generated C code. Those are the reasons why there is a strong preference for relative paths in Cython in general. In fact, it's quite actively trying to avoid writing absolute paths into the generated files. I could imagine doing something at runtime to construct the then valid absolute paths, but usually, source files won't actually be available at runtime anyway, so that's also not all that useful. In short: it's far from obvious to me if and how this should be improved. Stefan From jdemeyer at cage.ugent.be Fri Oct 27 05:35:12 2017 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Fri, 27 Oct 2017 11:35:12 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: References: <59F08290.9040506@cage.ugent.be> <59F088A3.3070302@cage.ugent.be> Message-ID: <59F2FDD0.4050803@cage.ugent.be> My use case is for calling Cython at runtime. For example, using cython.inline or %%cython or the SageMath-specific cython() function. In that case, absolute paths make the most sense since you want to support the user running Cython somewhere and then doing chdir(). Perhaps we could keep the default of relativizing the paths but support a parameter like cython --embed-position=abspath From erik.m.bray at gmail.com Fri Oct 27 10:28:04 2017 From: erik.m.bray at gmail.com (Erik Bray) Date: Fri, 27 Oct 2017 16:28:04 +0200 Subject: [Cython] Why does embed-position use relative filenames? In-Reply-To: <59F2FDD0.4050803@cage.ugent.be> References: <59F08290.9040506@cage.ugent.be> <59F088A3.3070302@cage.ugent.be> <59F2FDD0.4050803@cage.ugent.be> Message-ID: On Fri, Oct 27, 2017 at 11:35 AM, Jeroen Demeyer wrote: > My use case is for calling Cython at runtime. For example, using > cython.inline or %%cython or the SageMath-specific cython() function. In > that case, absolute paths make the most sense since you want to support the > user running Cython somewhere and then doing chdir(). > > Perhaps we could keep the default of relativizing the paths but support a > parameter like > > cython --embed-position=abspath +1 That seems like a straightforward solution that should make everyone happy.