[Python] each Configuration instance now has its own dicts

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.

[spacether]

Per this issue: #4389
The dictionaries used in Configuration instances are shared across instances.
This is not the intended function.
Each instance should use its own unique dict to store api_key and api_key_prefix
This PR makes that update and adds a test at samples/client/petstore/python/tests/test_configuration.py for verification

Related issue that may be closed by this PR:

• [BUG] [Python] Default configuration gives unexpected behaviour #3577

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python committee
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11)

[arbelpeled]

Looks good!
Thanks for the quick fix (:

[arbelpeled]

Nice

[TimoMorris]

Thanks for fixing this! 😃🚀

[wing328]

@spacether thanks for the PR, which has been included in the v4.2.2 release: https://twitter.com/oas_generator/status/1201432648544972800

[tomplus]

This is a breaking change. Some libraries use the feature of creating default configuration and this PR removed it. Method Configuration.set_default(cls, default) disappeared. I'll try to restore it in a different way.

[spacether]

Sorry that we broke this functionality. We look forward to your PR.
Can you share more about your use case?
have you considered these solutions:

• storing your configuration inputs in environment variables
• making one configuration instance in a module, then importing it into all the modules which need it

[TimoMorris]

@tomplus Sorry to hear we've caused you difficulties 😞

FWIW I did quite a detailed write-up of the issues I found with the way the behavior around default configurations when I raised issue #3577 (essentially the same as this issue as this one), which you might find helpful to refer to.

Essentially, it wasn't only caching a copy of the first configuration instantiated to use as a default, but it would then always return this default, even if Configuration was called with other parameters explicitly passed. So it was over-strongly enforcing the default.

It seemed to me the expected behavior would be to (at most) cache the first configuration as a default and return this if you called Configuration() with no parameters. Though even that might be unexpected for some users. But to have the class silently ignore different parameters explicitly passed on subsequent calls led to some very confusing and hard-to-trace behavior.

I imagine it would be relatively straightforward to re-implement a set_default() method, or perhaps have a keyword-only argument e.g. set_as_default for the __init__() method. But however it's implemented, it seems to me that in the Pythonic spirit of "explicit is better than implicit" the user should have to opt-in to it, rather than the default-setting/default-getting behavior being 'on' by default.

And I'd agree with @spacether's suggestions that the user implementing the defaulting behaviour in their own code seems better.

[tomplus]

Thanks for the discussion.

I know that it can be implemented in many ways but for me previous implementation was very handy (apart from bugs which were found). I have one server with many API exposed. I was able to create a well-prepared default configuration on startup and then used it without worrying about it.

I think the static method set_default() doesn’t break the principle “explicit is better than implicit” because I have to explicitly set configuration as default configuration.

I'm sending a PR soon.

[tomplus]

Here is my PR #5315, Thanks for reviewing.