on, enabled only for people who need
many CPUs. (I've tried it myself, but never got past the weird
crashes. Probably missed something silly).
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.or
On 9/18/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Adam Olsen" <[EMAIL PROTECTED]> writes:
>
> > * Bolt-on tracing GC such as Boehm-Demers-Weiser. Totally unsupported
> > by the C standards and changes cache characteristics
On 9/18/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> 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
&g
On 9/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Adam Olsen]
> > I don't like the idea of a conservative GC at all in general, but
> > Boehm GC seems to have very good quality, and it's easy to use from
> > the point of view of a C API.
This was M
s to do some fun here. It
could look something like this:
Class Wrapper(Core):
def __init__(self, *args):
Core.__init__(self)
self.core.handle = CAPI.init(*args)
@coremethod
def __coredel__(core):
CAPI.close(core.handle)
def foo(self):
CAPI.fo
small.
* Grapheme clusters, words, lines, other groupings, do we need/want
ways to slice based on them too?
* Cheap slicing and concatenation (between O(1) and O(log(n))), do we
want to support them? Now would be the time.
--
Adam Olsen, aka Rhamphoryncus
___
P
On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
> > so far
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
> > so fa
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > Before we ca
On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> >
> > On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > >
> > > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
[sni
ards
> surrogates).
Wow, you really did mean code units. In that case I'm very tempted to
support UTF-8, with byte indexing (which is what code units are in its
case). It's ugly, but it technically works fine, and it's the de
facto standard on Linux. No more ugly than UTF-
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Wow, you really did mean code units. In that case I'm very tempted to
> > support UTF-8, with byte indexing (which is what code units are in i
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > Wow,
ny error handling can use traditional python
methods: a try/except wrapped around the operation that may fail.
TOOWTDI.
And yes, it does still require an event loop, but so does your
original javascript example; what do you think calls your callback?
--
Adam Olsen, aka Rhamphoryncus
_
I thought I read
that we should skip bug reports, but I've been unable to find the
email saying so.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
d be good idea to make
> their hash unequal too. So, what do you think?
It's irrelevant. It's always possible to get the same hashes. We'd
need a performance reason or the like to bother changing either of
them.
--
Adam Olsen, aka Rhamphoryncus
___
nsition
necessary for the existing developers.
The word "distributed" in DVCS is exaggerated anyway. You'll always need a
stable server to host public branches (as opposed to private ones, which can
just use your laptop's LAN ip address.)
The advantages related to merging a
resented, I'll review them and
> make a decision.
I can't speak for the others, but I know I've decided not to pursue it.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
gument applies to list literals. The only limitation I see
is whether or not calling hash() on urlext is considered an essential
part of the semantics - and I'm inclined to say "no".
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailin
On Jan 25, 2008 12:52 PM, Collin Winter <[EMAIL PROTECTED]> wrote:
>
> On Jan 24, 2008 10:40 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Jan 24, 2008 5:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > > Looking over the code base, frozensets
ot;x in (C1, C2)" might actually be a slight win since
> probing a tuple must be much faster than probing a set; but that's a
> detail.)
Given that "x in {1,2,3}" can be optimized just as well with mutable
sets (can somebody think of an example that can't?
't we add a windows equivalent of the shebang? Files could
then start like this:
#!/usr/bin/python2.3
#¡C:/python23/python
Of course, something better than ¡ needs to be chosen.
A problem with this approach is that, if you only had 2.3 and 2.5
installed, both
On Feb 5, 2008 10:57 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:43 AM 2/5/2008 -0700, Adam Olsen wrote:
> >So why don't we add a windows equivalent of the shebang? Files could
> >then start like this:
> >
> >#!/usr/bin/python2.3
> >#¡C:/
whatever the original type was, and this makes me
think we shouldn't encourage that coding style.
dict(iterable) for the one, and only one, obvious way to do it.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
Python-3000@python
eraction between __del__() and close() in the
> IOBase class. Maybe __del__() should just flush() instead of close()?
That'd rely on prompt deletion for correct behaviour. Why not an
explicit detach method?
buf = sys.stdout.buffer
sys.stdout.detach()
sys.stdout = io.TextIOWrapper
re yet well-named decorator, not
an obscure syntax that's difficult to get help on.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mai
herefor its methods) be shareable, and Monitor is the easiest
way to provide that.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
On Mon, Mar 17, 2008 at 1:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Guido's asked me to give a quick status report, so here I go..
> >
> > The critical parts of the d
On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
> <[EMAIL PROTECTED]> wrote:
> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
> >
> > > I&#
On Tue, Mar 18, 2008 at 10:15 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Adam Olsen schrieb:
>
>
> > On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> > <[EMAIL PROTECTED]> wrote:
> >> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowal
On Tue, Mar 18, 2008 at 1:13 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
>
>
> > If they need access to containing objects the only option is to use
> > the underlying tool, deathq
On Tue, Mar 18, 2008 at 2:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
>
>
> > What sort of blocking wait do you use? Or did you mean you don't have one?
>
> I meant that I
On Tue, Mar 18, 2008 at 4:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
>
>
> > The finalizer thread blocks until something's been deleted.
>
> Ok. If this is the only u
On Tue, Mar 18, 2008 at 4:52 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
>
>
> > Search for info on java's deprecated Thread.stop() if you're not
> > already familiar
On Tue, Mar 18, 2008 at 6:47 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > I'd tend to assume only *purely* functional languages should have
> > asynchronous interrupts. Any imperative language with them is
> > suspect.
>
> Yet there
ttp://mail.python.org/pipermail/python-3000/2008-January/011868.html
In certain contexts, such as "if i in {1, 2, 3}:", you can reuse the
literal regardless of whether it's a set or a frozenset. I don't know
if anybody has begun implementing that though.
Playing around a bit, I&
On Tue, Mar 25, 2008 at 2:11 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> ..
> > I worry that there might be generated code using disgustingly large
> > literals.
>
> I
On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It does not even have to be a frozenset. A set works just as well,
> > never modified by the produced byte
On Wed, Mar 26, 2008 at 9:18 AM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
> >
> > <[EMAIL PROTECTED]> wrote:
&
the special methods to their old lookup behaviour. I think that'd
be cleaner than providing a method to do it. Not sure how easy it'd
be to implement though.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
Python-3000@python
to cleanly exiting a thread, but I don't
think one is possible. You need some way to contain the insanity.
Using a process is one. Using a side-effect-free language is another.
Cancellation is a third option, and what I think will be the most
conveni
x27;m now calling it cancellable) conditions in my
monitors, which'd make it quite easy to implement cancellable Lock
objects.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.or
On Tue, Apr 8, 2008 at 4:46 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Killing threads at arbitrary points really is that dangerous.
>
> I'm not talking about killing an arbitrary thread, but
> a particular thread that I've designed with
both futile and unnecessary,
> as far as I can see.
Sure, *now*, but C inherited their definition from a day when it
wasn't so clear cut. It may be obsolete today, but good luck getting
them to change the standard.
--
Adam Olsen, aka Rhamphoryncus
___
x27;s one thing that's difficult to
> write with a for loop without a lot of verbosity (at least I couldn't figure
> out how to do it...).
>>> time = 1901248
>>> seconds = time % 60
>>> minutes = time // 60 % 60
>>> hours = time // 60 // 6
eads). Instead, maybe it should be removed because it's
trivial to reimplement as well as being overshadowed by all the other
event loops built into bigger systems (tk, qt, gtk, twisted, etc)?
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing li
re plenty of use cases to
> justify retaining sched in the library...!
Google's codesearch shows dozens of unique users, if not more. (And
just as many unrelated modules also called "sched"...)
Brett, has sched been discussed before, or is it the one excep
wouldn't be surprised if half the uses mistakenly
believe it's a thread-safe mutex. It's disturbingly common to see
them loop until .testandset() returns true (which will always be on
the first call, or never.) That method shouldn't exist. It's not
worth the effort of
you've decided to remove it from range.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
help PEP 3138. We'd
need a third function that applies to containers (like repr),
differing only in how it handles non-ascii. PEP 3138 already provides
a simple solution for this though: ascii_repr(). It's just not the
default repr().
--
Adam Olsen, aka Rhamphoryncus
__
the bare minimum, a per-thread
last_exception? That'd quickly get clobbered (we should intentionally
clear when leaving an except block), but is that ever a problem?
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
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
t;
> def f():
>try:
>raise KeyError
>except:
>handle_exception()
This can be rewritten to use sys.exc_info(), ie:
def handle_exception():
if user() == "Albert":
# Albert likes his exceptions uncooked
raise sys.exc_info()[1]
els
ne, None). But with rewritten
> exception
> stacking, it may return the 3-tuple for the TypeError raised in
> except_yield().
What exception stacking? I thought we'd be using a simple per-thread
exception. I'd expect the yield statement to clear it, giving us
(Non
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 Type
ing to stdout, have it fail
(encoding can't handle it), then get an exception printed to stderr
with the string escaped.
Making stderr stricter would make it unable to print the string and
making stdout less strict would let the error pass silently (printing
potential garbage instead).
--
A
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
> +1
It should be replaced with a function that returns only the value -
type and traceback are both redundant now. I don't think anything's
been proposed yet though.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
Python-3000@py
On Mon, Jun 2, 2008 at 9:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 8:16 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Mon, Jun 2, 2008 at 8:56 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
>>> On May 31, 2008, at 6:42 PM, Tim Dela
tion to a separate
> interpreter (with its own GIL) without the need to marshal data
> across processes?
You'd still need to marshal across threads, as well as the thread
switch cost, and much of the extra memory of a process (due to
duplicated python modules.) All you really save is th
on.
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.
Once genexps are fixed to do that then there's no reason not to make
listcomps match, which seems to be a goal here.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
;s no way for
> the list() constructor to know where the StopIteration is coming
> from.
It can be fixed in the genexp by declaring it erroneous and raising a
RuntimeError when encountered. The list() constructor will see the
RuntimeError instead, which will get propagated properly.
--
Adam
On Fri, Jul 11, 2008 at 7:10 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>>
>> However, since the genexp considers all improper ones to be in error,
>> it could wrap them with a RuntimeError and pass it through .next()
>> instead.
>
> Wou
al containers shouldn't support
len() at all. Maybe a .len() method instead, with all the TMTOWTDI
that implies.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-
nd is available under the BSD license,
> see below.
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. If you don't need unicode then your
code should state so explicitly,
On Mon, Sep 29, 2008 at 5:12 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> 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
>&g
in Python2 it was:
> * os.getcwd() -> str (bytes)
> * os.getcwdu() -> unicode
Why not do:
* os.getcwd() -> unicode
* posix.getcwdb() -> bytes
os gets the standard version and posix has an (unambiguously named)
platform-specific version.
--
Adam Olsen, aka Rhamp
filesystem encoding to be Latin-1" approach has a certain
> charm as well, but clearly would be a mistake on OSX, and probably on
> other systems too (whenever the user doesn't think in Latin-1).
Aye, it's a better hack than UTF-8b, but adding byte functions is even better
On Mon, Sep 29, 2008 at 5:14 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>> There's no solution except to not
>> decode, and 8859-1 is the way to do that.
>
> I think you need to elaborate that. What does ISO-8859-1 has to do
>
epresented? "In 8859-1"
> is not a valid answer, because you cannot derive an implementation
> from that answer (atleast, I cannot). Please explain.
Decoding UTF-8 using 8859-1 gives you garbage, but it's lossless and
reversible, and that's all a backup program would need.
--
On Mon, Sep 29, 2008 at 5:33 PM, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Sep 29, 2008, at 7:23 PM, Adam Olsen wrote:
>>
>> An ugly hack, but more correct than UTF-8b or any similar attempt to
>> do "unicode but not quite unicode"; either it's los
it lossy
decode for printing, while still keeping the internal file name as
bytes.
Failing outright does have the advantage that the resulting exception
should have a half-decent approximation of the bad filename. (Thanks
to the recent choices on unicode repr() and having stderr do escapes.)
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. If you
extend unicode then you're unable to display that extended name[1].
I think Guido's right on this one. If I have to choose between
On Tue, Sep 30, 2008 at 3:28 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> 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,
>> yo
On Tue, Sep 30, 2008 at 5:24 AM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Adam Olsen writes:
>
> > [1] You could argue that Unicode should add new scalars to handle all
> > currently invalid UTF-8 sequences.
>
> AFAIK there are about 2^31 of these, thou
actually leads to another problem: improving
validating will change what gets escaped and what doesn't.
http://bugs.python.org/issue3297
http://bugs.python.org/issue3672
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
Python-3000@py
names on Windows. So,
> it seems to me, converting invalid UTF-8 sequences into lone surrogates for
> Unix doesn't actually add any new form of brokenness. So why not just do
> that?
I see it the opposite: lone surrogates on windows should be rejected
from unicode APIs, just as we want
e
> name, although I've tried to break that habit in recent years...
Yup, U+ is unicode, but still can't be used with many external
APIs, as it's a transformation of the real file name. The only real
advantage is you can store it in certain external formats, but
wo
On Fri, Oct 3, 2008 at 5:02 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/3/2008 2:36 PM, came the following characters from the
> keyboard of Adam Olsen:
>>
>> UTF-8b produces an *invalid* unicode sequence, via lone scalars. Any
>> attem
On Fri, Oct 3, 2008 at 10:14 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/3/2008 4:54 PM, came the following characters from the
> keyboard of Adam Olsen:
>> On Fri, Oct 3, 2008 at 5:02 PM, Glenn Linderman <[EMAIL PROTECTED]>
>> wrote:
&g
On Mon, Oct 6, 2008 at 5:12 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/3/2008 11:57 PM, came the following characters from the
> keyboard of Adam Olsen:
>> On Fri, Oct 3, 2008 at 10:14 PM, Glenn Linderman <[EMAIL PROTECTED]>
>> wrote:
>&g
On Mon, Oct 6, 2008 at 11:23 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/6/2008 10:18 PM, came the following characters from the
> keyboard of Adam Olsen:
>> But "Unicode" on windows is invalid. It shares all the same problems
>> UTF-8b d
file name already using those PUA?
Looks like they get passed through untouched when decoded, but will
get translated into invalid names upon encoding. So you still have
file names you can't open, and you're incompatible with what other
libraries do.
The only thing going for Qt is that they s
skip file names, it turns out to be the least surprising and
least magical. Indeed, it's the only option that never fails while
listing directory contents!
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http
ecause of this.
The definition of PyObject_HEAD_INIT and PyVarObject_HEAD_INIT
changed. We've gone from a series of common fields to a single struct
containing the fields. With the series of fields using
PyObject_HEAD_INIT followed by a size was perfectly correct, but with
a struct it's g
On Fri, Nov 21, 2008 at 10:53 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-11-21 18:36, Adam Olsen wrote:
>> On Fri, Nov 21, 2008 at 7:14 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> On 2008-11-20 20:34, Roger Binns wrote:
>>>> M.
variable created by "except
Exception, exc" be special, perhaps not allowing any further
assignment to it or other limitations.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman
On 1/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> * Profiling
>
> + cProfile
> + profile
> + hotshot
> + pstats
Perhaps 'diagnostics' instead, with pdb thrown in? Hopefully there
will be more tools in the future.
look into it:
> It was rev. 53421, the merging of the long-int-unification branch.
long_richcompare doesn't Py_DECREF a and b allocated by CONVERT_BINOP.
This exists in 53421 (and presumably earlier) by doing "1L == 2L" at
the interpreter prompt. There might be another func
ire code points, but the unicode type will expose them as
code units, so it could be seen as both per-code-point and
per-code-unit.
To be really pedantic, neither of them are truly "per-character" in
unicode parlance, despite the fact that they store
ame semantics? Although long,
.nonblockflush() would be explicit and allow .flush() to still block.
I'm especially wary of infinite buffers. They allow a malicious peer
to consume all your memory, DoSing the process or even the whole box
if Linux's OOM killer doesn't
On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 3/1/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Why do non-blocking operations need to use the same methods when
> > they're clearly not the same semantics? Although long,
> > .nonblockflush() w
; rather than "push" mode. It's hard to see how this
> could fit into the model as a minor variation on
> how writes are done.
Meaning it needs to be a distinct interface and explicitly designed as such.
--
Adam Olsen, aka Rhamphoryncus
On 3/4/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/4/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
>
> > > .nonblockflush() would be fine with me, but I don't think .flush()
> > > sh
plication to apply the buffering layer to a
non-blocking socket, and not something related to a connection reset?
+1 on the rest
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailma
h in my own code.)
This seems to match what I've usually needed, but I'm not sure it's
worth putting in python proper. How about a cookbook entry? It would
also be nice to reference in a guide on making code 3.0-ready.
--
Adam Olsen, aka Rhamphoryncus
f the warnings:
http://sourceforge.net/tracker/index.php?func=detail&aid=1631035&group_id=5470&atid=305470
I have a patch for several more:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470
--
Adam Olsen, aka Rhamphoryncus
__
er needs to include a cell
> variable for the current class whenever it thinks you might be using super().
+1 on super(self).foo. It's SomeLongClassName we want to get rid of, not self.
As a bonus, super() and super(cls) have obvious semantics.
--
Adam Olsen, aka Rhamphoryncus
__
a bit of prior art in the "old way".
Besides correcting the stdlib, adding a warning when running a script
from a dir with __init__.py would help change the momentum.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
Python-3
() benchmark might be a better a better demonstration
of the overall costs.
--
Adam Olsen, aka Rhamphoryncus
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
1 - 100 of 141 matches
Mail list logo
