I would like to split the huge unicodeobject.c file into smaller
files. It's just the longest C file of CPython: 14,849 lines.
I don't know exactly how to split it, but first I would like to know
if you would agree with the idea.
I don't know if it's better to use a subdirectory, or use a prefix for
new files: Objects/unicode_methods.c, Objects/unicode_codecs.c, etc.
There is already a Python/codecs.c file for example (same filename).
I would like to split the unicodeobject.c because it's hard to
navigate in this huge file between all functions, variables, types,
macros, etc. It's hard to add new code and to fix bugs. For example,
the implementation of str%args takes 1000 lines, 2 types and 10
functions (since my refactor yesterday, in Python 3.3 the main
function is 500 lines long :-)).
I only see one argument against such refactoring: it will be harder to
Use this script on a json file and observe all the trailing spaces
generated. (screenshot attached.)
Pretty print json file.
if __name__ == '__main__':
if '-h' in sys.argv or '--help' in sys.argv:
print "Usage: ppjson <FILE>"
assert sys.argv, "No file provided"
with open(sys.argv) as f:
print json.dumps(json.load(f), indent=4)
I'd like to submit the Wheel PEPs 425 (filename metadata), 426
(Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
been stable since May and we are preparing a patch to support it in
pip, but we need to earn consensus before including it in the most
widely used installer.
Wheel is a binary packaging format that is mostly based on the
phenomenal work done by 'packaging' as PEP 376 et al. The resulting
packages solve packaging problems by being installable without
setup.py or any variation of distutils, lxml can be installed in 0.7
seconds, and a simple installer is just "unzip" inside site-packages.
Wheel installers know about the major version number of the spec
itself, and will refuse to install version 2.0 wheels if they do not
understand them, so the format can be changed down the line.
Let me know what I need to do to get it accepted, if anything needs to
be added or revised, or, preferably, that it is awesome and you want
to use it ASAP.
Here is the code:
DEBUG = 
FONT_NAMES = 
FONT_NAMES = "query()"
Here is the output:
Traceback (most recent call last):
File "globalocal.py", line 13, in <module>
File "globalocal.py", line 8, in names
UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment
As you may see there is inconsistency between handling of line 6 -
"if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". This is very magical
and hard to troubleshoot. I wonder if this message can be improved with a
pointer to the concept on when global variables become local?
I wonder why Python uses signed chars for bytes
This is a Java thing, but Java doesn't have unsigned types at all
Windows implements BYTE as unsigned char, and it is in the same line as
WORD, DWORD etc. The way you look at memory contents in assembly.
byte type is also unsigned in .NET platform for all languages implementes,
and also has a sbyte counterpart.
When working with bytes in decimal system it is much more convenient to
operate with strictly positive values than with -128 - 127 (or is it -127
Could anybody reopen http://bugs.python.org/issue8766 ? I can't.
Reproducible 100% with Python 3.2 and 3.3 (3.1 didn't test).
> set PYTHONHOME=C:\
BTW, what is the role of PYTHONPATH on Windows?
Is it a path for %INSTALLDIR%\Lib\site-packages?
I just sent the announcement for the bug day to python-list (apparently
pending approval), core-mentorship and montrealpython. Core developers
who plan on being on IRC can add themselves to the list on
http://wiki.python.org/moin/PythonBugDay so that people can connect
nicknames with people.
The list by Petri at http://piratepad.net/pyconfi-sprint-issues can
still be updated. Otherwise we’ll fall back to the usual roundup query
for easy bugs.
In some scenarios, configure produces a Makefile which fails because ASDLGEN
doesn't point to a working Python. In particular, it seems to assume that if
there is an executable called e.g. "python3.4" on the path, then that will be a
In my perhaps unusual but IMO perfectly valid setup, I have various Python repos
set up like so:
+ and so on for 3.2, 3.1, 2.7
In order to facilitate testing some script against multiple Python versions, I
have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just run
the programs in the relevant directories in $HOME/projects/python/. (I know I
can do this using aliases etc., but I think that's beside the point.)
When I run configure in the repo for the default branch, it appears to look for
a Python on the path named python3.4, finds one in $HOME/bin, and thus generates
an ASDLGEN value of "python3.4". If I happen to have a built Python in the
default repo, then the script in $HOME/bin will successfully run that, and all
appears well; but if I clean the default repo and re-run make, it fails at the
ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
able to invoke $HOME/projects/python/default/python.
Is this a bug in configure, or is my configuration regarded as too perverse to