> I think it's just trying to say dynamic rather than static
> linking, not that the library has to be a pre-existing
> one. The important thing is that the library can be
> updated just by replacing a file, without having to
> re-link the executable.
>
> So Windows DLLs qualify, as far as I can s
On 9/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> > I'm not suggesting that Python handle small ints itself and then farm
> > out large integer computations, I'm suggesting that since we've
> > already coalesced small ints into 'large'
On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> I'm not suggesting that Python handle small ints itself and then farm
> out large integer computations, I'm suggesting that since we've
> already coalesced small ints into 'large' ones, we might want to
> review the performance implications o
On 9/9/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > I think it's just trying to say dynamic rather than static ...
> > library can be updated just by replacing a file, ...
>
> > So Windows DLLs qualify, as far as I can see.
>
> How many external
[Larry Hastings]
> I see--it's avoiding the Birthday Paradox.
It /tends/ to, yes. This wasn't a design goal of the string hash,
it's just a property observed after it was adopted, and appreciated
much later ;-)
It's much clearer for Python's small-int hash, where hash(i) == i for
i != -1. That
On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I think it's just trying to say dynamic rather than static ...
> library can be updated just by replacing a file, ...
> So Windows DLLs qualify, as far as I can see.
How many external library calls would need to be resolved at runtime
for the fo
On 9/8/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> in comments in dictobject.c. As it notes there, hashing the strings
> "namea", "nameb", "namec", and "named" currently produces (on a
> sizeof(long) == 4 box):
> -1658398457
> -1658398460
> -1658398459
> -1658398462
> That the hash codes are ve
Martin v. Löwis wrote:
> b) Use a suitable shared library mechanism for linking with the Library.
> A suitable mechanism is one that (1) uses at run time a copy of the
> library already present on the user's computer system, rather than
> copying library functions into the executable, and (2) will
Jim Jewett wrote:
> It has now come to the point where a
> compiler should be assumed to miscompile GMP.
> ...
> It doesn't work on the Intel Macintoshes, and the workarounds are so
> ugly that they won't be applied to the trunk.
Sounds like it's been optimised for speed over portability
in a real
On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > a) Accompany the work with the complete corresponding machine-readable
> > source code for the Library
>
> But if it's like the regular GPL, you can just tell people
> where to get the source -- you don't have to physical
Martin v. Löwis wrote:
> a) Accompany the work with the complete corresponding machine-readable
> source code for the Library
But if it's like the regular GPL, you can just tell people
where to get the source -- you don't have to physically
provide it yourself.
--
Greg
___
On 9/9/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> > On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > > Speaking of PyLong, and its' minor awkwardness to work with in C (you
> > > > either have to convert to another multiple-preci
On 9/8/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Speaking of PyLong, and its' minor awkwardness to work with in C (you
> > > either have to convert to another multiple-precision type through a
> > > string, or use Python's arithme
> That sounds like a nice basic simple interface. I suggest writing it up
> and submitting it as a patch or even making it stand alone module with
> its own distutils setup.py. It sounds like a good idea regardless of it
> its accepted into the standard library. (clearly what we have now for
> What I'd like to see:
>
> I like the idea of having audio device support for the major operating
> systems in the standard library.
>
> But I am even more interested in a common interface for simple operations.
>
> IMO, the API should support:
>
> - stereo playback
> - stereo recording
> - differ
> Rather than resurrecting the old RSA-copyright md5.c I can easily make new
> ones out of the libtomcrypt md5 and sha1 sources the same way i created the
> non-openssl sha256 and sha512 modules.
>
> We should not limit ourselves to only md5 if we do that, lets guarantee
> that md5, sha1 - sha512 a
On 9/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > "d) If distribution of the work is made by offering access to copy
> > from a designated place, offer equivalent access to copy the above
> > specified materials from the same place."
>
> This is the same as "distribute the source code".
On Sep 9, 2007, at 10:10 AM, Nick Coghlan wrote:
> While I don't object to that (I agree keeping the history in the
> __future__ module is a good thing), 2to3 should probably strip them
> anyway, since they're now redundant.
That would be good. From a compatibility perspective, they should
>> You could use _PyLong_AsByteArray.
>
> I'm scared by the underscore.
If that helps, feel free to submit a patch to remove the underscore,
and document the function properly.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http:/
Dnia 09-09-2007, N o godzinie 15:24 +0200, "Martin v. Löwis" napisał(a):
> You could use _PyLong_AsByteArray.
I'm scared by the underscore.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_
Fred Drake wrote:
> On Sep 7, 2007, at 1:24 PM, Georg Brandl wrote:
>> Should the __future__ be cleaned out for 3k, or should all future
>> imports
>> continue to work and do nothing?
>
> They should continue to work.
>
> One advantage of keeping the existing feature table in the __future__
>
> I actually need to convert it to mpz_t, which is best done via text
> in a C string in a base which is a power of 2. Since PyUnicode_Format
> for Python3 int creates a byte string first, it's quite silly to let
> a byte string be converted to a Unicode string and then back.
You could use _PyLong
Since PyString_Format is deprecated, is there a better way to convert a
Python3 int which doesn't fit in a C long to a hex representation in a
C string, than PyUnicode_Format and iterating over characters, casting
them from Unicode to bytes?
I actually need to convert it to mpz_t, which is best do
Thomas Wouters wrote:
Because (relatively) small dicts with (broadly speaking) similar keys
are quite common in Python. Module and class and instance __dict__s,
for instance ;) As Tim mentioned, the dict implementation only looks
at part of the actual hash value (depending on the size of the di
> You're being awfully selective in your reading.
On purpose. All alternatives can be ruled out quickly as unfeasible,
or equivalent to "distribute the source code".
> 6a is but one of 5 choices.
So which of these would you recommend?
> "b) Use a suitable shared library mechanism for linking wi
On 9/9/07, Larry Hastings <[EMAIL PROTECTED]> wrote:
> One goal of Jenkin's hashes is uniform distribution, so these functions
> presumably lack the serendipitous "similar inputs hash to similar values"
> behavior of Python's current hash function. But why is that a feature?
> (Not that I doubt T
On 9/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > The LGPL has no requirement that you convey source for unmodified
> > libraries. Linkage does not imply modification.
>
> Why do you say that? LGPL 2.1, section 6a) (talking about
> "work that uses the Library"):
>
> a) Accompany the work
> The LGPL has no requirement that you convey source for unmodified
> libraries. Linkage does not imply modification.
Why do you say that? LGPL 2.1, section 6a) (talking about
"work that uses the Library"):
a) Accompany the work with the complete corresponding machine-readable
source code for th
28 matches
Mail list logo
