An error occurred fetching the project authors.
- 25 Feb, 2009 1 commit
-
-
Robert Bradshaw authored
-
- 10 Feb, 2009 1 commit
-
-
Robert Bradshaw authored
-
- 17 Jan, 2009 2 commits
-
-
Jason Evans authored
-
Stefan Behnel authored
-
- 16 Jan, 2009 1 commit
-
-
Robert Bradshaw authored
-
- 20 Dec, 2008 1 commit
-
-
Jason Evans authored
-
- 27 Nov, 2008 1 commit
-
-
Dag Sverre Seljebotn authored
-
- 23 Nov, 2008 3 commits
-
-
Stefan Behnel authored
-
Stefan Behnel authored
-
Stefan Behnel authored
-
- 11 Nov, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 29 Oct, 2008 2 commits
-
-
Robert Bradshaw authored
-
Robert Bradshaw authored
-
- 25 Oct, 2008 2 commits
-
-
Stefan Behnel authored
-
Stefan Behnel authored
-
- 16 Oct, 2008 1 commit
-
-
Lisandro Dalcin authored
-
- 08 Oct, 2008 2 commits
-
-
Robert Bradshaw authored
-
Robert Bradshaw authored
-
- 04 Oct, 2008 2 commits
-
-
Robert Bradshaw authored
-
Robert Bradshaw authored
-
- 30 Sep, 2008 2 commits
-
-
"Lisandro Dalcin" authored
-
Robert Bradshaw authored
This paves the way for "cimport *" cimporting types, as well as other simplifications.
-
- 27 Sep, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 23 Sep, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 22 Sep, 2008 1 commit
-
-
Dag Sverre Seljebotn authored
--HG-- rename : tests/run/noneattributeacc.pyx => tests/run/nonecheck.pyx
-
- 13 Sep, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 16 Aug, 2008 2 commits
-
-
Stefan Behnel authored
-
Stefan Behnel authored
-
- 15 Aug, 2008 1 commit
-
-
Stefan Behnel authored
String literals pass through the compiler as follows: - unicode string literals are stored as unicode strings and encoded to UTF-8 on the way out - byte string literals are stored as correctly encoded byte strings by unescaping the source string literal into the corresponding byte sequence. No further encoding is done later on! - char literals are stored as byte strings of length 1. This can be verified by the parser now, e.g. a non-ASCII char literal in UTF-8 source code will result in an error, as it would end up as two or more bytes in the C code, which can no longer be represented as a C char. Storing byte strings is necessary as we otherwise loose the ability to encode byte string literals on the way out. They do not necessarily contain only bytes that fit into the source code encoding as the source can use escape sequences to represent them. Previously, ASCII encoded source code could not contain byte string literals with properly escaped non-ASCII bytes. Another bug that was fixed: in Python, escape sequences behave different in unicode strings (where they represent the character code) and byte strings (where they represent a byte value). Previously, they resulted in the same byte value in Cython code. This is only a problem for non-ASCII escapes, since the character code and the byte value of ASCII characters are identical.
-
- 14 Aug, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 12 Aug, 2008 1 commit
-
-
Stefan Behnel authored
fixes the unicode literal indexing problem (only for unicode strings, not for byte strings!)
-
- 11 Aug, 2008 1 commit
-
-
Stefan Behnel authored
-
- 08 Aug, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 06 Aug, 2008 1 commit
-
-
Dag Sverre Seljebotn authored
dtype is not supported yet (needs change in parser).
-
- 03 Aug, 2008 2 commits
-
-
Robert Bradshaw authored
I don't know how long_literal used to work, must have ran tests before that refactor...
-
Robert Bradshaw authored
-
- 02 Aug, 2008 1 commit
-
-
Robert Bradshaw authored
-
- 01 Aug, 2008 2 commits
-
-
Dag Sverre Seljebotn authored
-
Dag Sverre Seljebotn authored
-
- 31 Jul, 2008 1 commit
-
-
Robert Bradshaw authored
Now accepts U and LL suffixes, and large integer literals are longs rather than being truncated as Python objects.
-