V5.103.1

[5.103.1] - 2025-07-08

Added

• None Nothing Added

Changed

• Enhanced The HTTP Access Method (for Viya) has some places where it has to make an HTTP call in a loop. There were some of these where I was doing connect() and close() on the connection, inside the loop. Other places I wasn't. There's no need to have those in the loops, so I removed that from the places it was doing those. I also changed upload from doing 'chunked' http transfer manually, to having it done by the http request call itself. I also added try/except around all of the http request calls that didn't have it, to handle unexpected failures better.

Fixed

• None Nothing Fixed

Removed

• None Nothing removed

[5.103.0] - 2025-04-15

Added

• None Nothing Added

V5.103.0

[5.103.0] - 2025-04-15

Added

• None Nothing Added

Changed

• Enhanced The submit*() methods of the HTTP Access Method (for Viya) include a GETstatusDelay= option for delaying the HTTP calls to see if the code is finished, which happen in a loop until done. Once done the LOG and LST can then be retrieved. This was implemented as a sleep() call in the loop checking the status. I’ve found that the API call can take a wait= value suchthat it is a synchronous call with a timeout. I’ve changed to provide the GETstatusDelay value to the API call instead of being asleep delay in the python code. This will improve this loop be eliminating excessive calls while at the same time being more performant since wait= will return as soon as the job finishes, while sleep will sleep that whole time before making another status call. I’ve changed the default value of GETstatusDelay from 0 to 30 seconds to take advantage of this functionality, so it will be used by default. GETstatusDelay is no longer required to eliminate excessive http status calls, while returning as soon as the code finishes.

Fixed

• None Nothing Fixed

Removed

• None Nothing removed

V5.102.2

[5.102.2] - 2025-03-27

Added

• None Nothing Added

Changed

• None Nothing Changed

Fixed

• Fix Issue #640 found an edge case in sd2df where a row was dropped for a missing value in a single column data set for IOM
  and HTTP. STDIO didn't have the problem. Pandas read_csv required a column separator for that one case even though it didn't for
  cases with more than one column, even for the last column. I fixed the stream of data being provided to pandas so it handled
  this case.

Removed

• None Nothing removed

V5.102.1

Changelog

[5.102.1] - 2025-02-28

Added

• Enhancement PR #635 was contributed by a new contributor @gregorywaynepower who enhanced the install instructions for installing
  saspy from other package manages and enhanced the conda instructions as well. Appreciate it!

Changed

• None Nothing Changed

Fixed

• Fix Issue #634 was fixed in this release. The read_csv() and write_csv() methods generated a filename statement with double
  quotes around the physical path. That’s fine unless there are special characters that can be configused with marco variables; ‘&’
  for instance. I fixed this to use single quotes which won’t let the SAS parser think there are embedded marco variables to resolve
  in the path specification.

Removed

• None Nothing removed

New Contributors

• @gregorywaynepower made their first contribution in #635

V5.102.0

[5.102.0] - 2025-02-07

Added

