On Mon, Feb 13, 2006 at 04:04:26PM -0800, Guido van Rossum wrote:
> In private email, Phillip Eby suggested to add these things to the
> 2.5. standard library:
>
> bdist_deb, bdist_msi, and friends
FWIW, I've been using a patched distutils with bdist_deb, and it's worked
fine for the most part. T
Adam Olsen wrote:
> What would that imply for repr()? To support eval(repr(x))
I don't think eval(repr(x)) needs to be supported for the bytes
type. However, if that is desirable, it should return something
like
bytes([1,2,3])
Regards,
Martin
___
Py
Guido van Rossum wrote:
> In private email, Phillip Eby suggested to add these things to the
> 2.5. standard library:
>
> bdist_deb, bdist_msi, and friends
[...]
> I guess bdist_egg should also be added if we support setuptools (not
> setuplib as I mistakenly called it previously)?
I'm in favour
On Feb 14, 2006, at 12:20 AM, Phillip J. Eby wrote:
> bytes(map(ord, str_or_unicode))
>
> In other words, without an encoding, bytes() should simply treat
> str and
> unicode objects *as if they were a sequence of integers*, and
> produce an
> error when an integer is out of range. This i
M.-A. Lemburg wrote:
>>It's the consequences: nobody complains about tacking "const" on to a
>>former honest-to-God "char *" argument that was in fact not modified,
>>because that's not only helpful for C++ programmers, it's _harmless_
>>for all programmers. For example, nobody could sanely objec
On 2/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > We're talking about Py3k here: "abc" will be a Unicode string,
> > so why restrict the conversion to 7 bits when you can have 8 bits
> > without any conversion problems ?
>
> YAGNI. If you have a need for byte strin
Guido van Rossum wrote:
>>In py3k, when the str object is eliminated, then what do you have?
>>Perhaps
>>- bytes("\x80"), you get an error, encoding is required. There is no
>>such thing as "default encoding" anymore, as there's no str object.
>>- bytes("\x80", encoding="latin-1"), you get a bytest
Phillip J. Eby wrote:
> I was just pointing out that since byte strings are bytes by definition,
> then simply putting those bytes in a bytes() object doesn't alter the
> existing encoding. So, using latin-1 when converting a string to bytes
> actually seems like the the One Obvious Way to do i
M.-A. Lemburg wrote:
> We're talking about Py3k here: "abc" will be a Unicode string,
> so why restrict the conversion to 7 bits when you can have 8 bits
> without any conversion problems ?
YAGNI. If you have a need for byte string in source code, it will
typically be "random" bytes, which can be
Jeremy Hylton wrote:
> The compiler in question is gcc and the warning can be turned off with
> -Wno-write-strings. I think we'd be better off leaving that option
> on, though. This warning will help me find places where I'm passing a
> string literal to a function that does not take a const char
At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
>On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > I didn't mean that it was the only purpose. In Python 2.x, practical code
> > has to sometimes deal with "string-like" objects. That is, code that takes
> > either strings or unicode.
On Feb 13, 2006, at 7:29 PM, Guido van Rossum wrote:
> There's one property that bytes, str and unicode all share: type(x[0])
> == type(x), at least as long as len(x) >= 1. This is perhaps the
> ultimate test for string-ness.
But not perfect, since of course other containers can contain objects
On 2/13/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> In py3k, when the str object is eliminated, then what do you have?
> >> Perhaps
> >> - bytes("\x80"), you get an error, encoding is required. There is no
> >> such thing as "default encoding"
On Monday 13 February 2006 21:52, Neil Schemenauer wrote:
> Also, I think it would useful to introduce byte array literals at
> the same time as the bytes object. That would allow people to use
> byte arrays without having to get involved with all the silly string
> encoding confusion.
bytes(
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> In py3k, when the str object is eliminated, then what do you have?
>> Perhaps
>> - bytes("\x80"), you get an error, encoding is required. There is no
>> such thing as "default encoding" anymore, as there's no str object.
>> - bytes("\x80", encoding="la
On 2/13/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Monday 13 February 2006 15:40, Guido van Rossum wrote:
> > Shouldn't docs.python.org be removed? It seems to add mroe confusion
> > than anything, especially since most links on python.org continue to
> > point to python.org/doc/.
>
On 2/13/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> So, in python2.X, you have:
> - bytes("\x80"), you get a bytestring with a single byte of value
> 0x80 (when no encoding is specified, and the object is a str, it
> doesn't try to encode it at all).
> - bytes("\x80", encoding="latin-1"), you g
On Feb 13, 2006, at 7:09 PM, Guido van Rossum wrote:
> On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>> Sorry - I meant for the unicode to bytes case. A default encoding
>> that
>> behaves differently to the current to implicit encodes/decodes
>> would be
>> confusing IMHO.
>
> And I am
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I didn't mean that it was the only purpose. In Python 2.x, practical code
> has to sometimes deal with "string-like" objects. That is, code that takes
> either strings or unicode. If such code calls bytes(), it's going to want
> to include
Hi folks. I had been planning to attend PyCon this year and was really
looking forward to it, but i need to cancel. I am sorry that i won't
be getting to see you all in a couple of weeks.
If you know anyone who hasn't yet registered but wants to go, please
contact me -- we can transfer my regist
On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> Sorry - I meant for the unicode to bytes case. A default encoding that
> behaves differently to the current to implicit encodes/decodes would be
> confusing IMHO.
And I am in agreement with you there (I think only Phillip argued otherwise).
>
At 03:23 PM 2/13/2006 -0800, Guido van Rossum wrote:
>On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > The only
> > use I see for having an encoding for a 'str' would be to allow confirming
> > that the input string in fact is valid for that encoding. So,
> > "bytes(some_str,'ascii')" wou
Sorry, you're right. operator.index() sounds fine.
--Guido
On 2/13/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>...
> > I don't like to add a built-in index() at this point; mostly because
> > of Occam's razor (we haven't found a need
In private email, Phillip Eby suggested to add these things to the
2.5. standard library:
bdist_deb, bdist_msi, and friends
He explained them as follows:
"""
bdist_deb makes .deb files (packages for Debian-based Linux distros, like
Ubuntu). bdist_msi makes .msi installers for Windows (it's by M
On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> I don't like to add a built-in index() at this point; mostly because
> of Occam's razor (we haven't found a need).
I thought you had agreed, back when I had said that __index__ should
also be made easily available to implementors of
Guido van Rossum wrote:
> On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>> Phillip J. Eby wrote:
>> [snip..]
>>
>>> In fact, the 'encoding' argument seems useless in the case of str objects,
>>> and it seems it should default to latin-1 for unicode objects. The only
>>>
>>>
On Mon, 2006-02-13 at 15:44 -0800, Guido van Rossum wrote:
> The right way to look at this is, as Phillip says, to consider
> conversion between str and bytes as not an encoding but a data type
> change *only*.
That sounds right to me too.
-Barry
signature.asc
Description: This is a digitally
On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> [snip..]
> >
> > In fact, the 'encoding' argument seems useless in the case of str objects,
> > and it seems it should default to latin-1 for unicode objects. The only
> >
> -1 for having an implicit encode that behaves
Phillip J. Eby wrote:
[snip..]
>
> In fact, the 'encoding' argument seems useless in the case of str objects,
> and it seems it should default to latin-1 for unicode objects. The only
>
-1 for having an implicit encode that behaves differently to other
implicit encodes/decodes that happen in
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:03 AM 2/14/2006 +0100, M.-A. Lemburg wrote:
> >The conversion from Unicode to bytes is different in this
> >respect, since you are converting from a "bigger" type to
> >a "smaller" one. Choosing latin-1 as default for this
> >conversion
At 12:03 AM 2/14/2006 +0100, M.-A. Lemburg wrote:
>The conversion from Unicode to bytes is different in this
>respect, since you are converting from a "bigger" type to
>a "smaller" one. Choosing latin-1 as default for this
>conversion would give you all 8 bits, instead of just 7
>bits that ASCII pr
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, I thought we were talking about adding bytes() in 2.5.
I was.
> However, now that you've brought this up, it actually makes perfect sense
> to just use latin-1 as the effective encoding for both strings and
> unicode. In Python 2.
On 2/13/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It'd be cruel and unusual punishment though to have to write
> >
> > bytes("abc", "Latin-1")
> >
> > I propose that the default encoding (for basestring instances) ought
> > to be "ascii" just like everywhere else.
Phillip J. Eby wrote:
Why not just have the constructor be:
bytes(initializer [,encoding])
Where initializer must be either an iterable of suitable integers, or a
unicode/string object. If the latter (i.e., it's a basestring), the
encoding argument would the
Fred L. Drake, Jr. wrote:
> docs.python.org was created specifically to make searching the most recent
> "stable" version of the docs easier (using Google's site: modifier, no less).
> I don't know what the link count statistics say (other than what you
> mention), and don't know which gets hit mo
On Monday 13 February 2006 15:40, Guido van Rossum wrote:
> Shouldn't docs.python.org be removed? It seems to add mroe confusion
> than anything, especially since most links on python.org continue to
> point to python.org/doc/.
docs.python.org was created specifically to make searching the most
Tim Peters wrote:
> [Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
>
> [Tim]
>>> If he had _stuck_ to that, we wouldn't be having this discussion :-)
>>> (that is, nobody passes string literals to
>>> PyArg_ParseTuple
At 10:55 PM 2/13/2006 +0100, M.-A. Lemburg wrote:
>Guido van Rossum wrote:
> > On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >> At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
> >>> One recommendation: for starters, I'd much rather see the bytes type
> >>> standardized without a lite
Guido van Rossum wrote:
> Shouldn't docs.python.org be removed? It seems to add mroe confusion
> than anything, especially since most links on python.org continue to
> point to python.org/doc/.
>
>
All the web says about 1200 links into the docs.python.org subdomain.
(Different to the google li
On Mon, Feb 13, 2006 at 05:41:00PM -0500, A.M. Kuchling wrote:
> On Mon, Feb 13, 2006 at 03:52:44PM -0500, Fred L. Drake, Jr. wrote:
> > What I would also like to see is to have an automatically-updated
> > version for each of the maintainer versions of Python, as well as
> > the development trunk.
On 2/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > Ok. I reviewed the original problem and you're right, the problem was
> > not that it failed outright but that it produced a warning about the
> > deprecated conversion:
> > warning: deprecated conversion from stri
Guido van Rossum wrote:
> On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
>>> One recommendation: for starters, I'd much rather see the bytes type
>>> standardized without a literal notation. There should be are lots of
>>> ways to creat
+1
On 2/13/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> It sounds like the right answer for Python is to change the signature
> of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
> const rules .
>
> Jeremy
>
> On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 2/12
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules .
Jeremy
On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > [A large head-explodi
On Mon, Feb 13, 2006, Jim Jewett wrote:
>
> getattr and getattribute are both things you might reasonably want to
> do. __int__ is something you probably shouldn't be doing very often
> anymore; it is being kept for backwards compatibility.
And how do you convert a float to an int? __int__ is NOT
On Mon, Feb 13, 2006 at 03:52:44PM -0500, Fred L. Drake, Jr. wrote:
> What I would also like to see is to have an automatically-updated
> version for each of the maintainer versions of Python, as well as
> the development trunk. That would mean two versions at this point
> (2.4.x, 2.5.x); only one
On 2/13/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Travis wrote:
>
> > The patch adds a new API function int PyObject_AsIndex(obj)
>
> How did you decide between int and long?
>
> Why not ssize_t?
It should be the same type used everywhere for indexing. In the svn
HEAD that's int. Once PEP 353 l
Travis wrote:
> The patch adds a new API function int PyObject_AsIndex(obj)
How did you decide between int and long?
Why not ssize_t?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
Travis wrote:
> The patch adds a new API function int PyObject_AsIndex(obj)
How did you decide between int and long?
Why not ssize_t?
Also, if index is being added as a builtin, should the failure
result be changed? I'm thinking that this may become a
replacement for isinstance(val, (int, lon
On 2/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > [A large head-exploding set of rules]
>
> Blarg.
>
> Const - Just Say No.
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http:/
I've rejected PEP 351, with a reference to this thread as the rationale.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
> >One recommendation: for starters, I'd much rather see the bytes type
> >standardized without a literal notation. There should be are lots of
> >ways to create bytes objects from string ob
On 2/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > (Now that I work for Google I realize more than ever before the
> > importance of keeping URLs stable; PageRank(tm) numbers don't get
> > transferred as quickly as contents. I have this worry too in the
> > context
Is there a reason __integer__ would be rejected?
Guido van Rossum answered:
> Given the number of folks who misappreciate the difference between
> __getattr__ and __getattribute__, I'm not sure I'd want to encourage
> using abbreviated and full forms of the same term in the same context.
> When c
Guido van Rossum wrote:
> (Now that I work for Google I realize more than ever before the
> importance of keeping URLs stable; PageRank(tm) numbers don't get
> transferred as quickly as contents. I have this worry too in the
> context of the python.org redesign; 301 permanent redirect is *not*
> g
On Monday 13 February 2006 10:03, Georg Brandl wrote:
> The above docs are from August 2005 while docs.python.org/dev is current.
> Shouldn't the old docs be removed?
I'm afraid I've generally been too busy to chime in much on this topic, but
I've spent a bit of time thinking about it, and woul
Shouldn't docs.python.org be removed? It seems to add mroe confusion
than anything, especially since most links on python.org continue to
point to python.org/doc/.
On 2/13/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> The above docs are from August 2005 while docs.python.org/dev is current.
> Shou
On 2/13/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido:
>
> > I don't like __true_int__ very much. Personally,
> > I'm fine with calling it __index__
>
> index is OK, but is there a reason __integer__ would be
> rejected?
>
> __int__ roughly follows the low-level C implementation,
> and may do o
Guido:
> I don't like __true_int__ very much. Personally,
> I'm fine with calling it __index__
index is OK, but is there a reason __integer__ would be
rejected?
__int__ roughly follows the low-level C implementation,
and may do odd things on unusual input.
__integer__ properly creates a concept
Please do not spam multiple mail lists with these posts (edu-sig,
python-dev, and tutor).
Raymond
- Original Message -
From: "Smith" <[EMAIL PROTECTED]>
To:
Cc: ;
Sent: Monday, February 13, 2006 12:10 PM
Subject: Re: [Python-Dev] nice()
_
On 2/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > I'm tempted to say we should merge now. I know the branch works on
> > 64-bit boxes. I can test on a 32-bit box if Martin hasn't already.
> > There will be a lot of churn fixing problems, but maybe we can get
> > m
On 2/10/06, Mark Russell <[EMAIL PROTECTED]> wrote:
>
> On 10 Feb 2006, at 12:45, Nick Coghlan wrote:
>
> An alternative would be to call it "__discrete__", as that is the key
>
> characteristic of an indexing type - it consists of a sequence of discrete
>
> values that can be isomorphically mapped
At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
>One recommendation: for starters, I'd much rather see the bytes type
>standardized without a literal notation. There should be are lots of
>ways to create bytes objects from string objects, with specific
>explicit encodings, and those should suf
Guido van Rossum wrote:
> One recommendation: for starters, I'd much rather see the bytes type
> standardized without a literal notation. There should be are lots of
> ways to create bytes objects from string objects, with specific
> explicit encodings, and those should suffice, at least initially.
One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation. There should be are lots of
ways to create bytes objects from string objects, with specific
explicit encodings, and those should suffice, at least initially.
I also wonder if having a b"..
| From: Josiah Carlson <[EMAIL PROTECTED]>
| "Alan Gauld" <[EMAIL PROTECTED]> wrote:
|| However I do dislike the name nice() - there is already a nice() in
|| the
|| os module with a fairly well understood function.
perhaps trim(), nearly(), about(), defer_the_pain_of() :-) I've waited to think
On 2/13/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Eric Sumner wrote:
> > I realize that I made an assumption that may not be valid;
> > namely, that a new scope is generated by the 'with' statement.
>
> The with statement uses the existing scope - its just a way of factoring out
> try/finally b
The above docs are from August 2005 while docs.python.org/dev is current.
Shouldn't the old docs be removed?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Eric Sumner wrote:
> I realize that I made an assumption that may not be valid;
> namely, that a new scope is generated by the 'with' statement.
The with statement uses the existing scope - its just a way of factoring out
try/finally boilerplate code. No more, and, in fact, fractionally less (the
On 2/12/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[paragraphs swapped]
> The desire for context managers to have access to its enclosing scope is
> another discussion entirely, though it may do so without express
> permission via stack frame manipulation.
My main point was that, with relativel
70 matches
Mail list logo
