V5.9.0

[5.9.0] - 2024-04-08

Added

• None Nothing added

Changed

• Enhancement Per user request, I've added the ability to request a keepalive thread in the IOM access method.
  The workspace server has a timeout option (defined in metadata), which usually defaults to 60 minutes. If no interaction
  happens in that amount of time since the last interaction, the Workspace server will terminate itself. I've added an
  option keepalive for the IOM access method that can be defined in the Configuration Definition or on SASsession(keepalive=50) to
  specify you want this thread created and how many minutes in between interactions. So, if you're Workspace server has
  a timeout of 60 min, you can specify 'keepalive' : 50, in your config def to have saspy send a request every 50 min
  so the timeout doesn't happen, and keep your session connected until you terminate it. The default is, of course, the
  current behavior which is no keepalive thread.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.7.0

[5.7.0] - 2024-03-19

Added

• None Nothing added

Changed

• Enhancement Per user request, I've added the ability to CANCEL submit()'ed code in both the IOM and HTTP
  access methods. Until now you would see a message like the following if you tried to interrupt a submit:
  SAS attention handling is not yet supported over IOM. Please enter (T) to terminate SAS or (C) to continue.
  But now, with the ability to cancel long running code, you will see something like this instead:
  Please enter (T) to Terminate SAS or (C) to Cancel submitted code or (W) continue to Wait.
  If you choose 'C' then I can now use the API to tell the server to terminate whatever was being executed and
  come back immediately, so you can then run other code. Also, for IOM, I cancel any code in endsas() so that the
  workspace server terminates immediately instead of only after whatever is running finishes.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.6.0

[5.6.0] - 2024-02-05

Added

• None Nothing added

Changed

• Enhancement Per user request, I've added the ability to have the SASLOG returned from the submit methods
  be HTML with ERROR:, WARNING: and NOTE: lines colorized like in other SAS UI's. This is how the SAS_Kernel for
  Jupyter colors it's LOG and how the log returned in the SAS_Results object in SASPy colors that log too. This
  feature requires the Pygments package, so it is only available if that package in installed, else you get the
  current behavior. The new colorLOG configuration key is how to set this. It's a boolean and defaults to False;
  existing behavior. It can be specified in the Configuration Definition or on SASsession, like any other key.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.5.0

[5.5.0] - 2024-01-09

Added

• None Nothing added

Changed

• Tweak A user contribution enhanced an error case where parsing an empty log due to the SAS session being terminated returned a less than helpful error in the exception. This now would return a clear error as to the problem.

• Enhancement Regarding a SAS process unexpectedly terminating out from under SASPy, you may have seen this or a similar error message before: "No SAS process attached. SAS process has terminated unexpectedly." along with an arbitrary exception.
  I've enhanced this case, like many other situations to now throw a new exception, SASIOConnectionTerminated, and to log the message(s) previously returned (logger.fatal()). This should really have always been an exception as it is a fatal case where the SAS session is no longer functional, since there's no SAS process connected anymore.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

New Contributors

• @bagerard made their first contribution in #569
• @Sleemanmunk made their first contribution in #573

V5.4.4

[5.4.4] - 2023-11-02

Added

• None Nothing added

Changed

• Tweak Databricks finally enabled IPython support which allows for HTML rendering from w/in SASPy,
  like in both Jupyter and Zeppelin (Zeppelin has its own rendering, but SASPy supports it). So now
  display='databricks' will just use the same code as display='jupyter' so HTML can finally be rendered
  for you by SASPy instead of having to run batch mode to get the HTML returned to you and then you having
  to pass it to their displayHTML() method.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.4.3

[5.4.3] - 2023-10-27

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fixed The upload method wasn't validating that the file was uploaded successfully after the fact.
  It has a number of checks up front, and if there's a failure, it could return Success=False, but each
  access method is different and they didn't each get a failure the same way. So I added a more explicit
  validation after the upload is completed, to prove the file really made it or not. For the HTTP access
  method, I also mitigated a situation where the Compute server process could be killed for trying to
  access a restricted path. Now that just gets a clean failure with a message about the problem.

Removed

• None Nothing removed

V5.4.2

[5.4.2] - 2023-10-18

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fixed Found a SAS code gen syntax error in the HTTP access method causing an error in the log
  for sd2df. Needed to quote the fileref in a function. So, fixed that syntax error in that method.

Removed

• None Nothing removed

V5.4.1

[5.4.1] - 2023-10-06

Added

• None Nothing added

Changed

• Tweak Added to the doc for the HTTP access method, adding the 'refreshtoken' keyword which goes along with the
  'authtoken' keyword if you did your own authentication to SASLogon. Refreshtoken was added when authtoken was, I just
  didn't get it in the doc then.

Fixed

• Fixed Based upon Issue 562, I enhanced sd2df() to allow you to provide 'errors=' as a keyword parameter which is
  used in the decode() method when converting the bytes being streamed across to characters. The errors keyword determines
  how transcoding failures are handled; the default being failure. See bytes.decode() in the Python doc for valid values.

Removed

• None Nothing removed

V5.4.0

[5.4.0] - 2023-09-27

Added

• None Nothing added

Changed

• Tweak Changed the doc for saslib() to show how to deassign a libref using this method, as well
  as how it's already doc'ed for assigning librefs. Nothing changed with the method, just documenting how to use
  it for both assign and deassign.

Fixed

• Fixed An internal user found a bug with sd2df() where it was converting character variables values of
  'NA' in the SAS Data Set to NaN in the dataframe instead of them being the string 'NA'. This turned out to
  be due to the interaction of the na_values={...} dictionary I pass in, since I need to normalize the 30ish
  different MISSING Values that SAS has, to individual values to provide Pandas so they are processed correctly.
  The problem, however, is that the default value of keep_default_na= being True, appends my list to Pandas
  list of what it thinks values are for NaN's instead of only using my list. The file is to specify keep_default_na=True
  as well as provide my list via na_values={...}. That is fixed in this release.

Removed

• None Nothing removed

V5.3.0

[5.3.0] - 2023-08-29

Added

• None Nothing added

Changed

• Tweak Changed the value of Context in the HTTP config definitions in the example sascfg.py file to use
  the more likely SAS Studio compute context. This has no effect on any code. It's just an example configuration.

• Enhanced df2sd() now raises an exception (SASDFNamesToLongError) if any of the column names are longer than 32 bytes,
  in the SAS Session encoding, since the data step will fail for those columns and produce errors in the log, but SAS still create
  the SAS Data set, incorrectly. Previously, df2sd returned the SASData object, and issued a message about finding Errors in the log,
  but didn't fail. The resultant SAS Data Set wasn't correct so checking for this and raising the exception is what should happen.
  I also write a message with each column name that is too long, so you know which one(s) need to be changed. And remember, SAS's
  restriction on these names is 32 bytes in the SAS Session encoding, and not necessarily 32 characters of utf-8 from Python.

Fixed

• Fixed I found a bug in the code that parses the authinfo file to find the authkey. It was using startswith(authkey)
  to find the line to use, for the user and password. But startswith() isn't looking at the first word, only so many characters.
  This could result in using the wrong line from the authinfo file. For instance, if you had a line with the authkey of tom1 and
  another line further in the file with authkey of tom, then looking for authkey='tom' would use the first line with tom1 for the
  credentials instead of the correct line starting with tom. Simple fix to parse it correctly so it compares the whole first
  word of the line now.

Removed

• None Nothing removed