Guido van Rossum wrote:
> 2to3 lets you specify exactly which fixers to run with the -f command line
> flag.
Nice, one problem solved then. I assume that's also available in the library
version?
object. I find that very inconvenient.BTW, last time I checked, options were
passed into lib2to3 as
On Sat, May 31, 2008 at 4:41 PM, wesley chun <[EMAIL PROTECTED]> wrote:
> somewhat on-topic, can i hear from some of you as far as use-cases for
> oct() and hex() [plus bin()] in Python code? i find "%x" or "%o" (and
> its variants) sufficient in serving my needs. in other words, why
> oct() and
On Sat, May 31, 2008 at 2:33 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I think the reason why strict/backslashreplace (respectively) work
> well is that you can print a unicode string to stdout, have it fail
> (encoding can't handle it), then get an exception printed to stderr
> with the string e
2to3 lets you specify exactly which fixers to run with the -f command line flag.
I really don't like the idea of having Py3k code with doctests written
in a dialect of Py2k...
--Guido
On Sat, May 31, 2008 at 8:47 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>> Stefan Behnel
Antoine:
> Mark Hammond skippinet.com.au> writes:
> > In both Python 2.x and 3 (a few months old build of Py3k though), the
> > traceback isn't the same. For Python 2.0 you could write it like:
> >
> > def handle_exception():
> > ...
> > raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_inf
>>> I'd be fine with adding '#' back to the formatting language for hex and oct.
>>
>> And bin, I assume?
>
> Of course.
somewhat on-topic, can i hear from some of you as far as use-cases for
oct() and hex() [plus bin()] in Python code? i find "%x" or "%o" (and
its variants) sufficient in servin
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Of course, it would also be nice for ``help("if")`` to work effortlessly,
> which it currently only does if the generated HTML documentation is
> available somewhere, which it typically isn't -- on Unix most
> distribut
Hello again,
> Why not move f_exc_* into the PyTryBlock struct? We can eliminate the
> per-thread exception and have sys.exc_info() search the stack for an
> active except block. No need to swap anything because the stack is
> always current.
Yes it's a possible implementation. At the expense
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
sys.exc_info() will remain, it's just that the returned value will be
(None, None, None) if we are not in an except block in any of the
currently active frames in the thread. In the case above it would
return the current exception (the one caught in one
On Sat, May 31, 2008 at 2:03 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>>
>> The bytecode generation for "raise" could be changed literally be the
>> same as "except Foo as e: raise e". Reuse our existing stack, not add
>> another one.
>
> As someone else point
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Now that the docs are reST, the source is almost pretty enough to display
> it raw, but I could also imagine a "text" writer that removes the more
> obscure markup to present a casual-reader-friendly text version.
>
> Th
On Sat, May 31, 2008 at 11:30 AM, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 1:32 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> - I'm still not comfortable with making stdout default to
>> backslashreplace. Stuff written to stdout might be consumed by another
>> program
Great -- get ready to make your patch perfect!
On Sat, May 31, 2008 at 10:30 AM, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> Hi Guido,
>
> On Sun, Jun 1, 2008 at 1:32 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Hi Atsuo,
>>
>> I'm very close to accepting your PEP. I have a few questions:
>
Adam Olsen gmail.com> writes:
>
> The bytecode generation for "raise" could be changed literally be the
> same as "except Foo as e: raise e". Reuse our existing stack, not add
> another one.
As someone else pointed, there is a difference between the two constructs: the
latter appends a line to
On Sat, May 31, 2008 at 11:41 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>> > By the way, another interesting sys.exc_info() case:
>> >
>> > def except_yield():
>> >try:
>> >raise TypeError
>> >except:
>> >yield 1
>> >
>> > def f():
>> >
Adam Olsen gmail.com> writes:
> > By the way, another interesting sys.exc_info() case:
> >
> > def except_yield():
> >try:
> >raise TypeError
> >except:
> >yield 1
> >
> > def f():
> >for i in except_yield():
> >return sys.exc_info()
> >
> > Right now, running f
Hi Guido,
On Sun, Jun 1, 2008 at 1:32 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hi Atsuo,
>
> I'm very close to accepting your PEP. I have a few questions:
Great!
>
> - The Rationale has a more elaborate (and perhaps slightly
> conflicting, regarding the status of ASCII space?) definitio
On Sat, May 31, 2008 at 7:59 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Mark Hammond skippinet.com.au> writes:
>> In both Python 2.x and 3 (a few months old build of Py3k though), the
>> traceback isn't the same. For Python 2.0 you could write it like:
>>
>> def handle_exception():
>> ...
>>
Hi Atsuo,
I'm very close to accepting your PEP. I have a few questions:
- The Rationale has a more elaborate (and perhaps slightly
conflicting, regarding the status of ASCII space?) definition of our
definition of non-printable than the Specification. Perhaps this could
be merged?
- I'm still no
Georg Brandl wrote:
> Stefan Behnel schrieb:
>> I know, I could use the lib2to3 package, but it a) is a one-way tool
>> in the
>> wrong direction if you have to distinguish bytes/str literals, b) lacks
>> configurability stating exactly what changes need to be done and c)
>> seemed
>> harder to set
Georg Brandl wrote:
Brett Cannon schrieb:
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then
again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Fred had the interesting suggestion of removing pydoc in Py3K based on
the thinki
Brett Cannon schrieb:
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then
again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Fred had the interesting suggestion of removing pydoc in Py3K based on
the thinking that documentation
Stefan Behnel schrieb:
Hi,
I currently use a bunch of work-arounds for doctests in lxml's test suite to
make them work in Py3. I converted most tests to a mix of Py2 and Py3 syntax
(e.g. using both u'' and b'' literals), and most of the runtime work is done
using regular expressions that convert
Mark Hammond skippinet.com.au> writes:
> In both Python 2.x and 3 (a few months old build of Py3k though), the
> traceback isn't the same. For Python 2.0 you could write it like:
>
> def handle_exception():
> ...
> raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
>
> Its not cl
On Wed, May 28, 2008 at 5:48 AM, Carl Johnson <[EMAIL PROTECTED]> wrote:
> Proposed behavior of the __str__ method for iterables is that it returns the
> result of "".join(str(i) for i in self).
In 8-9 years of python programming I have probably never needed to do
"".join(str(i) for i in self), so
Hi,
I currently use a bunch of work-arounds for doctests in lxml's test suite to
make them work in Py3. I converted most tests to a mix of Py2 and Py3 syntax
(e.g. using both u'' and b'' literals), and most of the runtime work is done
using regular expressions that convert the except-as syntax, st
> >> This would render the following code illegal:
> >>
> >> def f():
> >> try: 1/0
> >> except: pass
> >> raise
> >
> > But you may want to use bare raise in a function called from an
> exception
> > handler, e.g.:
> >
> > def handle_exception():
> >if user() == "Albert":
> ># Al
27 matches
Mail list logo
