d in by
ceval.
Other than that, looking up the state inside the module but cache it (like
it's done for the _decimal context) also has reasonable performance.
Also I hit the same issues that Eli mentioned here a while ago:
https://mail.python.org/pipermail/python-dev/20
Hi,
I've released mpdecimal-2.4.1:
http://www.bytereef.org/mpdecimal/changelog.html
da74d3cfab559971a4fbd4fb506e1b4498636eb77d0fd09e44f8e546d18ac068
mpdecimal-2.4.1.tar.gz
Starting with Python 3.4.2, this version should be used for an external
libmpdec.
Stefan
of just the build of _decimal or something?)
I think using "memory.h" in an application is standard conforming.
Since _decimal compiles on all other Linux platforms, it may be worth
reporting this to the Android developers and see if they can fix it
(possibly by not including memory
dest = PyMem_Malloc(len * (sizeof *dest));
> +dest = PyMem_New(Py_ssize_t, len);
> if (dest == NULL) {
> PyErr_NoMemory();
> return NULL;
This, too, was already protected by len == ndim <= 64.
Stefan Krah
___
pe and would
extend to functions (not only tasks and generators).
c) ``man 3 setcontext``. A replacement for setjmp/longjmp. Somewhat
related in that it could be used to implement coroutines.
d) The .NET flowery language. I do did not fully understand what the
.NET ExecutionConte
s in a tls structure
and cache the whole structure. Extrapolating from my experiences with the
context, this might have a slowdown of "only" 4%.
Still, the argument "who uses subinterpreters?" of course still remains.
Stefa
ord
I'd expect something like a C struct or an ML record.
> from dataclass import dataclass
This is more intuitive, since the PEP example also has attached methods
like total_cost(). I don't think this is really common for records.
Stefan Krah
__
On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> On 2017-09-14 10:45, Stefan Krah wrote:
> >I'd expect something like a C struct or an ML record.
>
> Struct is taken, and your second example is record.
*If* the name were collections.record, I'd expect
ike to get rid
of this arcane rule.
https://bugs.python.org/issue31443
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-d
://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-crt/misc/mingw-aligned-malloc.c
Victor wrote a patch and would like to avoid adding a (probably unnecessary)
emulation function. I agree with that.
So if any platform does not have some form of aligned_alloc(), please
speak up.
Stefan Krah
ong with the new interface, everyone should be happy.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40m
g an emulation
> layer in terms of the old slots.
I don't have an opinion whether new slots should be available. For my use
case I just need PyMem_AlignedAlloc(), PyMem_AlignedFree() that automatically
use the faster allocator for 'sizeof(void *) <= align <= ALIGNMENT' and
&#x
n't
care.
Despite the mentioned shortcomings of Pipermail, it is 5 times faster
for me to navigate and less stressful to look at.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
k Pipermail is great for that. Quiet design, nice font, good contrast
for speed reading.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailma
.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e on
> the memory and/or CPU performance of the current dict implementation
I would think this is very unlikely, given that the previous dict implementation
has always been very fast. The new one is very fast, too.
Stefan Krah
___
Python-Dev mail
On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote:
> Do you suggest to make dictionary displays producing OrderedDict
> instead of dict?
No, this is essentially a language spec doc issue that would guarantee
the ordering properties of the current dict implementation.
Stefa
On Sun, Nov 05, 2017 at 09:09:37PM +0200, Serhiy Storchaka wrote:
> 05.11.17 20:39, Stefan Krah пише:
> >On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote:
> >>2. Someone invents a new arbitrary-ordered container that would improve on
> >>the memory and/or CPU perf
On Sun, Nov 05, 2017 at 09:35:38PM +0200, Serhiy Storchaka wrote:
> 05.11.17 21:20, Stefan Krah пише:
> >On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote:
> >>Do you suggest to make dictionary displays producing OrderedDict
> >>instead of dict?
>
x = pi_float()
$ time ./micropython xxx.py
real0m4.424s
user0m4.406s
sys 0m0.016s
$
$ time ../../cpython/python xxx.py
real0m1.066s
user0m1.056s
sys 0m0.010s
Congratulations ...
Stefan Krah
___
Python-Dev mailing list
Py
as a slightly mischievous benchmark indeed. -- Whether the proposal
is surreal or not depends on the likelihood that a) a substantially faster dict
algorithm will emerge and b) CPython, PyPy and Jython will switch to it.
My proposal was based on the fact t
ranteeing the insertion order of
dict literals.
If further guarantees are proposed, perhaps it would be a good idea to
open a new thread and state what exactly is being proposed.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
n that guarantee
> in a formally implementation-independent and future-proof way.
Ok good, I was primarily worried about collections.UnorderedDict coming up
and users thinking that OrderedDict could be replaced entirely by dict().
Stefan Krah
_
ones explaining how to use a tool
> to write the extension module for you :)
They will be slower and in my experience not easier to maintain -- quite
the opposite.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
precations.
I haven't followed the long discussions, so this is probably not a very
novel observation.
But it seems to me that we have a problem getting users to treat the
python command like e.g. gcc.
If I want gcc warnings, I use -Wall -Wextra.
I think the whole problem is that python w
the method is described in the Python Cookbook.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
015-July/001022.html
I want to add here that existing schemes for eliminating global variables
are inefficient (20% speed hit for _decimal), so a complete solution
would have to address that as well.
Stefan Krah
___
Python-Dev mailing list
Pyth
Brett Cannon python.org> writes:
> Anyone object if I update PEP 7 to remove the optionality of curly braces
in PEP 7?
I strongly prefer braces everywhere, but I'm -1 on enforcing it.
Stefan Krah
___
Python-Dev mailing list
Python-Dev
es.
IMO secure code can only be achieved by auditing it quietly in
a terminal, not being distracted by peripheral things like
version control and web interfaces (green merge buttons!) and
trying to do formal proofs (if time allows for it).
So I would not want to enforce a style if it makes some people
IMO the timings of the benchmark suite are a bit unstable -- this is not the
fault of Intel's setup, I noticed it also when running the suite myself.
On Tue, Jan 26, 2016 at 06:48:54PM +, Stewart, David C wrote:
> Wow, what happened to Python default to cause such a regression?
>
>
>
>
>
processing
step followed by the IBM specification grammar.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
the PEP are guaranteed to be accepted in the future.
One reason for keeping it simple is that I would not like to slow down
string conversion, but thinking about two grammars is also a problem --
part of the string conversion in libmpdec is modeled in ACL2, which
would be
g like that.)
Well, I think in this case it's the gcc AIX maintainer running it, so...
I think we should have a policy to stop reporting issues on unstable
bots unless someone has a concrete fix OR the bot maintainers are
known to fix issues fast (but that does not seem to be the case).
patches, the locale.h and
langinfo.h problems are solved. Do you think the following issues on the
Python bug tracker could be closed?
http://bugs.python.org/issue20305
http://bugs.python.org/issue22747
http://bugs.python.org/issue17905
Stefan Krah
_
o http://bugs.python.org/issue23496?
As I understand, that issue seems abandoned and the patches are
(despite core devs asking otherwise) against 3.4.
If Xavier is willing to do so, I think it would be best to start over
with a new issue that integrates his work
he tracker I just went by your contributor agreement.
I didn't check the lineage of the patches. Can I assume that either you
are re-licensing GPL-stuff written by yourself to the PSF (which is a
perfectly valid use case of the agreement) or rewriting from
sounds good.
> issue #26854: missing header on android for the ossaudiodev module
>(actually it's difficult to rewrite such an obvious patch)
Indeed. :)
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://
very healthy state if we
can afford to spend time on issues such as this one.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
even show up in Valgrind and
b) only occurs under severe memory pressure when the OOM-killer is
already waiting.
I'm honestly mystified by your terminology and it's beginning to feel
that you need to justify this patch at all costs.
Stefan Krah
python.supp ./python -c "import decimal"
[...]
==16945== LEAK SUMMARY:
==16945==definitely lost: 0 bytes in 0 blocks
^^^^
[...]
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
ht
Random832 fastmail.com> writes:
> On Thu, Apr 28, 2016, at 05:05, Stefan Krah wrote:
> > $ valgrind --suppressions=Misc/valgrind-python.supp ./python -c "import
> > decimal"
> >
> > [...]
> > ==16945== LEAK SUMMARY:
> &g
te and boring. I suspect that if
we promote wide changes across PyPI packages we'll see more additional
segfaults than theoretically plugged memory leaks.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
point is that I don't want to spend about a week per year
to evaluate the effect of needless code changes on a highly audited module.
And no, this isn't theoretical...
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https:
7.1.2, however version 8.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
If this continues, I'm going to release a premium version that's
50% faster and only available from bytereef.org or Anac
t would not have been present had things been left in place.
Also, I did not get any notification and now that I searched for
PEP 470 it seems that it wasn't announced here:
https://mail.python.org/pipermail/python
g them completely unreachable does not increase reliability. :)
> > But if the majority prefers PyPI that way, I'll stop arguing.
>
> I’m not sure what you mean here but if you want to argue for reverting PEP
470, I wouldn’t hold my
to upload Windows or
manylinux wheels just let me know; however, as this is just a proof of
concept, I do not intend to maintain it long-term.
That apparently all you can do: Move bits from place A to place B and not
care how long it took to produce them.
You
ls-sig level. Read Glyph's "calm" and "nice"
post again. Also note that *I* had already bowed out of the thread when
Glyph unnecessarily decided to spread complete misinformation.
Stefan Krah
___
Python-Dev mai
gal advice was apparently readily available.
https://pypi.python.org/pypi/m3-cdecimal
I can assure you that CoCs or "diversity statements" won't help you at all.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Chris Barker noaa.gov> writes:
> Indeed -- Fredrik never made any effort to support pypi, pip, etc. --
that's why the Pillow fork was started in the first place.
Maybe, but he created PIL, so thank you, Fredrik!
Stefan Krah
___
Python-
gleefully that I hadn't any (I still think they're
mistaken and an enterprising Oracle lawyer could come to a different
conclusion, but that's besides the point).
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
htt
people have concluded that the
influence/time ratio is too low to be worth it.
Also I don't know any other development group who is a) that quick
in trying to suppress any "off-topic" discussions and b) constantly
uses venues outside of the Python mailing lists to steer and
mani
ot None)
>
> requires_docstrings = unittest.skipUnless(HAVE_DOCSTRINGS,
I think that does not detect --without-doc-strings (i.e. the C docstrings are
empty).
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
Victor Stinner wrote:
> 2013/11/21 Nick Coghlan :
> > Huzzah! Thanks to you both for getting this ready for inclusion :)
>
> I now hope that someone will use it :-)
Congratulations! I hope pyfailmalloc can go into 3.4, too
RNING: renaming "_curses" since importing it failed: dynamic
module does not define init function (PyInit__curses)"
I need to see if http://hg.python.org/cpython/rev/97fb852c5c26 is
responsible.
Stefan Krah
___
Python-Dev mailing list
P
ow
readable the code is.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d that we should do, too.
+1 for cffi in the stdlib.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
me as with the Ubuntu version,
the remaining difference might be due to Ubuntu's use of -flto, as
Matthias suggests in http://bugs.python.org/issue17781 .
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
fines __GNUC__ but chokes on the __attribute__().
This works:
#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
> +_pickle_Pickler_clear_memo(PyObject *self, PyObject *Py_UNUSED(ignored))
I'm not a native speaker, but UNUSED(ignored) reads strange to me. I would
why this works, though, given that you say Intel doesn't support
> "__attribute__". The only difference I can spot is the space behind it.
You're right, icc version 12.0 supports the attribute. It must have been some
earlier version that failed.
Stefan Krah
ec-2.x.y series will stay binary compatible [1].
Stefan Krah
[1] Starting from 2.4.0: 2.4.0 is not binary compatible with 2.3.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsu
is another thing worth considering.
I agree with Serhiy, but that is probably known at this point. :)
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
is a non-trivial task, definitely
> inappropriate for 3.4.
I do not know the stringlib well enough, so I have a silly question:
Would it be possible to re-use the 2.x stringlib just for the bytes type,
name it byteslib and disable features as appropriate?
Stefan Krah
__
code will take up even more space (look e.g.
at Cython's custom parsers).
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python
ng the output of Argument Clinic later.
Serhiy, who started the discussion in another thread, is converting modules at
a rapid pace.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
user database.
Add another user? (yes/no): no
Goodbye!
freebsd-amd64# su - testuser
$ locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
Stefan Krah
_
Larry Hastings wrote:
> https://bitbucket.org/larry/clinic-buffer-samples/src
Thanks for doing this!
+1 for the sidefile, -1 for the current approach, +-0 for the rest.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
ht
oryview.h than memoryview.clinic.c.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Stefan Krah
___
Python-Dev mailing lis
Antoine Pitrou wrote:
> Objects/memoryview.clinic.h should be fine.
Last attempt:
Objects/memoryview.api.h
That is more neutral and describes what the file contains. IOW, it's easier to
ignore the name (which is good in this case).
Ste
y code.
Right. Objects/memoryview.ac.h perhaps? I sort of dislike reading full words
in filename extensions.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
Serhiy Storchaka wrote:
> .ac is well known suffix of autoconf related files.
I know, but unless someone writes Objects/configure.c I think this won't be a
problem.
> And tail .h has same disadvantages as .c.
I'm not strongly inconvenienced by those you liste
Larry Hastings wrote:
> Contestant 4: "Put in clinic directory, add .h"
>
> foo.c -> clinic/foo.c.h
> foo.h -> clinic/foo.h.h
+1 for this, 0 for the rest. Bonus points for any other directory name that is
more self-d
Stefan Krah wrote:
> Larry Hastings wrote:
> > Contestant 4: "Put in clinic directory, add .h"
> >
> > foo.c -> clinic/foo.c.h
> > foo.h -> clinic/foo.h.h
>
> +1 for this, 0 for the rest. Bonus points for any other directory name
is because signatures get really interesting for me
if they contain type information.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
andle "static inline" in header
files.
If you have a compiler that cannot, chances are that the platform is horribly
outdated and this particular performance issue will be relatively benign
compared to other ones.
Stefan Krah
___
Python-D
ones with
the more aggressive compilers) in release mode. I think that is beneficial
anyway.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman
, consider a bug in regrtest.py:
It happens that certain caches are initialized incrementally in each
repetition of the test, so the reported leaks are spurious. That is
why some caches like small integers are "warmed up" in regrtest.py.
Perhaps there is some recently added cache that n
st a decade,
> and can assure that none of those things you mention have yet
> happened.
Relax, I don't think Steve is making things up. That said, I can confirm
what you wrote: I've always installed Python to "Program Files" and I've
never had any issue
Just a warning, in case any of the new packaging team forgot to contact
http://cve.mitre.org/ .
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org
ip is some sort of apt-get
and all uploaded packages are safe.
Stefan Krah
[1] Note that the joke is quite innocent in comparison to what I've read on
distutils-sig about the subject.
___
Python-Dev mailing list
Python-Dev@python.org
htt
real question is: Why is there a warning if the person running pip
has explicitly allowed external packages?
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ntless because one cannot
trust governments.
OS package signing is useful since the packages are curated. If anyone
could upload a package to Debian, whereupon it would be signed with the
official key, apt-get would lose its usefulness.
Stefan Krah
___
tercepts mail (difficult, but far from the TLS attack category).
Maybe on a home or university network. Or a rogue person at a
mail provider.
4) Changes the uploaded file together with the hash.
pip would be perfectly happy, checking the hash via Google would turn
up a mismatch.
Stefa
correct sum would still exist under the scenario we're talking about
(i.e. not GHCQ hacking into Belgacom routers).
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
uggest that you confine that style of discussion to distutils-sig.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
idence to dispute that claim,
> although I'm surprised.
That is my understanding of the posted statistics, too. PyPI was overloaded,
the improved infrastructure fixed that, so more projects now host on PyPI.
Stefan Krah
___
Python-Dev mailing li
Donald, I'm out of his discussion. I have one last request: please don't
gossip about core devs in public as long as you have commit privs:
https://botbot.me/freenode/python-requests/
Stefan Krah
___
Python-Dev mailing list
Python-Dev@
requirements are no more valid that
> other possible. And other set of requirement fairly clearly lead to
> situation where CPython implementation is rejected as not correct for
> those requirements at all.
Several core-devs have said that using UTF-8 for MicroPython is perfectly okay.
ongobject.c.
> * Will VS 14 be golden prior to Python 3.5's release? It would suck to
> rely on a beta compiler.. :)
This is my only concern, too. Otherwise, +1 for the switch.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
h
Stefan Krah wrote:
> > * Will VS 14 be golden prior to Python 3.5's release? It would suck to
> > rely on a beta compiler.. :)
>
> This is my only concern, too. Otherwise, +1 for the switch.
One more thing: Will the SDK 64-bit tools be available for the Express
V
a new high for Twitter gossip. Well done. Perhaps in the next vote
the politbureau can indicate the intended outcome beforehand so we know how
to vote.
Thanks,
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
though, especially since the status quo
kind of works.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%
On Mon, Nov 19, 2018 at 04:08:07PM +0100, Victor Stinner wrote:
> Le lun. 19 nov. 2018 à 13:18, Stefan Krah a écrit :
> > In practice people desperately *have* to use whatever is there, including
> > functions with underscores that are not even officially in the C-API.
> &
think that such an API might be faster than CFFI on PyPy?
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ng how big the
breakage between each version is going to be.
But for the scientific ecosystem this sounds a bit like a potential
Python-4.0 breakage, which was universally rejected (so far).
In the extreme case I can imagine people staying on 3.7.
But it rea
ivate vs. public API.
As for PyPy, if I understood correctly, Armin Rigo was skeptical of the
proposed plan and favored publishing an API as a third party package.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
o not use it altogether [*] rather than trying to
> work around the compiler quirks.
Out of curiosity: Do these incomplete compilers have any problem with either
stdint.h or static inline functions in header files?
Stefan Behnel wrote:
> > you'd just pass in this string:
> >
> >(arg1 : int, arg2 : float, arg3 : ExtType, *, arg4=None) -> ExtType2
I've mentioned this proposal in http://bugs.python.org/issue16612 , but
it wasn't su
entations for the values.
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
1 - 100 of 324 matches
Mail list logo
