Re: [Python-3000] C API for ints and strings

> 3.0: 10 loops, best of 3: 6.76 sec per loop > 2.6: 10 loops, best of 3: 2.61 sec per loop I can't quite reproduce these results. On a 3.2GHz Pentium 4, running Linux 2.6.21, gcc 4.1.3, I get 3.0: 10 loops, best of 3: 728 msec per loop 2.6: 10 loops, best of 3: 558 msec per loop So it's only 30

Re: [Python-3000] 3.0 crypto

On Sep 7, 2007, at 2:48 PM, Gregory P. Smith wrote: > fwiw hashes are not cryptography. I assume you mean legally? I was referring to the fact that we're specifically discussing cryptographic hashes. > I see nothing wrong with leaving pycrypto as an add-on library as > most things don't need

Re: [Python-3000] 3.0 crypto (was: Re: Solaris support in 3.0?)

On Sep 6, 2007, at 10:54 AM, Guido van Rossum wrote: > I'm not sure what you meant with "doing the work isn't a problem". Are > you volunteering? I think we need someone who understands the red tape > situation most of all. Hopefully I'm worried for nothing. I'm trying to feel out whether there's

Re: [Python-3000] C API for ints and strings

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > If python.org agreed to host the GMP source, that would suffice for > > all people distributing python binaries (they could then just refer to > > the GMP source download as a link). > > It would not if they don't distribute the binary th

Re: [Python-3000] C API for ints and strings

On 9/11/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > I guess anything is debatable, but the LGPL explicitly defines programs > statically-linked with LGPL code as being "derivative works": Where exactly does it do that? The GPL does that, but not the LGPL. In fact, the LGPL does not define no

Re: [Python-3000] C API for ints and strings

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > I can't quite reproduce these results. On a 3.2GHz Pentium 4, > running Linux 2.6.21, gcc 4.1.3, I get > > 3.0: 10 loops, best of 3: 728 msec

Re: [Python-3000] C API for ints and strings

> In the GPL FAQ (). Specifically: > > Can I put the binaries on my Internet server and put the source on a > different Internet site? Ok. As you say, this applies to downloading only. > Of course, as several people have now pointed out, non-internet >

Re: [Python-3000] C API for ints and strings

On 11/09/2007, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > > > I can't quite reproduce these results. On a 3.2GHz Pentium 4, > > running

Re: [Python-3000] __format__ and datetime

