diff --git a/README.md b/README.md index 2b0b6b14d6bf..6658d4673949 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ Each service might have a number of libraries available from each of the followi ### Client: New Releases -New wave of packages that we are announcing as **GA** and several that are currently releasing in **preview**. These libraries allow you to use and consume existing resources and interact with them, for example: upload a blob. These libraries share a number of core functionalities such as: retries, logging, transport protocols, authentication protocols, etc. that can be found in the [azure-core](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/core/azure-core) library. You can learn more about these libraries by reading guidelines that they follow [here](https://azure.github.io/azure-sdk/python_introduction.html). +New wave of packages that we are announcing as **GA** and several that are currently releasing in **preview**. These libraries allow you to use and consume existing resources and interact with them, for example: upload a blob. These libraries share a number of core functionalities such as: retries, logging, transport protocols, authentication protocols, etc. that can be found in the [azure-core](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/core/azure-core) library. You can learn more about these libraries by reading guidelines that they follow [here](https://azure.github.io/azure-sdk/python/guidelines/index.html). You can find the [most up to date list of all of the new packages on our page](https://azure.github.io/azure-sdk/releases/latest/index.html#python-packages) @@ -32,11 +32,11 @@ You can find the [most up to date list of all of the new packages on our page](h ### Client: Previous Versions -Last stable versions of packages that have been provided for usage with Azure and are production-ready. These libraries provide you with similar functionalities to the Preview ones as they allow you to use and consume existing resources and interact with them, for example: upload a blob. They might not implement the [guidelines](https://azure.github.io/azure-sdk/python_introduction.html) or have the same feature set as the Novemeber releases. They do however offer wider coverage of services. +Last stable versions of packages that have been provided for usage with Azure and are production-ready. These libraries provide you with similar functionalities to the Preview ones as they allow you to use and consume existing resources and interact with them, for example: upload a blob. They might not implement the [guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) or have the same feature set as the Novemeber releases. They do however offer wider coverage of services. ### Management: New Releases -A new set of management libraries that follow the [Azure SDK Design Guidelines for Python](https://azure.github.io/azure-sdk/python/guidelines/) are now available. These new libraries provide a number of core capabilities that are shared amongst all Azure SDKs, including the intuitive Azure Identity library, an HTTP Pipeline with custom policies, error-handling, distributed tracing, and much more. -Documentation and code samples for these new libraries can be found [here](https://aka.ms/azsdk/python/mgmt). In addition, a migration guide that shows how to transition from older versions of libraries is located [here](https://github.com/Azure/azure-sdk-for-python/blob/master/doc/sphinx/mgmt_quickstart.rst#migration-guide). +A new set of management libraries that follow the [Azure SDK Design Guidelines for Python](https://azure.github.io/azure-sdk/python/guidelines/) are now available. These new libraries provide a number of core capabilities that are shared amongst all Azure SDKs, including the intuitive Azure Identity library, an HTTP Pipeline with custom policies, error-handling, distributed tracing, and much more. +Documentation and code samples for these new libraries can be found [here](https://aka.ms/azsdk/python/mgmt). In addition, a migration guide that shows how to transition from older versions of libraries is located [here](https://github.com/Azure/azure-sdk-for-python/blob/master/doc/sphinx/mgmt_quickstart.rst#migration-guide). You can find the [most up to date list of all of the new packages on our page](https://azure.github.io/azure-sdk/releases/latest/mgmt/python.html) diff --git a/scripts/pylint_custom_plugin/README.md b/scripts/pylint_custom_plugin/README.md index 963a3d098916..3d01aab8447e 100644 --- a/scripts/pylint_custom_plugin/README.md +++ b/scripts/pylint_custom_plugin/README.md @@ -1,7 +1,7 @@ -## Linting the Guidelines +## Linting the Guidelines In order to lint for the guidelines, you must make sure you are using the pylintrc file. -It is recommended you run pylint at the library package level to be consistent with how the CI runs pylint. +It is recommended you run pylint at the library package level to be consistent with how the CI runs pylint. Check that you are running pylint version >=2.5.2 and astroid version >=2.4.1. @@ -35,7 +35,7 @@ Check that you are running pylint version >=2.5.2 and astroid version >=2.4.1. ``` The pylint custom checkers for SDK guidelines fall into messages range C4717 - C4738. -You will know you came across a custom checker if it contains a link to the guidelines. +You will know you came across a custom checker if it contains a link to the guidelines. In the case of a false positive, use the disable command to remove the pylint error. @@ -46,15 +46,15 @@ In the case of a false positive, use the disable command to remove the pylint er | client-method-should-not-use-static-method | Use module level functions instead. | # pylint:disable=connection-string-should-not-be-constructor-param | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | | missing-client-constructor-parameter-credential | Add a credential parameter to the client constructor. Do not use plural form "credentials". | # pylint:disable=missing-client-constructor-parameter-credential | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | | missing-client-constructor-parameter-kwargs | Add a **kwargs parameter to the client constructor. | # pylint:disable=missing-client-constructor-parameter-kwargs | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | -| client-method-has-more-than-5-positional-arguments | Use keyword arguments to reduce number of positional arguments. | # pylint:disable=client-method-has-more-than-5-positional-arguments | [link](https://azure.github.io/azure-sdk/python_introduction.html#method-signatures) | -| client-method-missing-type-annotations | Check that param/return type comments are present or that param/return type annotations are present. Check that you did not mix type comments with type annotations. | # pylint:disable=client-method-missing-type-annotations | [link](https://azure.github.io/azure-sdk/python_introduction.html#types-or-not) | -| client-incorrect-naming-convention | Check that you use... snake_case for variable, function, and method names. Pascal case for types. ALL CAPS for constants. | # pylint:disable=client-incorrect-naming-convention | [link](https://azure.github.io/azure-sdk/python_introduction.html#naming-conventions) | +| client-method-has-more-than-5-positional-arguments | Use keyword arguments to reduce number of positional arguments. | # pylint:disable=client-method-has-more-than-5-positional-arguments | [link]((https://azure.github.io/azure-sdk/python_design.html#method-signatures) | +| client-method-missing-type-annotations | Check that param/return type comments are present or that param/return type annotations are present. Check that you did not mix type comments with type annotations. | # pylint:disable=client-method-missing-type-annotations | [link]((https://azure.github.io/azure-sdk/python_design.html#types-or-not) | +| client-incorrect-naming-convention | Check that you use... snake_case for variable, function, and method names. Pascal case for types. ALL CAPS for constants. | # pylint:disable=client-incorrect-naming-convention | [link]((https://azure.github.io/azure-sdk/python_design.html#naming-conventions) | | client-method-missing-kwargs | Check that any methods that make network calls have a **kwargs parameter. | # pylint:disable=client-method-missing-kwargs | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | | config-missing-kwargs-in-policy | Check that the policies in your configuration function contain a **kwargs parameter. | # pylint:disable=config-missing-kwargs-in-policy | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | | async-client-bad-name | Remove "Async" from your service client's name. | # pylint:disable=async-client-bad-name | [link](https://azure.github.io/azure-sdk/python_design.html#async-support) | | file-needs-copyright-header | Add a copyright header to the top of your file. | # pylint:disable=file-needs-copyright-header | [link](https://azure.github.io/azure-sdk/policies_opensource.html) | -| client-method-name-no-double-underscore | Don't use method names prefixed with "__". | # pylint:disable=client-method-name-no-double-underscore | [link](https://azure.github.io/azure-sdk/python_introduction.html#public-vs-private) | -| specify-parameter-names-in-call | Specify the parameter names when calling methods with more than 2 required positional parameters. e.g. self.get_foo(one, two, three=three, four=four, five=five) | # pylint:disable=specify-parameter-names-in-call | [link](https://azure.github.io/azure-sdk/python_introduction.html#method-signatures) | +| client-method-name-no-double-underscore | Don't use method names prefixed with "__". | # pylint:disable=client-method-name-no-double-underscore | [link]((https://azure.github.io/azure-sdk/python_design.html#public-vs-private) | +| specify-parameter-names-in-call | Specify the parameter names when calling methods with more than 2 required positional parameters. e.g. self.get_foo(one, two, three=three, four=four, five=five) | # pylint:disable=specify-parameter-names-in-call | [link]((https://azure.github.io/azure-sdk/python_design.html#method-signatures) | | connection-string-should-not-be-constructor-param | Remove connection string parameter from client constructor. Create a method that creates the client using a connection string. | # pylint:disable=connection-string-should-not-be-constructor-param | [link](https://azure.github.io/azure-sdk/python_design.html#constructors-and-factory-methods) | | package-name-incorrect | Change your distribution package name to only include dashes, e.g. azure-storage-file-share | # pylint:disable=package-name-incorrect | [link](https://azure.github.io/azure-sdk/python_implementation.html#packaging) | | client-suffix-needed | Service client types should use a "Client" suffix, e.g. BlobClient. | # pylint:disable=client-suffix-needed | [link](https://azure.github.io/azure-sdk/python_design.html#clients) | diff --git a/sdk/core/azure-core/README.md b/sdk/core/azure-core/README.md index 09235c818d70..2c35a1604ef9 100644 --- a/sdk/core/azure-core/README.md +++ b/sdk/core/azure-core/README.md @@ -1,8 +1,8 @@ # Azure Core shared client library for Python -Azure core provides shared exceptions and modules for Python SDK client libraries. -These libraries follow the [Azure SDK Design Guidelines for Python](https://azure.github.io/azure-sdk/python_introduction.html) . +Azure core provides shared exceptions and modules for Python SDK client libraries. +These libraries follow the [Azure SDK Design Guidelines for Python](https://azure.github.io/azure-sdk/python/guidelines/index.html) . If you are a client library developer, please reference [client library developer reference](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/core/azure-core/CLIENT_LIBRARY_DEVELOPER.md) for more information. @@ -10,9 +10,9 @@ If you are a client library developer, please reference [client library develope ## Getting started -Typically, you will not need to install azure core; -it will be installed when you install one of the client libraries using it. -In case you want to install it explicitly (to implement your own client library, for example), +Typically, you will not need to install azure core; +it will be installed when you install one of the client libraries using it. +In case you want to install it explicitly (to implement your own client library, for example), you can find it [here](https://pypi.org/project/azure-core/). ## Key concepts @@ -32,7 +32,7 @@ class AzureError(Exception): super(AzureError, self).__init__(self.message, *args) ``` -*message* is any message (str) to be associated with the exception. +*message* is any message (str) to be associated with the exception. *args* are any additional args to be included with exception. diff --git a/sdk/eventgrid/azure-eventgrid/migration_guide.md b/sdk/eventgrid/azure-eventgrid/migration_guide.md index ac0bfaa42735..5859cd83a1fb 100644 --- a/sdk/eventgrid/azure-eventgrid/migration_guide.md +++ b/sdk/eventgrid/azure-eventgrid/migration_guide.md @@ -25,7 +25,7 @@ To try and improve the development experience across Azure services, a set of un ### Cross Service SDK improvements -The modern Event Grid client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as +The modern Event Grid client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as - a unified logging and diagnostics pipeline offering a common view of the activities across each of the client libraries - using the new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library to share a single authentication approach between clients diff --git a/sdk/eventhub/azure-eventhub/migration_guide.md b/sdk/eventhub/azure-eventhub/migration_guide.md index 6510bfc6b79f..6825179943e6 100644 --- a/sdk/eventhub/azure-eventhub/migration_guide.md +++ b/sdk/eventhub/azure-eventhub/migration_guide.md @@ -23,7 +23,7 @@ A natural question to ask when considering whether or not to adopt a new version There were several areas of consistent feedback expressed across the Azure client library ecosystem. One of the most important is that the client libraries for different Azure services have not had a consistent approach to organization, naming, and API structure. Additionally, many developers have felt that the learning curve was difficult, and the APIs did not offer a good, approachable, and consistent onboarding story for those learning Azure or exploring a specific Azure service. -To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_introduction.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. +To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. ### Cross Service SDK improvements @@ -46,7 +46,7 @@ Refer to the [changelog](https://github.com/Azure/azure-sdk-for-python/blob/mast ### Client hierarchy In the interest of simplifying the API surface, we've made two distinct clients: the `EventHubProducerClient` for sending events and the `EventHubConsumerClient` for receiving events. This is in contrast to the single `EventHubClient` that was used to create senders and receivers. -We've also merged the functionality from `EventProcessorHost` into `EventHubConsumerClient`. +We've also merged the functionality from `EventProcessorHost` into `EventHubConsumerClient`. #### Approachability By having a single entry point for sending, the `EventHubProducerClient` helps with the discoverability of the API @@ -63,8 +63,8 @@ This provides consistency and predictability on the various features of the libr ### Client constructors While we continue to support connection strings when constructing a client, below are the differences in the two versions: -- In v5, we now support the use of Azure Active Directory for authentication. -The new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library allows us +- In v5, we now support the use of Azure Active Directory for authentication. +The new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library allows us to share a single authentication solution between clients of different Azure services. - The option to construct a client using an address of the form `amqps://:@/` is no longer supported in v5. This address is not readily available in the Azure portal or in any tooling and so was subject to human error. We instead recommend using the connection string if you want to use a SAS policy. @@ -74,7 +74,7 @@ In v1: eventhub_client = EventHubClient(address) # Authenticate with connection string -eventhub_client = EventHubClient.from_connection_string(conn_str) +eventhub_client = EventHubClient.from_connection_string(conn_str) # Authenticate the EventProcessorHost and StorageCheckpointLeaseManager eh_config = EventHubConfig(eh_namespace, eventhub_name, user, key, consumer_group="$default") @@ -86,8 +86,8 @@ In v5: # Address is no longer used for authentication. # Authenticate with connection string -producer_client = EventHubProducerClient.from_connection_string(conn_str) -consumer_client = EventHubConsumerClient.from_connection_string(conn_str) +producer_client = EventHubProducerClient.from_connection_string(conn_str) +consumer_client = EventHubConsumerClient.from_connection_string(conn_str) checkpoint_store = BlobCheckpointStore.from_connection_string(storage_conn_str, container_name) consumer_client_with_checkpoint_store = EventHubConsumerClient.from_connection_string(conn_str, consumer_group='$Default', checkpoint_store=checkpoint_store) @@ -130,12 +130,12 @@ event_data_batch.add(EventData('Single message')) producer.send_batch(event_data_batch) ``` -### Receiving events +### Receiving events - The `run` and `stop` methods were previously used since the single `EventHubClient` controlled the lifecycle for all senders and receivers. In v5, the `run` and `stop` methods are deprecated since the `EventHubConsumerClient` controls its own lifecycle. - The `add_receiver` method is no longer used to create receiver clients. Instead, the `EventHubConsumerClient` is used for receiving events. - In v1, the `receive` method returned a list of `EventData`. You would call this method repeatedly every time you want receive a set of events. In v5, the new `receive` method takes user callback to process events and any resulting errors. This way, you call the method once and it continues to process incoming events until you stop it. -- Additionally, we have a method `receive_batch` which behaves the same as `receive`, but calls the user callback with a batch of events instead of single events. +- Additionally, we have a method `receive_batch` which behaves the same as `receive`, but calls the user callback with a batch of events instead of single events. - The same methods can be used whether you want to receive from a single partition or from all partitions. In v1: @@ -160,14 +160,14 @@ with consumer_client: # Receive batch def on_event_batch(partition_context, event_batch): print("Partition {}, Received count: {}".format(partition_context.partition_id, len(event_batch))) - + consumer_client = EventHubConsumerClient.from_connection_string(conn_str, consumer_group, eventhub_name=eh_name) with consumer_client: consumer_client.receive_batch(on_event_batch=on_event_batch, partition_id=partition_id) ``` ### Migrating code from `EventProcessorHost` to `EventHubConsumerClient` for receiving events -In V1, `EventProcessorHost` allowed you to balance the load between multiple instances of +In V1, `EventProcessorHost` allowed you to balance the load between multiple instances of your program when receiving events. In V5, `EventHubConsumerClient` allows you to do the same with the `receive()` method if you diff --git a/sdk/keyvault/azure-keyvault-certificates/migration_guide.md b/sdk/keyvault/azure-keyvault-certificates/migration_guide.md index d04d6f353e27..fbbf9eeab97f 100644 --- a/sdk/keyvault/azure-keyvault-certificates/migration_guide.md +++ b/sdk/keyvault/azure-keyvault-certificates/migration_guide.md @@ -23,11 +23,11 @@ A natural question to ask when considering whether or not to adopt a new version There were several areas of consistent feedback expressed across the Azure client library ecosystem. One of the most important is that the client libraries for different Azure services have not had a consistent approach to organization, naming, and API structure. Additionally, many developers have felt that the learning curve was difficult, and the APIs did not offer a good, approachable, and consistent onboarding story for those learning Azure or exploring a specific Azure service. -To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. +To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. ### Cross Service SDK improvements -The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as +The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as - using the new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library to share a single authentication approach between clients - a unified logging and diagnostics pipeline offering a common view of the activities across each of the client libraries diff --git a/sdk/keyvault/azure-keyvault-keys/migration_guide.md b/sdk/keyvault/azure-keyvault-keys/migration_guide.md index beb763db3113..3b102031c7a8 100644 --- a/sdk/keyvault/azure-keyvault-keys/migration_guide.md +++ b/sdk/keyvault/azure-keyvault-keys/migration_guide.md @@ -24,11 +24,11 @@ A natural question to ask when considering whether or not to adopt a new version There were several areas of consistent feedback expressed across the Azure client library ecosystem. One of the most important is that the client libraries for different Azure services have not had a consistent approach to organization, naming, and API structure. Additionally, many developers have felt that the learning curve was difficult, and the APIs did not offer a good, approachable, and consistent onboarding story for those learning Azure or exploring a specific Azure service. -To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. +To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. ### Cross Service SDK improvements -The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as +The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as - using the new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library to share a single authentication approach between clients - a unified logging and diagnostics pipeline offering a common view of the activities across each of the client libraries diff --git a/sdk/keyvault/azure-keyvault-secrets/migration_guide.md b/sdk/keyvault/azure-keyvault-secrets/migration_guide.md index 61236c6dbf80..8487767e89da 100644 --- a/sdk/keyvault/azure-keyvault-secrets/migration_guide.md +++ b/sdk/keyvault/azure-keyvault-secrets/migration_guide.md @@ -23,11 +23,11 @@ A natural question to ask when considering whether or not to adopt a new version There were several areas of consistent feedback expressed across the Azure client library ecosystem. One of the most important is that the client libraries for different Azure services have not had a consistent approach to organization, naming, and API structure. Additionally, many developers have felt that the learning curve was difficult, and the APIs did not offer a good, approachable, and consistent onboarding story for those learning Azure or exploring a specific Azure service. -To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. +To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) was created for all languages to drive a consistent experience with established API patterns for all services. A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_design.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. ### Cross Service SDK improvements -The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as +The modern Key Vault client library also provides the ability to share in some of the cross-service improvements made to the Azure development experience, such as - using the new [`azure-identity`](https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/README.md) library to share a single authentication approach between clients - a unified logging and diagnostics pipeline offering a common view of the activities across each of the client libraries diff --git a/sdk/servicebus/azure-servicebus/migration_guide.md b/sdk/servicebus/azure-servicebus/migration_guide.md index 186a61156f29..9a07723b8959 100644 --- a/sdk/servicebus/azure-servicebus/migration_guide.md +++ b/sdk/servicebus/azure-servicebus/migration_guide.md @@ -42,7 +42,7 @@ and consistent onboarding story for those learning Azure or exploring a specific To try and improve the development experience across Azure services, a set of uniform [design guidelines](https://azure.github.io/azure-sdk/general_introduction.html) was created for all languages to drive a consistent experience with established API patterns for all services. -A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python_introduction.html) was also introduced to ensure +A set of [Python-specific guidelines](https://azure.github.io/azure-sdk/python/guidelines/index.html) was also introduced to ensure that Python clients have a natural and idiomatic feel with respect to the Python ecosystem. Further details are available in the guidelines for those interested. @@ -144,7 +144,7 @@ with ServiceBusClient.from_connection_string(connstr) as client: ### Sending messages - The `send` method is renamed to `send_messages` following the pattern of using the `messages` suffix in methods that deal with messages. -- You can now pass an array of messages directly in method used to send messages rather than first creating a `BatchMessage` +- You can now pass an array of messages directly in method used to send messages rather than first creating a `BatchMessage` - Sending multiple messages in a single go always had the potential to fail if batch size exceeded the size limit. To help with this, we have a new class `ServiceBusMessageBatch` which helps in creating a batch that will never increase the size limit. In V0.50: @@ -247,7 +247,7 @@ with sender: While in the new version, `session_id` is property on the `ServiceBusMessage`. - Previously `SessionReceiver` class is used for receiving messages from sessionful entities and performing session-related operations. In the new version, `SessionReceiver` has been collapsed into `ServiceBusReceiver` to improve modularity and reduce public API surface. -- `ServiceBusSession` class is introduced to perform session-related operations and it can be approached by property `ServiceBusReceiver.session`. For non-sessionful receivers, `ServiceBusReceiver.session` is `None`. +- `ServiceBusSession` class is introduced to perform session-related operations and it can be approached by property `ServiceBusReceiver.session`. For non-sessionful receivers, `ServiceBusReceiver.session` is `None`. In V0.50: ```python @@ -394,7 +394,7 @@ queues = service_bus_administration_client.list_queues() #### Migrating code from `QueueClient` and `Receiver` to `ServiceBusReceiver` for receiving messages In v0.50, `QueueClient` would be created directly or from the `ServiceBusClient.get_queue` method, -after which user would call `get_receiver` to obtain a receiver, calling `fetch_next` to receive a single +after which user would call `get_receiver` to obtain a receiver, calling `fetch_next` to receive a single batch of messages, or iterate over the receiver to receive continuously. In v7, users should initialize the client via `ServiceBusClient.get_queue_receiver`. Single-batch-receive