Django-guardian: ANONYMOUS_USER_NAME بلا قيمة

نعم ، أنت على حق ، هذا يبدو مراوغًا. بحاجة إلى طريقة لتكون قادرًا على تعيين "AnonymousUser" بشكل افتراضي دون منع تعيينه بشكل صريح على "بلا".

ماذا لو قمت بتغيير الرمز إلى ما يلي؟ أي تحسن؟ يجب أن يعين هذا القيمة الافتراضية إذا لم يتم تحديد أي شيء ويسمح صراحة بتعيينها على بلا.

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"

أود أن أقول فقط أزل السطرين اللذين علقت عليهما.

نظرًا لأن ANONYMOUS_USER_NAME هو في الواقع قيمة USERNAME_FIELD ، يمكن أن يكون ANONYMOUS_USER_NAME بريدًا إلكترونيًا أو أي شيء آخر. وبالتالي ، فإن التقصير إلى "AnonymousUser" يعد أمرًا مضللًا. علاوة على ذلك ، كان ANONYMOUS_USER_ID يقوم بتشغيل الميزة و ANONYMOUS_DEFAULT_USERNAME_VALUE كان بمثابة اسم مستخدم. لكن الآن ، تم دمجهم في مكان واحد ، والذي يعمل كمحفز وقيمة. لذلك لا فائدة من تقديم قيمة افتراضية.

لذلك سألتزم بما يلي:

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)

وإزالة السطرين المذكورين.

لدي مشاعر مختلطة حول بناء الجملة try...except لأنه ، على الرغم من أن الحقيقة ليست مسألة رقم ، لم أرها تستخدم للإعدادات مطلقًا. عادةً ما يعمل <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) الكلاسيكي بشكل جيد.

إذا لم نوفر قيمة افتراضية لـ ANONYMOUS_USER_NAME ، فسيؤدي ذلك إلى تعطيل التطبيقات الحالية التي تفترض أنه سيتم توفير قيمة افتراضية. على سبيل المثال ، لقد قمنا بتغيير السلوك عندما لا يتم تحديد إعداد ANONYMOUS_USER_NAME.

فلماذا لا تصطدم بـ 1.5.0 ، وإزالة ANONYMOUS_DEFAULT_USERNAME_VALUE والقيمة الافتراضية ، والتحذير من تعطل التغييرات؟

أعتقد أن الهدف كان السماح بتشغيل Django Guardian دون إنشاء مستخدم مجهول تلقائيًا. هل لديك حالة استخدام لهذا؟ لماذا لا تتجاهل المستخدم المجهول فقط إذا كنت لا تريده؟

أعتقد أن إنشاء مستخدم مجهول بشكل افتراضي أمر جيد ، ولا أرى أي سبب يدعو إلى تغيير هذا. ومع ذلك ، فنحن بحاجة إلى قيمة افتراضية قدرها ANONYMOUS_USER_NAME حتى يعمل هذا. إذا كان الإعداد الافتراضي غير مناسب لتطبيقك ، فيمكنك دائمًا تغييره.

بناء الجملة try ... except جيد لأنه يسمح بتمييز حالات "هل لم يتم إعطاء هذا الإعداد؟" و "هل تم إعطاء هذا الإعداد قيمة فارغة؟" - قد تكون قادرًا على استخدام getattr لهذا الغرض ، ومع ذلك فقد وجدت أن هذا يمكن أن يكون معقدًا بسرعة إلى حد ما ، خاصة إذا كنت ترغب في الاحتفاظ بـ DeprecationWarning. لست متأكدًا مما تقصده بعبارة "على الرغم من أن الحقيقة ليست مسألة عدد".

ما قصدته هو أنه ليس لأن الجميع يفعل شيئًا واحدًا هو الطريقة الصحيحة / الأفضل.

قد يكون فرض إنشاء مستخدم مجهول طريقة جيدة ، ولكن بعد ذلك يجب تحديث المستندات.

فيما يتعلق بموقفي ، فأنا أستخدم حقل بريد إلكتروني باعتباره USERNAME_FIELD الافتراضي ، ومن هنا كان ممانع في البداية إنشاء مثيل مستخدم مجهول. لكن يمكنني أن أدير.

هتافات. وشكرًا على السماح لي بإفساد عاهراتك.

يا رفاق ، لا أعتقد حقًا أن طلب إنشاء مستخدم مجهول فكرة جيدة. لقد كنت أستخدم django-guardian لفترة طويلة ولم يكن وجود مستخدم مجهول مطلوبًا أبدًا ، فلماذا تغيير ذلك الآن؟

لذا ، تم منح الحل الذي يتضمن try ... except 2 إعجاب ، ولكن عندما أبرر هذا الحل ، أعطيت 2 إعجاب. مربك. نظرًا لأنني لا أرى أي جانب سلبي حقًا ، وأعتقد أن هذه هي أبسط طريقة لحل الانحدار دون إضافة انحدارات جديدة ، سأقوم بتطبيق هذا الحل.

brianmay آسف على الارتباك. : +1: للإصلاح ، مع ذلك!