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
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
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
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
| 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
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"..
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.
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
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
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
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
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
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()
_
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 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
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
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
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
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
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/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:/
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
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
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
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 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
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
+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
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
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
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.
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
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
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
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
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
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
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.
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.
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:
> 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
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, 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
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
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 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
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
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
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
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).
>
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, 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
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, 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 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/.
>
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 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(
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 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
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.
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
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
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
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
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
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 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
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
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
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
70 matches
Mail list logo
