Thanks. I will see if I manage to make a PR next week.

It will silently ignore that os.isatty(fh.fileno()) failed. But write will still be set because of the

             write = self._write_binary 

line above it. No writing actually happens until further down either way.

I think I'll restructure that. It took me a bit of staring to work out that I hadn't forgotten to set write for either isatty() returns false or it fails.

In case you are using vim: I can recommend creating a snippet for ultisnips for this use-case! :)

Glad it's solved!

Hi! I package python-utils for Arch Linux.

When packaging 2.5.0, I noticed, that now the tests are installed top-level into the site-packages directory. This is a problem, because it will conflict with other packages (it happens from time to time, that packages accidentally install tests globally).

To fix this, the packages parameter for setuptools' setup() needs to be specified in such a way, that it only installs the contents of the utils, but not that of the tests.

Codecov Report

Merging #12 (632a90d) into develop (f65dd4b) will not change coverage. The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop       #12   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          202       202           
  Branches        45        45           
=========================================
  Hits           202       202           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f65dd4b...632a90d. Read the comment docs.

Coverage remained the same at 100.0% when pulling 632a90dfbf9195cb67ea9e8c7248b31ecf88af6d on dvzrv:issues/11 into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

Coverage remained the same at 100.0% when pulling 632a90dfbf9195cb67ea9e8c7248b31ecf88af6d on dvzrv:issues/11 into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

Guess you can now decide whether you would like your glass "half full" or "half empty" :laughing:

Ah lol, just realized that this is a dup implementation of #10

setup.py: Provide an include list for setuptools.find_packages() [1], which is called within setuptools.setup()'s packages parameter. This prevents the tests being picked up as a package and installed top-level in the site-packages directory (conflicting with other packages, that also make this mistake).

Fixes #11

[1] https://packaging.python.org/guides/distributing-packages-using-setuptools/#packages

Hi! I package python-utils for Arch Linux.

When packaging 2.5.0, I noticed, that now the tests are installed top-level into the site-packages directory. This is a problem, because it will conflict with other packages (it happens from time to time, that packages accidentally install tests globally).

To fix this, the packages parameter for setuptools' setup() needs to be specified in such a way, that it only installs the contents of the utils, but not that of the tests.

Codecov Report

Merging #10 (d433290) into develop (f65dd4b) will not change coverage. The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop       #10   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          202       202           
  Branches        45        45           
=========================================
  Hits           202       202           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f65dd4b...d433290. Read the comment docs.

Coverage remained the same at 100.0% when pulling d433290bfb9583619448ca94195fa607412807d7 on mgorny:setup.py-tests into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

setuptools.find_packages() finds all valid packages by default that incidentally includes the test directory that gets installed as global 'tests'. Add an explicit exclude to avoid that.

I just came across some STL files generated by the computational fluid dynamics software Star-CCM+, where numpy-stl fail to load the ASCII STL's.

This old bug in OpenFOAM have two simple examples attached: https://bugs.openfoam.org/view.php?id=516 see the file "cubes.zip". I attach the same file here as a reference: cubes.zip

The ASCII STL's start with " solid", i.e. a whitespace before the word "solid". This puzzles the automatic ASCII/binary detection in numpy-stl and it is attempted to read the file as binary, which fails.

The best descriptions I have found for the STL file format(s) are Wikipedia [1] and a page on fabbers.com [2]. Neither of them are perfectly clear on the validity of this file(s) coming from Star-CCM+... These resources (Wikipedia, Fabbers) are also sometimes in conflict, Wikipedia list tabs as examples of allowed whitespace characters and Fabbers explicitly write that this is not allowed. Fabbers, being an old resource, write that all coordinates must be non-negative, which is rarely enforced today. Wikipedia write that the file must start with the line "solid name", but later they state that whitespace may be used anywhere in the file except within numbers or words...

I then in the end conclude that whitespace are also allowed before the first "solid", and that both of the STL's in the attached file are valid STL's (even though both are really stupid in their own ways).

First I would like to know your thoughts on the validity of the attached STL's.

Then, secondly I do not like the current method of reading ASCII/binary STL's. I can force the reading of a binary STL with mode=Mode.BINARY, but the same is not true for Mode.ASCII, since by code design in stl.py:70 it nevertheless will jump to binary reading, since the first five characters of the file is not "solid"...

What would be the opinions on really having three modes: ASCII, binary and automatic? In ASCII mode it would never fall back to binary, in binary mode it would never fall back to ASCII and in automatic it would make an educated guess on the mode based on the file structure, and possibly fall back to the other mode if the first is failing. Opinions?

It can be possible for me to provide some pull request solving some of this, but I would like to hear your opinion first.

[1] https://en.wikipedia.org/wiki/STL_(file_format) [2] http://www.fabbers.com/tech/STL_Format

X-mas vacation, spent 12h on honor project. Cleaning of code. Superapp is going strong: <img src="https://user-images.githubusercontent.com/4957928/103173843-e5d48280-485d-11eb-907a-e20c9b25fbba.gif" width=200/>

Is the file HalfDonut.stl a valid stl file? solid HalfDonut.stl ... ENDSOLID HalfDonut.stl

An ASCII STL file begins with the line

sold <name>

The file concludes with endsolid <name>

What about case sensitivity of endsolid?

https://en.wikipedia.org/wiki/STL_(file_format)