1. 31 Agu, 2001 1 kayıt (commit)
    • 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
  2. 17 Agu, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      ceval, PyEval_MergeCompilerFlags: wasn't merging in the · e2c18e90
      Tim Peters yazdı
      CO_FUTURE_DIVISION flag.  Redid this to use Jeremy's PyCF_MASK #define
      instead, so we dont have to remember to fiddle individual feature names
      here again.
      
      pythonrun.h:  Also #define a PyCF_MASK_OBSOLETE mask.  This isn't used
      yet, but will be as part of the PEP 264 implementation (compile() mustn't
      raise an error just because old code uses a flag name that's become
      obsolete; a warning may be appropriate, but not an error; so compile() has
      to know about obsolete flags too, but nobody is going to remember to
      update compile() with individual obsolete flag names across releases either
      -- i.e., this is the flip side of PyEval_MergeCompilerFlags's oversight).
      e2c18e90
  3. 10 Agu, 2001 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Refactor future feature handling · fdd12f66
      Jeremy Hylton yazdı
      Replace individual slots in PyFutureFeatures with a single bitmask
      with one field per feature.  The flags for this bitmask are the same
      as the flags used in the co_flags slot of a code object.
      
          XXX This means we waste several bits, because they are used
          for co_flags but have no meaning for future statements.  Don't
          think this is an issue.
      
      Remove the NESTED_SCOPES_DEFAULT define and others.  Not sure what
      they were for anyway.
      
      Remove all the PyCF_xxx flags, but define PyCF_MASK in terms of the
      CO_xxx flags that are relevant for this release.
      
      Change definition of PyCompilerFlags so that cf_flags matches
      co_flags.
      fdd12f66
  4. 08 Agu, 2001 1 kayıt (commit)
    • Guido van Rossum's avatar
      Implement PEP 238 in its (almost) full glory. · 4668b000
      Guido van Rossum yazdı
      This introduces:
      
      - A new operator // that means floor division (the kind of division
        where 1/2 is 0).
      
      - The "future division" statement ("from __future__ import division)
        which changes the meaning of the / operator to implement "true
        division" (where 1/2 is 0.5).
      
      - New overloadable operators __truediv__ and __floordiv__.
      
      - New slots in the PyNumberMethods struct for true and floor division,
        new abstract APIs for them, new opcodes, and so on.
      
      I emphasize that without the future division statement, the semantics
      of / will remain unchanged until Python 3.0.
      
      Not yet implemented are warnings (default off) when / is used with int
      or long arguments.
      
      This has been on display since 7/31 as SF patch #443474.
      
      Flames to /dev/null.
      4668b000
  5. 02 Agu, 2001 1 kayıt (commit)
  6. 16 Tem, 2001 2 kayıt (commit)
    • Tim Peters's avatar
      Ugly. A pile of new xxxFlags() functions, to communicate to the parser · fe2127d3
      Tim Peters yazdı
      that 'yield' is a keyword.  This doesn't help test_generators at all!  I
      don't know why not.  These things do work now (and didn't before this
      patch):
      
      1. "from __future__ import generators" now works in a native shell.
      
      2. Similarly "python -i xxx.py" now has generators enabled in the
         shell if xxx.py had them enabled.
      
      3. This program (which was my doctest proxy) works fine:
      
      from __future__ import generators
      
      source = """\
      def f():
          yield 1
      """
      
      exec compile(source, "", "single") in globals()
      print type(f())
      fe2127d3
    • 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
  7. 23 Mar, 2001 1 kayıt (commit)
    • Ka-Ping Yee's avatar
      Add sys.excepthook. · b5c5132d
      Ka-Ping Yee yazdı
      Update docstring and library reference section on 'sys' module.
      New API PyErr_Display, just for displaying errors, called by excepthook.
      Uncaught exceptions now call sys.excepthook; if that fails, we fall back
          to calling PyErr_Display directly.
      Also comes with sys.__excepthook__ and sys.__displayhook__.
      b5c5132d
  8. 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
  9. 01 Mar, 2001 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Useful future statement support for the interactive interpreter · 9f324e96
      Jeremy Hylton yazdı
      (Also remove warning about module-level global decl, because we can't
      distinguish from code passed to exec.)
      
      Define PyCompilerFlags type contains a single element,
      cf_nested_scopes, that is true if a nested scopes future statement has
      been entered at the interactive prompt.
      
      New API functions:
          PyNode_CompileFlags()
          PyRun_InteractiveOneFlags()
          -- same as their non Flags counterparts except that the take an
             optional PyCompilerFlags pointer
      
      compile.c: In jcompile() use PyCompilerFlags argument.  If
          cf_nested_scopes is true, compile code with nested scopes.  If it
          is false, but the code has a valid future nested scopes statement,
          set it to true.
      
      pythonrun.c: Create a new PyCompilerFlags object in
          PyRun_InteractiveLoop() and thread it through to
          PyRun_InteractiveOneFlags().
      9f324e96
  10. 02 Şub, 2001 1 kayıt (commit)
    • Jeremy Hylton's avatar
      Move a bunch of definitions that were internal to compile.c to · 4b38da66
      Jeremy Hylton yazdı
      symtable.h, so that they can be used by external module.
      
      Improve error handling in symtable_enter_scope(), which return an
      error code that went unchecked by most callers. XXX The error handling
      in symtable code is sloppy in general.
      
      Modify symtable to record the line number that begins each scope.
      This can help to identify which code block is being referred to when
      multiple blocks are bound to the same name.
      
      Add st_scopes dict that is used to preserve scope info when
      PyNode_CompileSymtable() is called.  Otherwise, this information is
      tossed as soon as it is no longer needed.
      
      Add Py_SymtableString() to pythonrun; analogous to Py_CompileString().
      4b38da66
  11. 11 Eki, 2000 1 kayıt (commit)
  12. 16 Eyl, 2000 1 kayıt (commit)
  13. 01 Eyl, 2000 1 kayıt (commit)
  14. 27 Agu, 2000 2 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
    • Fredrik Lundh's avatar
      implements PyOS_CheckStack for Windows and MSVC. this fixes a · 2f15b25d
      Fredrik Lundh yazdı
      couple of potential stack overflows, including bug #110615.
      
      closes patch #101238
      2f15b25d
  15. 07 Agu, 2000 1 kayıt (commit)
  16. 09 Tem, 2000 1 kayıt (commit)
  17. 30 Haz, 2000 2 kayıt (commit)
  18. 26 Haz, 2000 1 kayıt (commit)
  19. 25 May, 2000 1 kayıt (commit)
  20. 04 Ara, 1998 1 kayıt (commit)
  21. 06 Şub, 1998 1 kayıt (commit)
  22. 29 Agu, 1997 1 kayıt (commit)
  23. 22 Agu, 1997 1 kayıt (commit)
  24. 12 Agu, 1997 2 kayıt (commit)
  25. 02 Agu, 1997 1 kayıt (commit)
    • Guido van Rossum's avatar
      Mass checkin (more to follow for other directories). · 29e46a9a
      Guido van Rossum yazdı
      Introduce truly separate (sub)interpreter objects.  For now, these
      must be used by separate threads, created from C.  See Demo/pysvr for
      an example of how to use this.  This also rationalizes Python's
      initialization and finalization behavior:
      
      Py_Initialize() -- initialize the whole interpreter
      Py_Finalize() -- finalize the whole interpreter
      
      tstate = Py_NewInterpreter() -- create a new (sub)interpreter
      Py_EndInterpreter(tstate) -- delete a new (sub)interpreter
      
      There are also new interfaces relating to threads and the interpreter
      lock, which can be used to create new threads, and sometimes have to
      be used to manipulate the interpreter lock when creating or deleting
      sub-interpreters.  These are only defined when WITH_THREAD is defined:
      
      PyEval_AcquireLock() -- acquire the interpreter lock
      PyEval_ReleaseLock() -- release the interpreter lock
      
      PyEval_AcquireThread(tstate) -- acquire the lock and make the thread current
      PyEval_ReleaseThread(tstate) -- release the lock and make NULL current
      
      Other administrative changes:
      
      - The header file bltinmodule.h is deleted.
      
      - The init functions for Import, Sys and Builtin are now internal and
        declared in pythonrun.h.
      
      - Py_Setup() and Py_Cleanup() are no longer declared.
      
      - The interpreter state and thread state structures are now linked
        together in a chain (the chain of interpreters is a static variable
        in pythonrun.c).
      
      - Some members of the interpreter and thread structures have new,
        shorter, more consistent, names.
      
      - Added declarations for _PyImport_{Find,Fixup}Extension() to import.h.
      29e46a9a
  26. 19 Tem, 1997 1 kayıt (commit)
  27. 14 Şub, 1997 1 kayıt (commit)
  28. 25 Eki, 1996 1 kayıt (commit)
  29. 22 May, 1996 1 kayıt (commit)
  30. 17 Şub, 1995 1 kayıt (commit)
  31. 07 Şub, 1995 1 kayıt (commit)
  32. 17 Ock, 1995 1 kayıt (commit)
  33. 12 Ock, 1995 1 kayıt (commit)
  34. 04 Ock, 1995 1 kayıt (commit)
    • Guido van Rossum's avatar
      Added 1995 copyright. · 5799b520
      Guido van Rossum yazdı
      object.h: made sizes and refcnts signed ints.
      stringobject.h: make getstrsize() signed int.
      methodobject.h: add METH_VARARGS and METH_FREENAME flag bit definitions.
      5799b520
  35. 14 Eyl, 1994 1 kayıt (commit)
  36. 07 Eyl, 1994 1 kayıt (commit)