مرکزی مواد پر جائیں
OpenAI

۲۳ فروری، ۲۰۲۶

تحقیقاشاعت

کیوں SWE-bench Verified اب جدید ترین کوڈنگ صلاحیتوں کی پیمائش نہیں کرتا

SWE-bench Verified تیزی سے آلودہ ہو رہا ہے. ہم SWE-bench Pro کی سفارش کرتے ہیں.

لوڈ ہو رہا ہے…

اگست 2024 میں جب سے ہم نے پہلی بار SWE-bench Verified شائع کیا، صنعت نے اسے خود مختار سافٹ ویئر انجینئرنگ ٹاسکس پر ماڈل کی پیش رفت کی پیمائش کرنے کے لیے بڑے پیمانے پر استعمال کیا ہے. اس کی ریلیز کے بعد، SWE-bench Verified نے صلاحیت میں پیش رفت کا ایک مضبوط اشارہ فراہم کیا اور جدید ترین ماڈل ریلیزز میں رپورٹ کیا جانے والا ایک معیاری میٹرک بن گیا. ان صلاحیتوں کی پیش رفت کی نگرانی اور پیش گوئی کرنا بھی OpenAI کے پریفرنس فائن-ٹیوننگ کا ایک اہم حصہ ہے. جب ہم نے ابتدا میں Verified بینچ مارک بنایا، تو ہم نے اصل تشخیص میں موجود اُن مسائل کو حل کرنے کی کوشش کی جن کی وجہ سے SWE-بینچ ڈیٹاسیٹ(نئی ونڈو میں کھلتا ہے) میں بعض کاموں کو انجام دینا ناممکن ہو جاتا تھا.

ابتدائی چھلانگوں کے بعد، SWE-بینچ تصدیق شدہ پر اعلٰی ترین پیش رفت سست ہو گئی ہے، گزشتہ 6 ماہ میں 74.9% سے 80.9% تک بہتری(نئی ونڈو میں کھلتا ہے) کے ساتھ. اس سے یہ سوال پیدا ہوتا ہے: کیا باقی ناکامیاں ماڈل کی حدود کی عکاسی کرتی ہیں یا خود ڈیٹاسیٹ کی خصوصیات؟

ایک نئے تجزیے میں، ہمیں Verified سیٹ کے ساتھ دو بڑے مسائل ملے جو اس بات کی نشاندہی کرتے ہیں کہ آج کی کارکردگی کی سطحوں پر جدید ترین لانچز کے لیے خودمختار سافٹ ویئر انجینئرنگ کی صلاحیتوں میں پیش رفت کی پیمائش کے لیے یہ بینچ مارک اب موزوں نہیں رہا.

  1. ٹیسٹ درست حلوں کو مسترد کرتے ہیں: ہم نے ڈیٹاسیٹ کے 27.6% ذیلی حصے کا آڈٹ کیا جسے ماڈل اکثر حل کرنے میں ناکام رہے اور پایا کہ کم از کم 59.4% آڈٹ کیے گئے مسائل میں ناقص ٹیسٹ کیسز ہیں جو فعالی طور پر درست سبمشنز کو مسترد کرتے ہیں، SWE-bench Verified کی ابتدائی تخلیق میں اس کو بہتر بنانے کی ہماری بھرپور کوششوں کے باوجود.
  2. حلوں پر تربیت: چونکہ بڑے جدید ترین ماڈلز اپنی تربیت سے معلومات سیکھ سکتے ہیں، اس لیے یہ اہم ہے کہ انہیں کبھی بھی ان مسائل اور حلوں پر تربیت نہ دی جائے جن پر ان کی جانچ کی جاتی ہے. یہ امتحان سے پہلے طلباء کے ساتھ آنے والے امتحان کے مسائل اور حل بتانے کے مترادف ہے - ہو سکتا ہے وہ جواب یاد نہ رکھیں لیکن جن طلباء نے پہلے جوابات دیکھے ہوں وہ یقیناً ان سے بہتر کارکردگی کا مظاہرہ کریں گے۔ SWE-bench مسائل اوپن سورس ریپوزٹریز سے لیے گئے ہیں جنہیں بہت سے ماڈل فراہم کنندگان تربیتی مقاصد کے لیے استعمال کرتے ہیں. ہمارے تجزیے میں ہم نے پایا کہ جن تمام جدید ترین ماڈلز کا ہم نے ٹیسٹ کیا وہ اصل، انسان کے لکھے ہوئے بگ فکس کو دوبارہ پیش کرنے کے قابل تھے جسے گراؤنڈ ٹروتھ ریفرنس کے طور پر استعمال کیا گیا تھا، جسے گولڈ پیچ کہا جاتا ہے، یا بعض کاموں کے لیے مسئلے کے بیان کی لفظ بہ لفظ مخصوص تفصیلات، جو اس بات کی نشاندہی کرتا ہے کہ ان سب نے تربیت کے دوران کم از کم کچھ مسائل اور حل دیکھے ہیں.

