[Bug]: TradingClient.get_clock() results in a positional argument TypeError

[dlewisd11]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

After upgrading to alpaca-py 0.6.0, a call to TradingClient.get_clock results in a positional argument TypeError. Here is my summarized code (I've removed my api keys):

from alpaca.trading.client import TradingClient trading_client = TradingClient(api_key=apiKeyID, secret_key=secretKey, paper=paperAccount) trading_client.get_clock()

Here is the stack trace I am getting:

2022-15-09 09:41:47.252 api.isMarketOpen Traceback (most recent call last): File "api.py", line 35, in isMarketOpen return trading_client.get_clock().is_open File ".../alpaca/trading/client.py", line 375, in get_clock return Clock(response) File "pydantic/main.py", line 332, in pydantic.main.BaseModel.__init__ TypeError: __init__() takes exactly 1 positional argument (2 given)

Expected Behavior

When I run the code cited above, a Clock object should be returned by the TradingClient.get_clock() method. This should not throw an exception.

SDK Version I encountered this issue in

alpaca-py version 0.6.0

Steps To Reproduce

1.) Running python 3.10.4, I execute the code cited above
2.) Error received

Filled out the Steps to Reproduce section?

• I have entered valid steps to reproduce my issue or have attached a minimally reproducible case in code that shows my issue happening; and understand that without this my issue will be flagged as invalid and closed after 30 days.

Anything else?

N/A

[impredicative]

To confirm, this worked fine with v0.5.5. The version of pydantic remains unchanged at v1.10.2.

The change looks to be here. The old code used Clock(**self.get("/clock")) but the new code looks to use Clock(self.get("/clock")).

There really should exist unit tests for this functionality. It should not be released without such tests passing. Even in the absence of a unit test, a type checker such as mypy alone ought to have been able to detect this bug. Tagging @haxdds

[impredicative]

This looks to be fixed in v0.6.1 which had been released.

[haxdds]

Thank you @impredicative!