Saspy

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

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

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 finds 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

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 wnt 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

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' 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

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 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