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
Stefan Behnel wrote:
Travis Oliphant wrote:
Stefan Behnel wrote:
Anyway, my point is that this part of the protocol actually implies
setting a
lock on the buffer *provider* rather than the buffer itself, as the
buffer
provider cannot distinguish between different buffers based on a NULL
pointer
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_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymor
Perhaps drawing a distinction between containers (or maybe "collections"?),
and non-container iterables is appropriate? I would define containers as
objects that can be iterated over multiple times and for which iteration
does not instantiate new objects. By this definition generators would not
b
Hi,
I'm surprised that nobody except Robert Brewer reacted to my proposal. The two
relevant bugs (#2507 and #2833) have been marked respectively as "critical" and
"release blocker", so I thought at least some people felt concerned :-)
Should I wait a bit for people to react and give a qualified
Hi,
Python 3.0's urllib.quote() and unquote() handle non-ASCII data strangely.
quote() encodes characters with codepoint < 256 using latin-1, but others
using utf-8. unquote() decodes everything using latin-1.
Is the correct behavior to always use utf-8?
Georg
--
Thus spake the Lord: Thou shal
On Fri, May 30, 2008 at 02:19:23PM +0200, Georg Brandl wrote:
> Python 3.0's urllib.quote() and unquote() handle non-ASCII data strangely.
> quote() encodes characters with codepoint < 256 using latin-1, but others
> using utf-8. unquote() decodes everything using latin-1.
>
> Is the correct behav
Oleg Broytmann phd.pp.ru> writes:
> On Fri, May 30, 2008 at 02:19:23PM +0200, Georg Brandl wrote:
> > Python 3.0's urllib.quote() and unquote() handle non-ASCII data strangely.
> > quote() encodes characters with codepoint < 256 using latin-1, but others
> > using utf-8. unquote() decodes everythi
Hello,
As I can see that there is a PyInstanceMethod_New C API in Python 3,
which is a replacement of the old new.instancemethod. However, it is not
exported to Python namespace such as builtin or other module currently.
So I am curious that is there any plan to export it?
Thank you!
Best r
Raymond Hettinger wrote:
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An obj
The issue you're raising is deep. subtle and complex -- I can't quite
fathom your proposal, and expect I'd have to spend at least an hour
with the source code before I could truly understand the issue and the
proposal. I haven't done that yet, so take the following with a grain
of salt.
That said,
On Fri, May 30, 2008 at 3:51 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm surprised that nobody except Robert Brewer reacted to my proposal. The two
> relevant bugs (#2507 and #2833) have been marked respectively as "critical"
> and
> "release blocker", so I thought at least some
Hello,
Guido van Rossum python.org> writes:
>
> That said, it seems you are proposing taking the logical consequence
> of making except handlers properly nested and scoped,
It's exactly that.
> I would be okay as well with restricting bare raise syntactically to
> appearing only inside an exc
Adam Olsen gmail.com> writes:
> I'd like if a bare "raise" became purely lexical (as Guido just
> suggested), ditching all the magic.
>
> However, things such as pdb.pm() still need access to the last
> exception. Maybe we can pare it down the bare minimum, a per-thread
> last_exception? That'd
On Fri, May 30, 2008 at 10:40 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I'd like if a bare "raise" became purely lexical (as Guido just
> suggested), ditching all the magic.
>
> However, things such as pdb.pm() still need access to the last
> exception. Maybe we can pare it down the bare minimum
On Fri, May 30, 2008 at 11:10 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Guido van Rossum python.org> writes:
>>
>> That said, it seems you are proposing taking the logical consequence
>> of making except handlers properly nested and scoped,
>
> It's exactly that.
>
>> I would be okay as well
On Fri, May 30, 2008 at 12:16 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>> I'd like if a bare "raise" became purely lexical (as Guido just
>> suggested), ditching all the magic.
>>
>> However, things such as pdb.pm() still need access to the last
>> exception.
Adam Olsen gmail.com> writes:
>
> Just to be clear, you'll remove PyFrameObject's
> f_exc_{type,value,traceback},
Yes.
> and rely exclusively on sys.exc_info(),
> right?
More exactly, tstate->exc_* will continue storing the current state, and
sys.exc_info() will continue relying on these valu
Hi,
there still is a plat-mac directory in Lib (though it's empty), and several
places in the tree refer to it. Also, quite a few libs/scripts/tools in the
Mac subdir refer to modules that were removed in Python 3.
Some Mac head will need to do some additional cleanup before final release
(I'd
I'd be fine with adding '#' back to the formatting language for hex and oct.
On Thu, May 29, 2008 at 5:45 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> wesley chun wrote:
>>
>> On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
>>>
>>> Marcin 'Qrczak' Kowalczyk wrote:
Except that it works i
On Fri, May 30, 2008 at 2:08 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> there still is a plat-mac directory in Lib (though it's empty), and several
> places in the tree refer to it. Also, quite a few libs/scripts/tools in the
> Mac subdir refer to modules that were removed in Python 3.
On Fri, May 30, 2008 at 12:22 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 2:08 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> there still is a plat-mac directory in Lib (though it's empty), and several
>> places in the tree refer to it. Also, quite a few li
Of course.
On Fri, May 30, 2008 at 12:23 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>
>> I'd be fine with adding '#' back to the formatting language for hex and
>> oct.
>
> And bin, I assume?
>
>>
>> On Thu, May 29, 2008 at 5:45 PM, Eric Smith
>> <[EMAIL PROTECTED]> wrote
Guido van Rossum wrote:
I'd be fine with adding '#' back to the formatting language for hex and oct.
And bin, I assume?
On Thu, May 29, 2008 at 5:45 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
wesley chun wrote:
On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
Marcin 'Qrczak' Kowalczyk wro
On Fri, May 30, 2008 at 2:36 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 12:22 PM, Benjamin Peterson
>>
>> I'm pretty sure that plat-mac is going to go, but can Brett confirm?
>
> Ditch it. It's empty so there is no need to keep it. I am not even
> sure how useful the Mac
Guido van Rossum python.org> writes:
> I would be okay as well with restricting bare raise syntactically to
> appearing only inside an except block, to emphasize the change in
> semantics that was started when we decided to make the optional
> variable disappear at the end of the except block.
>
On Fri, May 30, 2008 at 7:33 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Guido van Rossum python.org> writes:
>> I would be okay as well with restricting bare raise syntactically to
>> appearing only inside an except block, to emphasize the change in
>> semantics that was started when we decid
27 matches
Mail list logo
