Examples

<file_path>numpy/core/_internal.py</file_path>

<structural_path>

</structural_path>

<code>

282 282 \n

283 - # Given a datatype and an order object

284 - # return a new names tuple

285 - # with the order indicated

286 283 def _newnames(datatype, order):

</code>

</edit 0>

<file_path>numpy/core/_internal.py</file_path>

<structural_path>

def _newnames(datatype, order):

</structural_path>

<code>

286 283 def _newnames(datatype, order):

284 + """

285 + Given a datatype and an order object, return a new names tuple, with the

286 + order indicated

287 + """

287 288 oldnames = datatype.names

</code>

</edit 1>

Example 1

Commit URL: https://github.com/numpy/numpy/commit/3cdcbe0f8402e795262341837afe39a279d9b888
Partial order label: 0 before 1
Reason: These two edits correspond to removing outdated inline comments (Edit 0) and adding a structured docstring (Edit 1). Together, they form a typical “cut-and-paste” style documentation update. Since developers rarely write the new docstring before deleting the obsolete comments, the cognitive order is naturally unidirectional from Edit 0 to Edit 1. Other edit-hunk pairs that naturally exhibit unidirectional cognitive ordering also include refactoring actions, such as deleting the shared logic and the creation of a new helper method.

<file_path>corporate/lib/stripe.py</file_path>

<structural_path>

def get_free_trial_days()->Optional[int]:

</structural_path>

<code>

3628 3635 \n

3629 - def <dep>get_free_trial_days</dep>() -> Optional[int]:

3636 + def <dep>get_free_trial_days</dep>(is_self_hosted_billing: bool = False) -> Optional[int]:

3637 + if is_self_hosted_billing:

3638 + return settings.SELF_HOSTING_FREE_TRIAL_DAYS

3639 + \n

3630 3640 return settings.CLOUD_FREE_TRIAL_DAYS

</code>

</edit 0>

<file_path>corporate/views/portico.py</file_path>

<structural_path>

def plans_view(request: HttpRequest)->HttpResponse:

PlansPageContext(

is_cloud_realm=True,

sponsorship_url=reverse("sponsorship_request"),

free_trial_days=get_free_trial_days(),

is_sponsored=realm is not None and realm.plan_type == Realm.PLAN_TYPE_STANDARD_FREE,

)

</structural_path>

<code>

91 91 sponsorship_url=reverse("sponsorship_request"),

92 - free_trial_days=<dep>get_free_trial_days</dep>(),

92 + free_trial_days=<dep>get_free_trial_days</dep>(False),

93 93 is_sponsored=realm is not None and realm.plan_type == Realm.PLAN_TYPE_STANDARD_FREE,

</code>

</edit 1>

Example 2

Commit URL: https://github.com/zulip/zulip/commit/ce56e19d1c3fbe857e06260e60a4c34cd6956cd7
Partial order label: Bi-directional
Reason: Edit 0 adds a new argument to the function signature, while Edit 1 updates a call site to pass this new argument. Although performing Edit 1 before Edit 0 may introduce a temporary lint or type checking warning due to the mismatched signature, we still consider this pair bi directional. Developers often update call sites first when they are exploring an API change, and it is also common for developers to work through a briefly incorrect intermediate state during iterative editing. At the same time, many developers prefer to adjust the callee first and then update all callers. Since both directions represent reasonable and frequently observed editing practices, no strict cognitive precedence can be established between these two edits.

<file_path>webui.py</file_path>

<structural_path>

</structural_path>

<code>

271 271 \n

272 + \n

273 + def stop_route(request):

274 + shared.state.server_command = "stop"

275 + return Response("Stopping.")

276 + \n

277 + \n

272 278 def webui():

</code>

</edit 0>

<file_path>webui.py</file_path>

<structural_path>

def webui():

shared.demo.launch(

share=cmd_opts.share,

server_name=server_name,

server_port=cmd_opts.port,

ssl_keyfile=cmd_opts.tls_keyfile,

ssl_certfile=cmd_opts.tls_certfile,

ssl_verify=cmd_opts.disable_tls_verify,

debug=cmd_opts.gradio_debug,

auth=[tuple(cred.split(':')) for cred in gradio_auth_creds] if gradio_auth_creds else None,

inbrowser=cmd_opts.autolaunch,

prevent_thread_lock=True

)

</structural_path>

<code>

319 325 )

326 + if cmd_opts.add_stop_route:

327 + app.add_route("/_stop", stop_route, methods=["POST"])

320 328 \n

</code>

</edit 1>

Example 3

Commit URL: https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/875990a23213c63c19b8fdd3c87345f7a8ea2ceb
Partial order label: Bi-directional
Reason: Edit 0 introduces the new handler function stop_route, while Edit 1 registers this handler through app.add_route. Although there is no direct static dependency between the two edits, they are strongly related at the execution level because the route registration ultimately relies on the handler’s existence. Developers may choose to write the handler first and then register it, but it is equally common to begin by adding the route entry as a placeholder before completing the handler implementation. Therefore, both editing directions are plausible, and no strict cognitive precedence can be established for this pair.

