1. 09 Agu, 2002 1 kayıt (commit)
  2. 02 Agu, 2002 2 kayıt (commit)
  3. 28 Tem, 2002 2 kayıt (commit)
  4. 03 Mar, 2002 1 kayıt (commit)
  5. 11 Şub, 2002 1 kayıt (commit)
  6. 12 Ock, 2002 1 kayıt (commit)
  7. 06 Ara, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      SF bug #488514: -Qnew needs work · 3caca232
      Tim Peters yazdı
      Big Hammer to implement -Qnew as PEP 238 says it should work (a global
      option affecting all instances of "/").
      
      pydebug.h, main.c, pythonrun.c:  define a private _Py_QnewFlag flag, true
      iff -Qnew is passed on the command line.  This should go away (as the
      comments say) when true division becomes The Rule.  This is
      deliberately not exposed to runtime inspection or modification:  it's
      a one-way one-shot switch to pretend you're using Python 3.
      
      ceval.c:  when _Py_QnewFlag is set, treat BINARY_DIVIDE as
      BINARY_TRUE_DIVIDE.
      
      test_{descr, generators, zipfile}.py:  fiddle so these pass under
      -Qnew too.  This was just a matter of s!/!//! in test_generators and
      test_zipfile.  test_descr was trickier, as testbinop() is passed
      assumptions that "/" is the same as calling a "__div__" method; put
      a temporary hack there to call "__truediv__" instead when the method
      name is "__div__" and 1/2 evaluates to 0.5.
      
      Three standard tests still fail under -Qnew (on Windows; somebody
      please try the Linux tests with -Qnew too!  Linux runs a whole bunch
      of tests Windows doesn't):
          test_augassign
          test_class
          test_coercion
      I can't stay awake longer to stare at this (be my guest).  Offhand
      cures weren't obvious, nor was it even obvious that cures are possible
      without major hackery.
      
      Question:  when -Qnew is in effect, should calls to __div__ magically
      change into calls to __truediv__?  See "major hackery" at tail end of
      last paragraph <wink>.
      3caca232
  8. 04 Eyl, 2001 2 kayıt (commit)
  9. 31 Agu, 2001 2 kayıt (commit)
    • Guido van Rossum's avatar
      97741a30
    • Guido van Rossum's avatar
      Add warning mode for classic division, almost exactly as specified in · 393661d1
      Guido van Rossum yazdı
      PEP 238.  Changes:
      
      - add a new flag variable Py_DivisionWarningFlag, declared in
        pydebug.h, defined in object.c, set in main.c, and used in
        {int,long,float,complex}object.c.  When this flag is set, the
        classic division operator issues a DeprecationWarning message.
      
      - add a new API PyRun_SimpleStringFlags() to match
        PyRun_SimpleString().  The main() function calls this so that
        commands run with -c can also benefit from -Dnew.
      
      - While I was at it, I changed the usage message in main() somewhat:
        alphabetized the options, split it in *four* parts to fit in under
        512 bytes (not that I still believe this is necessary -- doc strings
        elsewhere are much longer), and perhaps most visibly, don't display
        the full list of options on each command line error.  Instead, the
        full list is only displayed when -h is used, and otherwise a brief
        reminder of -h is displayed.  When -h is used, write to stdout so
        that you can do `python -h | more'.
      
      Notes:
      
      - I don't want to use the -W option to control whether the classic
        division warning is issued or not, because the machinery to decide
        whether to display the warning or not is very expensive (it involves
        calling into the warnings.py module).  You can use -Werror to turn
        the warnings into exceptions though.
      
      - The -Dnew option doesn't select future division for all of the
        program -- only for the __main__ module.  I don't know if I'll ever
        change this -- it would require changes to the .pyc file magic
        number to do it right, and a more global notion of compiler flags.
      
      - You can usefully combine -Dwarn and -Dnew: this gives the __main__
        module new division, and warns about classic division everywhere
        else.
      393661d1
  10. 23 Tem, 2001 1 kayıt (commit)
  11. 18 Tem, 2001 1 kayıt (commit)
  12. 16 Tem, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Part way to allowing "from __future__ import generators" to communicate · 5ba58662
      Tim Peters yazdı
      that info to code dynamically compiled *by* code compiled with generators
      enabled.  Doesn't yet work because there's still no way to tell the parser
      that "yield" is OK (unlike nested_scopes, the parser has its fingers in
      this too).
      Replaced PyEval_GetNestedScopes by a more-general
      PyEval_MergeCompilerFlags.  Perhaps I should not have?  I doubted it was
      *intended* to be part of the public API, so just did.
      5ba58662
  13. 12 Haz, 2001 1 kayıt (commit)
  14. 10 Nis, 2001 1 kayıt (commit)
  15. 22 Mar, 2001 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Extend support for from __future__ import nested_scopes · bc320247
      Jeremy Hylton yazdı
      If a module has a future statement enabling nested scopes, they are
      also enable for the exec statement and the functions compile() and
      execfile() if they occur in the module.
      
      If Python is run with the -i option, which enters interactive mode
      after executing a script, and the script it runs enables nested
      scopes, they are also enabled in interactive mode.
      
      XXX The use of -i with -c "from __future__ import nested_scopes" is
      not supported.  What's the point?
      
      To support these changes, many function variants have been added to
      pythonrun.c.  All the variants names end with Flags and they take an
      extra PyCompilerFlags * argument.  It is possible that this complexity
      will be eliminated in a future version of the interpreter in which
      nested scopes are not optional.
      bc320247
  16. 02 Mar, 2001 1 kayıt (commit)
  17. 23 Şub, 2001 1 kayıt (commit)
    • Barry Warsaw's avatar
      Py_Main(): When compiled by Insure (i.e. __INSURE__ is defined), call · 3e13b1e4
      Barry Warsaw yazdı
      the internal API function to release the interned strings as the very
      last thing before returning status.  This aids in memory use debugging
      because it eliminates a huge source of noise from the reports.  This
      is never called during normal (non-debugging) use because releasing
      the interned strings slows Python's shutdown and isn't necessary
      anyway because the system will always reclaim the memory.
      3e13b1e4
  18. 22 Şub, 2001 1 kayıt (commit)
  19. 15 Ara, 2000 1 kayıt (commit)
  20. 03 Kas, 2000 1 kayıt (commit)
    • Thomas Wouters's avatar
      Move our own getopt() implementation to _PyOS_GetOpt(), and use it · 2cffc7d4
      Thomas Wouters yazdı
      regardless of whether the system getopt() does what we want. This avoids the
      hassle with prototypes and externs, and the check to see if the system
      getopt() does what we want. Prefix optind, optarg and opterr with _PyOS_ to
      avoid name clashes. Add new include file to define the right symbols. Fix
      Demo/pyserv/pyserv.c to include getopt.h itself, instead of relying on
      Python to provide it.
      2cffc7d4
  21. 15 Eyl, 2000 1 kayıt (commit)
  22. 05 Eyl, 2000 1 kayıt (commit)
  23. 01 Eyl, 2000 1 kayıt (commit)
  24. 27 Agu, 2000 1 kayıt (commit)
    • Guido van Rossum's avatar
      Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), · 0df002c4
      Guido van Rossum yazdı
      PyRun_FileEx().  These are the same as their non-Ex counterparts but
      have an extra argument, a flag telling them to close the file when
      done.
      
      Then this is used by Py_Main() and execfile() to close the file after
      it is parsed but before it is executed.
      
      Adding APIs seems strange given the feature freeze but it's the only
      way I see to close the bug report without incompatible changes.
      
      [ Bug #110616 ] source file stays open after parsing is done (PR#209)
      0df002c4
  25. 09 Tem, 2000 1 kayıt (commit)
  26. 30 Haz, 2000 2 kayıt (commit)
  27. 02 May, 2000 1 kayıt (commit)
  28. 01 May, 2000 1 kayıt (commit)
    • Guido van Rossum's avatar
      Marc-Andre Lemburg: · c15a9a1f
      Guido van Rossum yazdı
      Added -U command line option.
      
      With the option enabled the Python compiler interprets all "..."
      strings as u"..." (same with r"..." and ur"...").
      c15a9a1f
  29. 19 Nis, 1999 1 kayıt (commit)
  30. 09 Şub, 1999 1 kayıt (commit)
  31. 28 Ock, 1999 1 kayıt (commit)
  32. 07 Ara, 1998 1 kayıt (commit)
  33. 07 Eki, 1998 1 kayıt (commit)
  34. 13 Nis, 1998 1 kayıt (commit)
  35. 10 Nis, 1998 1 kayıt (commit)