James Y Knight, 10.03.2011 06:52:
But you're also left with not being able to 'import hashlib'. While python has
fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if
openssl was found at build time. So you can't just select at runtime that you
didn't want to use openssl.
Westley Martínez writes:
> Is it legal to distribute GPL programs that use the Win32 API?
Yes. Their use of the Win32 API falls under the "essential system
library" clause. The criterion for "essential" is that normal, basic
use of the system would fail without the library. Windows won't boot
On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote:
> It seems introduced by the patch debian/patches/setup-modules-ssl.diff
> with description "# DP: Modules/Setup.dist: patch to build _hashlib
> and _ssl extensions statically"
Indeed you're right -- out of the box, python still builds _ssl.so as a
s
Joao S. O. Bueno writes:
> Any libraries commonly avaliable with a CPython instalation can be
> considered as "system libraries" for GPL purposes - and so
> this would fall in the "system library exception" as described by the FAQ:
Note that your interpretation would allow Python to distribute
Am 09.03.11 20:25, schrieb Sturla Molden:
These methods require the memory to be aligned
on 32-byte boundaries.
You misread the documentation - it's a 32-*bit*
boundary that the LONG variable must be on. The malloc()
call that is currently used trivially meets this requirement.
As for the vola
On Tue, Mar 8, 2011 at 6:30 PM, Éric Araujo wrote:
> What’s the command you use with git? Maybe someone will find the
Mercurial one.
>
Something like the following, assuming we're both working on branch "master"
to begin with.
git fetch their-repository master:experimental-branch
git diff mas
On Thu, Mar 10, 2011 at 12:49 AM, Westley Martínez wrote:
> On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote:
>> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
>> 2.6) is *always* linked against openssl, instead of waiting for you to
>> "import ssl".
>>
>> Doe
Am 09.03.11 18:20, schrieb James Y Knight:
[1] Python (from 2.6) is *always* linked against openssl
Others have already pointed that out, but let me stress it again:
this statement is false. It is as possible and easy to build Python
without OpenSSL as it always was.
> instead of waiting for y
> IMO, it's "hg diff --git" that's broken, as it doesn't include the base
> revision (other formats, such as "hg export", do).
I agree that it's poor form to omit the revisions, and we should
supplicate Mercury at his temple. But I don't see the problem for
Reitveld integration; they're ea
On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
> 2.6) is *always* linked against openssl, instead of waiting for you to
> "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation)
Den 10.03.2011 03:02, skrev Mark Hammond:
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
Ok, sorry :-)
It would also be good to know if there is an actual behaviour bug
caused by this (ie, what problems can be obse
On 4 Mar, 2011, at 16:35, Martin v. Löwis wrote:
>
>
> I'd still like the PEP to tell me whether it's python3w.exe or
> pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
> me). It would also be good if the PEP took a position on providing
> pythonXY.exe binaries on Windows (with
> Indeed, see http://bugs.python.org/issue11244
Yes, I've noticed that too. However, if I'm not missing something, your patches
do not address folding of -0.
Btw, there's an alternative approach to allow "recursive" constant folding.
Instead of keeping a stack of last constants, you can keep a po
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
Mark
On Wed, Mar 9, 2011 at 8:20 PM, James Y Knight wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
> 2.6) is *always* linked against openssl, instead of waiting for you to
> "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation) to
Atomic operations (InterlockedCompareExchange, et al.) are used on the
field 'owned' in NRMUTEX. These methods require the memory to be aligned
on 32-byte boundaries. They also require the volatile qualifer. Three
small changes are therefore needed (see below).
Regards,
Sturla Molden
t
Hello,
> I've noticed since version 3.2 python doesn't fold -0:
Indeed, see http://bugs.python.org/issue11244
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
Hello,
I've noticed since version 3.2 python doesn't fold -0:
Python 3.1.3 (r313:86834, Nov 28 2010, 10:01:07)
>>> def foo(): return -0
>>> dis(foo)
1 0 LOAD_CONST 1 (0)
3 RETURN_VALUE
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00)
>>> def foo(): return -0
On Thu, Mar 10, 2011 at 00:32, Antoine Pitrou wrote:
> Also, with the system Python 2.6 shipped on a Mandriva distribution:
>
> $ ldd /usr/bin/python
> linux-vdso.so.1 => (0x7fff8456d000)
> libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0
> (0x7f1a0b1e2000) libc.so.6 =>
On Wed, 9 Mar 2011 18:20:01 -0500
James Y Knight wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
> 2.6) is *always* linked against openssl, instead of waiting for you to
> "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation)
On 9 Mar 2011, at 06:50, Georg Brandl wrote:
> On 08.03.2011 23:47, "Martin v. Löwis" wrote:
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the firs
It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
2.6) is *always* linked against openssl, instead of waiting for you to "import
ssl".
Doesn't this mean it's now impossible (rather, a license violation) to
distribute a GPL'd python program (or to use a GPL'd library in
On 3/9/2011 9:50 AM, Tim Lesher wrote:
We used to do biweekly-ish Python-Dev summaries for this reason.
They were, is a sense, too detailed, complete, and voluminous.
In whatever format, terser announcement of just things others really
need to know - like decisions that affect them, would pro
On 3/9/2011 4:14 PM, Antoine Pitrou wrote:
On Wed, 9 Mar 2011 19:42:36 +0100
Perhaps the part of the "what's new" document which deals with porting
issues and compatibility breakage would need more highlighting?
That could go at the tops.
Deletions in 3.3
...
Planned deletions in future ver
At 05:35 PM 3/4/2011 +, Michael Foord wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Er, what? That's news to me. Could you file a bug report about what
doesn't work, specifically?
___
On Wed, 9 Mar 2011 19:42:36 +0100
Giampaolo Rodolà wrote:
> > Actually, why not put up a web page of "upcoming changes" somewhere, that
> > lists major decisions with user impact that were taken on python-dev?
>
> I think "what's new" serves this purpose properly.
> Usually, every time I commit a
On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote:
> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel wrote:
>> Actually, why not put up a web page of "upcoming changes" somewhere, that
>> lists major decisions with user impact that were taken on python-dev?
>> Including a link to the relevant discussion
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
I think "what's new" serves this purpose properly.
Usually, every time I commit a new feature, I update the what's new
file as well.
In fact we alread
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel wrote:
> "Martin v. Löwis", 08.03.2011 23:47:
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the
On Wed, Mar 9, 2011 at 01:15, Stefan Behnel wrote:
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
> Including a link to the relevant discussion and decision. Often enough,
> decisions are taken ins
On 3/9/2011 7:55 AM, Mark Shannon wrote:
Hi,
I hope this is the right place to ask this.
Do anyone know why the str (unicode) object is implemented
with an external buffer like list, rather than internal one like
tuple and bytes?
Would anything bad happen if it were changed?
I'm not suggesting
Hi,
I hope this is the right place to ask this.
Do anyone know why the str (unicode) object is implemented
with an external buffer like list, rather than internal one like
tuple and bytes?
Would anything bad happen if it were changed?
I'm not suggesting any changes, just doing some research.
C
On 3/9/2011 3:15 AM, Scott Dial wrote:
> I wanted to draw attention to issue11450 [1]. In trying to using mq to
> work on patches for CPython, I found that I could no longer get regrtest
> to run.
Just to update this thread, thanks to the swift work of Nadeem Vawda and
Antoine for pushing it in, i
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel wrote:
> A publicly visible list of those decisions would
>
> a) make it easier for non-core developers to follow important changes on
> python-dev
>
> b) allow potentially impacted people to bring up their POV more quickly,
> e.g. during the alpha cyc
On 9 March 2011 06:27, Mark Hammond wrote:
> I'm glad solving world hunger is out of scope for this :) I understand your
> position but my personal opinion is that simple support for #! is more
> desirable. I'd be happy to go with the consensus though...
Just in case you need some reassurance a
I wanted to draw attention to issue11450 [1]. In trying to using mq to
work on patches for CPython, I found that I could no longer get regrtest
to run. This issue comes down to the size of the output of
"hg id -t ." being much longer than expected.
$ hg qnew dummy-patch
$ echo "/* dummy change */"
On 3/9/2011 1:27 AM, Mark Hammond wrote:
your position but my personal opinion is that simple support for #! is
more desirable.
I agree. One weird line in a file is enough!
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http:/
37 matches
Mail list logo