<file_path>pandas/core/internals/blocks.py</file_path>

<structural_path>

class NumericBlock(NumpyBlock):

</structural_path>

<code>

2149 2149 \n

2150 - class NumericBlock(NumpyBlock):

2151 - # this Block type is kept for backwards-compatibility

2152 - # TODO(3.0): delete and remove deprecation in __init__.py.

2153 - __slots__ = ()

2154 - \n

2155 - \n

2156 - class ObjectBlock(NumpyBlock):

2157 - # this Block type is kept for backwards-compatibility

2158 - # TODO(3.0): delete and remove deprecation in __init__.py.

2159 - __slots__ = ()

2160 - \n

2161 - \n

2162 2150 class NDArrayBackedExtensionBlock(EABackedBlock):

</code>

</edit 0>

<file_path>pandas/tests/internals/test_api.py</file_path>

<structural_path>

def test_deprecations(name):

</structural_path>

<code>

54 52 \n

55 - if name not in ["NumericBlock", "ObjectBlock"]:

56 - # NumericBlock and ObjectBlock are not in the internals.api namespace

57 - with tm.assert_produces_warning(DeprecationWarning, match=msg):

58 - getattr(api, name)

59 - \n

60 53 \n

</code>

</edit 1>

Example 4

Commit URL: https://github.com/pandas-dev/pandas/commit/d04f908a7af35602a3477bbc10d2ec05c61088e3
Partial order label: Bi-directional
Reason: Edit 0 removes the legacy classes NumericBlock and ObjectBlock from the internals implementation. Edit 1 deletes the corresponding special-case branch in the test suite that referenced these two names. Although the edits concern the same cleanup task, there is no static or behavioral dependency requiring one to precede the other. Developers may remove the classes first and then clean up the tests, or they may simplify the tests before eliminating the underlying implementations. Both directions produce valid intermediate states, so no strict cognitive precedence exists for this pair.

<file_path>homeassistant/components/knx/device_trigger.py</file_path>

<structural_path>

def async_attach_trigger(

hass: HomeAssistant,

config: ConfigType,

action: TriggerActionType,

trigger_info: TriggerInfo,

)->CALLBACK_TYPE:

</structural_path>

<code>

88 89 job = HassJob(action, f"KNX device trigger {trigger_info}")

89 - knx: KNXModule = hass.data[DOMAIN]

90 90 \n

</code>

</edit 0>

<file_path>homeassistant/components/knx/telegrams.py</file_path>

<structural_path>

</structural_path>

<code>

15 16 \n

16 - from .const import DOMAIN

17 + from .const import DOMAIN, SIGNAL_KNX_TELEGRAM_DICT

17 18 from .project import KNXProject

</code>

</edit 1>

Example 5

Commit URL: https://github.com/home-assistant/core/commit/a9b51f0255eb673d204bc0e536dbda41dc851584
Partial order label: No relation
Reason: Edit 0 removes an unused local assignment knx from the KNX device trigger handler. Edit 1 extends an import in telegrams.py to also bring in SIGNAL_KNX_TELEGRAM_DICT from .const, enabling additional functionality elsewhere in that module. These edits touch different files and address unrelated concerns: one is a small cleanup of dead code in the trigger handler, while the other prepares the telegrams module to use a new constant. There is no shared data flow, control flow, or API dependency between them, and each can be applied independently without affecting the other. Therefore, this pair naturally has no direct ordering relation.

<file_path>lib/core/option.py</file_path>

<structural_path>

def __setKnowledgeBaseAttributes(flushAll=True):

</structural_path>

<code>

1443 1443 kb.resumedQueries = {}

1444 + kb.safeCharEncode = False

1444 1445 kb.singleLogFlags = set()

</code>

</edit 0>

<file_path>lib/techniques/union/use.py</file_path>

<structural_path>

def __oneShotUnionUse(expression, unpack=True):

</structural_path>

<code>

98 98 \n

99 - return output

99 + return safecharencode(output) if kb.safeCharEncode else output

100 100 \n

</code>

</edit 1>

Example 6

Commit URL: https://github.com/sqlmapproject/sqlmap/commit/6bbb8139a0e26652efacca19f736e997251a2c24
Partial order label: Bi-directional
Reason: Edit 0 adds a new knowledge-base flag kb.safeCharEncode and initializes it to False. Edit 1 uses this flag. There is a data-flow connection—Edit 1 reads the flag introduced in Edit 0—but no strict ordering is required. Developers may introduce the flag first before wiring it into the logic, or update the return path assuming the flag will be added shortly after. Both sequences produce valid intermediate states, so the ordering is naturally bidirectional.