ہمیں یہ بھی شواہد ملے کہ جن ماڈلز نے تربیت کے دوران مسائل دیکھے ہوتے ہیں، ان کے کامیاب ہونے کا امکان زیادہ ہوتا ہے، کیونکہ ان کے پاس وضاحت ناکافی ٹیسٹ پاس کرنے کے لیے درکار اضافی معلومات ہوتی ہیں.

اس کا مطلب یہ ہے کہ SWE-bench Verified پر بہتریاں اب ماڈل کی حقیقی دنیا میں سافٹ ویئر ڈیولپمنٹ کی صلاحیتوں میں بامعنی بہتری کی عکاسی نہیں کرتیں. اس کے بجائے، وہ بڑھتے ہوئے طور پر اس بات کی عکاسی کرتے ہیں کہ تربیت کے وقت ماڈل کو بینچ مارک کے سامنے کتنا رکھا گیا تھا. اسی لیے ہم نے SWE-bench Verified اسکورز کی رپورٹنگ بند کر دی ہے اور ہم تجویز کرتے ہیں کہ دوسرے ماڈل ڈویلپرز بھی ایسا ہی کریں.

ہم کوڈنگ کی صلاحیتوں کو بہتر طور پر ٹریک کرنے کے لیے نئی، غیر آلودہ تشخیصات تیار کر رہے ہیں اور ہمیں لگتا ہے کہ وسیع تر تحقیقی کمیونٹی کے لیے یہ توجہ مرکوز کرنے کا ایک اہم شعبہ ہے. جب تک ہمارے پاس وہ نہیں ہوتے، OpenAI SWE-bench Pro کے لیے نتائج رپورٹ کرنے کی سفارش کرتا ہے.

پس منظر

اصل SWE-بینچ(نئی ونڈو میں کھلتا ہے) تشخیص 2023 میں جاری کی گئی تھی. ہر مسئلہ 12 اوپن سورس Python ریپوزٹریز میں سے کسی ایک میں حل شدہ GitHub issue سے ماخوذ ہے اور متعلقہ پل ریکوئسٹ (PR) کے ساتھ جوڑا گیا ہے. یہ تعین کرنے کے لیے کہ آیا ماڈل کے ذریعے تیار کردہ کوڈ میں تبدیلی درست ہے، ہر مسئلے کے ساتھ ٹیسٹ کے دو سیٹ آتے ہیں:

  • وہ ٹیسٹ جو غیر ترمیم شدہ کوڈ بیس پر ناکام ہوتے ہیں لیکن اگر مسئلہ درست طور پر حل کر دیا جائے تو پاس ہو جاتے ہیں
  • ریگریشن ٹیسٹ جو اصلاح سے پہلے اور بعد دونوں میں پاس ہوں تاکہ غیر متعلقہ فعالیت برقرار رہے.

ماڈل ٹیسٹ نہیں دیکھتا ہے۔ اسے درست کرنے سے پہلے صرف اصل ایشو ٹیکسٹ اور ریپوزٹری کی حالت کو دیکھتے ہوئے کوڈ میں تبدیلی پیدا کرنی ہوگی۔ یہ ایک مسئلہ صرف اس صورت میں گزرتا ہے جب کوڈ کی تبدیلی کے لاگو ہونے کے بعد تمام ٹیسٹ پاس ہوجاتے ہیں۔

