出现了课程名相同，班号一样，学院相同的课程

[Lester-Peking-University]

Check List

• 我已经阅读了 Readme, Migration Guide, Realease History ，但是并没有找到有用的信息
• 我已经搜索了已有的 Issues ，但是没有找到相同的问题

Version / Environment

System infomation: [Windows10 64bit]
Python version: [3.6.8]
AutoElective version: [3.0.5]

Config

除了学号/密码外的其他配置

[course:wl]
name = 财务会计
class = 1
school = 光华管理学院

[course:hh]
name = 财务会计
class = 2
school = 光华管理学院

Issue Description

What

遇到的问题
见图片

财会有两门课，用英语和汉语授课，唯一区别是课号不同
想问一下
if 三门都在培养方案中，如果不想上英文课程，想抢两门中文课程的任意一门，如何操作？
else if 需要跨院系选课，三门上哪一门都可以，config里的配置可以保证刷课成功吗，即两门班号为1的课程有任意一门出现空位就可以补选
没有看源码，不是很了解补选的实现算法

Console Log

必要的终端输出信息
这个似乎不是很需要？

Reproduce

如有必要，提供复现的步骤

[Lester-Peking-University]

update:
由于同时抢上了别的课，2班时间冲突，然后刚刚1班中文班扩了5个名额，抢上了1班中文班，loop就终止了
这按说应该是我们期望的程序运行结果

[zhongxinghong]

你这个情况我确实是第一次遇到过 ... 我所见过的选课计划里，如果一个课有中英文两种班，那么它们会被编为同一个课程号下的不同班，像这种同课名同年级同学分同上课时间最后还编成两个不同课的情况还真的是第一次见过 ...

按照 loop.py 中的这段代码

for c0 in plans: # c0 has detail
    if c0 == c:
        if c0.is_available():
            delay = delays[ix]
            if delay != NO_DELAY and c0.remaining_quota > delay:
                cout.info("%s hasn't reached the delay threshold %d, skip" % (c0, delay))
            else:
                tasks.append((ix, c0))
                cout.info("%s is AVAILABLE now !" % c0)
        break
else:
    raise UserInputException("%s is not in your course plan, please check your config." % c)

对于你这种情况，两个 “财务会计” 会按先后顺序出现在 plans 里面，当 c 对应着你定义的 “1班” 时，c0 首先会遍历到中文班，然后判断是否有名额，之后不管怎样就 break 了，英文班会被无视。所以现有的程序没法选上英文班 ... 多个“相同”的班，只有第一个匹配到的会被识别。回到你的问题来讲，如果你想只选中文班，那么程序歪打正着地帮你实现了，因为它根本解析不到英文班 :( 如果三门课上哪门都可以，那么实际上也只监听其中两门中文班，英文班就算有名额也选不上

我觉得这种编课的行为非常个例，可能并不符合课程系统的正常逻辑，因为选课网有一种错误描述了你同时选了一门课的不同班，如果按照这样的定义，如果时间不冲突的话，你应该可以同时选上这两个班，这是很不合理的。

而要区分这种情况会有点麻烦，因为我看了一下，除了 教师 和 上课/考试信息 外，没有任何可以用来区分这两者的值出现在 补退选 页的表格里，尤其是没有 课程号

虽然还是有方法找到课程号的，那就是从补选链接的 seq 参数里解析出课程号，但是这种方法可能会有一些丑陋。

而且如果使用 课程号 作为标识的话，用户可能需要在每个课程定义的时候都要点开课程详细信息来获取课程号，然后会有些用户不友好 ...

我更希望用户能仅靠 补退选 页，而且不需要 F12 这样的高级功能，就可以准确地定义好一个课程，所以我就采用更加直观一点的 课名 + 班号 + 院系 作为一种 “联合主键” 来定位一个课程，这个方案一直用到现在，仅仅就你这个情况中出现了歧义 ...

我目前的想法是，如果这种情况非常非常少见的话，我就暂时不对它进行适配了，因为如果要适配的话，可能要涉及到 数据模型 这种层面的修改，到时候影响的范围会很大，需要做很多测试，可能会增加很多未知的 bug。我打算目前还是继续沿用现有的模式吧 :)

然后我打算开着这个 Issue 看之后还有没有更多的相似反馈，如果这个问题真的成了一定规模我再改动吧 ...