1. 02 Şub, 2009 1 kayıt (commit)
  2. 26 Agu, 2008 1 kayıt (commit)
    • Antoine Pitrou's avatar
      Issue #2534: speed up isinstance() and issubclass() by 50-70%, so as to · 0668c626
      Antoine Pitrou yazdı
      match Python 2.5 speed despite the __instancecheck__ / __subclasscheck__
      mechanism. In the process, fix a bug where isinstance() and issubclass(),
      when given a tuple of classes as second argument, were looking up
      __instancecheck__ / __subclasscheck__ on the tuple rather than on each
      type object.
      
      Reviewed by Benjamin Peterson and Raymond Hettinger.
      0668c626
  3. 12 Agu, 2008 1 kayıt (commit)
  4. 18 Mar, 2008 1 kayıt (commit)
  5. 17 Mar, 2008 1 kayıt (commit)
  6. 17 Şub, 2008 1 kayıt (commit)
    • Eric Smith's avatar
      Backport of PEP 3101, Advanced String Formatting, from py3k. · a9f7d624
      Eric Smith yazdı
      Highlights:
       - Adding PyObject_Format.
       - Adding string.Format class.
       - Adding __format__ for str, unicode, int, long, float, datetime.
       - Adding builtin format.
       - Adding ''.format and u''.format.
       - str/unicode fixups for formatters.
      
      The files in Objects/stringlib that implement PEP 3101 (stringdefs.h,
      unicodedefs.h, formatter.h, string_format.h) are identical in trunk
      and py3k.  Any changes from here on should be made to trunk, and
      changes will propogate to py3k).
      a9f7d624
  7. 10 Şub, 2008 1 kayıt (commit)
  8. 04 Şub, 2008 1 kayıt (commit)
  9. 19 Ara, 2007 1 kayıt (commit)
  10. 06 Ara, 2007 1 kayıt (commit)
    • Raymond Hettinger's avatar
      Fix Issue 1045. · 4e2f7140
      Raymond Hettinger yazdı
      Factor-out common calling code by simplifying the length_hint API.
      Speed-up the function by caching the PyObject_String for the attribute lookup.
      4e2f7140
  11. 21 Tem, 2007 1 kayıt (commit)
  12. 22 Eki, 2006 1 kayıt (commit)
  13. 12 Agu, 2006 1 kayıt (commit)
    • Neal Norwitz's avatar
      Patch #1538606, Patch to fix __index__() clipping. · 8a87f5d3
      Neal Norwitz yazdı
      I modified this patch some by fixing style, some error checking, and adding
      XXX comments.  This patch requires review and some changes are to be expected.
      I'm checking in now to get the greatest possible review and establish a
      baseline for moving forward.  I don't want this to hold up release if possible.
      8a87f5d3
  14. 18 Nis, 2006 1 kayıt (commit)
  15. 14 Nis, 2006 1 kayıt (commit)
  16. 07 Mar, 2006 1 kayıt (commit)
  17. 04 Mar, 2006 1 kayıt (commit)
  18. 15 Şub, 2006 1 kayıt (commit)
  19. 11 Şub, 2006 1 kayıt (commit)
  20. 24 Eyl, 2005 1 kayıt (commit)
  21. 12 Mar, 2004 2 kayıt (commit)
  22. 20 Eki, 2003 1 kayıt (commit)
  23. 12 May, 2003 1 kayıt (commit)
  24. 28 Şub, 2003 1 kayıt (commit)
  25. 25 Kas, 2002 1 kayıt (commit)
  26. 12 Agu, 2002 1 kayıt (commit)
  27. 08 May, 2002 1 kayıt (commit)
  28. 05 Ock, 2002 1 kayıt (commit)
  29. 28 Kas, 2001 1 kayıt (commit)
  30. 09 Kas, 2001 1 kayıt (commit)
  31. 28 Eki, 2001 1 kayıt (commit)
  32. 26 Eki, 2001 2 kayıt (commit)
    • Fred Drake's avatar
      Added two new functions to conveniently call functions/methods from C. · b421b8c1
      Fred Drake yazdı
      PyObject_CallFunctionObArgs() and PyObject_CallMethodObArgs() have the
      advantage that no format strings need to be parsed.  The CallMethod
      variant also avoids creating a new string object in order to retrieve
      a method from an object as well.
      b421b8c1
    • Tim Peters's avatar
      Generalize dictionary() to accept a sequence of 2-sequences. At the · 1fc240e8
      Tim Peters yazdı
      outer level, the iterator protocol is used for memory-efficiency (the
      outer sequence may be very large if fully materialized); at the inner
      level, PySequence_Fast() is used for time-efficiency (these should
      always be sequences of length 2).
      
      dictobject.c, new functions PyDict_{Merge,Update}FromSeq2.  These are
      wholly analogous to PyDict_{Merge,Update}, but process a sequence-of-2-
      sequences argument instead of a mapping object.  For now, I left these
      functions file static, so no corresponding doc changes.  It's tempting
      to change dict.update() to allow a sequence-of-2-seqs argument too.
      
      Also changed the name of dictionary's keyword argument from "mapping"
      to "x".  Got a better name?  "mapping_or_sequence_of_pairs" isn't
      attractive, although more so than "mosop" <wink>.
      
      abstract.h, abstract.tex:  Added new PySequence_Fast_GET_SIZE function,
      much faster than going thru the all-purpose PySequence_Size.
      
      libfuncs.tex:
      - Document dictionary().
      - Fiddle tuple() and list() to admit that their argument is optional.
      - The long-winded repetitions of "a sequence, a container that supports
        iteration, or an iterator object" is getting to be a PITA.  Many
        months ago I suggested factoring this out into "iterable object",
        where the definition of that could include being explicit about
        generators too (as is, I'm not sure a reader outside of PythonLabs
        could guess that "an iterator object" includes a generator call).
      - Please check my curly braces -- I'm going blind <0.9 wink>.
      
      abstract.c, PySequence_Tuple():  When PyObject_GetIter() fails, leave
      its error msg alone now (the msg it produces has improved since
      PySequence_Tuple was generalized to accept iterable objects, and
      PySequence_Tuple was also stomping on the msg in cases it shouldn't
      have even before PyObject_GetIter grew a better msg).
      1fc240e8
  33. 08 Eyl, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      Generalize operator.indexOf (PySequence_Index) to work with any · 16a77adf
      Tim Peters yazdı
      iterable object.  I'm not sure how that got overlooked before!
      
      Got rid of the internal _PySequence_IterContains, introduced a new
      internal _PySequence_IterSearch, and rewrote all the iteration-based
      "count of", "index of", and "is the object in it or not?" routines to
      just call the new function.  I suppose it's slower this way, but the
      code duplication was getting depressing.
      16a77adf
  34. 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
  35. 02 Agu, 2001 1 kayıt (commit)
  36. 05 May, 2001 3 kayıt (commit)
    • Tim Peters's avatar
      Reimplement PySequence_Contains() and instance_contains(), so they work · cb8d368b
      Tim Peters yazdı
      safely together and don't duplicate logic (the common logic was factored
      out into new private API function _PySequence_IterContains()).
      Visible change:
          some_complex_number  in  some_instance
      no longer blows up if some_instance has __getitem__ but neither
      __contains__ nor __iter__.  test_iter changed to ensure that remains true.
      cb8d368b
    • Tim Peters's avatar
      Generalize tuple() to work nicely with iterators. · 6912d4dd
      Tim Peters yazdı
      NEEDS DOC CHANGES.
      This one surprised me!  While I expected tuple() to be a no-brainer, turns
      out it's actually dripping with consequences:
      1. It will *allow* the popular PySequence_Fast() to work with any iterable
         object (code for that not yet checked in, but should be trivial).
      2. It caused two std tests to fail.  This because some places used
         PyTuple_Sequence() (the C spelling of tuple()) as an indirect way to test
         whether something *is* a sequence.  But tuple() code only looked for the
         existence of sq->item to determine that, and e.g. an instance passed
         that test whether or not it supported the other operations tuple()
         needed (e.g., __len__).  So some things the tests *expected* to fail
         with an AttributeError now fail with a TypeError instead.  This looks
         like an improvement to me; e.g., test_coercion used to produce 559
         TypeErrors and 2 AttributeErrors, and now they're all TypeErrors.  The
         error details are more informative too, because the places calling this
         were *looking* for TypeErrors in order to replace the generic tuple()
         "not a sequence" msg with their own more specific text, and
         AttributeErrors snuck by that.
      6912d4dd
    • Tim Peters's avatar
      Make PyIter_Next() a little smarter (wrt its knowledge of iterator · f4848dac
      Tim Peters yazdı
      internals) so clients can be a lot dumber (wrt their knowledge).
      f4848dac