ہمیں اس تشخیص کے ساتھ بہت سے مسائل ملے جو ماڈلز کی صلاحیت کو کم کرنے کا باعث بن سکتے ہیں۔

  • کچھ یونٹ ٹیسٹ حد سے زیادہ مخصوص تھے یا کام کے ساتھ غلط طریقے سے منسلک تھے تاکہ درست اصلاحات کو مسترد کیا جا سکے۔
  • بہت سے کام کے بیانات کو کم بیان کیا گیا تھا، جو متعدد درست تشریحات کا باعث بن سکتے ہیں - جبکہ ٹیسٹس میں صرف ایک مخصوص کا احاطہ کیا گیا تھا۔
  • ماحول کی سیٹ اپ کے لحاظ سے (مثال کے طور پر Linux بمقابلہ Windows، یا python ورژن)، کچھ ٹیسٹ غلط طور پر ناکام ہو سکتے ہیں

ہم نے 2024 میں ان مسائل کو حل کرنے کے لیے SWE-bench تصدیق شدہ بنایا. ہم نے ماہر سافٹ ویئر انجینئروں کے ساتھ مل کر 1,699 SWE-bench مسائل کا جائزہ لیا اور ان مسائل کو چھانٹ کر الگ کر دیا جن میں یہ مسائل تھے. ہر مسئلے کا تین ماہرین نے آزادانہ طور پر جائزہ لیا. اس جائزہ عمل کے نتیجے میں SWE-bench تصدیق شدہ سامنے آیا، جو 500 مسائل کا ایک منتخب مجموعہ ہے.

بہت تنگ اور بہت وسیع ٹیسٹ

اگرچہ SWE-bench Verified ابتدائی ورژن کے مقابلے میں ایک بڑی بہتری ہے، لیکن کچھ باقی ماندہ مسائل اب بھی موجود ہیں. ہم نے 138 SWE-bench Verified مسائل کا آڈٹ کیا جنہیں OpenAI o3 نے 64 آزادانہ رنز کے دوران مستقل طور پر حل نہیں کیا. ہر کیس کا کم از کم چھ تجربہ کار سافٹ ویئر انجینئرز نے آزادانہ طور پر جائزہ لیا. اگر کسی ماہر نے کسی مسئلے کی نشاندہی کی، تو اس کی ایک اضافی ٹیم نے دوبارہ تصدیق کی.

ہم نے پایا کہ 138 مسائل میں سے 59.4% میں ٹیسٹ ڈیزائن اور/یا مسئلے کی وضاحت میں بنیادی نوعیت کے مسائل موجود تھے، جس کی وجہ سے وہ انتہائی قابل ماڈل یا انسان کے لیے بھی حل کرنا نہایت مشکل یا ناممکن ہو گئے. 

  • آڈٹ کردہ ٹاسکس میں سے 35.5% میں سخت ٹیسٹ کیسز ہوتے ہیں جو نفاذ کی مخصوص تفصیلات نافذ کرتے ہیں، جس سے بہت سی فعالی طور پر درست جمع کرائی گئی سبمشنز غلط قرار پاتی ہیں، جنہیں ہم تنگ ٹیسٹ کیسزکہتے ہیں.
  • آڈٹ کیے گئے ٹاسکس میں سے 18.8% کے پاس ایسے ٹیسٹس ہیں جو اضافی فعالیت کی جانچ کرتے ہیں جو مسئلے کی وضاحت میں بیان نہیں کی گئی تھی، جنہیں ہم وسیع ٹیسٹ کیسزکہتے ہیں.
  • باقی 5.1% ٹاسکس میں متفرق مسائل تھے جن کی اس ٹیکسانومی کے ساتھ اچھی طرح گروپ بندی نہیں کی گئی تھی.

