Martin v. Löwis wrote:
>> You mean if it were fixed it could fail, right? Code calling it should
>> be checking for errors anyway because it allocates memory.
>>
>> Have you tried making this particular change and seeing what fails?
>
> I now tried, and it turned out that bytes.__reduce__ would b
Greg Ewing wrote:
> Ron Adam wrote:
>> It's *not* a default. The default is to have no max_width.
>
> You're suggesting it would be a default if you
> *did* specify a max width but no replacement
> char. That's what I'm saying would be a bad
> default.
Absolutely, *for_field_widths* which is s
>> I now tried, and it turned out that bytes.__reduce__ would break
>> (again); I fixed it and changed it in r56755.
>>
>> It turned out that PyUnicode_FromString was even documented to
>> accept latin-1.
>
> Yes, that seemed to me to be the most obvious interpretion.
Unfortunately, this made cre
Greg Ewing wrote:
> Ron Adam wrote:
>> If the string __format__ method got 'k10' as a format specifier, it has
>> no idea what the 'k10' is suppose to mean, it needs to make a choice to
>> either fall back to str(), or raise an exception that could be caught
>> and handled.
>
> I think Guido'
Martin v. Löwis wrote:
>>> I now tried, and it turned out that bytes.__reduce__ would break
>>> (again); I fixed it and changed it in r56755.
>>>
>>> It turned out that PyUnicode_FromString was even documented to
>>> accept latin-1.
>> Yes, that seemed to me to be the most obvious interpretion.
>
Talin wrote:
> Of course, the two can't be entirely isolated because there is
> interaction between the two specifiers for some types. For example, it
> would normally be the case that padding is applied by 'apply_format',
> which knows about the field width and the padding character. However, i
Talin wrote:
> Greg Ewing wrote:
>> Talin wrote:
>>> in
>>> the case of an integer that is printed with leading zeros, the sign must
>>> come *before* the padding: '+00010'. It's not sufficient to simply
>>> apply padding blindly to the output of __format__, which would give you
>>> '00
[EMAIL PROTECTED] wrote:
> skip> Yes, but an int is both much smaller than a function and can't be
> skip> involved in cyclic garbage.
>
> I also forgot to mention that inexperienced users will probably find it
> easier to hang onto an int than create a closure
a) functools.partial isn't
Martin v. Löwis wrote:
> I don't think it needs to be a separate type,
> instead, bytes objects could have a idem-potent
> .freeze() method which switches the "immutable"
> bit on. There would be no way to switch it off
> again.
+1 here - hashable byte sequences are very handy for dealing with
fr
On Thu, 02 Aug 2007 21:43:14 +0200, Martin v. Löwis wrote:
>> The patch is based on the latest trunk/ checkout, Python 2.6. I don't
>> think this is a problem if nobody else made any effort towards making
>> xrange more sequence-like in the Python 3000 branch. The C source might
>> require some ta
Nick> a) functools.partial isn't that hard to use
Never heard of it and I've been writing Python since the mid-90's. The
point is that not everybody dreams in a functional programming style.
Nick> b) we could create it automatically in atexit.register and return
Nick>it
That's
On 4 Aug 2007, at 06:11, Kurt B. Kaiser wrote:
> Although there has been quite a bit of discussion on dropping reduce()
> and retaining map(), filter(), and zip(), there has been less
> discussion
> (at least that I can find) on changing them to return iterators
> instead
> of lists.
>
> I thi
This is a fairly specific question, but it gets at a more general
issue I don't fully understand.
I recently updated httplib and urllib so that they work on the struni
branch. A recurring problem with these libraries is that they call
methods like strip() and split(). On a string object, calling
On 8/6/07, Nicko van Someren <[EMAIL PROTECTED]> wrote:
> On 4 Aug 2007, at 06:11, Kurt B. Kaiser wrote:
> > There are a number of instances where map() is called for its side
> > effect, e.g.
> >
> > map(print, line_sequence)
> >
> > with the return result ignored. In py3k this has caused
Do you guys need more guidance on this? It seems Martin's checkin
didn't make things worse in the tests deparment -- I find (on Ubuntu)
that test_ctypes is now failing, but test_threaded_import started
passing.
One issue with just putting this in the C API docs is that I believe
(tell me if I'm wr
On 8/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> This brings me to join others in the desire for
> immutable bytes objects: I think such a type is
> needed, and it should probably use the same
> hash algorithm as str8.
>
> I don't think it needs to be a separate type,
> instead, bytes obje
On 8/3/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> Although there has been quite a bit of discussion on dropping reduce()
> and retaining map(), filter(), and zip(), there has been less discussion
> (at least that I can find) on changing them to return iterators instead
> of lists.
That's prob
On 6 Aug 2007, at 16:22, Steven Bethard wrote:
> On 8/6/07, Nicko van Someren <[EMAIL PROTECTED]> wrote:
...
>> Filter returning an iterator is going to break lots of code which
>> says things like:
>> interesting_things = filter(predicate, things)
>> ...
>> if foo in inter
On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/3/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> > If the statistics on the usage of map() stay the same, 2/3 of the time
> > the current implementation will require code like
> >
> > foo = list(map(fcn, bar)).
>
> And the 2to
On 8/6/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> This is a fairly specific question, but it gets at a more general
> issue I don't fully understand.
>
> I recently updated httplib and urllib so that they work on the struni
> branch. A recurring problem with these libraries is that they call
>
On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Do you guys need more guidance on this? It seems Martin's checkin
> didn't make things worse in the tests deparment -- I find (on Ubuntu)
> that test_ctypes is now failing, but test_threaded_import started
> passing.
The test_threaded_import
On 8/6/07, Kevin Jacobs <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
> I hate to be pedantic, but it is not possible for 2to3 to tell, in general,
> that it is safe to elide the list() because the result is used directly in a
> for loop (for the usual arguments that use the Halting Problem as a t
I thought rfc822 was going away. From the current module documentation:
Deprecated since release 2.3. The email package should be used in
preference to the rfc822 module. This module is present only to maintain
backward compatibility.
Shouldn't rfc822 be gone altogether in Python 3?
>> Unfortunately, this made creating and retrieving asymmetric:
>> when you do PyUnicode_AsString, you'll get an UTF-8 string; when
>> you do PyUnicode_FromString, you did have to pass Latin-1. Making
>> AsString also return Latin-1 would, of course, restrict the number of
>> cases where it works.
> One issue with just putting this in the C API docs is that I believe
> (tell me if I'm wrong) that these haven't been kept up to date in the
> struni branch so we'll need to make a lot more changes than just this
> one...
That's certainly the case. However, if we end up deleting the str8
type en
>> If that is not acceptable, please tell me how else
>> to fix the dbm modules.
>
> By fixing the code that uses them?
I don't know how to do that. All implementation strategies I
can think of have significant drawbacks.
> By using str8 (perhaps renamed to
> frozenbytes and certainly stripped o
On Aug 6, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote:
> I thought rfc822 was going away. From the current module
> documentation:
> ...
> Shouldn't rfc822 be gone altogether in Python 3?
Yes. And the answers to Jeremy's questions about what sort of IO is
appropriate for the email package shou
Hi all,
I recently asked about the UCS2 / UCS4 binary compatibility issues
with Python on Guido's blog, and Guido suggested I continue the
discussion here:
http://www.artima.com/forums/flat.jsp?forum=106&thread=211430
The issue is that Python has a compile-time configuration setting
which change
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> If that is not acceptable, please tell me how else
> >> to fix the dbm modules.
> >
> > By fixing the code that uses them?
>
> I don't know how to do that. All implementation strategies I
> can think of have significant drawbacks.
Can yo
>> I don't know how to do that. All implementation strategies I
>> can think of have significant drawbacks.
>
> Can you elaborate about the issues?
It's a decision tree:
0. whichdb fails
1. should the DB APIs use strings or bytes as keys and values?
Given the discussion of bsddb, I went for
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I think I will have to bite the bullet and use str8 explicitly,
> although doing so makes me shudder.
This is the right short-term solution IMO. We'll rename or reconsider
later -- either closer to the a1 release or after.
--
--Guido van
We're down to 11 failing test in the struni branch. I'd like to get
this down to zero ASAP so that we can retire the old p3yk (yes, with
typo!) branch and rename py3k-struni to py3k.
Please help! Here's the list of failing tests:
test_ctypes
Recently one test started failing again, after Martin c
On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > >> If that is not acceptable, please tell me how else
> > >> to fix the dbm modules.
> > >
> > > By fixing the code that uses them?
> >
> > I don't know how to do that. All impleme
On 8/6/07, Chris Monson <[EMAIL PROTECTED]> wrote:
> On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > b) should bytes literals be regular or frozen bytes?
> >
> > Regular -- set literals produce mutable sets, too.
>
> But all o
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> I don't know how to do that. All implementation strategies I
> >> can think of have significant drawbacks.
> >
> > Can you elaborate about the issues?
>
> It's a decision tree:
>
> 0. whichdb fails
>
> 1. should the DB APIs use strings or
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
>> I think of map() and filter() as sequence transformers. To me, it's
>> an unexpected semantic change that the result is no longer a list.
>
> Well, enough people thought of them as iteratables to request imap(),
> ifilter() and izip() added to the
Ron Adam wrote:
> {0:d,10+20} # Field width are just string operations done after
> # formatting is done.
>
> {0:d10+20} # Numeric widths, differ from field widths.
> # They are specific to the type so can handle special
>
Ron Adam wrote:
> What should happen in various situations of mismatched or invalid type
> specifiers?
I think that a format string that is not understood
by any part of the system should raise an exception
(rather than, e.g. falling back on str()). Refuse the
temptation to guess.
--
Greg
__
Guido van Rossum wrote:
> The frozenbytes type is intended (if I
> understand the use case correctly) as for the relatively rare case
> where bytes must be used as dict keys
Another issue I can see is that not having a frozen
bytes literal means that there is no efficient way of
embedding constant
Ron Adam wrote:
> Now here's the problem with all of this. As we add the widths back into
> the format specifications, we are basically saying the idea of a separate
> field width specifier is wrong.
>
> So maybe it's not really a separate independent thing after all, and it
> just a convenien
On Aug 6, 2007, at 9:30 PM, Greg Ewing wrote:
> If the literal form is frozen, on the other hand,
> you only incur these overheads when you really need
> a mutable copy of the data.
Indeed. I have no reason to think the desire for a frozen form is
the oddball case; I suspect it will be much mor
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>> I don't think it needs to be a separate type,
>> instead, bytes objects could have a idem-potent
>> .freeze() method which switches the "immutable"
>> bit on. There would be no way to switch it off
>> again.
>
> +1 here - hashable byte sequences are
On 6-Aug-07, at 5:39 PM, Guido van Rossum wrote:
>
> I thought about this issue some more.
>
> Given that the *dbm types strive for emulating dicts, I think it makes
> sense to use strings for the keys, and bytes for the values; this
> makes them more plug-compatible with real dicts. (We should id
On 8/6/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 6-Aug-07, at 5:39 PM, Guido van Rossum wrote:
> > Given that the *dbm types strive for emulating dicts, I think it makes
> > sense to use strings for the keys, and bytes for the values; this
> > makes them more plug-compatible with real dicts. (
On 8/6/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> writes:
[...pushback...]
> However, IMHO eliminating the strict versions of map() and filter() in
> favor of the lazy versions from itertools kicks the degree of
> sophistication necessary to understand t
On 6-Aug-07, at 7:06 PM, Guido van Rossum wrote:
> On 8/6/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
>> For instance, it is quite common to use integers as keys. If you are
>> inserting keys in order, it is about a hundred times faster to encode
>> the ints in big-endian byte order than than lit
Greg Ewing wrote:
> Ron Adam wrote:
>> What should happen in various situations of mismatched or invalid type
>> specifiers?
>
> I think that a format string that is not understood
> by any part of the system should raise an exception
> (rather than, e.g. falling back on str()). Refuse the
> te
> Personally, I still think that converting to the latin-1 encoding is
> probably just as good for this particular use case. So perhaps I don't
> understand the use case(s?) correctly.
No, it rather means that this solution didn't occur to me. It's a bit
expensive, since every access (getitem or s
> I thought about this issue some more.
>
> Given that the *dbm types strive for emulating dicts, I think it makes
> sense to use strings for the keys, and bytes for the values; this
> makes them more plug-compatible with real dicts. (We should ideally
> also change the keys() method etc. to retur
> The most efficient representation of immutable bytes is quite different
> from the most efficient representation of mutable bytes.
In what way?
Curious,
Martin
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo
> Or perhaps a special value of the encoding argument passed to
> *dbm.open() (maybe None, maybe the default, maybe "raw" or "bytes"?)
> to specify that the key values are to be bytes?
This is essentially the state of the bsddb module in the struni branch
right now. The default is bytes keys and v
> For instance, it is quite common to use integers as keys. If you are
> inserting keys in order, it is about a hundred times faster to encode
> the ints in big-endian byte order than than little-endian:
>
> class MyIntDB(object):
> def __setitem__(self, key, item):
>sel
From: "Kurt B. Kaiser" <[EMAIL PROTECTED]>
> , IMHO eliminating the strict versions of map() and filter() in
> favor of the lazy versions from itertools kicks the degree of
> sophistication necessary to understand these functions up a notch (or
> three).
Not really. Once range() starts returning
Martin v. Löwis wrote:
>> The most efficient representation of immutable bytes is quite different
>> from the most efficient representation of mutable bytes.
>
> In what way?
Well, in some runtime environments (I'm not sure about Python), for
immutables you can combine the object header and the
> This means that I can't distribute Python extensions as binaries.
I think this conclusion is completely wrong. Why do you come to it?
If you want to distribute extension modules for Ubuntu, just distribute
the UCS-4 module. You need separate binary packages for different
microprocessors and ope
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Or perhaps a special value of the encoding argument passed to
> > *dbm.open() (maybe None, maybe the default, maybe "raw" or "bytes"?)
> > to specify that the key values are to be bytes?
>
> This is essentially the state of the bsddb modul
On 8/6/07, Talin <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> >> The most efficient representation of immutable bytes is quite different
> >> from the most efficient representation of mutable bytes.
> >
> > In what way?
>
> Well, in some runtime environments (I'm not sure about Python), fo
>>> The most efficient representation of immutable bytes is quite different
>>> from the most efficient representation of mutable bytes.
>>
>> In what way?
>
> Well, in some runtime environments (I'm not sure about Python), for
> immutables you can combine the object header and the bytes array int
On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > For how long? Do you expect to receive further information that will
> > make a decision simpler?
>
> I'm waiting for a show-stopper issue that can't be solved without
> having an im
"Martin v. Löwis" writes:
> It's always possible to treat these as if they were latin-1, but this
> is so unnaturally hacky that I didn't think of it.
Emacs and XEmacs have both suffered (in different ways) from treating
raw bytes as ISO 8859-1. Python is very different (among other
things, th
> Apologies if this has been answered before, but why are you waiting
> for a show-stopper that requires an immutable bytes type rather than
> one that requires a mutable one?
You mean, the need for a mutable bytes type might not be clear yet?
Code that has been ported to the bytes type probably
> 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 bytes:bytes, any encoding wrappers on
top of it can be added later.
> Perhaps t
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> [...pushback...]
>
>> However, IMHO eliminating the strict versions of map() and filter() in
>> favor of the lazy versions from itertools kicks the degree of
>> sophistication necessary to understand these functions up a notch (or
>> three).
>
> I w
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> Not really. Once range() starts returning an iterator,
> that will be the new, basic norm. With that as a foundation,
> it would be suprising if map() and enumerate() and zip()
> did not return iterators. Learn once, use everywhere.
Except that
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Apologies if this has been answered before, but why are you waiting
> > for a show-stopper that requires an immutable bytes type rather than
> > one that requires a mutable one?
>
> You mean, the need for a mutable bytes type might not be
Guido van Rossum wrote:
> test_minidom
> Recently started failing again; probably shallow.
test_minidom is passing for me (Ubuntu 7.04, r56793, UCS2 build).
> test_tarfile
> Virgin territory again (but different owner :-).
The tarfile should be addressed by either its original author or
somebody
> For low-level I/O code, I totally agree that a mutable buffery object
> is needed.
The code we are looking at right now (dbm interfaces) *is* low-level
I/O code.
> For example, to support re-using bytes buffers, socket.send()
> would need to take start and end offsets into its bytes argument.
>
67 matches
Mail list logo
