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

V5.100.1

[5.100.1] - 2024-07-17

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fix The HTTP authorization interfaces keep changing and an internal user found a code path that didn't provide the expected behavior. In order to still support older versions of viya 3.x, which don't have the SASPy client_id and only supported user/pw authentication (that's changed in more recent 3.5 versions), I had to use a different internal client_id. However, that client id doesn't support all the things, specifically refresh token in this case, that the SASPy client id supports. The path through authentication in saspy when using user/pw and providing client_id didn't use the client id you provided, but rather used the old internal one. So, this fix simply allows you to provide a client_id (SASPy or other), and user/pw as the means to connect. Authorization Code authentication uses the SASPy id by default (which supports that) as well as with any client_id you provide, so it's only the user/pw case with client_id being provided that had to be fixed; it now uses the client_id you said. Until I no longer have to support the old Viya 3.x versions, you do need to specify client_id='SASPy' (when using user/pw auth) in order to get the refresh token, which I do use to automatically refresh your auth token so you don't have it expire after 1 hour, which they changed it to recently.

Removed

• None Nothing removed

V5.100.0

[5.100.0] - 2024-07-10

Added

• Enhancement Per a user request. I've added support in the sd2df* methods for dealing with SAS dates and datetimes that are out of range of Pandas Timestamps (pandas.Timestamp.min, pandas.Timestamp.max). These values will be converted to NaT in the dataframe. The new feature is to specify a Timestamp value (str(Timestamp)) for the high value and/or low values (tsmin=, tsmax=) to use to replace Nat's with in the dataframe. This works for both SAS datetime and date values. For instance, given a SASdata object: sd.to_df(tsmin='1966-01-03 00:00:00.000000', tsmax='1966-01-03 23:59:59.111111')

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

Note

• This is just a note to acknowledge that the minor version jumped from 15 to 100. What's that about!?
  Well, glad you asked ;) This is the 100th release of SASPy, in under its almost 10 years in existence. So, I just
  thought I'd skip a few minor releases to identify the milestone. It's been a privilege to have created and supported
  SASPy this whole time, and to have helped and supported all of our users who use it!
  Tom