Le mercredi 03 mai 2006 à 04:41 -0700, Michael Chermside a écrit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and floats.
>[...]
> > I'd like to see this change in Python 3000. N
ing), it may be an
interesting optimization.
Regards
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%40mail-archive.com
one, and so on)?
Sorry if it looks really silly.
Regards
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%40mail-archive.com
> Can you explain the difference to:
>
> try:
> self.db_transaction.commit()
> self.tmpoutfile.close()
> self.destroy_shared_memory_handle()
> except Exception, e:
> logging.error("an exception occurred in cleanup: %s", e)
In your construct, if self.db_transaction.commit() rai
> So let me spit out some possible suggestions in terms of keywords:
>
> ref
> refer
> share
> sharing
> common
> use
> using
> borrow
I think you are trying too hard.
Those proposals are all semantically ambiguous.
"ref" / "refer" seems to hint at t
> The standard library is not about easeness of installation. It is about
> having
> a consistent fixed codebase to work with. I don't want to go Perl/CPAN,
> where you have 3-4 alternatives to do thing A which will never
> interoperate
> with whatever you chose among the 3-4 alternatives to do thi
> Which is really, really, REALLY sad. The "Cheese Shop" name may reflect
> the
> proper cultural bias toward Monty Python, but it's a sure way to alienate
> people by presenting the hard work of the community under a completely
> silly
> name that communicates nothing about what it's about.
Isn
.
It happened to me a few times when using function pointers and casts
(IIRC). Pyrex would generate C code but gcc would choke on it.
That's when you realize that C code generated by Pyrex is not very
readable ;-P
But Pyrex is a great tool anyway.
Regards
Antoine.
__
> I bring this up because I recently (like - today) spent about 8 hours
> trying to debug a Python installation problem - and realizing that much
> of the reason that installation and deployment infrastructure of Python
> programs is so ing complex is because of the poverty of tools like
> Make
> OTOH, having `global` and `nonlocal` mean the same thing for
> module-bound variables violates TOOWTDI.
Then you can disallow "nonlocal" for anything else than closure variables.
And disallow "global" for anything else than module-global variables.
It is explicit and unambiguous, and reduces th
> Non-duck typing is a seriously bad idea, forced
> on some other languages by static typing.
Static != non-duck.
One could imagine static duck typing (is it the same as structural
typing?) with type inference. I wonder if some existing languages have
static duck typing (boo? haskell?).
__
pattern ?).
> and note that Python's usually aiming for "(nearly) invisible", not
> "formal", in Norvig's taxonomy.
What is more "invisible", including the callback straight at the point
where it is registered, or defining it beforehand?
The only t
>> The problem is not merely related to the number of lines of code. It is
>> a
>> readibility problem. Having the callback enclosed in a the function call
>> which registers it makes the code more readable than defining the
>> callback
>> beforehand.
>
> And, unless I'm missing something, much ha
e than one callback, and you
cannot decorate two functions at once. For example, with Twisted you can
define a callback (called on success) and an errback (called on error).
But I agree that decorators help to solve a lot of problems.
Thanks for the answer
Antoine.
_
> However, this special-case approach is flawed in this example, because
> its use is so narrow. If you think about it for a minute, you
> immediately start to imagine all of the things that 'upon' ought to deal
> with that it doesn't.
> For example, it has no way to deal with error
> callbacks;
A
> 2. a 'defop' syntax as shorthand for 'addmethod()', such that e.g.:
>
> import operator
>
> class Foo:
> defop iter(self):
> ...
> defop len(self):
> ...
> defop operator.getitem(self, key):
> ...
Is "defop" useful?
Why
> On Wed, 6 Dec 2006, Ka-Ping Yee wrote:
> and "%" is overloadable on the basis that the return type is determined
> to be compatible with "some_type_that_signals_sql_interpolation". Those
> are some mighty big "IF"s though, and you could still concoct cases
> where things would break :-)
Or perha
> Or perhaps simpler, a new kind of string literal would construct an
> Interpolation object:
Hmm, so Jan proposed something similar in the meantime. Sorry for the noise.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mail
> (people who do interpolation tend to expect dynamic lexical scoping, not
> static
> object binding...)
After thinking a bit about it, you are right. Or more precisely, "inline"
interpolation with literals is mainly useful for quick-and-dirty scripts
rather than full-blown apps.
(this "quick-an
> Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> That is for a warm cache.
>
> If you drop your caches first (like this under linux) you get quite a
> different story...
>
> $ sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
> $ time python -c &q
> 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. :)
Part of the reason Benjamin says this is probably that I've been bugging
him quite a few times to commit some pending patches (he wa
Le jeudi 06 avril 2006 à 13:33 -0700, Guido van Rossum a écrit :
> I think that the solution to this would be a book or course "Python
> for Java programmers". Not using the most natural name for a feature
> because Java programmers might misunderstand it sound like the wrong
> motivation.
>
> Pl
Le jeudi 06 avril 2006 à 17:10 -0700, Guido van Rossum a écrit :
> On 4/6/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > But overloaded methods as they exist now have exactly the same
> > expression as non-overloaded methods, all the machinery (mro walking
> >
s a clever syntax for representing XML
fragments in-code.
Here is a simplified example from the tutorial :
let parents : ParentBook =
[
[
"Clara"
[
[
"Pål André"
[]
]
]
"[EMAIL PROTECTED]"
&q
Le mercredi 26 avril 2006 à 08:40 -0400, Greg Wilson a écrit :
> I think this is because:
>
> a) sets are new to Python --- habit and examples both encourage us to use
>lists, even when the collections in question aren't intrinsically
>ordered; and
>
> b) the current notation is unpleasan
Le mercredi 26 avril 2006 à 11:38 -0400, Jim Jewett a écrit :
> (2) How to make set usage at least as efficient.
> (3) Whether the tradeoffs are worth it.
Well, testing for inclusion in a container of 3 ints may not be
significant vs. all the overhead of the interpreter and vs. what you are
act
ook like" if it
comes by default with Python.
Better not ship a "standard GUI system" and let everybody choose, IMHO.
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-30
Le samedi 29 avril 2006 à 02:07 -0400, Tim Peters a écrit :
> If you don't remember these confusions, I think it should suffice to
> remind that Perl's join() does take the separator first (which is
> essentially forced in Perl, given its odd LIST syntax):
PHP's join does too, also some versions h
Le vendredi 28 avril 2006 à 23:14 -0700, Josiah Carlson a écrit :
> Ultimately, PyGUI is essentially a wrapper of native or near-native
> widgets into a common interface. wxPython is exactly the same thing,
> only it has a much larger user base, developer support, and (native and
> emulated) platf
Le samedi 29 avril 2006 à 21:10 +0200, tomer filiba a écrit :
> and if we do that already, perhaps we should introduce async
> operations as a
> built-in feature? .NET does (BeginRead, EndRead, etc.)
> def async_read(self, count, callback)
> def async_write(self, data, callback)
I think m
Le lundi 01 mai 2006 à 10:57 +0200, Fredrik Lundh a écrit :
> Thomas Wouters wrote:
>
> > > join()
> > >
> > > it's time to make this a builtin. the "it's the separator that's doing
> > > the
> > > joining" idea is silly and unintuitive, and should be fixed.
> >
> >
> > I disagree, and I believe
Le lundi 01 mai 2006 à 23:08 +1200, Greg Ewing a écrit :
> Are you sure? Last time I looked at wxWindows, it seemed more
> like it re-implemented everything its own way.
>
> I might be wrong, but if wxWindows is just a wrapper, why
> is it so huge?
I think it is huge because it has a lot of widge
Le lundi 01 mai 2006 à 09:59 -0700, Bill Janssen a écrit :
> Interesting. I never seem to use tree-views, but I do use graph
> views. I think the standard Python GUI should make it easy to build
> these kinds of things. Right now a graph view is fairly easy to build
> on top of a raw View.
As f
y define "groups" for tab-key navigation to work.
- context menus (e.g. on right click).
All that is not to say that "PyGUI s*cks" (it doesn't seem to ;-)), but
that there are a few important things lacking compared to more mature
(and possibly bloated!) GUI systems.
Regards
library in the stdlib is really *not* helpful
to developers, it can even be deceptive.
(by the way, +1 to Talin's expectations for a GUI system:
standardization of look and feel is very important)
Regards
Antoine.
___
Python-3000 mailing list
Py
Le mercredi 03 mai 2006 à 07:46 +0200, Fredrik Lundh a écrit :
> Antoine Pitrou wrote:
>
> > Including a simplistic GUI library in the stdlib is really *not* helpful
> > to developers, it can even be deceptive.
>
> what makes discussions like these impossible is that eve
(used the wrong address and first sent it in private to Michael, sorry)
Le mercredi 03 mai 2006 à 04:41 -0700, Michael Chermside a écrit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and flo
Le mercredi 03 mai 2006 à 09:22 -0400, Greg Wilson a écrit :
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
>
> TypeTwo elementsOne elementEmpty
> List[1, 2]
enforceable. I must be misunderstanding you.
> > Yes, I meant "get rid of all duck typing". Duck typing is for
> > languages that can't do any better. It's a weakness, not a strength.
If you want a Python-lookalike with strong static typing (and optional
duck typing w
Le dimanche 07 mai 2006 à 17:47 +1200, Greg Ewing a écrit :
> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't
project.
* An OS/2 port is in progress, and you can also compile wxWidgets
for GTK+ or Motif on OS/2. »
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubs
used it).
I think styled text display is important. Editable styled text much
less.
An example use case for styled text display: a chat window with chat
messages scrolling along, where you want the name of the participant to
be displayed in bold at the beginning of his/her messages.
Regards
An
hieved roughly the same thing: some kind of compile-time duck-typing.
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
Apparently it has been removed in gcc 3 or 4.
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://ma
ttributes by mistake and trigger
unexpected behaviour. Even you are careful there is still the risk that
a later library version adds a property or method whose name clashes
with one of yours)
Regards
Antoine.
___
Python-3000 mailing list
Python-
Le mercredi 10 mai 2006 à 03:23 +0200, Giovanni Bajo a écrit :
> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
> Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
> different APIs from the Yes/No case, if you're going to use a specialized
> vers
Le jeudi 11 mai 2006 à 10:00 -0600, Travis E. Oliphant a écrit :
>
> That sounds reasonable. As I said before, I like the idea of PyGUI.
> My main consternation is wxWindows. I'm not a big fan of how wxPython
> builds on top of wxWindows which builds on top of GTK which itself
> builds on G
Le dimanche 14 mai 2006 à 11:01 +1000, Nick Coghlan a écrit :
> Fredrik Johansson wrote:
> > For example, square roots are known as math.sqrt(x) for floats,
> > cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> > gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
>
re also inconsistencies in casing
("StringIO, "cPickle", etc.), unnecessary distinctions ("thread" vs.
"threading")...
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailma
Le lundi 22 mai 2006 à 09:46 -0700, Aahz a écrit :
> On Mon, May 22, 2006, Antoine Pitrou wrote:
> >
> > For example, one common annoyance IMO is naming: why "urllib" or
> > "httplib"? If I import something, it's obvious it's a lib, so &quo
Le mercredi 24 mai 2006 à 15:43 -0400, Benji York a écrit :
> Hmm, the next best thing I can come up with is:
>
> def f(a, b, =, c, d):
Why not:
def f(a, b, !c, !d):
The exclamation mark can be thought to say "you must explicitly mention
this one by its name".
I think having a sigil in front o
Le mercredi 24 mai 2006 à 17:15 -0400, Benji York a écrit :
> In that case, just use the current default value syntax, sans value (d,
> below):
>
> def f(a, b, c=None, d=):
Then we can't decide whether "c" can be positional or is keyword-only.
___
Py
sted
modules would be a good think.
(for example, I don't like the way "os.path" is magically imported when
importing "os". Some functions are in "os", others in "os.path", without
any clear logical reason. They should all belong in "os" - or any
uot;url"?
etc.
The documentation can be topically structured, which is indeed handy
when discovering Python and its stdlib, but why force the categorization
on the programmer while it does not bring any benefits?
Regards,
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%40mail-archive.com
uld register themselves. This
could allow third-party modules (e.g. "gtk") to register themselves in
stdlib-supplied virtual packages (e.g. "gui"), for documentation and
findability purposes. "import gui; help(gui)" would give you the list of
available modules.
Regards
different from the default system encoding
(depending on how it's declared in /etc/fstab). I don't know of a simple
way to retrieve the encoding for a given directory (except trying to
find out the filesystem mounting point and parsing /etc/fstab...
*sigh*). This can be annoying when h
nters ("seek cookies" ?), f.seek(0, 1) is a
> no-op, f.seek(0, 2) seeks to EOF.
Perhaps it would be good to drop those magic numbers (0, 1, 2) for
seek() ? They don't really help readibility except perhaps for people
who still do a
sh
for UTF-8 but I guess the problem is related to Mandriva company
management or priority setting policy.
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
looks like "relative seek" to me (having be used to move /
rmove for graphic primitives a long time ago).
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
Le vendredi 08 septembre 2006 à 15:04 -0400, Jim Jewett a écrit :
> > What about seek(), seek_relative() and seek_reverse() ?
>
> Why not just borrow the standard symbolic names of cur and end?
>
> seek(pos=0)
> seek_cur(pos=0)
> seek_end(pos=0)
You are right, it's clear and shorter
s, and autotextfile() for small scripts and the like.
Different names make it clear that they are for different uses, and
allow to spot them easily when looking at source code (either by a human
reader or a quality measurement tool).
Regards
Antoine.
___
ile.set_default_encoding" (with
underscores), or even "text.textfile.set_default_encoding" (if all this
resides in a "text" module).
Regards
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%40mail-archive.com
Le dimanche 10 septembre 2006 à 21:58 +1000, Nick Coghlan a écrit :
> Antoine Pitrou wrote:
> > So, here is an alternative proposal :
> > Make it so that textfile() doesn't recognize system-wide defaults (as in
> > your proposal), but also provide autotextfile() which
This will lead to a crash in the likely case that some
characters in the source file can't be represented using the character
encoding auto-detected for the destination file.
Yet the append_text() function does look correct, doesn't it?
We shouldn
nefficient because it results in opening the file twice:
once in string.guessencoding(), and once in open().
This does not happen if there is a special argument instead, like
"by_content=True" in my proposal.
Cheers
Antoine.
___
Pytho
;myfile.txt', by_content=True)
enc = f.encoding
> Alternatively, it could be possible to allow the encoding to be set
> after the file has been opened, in which case a separate function
> could do the guessing.
Yes, sounds like a nice alternative.
Regards
Antoine.
_
nning with:
import sys, text
if len(sys.argv) > 1:
f = textfile(sys.argv[1], "r")
else:
f = text.stdin
Should encoding policy be chosen differently depending on whether the
script is called with:
python script.py in.txt
or with:
python script.py <
will have swapped out other
data/code in order to make some place in the filesystem cache.
Also, Python is often used on more modest hardware.
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listi
hout BOM*) and the non-Unicode encoding which is popular for
a given language (e.g. ISO-8859-15).
I doubt many people have to discriminate between UTF-16LE, UCS-4 and
UTF-8. Are there real cases like that for text files?
Regards
Antoine.
___
Python
ul, why would they be only
for beginners and students?
IMHO, it would be better to label the module "scripting" rather than
"beginnerlib" (and why append "lib" at the end of module names
anyway? :-)).
It might even contain stuff such as encoding guessing.
>>>
cit fallback to iso-8859-15 is for the common case
where the user has a Western European language, his user locale is utf-8
and he has some non-Unicode files hanging around...
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
t;>> len(a)
5
>>> len(b)
6
>>> a == b
False
>>> a
u'hello'
>>> b
u'\ufeffhello'
>>> print a
hello
>>> print b
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/encodings/
r to use a specific UTF-8 variant
specialized in BOM-stripping will make eyes roll... "why doesn't the
standard UTF-8 do it for me?"
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/lis
ny languages this would mean iso-8859-), use that encoding
- otherwise, no one-byte encoding
This would ensure that, for example, Russian text on a system configured
with a Russian locale does not always end up using two bytes per
character intern
n
distributing IO to multiple cores (and it could even cause a small
decrease in performance because of inter-CPU communication overhead).
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/pyt
Le lundi 18 septembre 2006 à 09:48 -0600, Adam Olsen a écrit :
> * Bolt-on tracing GC such as Boehm-Demers-Weiser. Totally unsupported
> by the C standards and changes cache characteristics that CPython has
> been designed with for years, likely with a very large performance
> penalty.
Has it be
ibutes and methods), so let's make the clean common
case easy to type and unobstrusive, and the rare dirty case easy to
spot. Lots of "global" in a Python program immediately hint at dirty
code.
Regards
Antoine.
___
Python-3000
Le vendredi 03 novembre 2006 à 15:19 -0600, Ka-Ping Yee a écrit :
> I suppose that's fine. Also i guess
>
> nonlocal x = y = 0
That's ambiguous.
Is only "x" nonlocal, or are both "x" and "y"?
What's the point anyway? if you write "nonlocal x = 0", it means you
aren't reusing the variable v
Le vendredi 03 novembre 2006 à 16:22 -0600, Ka-Ping Yee a écrit :
> Only x is nonlocal.
>
> nonlocal x = y = 0
>
> is equivalent to
>
> nonlocal x; x = y = 0
Perhaps, but the point is that it's non-intuitive from reading.
Just like the old "char * x, y" annoyance in C.
> The point is t
Le lundi 06 novembre 2006 à 14:37 -0800, Mike Orr a écrit :
> def __init__(klass, *args):
> if len(args) == 1 and isinstance(args[0], klass.path_class):
> self.path = args[0]
> else:
> self.path = self.path_class(*args)
s/klass/self/, I suppose ?
> Subc
Le jeudi 09 novembre 2006 à 20:45 +, Paul Moore a écrit :
> Again, I don't believe this is possible for all corner cases: what is
> the drive for /my/file on a Windows system?
Why not the current drive?
> If you mandate that all filenames must be relative, you could manage,
> but enforcing t
Le samedi 18 novembre 2006 à 22:42 -0700, Neil Toronto a écrit :
> Actually, plenty of people would dream of it and even do it. I've seen
> some pretty evil implementations of Java interfaces. All they can
> enforce is static types and method signatures.
But protecting against erroneous use (ra
Le dimanche 19 novembre 2006 à 12:44 -0500, George Sakkis a écrit :
> I understand this is not the point you're trying to make, but in such
> cases I usually prefer to make @decorator be equivalent to
> @decorator() by something like:
I could do that, but it's not very clean. Also it doesn't inva
Le mercredi 22 novembre 2006 à 11:52 -0800, Guido van Rossum a écrit :
> but how on earth is the defop syntax of the @defop decorator going to
> generate this? I can't see any way to implement it without having
> access to the class object, but that doesn't exist yet at the time
> defop or @defop
Le mercredi 22 novembre 2006 à 12:47 -0800, Guido van Rossum a écrit :
> > class DefOpDescriptor:
> > def __init__(self, genfunc, implfunc):
> > self.genfunc = genfunc
> > self.implfunc = implfunc
> > def __call__(self, *args, **kargs):
> > # Directly call the implem
Le samedi 25 novembre 2006 à 21:32 +0200, tomer filiba a écrit :
> "contract" is a better term, IMO, since it's already used in CS (as in
> Eiffel),
> and describes the situation more correctly: *behavior* rather than
> *signature*.
> "ability" just doesn't seem right to me: my class is not *abl
C macro as an "external function" in the
Pyrex code and Pyrex would probably be happy with that. (I've never
tried though ;-))
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/p
.3 msec per loop
-> PyVarObject patch: 17.8 msec per loop
Even if the patch is rejected, I think it is important to remember that
implementation characteristics of the unicode type will be crucial for Py3k
performance :-)
Regards
Antoine.
___
Python-3000 mail
Py_DECREF(v);
break;
Regards
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%40mail-archive.com
> The explanation seems to be that, while exc_info is cleared immediately, the
> thread state exception fields are only cleaned up at the end of
> PyEval_EvalFrameEx.
Patch and test in http://bugs.python.org/issue2507
___
Python-3000 mailing list
Pyth
Steve Howell yahoo.com> writes:
>
>line 673234: lambda cannot be renamed in ANY
> temporal dimension
>
[...]
>
>line 913975: parens not removed from print(),
> please use 3to4 converter instead
Mmmh... "3to2" was released on April 1st right ? :)
_
st):
File "", line 1, in
RuntimeError: dictionary changed size during iteration
The "problem" here is that while d.keys() returns the view, enumerate() in turn
calls iter() on the view and that iterator fails on you when dictionary changed
size (as iterkeys() alread
Gregory P. Smith krypto.org> writes:
>
> yes bytearray makes more sense to me given that its hard to read into an
immutable bytes object ;)
It seems to me that readinto accepts any object providing a writeable buffer
interface. I don't know how to express that as an annotation, though.
__
Christian wrote:
> > Make file objects as thread safe as the underlying libc FILE*
> > implementation.
> > close() will now raise an IOError if any operations on the file object
> > are currently in progress in other threads.
> >
> > Most code was written by
Greg Ewing canterbury.ac.nz> writes:
>
> It might not be a serious problem when most of the chars in
> the string are ascii, but what about e.g. a Japanese user
> whose strings consist almost entirely of non-ascii, but are
> for the most part what constitutes perfectly readable text
> to them? Th
Mark Dickinson gmail.com> writes:
> Fair enough. My twisted mind was trying to find ways that size_t
> might be something other than long or long long, but that
> seems unlikely...
There has been a report where sizeof(size_t) < sizeof(long). It breaks things in
the dict implementation:
http://bu
8 bits.
>
> Nope. Everyone understands "octet" to be 8 bits.
And in French, the only word for "byte" is... "octet" ;-)
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/li
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
Unicode. Of course you can encode to UTF-8, UTF-16, etc. - which
/are/ encodings (and, in this case, Python returns you a bytes object :-)).
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/pyt
eplace all occurrences of repr() by ascii(), to err on
the safe side.
Regards
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%40mail-archive.com
proposal looks fine
- we must fix both #2507 and #2833 in a clean way, but your proposal is
completely bogus
cheers
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://m
1 - 100 of 182 matches
Mail list logo