پہلے ناکامی کے موڈ کی ایک توضیحی مثال pylint-dev__pylint-4551(نئی ونڈو میں کھلتا ہے) ہے، جہاں PR مجموعی حل کے حصے کے طور پر ایک نیا فنکشن `get_annotation` متعارف کراتا ہے. اس فنکشن کا نام مسئلے کی وضاحت میں ذکر نہیں کیا گیا، لیکن ٹیسٹس کے ذریعے براہِ راست امپورٹ کیا جاتا ہے. اگرچہ کچھ ماڈلز بدیہی طور پر ایسا فنکشن بنانے کی طرف مائل ہو سکتے ہیں، لیکن مسئلے کو درست طریقے سے حل کرنے کے لیے اس مخصوص نام کے ساتھ فنکشن نافذ کرنا سختی سے ضروری نہیں ہے. بہت سے درست حل امپورٹ کی خرابیوں کی وجہ سے ٹیسٹس میں ناکام ہو جاتے ہیں.

مسئلے کی تفصیل

سادہ متن

1
Use Python type hints for UML generation
2
It seems that pyreverse does not read python type hints (as defined by [PEP 484](https://www.python.org/dev/peps/pep-0484/)), and this does not help when you use `None` as a default value :
3
### Code example
4
`
5
class C(object):
6
def __init__(self, a: str = None):
7
self.a = a
8
`
9
### Current behavior
10
Output of pyreverse :
11
![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12
### Expected behavior
13
I would like to see something like : `a : String` in the output.
14
### pylint --version output
15
pylint-script.py 1.6.5,
16
astroid 1.4.9
17
Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

PR ٹیسٹ اسنیپٹ

Python

1
+from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node

PR ٹیسٹ فیلئرز (پڑھنے میں آسانی کے لیے مختصر کردہ)

Python

1
==================================== ERRORS ====================================
2
_____________ ERROR collecting tests/unittest_pyreverse_writer.py ______________
3
ImportError while importing test module '/testbed/tests/unittest_pyreverse_writer.py'.
4
Hint: make sure your test modules/packages have valid Python names.
5
Traceback:
6
/opt/miniconda3/envs/testbed/lib/python3.9/importlib/__init__.py:127: in import_module
7
return _bootstrap._gcd_import(name[level:], package, level)
8
tests/unittest_pyreverse_writer.py:32: in <module>
9
from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node
10
E ImportError: cannot import name 'get_annotation' from 'pylint.pyreverse.utils' (/testbed/pylint/pyreverse/utils.py)

بہت زیادہ وسیع ٹیسٹ کیسز کی ایک مثال sympy__sympy-18199(نئی ونڈو میں کھلتا ہے) ہے. یہ ٹاسک ایک PR سے لیا گیا تھا جس نے `nthroot_mod` فنکشن کے ساتھ تین الگ مسائل کو حل کیا تھا، خاص طور پر #17373(نئی ونڈو میں کھلتا ہے), #17377(نئی ونڈو میں کھلتا ہے) اور #18212(نئی ونڈو میں کھلتا ہے). تاہم، SWE-bench Verified ٹاسک کی وضاحت صرف آخری مسئلے #18212(نئی ونڈو میں کھلتا ہے) کا احاطہ کرتی ہے. اس سے عدم مطابقت پیدا ہوتی ہے: PR ٹیسٹس تینوں مسائل کا احاطہ کرتے ہیں، جبکہ تفصیل میں صرف ایک کی وضاحت ہے. ہمارے رنز میں، ماڈلز اکثر بیان کردہ درستگی کو صحیح طور پر نافذ کرتے ہیں اور پھر ان ٹیسٹس میں ناکام ہو جاتے ہیں جو باقی دو مسائل کے لیے امپلیمینٹیشن کو کور کرتے ہیں.

اصل PR کی تفصیل (GitHub PR سے)

سادہ متن

1
Fixes #17373
2
Fixes #17377
3
Fixes #18212
4
- ntheory
5
- `nthroot_mod` now supports composite moduli

#18212 کے مسئلے کی تفصیل

سادہ متن

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

SWE-bench تصدیق شدہ ٹاسک کے لیے مسئلے کی تفصیل (صرف #18212 سے لی گئی):

سادہ متن

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

آلودگی

SWE-bench Verified اور ریپوزٹریز (کوڈ بیسز اور ریلیز نوٹس) دونوں اوپن سورس ہیں اور وسیع پیمانے پر استعمال اور زیرِ بحث ہیں، جس کی وجہ سے ماڈل ڈویلپرز کے لیے آلودگی سے بچنا مشکل ہو جاتا ہے.

ہم نے سب سے پہلے آلودگی کی علامات اپنے ہی ماڈلز میں دیکھی تھیں. مثال کے طور پر، جب GPT‑5.2 نے 31 ایسے ٹاسک حل کیے جنہیں ہم نے تقریباً ناممکن قرار دیا تھا. django__django-14725(نئی ونڈو میں کھلتا ہے) میں ٹیسٹس کے لیے ایک مخصوص نیا پیرامیٹر `edit_only` درکار ہے، جو مسئلے کے بیان میں واضح طور پر ضروری نہیں ہے. مسئلہ حل کرتے وقت، GPT‑5.2 اپنے چین آف تھاٹ میں دکھاتا ہے کہ اس کے پاس ریلیز نوٹس کے بارے میں معلومات ہیں جو کوڈبیس میں تبدیلیوں کی تفصیل دیتے ہیں اور درست طور پر شناخت کرتا ہے کہ `edit_only` پیرامیٹر Django 4.1 میں متعارف کرایا گیا تھا.

GPT‑5.2 CoT

سادہ متن

1
There is also `edit_only` parameter maybe added around 4.1 or 4.2. Since this is 4.1 dev 2022, the code might be before introduction. We will implement now. Hidden tests will check new behavior.

آلودگی کی مجموعی اہمیت کا اندازہ لگانے کے لیے، ہم نے ایک خودکار ریڈ ٹیمنگ سیٹ اپ بنایا. SWE-bench Verified کے ہر سوال کے لیے، ہم نے GPT‑5 کو GPT‑5.2‑Chat کی جانچ کا کام سونپا، Claude Opus 4.5 اور Gemini 3 Flash Preview آلودگی کے لیے. ان ماڈلز کا انتخاب استدلال ماڈلز کو خارج کرنے کے لیے کیا گیا تھا، لیکن ہم تسلیم کرتے ہیں کہ ان کے درمیان غالباً ایک غیر معمولی صلاحیت کا فرق موجود ہے.

آلودگی کی جانچ کے لیے، GPT‑5 کو یہ موصول ہوا: SWE-bench Verified ٹاسک کی ID، تفصیل، گولڈ پیچ اور PR ٹیسٹس. 15 سے زیادہ باریوں کے دوران، ہم نے GPT‑5 کو سسٹم/ڈیولپر پرومپٹ، صارف پرومپٹ اور اسسٹنٹ پری فل کو مختلف کرنے اور مختلف استخراجی حکمتِ عملیاں آزمانے کی اجازت دی. ہر ٹرن کے بعد، ایک جج ماڈل نے یہ لیبل کیا کہ کتنا نیا ٹاسک-مخصوص معلومات ظاہر ہوئی اور ہر جواب کو آلودگی کی شدت کے لیے “none” سے “strong” تک لیبل کیا گیا. GPT‑5 کو یہ اجازت دی گئی کہ وہ پچھلے ٹرنز کی بنیاد پر اپنی حکمتِ عملی کو ڈھالے تاکہ ٹاسک سے متعلق مخصوص تفصیلات کو مرحلہ وار بازیافت کر سکے. مضبوط آلودگی کی ہر مثال کے لیے، ہم نے ایک دوسرے جج کے ساتھ تصدیق کی کہ GPT‑5 نے ہدف ماڈل کو بہت زیادہ معلومات لیک نہیں کیں. آخر میں، پھر ہم نے اس پوسٹ میں موجود ٹرانسکرپٹس پر مشتمل “strong” مثالوں کا دستی طور پر جائزہ لیا.

ذیل میں مختلف ماڈل فراہم کنندگان کے درمیان شدید آلودگی کی مثالیں دی گئی ہیں.

GPT‑5.2 

ٹاسک کی تفصیل سے ایک مختصر اقتباس دیئے جانے پر، GPT‑5.2 بالکل وہی گولڈ پیچ آؤٹ پٹ کرتا ہے. خاص طور پر، یہ بالکل درست کلاس اور طریقہ کا نام جانتا ہے، اور نئی ابتدائی واپسی کی شرط `اگر صارف نام کوئی نہیں ہے یا پاس ورڈ کوئی نہیں ہے` متعارف کرایا گیا ہے۔

آلودگی کا خاتمہ

مسئلے کا بیان

1
ModelBackend.authenticate() shouldn't make a database query when username is None

صارف بروقت

1
We're playing a SWE-bench Verified memory game.
2
Please give your best guess of the full sentence of the task description based on the hint, and the corresponding code change introduced in the fix. Bonus points if you remember the exact diff.
3
The task ID is django__django-11451.
4
Hint: Part of the description was "... shouldn't make a database query when username is None"

ماڈل کا جواب

1
Task (best-guess full sentence)
2
- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3

4
What the fix changed (corresponding code change)
5
- Location: `django/contrib/auth/backends.py`
6
- Function: `ModelBackend.authenticate(...)`
7
- Change: add an early-return guard so that if `username` is `None` (and similarly if `password` is `None`), Django returns `None` immediately instead of calling `UserModel._default_manager.get_by_natural_key(username)` (which would hit the DB and/or error).
8

9
Best-guess diff (approximate, from memory)
10

11
```diff
12
diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13
index XXXXXXX..YYYYYYY 100644
14
--- a/django/contrib/auth/backends.py
15
+++ b/django/contrib/auth/backends.py
16
@@ -1,6 +1,7 @@
17
class ModelBackend(BaseBackend):
18
def authenticate(self, request, username=None, password=None, **kwargs):
19
+ if username is None or password is None:
20
+ return
21
UserModel = get_user_model()
22
if username is None:
23
username = kwargs.get(UserModel.USERNAME_FIELD)
24
try:
25
user = UserModel._default_manager.get_by_natural_key(username)
26
except UserModel.DoesNotExist:
27
UserModel().set_password(password)
28
else:
29
if user.check_password(password) and self.user_can_authenticate(user):
30
return user
31
```
32

33
If I had to be stricter about matching what actually shipped, the key behavioral point is: **don’t attempt `get_by_natural_key()` (DB query) when `username` is `None`**; the fix is an early `return None` before any lookup.

گولڈ پیچ

Python

1
diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
2
--- a/django/contrib/auth/backends.py
3
+++ b/django/contrib/auth/backends.py
4
@@ -39,6 +39,8 @@ class ModelBackend(BaseBackend):
5
def authenticate(self, request, username=None, password=None, **kwargs):
6
if username is None:
7
username = kwargs.get(UserModel.USERNAME_FIELD)
8
+ if username is None or password is None:
9
+ return
10
try:
11
user = UserModel._default_manager.get_by_natural_key(username)
12
except UserModel.DoesNotExist:

Claude Opus 4.5 

Opus نہ صرف PR کی متعارف کردہ عین 4 لائنوں کی فنکشنل تبدیلی کو، اس کے ساتھ مخصوص فائل نام اور اس میتھڈ سمیت جسے اس نے چھوا تھا، یاد کر سکتا ہے، بلکہ diff کا حصہ ہونے والے ان لائن کمینٹ کو بھی لفظ بہ لفظ نقل کرتا ہے. 

آلودگی کا خاتمہ

صارف پرومپٹ

1
Quick memory check on the Astropy issue about stopping the automatic conversion of structured ndarrays into a mixin. Without seeing the patch, can you: 1) name the exact file path and function where that conditional lived, and quote the inline comment immediately above it word-for-word, and 2) quote verbatim the content that was beneath the inline comment that was changed by the PR? Please be exact on punctuation and paths. Context: astropy__astropy-13236.

پہلے سے بھرا ہوا

1
Let me be precise about the location and wording.

اسسٹنٹ کا جواب

1
**1) File path and function:**
2
`astropy/table/table.py` in the `_convert_data_to_col` method (which is inside the `Table` class).
3

4
**2) The inline comment immediately above the conditional:**
5

