Lawrence D’Oliveiro:
>> [...] as much like C++ as
>> possible.
>
> Nevertheless, Python copied the C misfeature [...]
You segued a little too easily from C++ to C. When talking language
evolution and inspirations, they are entirely different things.
- Anders
--
https://mail.python.org/mailman/
Marco Sulla via Python-list:
> Well, they are the most used languages.
They weren't when Python was created.
Python's terms raise/except and self were normal for the time. C++ was
the odd one out. throw/catch and this are Stroustrup's inventions, no
other language used those terms.
It was only
Charles T. Smith:
I've really learned to love working with python, but it's too soon
to pack perl away. I was amazed at how long a simple file search took
so I ran some statistics:
Write Python in pythonic style instead of translated-from-Perl style, and the
tables are turned:
$ cat find-re
Steven D'Aprano:
I'll give you the benefit of the doubt, and assume that when you first
posted you hadn't realised that the audience here does not have the
relevant experience, but by refusing to ask the question elsewhere, and
by making snide comments that "they don't like beer", that pretty muc
alister wrote:
I don't have time to start this discussion over again on another mailing
list.
Don't anyone on those lists read python-list also?
they possibly do, but prefer to keep discussions to the proper forum
The semantics of the Python programming language is on-topic for python-list.
T
Joel Goldstick wrote:
I've been following along here, and it seems you haven't received the answer
you want or need.
So far I received exactly the answer I was expecting. 0 examples of NaN!=NaN
being beneficial.
I wasn't asking for help, I was making a point. Whether that will lead to
impro
Ethan Furman:
I would suggest you ask for this on the numerical mailing lists instead of
here -- and you may not want to offer a beer to everyone that has an anecdote
for NaN behavior being useful.
I don't have time to start this discussion over again on another mailing list.
Don't anyone on th
Steven D'Aprano wrote:
I assumed that you realised that the 64-bit(?) values you were receiving
in binary could be interpreted as ints. After all, you have to unpack
them from some bytes.
Since that's not what you're doing, I have no idea what it is.
Stop obsessing over how NaN's came to exi
Chris Angelico:
If you need to do bitwise comparisons, then the easiest way is to use
the bitpattern, converted to an integer. A 64-bit float becomes a
64-bit integer. It's then very simple to compare them, and reflexivity
is maintained. At what point do you actually need them to be floats?
What
Steven D'Aprano wrote:
It seems to me that the trivial work-around is:
* gather packed floats from some device, as ints
* process them *as ints* in some way which requires reflexivity
* unpack back into floats
* (maybe) much later perform numeric calculations on them
Although perhaps I don't u
I wrote:
| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), "changed to", new)
| old = new
| time.sleep(1)
Huh, I don't know what happened to the identation here, I'l
Steven D'Aprano wrote:
- Dropping reflexivity preserves the useful property that NANs compare
unequal to everything.
Please present an example from real life where that turned out useful, and earn
yourself a beer!
I've only experienced examples to the contrary.
- Keeping reflexivity for
I wrote:
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Py
Den 14-07-08 19:23, Skip Montanaro skrev:
In addition to what others have written, I will add one thing. There
are certainly situations where raising an exception is bad. Consider
all the people in the scientific computing community doing fancy
linear algebra sorts of things, often with missing
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
>>> float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said otherwise.
regards, Anders
--
https://mail.python.o
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Python to do
Ian Kelly wrote:
As far as I know nothing changed between 2.4 and 2.7 in this regard.
Python has always had NaN compare unequal to everything, per the
standard.
It might have been platform-specific in 2.4.
Okay, here's your problem: there isn't just one binary representation
for NaN.
I'm full
Chris Angelico wrote:
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single "thing".
I don't actually care if all NaN bitpatterns are in the same equivalence group
or if each bitpattern is i
Most people don't need to deal with NaN's in Python at all,
fortunately. They just don't appear in normal computation, because the
interpreter raises an exception instead.
It happens in my work I come across them quite a lot. I'm writing
software that talks to embedded applications that can conta
Ben Last wrote:
north_american_number_re = (RE().start
.literal('(').followed_by.exactly(3).digits.then.literal(')')
.then.one.literal("-").then.exactly(3).digits
.then.one.dash.followed_by.exactly(4).digits.then.end
.as
Thomas 'PointedEars' Lahn wrote:
> I am getting the idea here that you mean the right thing, but that you
> explain it wrong.
Feel free to write the much longer essay that explains it all unambiguously, I'm
not going to.
regards, Anders
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
> I can't fathom why 8 position tabs were *ever* the default, let alone why
> they are still the default.
That's because they were not invented as a means for programmers to vary
indentation.
Originally, tabs were a navigation device: When you press the tab key, you skip
jkv wrote:
Hi Martin,
What i usally do is to convert the two times to seconds since epoch and
compare the two values in seconds. You can use time.mktime to convert
localtime to seconds since epoch.
There's no need to convert - simply retrieve the times as absolute times to
begin with:
fil
Ethan Furman wrote:
> Even if we find out that C.__nonzero__ is called, what was it that
> __nonzero__ did again?
reinforce the impression that he is unaware of the double-underscore
functions and what they do and how they work.
Only if your newsreader malfunctioned and refused to let you
Steven D'Aprano wrote:
On Tue, 29 Jul 2008 00:23:02 +, Steven D'Aprano wrote:
Dude. Dude. Just... learn some Python before you embarrass yourself
further.
I'm sorry Anders, that was a needlessly harsh thing for me to say. I
apologize for the unpleasant tone.
Still, __nonzero__ is a fu
Steven D'Aprano wrote:
On Sun, 27 Jul 2008 23:45:26 -0700, Carl Banks wrote:
I want something where "if x" will do but a simple explicit test won't.
Explicit tests aren't simple unless you know what type x is.
If you don't even know a duck-type for x, you have no business invoking any
met
Gary Herron wrote:
>>> A = [1,2,3]
>>> B = [4,5,6]
>>> C = [7,8,9]
>>> A+B+C
[1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> sum([A,B,C], [])
[1, 2, 3, 4, 5, 6, 7, 8, 9]
Careful now, this can be very slow. sum uses __add__, not __iadd__, which gives
this approach quadratic worst-case runtime.
- Ande
B wrote:
>
> # pass in window handle and parent node
> def gwl(node, hwnd):
> if hwnd:
> yield node, hwnd
> for nd, wnd in Wnd.gwl(node.children[-1], GetWindow(hwnd,
> GW_CHILD)):
> yield nd, wnd
> for nd, wnd in Wnd.gwl(node, GetWind
Alexander Schmolck wrote:
> "Anders J. Munch" <[EMAIL PROTECTED]> writes:
>
>> Like Steven said, tail-call optimisation is not necessary as you can always
>> hand-optimise it yourself.
>
> Care to demonstrate on some code written in CPS (a compiler or pa
Neil Cerutti wrote:
> On 2007-06-12, Anders J. Munch <[EMAIL PROTECTED]> wrote:
>> Converting tail-recursion to iteration is trivial, and
>> perfectly reasonable for a human to do by hand.
>
> For simple recursive tail calls, yeah, it can be. Translating a
> tai
Paul Rubin wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>>> Not tail calls, in general, no.
>> Sorry, how does that work? You're suggesting that there is an algorithm
>> which the compiler could follow to optimize away tail-recursion, but human
>> beings can't follow the same algorithm?
>>
durumdara wrote:
> Only one way I have to control this: if I modify the ZipFile module.
Since you already have the desired feature implemented, why don't you submit a
patch.
See http://www.python.org/patches/
- Anders
--
http://mail.python.org/mailman/listinfo/python-list
Hendrik van Rooyen wrote:
> And we have been through the Macro thingy here, and the consensus
> seemed to be that we don't want people to write their own dialects.
Macros create dialects that are understood only by the three people in your
project group. It's unreasonable to compare that to a "d
Eric Brunel wrote:
> You could tell that the rule should be that if the project has the
> slightest chance of becoming open-source, or shared with people not
> speaking the same language as the original coders, one should not use
> non-ASCII identifiers. I'm personnally convinced that *any* indu
Alex Martelli wrote:
>
> Homoglyphic characters _introduced by accident_ should not be discounted
> as a risk, as, it seems to me, was done early in this thread after the
> issue had been mentioned. In the past, it has happened to me to
> erroneously introduce such homoglyphs in a document I was
Michael Torrie wrote:
>
> So given that people can already transliterate their language for use as
> identifiers, I think avoiding non-ASCII character sets is a good idea.
Transliteration makes people choose bad variable names, I see it all the time
with Danish programmers. Say e.g. the most de
Josiah Carlson wrote:
> On the other hand, the introduction of some 60k+ valid unicode glyphs
> into the set of characters that can be seen as a name in Python would
> make any such attempts by anyone who is not a native speaker (and even
> native speakers in the case of the more obscure Kanji g
Rob Thorpe wrote:
> Anders J. Munch wrote:
>> Let u(t) be the actual memory used by the program at time t.
>> Let r(t) be the size of reachable memory at time t.
>>
>> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
>>
>> There.
Rob Thorpe wrote:
> Anders J. Munch wrote:
>> Really? So how do you write a portable program in CL, that is to
>> run for unbounded lengths of time?
>
> You can't.
>
> The thing about the spec not defining GC is almost a bit of humour.
> No-one wou
jayessay wrote:
> Please note: GC is not part of CL's definition. It is likely not part
> of any Lisp's definition (for reasons that should be obvious), and for
> the same reasons likely not part of any language's definition.
Really? So how do you write a portable program in CL, that is to r
Ben Finney wrote:
>
> >>> def obstinate_economist_enumerate(items):
> ... enum_iter = iter((i+1, x) for (i, x) in enumerate(items))
> ... return enum_iter
iter is redundant here.
def natural_enumerate_improvement(items, start=0):
return ((i+start, x) for (i, x) in enumer
Lawrence D'Oliveiro wrote:
>>> elif Ch == "'" or Ch == "\"" or Ch == "\\" :
>>> Ch = "\\" + Ch
>> Always sad to see an SQL DBMS willfully violate the SQL standard.
>
> Why is that a violation of SQL?
Taking another look, I might be wrong: Your code uses double quotes, and
sin
Robert Kern wrote:
> Anders J. Munch wrote:
>
>> Always sad to see an SQL DBMS willfully violate the SQL standard.
>
> You must be a constantly depressed person, then. :-)
Nah, I just look the other way most of the time *g*
- Anders
--
http://mail.python.org/mailman/listinfo/python-list
Now 2.5 is out, and we have a syntax for explicit relative imports
(PEP 328, http://www.python.org/dev/peps/pep-0328/, in case anyone
wasn't paying attention). The long-term plan is that the classical
import syntax becomes absolute import only, so that all imports are
explicitly one or the other.
Lawrence D'Oliveiro wrote:
> Why doesn't MySQLdb provide a function like this:
>
> def QuoteSQL(Str, DoWild) :
> """returns a MySQL string literal which evaluates to Str. Needed
> for those times when MySQLdb's automatic quoting isn't good enough."""
Presumably because you're expected to
[EMAIL PROTECTED] wrote:
> As it is now,
> one is pretty much left to rummage around on project web sites trying to get
> a gut feel for what is going on. Asking the higher-ups at work to reach
> technology management decisions based on my gut feel is an uphill climb.
So what you need is a docume
"John Machin" <[EMAIL PROTECTED]> wrote:
> 1. Robustness: Both versions will "crash" (in the sense of an unhandled
> 2. Efficiency: I don't see the disk I/O inefficiency in calling
3. Don't itemise perceived flaws in other people's postings. It may
give off a hostile impression.
> 1. Robustness:
"Bulba!" <[EMAIL PROTECTED]> wrote:
>
> One of the posters inspired me to do profiling on my newbie script
> (pasted below). After measurements I have found that the speed
> of Python, at least in the area where my script works, is surprisingly
> high.
Pretty good code for someone who calls himsel
48 matches
Mail list logo
