On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou <solipsis(a)pitrou.net> wrote:
> Le Wed, 27 Feb 2013 11:33:30 -0800,
> "fwierzbicki(a)gmail.com" <fwierzbicki(a)gmail.com> a écrit :
>>
>> There are a couple of spots that might be more controversial. For
>> example, Jython has a file Lib/zlib.py that implements zlib in terms
>> of the existing Java support for zlib. I do wonder if such a file is
>> acceptable in CPython's Lib since its 195 lines of code would be
>> entirely skipped by CPython.
>
> That's a bit annoying. How will we know that the code still works, even
> though our buildbots don't exercise it?
> Also, what happens if the code doesn't work anymore?
Agreed on those problems. Would it be possible to use a design
pattern in these cases so the Jython-only code wouldn't need to be
part of the CPython repo? A naive example would be refactoring zlib
to allow subclassing in the way that Jython needs, and then Jython
could subclass in its own repo. CPython could have tests to check the
subclass "contract" that Jython needs.
--Chris
Hi
I know this is a hard topic, but python-dev is already incredibly
high-volume and dragging discussion off-topic is making following
important stuff (while ignoring unimportant stuff) very hard.
For example in a recent topic "cffi in stdlib" I find a mail that says
"we have to find a sufficiently silly species of snake". It's even
funny, but it definitely makes it very hard to follow for those of us
who don't read python-dev 24/7. Would it be reasonable for python-dev
to generally try to stay on topic (for example if the thread is called
"silly species of snakes", I absolutely don't mind people posting
there whatever they feel like as long as I'm not expected to read
every single message).
Cheers,
fijal
Following up on a conversation on python-dev from last December:
http://mail.python.org/pipermail/python-dev/2012-December/122920.html
I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
into the CPython source tree.
http://www.python.org/dev/peps/pep-0436/
Argument Clinic itself hasn't changed much in the intervening three
months; I did add a prototype extension mechanism for adding user types
at runtime, and I allow writing the generated code to a separate file.
The PEP is adopted out of the "clinic.txt" included with the prototype,
updated and with a new rationale.
For what it's worth, the bug tracker issue is here:
http://bugs.python.org/issue16612
I'm guessing python-dev is the right place for the ten-thousand-foot
view topics: the merits of the specific proposed DSL syntax, the
possible runtime extension API, and the approach as a whole. So for now
let's just use the bug tracker issue for code reviews and the like.
The prototype implementation is checked in here:
https://bitbucket.org/larry/python-clinic/
as well as being posted to the above issue on the tracker in patch form.
I look forward to your comments,
//arry/
See: http://mail.python.org/mailman/listinfo/python-legal-sig
Open archives. As the header says this is for the discussion of CLA/other issues. If specific legal questions or alterations to Python/the PSF trademarks, CLA/etc are requested those *must* be sent to psf(a)python.org for board oversight and approval. This is an open discussion list, and is not official legal stance of the foundation, trademarks, etc.
jesse
eli.bendersky <python-checkins(a)python.org> wrote:
> +Ordered comparisons between enumeration values are *not* supported. Enums are
> +not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
Actually all I want from a Python enum is to be like a C enum with symbolic
representations for the values.
Stefan Krah
Hi there,
like posted here:
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/xXij44…
I'm curious to find out are there any timelines when 2.7.4 and 3.2.4 will
be available.
I was kinda waiting for it to release new Portable Python so now I'm just
curious should I wait bit more and release on this python base or should I
go for 2.7.3 and 3.2.3
On Feb 25, 2013, at 05:40 PM, brett.cannon wrote:
>http://hg.python.org/peps/rev/7aa92fb33436
>changeset: 4776:7aa92fb33436
>user: Brett Cannon <brett(a)python.org>
>date: Mon Feb 25 11:39:56 2013 -0500
>summary:
> Add PEP 445: The Argument Clinic DSL
I beat you with PEP 436. :)
-Barry
Hi.
I downloaded Python 3.3 source, opened up the solution in VS2012 Express for Desktop and built the "python" subproject using "Release" and "x64" configurations. I now have a "python.exe" in the PCBuild/amd64 subfolder that appears to be working as far as i can see.
I have a few questions:
a) Is there a test suite that I can run to verify that the build is working fine?
b) I now intend to build some extensions (such as NumPy). Not sure if this is the right list, but would I need to modify something in distutils to get it working with VS2012?
thanks,
Rahul
I wish to report the following bug.
Scipy v.11 library in python2.7 gives
spearmanrcorrel([1,2,3,4,5],[5,6,7,8,7]) = 0.8207 while scipy v.6 in
python2.5 gives spearmanr([1,2,3,4,5],[5,6,7,8,7]) = 0.825(which is
correct according to spearman correlation formula).
The spearman correlation for [1,2,3,4,5],[5,6,7,8,7] calculated online
according to formula available at :
https://statistics.laerd.com/calculators/spearmans-rank-order-correlation-c…,
also gives 0.825.
--The definition of spearmanr function in Scipy v.11 is given at :
http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.spearmanr.h….
Thanks,
- Om Damani
On Mon, Feb 25, 2013 at 12:41 PM, daniel.holth
<python-checkins(a)python.org> wrote:
> http://hg.python.org/peps/rev/7d2494f4cd0a
> changeset: 4772:7d2494f4cd0a
> user: Daniel Holth <dholth(a)fastmail.fm>
> date: Sun Feb 24 21:41:40 2013 -0500
> summary:
> PEP-0427: clarify some implementation details.
>
> Hope it's OK to clarify two details that came up during Vinay's distlib wheel
> implementation: zip directory filenames are encoded as utf-8, and it's nicer
> to put the .dist-info directory at the end of the archive.
It's better to announce the intended update/clarification on
python-dev first, but I agree both these adjustments are reasonable (I
don't remember if I actually said that in the distutils-sig thread).
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia