Josiah Carlson gmail.com> writes:
>
> From what I understand of the memoryview when I tried to do the same
> thing a few months ago (use memoryview to replace buffer in
> asyncore/asynchat), memoryview is incomplete. It didn't support
> character buffer slicing (you know, the 'offset' and 'size'
M.-A. Lemburg egenix.com> writes:
>
> The difference is that None is a singleton, so the set of all
> None type instances is {None}. You always have an intuitive total order
> relation on one element sets: the identity relation.
But it's not what you are asking for. You are asking for None to su
M.-A. Lemburg egenix.com> writes:
>
> >>> None > None
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: NoneType() > NoneType()
> >>> None != None
> False
>
> Two values that compare equal to each other (and are in fact identical),
> yet cannot be comp
M.-A. Lemburg egenix.com> writes:
>
> NULLs are a fact in life, not only in SQL, but also in numerics and
> statistics. You often don't want a complex calculation or query to
> fail just because a few input values are not available.
But it only works in the case where you only do comparisons, an
M.-A. Lemburg egenix.com> writes:
>
> Why was the special case for None being "smaller" than all other
> objects in Python removed from Python 3.0 ? (see object.c in Py2.x)
Because ordered comparisons (<, <=, >, >=) are much stricter in 3.0 than in 2.x.
In practice, ordered comparisons which do
Le mardi 07 octobre 2008 à 18:00 -0400, Barry Warsaw a écrit :
> On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:
> > 15-Oct-2008 3.0 rc 2
> > 05-Nov-2008 3.0 rc 3
> > 19-Nov-2008 3.0 rc 4
> > 03-Dec-2008 3.0 final
>
> I'm okay with that too. It does seem odd to go back to beta then
> re
Le mercredi 08 octobre 2008 à 00:00 +0200, "Martin v. Löwis" a écrit :
> You seem to think that the notion of "file system encoding"
> is also flawed - but do you infer from that that it also should be
> removed?
Under the condition we find something better, yes.
Otherwise, let's keep the heuristi
Guido van Rossum python.org> writes:
>
> I expect that the only effect of this change would be that the
> filesystem encoding would become the de-facto default encoding for
> other contexts as well.
But there is no such thing as "the" filesystem encoding (except in Python's
simplified heuristics
Hi,
James Y Knight fuhm.net> writes:
>
> - Having os.getcwdb isn't much use when you can't even run python in
> the first place when the current directory has "bad" bytes in it.
I don't agree it's a similar problem. Python should be installed in a well-known
place with a sensible path. Of
Stephen J. Turnbull sk.tsukuba.ac.jp> writes:
>
> It's usually not "hypothetical"; often, the user knows what it is.
> Why not ask her? That's what web browsers do, in effect, by providing
> View as Charset commands.
The average user does not even /know/ what a charset is.
Web browsers provide
Stephen J. Turnbull xemacs.org> writes:
>
> What makes you think the filenames are invalid? The file*names* are
> probably perfectly valid in the intended encoding; they are simply
> invalid in the encoding that Python wants to apply.
Those filenames don't work today with Python 3, the problem
Greg Ewing canterbury.ac.nz> writes:
>
> Seems like what will fail is taking one of these utf-8b
> decoded names and passing it to some external library
> that uses it as a filename without knowing that it has
> to use utf-8b to encode it. Then the funny characters
> won't be encoded the way they
Le mardi 30 septembre 2008 à 23:33 +0200, "Martin v. Löwis" a écrit :
> > By the way, doesn't all this controversy yearn for a PEP?
>
> There must be a solution for 3.0 (which *could* be "it's a bug,
> don't use Python 3.0 on such broken systems"); we can't wait for
> a PEP to resolve this issue f
Martin v. Löwis v.loewis.de> writes:
>
> True. I try to outweigh the need for simplicity in the API against the
> need to support all cases. So I see two solutions:
>
> a) (...)
>
> b) (...)
By the way, doesn't all this controversy yearn for a PEP?
__
Le lundi 29 septembre 2008 à 17:50 -0600, Adam Olsen a écrit :
> It's correct in the sense that it can roundtrip all filenames. UTF-8b
> is lossy, so certain filenames are not roundtripped properly.
Why do you say UTF-8b is lossy? From what I've read it claims to be
lossless (i.e. the range of ch
Adam Olsen gmail.com> writes:
>
> The only way to display that file would be to transform it into some
> other valid unicode string. However, as that string is already valid,
> you've just made any files named after it impossible to open.
Not if those valid sequences are also properly escaped t
Adam Olsen gmail.com> writes:
>
> UTF-8b doesn't work as intended. It produces an invalid unicode
> object (garbage surrogates) that cannot be used with external APIs or
> libraries that require unicode.
At least it works with all Python operations supported by the unicode type
(methods, concat
So what would be the outcome of this discussion, and should a decision (and
which one) be taken?
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python
> Gerhard suggested that if predictable
> ordering was desired that "order by rowid" would be better.
I personally don't understand what predictability brings (using a disk backend
implies that you should minimize queries, so using keys() then values() is
inefficient compared to using items() any
Josiah Carlson gmail.com> writes:
>
> While the wrapper for sqlite to offer
> a dbm-like interface is relatively untested (it does have testcases
> thanks to Skip), dealing with a couple-hundred (at most) line wrapper
> is far more reasonable for testing, verification, bugfixing, etc.,
> than the
Hello,
M.-A. Lemburg egenix.com> writes:
>
> It turned out that the patch only provides a marginal performance
> improvement, so the perceived main argument for the PyVarObject
> implementation doesn't turn out to be a real advantage.
Uh, while the results are not always overwhelming, they are
Nick Coghlan gmail.com> writes:
>
> Given that the *API* is fixed though, it is probably better to have the
> module present in 3.0 and bring it back to the main line in 2.7.
>
> If any absolute clangers from a performance/stability point of view get
> past Raymond (and everyone else with an int
Hello,
I thought I'd mention the following issue before it's too late to possibly fix
it in 3.0. Basically, os.write() accepts str as well as bytes object, which
doesn't sound right.
http://bugs.python.org/issue3782
Regards
Antoine.
___
Python-3000
Stefan Behnel behnel.de> writes:
>
> cdef class MyListSubType(PyListObject):
> cdef int some_additional_int_field
> cdef my_struct* some_struct
>
> def __init__(self):
> self.some_struct = get_the_struct_pointer(...)
> self.some_additional_int_
Stefan Behnel behnel.de> writes:
>
> From a Cython perspective, I find the lack of efficient subclassing after such
> a change particularly striking. That seriously bit me in Py2 when I tried
> making XML text content a bit more intelligent in lxml (i.e. make it remember
> what XML element it ori
Jeremy Kloth gmail.com> writes:
>
> I don't know if this is too late to do before the final release, but
> shouldn't
> the implementation of PyUnicodeObject be updated to match the much more
> efficient old PyStringObject layout? I mean eliminating the double malloc
> that is currently requi
Jesus Cea jcea.es> writes:
>
> First we had "thread.setDaemon()". This was not PEP8, so Python 3.0
> renamed it to "thread.set_daemon()". Lately Python 3.0 changes the
> method to an attribute "thread.daemon".
>
> I think the last change is risky, because you can mistype and create a
> new attri
Hi,
Just a bunch of simple statistics between the current py3k branch and the trunk.
Compilation was done with all default values (bare "./configure") on a Linux
machine with gcc, in non-debug mode.
The fact that 3.0 is measurably smaller than 2.6 (for various meanings of the
"size" metric) is n
Gregory P. Smith krypto.org> writes:
>
> http://bugs.python.org/issue3618 is a release blocker due to deadlock
> in the io library.
>
> and the related C RLock implementation in
[etc.]
By the way, please note using an RLock will just solve the deadlock bug. It
won't make the behaviour of write
Hello Nick,
> At some stage, we should probably put a simple type in the C API testing
> module that we can use to test some of the extra indexing and buffer
> interface features that aren't exercised within the standard library.
Yes, I think that's what we should do. The only problem is that ou
Hi,
Guido van Rossum python.org> writes:
> > 2394[Py3k] Finish the memoryview object implementation
> > - - High priority
> > - - This one is serious enough to hold up the release. I really do not
think we
> > should be finishing this implementation in the rc phase.
>
> Can someone review
Hi,
Would anybody object to the slight cleanup of the C PyMemoryView API that I
proposed in http://bugs.python.org/issue3560 ?
It's better to do this now before any third party extension starts relying on
it.
Regards
Antoine.
___
Python-3000 maili
Barry, could you please take a look at http://bugs.python.org/issue2834 ?
It's not marked as release blocker but if it doesn't integrate beta3 it will
probably not make it at all into 3.0 (unless you are fine with such a change
before an rc).
Thanks
Antoine.
___
Benjamin Peterson gmail.com> writes:
>
> Well, unless the parser decodes explicitly, I believe this should be true.
XML documents have an encoding declaration... the parser's should be able to
handle it, no?
Actually, I've just checked and ElementTree does support bytes input, including
with no
I took a look at test_sax and it seems sax.parser expects all (XML) input as
unicode rather than bytes. Apparently ElementTree does the same. Is there any
rationale for this decision?
cheers
Antoine.
___
Python-3000 mailing list
Python-3000@python.or
Le vendredi 15 août 2008 à 00:13 +0200, "Martin v. Löwis" a écrit :
> > Any thoughts?
>
> That is http://bugs.python.org/issue586680, right?
>
> As a work-around, test_cmd_line should set PYTHONPATH to include
> the build directory (i.e. what addbuilddir has added).
Thanks a lot for the suggesti
Christian Heimes cheimes.de> writes:
>
> Couldn't you use "from _thread import allocate_lock as Lock" instead?
I feel stupid for not thinking of such an obvious solution.
(by the way, is _thread always available?)
___
Python-3000 mailing list
Python-
Well, it looks like I underestimated the consequences of making io.py depend on
the threading module. Is it ok if I add itertools, operator, _collections and
time to the list of statically compiled modules? They are needed by threading,
and thus necessary for running setup.py on a blank checkout.
Hello,
I have a problem with "python -S". When python is launched from its build dir,
the extension build dir is not added to sys.path, and thus importing some
modules fails:
$ ./python -S -c "import threading"
Traceback (most recent call last):
File "", line 1, in
File "/home/antoine/py3k/p
Anand Balachandran Pillai gmail.com> writes:
>
> I think being able to send gzip compressed strings directly would be useful
> for applications which require to send gzip data over the wire without
> having to write to files and read-back.
I also think gzip.compress() and gzip.decompress() would
Amaury Forgeot d'Arc gmail.com> writes:
>
> I corrected this with r65341.
> But this prebuilt MemoryError has another nasty consequence:
> when PyErr_NoMemory is raised, the traceback is attached to the
> prebuilt object,
> and all local variables of the failing procedure are still referenced
> a
Guido van Rossum python.org> writes:
>
> FWIW, are there any legitimate occurrences of OverflowError in Py3k
> now that ints have unlimited range?
Legitimate:
>>> n = 2 ** 16384
>>> float(n)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Python int too large to convert
Hi,
> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value')" needs to be changed to
> "db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
> similar.
Why not "db.put(b'key', b'value')"?
> This is ugly and generates in
Hi,
There is an uncertainty in the signature for RawIOBase.read().
PEP 3116 says:
read(n: int) -> bytes
but current io.py says:
def read(self, n: int = -1) -> bytes:
Is omitting the `n` parameter always supported by RawIOBase implementations?
(meaning: read up to the end)
Regards
Anto
Hi,
I've posted my final patch to adapt the re module to the py3k standards of
bytes/unicode separation.
Here is a short summary of the changes:
- mixing bytes and str patterns, search and replacement strings raises a
TypeError
- re.UNICODE and (?u) become almost no-ops: they are the default for
Hi,
Georg Brandl gmx.net> writes:
> * 3134 -- exception chaining
There are few things to correct/clean up:
(1) The "C API" paragraph contains incorrect information:
- the sentence "The PyErr_Set* calls for setting exceptions will not set the
'__context__' attribute on exceptions" is wrong. T
Hi,
it would be nice if someone could take a look at the patch for issue 2523. Right
now it takes py3k 30 seconds at 100% CPU to read a 10MB binary file.
Thanks
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mail
Hi,
Barry Warsaw python.org> writes:
> But 3139 appears important enough to hold up beta 2.
>
> http://bugs.python.org/issue3139
> bytearrays are not thread safe
>
> Can we get this fixed by tomorrow? Does anybody disagree that we
> should hold up the release for this one? We don't have mu
Hey,
My previous mail to the list apparently lost itself somewhere...
> > I can do that for you. OTOH, I think it's time we gave Antoine commit
> > access; we've gotten nothing but great things out of him so far. :)
>
> Antoine just needs to ask himself and someone who knows how to add
> commit
Hi,
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
> tomorrow. I will try to hang out on #python-dev today and will start
> looking at the trackers and buildbots. Hopefully, we're on track to
> get the releases out!
In http://codereview.appspot.com/2448 (PEP 3134 e
I would like to say that the patch is ready for review here:
http://codereview.appspot.com/2448
And the corresponding issue: http://bugs.python.org/issue3112
It's probably a bit short for inclusion in beta2, although it would be nice to
exercise it in the wild before it's too late... Right now w
Greg Ewing canterbury.ac.nz> writes:
>
> This seems like a lot of trouble to go to in order to
> fix a rather obscure problem. Is it really a serious
> enough problem in practice? Anyone have any real-life
> stories about this?
Agreed. I think it is ok for some behaviours to be unspecified and s
Carl Johnson carlsensei.com> writes:
>
> However, it can be argued that in Python 3 list comprehensions should be
> thought of as "syntatic sugar" for ``list(generator expression)`` not a
> for-loop with an accumulator. (This seems to be the motivation for no
> longer "leaking" variables from lis
Hello,
> I know it's good to follow the release plan, but it
> also may save you, the release manager, work for the third beta (which
> I think will be necessary if beta2 is released tomorrow).
Yes, there are a lot of things remaining to do before Python 3.0 is sufficiently
polished. For example
Another question, about re.LOCALE. Its utility is dubious, and it's never used
in the stdlib (apart from the re tests themselves). What should we do:
- drop it entirely
- only allow it on bytes patterns (it doesn't make sense on unicode strings)
- leave it as-is
?
Mark Dickinson gmail.com> writes:
>
> In any case, it seems to me that having something like re.ASCII
> would be useful.
Should an inline flag "(?a)" also be introduced to mirror the existing "(?u)" to
set the unicode flag inside a pattern?
___
Pyth
Mark Dickinson gmail.com> writes:
>
> Is there a quick way to convert a general Unicode digit to its
> ascii equivalent? Having to run str(int(c)) on each numeric character
> sounds painful, and the Decimal constructor doesn't need to
> be any slower right now.
In C it looks like PyUnicode_Enco
Le dimanche 29 juin 2008 à 12:05 +0100, Mark Dickinson a écrit :
> Might this have some unintended consequences? For example, one
> would then get the following undesirable behaviour from the decimal
> module, using inputs with Unicode fullwidth digits.
>
> >>> Decimal('\uff11')
> Decimal('１')
>
Nick Coghlan gmail.com> writes:
> > Would there be any reason (I do not know) to replace that with an
> > re.ASCII flag to have the reverse effect (assuming there is not now)?
>
> I'd be inclined to have it implied by the type of the argument - a str
> argument implies re.UNICODE is set, a byte
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
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
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 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
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
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
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
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
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
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
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,
A patch is now at http://bugs.python.org/issue3021 .
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40ma
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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"
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
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
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
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.
__
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"
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 ? :)
_
> 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
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
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,
> Plus I am only a single person and I know that my opinion does not
> always mesh with everyone else out there (there is a reason why most
> of my PEPs end up being heavily cut back =) . So I am asking anyone
> who is interested in helping me out with this to reply to this thread.
I might
FWIW and in light of the thread on removing __del__ from the language, I
just posted Yet Another Recipe for automatic finalization:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621
It allows writing a finalizer as a single __finalize__ method, at the
cost of explicitly calling an en
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
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 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 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
1 - 100 of 161 matches
Mail list logo
