protocol, and it more
often than not specifies (perhaps not in English words, but
only in the source code of the generator) that the default should
by LE.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
#x27;t do that, then.
Regards,
Martin
___
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
Skip Montanaro wrote:
> Martin> Yet, this *still* is a platform dependence. Python makes no
> Martin> guarantee that 1e1000 is a supported float literal on any
> Martin> platform, and indeed, on your platform, 1e1000 is not supported
> Martin> on your platf
suppress sharing if an application needs to suppress it for
backwards compatibility.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
Nick Coghlan wrote:
> Are context diffs still favoured for patches?
Just for the record: I also prefer unified over context diffs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
s before. If I
knew a solution, it were applied to Python already.
Please understand that this perhaps hostile-sounding response is just
my personal view; if somebody else responds more gracefully, just
ignore me.
Regards,
Martin
___
Python-Dev ma
Irmen de Jong wrote:
> Please advise?
setup.py should refer to config_h_vars, which in turn should be set earlier.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
Greg Ewing wrote:
> Wouldn't this mean you're only solving half the problem?
> Unpickling a Numeric array this way would still use an
> intermediate string.
Precisely my concern.
Martin
___
Python-Dev mailing list
Python-
e passed to the compiler when compiling
with --enable-shared. It is set in configure.in.
It might be reasonable to add a variable that will just take additional
compiler flags, and never be modified in configure.
Regards,
Martin
___
Python-Dev mailing li
Brett C. wrote:
> The other option is to not make configure.in skip injecting arguments when a
> pydebug build is done based on whether OPT is defined in the environment. So
> configure.in:670 could change to ``OPT="$OPT -g -Wall -Wstrict-prototypes"``.
That's a procedural question: do we want to
not use -O3 but, say, -O1. I don't think there
is much point in allowing OPT to be extended. But then, it is already
possible to override OPT (when invoking make), which might be enough
control.
Regards,
Martin
___
Python-Dev mailing list
Python-
shell when the Makefile is running?).
If you put it into Makefile.pre.in, the only thing to avoid that
configure evaluates is is not to use @[EMAIL PROTECTED] OTOH, putting a $
in front of it is not good enough for make: $EXTRA_CFLAGS evaluates
the variable E, and then appends XT
gt; say yes.
You means sysconfig.py, right? Probably yes.
This is a mess. distutils should just do what Makefile does for builtin
modules, i.e. use CFLAGS from the Makefile. Instead, it supports CFLAGS
as being additive to the Makefile value CFLAGS, which in turn it just
*knows* $(BASECFLAGS) $
Brett C. wrote:
>>You means sysconfig.py, right?
Right.
> No, I mean Python's setup.py; line 174.
Ah, ok.
> You mean Distutils' sysconfig, right? I can change that as well if you want.
Please do; otherwise, people might see strange eff
Brett C. wrote:
> OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and
> distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way
> you wanted.
It is the way I wanted it, but it doesn't work. Just try and use it for
some extension modules to se
to _localemodule.c)
are welcome, independent of whether they are removed from the methods
on Unicode objects. Such functions should probably polymorphically
operate both on byte strings and Unicode strings, allowing to deprecate
the locale-specific methods on st
ons:
fn()
atexit.register(_run)
def register(fn):
allregistrations.append(fn)
def unregister(fn):
allregistrations.remove(fn)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Ugo Di Girolamo wrote:
> What am I doing wrong?
This is not the forum to ask this question, please use
python-list@python.org instead.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
_UNICODE_TYPE
Py_UNICODE* data = (Py_UNICODE*) my_data;
do_free=0;
#else
Py_UNICODE* data = malloc(sizeof(Py_UNICODE)*my_data_len);
for(int i=0;i<=my_data_len)
data[i] = my_data[i];
do_free=1;
#endif
PyObject *uni = PyUnicode_FromUnicode(data);
if(do_fr
t to know "Is Python's Unicode 16-bit or 32-bit?"
So the documentation should explicitly say "it depends".
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
be available on Windows.
I haven't check whether VC 7.1 provides them, and if it doesn't,
somebody would have to provide a "direct" implementation.
I'd say "contributions are welcome".
Regards,
Martin
___
Python-Dev m
print line.rstrip()
after locking(myLock):
# code that needs to hold the lock
Regards,
Martin
___
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
; the internal representation is.
Why is that? Of *course* people will have to manipulate Py_UNICODE*
buffers directly. What else can they use?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
r surrogate
characters (e.g. in UTF-8 codec), so it is not "pure" UCS-2, but
this is a minor issue.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
need different background, especially if they are
writing different applications.
Regards,
Martin
___
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
option mean?
It tells you whether you have the two-octet form of the Universal
Character Set, or the four-octet form.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
be saying that this isn't true.
It's a compile-time option (as all configure options). So at run-time,
it isn't variable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
ise, Python will default to UCS-2.
Regards,
Martin
___
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
M.-A. Lemburg wrote:
> Hmm, looking at the configure.in script, it seems you're right.
> I wonder why this weird dependency on TCL was added.
If Python is configured for UCS-2, and Tcl for UCS-4, then
Tkinter would not work out of the box. Hence the weird dependency.
Rega
efficient
implementation isn't possible. If you want "safe" indexing and slicing,
you need ucs4.
Regards,
Martin
___
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
"I couldn't transcode this" UCS-2
> code point (I don't remember which on that is off the top of my head).
OTOH, if Python really supported UTF-16, then unichr(0x1) would
work, and len(u"\U0001") would be 1.
It is primarily just the UTF-8
only sizeof(Py_UNICODE) changes, but also
the names of all symbols change.
Regards,
Martin
___
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
e latter. PEP 261 specifies what should
and shouldn't work.
Regards,
Martin
___
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
vide value, there are good reasons for each setting. Which
of the two alternatives do you consider useless?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
um value.
With --enable-unicode=ucs2, Python's Py_UNICODE does *not* start
supporting the full Unicode ccs the same way it supports UCS-2.
Individual surrogate values remain accessible, and supporting
non-BMP characters is left to the application (with the exception
of the U
icode_AsUnicode get a Py_UNICODE*, and
can use that to directly access the characters.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
> Yes, but the first few steps are the same for nearly everyone, and
> people need more help taking the first few steps.
Contributions to the documentation are certainly welcome.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
Shane Hathaway wrote:
> Py_UNICODE would always be 32 bits wide.
This would break PythonWin, which relies on Py_UNICODE being
the same as WCHAR_T. PythonWin is not broken, it just hasn't
been ported to UCS-4, yet (and porting this is difficult and
will cause a performance loss).
Regards
In this case,
combining characters do not matter much, because the XML
spec is defined in terms of Unicode coded characters, causing
combining characters to appear as separate entities for lexical
purposes (unlike half surrogates).
Regards,
Martin
_
d be
> a much more reasonable choice than whatever TCL uses.
The goal of the build process is to provide as many extension
modules as possible (given the set of headers and libraries
installed), and _tkinter is an important extension module
because IDLE
fectly happy with UCS-4.
-1 on the idea of dropping one alternative. They are both used
(on different systems), and people rely on both being supported.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
it SHOULD NOT support surrogate
> pairs. Supporting surrogate paris is the purvey of variable width
> encodings, and UCS-2 is not among them.
So you suggest to renaming it to --enable-unicode=utf16, right?
My point is that a Unicode type with UTF-16 would correctly
support all assigned U
Nicholas Bastin wrote:
> All of my proposals for what to change the documention to have been
> shot down by Martin. If someone has better verbiage that they'd like
> to see, I'd be perfectly happy to patch the doc.
I don't look into the specific wording - you speak En
Something in the docs needs
> to spell this out.
Again, patches are welcome. I was opposed to Nick's proposed changes,
since they explicitly said that you are not supposed to know what
is in a Py_UNICODE. Integrating the essence of PEP 261 into the
main documentation would be a worthwhile ta
t, either directly, or
> through the use of surrogate pairs.
Try to match regular expression classes for non-BMP characters:
>>> re.match(u"[\u1234]",u"\u1234").group()
u'\u1234'
works fine, but
>>> re.match(u"[\U00011234]",u"
ong guarantee that you won't
see a Windows Python build with UCS-4 for quite some time.
Regards,
Martin
___
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
ean they don't get a working
_tkinter, unless they rebuild Tcl as well. Nevertheless, it is indeed
likely that people do that. So if you want to support them, you
need to distribute two versions of your binary module, or give
them source code.
Regards,
Martin
_
isn't my experience: functions that scan XML strings
are much slower than regular expressions. I can't imagine
how a custom codec could work, so I cannot comment on that.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
M.-A. Lemburg wrote:
> I think we should remove the defaulting to whatever
> TCL uses and instead warn the user about a possible
> problem in case TCL is found and uses a Unicode
> width which is incompatible with Python's choice.
-1.
M.-A. Lemburg wrote:
> Martin, please reconsider... the choice is between:
The point is that this all was discussed, and decided the
other way 'round. There is no point in going back and forth
between the two choices:
http://mail.python.org/pipermail/python-dev/2003-June/036461.htm
M.-A. Lemburg wrote:
> If all you're interested in is the lexical class of the code points
> in a string, you could use such a codec to map each code point
> to a code point representing the lexical class.
How can I efficiently implement such a codec? The whole point is doing
that in pure Python (
ily;
if there is a plan for obsoleting this setting, it should be
done in a phased manner).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
icode=ucs4
> (if you know that TCL uses UCS4) to your configure
> setup. The --enable-unicode=ucs4 configure setting
> is part of RedHat and SuSE already, so there won't
> be any changes necessary.
Yes, but users of these systems need to adjust.
Regards,
Martin
___
s 100% (better 150%)
compatible with the old code, even in border cases. I don't know
whether this is possible at all, from experience, I would guess
that there is a significant chance of breaking something.
Regards,
Martin
___
Python-De
ns (of which we currently only have
KeyboardInterrupt). The PEP should point out that an async
exception between the beginning of the with statement and
the assignment to the variable may or may not cause __exit__
to be called (depending on how far you are into __enter__)
Regards,
Martin
__
icated a dislike to contribute certain
pieces of work, primarily out of fear to lose control. My
experience with integrating his work without his explicit
cooperation (specifically: sgmlop in PyXML) show that
he won't object to somebody else doing such integration,
but also won'
lease post to comp.lang.python.
Or, as a medium-sized answer: google for "python free threading".
Removing the GIL is easy, but then the interpreter crashes in cases of
simultaneous accesses to dictionaries, reference counters, etc.
I also disagree with Martin Aliger's premises:
docs.python.org/api/includes.html
"Warning: Since Python may define some pre-processor definitions which
affect the standard headers on some systems, you must include Python.h
before any standard headers are included. "
If you follow this recommendation, this kind of error shoul
of gcc (this was in 2002).
In Dec 2004, Mark Asbach did the same thing with ICC 8 vs. gcc 3.3.4,
on Linux:
http://groups-beta.google.com/group/comp.lang.python/msg/a4af997f8f95592e?hl=en
He reported a small speedup.
I couldn't find anything on Python and ICC V9.
Regards,
Martin
_
and even if there
is no procedure to clear them. The reason is that they would become
stale if the module object went away. As there is no way to protect
against this case, they just keep a garbage reference.
Regards,
Martin
___
Python-Dev mailing lis
at Tim asserts, saying that people who want to use the
feature should fix it themselves.
Regards,
Martin
___
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
tself": How did you
miss the "Get help" and "Bug reports" links below "Contact Us"
on the PyPI page? They would have brought you to the PyPI SF trackers,
but that would also have been the right place.
Regards,
Martin
_
BJörn Lindqvist wrote:
> Would it also be possible for the PEP-maintainers not to accept PEPs
> that are obvious jokes unless thedate is April I?
I believe this is the current policy. Why do you think the PEP editor
works differently?
Regards,
asional checks should be sufficient; I cannot
see a point in having code permanently pass with that option. In
particular not if you are interfacing with C libraries.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
n be constructed from strings, and will do a
conversion; in Py3k, .encode will already return a string, so
this will be a no-op.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
rgument seems useless in the case of str objects,
> and it seems it should default to latin-1 for unicode objects.
I agree with the former, but not with the latter. There shouldn't be a
conversion of Unicode objects to bytes at all. If you want bytes from
a Unicode string U, wri
x80".encode("latin-1")
if they absolutely want to, although they better write
bytes([0x80])
Now, the first form isn't valid in 2.5, but
bytes(u"\x80".encode("latin-1"))
could work in all versions.
Regards,
Martin
ic Py_KEYWORDS_STRING_TYPE *kwslist[] = {"yada", NULL};
> ...
You did not read Tim's message carefully enough. He wasn't talking
about PyArg_ParseTupleAndKeywords *at all*. He only talked about
changing char* arguments to const char*, e.g. in
PyObject_SetAttrString. Did t
re fond of eggs, for reasons that I haven't yet
understood.
>From a release management point of view, I would still like to
make another bdist_msi release before contributing it to Python.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@
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 should return something
like
bytes([1,2,3])
Regards
some function won't modify the storage behind a char*, even though
it doesn't take a const char*). So it is appropriate that the
warning generates many false positives. Therefore, it should be
a manual interaction to turn this warning on, inspect all the
m
Bob Ippolito wrote:
>>Martin von Loewis's alternative for the "very controversial" set is to
>>disallow an encoding argument and (I believe) also to disallow Unicode
>>arguments. In 3.0 this would leave us with s.encode() as the
>>only way to convert a st
n-1" assumption in that code. Suppose
you do
# -*- coding: koi-8r -*-
print bytes("Гвидо ван Россум")
in Python 2.x, then this means something (*). In Python 3, it gives
you an exception, as the ordinals of this are suddenly above 256.
Or, perhaps worse, the code
# -*- coding
ource code, including (byte)
string literals, comments, identifiers, and keywords. IOW, if you
declare your source encoding is utf-8, the keyword "print" must
be represented with the bytes that represent the Unicode letters
for "p","r","i","n", and &quo
u have read), so
you would need to unbuffer these, and reinterpret
them. To support that, you really need to buffer
both the original bytes, and the decoded ones, since
the encoding might not roundtrip.
Regards,
Martin
___
Python-Dev mailing
't want to
do it, I would.
Regards,
Martin
___
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
bit (byte) strings.
Regards,
Martin
___
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
Alain Poirier wrote:
> - is (c)ElementTree still planned for inclusion ?
It is included already.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
FG generator, or something between AST and
> CFG) can decide not to validate internally generated AST for non-debug
> builds, for instance.
That's how the ast-objects branch currently works. There is a method
checking that the tree actually conforms to the gr
Jason Orendorff wrote:
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
This looks good, although it duplicates
expected_md5_hash = binascii.unhexlify('5c535024cac5199153e3834fe5c92e6a')
Regards,
Martin
___
anges should be made, please
discuss them here - they would need to be reflected in the
PEP as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
body has told me how to
maintain PyXML so that it can continue to work both for 2.5 and for 2.4.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
so notice that this has nothing
to do with stdio: os.open does not use stdio; this is
POSIX open).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
Ideally, a committer then will only have to read the entire review
process, agree with it step-by-step, and commit the proposed change.
As a historical note: people doing a lot of reviews eventually end
up as committers, just because it is easier for th
ode, or string.decode.
Why is
s.encode("uu")
any better than
binascii.b2a_uu(s)
Regards,
Martin
___
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
memory leak
is and how to correct it would be more appropriate. Most
likely, there is no memory leak in eval.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ult could be assignable
and del-able.
Also, I think has_key/in should return True if there is a default.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
M.-A. Lemburg wrote:
> Just because some codecs don't fit into the string.decode()
> or bytes.encode() scenario doesn't mean that these codecs are
> useless or that the methods should be banned.
No. The reason to ban string.decode and bytes.encode is that
it confuses user
just as if it were a normal dictionary - which is a useful
property, IMO.
Regards,
Martin
___
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. The point of the PEP process is to channel
and collect discussion, so that the BDFL can make a decision.
The BDFL is not bound at all to the PEP process.
To document things, we use (or should use) documentation.
Regards,
Martin
___
Python-Dev m
share across architectures, and
because trying to do the sharing still causes problems (e.g.
what if the packaging systems of different architectures
all decide to put the same files into /usr/share?)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pytho
es defaulting
(i.e. __dict__ access); I think it should. This would cause
__getattr__ to have no effect if the object's dictionary has
a default factory (unless that raises a KeyError).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
Josiah Carlson wrote:
> How are users confused?
Users do
py> "Martin v. Löwis".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
ordinal not in
ue as a modification.
The default value has been there, all the time. It only is incarnated
lazily.
Regards,
Martin
___
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
KeyError, so they must
> avoid depending on it either way.
Can you give an example of real, existing code that will break
if a such a dict is passed?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
the real example
where this difference would matter? (I'm not asking for
a realistic example, I'm asking for a real one)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
a, it is
the streaming aspect: that you don't need to process all data
at once, but can feed data sequentially. Of course, you are
not using this in your example.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
ou find that many access operations also
have side effects. For example, .read() on a file not only returns
some data, but also advances the file position. Queue.get not
only returns the next item, but also removes it from the queue.
Regards,
Martin
___
P
So should I write
3.1415.encode("sin")
or would that be
3.1415.decode("sin")
What about
"http://www.python.org".decode("URL")
It's "data in, data out", after all. Who needs functions?
Regards,
Martin
_
manipulation of a dictionary in multiple threads, today: if you
do
try:
d[k].append(v)
except KeyError:
d[k] = [v]
then two threads might interleavingly execute the except-suite.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
4601 - 4700 of 5770 matches
Mail list logo