Eric Smith wrote: > I have a patch to add __format__ to datetime.time, .date, and .datetime. > For non-empty format_spec's, I just pass on to .strftime. For empty > format_spec's, it returns str(self). What's the best way to call str(self)? I'm currently doing: if (PyUnicode_GetSize(for

Re: [Python-3000] __format__ and datetime

Eric Smith wrote: > Eric Smith wrote: >> I have a patch to add __format__ to datetime.time, .date, and .datetime. >> For non-empty format_spec's, I just pass on to .strftime. For empty >> format_spec's, it returns str(self). > > What's the best way to call str(self)? > > I'm currently doing:

Re: [Python-3000] C API for ints and strings

Martin v. Löwis wrote: > I personally never said what I think of the LGPL. I was merely trying > to explain what it actually says. FWIW, I quite like both the GPL, and > the LGPL, and applaud the motivations behind it. That's why I prefer > to follow it faithfully, and in its spirit, rather than tr

[Python-3000] ordered dict for p3k collections?

Hi, Is there any chance that an ordered dict will be added to Python 3's library? I personally find such data structures v. useful in C++. I know that in Python the sort function is v. fast, but often I prefer never to sort but simply to use an ordered data structure in the first place. (I'm awar

Re: [Python-3000] __format__ and datetime

Nick Coghlan wrote: > Eric Smith wrote: >> Eric Smith wrote: >>> I have a patch to add __format__ to datetime.time, .date, and >>> .datetime. For non-empty format_spec's, I just pass on to >>> .strftime. For empty format_spec's, it returns str(self). >> >> What's the best way to call str(self)

Re: [Python-3000] __format__ and datetime

Skip> I would like to see an analog to %S which preserves fractions of a Skip> second as the default formatting for time and datetime objects Skip> does: Skip> >>> print(now) Skip> 2007-09-10 22:07:53.654774 Guido> Right. It's odd that there's nothing explicit that exactl

[Python-3000] help(pickle) fails: unorderable types: type() < type()

Python 3.0a1 (py3k, Sep 8 2007, 15:57:56) [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> help(pickle) Traceback (most recent call last): [...] File "/usr/local/lib/python3.0/pydoc.py", line 954, i

Re: [Python-3000] 3.0 crypto (was: Re: Solaris support in 3.0?)

> I'm trying to feel out whether there's strong opposition to shipping =20 > a good set of built-in crypto operations with Python, and in a way =20 > that doesn't depend on external libraries. Could you say a bit more about what these "built-in crypto operations" would be? What's the scope of you

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > ... I'm hoping Travis has a particular way in mind of > > handling LOCKDATA that can be used as a template. > The use case I had in mind comes about quite often in NumPy when you > want to modify the data-area

Re: [Python-3000] C API for ints and strings

On 9/11/07, Paul Moore <[EMAIL PROTECTED]> wrote: > On 11/09/2007, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > > > > > I can't quit

[Python-3000] Which joker tried to remove me from the py3k list?

-- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Sep 11, 2007 9:58 AM Subject: Your confirmation is required to leave the Python-3000 mailing list To: [EMAIL PROTECTED] Mailing list removal confirmation notice for mailing list Python-3000 We have received

Re: [Python-3000] __format__ and datetime

On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Skip> I would like to see an analog to %S which preserves fractions of a > Skip> second as the default formatting for time and datetime objects > Skip> does: > > Skip> >>> print(now) > Skip> 2007-09-10 22:07:53.654774

Re: [Python-3000] help(pickle) fails: unorderable types: type() < type()

On 9/11/07, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Python 3.0a1 (py3k, Sep 8 2007, 15:57:56) > [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import pickle > >>> help(pickle) > Traceback (most rece

Re: [Python-3000] 3.0 crypto (was: Re: Solaris support in 3.0?)

On 9/11/07, Ivan Krstić <[EMAIL PROTECTED]> wrote: > On Sep 6, 2007, at 10:54 AM, Guido van Rossum wrote: > > I'm not sure what you meant with "doing the work isn't a problem". Are > > you volunteering? I think we need someone who understands the red tape > > situation most of all. Hopefully I'm wo

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I'd like to see Travis's response to this. It's setting a precedent > > regarding locking objects in read-only mode; I haven't found other > > examples of objects using LOCKDATA (the only mentions of it seem to

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Guido van Rossum wrote: > On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > >> > > Hm, so this is completely different from what I thought. It seems you > are describing the following: > > 1. acquire the buffer with LOCK_DATA > 2. copy the data out of the buffer into a scratch area > 3

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Jim Jewett wrote: > On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: >> >>> ... I'm hoping Travis has a particular way in mind of >>> handling LOCKDATA that can be used as a template. >>> > > > Does it do its processing in the original buffer,

Re: [Python-3000] Which joker tried to remove me from the py3k list?

Hello, Guido van Rossum wrote: > -- Forwarded message -- > From: [EMAIL PROTECTED] > <[EMAIL PROTECTED]> > Date: Sep 11, 2007 9:58 AM > Subject: Your confirmation is required to leave the Python-3000 mailing list > To: [EMAIL PROTECTED] > > > Mailing list removal confirmation notic

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

On 9/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 9/10/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > I'd like to see Travis's response to this. It's setting a precedent > > > regarding locking objects in read-only mode; I haven't found other > > >

Re: [Python-3000] 3.0 crypto

> Last I heard, AMK was no longer maintaining pycrypto, and a number of > people have found weird issues with it and were generally uncertain > of the correctness of the implemented crypto. > > > The pycrypto API is is very nice. But if we were to consider it > > for the standard library I'd prefe

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

On 9/11/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > I'm not sure I understand the difference between a classic read lock and > the exclusive write lock concept. Does the classic read-lock just > prevent writing to the memory area. In my mind that is a read-only > memory buffer and the bu

Re: [Python-3000] C API for ints and strings

Nick Coghlan wrote: > The LGPL and GPL have different aims from the PSF license, with a much > greater focus on preserving freedom for the end-user, Seems to me they go somewhat beyond "preserving freedoms" and into other areas. It's one thing to *allow* people to use the source if they can get i

Re: [Python-3000] __format__ and datetime

Guido van Rossum wrote: > I don't expect there to be a practical use for nanoseconds (even > microseconds are doubtful, but useful since one might want unique > timestamps for more than 1000 events per second). But... what if you want unique timestamps for more than 100 events per second? :-)

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Guido van Rossum wrote: > 0 -> 1 -> 2 -> ... (SIMPLE or WRITABLE get) > ... -> 2 -> 1 -> ... (SIMPLE or WRITABLE release) > 0 -> -1 (LOCKDATA get) > -1 -> 0 (LOCKDATA release) And if this is the correct interpretation, the requests should be called something like READ_LOCK and WRITE_LOCK to make

Re: [Python-3000] __format__ and datetime

On 9/11/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't expect there to be a practical use for nanoseconds (even > > microseconds are doubtful, but useful since one might want unique > > timestamps for more than 1000 events per second). > > But... what if you want un

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Travis E. Oliphant wrote: > I'm not sure I understand the difference between a classic read lock and > the exclusive write lock concept. A read lock means that others can obtain read locks, and nobody can obtain a write lock. A write lock means that nobody else can obtain a lock of any kind. I

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Jim Jewett wrote: > > why does it need the lock the whole time? > Is someone getting known stale data (when you could tell them to > wait) always OK, but overwriting someone else's change never is? In a threaded environment, it shouldn't really be a problem as long as the view of the data is cons

Re: [Python-3000] Which joker tried to remove me from the py3k list?

Amaury Forgeot d'Arc wrote: > Of course, this means that someone followed the link, then clicked the > "unsubscribe" button. A robot? It could just be someone trying to unsubscribe themselves, but hitting the wrong link and not noticing. -- Greg ___ Pyt

Re: [Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

Guido van Rossum wrote: > Any number of concurrent SIMPLE accesses can > coexist since the clients promise they will only read. As a general principle, using a word like SIMPLE in an API is a really bad idea imo, as it's far too vague. I'm finding it impossible to evaluate the truthfulness of stat

Re: [Python-3000] C API for ints and strings

> The Pentium M and Pentium D are much more alike, architecturally, than > either and the Pentium 4, [cpu rant] Off topic: not true. The Pentium D is the final Pentium 4 netburst architecture based design. It is not at all close to the Pentium M. The M is much more a derivative of the pentium

Re: [Python-3000] C API for ints and strings

On 9/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > [cpu rant] > Off topic: not true. The Pentium D is the final Pentium 4 netburst > architecture based design. It is not at all close to the Pentium M. The M > is much more a derivative of the pentium pro,ii,iii, & iii-m before it as > cor