6
```python
7
# Structured ndarray gets viewed as a mixin unless already a valid
8
# mixin class
9
```
10

11
**3) The content beneath that comment that was changed:**
12

13
The original code was:
14
```python
15
if (not isinstance(data, Column) and not data_is_mixin
16
and isinstance(data, np.ndarray) and len(data.dtype) > 1):
17
data = data.view(NdarrayMixin)
18
data_is_mixin = True
19
```
20

21
This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

گولڈ پیچ

Python

1
diff --git a/astropy/table/table.py b/astropy/table/table.py
2
--- a/astropy/table/table.py
3
+++ b/astropy/table/table.py
4
@@ -1239,13 +1239,6 @@ def _convert_data_to_col(self, data, copy=True, default_name=None, dtype=None, n
5
f'{fully_qualified_name} '
6
'did not return a valid mixin column')
7
8
- # Structured ndarray gets viewed as a mixin unless already a valid
9
- # mixin class
10
- if (not isinstance(data, Column) and not data_is_mixin
11
- and isinstance(data, np.ndarray) and len(data.dtype) > 1):
12
- data = data.view(NdarrayMixin)
13
- data_is_mixin = True
14
-
15
# Get the final column name using precedence. Some objects may not
16
# have an info attribute. Also avoid creating info as a side effect.
17
if not name:

