Is there a doctest mailing list? I couldn't find it.
I'm try to use doctest to verify my docs (imagine that!) but I'm having trouble with the one that uses pickle (imagine
Any advice on how to make it work?
Here's the excerpt:
Enumerations can be pickled and unpickled::
>>> from enum import Enum
>>> class Fruit(Enum):
... tomato = 1
... banana = 2
... cherry = 3
>>> from pickle import dumps, loads
>>> Fruit.tomato is loads(dumps(Fruit.tomato))
The usual restrictions for pickling apply: picklable enums must be defined in
the top level of a module, since unpickling requires them to be importable
from that module.
Oh, and I just realized this is probably why the flufl.enum docs import from a preexisting module instead of creating a
new class on the spot. Still, it would be nice if this could work.
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt,
*.py, *.c and *.h files. I think it would be worthwhile to update the
source code and documentation for more modern RFCs.
For example for updating RFC3548 to RFC4648 there is an issue #16995.
On Wed, Jun 5, 2013 at 3:20 AM, lukasz.langa <python-checkins(a)python.org>wrote:
> +from weakref import WeakKeyDictionary
FYI, this change exposes a bug in the atexit module involving
subinterpreters, causing the refleaks reported by Antoine's daily report:
interpreter startup now always imports weakref, which imports atexit and
registers a classmethod. Unfortunately the atexit module doesn't seem to
know subinterpreters from subtitles and so doesn't unregister this
classmethod when the subinterpreter is terminated.
This isn't a new bug, but it's exposed by always importing weakref and
atexit during interpreter startup. I'm wondering if that's really necessary
Thomas Wouters <thomas(a)python.org>
Hi! I'm an email virus! Think twice before sending your email to help me
I just used the build system on the 3.4.0 docs, and some of the library modules (haven't checked the others) have the
TOC showing up at the bottom of the page instead of the top.
Am I doing something wrong?
I'd like to start this email by saying this is not a proposal to change
Python's build system. This is just the results of some experimentation you
might be interested it.
I have been working on a cross-platform build system called Meson, which is
implemented in Python 3. For symmetry I wanted to see if it could be used
to build Python itself. After about an evening worth of work, I got the
basic C parts (that is, the build targets in the main Makefile such as core
Python, pgen etc) built.
- pyconfig.h generation in a fully cross-platform way without Autoconf (not
tested with Visual Studio but should work as Meson has unit tests for this,
tests for functions in header files and some others not done)
- builds in a separate build directory, can have arbitrarily many build
dirs with different configurations (for gcc/clang/static
- configure time 5s, build time 8s on an i5 Macbook running Ubuntu
(Autotool-configure takes 37 s but it's not directly comparable because it
does a lot more)
- the file describing the build is 433 lines, most of which look like this:
- implementation of Meson is 100% Python 3, it does not have a dependency
on the shell and in fact already works on Windows
If you want to try it yourself, here are the steps (only 64 bit Linux
tested thus far):
- install python3-ply and Ninja (Ubuntu package ninja-build)
- get Meson git head: https://sourceforge.net/p/meson/code/
- get Python3 trunk
- download and extract the build files into trunk:
- cd into Python trunk and do the following commands:
And there you have it. You can't do much with it, though (except run pgen
to ensure that it actually did something ;) ).
If you have any questions that are not directly related to Python, feel
free to email me or the Meson mailing list.
Hi. My 2 cents about this: (well I'm only a noob)
I had this problem; I don't know about other people's environment, but
my environment's problem was that it was actually not POSIX-compliant:
it didn't have other file functions as well, but anyway the `fstat`
error is the FIRST error you get when you compile in such environments,
so people as unaware as me think the problem is with fstat only.
Anyway I think if you are going to remove anything, you should think in
terms of POSIX-compliancy of the target system. Removing HAVE_FSTAT
might be fine (as user can easily write his own version of the function
and have it included into the python's sources), but if you instead
provide the user with the ability to use his custom functions when POSIX
one's aren't available, it would help make python compile on even more
platforms. Sorry if this last one was off-topic.