Josiah Carlson wrote:
Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle). If it isn't any
faster than cPickle or marshal, then users may bypass the module and opt
for fork/etc. + XML-RPC
XML-RPC isn't close to marshal
Tim Lesher wrote:
1. Does this seem like a reasonable addition to the standard library?
I cannot remember ever doing this, or seeing anyone except Perforce
doing this, and it'll only save you a few lines of code every other year
or so, so my answer is definitely no.
(if you're serious about
Talin wrote:
/*
Plot a point at position x, y.
'x' - The x-coordinate.
'y' - The y-coordinate.
*/
void Plot( int x, int y );
The scanner should note that: 'x' and 'y' are in single-quotes, so they
probably refer to code identifiers.
or maybe they're
Chuzo Okuda wrote:
I received the bounced email as follow. How do I become a member?
the moderator has approved your message, and it has reached the right
persons. I'm sure they'll get back to you soon.
/F
___
Python-Dev mailing list
Nicko van Someren wrote:
If it speeds up pystone by 5.5% with such minimal down side
I'm hard pressed to see a reason not to use it.
can you tell me where exactly pystone does string concatenations?
/F
___
Python-Dev mailing list
Steve Holden wrote:
instance.method(*args) == type.method(instance, *args)
You can nowadays spell this as str.join(, lst) - no need to import a
whole module!
except that str.join isn't polymorphic:
str.join(u,, [1, 2, 3])
Traceback (most recent call last):
File stdin, line 1, in
[EMAIL PROTECTED] wrote:
Greg have you run any generic benchmarks such as pystone to get a
Greg better idea of what the net effect on typical python code is?
MAL's pybench would probably be better for this presuming it does some
addition with string operands.
or stringbench.
/F
Ron Adam wrote:
I think what may be missing is a larger set of higher level string functions
that will work with lists of strings directly. Then lists of strings can be
thought of as a mutable string type by its use, and then working with
substrings
in lists and using ''.join() will not
Terry Reedy wrote:
For true floating point measurements (of temperature, for instance),
'integral' measurements (which are an artifact of the scale used (degrees F
versus C versus K)) should generally be no more common than other realized
measurements.
a real-life sensor is of course
just noticed that the first google hit for what's new in python 2.5:
http://docs.python.org/dev/whatsnew/whatsnew25.html
points to a document that's a weird mix between that actual document, and
a placeholder for what's new in python 2.6.
/F
Jack Jansen wrote:
I was wondering: how many other people who maintain websites (well:
maintain might be a bit of a misnomer in my case:-) related to
Python have also got this spam?
probably everyone. I've gotten two copies, this far.
/F
___
Nick Craig-Wood wrote:
Is there any reason why float() shouldn't cache the value of 0.0 since
it is by far and away the most common value?
says who ?
(I just checked the program I'm working on, and my analysis tells me
that the most common floating point value in that program is 121.216,
Simon Brunning wrote:
The How to use this module sections sound like /F's The Python
Standard Library, of which I keep the dead tree version on my desk
and the PDF vesion on my hard drive for when I'm coding in the pub. It
or something like it would be a superb addition to the (already very
[EMAIL PROTECTED] wrote:
I think the right thing is for InteractiveConsole to dup sys.std{in,out,err}
and do its own thing for its raw_input() method instead of naively calling
the raw_input() builtin.
what guarantees that sys.stdin etc has a valid and dup:able fileno when
the console is
Anthony Baxter wrote:
The plan for 2.4.4 is to have a release candidate on October 11th, and
a final
release on October 18th. This is very likely to be the last ever 2.4 release,
after which 2.4.4 joins 2.3.5 and earlier in the old folks home
finally leaves school is a more correct
Greg Ewing wrote:
Actually I'd like this for lists. Often I find myself
writing
if x not in somelist:
somelist.remove(x)
A single method for doing this would be handy, and
more efficient.
there is a single method that does this, of course, but you have to sprinkle
some sugar on it:
Raja Rokkam wrote:
I would like to code in Python , but i am new to Python Network Programming
wrong list: python-dev is for people who develop the python core, not people
who want to develop *in* python.
see
http://www.python.org/community/lists/
for a list of more appropriate forums.
Johann C. Rocholl wrote:
What is the status of http://effbot.org/lib/ ?
I think it's a step in the right direction. Is it still in progress?
the pushback from the powers-that-be was massive, so we're currently working
under
the radar, using alternative deployment approaches (see
Muguntharaj Subramanian wrote:
Hi All,
I tried building python 2.5c1 using VC8.
Getting the following errors while building pythoncore_pgo:
Creating library pythoncore_pgo/python25.lib and object
pythoncore_pgo/python25.exp
config.obj : error LNK2001: unresolved external symbol
Muguntharaj Subramanian wrote:
That error mentioned in that post was in pythoncore module.
My error is while compiling pythoncore_pgo module.
iirc, that's a partially experimental alternative build for playing with
performance guided optimizations. are you sure you need that module ?
/F
Steve Holden wrote:
Standards, apparently, are for *other* people :-)
ET was written years before the certain modules should use camelcase stuff
was removed from PEP 8. as a refresher for those of you who have trouble
remembering how things were back in early 2004, here's GvR's original style
Paul Moore wrote:
One little addition to the elementtree docs. In the overview section,
adding a paragraph explaining best practice for importing the module
might be useful.
good idea.
PS This actually begs the question - are there platforms where
xml.etree.cElementTree is not available?
Guido van Rossum wrote:
(*) I found an example of code testing if string.find(s, t) != 0,
thinking it was a bug attempting to write if t in s, but which Vinay
identified as a 1.5.2 idiom for if not s.startswith(t)...
and as noted on the py3k list, not a very good one, given that the usual
Guido van Rossum wrote:
I prefer to focus on clearer and less error-prone rather than
faster in most cases.
well, given that startwith is by far the most common typo I make
when writing Python programs these days, I'm not so sure about that
error-proneness thing, but never mind...
I do agree
Neal Norwitz wrote:
I've profiled various combinations. Here are the various results
normalized doing xrange(0, 1e6, 1):
Run on all integer (32-bit) values for start, step, end:
C xrange and iter: 1
Py xrange w/C iter: 1
in real life, loops are a lot shorter than that.
if you take that
Alex Martelli wrote:
Sprints are indeed a fascinating idea and have proven they work, in
an open-source context -- I do wonder if they could be made to work
in other contexts, and I'm sure many others are wondering similarly.
war room development and other colocation approaches are
Martin v. Löwis wrote:
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess)
make that over a decade. the first Python system I built was on
tru64, back in 1995 (portions of the the initial prototype was written
on a 286 box under MS-DOS, but the bulk was developed on tru64
John J Lee wrote:
If nobody has time to fix this, perhaps rev 47154 should be reverted?
yes please.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Georg Brandl wrote:
The example code causes segfaults and probably always has (at last to 2.2)
Interesting! From a naive POV, the docs' example is quite right.
except that it doesn't work?
the problem is that it's using a *high-level* API to manipulate objects
that are not properly
Georg Brandl wrote:
Okay, now that I stumbled over and read the c.l.py thread, I think that we
should
* remove the faulty example (the correct one is already in there)
* add a note to PyList_New that the new list must be filled with items
before handing it to Python code or using it
Guido van Rossum wrote:
To be honest I have no idea how/why Martin or Tim picked this name.
Perhaps it is in POSIX?
it's from sys/types.h, which is a posix thing, afaik:
http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
/F
___
Chris S wrote:
and while most users and the w3 spec
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting)
agree this feature is actually a bug
ET's not a canonicalization library, and doesn't claim to be one, so that
reference isn't
very relevant. And most users know that ET
Martin v. Löwis wrote:
That is not enough reason. Yes, it makes certain applications
impossible, e.g. when namespace prefixes are inside attribute
values. It just means you can't use it for that application,
then. XML has many other applications, and so does ElementTree.
there are ways to
Ralf Schmitt wrote:
any chance to get SimpleXMLWriter (and other modules maybe??) getting
included into xml.etree? Otherwise people might have to stick to the
original elementtree, which doesn't really make sense, since most of
elementtree already is included.
the original decision was to
Neal Norwitz wrote:
Given that several people here think we should lengthen the schedule
in some way, I suspect we will do something. I'm not really against
it, but I don't think it will provide much benefit either. A few more
bugs will be fixed since we have more time.
you're still
Neal Norwitz wrote:
This is the part I don't get. For the external developers, if they
care about compatibility, why aren't they testing periodically,
regardless of alpha/beta releases?
because they don't want to waste time and effort on testing against
releases that are not necessarily a
Nick Maclaren wrote:
I don't think that applies to the Python args[] though,
since its args[0] isn't the path of the OS-level
executable, it's the path of the main Python script.
Oh, yes, it does! The file descriptor or inode number could refer to
the script just as well as it could to
A.M. Kuchling wrote:
While the new python.org is very nice, I do note that there's no blogs
entry on the front page, something which has become a fixture on almost
every other website I visit regularly.
A 'Blogs' link could be trivially added by linking to
planet.python.org, though the blogs
given that java has beaten us with some 60 bytes:
http://programming.reddit.com/info/9xha/comments/c9y8b
and in order to further improve Python's Kolmogorov rating:
http://en.wikipedia.org/wiki/Kolmogorov_complexity
how about adding Peter Norvig's constraint-based solver to the Python
[EMAIL PROTECTED] wrote:
He clearly wasn't fully master of the environment in which his
customers ran his software, so I think it's understandable that he was
caught by surprise by this change.
a programmer that's surprised that code that relies on undocumented behaviour
might behave
Bob Ippolito wrote:
What do you mean by open classes? Python
classes already seem pretty open to me, by
the standards of other languages!
I'm guessing he's talking about being like Ruby or Objective-C where
you can add methods to any other class in the runtime.
wouldn't a standard
K.S.Sreeram wrote:
(just waiting for somebody to give a serious explanation on why this is
a bad idea!)
\F might have to post this to comp.lang.python first...
/F
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
The person whose 'complaints' I was stating says that DSLs (Domain
Specific Languages for those who, like me, were confused about the
acronym) are a big part of what he is after and one per interpreter is
fine by him. He also realises that the application(s) he needs them
Thomas Heller wrote:
Naturally I tried to call base64.encodestring(buffer(ctypes_instance))
and it worked, so that was my answer.
does ctypes_instance implement the buffer API ? if it does, is the
buffer() call even necessary ?
/F
___
Python-Dev
Thomas Heller wrote:
Naturally I tried to call base64.encodestring(buffer(ctypes_instance))
and it worked, so that was my answer.
does ctypes_instance implement the buffer API ? if it does, is the
buffer() call even necessary ?
Yes, in both cases.
are you sure? does it implement the
Talin wrote:
I think python should have a couple more of future imports. from __future__
import new_classes and from __future__ import unicode_literals would be
really welcome, and would smooth the Py3k migration process
Actually - can we make new-style classes the default, but allow a way
Fred L. Drake, Jr. wrote:
It feels like the release cycle from alpha1 to final has gotten increasingly
rushed.
python 2.2: ~5 months
python 2.3: ~7 months
python 2.4: ~5 months
python 2.5: ~4 months
I think the biggest problem is the time between basically stable beta
and final; it was ~90
Georg Brandl wrote:
Late it comes, but here is a patch for getopt.c implementing
this pronouncement. I think there's no need to wait for 2.6 with it,
or is there?
check it in already.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Boris Borcic wrote:
note that most examples of this type already work, if the target type is
mutable, and implement the right operations:
def counter(num):
num = mutable_int(num)
def inc():
num += 1
return num
return inc
Jeremy Hylton wrote:
To express this email in the positive form:
1. Reserved words should be real words.
2. The meaning of the word should be clear.
3. Put statements in positive form. (Strunk White)
4. The word should sound good.
agreed. a word should describe what a thing is, not what
Talin wrote:
I also think that it won't be a complete disaster if we do nothing at
all - there *are* existing ways to deal with this problem; there are
even some which aren't hackish and non-obvious. For example, its easy
enough to create an object which acts as an artificial scope:
Peter Åstrand wrote:
I intend to fix bug #1223937: subprocess.py abuse of errno. I thought
this was going to to tricky, to maintain backwards compatibility, but
then I realized that check_call() and CalledProcessError() are not
available in any released version of Python, so I guess it's
Boris Borcic wrote:
I believe that in this case native linguistic intuition made the decision...
The reason has nothing to do with language. Guido didn't
want sum() to become an attractive nuisance by *appearing*
to be an obvious way of joining a list of strings, while
actually being a very
Boris Borcic wrote:
in what language [is] the word sum an appropriate synonym for
concatenate ?
any that admits a+b to mean ''.join([a,b]), I'd say.
and what human language would that be ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Just van Rossum wrote:
Why couldn't at least augmented assignment be implicitly rebinding? It
has been suggested before (in the context of a rebinding operator), but
I'm wondering, is this also off the table?
def counter(num):
def inc():
num += 1
Brad Doctor wrote:
I am not sure if this is the proper forum or means to submit something
like this, so please forgive me and advise accordingly if I am in error.
to make sure that they don't just disappear under a zillion other mails,
patches should be submitted to the patch tracker:
Georg Brandl wrote:
Can this be correct if from or to isn't a string object, but a
char buffer compatible object?
May I note that this is still unresolved? I can submit a bug report
and add it to PEP 356, too...
it's already on my todo list, but that list is full of stuff, so having
it on
Martin v. Löwis wrote:
In developing a cPickle module for IronPython that's as compatible as
possible with CPython, these questions have come up:
[I wish you were allowed to read the source code of Python]
on the other hand, it would be nice if someone actually used Bruce's questions
and the
[EMAIL PROTECTED] wrote:
One other thought -- at PyCon, I talked with a group of
educators. While they needed some minor tweaks to the Turtle
module, there were no requests for an extensive rewrite or a
fatter API. The name of the game was to have a single module
with a minimal toolset
Eric Sumner wrote:
You mean something like this?:
switch x in colours:
case RED:
# whatever
case GREEN:
# whatever
case BLUE:
# whatever
I think Guido's right. It doesn't solve the underlying problem because the
compiler still has to figure
Eric Sumner wrote:
what's a label ?
In your example, RED, GREEN, and BLUE. colours provides a mapping
from values to labels/cases, and the switch statement provides a
mapping from labels/cases to code. Sorry about introducing a new term
without saying anything about it.
yeah, but what
Georg Brandl wrote:
In followup to a clpy discussion, should the docs contain
a note that property can be used as a decorator for creating
read-only properties?
feel free to steal the extended example and the read-only example from
the pyref wiki:
http://pyref.infogami.com/property
/F
Nick Coghlan wrote:
There certainly isn't anything in the code above to suggest to a reader that
the condition attempting to guard evaluation of the switch statement might not
do its job.
that's why the evaluation model used in the case statement needs to be explicit.
that applies to the
Phillip J. Eby wrote:
Hear, hear! We already have if/elif, we don't need another way to spell
it. The whole point of switch is that it asserts that exactly *one* case
is supposed to match
that's not true for all programming languages that has a switch construct,
though;
the common trait is
Guido van Rossum wrote:
Is it unacceptable - or impractical - to break the addition of switch
to python in two (minor version separated) steps ?
But what's the point? We have until Python 3000 anyway.
except that we may want to reserve the necessary keywords in 2.6...
/F
Guido van Rossum wrote:
that's not true for all programming languages that has a switch construct,
though;
the common trait is that you're dispatching on a single value, not
necessarily that
there cannot be potentially overlapping case conditions.
You have a point.
that can happen to
Gregor Lingl wrote:
Already now, only one week after publishing it I have some very positive
feedback and people start to use it. So I think there is some demand for
it.
some demand != should be added to the core distribution a few days after
its first release. (and if everything that someone
Gregor Lingl wrote:
What a shame!! An immanent bug, persistent
for years now!
Is this what Anthony Baxter calls
the most solid Python release ever
do you really think stuff like this helps your cause ?
/F
___
Python-Dev mailing list
Alexander Belopolsky wrote:
Setobject code allocates several internal objects on the heap that are
cleaned up by the PySet_Fini function. This is a fine design choice,
but it often makes debugging applications with embedded python more
difficult.
given that CPython has about a dozen Fini
Guido van Rossum wrote:
Here's an argument for allowing names (this argument has been used
successfully for using names instead of string literals in many APIs):
if there is a spelling error in the string literal, the case will
silently be ignored, and who knows when the bug is detected. If
Guido van Rossum wrote:
Most school I proponents (perhaps you're the only exception) have
claimed that optimization is desirable, but added that it would be
easy to add hash-based optimization. IMO it's not so easy in the light
of various failure modes of hash(). (A possible solution would be
Talin wrote:
In fact, I'd like to point out something that hasn't been brought up,
which is that in many cases having a closure rebind the switch cases
defeats the purpose of the thing. For example:
def outer():
def inner(x):
switch(x):
case 1: ...
Phillip J. Eby wrote:
I don't see this as much of a problem, really: we can simply restrict
the optimization to well-known data types (homogenous switches using
integers or strings should cover 99.9% of all practical cases), and then
add an opcode that checks uses a separate dispatch object
Josiah Carlson wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct.
there's no shortage of Python constructs that are functionally identical
to existing constructs. as with all syntactic sugar, the emphasis
Guido van Rossum wrote:
just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR is a temporary variable,
Phillip J. Eby wrote:
I think I like it. I was confused by what Fredrik meant by const, but
your renaming it to static makes more sense to me;
footnote: I suggested static in my list of use cases; while const
makes sense in many cases, static makes more sense for things like this:
Guido van Rossum wrote:
That sounds like a good solution all around. I hope that others can
also find themselves in this.
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no
Fredrik Lundh wrote:
I'd still prefer the explicit is better than implicit route, approach
switch/case (if added) is defined in terms of if/elif, and optimizations
are handled by the optimizer/code generator.
s/approach/where/
/F
___
Python-Dev
Fredrik Lundh wrote:
(now, if you're written implied 'break', I'm all for it)
note to self: the fact that it's a holiday doesn't mean that you should
post before you'd had enough coffee.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http
Nick Maclaren wrote:
Unfortunately, that doesn't help, because it is not where the issues
are. What I don't know is how much you know about numerical models,
IEEE 754 in particular, and C99. You weren't active on the SC22WG14
reflector, but there were some lurkers.
SC22WG14? is that some
Guido van Rossum wrote:
which simply means that expr will be evaluated at function definition
time, rather than at runtime. example usage:
var = expression
if var == constant sre.FOO:
...
elif var == constant sre.BAR:
...
elif var in constant
Guido van Rossum wrote:
def foo(value):
const bar = fie.fum
if value == bar:
...
which would behave like
def foo(value, bar=fie.fum):
if value == bar:
...
but without the what if we pass in more than one argument? issue.
So
Guido van Rossum wrote:
well, I find the proposed magic behaviour of case at least as confusing...
It's not magic if it can be explained. def goes over all the cases
and evaluates them in the surrounding scope and freezes the meaning of
the cases that way as long as the function object
Nick Coghlan wrote:
BTW, prove me Decimal is not fast enough, ;)
C:\Python24python -m timeit -s x = 1.0 x+x
1000 loops, best of 3: 0.137 usec per loop
C:\Python24python -m timeit -s from decimal import Decimal as d; x = d(1)
x+x
1 loops, best of 3: 48.3 usec per loop
I don't
Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
if you're now in the efficiency camp, why not just solve this on the
code generator level ?
Fredrik Lundh wrote:
But in most cases the 'constant' is actually an expression involving a
global, often even a global in another module. (E.g. sre_compile.py)
The compiler will have a hard time proving that this is really a
constant, so it won't optimize the code.
unless we come up
Aahz wrote:
Did we make a final decision about whether the canonical location for
ElementTree should be xml or xmlcore?
the original idea was to use xml to get the latest and greatest from
either the core or PyXML, xmlcore to use the bundled version. I see
no reason to change this just
M.-A. Lemburg wrote:
The winerror module is intended to be able to use symbolic
names for code using .winerror (much like the errno
serves this purpose for .errno).
couldn't this be implemented as an extra table in errno instead ?
/F
___
Giovanni Bajo wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages (see
M.-A. Lemburg wrote:
Since replace() only works on string objects, it appears
as if a temporary string object would have to be created.
However, this would involve an unnecessary allocation
and copy process... it appears as if the refactoring
during the NFS sprint left out that case.
what's
[EMAIL PROTECTED] wrote:
On 5/4/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
I'm +1 on adding --help and --version, +1 on adding -? and /? for
windows only,
-0=slightly sceptical if adding a generic long option machinery is
worth it, and -1
on a guessing machinery.
I
Guido van Rossum wrote:
Maybe we should get serious about slimming down the core distribution
and having a separate group of people maintain sumo bundles containing
Python and lots of other stuff.
there are already lots of people doing that (most Linux distributions add
stuff, directly
or
Brett Cannon wrote:
But I don't think this is trying to say they don't care. People just want
to lower the overhead of maintaining the distro.
well, wouldn't the best way to do that be to leave all non-trivial maintenance
of a
given component to an existing external community?
(after all,
Bill Janssen wrote:
If it's Python, it has to comply with the Python specification,
regardless of what Java does.
what specification ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
I just ran the PIL test suite using the current Python trunk, and the
tests for a user-contributed plugin raised an interesting exception:
ValueError: can't unpack IEEE 754 special value on non-IEEE platform
fixing this is easy, but the error is somewhat confusing: since when is
a modern Intel
Phillip J. Eby wrote:
I'd still rather have a Packages/ directory, but beggars can't be
choosers.
there's plenty of time to work on that for 2.6...
/F
___
Python-Dev mailing list
Python-Dev@python.org
Phillip J. Eby wrote:
I just want changes made by the Python core developers to be reflected in
the external releases.
and presumably, the reason for that isn't that you care about your ego,
but that you care about your users.
/F
___
Python-Dev
Tim Peters wrote:
Which OS and compiler were in use? A possible cause is that the
platform didn't supply #defines for SIZEOF_DOUBLE and/or SIZEOF_FLOAT
when Python was compiled. This was, e.g., true on Windows before rev
46065.
and looking again, I was indeed running 2.5 alpha 2 (revision
Fred L. Drake, Jr. wrote:
With the introduction of the xmlcore package in Python 2.5, should we
document
xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I
don't think they're going to get xml.etree, which will be really confusing.
We can be sure that
Simon Percivall wrote:
how about tweaking the xml loader to map xml.foo to _xmlplus.foo
only if that subpackage really exists ?
I'm a bit confused by what the problem is. I though this was all
handled like it should be now.
that's how I thought things were done, but then I read Fred's
101 - 200 of 622 matches
Mail list logo