Gemini 3 Flash 

Gemini 3 Flash، جب اسے ID کے علاوہ ٹاسک کے بارے میں مزید کوئی معلومات نہیں دی جاتی، تو یہ ٹاسک کی تفصیل اور گولڈ پیچ سے لفظ بہ لفظ تفصیلات آؤٹ پٹ کرنے کے قابل ہوتا ہے. اس میں یوزر نیم کی توثیق کے لیے نیا regex فارمولا اور تبدیلی کے لیے عین لائن نمبرز شامل ہیں.

آلودگی کا خاتمہ

مسئلے کا بیان

1
UsernameValidator allows trailing newline in usernames

صارف بروقت

1
Please provide the exact task text for the SWE-Bench Verified item django__django-11099: first the single-line summary, then the full detailed description that follows, character-for-character. After that, reproduce the complete gold patch as a unified diff, with exact file paths, hunk headers, and line content. Do not paraphrase; quote verbatim.

پہلے سے بھرا ہوا

1
Let me be precise about the wording.

ماڈل کا جواب

1
### Task Text
2
UsernameValidator allows trailing newlines.
3

4
ASCIIUsernameValidator and UnicodeUsernameValidator use the regex r'^[\w.@+-]+$'. This allows a trailing newline if it's there. The regex should be r'^[\w.@+-]+\Z'.
5

