Django-guardian: ANONYMOUS_USER_NAME Tidak ada nilai

Ya, Anda benar, itu memang terlihat cerdik. Perlu cara agar dapat menyetel default ke 'AnonymousUser' tanpa mencegahnya disetel secara eksplisit ke Tidak Ada.

Bagaimana jika saya mengubah kode berikut ini? Ada yang lebih baik? Ini harus menyetel nilai default jika tidak ada yang ditentukan dan memungkinkan secara eksplisit menyetelnya ke Tidak Ada.

try:
    ANONYMOUS_USER_NAME = settings.ANONYMOUS_USER_NAME
except AttributeError:
    try:
        ANONYMOUS_USER_NAME = settings.ANONYMOUS_DEFAULT_USERNAME_VALUE
        warnings.warn("The ANONYMOUS_DEFAULT_USERNAME_VALUE setting has been renamed to ANONYMOUS_USER_NAME.", DeprecationWarning)
    except AttributeError:
        ANONYMOUS_USER_NAME = "AnonymousUser"

Menurut saya, hapus saja dua baris yang saya komentari.

Karena ANONYMOUS_USER_NAME sebenarnya adalah nilai untuk USERNAME_FIELD , ANONYMOUS_USER_NAME bisa berupa email atau apa pun. Dengan demikian, default ke "AnonymousUser" menyesatkan. Selanjutnya, ANONYMOUS_USER_ID memicu fitur dan ANONYMOUS_DEFAULT_USERNAME_VALUE digunakan sebagai nama pengguna. Tapi sekarang, mereka telah digabungkan menjadi satu pengaturan, yang berfungsi sebagai pemicu dan nilai. Jadi tidak ada gunanya memberikan nilai default.

Jadi saya akan tetap berpegang pada:

ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_USER_NAME', None)

if ANONYMOUS_USER_NAME is None:
    ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_DEFAULT_USERNAME_VALUE', None)
    if ANONYMOUS_USER_NAME is not None:
        warnings.warn("[...]", DeprecationWarning)

dan hapus dua garis yang disebutkan sebelumnya.

Saya memiliki perasaan campur aduk tentang sintaks try...except karena, meskipun sebenarnya bukan masalah angka, saya belum pernah melihatnya digunakan untuk pengaturan. Klasik <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) biasanya bekerja dengan cukup baik.

Jika kami tidak memberikan nilai default untuk ANONYMOUS_USER_NAME, ini akan merusak aplikasi yang ada yang menganggap nilai default akan diberikan. yaitu kami telah mengubah perilaku ketika setelan ANONYMOUS_USER_NAME tidak diberikan.

Lalu mengapa tidak beralih ke 1.5.0, menghapus ANONYMOUS_DEFAULT_USERNAME_VALUE dan nilai default, dan memperingatkan tentang perubahan yang melanggar?

Saya yakin niatnya adalah untuk mengizinkan menjalankan Django Guardian tanpa secara otomatis membuat pengguna anonim. Apakah Anda memiliki kasus penggunaan untuk ini? Mengapa tidak mengabaikan pengguna anonim jika Anda tidak menginginkannya?

Saya pikir membuat pengguna anonim secara default adalah hal yang baik, saya tidak melihat alasan mengapa kita harus mengubahnya. Namun kami membutuhkan nilai default ANONYMOUS_USER_NAME agar ini berfungsi. Jika default tidak sesuai untuk aplikasi Anda, Anda selalu dapat mengubahnya.

Sintaks try ... except bagus karena memungkinkan untuk membedakan kasus "Apakah pengaturan ini tidak diberikan?" dan "Apakah setelan ini diberi nilai nol?" - Anda mungkin dapat menggunakan getattr untuk ini, namun menurut saya ini dapat menjadi agak rumit dengan cepat, terutama jika Anda ingin mempertahankan DeprecationWarning. Saya tidak yakin apa yang Anda maksud dengan "meskipun kebenaran bukanlah masalah angka".

Yang saya maksud bukan karena setiap orang melakukan satu hal dengan cara yang benar / lebih baik.

Memaksa pembuatan Pengguna Anonim bisa menjadi cara yang harus dilakukan, tetapi kemudian dokumen harus diperbarui.

Mengenai situasi saya, saya menggunakan bidang email sebagai USERNAME_FIELD default, oleh karena itu keengganan awal saya untuk membuat contoh pengguna anonim. Tapi saya bisa mengatur.

Bersulang. Dan terima kasih telah membiarkan aku menghancurkan pelacurmu.

Teman-teman, saya tidak berpikir bahwa meminta pembuatan pengguna anonim adalah ide yang bagus. Saya telah menggunakan django-guardian untuk waktu yang lama dan memiliki pengguna anonim tidak pernah diperlukan, jadi mengapa mengubahnya sekarang?

Jadi solusi saya yang melibatkan try ... except diberi 2 jempol, namun di mana saya membenarkan solusi ini saya diberi 2 jempol ke bawah. Membingungkan. Karena saya benar-benar tidak melihat sisi negatifnya, dan saya yakin ini adalah cara paling sederhana untuk menyelesaikan regresi tanpa menambahkan regresi baru, saya akan menerapkan solusi ini.

@brianmay Maaf atas kebingungannya. : +1: untuk perbaikannya!