inding real use cases and
exploring how best to solve them. Otherwise we might as well throw in
my OrderedSet[1] as-is, despite that it's got no comments and no
ratings. Even I don't seem to use it.
Everybody has an opinion on the colour of this bike
On Thu, Jun 19, 2008 at 3:23 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti
>> <[EMAIL PROTECTED]> wrote:
>>> Would a
rt: the gc is tuned for typical usage. If your usage of python
> is specific,
> use gc.set_threshold and increase its values.
For very large bursts of allocation, tuning is no different from
disabling it outright, and disabling is simpler/more reliable.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t getting traced. We could also tweak when in the object
life-cycle "pending" is increased.
The first two generations would remain as they are today.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
On Sat, Jun 28, 2008 at 12:47 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>>
>> We need two counters: one is the total number of traceable objects
>> (those we would inspect if we did a full collection) and a number of
>> &qu
;d probably don't want the full
collection pauses except from big bursts, which is trivially done by
making the deleted factor 0.0. My original proposal was assuming a
non-zero deleted factor, while yours (and the existing codebase)
assumed it'd be zero - this is how our two proposals
> while 1:
> x=[]
>
> trigger a full garbage collection fairly quickly?
"deleted" means deallocated survivors.
I could imagine wanting to move survivors and deleted up to the first
generation, to give a stronger guarantee of how often it'd run, but
that'd require a mu
t is an intriguing thought nevertheless. The module clearing
> causes nothing but trouble...
Already gone in python-safethread. Then again, so is __del__. ;)
(Replaced with __finalize__)
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
bage collection.
>
> Also, why would you want to move deleted objects anywhere? Their
> storage is reclaimed, and they don't occur in any list of objects.
Sorry, really poor wording on my part. I meant to move the
*counters*, so that even the first generation qualifies as a
"surv
y
> valid Unicode code points, nevertheless. Just as a lone combining
> code point is valid on its own.
That is a big part of these problems. For all practical purposes, a
surrogate is like a UTF-8 code unit, and must be handled the same way,
so why th
On Thu, Jul 3, 2008 at 11:35 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080703 19:21], Adam Olsen ([EMAIL PROTECTED]) wrote:
>>On Thu, Jul 3, 2008 at 7:57 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> Please remember that lone surrogate
builds as a matter of purity even though
> on it would be time-costly on 16-bit builds as a matter of practicality.
Wrong term - code units and code points are equivalent in UTF-16 and
UTF-32. What you're looking for is unicode scalar values.
--
Adam Olsen, aka Rhamphoryncus
_
On Thu, Jul 3, 2008 at 4:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 3, 2008 at 3:00 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Thu, Jul 3, 2008 at 3:01 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>>
>>> The premise is the OP
fix it". The stdlib is definitely broken if it raises
> warnings of that kind.
Is the stdlib broken or is it the warnings that are broken? The code
is just fine in 2.6. Adding pragmas to disable warnings would be just
fine. Or we could hardcode some warnings as "already seen".
silenced so as to not risk breaking backwards-compatibility?
Just silence them. The warnings are an aid for finding bugs, not an
excuse to create more bugs.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
hould expect weakrefs to be cleared at random
points, and code defensively.
One approach I've used before is to enqueue all the cleared weakrefs,
then process that queue when the WeakKeyDictionary is modified.
--
Adam Olsen, aka Rhamphoryncus
___
Pyth
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 Rha
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 bet
just moves around what gets treated as garbage. As
all valid unicode scalars can be round tripped, there's no way to
create a valid unicode file name without being lossy. The alternative
is not be valid unicode, but since we can't use such objects with
external libs,
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 betw
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
em of how to turn it on. I'm against
automatically Python changing the filesystem encoding, no matter how
well intentioned. Better to let the app do that, which is easy and
could be done for all apps (not just python!) if someone defined a
libc encoding of "null-escaped UTF-8".
O
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-Dev mailing list
Python-Dev@python.org
hon.org/3.0/
>
> We already have archived versioned docs at http://www.python.org/doc/X.Y.
Why not use versioned URLs, but with a link at the top of old pages
saying they're outdated, linking to the new version. Either way they
should update their li
ut this way you don't shoot them in the
>> foot to do it.
>
> Wouldn't that require changes to the old pages?
Hopefully just to whatever common templating they're using. I'm not
familiar with how they're generated though.
--
Adam Olsen, aka Rhamphoryncus
__
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
To clarify: This is *NOT* actually a form of threading, is it? It
"merely" breaks the giant dispatch table into a series of small ones,
while also grouping instructions into larger superinstructions? OS
threads are not touched at any point?
--
A
r non-core code is invoked.
Ahh, or do it per object! Convert the core to use a precise GC
references, but retain the refcount API as a sort of forced unknown
reference. Needs bodging to retain our current handling of cycles in
refcounted objects, but it
On Fri, Oct 31, 2008 at 2:11 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>> Neil Schemenauer wrote:
>>>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> w
askfibreropebobprocess is a little
too long for normal use, so I'm gonna keep calling it thread (and to
distinguish it from an OS process).
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
run under Jython or IronPython everyone once in a while.
I've considered making files issue a warning if they've got buffered
writes and they're not explicitly closed. Although my feeling is a
read-only file should produce the same warning, there's sit
ouldn't have the option of doing that. I'd be disappointed
> if that meant I could no longer use Python for these kinds of
> games.
I consider realtime games to be an essential use case and will be
pursuing incremental GC with my experiments.
--
Adam Olsen, aka Rhamphoryncus
___
ethod?
>
> Both are awkward on numeric types in python, necessitating brackets or a
> space before the dot:
>
> (1).__doc__
> 1 .__doc__
It's only awkward on constants, which should be pretty rare for a
numbits property. The expected u
er all classes that might appear them.
> Showing the class name would solve this problem and could save a lot
> of time.
I'm sure you'll get support for this, unless it's a really
inconvenient spot that requires a gross hack to print the type name.
Post a patch on the bug tr
f controlling the environment given to a subprocess
requires os.environb, but it may be too obscure to really matter.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Thu, Dec 4, 2008 at 2:09 PM, André Malo <[EMAIL PROTECTED]> wrote:
> * Adam Olsen wrote:
>> On Thu, Dec 4, 2008 at 1:02 PM, Toshio Kuratomi <[EMAIL PROTECTED]>
> wrote:
>> > I opened up bug http://bugs.python.org/issue4006 a while ago and it was
>> > s
greed solution, but it wasn't considered a common
> enough issue to delay the release of 3.0 until all of those parallel
> APIs had been implemented
Aye. IMO it's fairly clear that os.getenv()/os.putenv() should follow
suit in 3.1. I'm not so sure about adding os.env
On Thu, Dec 4, 2008 at 3:47 PM, André Malo <[EMAIL PROTECTED]> wrote:
> * Adam Olsen wrote:
>
>> On Thu, Dec 4, 2008 at 2:09 PM, André Malo <[EMAIL PROTECTED]> wrote:
>
>> > Here's an example which will become popular soon, I guess: CGI scripts
>> &g
nd trip correctly at some point or
another. They're simply about shuffling the failure around to
somewhere the poster happens to like.
Please, if you have a *new* idea that doesn't have a failure mode, by
all means post it. But don't resurrect a pointless bikeshed.
--
Adam Olsen
n't happen very often in practice, as having
only one encoding makes it quite clear that it's a broken file name,
not a mixed encoding environment.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
;s not valid. So, it works fine as an escape character. It can
> round-trip perfectly.
The failure is more subtle, in that a path from the filesystem cannot
round trip via a different return path. i.e. list the dir via python,
pass it to an external lib
ers on various Unix systems except OSX (which uses UTF8 for
> its filesystems), and perhaps the occasional developer on OSX whose
> app needs to work with files on mounted filesystems that use a
> different encoding.
--
Adam Olsen, aka Rhamphoryncus
_
ter is a
bikeshed.
Not only that, but we already have a solution that makes the choice
explicit, avoiding the subtle failure. This is the solution already
in use for os file & path functions. It's the solution Guido
supports.
--
Adam Olsen, aka Rhamphoryncus
ing UTF-8, since that should be able to encode
> anything the Unicode APIs can handle.
If the Unicode APIs only have correct unicode, sure. If not you'll
get errors translating to UTF-8 (and the byte APIs are supposed to
pass bad names through unaltered.) Kinda ironic, no?
--
Adam Ols
gs.python.org/issue3672
http://bugs.python.org/issue3297
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
8 for the binary API would not be the place to enforce it.
No. Unicode *requires* them to be treated as errors. If you want to
pass them through then you're creating a custom encoding... which you
might argue for in this case, but it needs to be clearly separate from
the real UTF-8.
--
Ad
On Sun, Dec 7, 2008 at 11:18 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 11:35, Adam Olsen <[EMAIL PROTECTED]> wrote:
>>>> http://bugs.python.org/issue3672
>>>> http://bugs.python.org/issue3297
>>
>> No. Unicode *requ
checked it in UTF-8, then passed
it to python. It would be nice if the library validated too, but a
major advantage of UTF-8 is older libraries (or protocols!) intended
for ASCII need only be 8-bit clean to be repurposed for UTF-8. Their
security checks continue to work, so long as nobody down
On Sun, Dec 7, 2008 at 11:04 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 12/7/2008 9:11 PM, came the following characters from the
> keyboard of Adam Olsen:
>> On Sun, Dec 7, 2008 at 9:45 PM, Glenn Linderman <[EMAIL PROTECTED]>
>> wrote:
>
e a type that can store an
arbitrary mix of unicode and bytes, so the undecodable portions stay
in their original form. :P
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
x27;)? I'm +1 on making that work.
> * a warning error handler that replaces the problem cases with
> a question mark and issues a warning through the warning
> framework
I dub thee errors='warnreplace'.
--
Adam Olsen, aka Rhamphoryncus
oes it crash. Seems like the
>> best compromise with the broken nature of the real world IT
>> environment.
>
> OK, I can live with that too.
+1
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://
On Mon, Dec 8, 2008 at 2:44 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-12-08 22:32, Adam Olsen wrote:
>> On Mon, Dec 8, 2008 at 2:01 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> On 2008-12-08 21:45, Antoine Pitrou wrote:
>>>> M.-
On Tue, Dec 9, 2008 at 11:31 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> On Monday 08 December 2008, Adam Olsen wrote:
>> At this point someone suggests we have a type that can store an
>> arbitrary mix of unicode and bytes, so the undecodable portions stay
>>
s that may be used with it.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Dec 10, 2008 at 3:39 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> On Tuesday 09 December 2008, Adam Olsen wrote:
>> The only thing separating this from a bikeshed discussion is that a
>> bikeshed has many equally good solutions, while we have no good
>> solut
use it on certain supported platforms,
and probably disable it by default anyway (configure option? Not
sure). Still, it'd be useful to have it there.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http:
ns like
> those, recovering would be likely (caveat emptor of course).
The only safe option there is a subprocess.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
in R.
>
> It may, however, be better to move further discussion to the tracker
> (I understand that the patch is at
> <http://bugs.python.org/issue3999>).
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
bytes APIs that return
raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
unicode, despite being much more likely than on linux). The only real
issue I see is that UTF-16 isn't an ASCII superset, so it won't print
nicely.
In other words, bytes can be your
hile printing the first.
Just think about how indirect refcounting bugs tend to be. Another
example is messing up GIL handling. There's heaps of things for which
we'd want good stack traces, which can't be done from Python.
--
Adam Olsen, aka Rhamphoryncus
___
ase, as a user, if your app is creating new files, do NOT use
bytes! You have no excuse for creating garbage, and garbage doesn't
help the user any. Getting the encoding right, use the unicode APIs,
and don't pass the buck on to everything else.
The fact that the unicode is easier is a bo
On Thu, Dec 11, 2008 at 10:41 PM, Toshio Kuratomi wrote:
> Adam Olsen wrote:
>> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
>> wrote:
>>> Unfortunately, even programmers experienced in I18N like Martin, and
>>> those with intuition-that-has-the-for
On Thu, Dec 11, 2008 at 10:22 PM, Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
> wrote:
>> Unfortunately, even programmers experienced in I18N like Martin, and
>> those with intuition-that-has-the-force-of-law like Guido,
>> express deliberate
On Thu, Dec 11, 2008 at 11:25 PM, Curt Hagenlocher wrote:
> On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen wrote:
>>
>> I doubt that UTF-16 is used very much (other than on windows).
>
> There's this other obscure platform called "Java"... ;)
Sorry,
On Fri, Dec 12, 2008 at 12:33 AM, Toshio Kuratomi wrote:
> Adam Olsen wrote:
>> As a data point, firefox (when pointed at my home dir) DOES skip over
>> garbage files.
>>
>>
> That's not true. However, it looks like Firefox is actually broken.
> Take a l
On Fri, Dec 12, 2008 at 1:31 AM, Ulrich Eckhardt
wrote:
> On Thursday 11 December 2008, Adam Olsen wrote:
>> The simplest solution there is to have windows bytes APIs that return
>> raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
>> unicode, despite being
On Fri, Dec 12, 2008 at 2:11 AM, André Malo wrote:
> * Adam Olsen wrote:
>
>> UTF-8 in percent encodings is becoming a defacto standard. Otherwise
>> the browser has to display the percent escapes in the address bar,
>> rather than the intended text.
>
> Duh! The
On Fri, Dec 12, 2008 at 9:47 PM, André Malo wrote:
> * Adam Olsen wrote:
>> On Fri, Dec 12, 2008 at 2:11 AM, André Malo wrote:
>> > * Adam Olsen wrote:
>> >> UTF-8 in percent encodings is becoming a defacto standard. Otherwise
>> >> the browser has to
confident that there
> are no loops in this dict, and nothing for cyclic gc to collect.
Try putting an explicit gc.collect() at the end, with the usual
timestamps before and after.
After that try deleting your dict, then calling gc.collect(), with
timesta
That might mean that there are a lot of passes through
> this loop per free (i.e., that gdb is taking a long time to process
> 100,000 silent breaks), or perhaps I've made a mistake, or gdb isn't
> handling this well.
To make sure that's the correct
deas
> on how to systematically find types which are defined in the core, but
> are missing an explicit PyType_Ready call? (I guess one way would be to
> remove all the implicit calls in a local build and see what blows up...
> that seems a little drastic though)
What I did with safethread w
d a few standard modules.
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy you into using them. We won't be using them, and
the extra casts and nothing but noise. Figure out a way to turn off
the warnings instead.
http://www.research.att.com/~bs/b
On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
wrote:
> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen wrote:
> ..
>>
>> As C++ has more specific ways of allocating memory, they impose this
>> restriction to annoy you into using them.
>
> And so does
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg wrote:
> On 2009-01-02 08:26, Adam Olsen wrote:
>> Python's malloc wrappers are pretty messy. Of your examples, only
>> unicode->str isn't obvious what the result is, as the rest are local
>> to that function. Even
n the file will be
>> closed; its up to the GC implementation details. Good code should never
>> depend on the GC for a timely release of scarce external resources (file
>> descriptors/handles).
>
> And buffer flushing. While I don't want to guarantee that the bu
help if the file repr gave the encoding:
>>> f = open('/dev/null')
>>> f
>>> import sys
>>> sys.stdout
Of course I can check .encoding manually, but it needs to be more intuitive.
--
Adam Olsen, aka Rhamphoryncus
/unicode if it's only ascii values, switching
to a list of hex literals if there's any non-ascii values
3. b"foo" literal with ascii for all ascii characters (other than \
and "), \xFF for individual characters that aren't ascii
Given the choice I prefer the thir
On 2/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > What would that imply for repr()? To support eval(repr(x))
>
> I don't think eval(repr(x)) needs to be supported for the bytes
> type. However, if that is desirable, it sho
, openbinary()
-1 on silently changing open() in a way that results in breakage
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
is these would become errors in 3.x. bytes(str) is only
needed so you can do bytes(u"abc".encode('utf-8')) and have it work in
2.x and 3.x.
(I wonder if maybe they should be an error in 2.x as well. Source
encoding is for unicode literals, not str literals.)
--
Adam Ols
On 2/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/14/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > In 3.0 it changes to:
> > "It's...".encode('utf-8')
> > u"It's...".byteencode('utf-8') # Same as abo
On 2/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/13/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > If I understand correctly there's three main candidates:
> > 1. Direct copying to str in 2.x, pretending it's latin-1 in unicode in 3.x
>
> I
Although I'm not arguing for or against byte literals. They do make
for a much terser form, but they're not strictly necessary.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
On 2/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > (I wonder if maybe they should be an error in 2.x as well. Source
> > encoding is for unicode literals, not str literals.)
>
> Source encoding applies to the entire source cod
an array and has variable size.
In any case we already have the struct module:
>>> import struct
>>> struct.calcsize('l')
4
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Making it an error to have 8-bit str literals in 2.x would help
> > educate the user that they will change behavior in 3.0 and not be
> > 8-bit str literals anymore.
>
> You
ation Strings -> Documentation Text
String Pattern Matching -> Text Pattern Matching
String Services -> Text Services. Actually this is a problem. struct
should be used on bytes, not unicode/text.
textwrap -> textwrap
stringprep -> textprep? Doesn't seem like a descriptive
looks like it wouldn't be hard to implement. It could
> be a builtin named defaultdict. The first, required, argument to the
> constructor should be the default value. Remaining arguments (even
> keyword args) are passed unchanged to the dict constructor.
-1 (atleast until
no such problems and has a much simpler specification:
def getorset(self, key, func):
try:
return self[key]
except KeyError:
value = self[key] = func()
return value
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's also makes it harder to read code. You may expect d[key] to
> > raise an exception, but it won't because of a single line up several
&
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Still -1. It's better, but it violates the principle of encapsulation
> > by mixing how-you-use-it state with what-it-stores state. In doing
> > that it has the potential
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > You could pass a float in as well. But if the function is documented
> > as taking a dict, and the programmer expects a dict.. that now has to
> > be changed to "dict
we add another module
> for text->text transforms? Would it start having names like t2e_rot13()
> and e2t_rot13()?
If top-level modules are the problem then why not make codecs into a package?
from codecs import utf8, base64
utf8.encode(u) -> b
utf8.decode(b) -> u
base64.encod
_ dict prevents.
It just occured to me, what affect does this have on repr? Does it
attempt to store the default_factory in the representation, or does it
remove it? Is it even possible to store a reference to a builtin such
as list and have eval restore it?
--
Adam Olsen, aka Rhamphoryncus
torset(key, func) would work in your use cases?
> Those of you arguing something different: do you have a real use case
> (that you've implemented in real code)?
(again, for the record) getorset provides the minimum needed
functionality in a clean and intuitive way. Why go for a compl
On 2/20/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Adam Olsen asked:
> > ... d.getorset(key, func) would work in your use cases?
>
> It is an improvement over setdefault, because it doesn't
> always evaluate the expensive func. (But why should every
> call have
se multiple CPUs if you need to.
References:
[0]
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
ture.
For example, with Greenlets you would use the .switch() method of a
specific greenlet instance to switch to it, and with my python-native
threads you would use the global idle() function which would decide
for itself which thread to switch to.
--
Adam Olsen,
101 - 200 of 230 matches
Mail list logo