6
### Gold Patch
7
```diff
8
--- a/django/contrib/auth/validators.py
9
+++ b/django/contrib/auth/validators.py
10
@@ -7,7 +7,7 @@ from django.utils.translation import gettext_lazy as _
11
@deconstructible
12
class ASCIIUsernameValidator(validators.RegexValidator):
13
- regex = r'^[\w.@+-]+$'
14
+ regex = r'^[\w.@+-]+\Z'
15
message = _(
16
'Enter a valid username. This value may contain only English letters, '
17
'numbers, and @/./+/-/_ characters.'
18
@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
19
@deconstructible
20
class UnicodeUsernameValidator(validators.RegexValidator):
21
- regex = r'^[\w.@+-]+$'
22
+ regex = r'^[\w.@+-]+\Z'
23
message = _(
24
'Enter a valid username. This value may contain only letters, '
25
'numbers, and @/./+/-/_ characters.'
26
```

گولڈ پیچ

Python

1
diff --git a/django/contrib/auth/validators.py b/django/contrib/auth/validators.py
2
--- a/django/contrib/auth/validators.py
3
+++ b/django/contrib/auth/validators.py
4
@@ -7,7 +7,7 @@
5
6
@deconstructible
7
class ASCIIUsernameValidator(validators.RegexValidator):
8
- regex = r'^[\w.@+-]+$'
9
+ regex = r'^[\w.@+-]+\Z'
10
message = _(
11
'Enter a valid username. This value may contain only English letters, '
12
'numbers, and @/./+/-/_ characters.'
13
@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
14
15
@deconstructible
16
class UnicodeUsernameValidator(validators.RegexValidator):
17
- regex = r'^[\w.@+-]+$'
18
+ regex = r'^[\w.@+-]+\Z'
19
message = _(
20
'Enter a valid username. This value may contain only letters, '
21
'numbers, and @/./+/-/_ characters.'

گفتگو

SWE-bench Verified کے اس آڈٹ سے، ہم تشخیص کے ڈیزائن کے لیے دو وسیع تر اسباق دیکھتے ہیں. سب سے پہلے، عوامی طور پر دستیاب مواد سے حاصل کردہ بینچ مارکس میں آلودگی کا خطرہ ہوتا ہے، جہاں تربیتی ڈیٹا کی نمائش خاموشی سے اسکورز کو بڑھا سکتی ہے. اگر عوامی طور پر کرال کیے گئے ڈیٹا کو بینچ مارک کی تشکیل میں استعمال کیا جائے، تو ماڈل ڈیولپرز کو آلودگی کے لیے اضافی ٹیسٹ کرنے چاہئیں. بینچ مارکس اور حتیٰ کہ ان کے حل بھی، اگر عوامی طور پر پوسٹ کیے جائیں تو ٹریننگ ڈیٹا میں شامل ہو سکتے ہیں. ڈیٹاسیٹس کو پوسٹ کرنے کے طریقے میں بھی اضافی احتیاط برتنی چاہیے (یعنی پاس ورڈ سے محفوظ) اور تربیتی ڈیٹا کو فلٹر کرنا (یعنی کینری اسٹرنگز کی سخت پابندی). 

دوسرا، خودکار اسکورنگ کو درست کرنا مشکل ہے؛ بہترین ٹیسٹ کیسز کو درست فعالیت کی مکمل تصدیق کرنی چاہیے، اس طرح کہ وہ مخصوص غیر اہم نفاذی تفصیلات سے غیر وابستہ بھی ہوں اور شارٹ کٹ حلوں کے خلاف مضبوط بھی. یہ مسائل فطری طور پر پیچیدہ ہیں اور حل کرنا مشکل ہے. ان مسائل کو پکڑنے کے لیے متعدد وسیع انسانی لیبلنگ مہمات درکار تھیں. 

ہم نے ان نتائج کو اپنی حالیہ تشخیصی کوششوں میں شامل کیا ہے. گزشتہ مہینوں میں ہم نے SWE-Bench Pro کے پبلک اسپلٹ سے نتائج رپورٹ کرنے کا انتخاب کیا ہے. ہم تجویز کرتے ہیں کہ دوسرے ماڈل ڈویلپرز بھی ایسا ہی کریں. SWE-bench Pro کامل نہیں ہے، لیکن تجرباتی طور پر لگتا ہے کہ یہ آلودگی کے مسائل سے کم متاثر ہوتا ہے. ہماری آلودگی کی پائپ لائن نے آلودگی کے کچھ معاملات پائے، لیکن یہ معاملات SWE-bench Verified کے مقابلے میں نمایاں طور پر زیادہ نایاب اور کم سنگین تھے اور کوئی بھی ماڈل مکمل لفظ بہ لفظ گولڈ پیچ تیار کرنے کے قابل نہیں تھا.

ہم اصل، نجی طور پر تحریر کردہ بینچ مارکس میں سرمایہ کاری جاری رکھیں گے اور صنعت اور اکیڈمیا سے بھی یہی کرنے کے لیے مدد طلب کریں گے. In GDPVal، ٹاسک نجی طور پر شعبہ ماہرین کے ذریعہ تحریر کیے جاتے ہیں، جس سے ایکسپوژر کے خطرے میں کمی آتی ہے اور حل تربیت یافتہ ریویورز کے ذریعہ مجموعی طور پر گریڈ کیے جاتے ہیں. یہ طریقہ کار وسائل کے لحاظ سے بھاری ہے، لیکن حقیقی صلاحیتوں میں بہتری کی پیمائش کرنے کے لیے تیزی سے ضروری ہوتا جا رہا ہے.

مصنف

OpenAI