I am not at all a windows person but I have used
http://www.dennisbareis.com/makemsi.htm in the past to automate editing and
tweaking some MSI files for testing. It can also be used to generate new
ones. It looks like it would still require something to generate its own
input description. Regard
On Sun, Nov 23, 2008 at 3:16 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 22, 2008 at 11:51 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Nov 22, 2008 at 06:29, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> > -BEG
On Sat, Nov 22, 2008 at 11:51 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 22, 2008 at 06:29, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Nov 22, 2008, at 4:05 AM, Martin v. Löwis wrote:
> >
> >> I just noticed that the Pyth
On Sun, Sep 28, 2008 at 2:13 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> "broken" systems will always exist. Code to deal with them must be
>> possible to write in python 3.0.
>
> Python 3.0 will have bugs. This might just be one of them. I can agree
> that Python 3.x will need to support
On 9/27/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> I think that the problem is important because it's a regression from 2.5
>> to
>> 2.6/3.0. Python 2.5 uses bytes filename, so it was possible to
>> open/unlink "invalid" unicode strings (since it's not unicode but bytes).
>
> I'd like to s
On Tue, Sep 9, 2008 at 6:23 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> That seems risky to me. First, it's a new feature. Second, it will be
> largely untested code. I would much rather see dbm.sqlite released as a
> separate package for possible integration into the core for 3.1.
>
> - -Ba
ote:
> This needs to be fixed. It is surely a relic from the alpha1 situation
> where the bytes type was mutable. No read APIs should return mutable
> bytes. Write APIs should accept mutable and immutable bytes though.
>
> On Fri, Sep 5, 2008 at 12:17 AM, Gregory P. Smith <[EMAIL PROT
On Thu, Sep 4, 2008 at 8:39 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Jesus Cea wrote:
>>
>> I would rather revert to the method style, or redo the class to avoid
>> new attribute creation, maybe via some "thread.__setattr__()" magic.
>
> Or maybe with __slots__ in the threading class. It'd
to fix it.
-gps
On Wed, Sep 3, 2008 at 10:42 PM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> On Thu, Sep 4, 2008 at 10:47 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>> I agree that this should go in. zlib should return bytes. other read
>> functions and s
I agree that this should go in. zlib should return bytes. other read
functions and similar modules like bz2module already return bytes.
unless i hear objections, i'll commit this in about 12 hours.
On Wed, Aug 20, 2008 at 12:20 AM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>
On Wed, Sep 3, 2008 at 8:36 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Skip> Remind me why we want to get rid of bsddb?
>>
>> Benjamin> The reasons are enumerated in PEP 3108.
>>
>> Not much justification and no references to outside discussion for such a
>> heavily used package which
http://bugs.python.org/issue3618 is a release blocker due to deadlock
in the io library.
and the related C RLock implementation in
http://bugs.python.org/issue3001 at this point in the release process.
Its obviously missed beta3 which is why I suggested in 3001 that it
was too late. That was bef
On Sat, Jul 19, 2008 at 1:00 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
>
> Anybody is able to compile current bsddb in 3.0 svn?. May I overwrite
> current version with my own one, updated with your patches (except the
> buffer code; I rather prefer to delay that)?.
>
Yes, feel free to replace it w
On Tue, Jul 1, 2008 at 8:29 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Jul 1, 2008, at 10:42 PM, Benjamin Peterson wrote:
>
>> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>
>>> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>>>
Is a Google Calendar kep
On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-06-09 07:20, Gregory P. Smith wrote:
>
>> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>
>> On 2008-06-03 01:29, Gregory P. Smith wrote:
>>&g
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-06-03 01:29, Gregory P. Smith wrote:
>
>> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>
>> I will freely admit that I haven't fo
On Wed, Jun 4, 2008 at 7:32 PM, Andrew MacIntyre <
[EMAIL PROTECTED]> wrote:
> There are 2 disparate approaches to clearing/compacting free lists for
> basic types:
> - APIs of the form Py_ClearFreeList() called from gc.collect()
> [class, frame, method, tuple & unicode types];
> - APIs of the fo
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I will freely admit that I haven't followed this thread in any detail,
> but if it were up to me, I'd have the 2.6 internal code use PyString
...
Should we read this as a BDFL pronouncement and make it so?
All that wo
On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>> Okay, how about this? http://codereview.appspot.com/1521
>>
>> Using that patch, both PyString_ and PyBytes_ APIs are available using
>> function stubs similar to the above. I opted to define the stub
>> functions righ
On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-30 00:57, Nick Coghlan wrote:
>>
>> M.-A. Lemburg wrote:
>>>
>>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
>>> with one redirecting to the other ?
>>
>> We do have that - the PyString_* name
On Thu, May 29, 2008 at 3:57 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>> to restructure itself ?
>
> With the better explanation from Greg of what the checked in approach
> achieves (i.e. preserving ex
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
>
> How can it be that we allow major C API chang
Agreed. Otherwise the common ascii based network protocol task of reading
some bytes in and converting them to the integer that they represent in
ascii would require an additional unicode decoding step.
On Tue, Apr 15, 2008 at 7:18 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Yeah, practica
-cc: python-dev
+cc: python-3000
Hi Haoyu,
I'm glad someone wanting to work on updating swig for python 3.x. A better
mailing list for python 3.x internals questions as you work on this is the
python-3000@python.org list.
The first place I suggest looking when you have a question is in the Pyth
On Wed, Apr 9, 2008 at 4:10 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Christian wrote:
> > > Make file objects as thread safe as the underlying libc FILE*
> implementation.
> > > close() will now raise an IOError if any operations on the file object
> > > are currently in progress in other
yes bytearray makes more sense to me given that its hard to read into an
immutable bytes object ;)
On Sun, Apr 6, 2008 at 6:46 AM, Benjamin Peterson <
[EMAIL PROTECTED]> wrote:
> While working on the io module docs, I noticed the annotation for readinto
> methods is bytes. This should be bytearra
t much better. I'd
> rather expect this in the vicinity of md5 and sha... Is it possible to
> tweak that C code to use the zlib version if present and the old C
> code otherwise?
>
> On Tue, Mar 18, 2008 at 3:21 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > Both modu
On 3/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes schrieb:
>
> > In Python 3.0 the unit test for zlib is broken because in 3.0
> > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed
> int.
> >
> > How should the issue be solved? I think the unsigned l
Both modules have a crc32 function. The zlib version is faster when zlib
has been compiled optimally or about the same when zlib is old or uses its C
code.
Should we ditch the binascii.crc32 version in py3k?
64bit Linux (CentOS 5.1):
$ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import bin
On 3/16/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > On Sun, Mar 16, 2008 at 4:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
>
> >> People would try the process on their development machines, and change
> >> the code until it actually runs under both version
On 3/16/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I don't see a lot of objections left against using the bug tracker. I
> just talked to Neal and he's going to transfer all tasks from the 2.6
> spreadsheet to the bug tracker.
>
> I'll also be adding various other tasks., as I think of the
On 3/16/08, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Moving this to a new subject to keep the discussion of tasks and the
> > discussion of task tracking tools separate.
> >
> > On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> >> I
bytes objects are by their definition immutable and read only. but when
passing one to a buffer api that tries to use the PyBUF_LOCK flag it raises
BufferError "Cannot lock this object." from PyBuffer_FillInfo in
Objects/abstract.c as called by Objects/bytesobject.c's bytes_getbuffer
method.
I th
yep we've already been through that problem in the past when list
comprehensions, generators and with were added to name a few. since python
3 code is highly unlikely to even parse with a 2.x interpreter much of the
time thats a reason to consider a .py3 extension if this precedent of not
caring i
On 1/10/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Jan 10, 2008 4:52 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> > I'm very dependent of bsddb support in python. I'm very sorry also of
> > the maintainer support of it: he is slow and doesn't implement python
> > bindings for berkeleydb f
it doesn't. read the patch. it adds a __reversed__ method.
http://bugs.python.org/file8902/reverse-file-iterator-20071209.diff
On 12/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Mark Russell wrote:
> > I posted a patch (http://bugs.python.org/issue1677872) a while ago to
> > add support for
heh ag
On 12/7/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Gregory P. Smith wrote:
> > look at the length of a
> > hex pointer in the repr of a class for C pointer size.
>
> I don't think that will work, because the repr only uses
> as many hex dig
On 12/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > It's only used for sys.maxint. Do we still need sys.maxint and
> > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > > better names.
> >
>
On 11/21/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > I would not hold up a compiler decision based on the mingw project. Always
> > use the latest MS compiler released at the time for a x.0 build of any
> > python. Doing otherwise c
On 11/20/07, Paul Moore <[EMAIL PROTECTED]> wrote:
>
> On 20/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> > PPS I *will* see what the current status of msvcr8/9 support in the
> > Mingw project is, but I'm not too hopeful - mingw is currently
> > undergoing a change of maintainers and progress
On 11/15/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > Now, is it really necessary to install perl in order to compile python?
>
> Yes, if you want OpenSSL support.
Yep. Sadly OpenSSL uses Perl to generate its asm files in one of two or
three different x86 asm syntaxes. Why is this sad
and there was much rejoicing!
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Too late. It's already gone. ;-)
>
> On 11/2/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > +1 on removing implicit str calls from join altogether.
> >
> > +1 from me, too.
> >
> > Bill
> >
>
>
> --
> --Gu
On 11/1/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
>
> > I could leave this all up to the 3.0 application, which would have to
> > "fix up" any bytes in the pickle it receives explicitly if it wants
> > to. Alternatively, I could add an encod
-1 on having "".join() call str at all. yuck. shouldn't the caller just
write:
"".join((str(x) for x in thing))
when they desire guaranteed stringification instead of a TypeError?
Anyways others disagree and this was already implemented so I assume my -1
is rejected, I at least agree on this:
And for non-unicode inputs the code should use the PEP 3118 buffer API
rather than PyBytes_ or PyString_ or whatnot.
On 10/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> 2007/10/26, Bill Janssen <[EMAIL PROTECTED]>:
> > I'm looking at the Py3K SSL code, and have a question:
> >
> > What's
On 10/8/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
>
> - add missing methods to PyBytes (for list, see the PEP and compare to
> > what's already there)
>
>
Committed revision 58493. (closes issue1261).
fwiw - On py3k head on the x86 ubuntu feisty box i use
> Anyways I'll be done with my patch to add the copying versions of the
> methods later today. Stay tuned.
>
The PyBytes methods from PEP3137 have been implemented. Review as desired.
http://bugs.python.org/issue1261
If its good as is, let me know and I can check that in if you don't want to
while trying to figure out what to update the common method docstrings to
say I've come up with terms such as 'byte string' or 'byte buffer' but none
of those are extra appealing to me to turn into an ABC name. other
thoughts?
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/15/
On 10/15/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | > > > As I work on these.. Should the mutable PyBytes_ (buffer) objects
> implement
> | > > > the following methods inplace and return an additional refere
> > >> Also what about .replace() and .translate()?
> > >
> > >> If they are not done in place should they return a new buffer
> (PyBytes_)
> > >> object or a bytes (PyString_) object? [i'd say a buffer (PyBytes_)]
> > >
> > > They should return the same type as 'self'.
> >
> > My preference would
> - add missing methods to PyBytes (for list, see the PEP and compare to
> > what's already there)
> >
>
As I work on these.. Should the mutable PyBytes_ (buffer) objects implement
the following methods inplace and return an additional reference to self?
.capitalize(), .center(), .expandtabs(), .
On 10/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > Um, where does the filename object in that expression come from? It
> > > appears to be a PyString object. Who created it? That could should be
> >
On 10/11/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> Guido -
>
> One tiny question has come up while working on this one:
>
> Should the PyBytes buffer (mutable bytes) object's .append(val) and
> .remove(val) methods accept anything other than an int in the
.append('33') will happily
append a b'!' by converting it into an int then into a byte. regardless of
the answer that misbehavior will be zapped in the patch i'm about to submit.
;)
-gps
On 10/8/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
>
> - add
> On 10/10/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > > - remove buffer API from PyUnicode
> > >
> > > I'll take these two with a goal of having them done by the end of the
> > week.
> > >
> >
> > I should've known
>
> > - remove buffer API from PyUnicode
>
>
> I'll take these two with a goal of having them done by the end of the
> week.
>
> -gps
>
I should've known not to believe the simple description. This one is
proving difficult by itself. If I modify the Unicode object to not support
the buffer API I
> - add missing methods to PyBytes (for list, see the PEP and compare to
> what's already there)
> - remove buffer API from PyUnicode
I'll take these two with a goal of having them done by the end of the week.
-gps
___
Python-3000 mailing list
Python-3
+10 from me
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
On 9/29/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
>
> On 9/29/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 07:33 AM 9/29/2007 -0700, Guido van Rossum wrote:
> > >Until just before 3.0a1, they were unequal. We decided to raise
> > >TypeError because we noticed many bugs in code that was
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [PEP 3137]
> > > **Open Issue:** I'm undecided on whether indexing bytes and buffer
> > > objects should return small ints (like the bytes type in 3.0a1, and
> > > like lists or array.array('B')), or bytes/buffer objects of length 1
> > > (l
On 9/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > However there's quite a bit of Python 2.x code around that manipulates
> > *bytes* in the guise of 8-bit strings, and it uses tests like "if s[0]
> > == 'x': ..." frequently. This can of course be rewritten using a
>
On 9/16/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 16/09/2007, Fred Drake <[EMAIL PROTECTED]> wrote:
> > On Sep 15, 2007, at 10:00 PM, Nicholas Bastin wrote:
> > > Then lets stop beating around the bush and implement an immutable
> > > bytes type. Why put ourselves through contortions trying t
On 9/15/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 15/09/2007, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > similarly for the environment. os.environ dict
> > should be bytes object keys and values
>
> You can't have bytes as keys - the type isn't
On 9/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Hagen Fürstenau wrote:
> > sys.argv could be of type bytes and sys.arguments (or whatever) could be
> > a function taking an encoding parameter (which defaults to UTF-8) and
> > returning strings.
> >
> > Of course that's backwards incompatible an
On 9/13/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> I think if it doesn't go through the buffer interface it is up to the
> object to decide (i.e. what does the object do with itself when buffers
> are exported --- that will depend on the object). All it must do is
> support the buffer in
On 9/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > When I read the plain term EXCLUSIVE I read that to mean nobody else can
> > read -or- write, ie: not shared in any sense.
>
> You're right, it's not the best term.
>
&g
On 9/11/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> 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.
> 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
> 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
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
> > >
On 9/10/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 9/10/07, gregory.p.smith <[EMAIL PROTECTED] > wrote:
> >
> > Author: gregory.p.smith
> > Date: Mon Sep 10 01:55:55 2007
> > New Revision: 58068
> >
> > Modified:
> >python/branches/py3k/Doc/library/exceptions.rst
> >python/branc
> 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
s in the 3.0a1 release, we
> should pair-program on it ASAP, preferable tomorrow morning.
> Otherwise, let's do a review next week.
>
> --Guido
>
> On 8/29/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > Attached is what I've come up with so far. Only a
On 9/4/07, Thomas Hunger <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> I don't know much about python internals, so the following might be
> bogus:
>
> I replaced unicode_hash and string_hash with the hash function from
> here: http://www.azillionmonkeys.com/qed/hash.html.
>
> Then I ran the followin
On 9/6/07, Ivan Krstić <[EMAIL PROTECTED]> wrote:
>
> On Sep 6, 2007, at 4:09 AM, Martin v. Löwis wrote:
> > There are more issues, of course: some countries restrict the use
> > of cryptography. France is given as an example: you need to register
> > your cryptography keys with the government (SCS
>
> Also, the NIST SHA-1/256/384/512 code is freely available, there's
> also no reason to rely on OpenSSL for it (although it looks like the
> PKI reference implementation links that I can find are dead, so we
> might have to hunt a little bit).
>
> In either case, we could probably copy the relev
> Yes, this is a serious issue -- we are totally dependent on openssl
> for computing MD5 checksums. Several modules use MD5 checksums
> casually, and it's not good that these fail when openssl isn't
> available (or if it's too old, like what happened on an ancient Red
> Hat 7.3 system I have at ho
On 9/4/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> According to PEP 358, "bytes" will be in both 2.6 and 3.0. It would
> be nice if the C API for "bytes" existed in the trunk, so that it
> could be used for new code that will port more easily to 3.0.
>
> Bill
I assume this includes the new b
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > (assuming d[x] is O(log n))
>
> In Python, d[x] is typically considered to be O(1) (unlike in C++,
> where it is O(log n)). Of course, with Python using a hashtable,
> performance may decrease in the presence of collisions. In the
> nor
e're *reading* and I don't
> think the GIL is even released while we're reading such things.
>
> If you think it's important to get this in the 3.0a1 release, we
> should pair-program on it ASAP, preferable tomorrow morning.
> Otherwise, let's do a review next w
Attached is what I've come up with so far. Only a single field is
added to the PyBytesObject struct. This adds support to the bytes
object for PyBUF_LOCKDATA buffer API operation. bytes objects can be
marked temporarily read-only for use while the buffer api has handed
them off to something whic
> Adding data locking shouldn't be too complicated, but is it necessary?
> The bytes object does support locking the buffer in place; isn't that
> enough? It means someone evil could still produce a phase error by
> changing the contents while you're looking at it (basically sabotaging
> their own
+1 from me, i don't see a reason for bytes(s, e) to exist when
s.encode(e) does the same job and is more symmetric.
On 8/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm still working on stricter enforcement of the "don't mix str and
> bytes" rule. I'm finding a lot of trivial problems, wh
On Fri, Aug 24, 2007 at 09:58:24AM -0700, Gregory P. Smith wrote:
> On Thu, Aug 23, 2007 at 09:17:04PM -0700, Guido van Rossum wrote:
> > On 8/23/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Gregory P. Smith wrote:
> > > > Wasn't a past mailing list th
On 8/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Gregory P. Smith wrote:
> > I'm in favor of not allowing unicode for hash functions. Depending on
> > the system default encoding for a hash will not be portable.
> >
> > another question for hash
w about encodings of the data
being received.
-gps
On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Change r57490 by Gregory P Smith broke a test in test_unicodedata and,
> on PPC OSX, several tests in test_hashlib.
>
> Looking into this it's pretty clear *why* it
ss their
> length, and I've never seen a string with a negative length either.
> :-)
>
> I could even see code computing the difference between two dimensions
> and checking if it is negative; don't some compilers actively work
> against making such code work correctly?
>
Anyone mind if I do this?
--- Include/object.h(revision 57412)
+++ Include/object.h(working copy)
@@ -148,7 +148,7 @@
Py_ssize_t itemsize; /* This is Py_ssize_t so it can be
pointed to by strides in simple case.*/
int readonly;
-
On 8/25/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > FWIW, I'm very much against moving email out of the core. This has
> > been discussed a number of times before, and as far as I am aware, no
> > conclusion reached. However, the "batteries included" approach of
> > Python is a huge benefit for
On Sat, Aug 25, 2007 at 03:00:15PM -0700, Brett Cannon wrote:
> On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > Alternately, we could move toward separate libraries for such
> > components; this allows separate packages to have separate
> > maintenance cycles, and makes it easier for applicat
On Fri, Aug 24, 2007 at 08:30:48PM -0700, Neal Norwitz wrote:
> On 8/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Guido> Are there any existing uses (in the core) that are hard to
> > > Guido> replace with PyArg_
On Thu, Aug 23, 2007 at 09:17:04PM -0700, Guido van Rossum wrote:
> On 8/23/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Gregory P. Smith wrote:
> > > Wasn't a past mailing list thread claiming the bytes type was supposed
> > > to be great for IO? How'
On Thu, Aug 23, 2007 at 09:18:59PM +0200, "Martin v. L?wis" wrote:
> > I -detest- the idea of making another temporary copy of the data just
> > to allow the GIL to be released during IO. data copies == bad.
> > Wasn't a past mailing list thread claiming the bytes type was supposed
> > to be great
On Thu, Aug 23, 2007 at 09:49:19AM +0200, "Martin v. L?wis" wrote:
> > Yeah you did the keys (good!). I just checked in a change to require
> > values to also by bytes. Maybe that goes so far as to be inconvenient?
>
> Ah, ok. I think it is fine. We still need to discuss what the best
> way is t
On Thu, Aug 23, 2007 at 07:58:33AM +0200, "Martin v. L?wis" wrote:
> > IMHO all of that is desirable in many situations but it is not strict.
> > bytes:bytes or int:bytes (depending on the database type) are
> > fundamentally all the C berkeleydb library knows. Attaching meaning
> > to the keys an
On Wed, Aug 22, 2007 at 11:12:32PM -0700, Gregory P. Smith wrote:
> Is there anything similar to chr(65) for creating a single byte string
> that doesn't involve creating an intermediate string or tuple object?
>
> bytes(chr(65))
> bytes((65,))
>
> both seem slight
Is there anything similar to chr(65) for creating a single byte string
that doesn't involve creating an intermediate string or tuple object?
bytes(chr(65))
bytes((65,))
both seem slightly weird.
Greg
___
Python-3000 mailing list
Python-3000@python.o
> > There are currently about 7 failing unit tests left:
> >
> > test_bsddb
> > test_bsddb3
...
fyi these two pass for me on the current py3k branch on ubuntu linux
and mac os x 10.4.9.
-greg
___
Python-3000 mailing list
Python-3000@python.org
http://m
On Tue, Aug 07, 2007 at 06:53:32AM +0200, "Martin v. L?wis" wrote:
> > I guess we have to rethink our use of these databases somewhat.
>
> Ok. In the interest of progress, I'll be looking at coming up with
> some fixes for the code base right now; as we agree that the
> underlying semantics is byt
100 matches
Mail list logo
