Le jeudi 06 avril 2006 à 13:33 -0700, Guido van Rossum a écrit :
> I think that the solution to this would be a book or course "Python
> for Java programmers". Not using the most natural name for a feature
> because Java programmers might misunderstand it sound like the wrong
> motivation.
>
> Pl
Le jeudi 06 avril 2006 à 17:10 -0700, Guido van Rossum a écrit :
> On 4/6/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > But overloaded methods as they exist now have exactly the same
> > expression as non-overloaded methods, all the machinery (mro walking
> >
Le samedi 22 avril 2006 à 16:17 +0100, Guido van Rossum a écrit :
> Groovy has a different approach that doesn't blend the two syntaxes,
> but rather gives you more native syntax for constructing DOM trees (or
> event streams; it wasn't clear from the description I saw today). That
> makes perhaps
Le mercredi 26 avril 2006 à 08:40 -0400, Greg Wilson a écrit :
> I think this is because:
>
> a) sets are new to Python --- habit and examples both encourage us to use
>lists, even when the collections in question aren't intrinsically
>ordered; and
>
> b) the current notation is unpleasan
Le mercredi 26 avril 2006 à 11:38 -0400, Jim Jewett a écrit :
> (2) How to make set usage at least as efficient.
> (3) Whether the tradeoffs are worth it.
Well, testing for inclusion in a container of 3 ints may not be
significant vs. all the overhead of the interpreter and vs. what you are
act
Le vendredi 28 avril 2006 à 15:12 -0400, Terry Reedy a écrit :
> The generic solution is better package fetching, such as apparently done (I
> have not used them yet) by setuptools and easy_install. The installing an
> app needing wxPython should fetch and install that also and installing an
>
Le samedi 29 avril 2006 à 02:07 -0400, Tim Peters a écrit :
> If you don't remember these confusions, I think it should suffice to
> remind that Perl's join() does take the separator first (which is
> essentially forced in Perl, given its odd LIST syntax):
PHP's join does too, also some versions h
Le vendredi 28 avril 2006 à 23:14 -0700, Josiah Carlson a écrit :
> Ultimately, PyGUI is essentially a wrapper of native or near-native
> widgets into a common interface. wxPython is exactly the same thing,
> only it has a much larger user base, developer support, and (native and
> emulated) platf
Le samedi 29 avril 2006 à 21:10 +0200, tomer filiba a écrit :
> and if we do that already, perhaps we should introduce async
> operations as a
> built-in feature? .NET does (BeginRead, EndRead, etc.)
> def async_read(self, count, callback)
> def async_write(self, data, callback)
I think m
Le lundi 01 mai 2006 à 10:57 +0200, Fredrik Lundh a écrit :
> Thomas Wouters wrote:
>
> > > join()
> > >
> > > it's time to make this a builtin. the "it's the separator that's doing
> > > the
> > > joining" idea is silly and unintuitive, and should be fixed.
> >
> >
> > I disagree, and I believe
Le lundi 01 mai 2006 à 23:08 +1200, Greg Ewing a écrit :
> Are you sure? Last time I looked at wxWindows, it seemed more
> like it re-implemented everything its own way.
>
> I might be wrong, but if wxWindows is just a wrapper, why
> is it so huge?
I think it is huge because it has a lot of widge
Le lundi 01 mai 2006 à 09:59 -0700, Bill Janssen a écrit :
> Interesting. I never seem to use tree-views, but I do use graph
> views. I think the standard Python GUI should make it easy to build
> these kinds of things. Right now a graph view is fairly easy to build
> on top of a raw View.
As f
Le lundi 01 mai 2006 à 11:44 -0700, Bill Janssen a écrit :
> > - list controls
>
> Not sure what you mean here.
A control which displays and allows to interact with several lines of
widgets (e.g. labels, images...).
For example a buddy list in an Instant Messaging client.
> > - menu hotkeys (e.g
Le mardi 02 mai 2006 à 18:14 -0400, Jim Jewett a écrit :
> They can, by installing wxPython. How long would it take to
> understand wxpython? My gut feel is "longer than it took to
> understand Python", which makes it pretty heavyweight.
Understanding wxPython in itself is not difficult (a tool
Le mercredi 03 mai 2006 à 07:46 +0200, Fredrik Lundh a écrit :
> Antoine Pitrou wrote:
>
> > Including a simplistic GUI library in the stdlib is really *not* helpful
> > to developers, it can even be deceptive.
>
> what makes discussions like these impossible is that eve
(used the wrong address and first sent it in private to Michael, sorry)
Le mercredi 03 mai 2006 à 04:41 -0700, Michael Chermside a écrit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and flo
Le mercredi 03 mai 2006 à 09:22 -0400, Greg Wilson a écrit :
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
>
> TypeTwo elementsOne elementEmpty
> List[1, 2]
Le samedi 06 mai 2006 à 08:05 -0400, Blake Winton a écrit :
> Bill Janssen wrote:
> > GvR writes:
> >>On 5/5/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >Is there anywhere else in Python where the type of an object isn't
> >checkable with isinstance()?
> Yes, it's called duck typing.
Le dimanche 07 mai 2006 à 17:47 +1200, Greg Ewing a écrit :
> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't
Le lundi 08 mai 2006 à 07:13 -0700, Aahz a écrit :
> Aside from Java and Swing (which has its own set of problems), is there
> any readily-available GUI that includes a significant number of platforms
> other than the Big Three?
>From the wxWidgets FAQ:
« What platforms are supported by wxWidgets
Hi
Le mardi 09 mai 2006 à 09:30 -0700, Bill Janssen a écrit :
> I have to confess I don't see the point of some of them: Listview and
> Gridview are trivial if there's a reasonable layout system,
Listviews (and likewise Gridviews) have more functionality than a simple
layout. An average listview
Hi,
Le mardi 09 mai 2006 à 12:46 -0400, Phillip J. Eby a écrit :
> Unless this can be done by a third party, it's not at all the same
> thing. Currently in Python for a third party to add a mixin, they would
> have to hack the class's __bases__, which I am not suggesting here at all.
>
> In f
Le mardi 09 mai 2006 à 20:44 -0400, Jim Jewett a écrit :
> Events (or slots, or signals) which are internal to the GUI do not
> need to be exposed.
> When it is needed, translating between from a signal to an event or an
> event to a slot may not be the most graceful solution, but it will
> work.
Le mercredi 10 mai 2006 à 03:23 +0200, Giovanni Bajo a écrit :
> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
> Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
> different APIs from the Yes/No case, if you're going to use a specialized
> vers
Le jeudi 11 mai 2006 à 10:00 -0600, Travis E. Oliphant a écrit :
>
> That sounds reasonable. As I said before, I like the idea of PyGUI.
> My main consternation is wxWindows. I'm not a big fan of how wxPython
> builds on top of wxWindows which builds on top of GTK which itself
> builds on G
Le dimanche 14 mai 2006 à 11:01 +1000, Nick Coghlan a écrit :
> Fredrik Johansson wrote:
> > For example, square roots are known as math.sqrt(x) for floats,
> > cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> > gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
>
Le lundi 22 mai 2006 à 09:07 -0700, Brett Cannon a écrit :
> Actually, there aren't any real proposals. =)
>
> I tried bringing up the topic earlier this year shortly after Python
> 3000 discussion took off, and everyone said to hold off for a while on
> that topic.
Perhaps a wiki page somewher
Le lundi 22 mai 2006 à 09:46 -0700, Aahz a écrit :
> On Mon, May 22, 2006, Antoine Pitrou wrote:
> >
> > For example, one common annoyance IMO is naming: why "urllib" or
> > "httplib"? If I import something, it's obvious it's a lib, so &quo
Le mercredi 24 mai 2006 à 15:43 -0400, Benji York a écrit :
> Hmm, the next best thing I can come up with is:
>
> def f(a, b, =, c, d):
Why not:
def f(a, b, !c, !d):
The exclamation mark can be thought to say "you must explicitly mention
this one by its name".
I think having a sigil in front o
Le mercredi 24 mai 2006 à 17:15 -0400, Benji York a écrit :
> In that case, just use the current default value syntax, sans value (d,
> below):
>
> def f(a, b, c=None, d=):
Then we can't decide whether "c" can be positional or is keyword-only.
___
Py
Le mardi 30 mai 2006 à 09:25 -0700, Brett Cannon a écrit :
>
> I think what needs to happen is decide if we want to group modules
> into packages (but no deeper than a single depth), and then how to
> handle general naming (e.g., net.http, net.httplib, http, or
> httplib?).
I don't see the point
Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :
>
> That might be true of http, but what about modules with a more
> ambiguous name?
Then perhaps the name can be made less ambiguous ;)
For example "ElementTree" could be named "xmltree", or whatever.
> But with Java (don't have muc
Le mercredi 31 mai 2006 à 11:31 -0700, Brett Cannon a écrit :
> If there were categories, though, I would most likely have the handful
> of package names memorized. So I would run help() on the packages to
> see what modules they had and the summary. Basically what I should
> probably be doing wi
Hi,
Le jeudi 07 septembre 2006 à 12:21 -0700, Paul Prescod a écrit :
> If you have access to "German Windows XP", "Japanese Windows XP",
> "Spanish OS X", "Japanese OS X", "German Ubuntu" etc., I would
> appreciate answers to the following questions.
French Mandriva (up-to-date development ver
Le jeudi 07 septembre 2006 à 16:33 -0700, Guido van Rossum a écrit :
> Why not use tell() and seek() instead of get_pointer() and
> set_pointer()? Seek should also support several special cases:
> f.seek(0) seeks to the start of the file no matter what type is
> otherwise used for pointers ("seek c
Le jeudi 07 septembre 2006 à 15:41 -0700, Paul Prescod a écrit :
> Are you plugged into the Mandriva community?
Not much. I only participe in bug reports ;)
> Is there any debate about the continued use of iso8859-15?
I think there has been some for years. Some people in the community push
for
Le vendredi 08 septembre 2006 à 11:06 -0700, Guido van Rossum a écrit :
> -1 on those particular cryptic names. Which one of seekby() and
> rseek() is the relative seek? Where's the seek relative to EOF?
What about seek(), seek_relative() and seek_reverse() ?
"rseek" also looks like "relative see
Le vendredi 08 septembre 2006 à 15:04 -0400, Jim Jewett a écrit :
> > What about seek(), seek_relative() and seek_reverse() ?
>
> Why not just borrow the standard symbolic names of cur and end?
>
> seek(pos=0)
> seek_cur(pos=0)
> seek_end(pos=0)
You are right, it's clear and shorter
Le samedi 09 septembre 2006 à 20:29 -0700, Paul Prescod a écrit :
> The type could be a true encoding or one of a small set of additional
> symbolic values. The two main symbolic values are:
Actually your proposal has three ;)
> For example, a Japanese school teacher using Windows might default
>
> The Site Decoding Hook
>
>
> The "sys" module could have a function called
> "setdefaultfileencoding". The encoding specified could be a true
> encoding name or one of the encoding detection scheme names ( e.g.
> "guess" or "XML").
Isn't it more intuitive to gather fu
Le dimanche 10 septembre 2006 à 21:58 +1000, Nick Coghlan a écrit :
> Antoine Pitrou wrote:
> > So, here is an alternative proposal :
> > Make it so that textfile() doesn't recognize system-wide defaults (as in
> > your proposal), but also provide autotextfile() which
Hi,
Let me add that 'guess' should probably be forbidden as an encoding
parameter (instead, a separate function argument should be used as in my
proposal).
Here is a schematic example to show why :
def append_text(filename, encoding):
src = textfile(filename, "r", encoding)
my_text = sr
Le dimanche 10 septembre 2006 à 23:44 +1000, Nick Coghlan a écrit :
> Interesting. This goes back more towards the model of "no default encoding,
> but provide the right tools to make it easy for a program to choose one in
> the
> absence of any metadata".
In the "clean" API yes.
But it would
Le dimanche 10 septembre 2006 à 14:52 +0100, David Hopwood a écrit :
> > On the other hand "autotextfile('myfile.txt', by_content=True)" would
> > enable content-based guessing, thus be equivalent to Paul's
> > "encoding='guess'".
>
> As I pointed out earlier, any file open function that guesses t
Hi,
Another aspect of the textfile discussion.
sys.stdin and sys.stdout are for now, concretely, byte streams (AFAIK,
at least under Unix). Yet it must be possible to read/write text to and
from them.
So two questions:
- Is there a builtin text.stdin / text.stdout counterpart to
sys.stdin / sys
Le dimanche 10 septembre 2006 à 12:02 -0700, Paul Prescod a écrit :
> Your algorithm is more predictable but will confuse BOM-less UTF-8
> with the system encoding frequently.
I don't think it is desirable to acknowledge only some kinds of UTF-8.
It will confuse the hell out of programmers, and u
Le dimanche 10 septembre 2006 à 11:30 -0700, Paul Prescod a écrit :
> I don't mind your name of autotextfile but I think that your
> by_content argument defeats the goal of having a very simple API for
> quick and dirty stuff. If content detection is a good idea (usually
> right) then we should do
Le lundi 11 septembre 2006 à 11:22 -0700, Michael Chermside a écrit :
> The idea of a standard edu library though is a GREAT one. That would
> provide a standard place for things like raw_input() (with a better
> name) as well as lots of other "helper functions" useful to beginners
> and/or studen
Le lundi 11 septembre 2006 à 18:16 -0700, Paul Prescod a écrit :
> On Unix, VIM is also set up to auto-detect UTF-8 (using the BOM or
> full decoding attemption). According to Google, XEmacs also has some
> kind of UTF-8/BOM detector but I don't know the details. GNU Emacs:
> According to "Emacs wi
Le mercredi 13 septembre 2006 à 09:41 -0700, Josiah Carlson a écrit :
> And is generally ignored, as per unicode spec; it's a "zero width
> non-breaking space" - an invisible character with no effect on wrapping
> or otherwise.
Well it would be better if Py3K (with all strings unicode) makes thin
Hi,
Le mercredi 13 septembre 2006 à 16:14 -0700, Josiah Carlson a écrit :
> In any case, I believe that the above behavior is correct for the
> context. Why? Because utf-8 has no endianness, its 'generic' decoding
> spelling of 'utf-8' is analagous to all three 'utf-16', 'utf-16-be', and
> 'utf
Le vendredi 15 septembre 2006 à 10:48 -0700, Josiah Carlson a écrit :
> This is one of the reasons why I was talking Latin-1, UCS-2, and UCS-4:
You could replace "latin-1" with "one-byte system encoding chosen at
interpreter startup depending on locale".
There are lots of 8-bit encodings other tha
Le dimanche 17 septembre 2006 à 23:16 +1000, Nick Coghlan a écrit :
> Brett Cannon's sandboxing work (which aims to provide first-class support for
> multiple interpreters in the same process for security reasons) also seems
> like a potentially fruitful approach to distributing processing to mul
Le lundi 18 septembre 2006 à 09:48 -0600, Adam Olsen a écrit :
> * Bolt-on tracing GC such as Boehm-Demers-Weiser. Totally unsupported
> by the C standards and changes cache characteristics that CPython has
> been designed with for years, likely with a very large performance
> penalty.
Has it be
Le lundi 09 octobre 2006 à 12:49 +0200, Georg Brandl a écrit :
> They wouldn't be "local" unless declared with "var", I assume.
Which is a sure way to cause all kind of frigging bugs if you forget to
put "var", because then your variable is global, which is fine when it's
a plain int or string, n
Le vendredi 03 novembre 2006 à 15:19 -0600, Ka-Ping Yee a écrit :
> I suppose that's fine. Also i guess
>
> nonlocal x = y = 0
That's ambiguous.
Is only "x" nonlocal, or are both "x" and "y"?
What's the point anyway? if you write "nonlocal x = 0", it means you
aren't reusing the variable v
Le vendredi 03 novembre 2006 à 16:22 -0600, Ka-Ping Yee a écrit :
> Only x is nonlocal.
>
> nonlocal x = y = 0
>
> is equivalent to
>
> nonlocal x; x = y = 0
Perhaps, but the point is that it's non-intuitive from reading.
Just like the old "char * x, y" annoyance in C.
> The point is t
Le lundi 06 novembre 2006 à 14:37 -0800, Mike Orr a écrit :
> def __init__(klass, *args):
> if len(args) == 1 and isinstance(args[0], klass.path_class):
> self.path = args[0]
> else:
> self.path = self.path_class(*args)
s/klass/self/, I suppose ?
> Subc
Le jeudi 09 novembre 2006 à 20:45 +, Paul Moore a écrit :
> Again, I don't believe this is possible for all corner cases: what is
> the drive for /my/file on a Windows system?
Why not the current drive?
> If you mandate that all filenames must be relative, you could manage,
> but enforcing t
Le samedi 18 novembre 2006 à 22:42 -0700, Neil Toronto a écrit :
> Actually, plenty of people would dream of it and even do it. I've seen
> some pretty evil implementations of Java interfaces. All they can
> enforce is static types and method signatures.
But protecting against erroneous use (ra
Le dimanche 19 novembre 2006 à 12:44 -0500, George Sakkis a écrit :
> I understand this is not the point you're trying to make, but in such
> cases I usually prefer to make @decorator be equivalent to
> @decorator() by something like:
I could do that, but it's not very clean. Also it doesn't inva
Le mercredi 22 novembre 2006 à 11:52 -0800, Guido van Rossum a écrit :
> but how on earth is the defop syntax of the @defop decorator going to
> generate this? I can't see any way to implement it without having
> access to the class object, but that doesn't exist yet at the time
> defop or @defop
Le mercredi 22 novembre 2006 à 12:47 -0800, Guido van Rossum a écrit :
> > class DefOpDescriptor:
> > def __init__(self, genfunc, implfunc):
> > self.genfunc = genfunc
> > self.implfunc = implfunc
> > def __call__(self, *args, **kargs):
> > # Directly call the implem
Le samedi 25 novembre 2006 à 21:32 +0200, tomer filiba a écrit :
> "contract" is a better term, IMO, since it's already used in CS (as in
> Eiffel),
> and describes the situation more correctly: *behavior* rather than
> *signature*.
> "ability" just doesn't seem right to me: my class is not *abl
Le samedi 02 décembre 2006 à 13:58 -0700, Neil Toronto a écrit :
> One potential problem with this idea is that you can't drop into C code
> without calling an external C function, which may not be acceptable in
> some instances.
Are you sure ?
I think you could declare a C macro as an "externa
Hi,
Since there are discussions going on on the topic of allocation algorithms for
various built-in types, I thought I'd mention there's a patch for turning
unicode objects into variable-sized objects (rather than using a
separately-allocated buffer). The aim is to make allocation of those objects
Hi Jeffrey,
> I had thought that exc_info was
> automatically cleared at the end of any except block that caught an
> exception, but apparently that isn't the case. Is this a bug in 3.0,
> or do we need to keep sys.exc_clear() around?
The explanation seems to be that, while exc_info is cleared i
> The explanation seems to be that, while exc_info is cleared immediately, the
> thread state exception fields are only cleaned up at the end of
> PyEval_EvalFrameEx.
Patch and test in http://bugs.python.org/issue2507
___
Python-3000 mailing list
Pyth
Steve Howell yahoo.com> writes:
>
>line 673234: lambda cannot be renamed in ANY
> temporal dimension
>
[...]
>
>line 913975: parens not removed from print(),
> please use 3to4 converter instead
Mmmh... "3to2" was released on April 1st right ? :)
_
Michael Urman gmail.com> writes:
> The biggest concern I have is over whether the following works:
>
> for i, k in enumerate(d.keys()):
> if i % 2: del d[k]
>
Well:
Python 3.0a3+ (py3k, Mar 30 2008, 21:14:40)
[GCC 4.2.3 (4.2.3-5mnb1)] on linux2
Type "help", "copyright", "credits"
Gregory P. Smith krypto.org> writes:
>
> yes bytearray makes more sense to me given that its hard to read into an
immutable bytes object ;)
It seems to me that readinto accepts any object providing a writeable buffer
interface. I don't know how to express that as an annotation, though.
__
Christian wrote:
> > Make file objects as thread safe as the underlying libc FILE*
> > implementation.
> > close() will now raise an IOError if any operations on the file object
> > are currently in progress in other threads.
> >
> > Most code was written by
Greg Ewing canterbury.ac.nz> writes:
>
> It might not be a serious problem when most of the chars in
> the string are ascii, but what about e.g. a Japanese user
> whose strings consist almost entirely of non-ascii, but are
> for the most part what constitutes perfectly readable text
> to them? Th
Mark Dickinson gmail.com> writes:
> Fair enough. My twisted mind was trying to find ways that size_t
> might be something other than long or long long, but that
> seems unlikely...
There has been a report where sizeof(size_t) < sizeof(long). It breaks things in
the dict implementation:
http://bu
James Y Knight fuhm.net> writes:
> On Apr 16, 2008, at 11:00 PM, Greg Ewing wrote:
>
> > If a word is needed for this concept, then invent a new
> > one, e.g. "size unit", rather than reusing "byte", which
> > everyone already understands as meaning 8 bits.
>
> Nope. Everyone understands "octet"
Guido van Rossum python.org> writes:
>
> I'd like to get some more people trying out codereview.appspot.com, so
> I'm offering the first 10 people to submit a new patch there for my
> review to do the review by Monday.
I just tried to submit a patch using the Web form, and got a 500 Server Error
M.-A. Lemburg egenix.com> writes:
>
> It's all a matter of perspective. You can say you're encoding Latin-1
> to Unicode, or you can say your encoding Unicode to Latin-1.
Except that Latin-1 is an encoding while Unicode is not. So I don't see how you
can encode to Unicode. Of course you can enco
Le jeudi 22 mai 2008 à 10:55 -0700, Guido van Rossum a écrit :
> Hi folks,
>
> Is this thread reaching a conclusion yet? I am hoping I can soon
> accept some variant of the following:
>
> 1. repr() returns a Unicode string containing only printable Unicode
> characters, using \x\u\U escapes for c
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
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,
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
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
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.
>
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
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
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
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
Hello,
A patch is now at http://bugs.python.org/issue3021 .
Antoine.
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40ma
Collin Winter gmail.com> writes:
>
> See PEP 3109: http://www.python.org/dev/peps/pep-3109/
By the way, this document mentions a "raise ... from ..." form, but it doesn't
seem to me it has been implemented. Perhaps the document should be corrected?
Also, it doesn't mention the with_traceback()
Hello,
Along the discussion of issue 3021 (a patch for the exception nesting issues
already discussed here), Adam Olsen suggested I bring on this mailing-list
the subject of PEP 3134. Indeed, he remarked, the patch I proposed, by
implementing proper exception stacking, should make it relatively
Hello all,
> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently.
Perhaps it may happen more implicitly than people think. Especially
for methods like __bool__, __str__, __iter__...
Afte
Hi,
Georg Brandl gmx.net> writes:
>
> I would argue that the __enter__ and __exit__ behavior should be changed too.
> The reason for the current behavior is this:
>
[...]
>
> IOW, when "with" is compiled, the attributes are retrieved using bytecode.
> It wouldn't be hard to have a WITH_SETUP
Nick Coghlan gmail.com> writes:
> That said, the with statement implementation is already a bit different
> in 2.6/3.0 (it moves things around on the stack so it can avoid the
> STORE_FAST/LOAD_FAST/DELETE_FAST operations):
Hmm, check again with the current 3.0 - it has changed back to storing
Hello,
In the true spirit of the anti-code retention meme launched by Guido, I've
posted a patch implementing the implicit exception chaining part of PEP 3134.
The core functionality is there, but its consequences on exception reporting
are still non-existent (no funky multi-traceback exception m
Neil Schemenauer arctrix.com> writes:
> I wonder if it would make sense to start installing the Python
> standard library as a .zip file by default. Some benefits would be
> a tidier and more compact install and slightly faster startup times.
Are any users complaining about Python's install size
Hi,
I have implemented PEP 3134 exception reporting in
http://bugs.python.org/issue3112
The code is fully functional but it needs a final clean-up and that clean-up
is awaiting answers to the following questions:
1) API visibility: should we expose a function PyErr_DisplaySingle in order
to di
Hi,
I don't know who designed that API but what is the reason for
PyException_Set{Traceback,Cause,Context} not to INCREF their argument? It means
the caller has to do it himself, and seems inconsistent with most of Python's C
API. Is it too late to change those functions to do the right thing?
R
Hi,
I've submitted a final patch with the following variations:
- no additions or changes to public APIs
- tracebacks are standardized as suggested by Georg Brandl
- reference cycles along the __context__ chain are broken in PyErr_SetObject
(it is an O(n) linear search but should show almost z
Hello,
Several posters (including a certain GvR) in the bug tracker (*) have been
baffled by an apparent bug where the re.IGNORECASE flag didn't imply
case-insensitivity for non-ASCII characters. It turns out that, although the
pattern was a string object and although Py3k is supposed to be
unicod
1 - 100 of 161 matches
Mail list logo
