HttpUrl.path differs from same-named argument in the factory method

[jojo243]

Initial Checks

• I confirm that I'm using Pydantic V2

Description

When I build a HttpUrl from parts of another HttpUrl (using the HttpUrl.build() method), I frequently stumble across the fact that the parameter for path I should hand to HttpUrl.build() is not the same as the output of existingHttpUrl.path. The .path attribute includes the leading /, whereas the parameter to HttpUrl.build() does not expect it and fills it in automatically.

I'd expect this to be the same. Is this a bug or an expected behaviour?

Example Code

# Minimal, reprocucible example
from pydantic import HttpUrl

path = "foo"
url = HttpUrl.build(
   scheme="https",
   host="test.dev",
   path=path
)

assert url.path == path
# assert "/foo" == "foo"





# Problematic use case: Adding username and password to a given input url
from pydantic import HttpUrl
from os import environ

# user gives any input url
h1 = HttpUrl("https://test.dev/foo")

def addCredsToUrl(h: HttpUrl) -> HttpUrl:
    """Add authentication credentials to given url"""
    return HttpUrl.build(
        scheme=h.scheme,
        host=h.host,
        path=h.path,
        username="John.Doe",
        password="y0urV3ryS€cRetAP!kEy",
    )

addCredsToUrl(h1)  # <--- this will include two // after the host part

Python, Pydantic & OS Version

        pydantic version: 2.6.4
        pydantic-core version: 2.16.3
          pydantic-core build: profile=release pgo=true
                 install path: /home/johannes/.local/lib/python3.8/site-packages/pydantic
               python version: 3.8.10 (default, Nov 22 2023, 10:22:35)  [GCC 9.4.0]
                     platform: Linux-5.11.0-38-generic-x86_64-with-glibc2.29
             related packages: typing_extensions-4.8.0 mypy-1.1.1 mypy-1.1.1 typing_extensions-4.5.0
                       commit: unknown

[fdemmer]

Possibly related: #7186

[sydney-runkle]

@fdemmer,

Hmm, that does seem odd / buggy. I've added the urls tag to this issue - I think this could be addressed with #7186, which you've listed above!