• Enhancement Per user request (#620) I’ve added a *kwargs parameter to the Submit() methods for the IOM Access Method, reset= which resets the LanguageService to an initial state with respect to token scanning; the default is False. This isn't something needed normally, but the API provides it so I added the ability to call it if needed.

Changed

• Enhancement I’ve changed the method for acquiring the local IP address of the client for the SSH access method (STDIO over SSH) from using nslookup to using a a socket connect/close (to the remote host) to get the IP. This was a problem with internal systems that happened w/ a VPN application that no longer registers client machines w/ DNS such that the previous method didn’t resolve the hostname. This should cause no changes or regressions.

Fixed

• Fix From another internal consumer, I’ve fixed a bug in the HTTP access method around interrupt handling for submit*() methods. When processing a keyboard interrupt in submit, while waiting for the code to complete, the user is prompted with choices to take; Cancel the submitted code, Quit waiting for the results, or ignore – continue to Wait. Cancel is a new feature in this access method, and for the case where Prompt=False (in the configuration file), where there can be no prompting, Cancel is the default for this interrupt. What has been changed/fixed is that in the case of Prompt=False and this interrupt happening and Canceling the submitted statements, that interrupt was not then being raised so the calling code (Prompt=False is used for non-interactive scripts) could catch that and do what was needed from the application. For the interactive case where the prompt is displayed, there is no change. So, for the case where Prompt=False and a keyboard interrupt (ctl-C) is taken in submit, the statements are Canceled (no change with that), and the interrupt is percolated to the caller (this is the change), instead of just returning.

Removed

• None Nothing removed

V5.101.1

[5.101.1] - 2024-12-20

Added

• Enhancement For an internal request to get around a VPN DNS problem, I've enhanced the way I try to get
  the local IP address for the Python machine, when using the SSH access method to connect to a remote server.
  So when the local machine isn't registered in DNS, this can get the local IP to use w/out requiring setting the
  localhost key in your configuration. localhost will still be used if provided.

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.101.0

[5.101.0] - 2024-11-05

Added

• Enhancement For an internal request to get data set information, like date time created/modified, ...
  I added a method on the SASdata object called attrs which returns a 1 row dataframe with each of the attributes
  returned by the ATTRN and ATTRC functions. Mostly they are character or numeric, but the create/modified are
  returned as timestamps. This provides an easy programmatic way to access any of these values.

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.100.4

[5.100.4] - 2024-10-28

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Tweak This was from an internal reported issue. I noticed 2 places where I was submitting code internally where
  I was missing the results='text' that I use for internal code submissions that don't need ODS results. For an unusual
  (not user case) reason that was causing them a problem. There's no issue reported from the field for this, so just
  cleaning up these 2 submits so they are the same as all of the others.

Removed

• None Nothing removed

V5.100.3

[5.100.3] - 2024-09-10

Added

• Enhancement I added the timestamp of when the SAS Session was started to the output when submitting the SASsession Object.
  See SASsession started below:

>>> sas
Access Method         = IOM
SAS Config name       = iomj
SAS Config file       = /opt/tom/github/saspy/saspy/sascfg_personal.py
WORK Path             = /sastmp/SAS_work7AD4000A185A_tom64-7/SAS_workA74A000A185A_tom64-7/
SAS Version           = 9.04.01M8P01182023
SASPy Version         = 5.100.3
Teach me SAS          = False
Batch                 = False
Results               = Pandas
SAS Session Encoding  = utf-8
Python Encoding value = utf_8
SAS process Pid value = 661594
SASsession started    = Tue Sep 10 13:52:19 2024

Changed

• None Nothing changed

Fixed

• Fix From Issue #516, I reworked how SASPy looks through the SASLOG to see if there was an ERROR, to set the
  SASsession attreibute, sas.check_error_log, to True. The usual 'ERROR:' that starts a line in the SASLOG sometimes
  has line number/col number embedded in it, though that's not the usual case. I reworked all of the places looking for
  ERROR: in the log to use a better regex expression that finda both that case and the other; for instance:
  ERROR 180-322: Statement is not valid or it is used out of proper order.

Removed

• None Nothing removed

V5.100.2

[5.100.2] - 2024-07-30

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fix The user contributed method sd2pq() had a bug in that the signature had a default dictionary declared, but that persists as an independent object, and the method conditionally assigns other key:values to it which then persist, incorrectly, in subsequent calls. See issue 611 for details. This version fixes that by defaulting to None in the signature and using a local variable to provide the actual defaults and other values.

• Fix Per issue 612, I've added parquet as an optional requirement for the SASPy install, so pyarrow can be conditionally installed if wanting to use the new user contributed sd2pq() method. I also went ahead and added a conditional install for pandas, via pandas, since I never added that to the condition install list and it's also not a requirement except for if using the sd2df() and df2sd() methods. This doesn't affect any behavior.

Removed

• None Nothing removed