Op 14-11-15 om 04:11 schreef Michael Torrie:
> On 11/10/2015 03:03 AM, Antoon Pardon wrote:
>> Op 10-11-15 om 00:29 schreef Ben Finney:
>>>
>>> Who is doing what to whom? The user of the library isn't doing anything
>>> to the library author, so what is it the library author would consent
>>> to? I
On 11/10/2015 03:03 AM, Antoon Pardon wrote:
> Op 10-11-15 om 00:29 schreef Ben Finney:
>>
>> Who is doing what to whom? The user of the library isn't doing anything
>> to the library author, so what is it the library author would consent
>> to? Instead, you seem to be trying to assert a *power* of
On 11/13/2015 01:19 AM, Denis McMahon wrote:
On Fri, 13 Nov 2015 09:04:54 +1100, Steven D'Aprano wrote:
On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote:
[crap I expect]
And you should consider the irony, and hypocrisy, of somebody who signs
his posts "PointedEars" bitching a
On Fri, 13 Nov 2015 09:04:54 +1100, Steven D'Aprano wrote:
> On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote:
> > [crap I expect]
> And you should consider the irony, and hypocrisy, of somebody who signs
> his posts "PointedEars" bitching about supposed "real names".
TPEL has been
On Fri, Nov 13, 2015 at 9:19 AM, BartC wrote:
> (FWIW, my real first name is Bart and C is the initial of my last name. Very
> dull I know.)
That's a common way of signing emails. I sign most of mine "ChrisA",
which (as you'll see from my headers) is constructed the same way. So
did the late Dave
On 12/11/2015 20:40, Thomas 'PointedEars' Lahn wrote:
Chris Angelico wrote:
[…] Ben Finney […] wrote:
I recommend you ignore that request; “Bartc” is fine as a name here,
IMO.
Given that LARTC means Linux Advanced Routing and Traffic Control, I'm
guessing Bartc is all about *BSD networking?
On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote:
> And on GABELNs [1] it is considered polite to post using your real name.
Falsehoods programmers believe about names:
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> You have been warned.
And you
Chris Angelico wrote:
> […] Ben Finney […] wrote:
>> I recommend you ignore that request; “Bartc” is fine as a name here,
>> IMO.
>
> Given that LARTC means Linux Advanced Routing and Traffic Control, I'm
> guessing Bartc is all about *BSD networking? :)
I thought LART were the Luser Attitude Re
On Wed, 11 Nov 2015 07:30 pm, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Since compile, eval and exec are Python built-ins, if it doesn't
>> include a byte-code compiler, it isn't Python. It's just a subset of
>> Python.
>
> compile() can be implemented trivially, or in any other manner. It
Steven D'Aprano :
> Since compile, eval and exec are Python built-ins, if it doesn't
> include a byte-code compiler, it isn't Python. It's just a subset of
> Python.
compile() can be implemented trivially, or in any other manner. It
simply needs to return a "code object." I suspect even a string
On Wednesday 11 November 2015 00:26, BartC wrote:
> Does the Python language specify how it is to be compiled and executed?
Not in so many words, but there are limitations on what you can do based on
the specified semantics of Python.
But so long as you meet those semantics, you can implement t
On Tue, 10 Nov 2015 11:14 pm, Ben Finney wrote:
>> Python -- yes, even CPython -- has a runtime compiler. When you import
>> a module, it is compiled (if needed) just before the import. Likewise,
>> when you call the `compile`, `eval` or `exec` built-ins, the compiler
>> operates.
>>
>> I'm not ca
On 10/11/2015 11:34, Steven D'Aprano wrote:
On Tue, 10 Nov 2015 05:10 pm, Ben Finney wrote:
I am a Bear of Little Brain, but: Isn't anything that the *compiler*
does, by definition done at *compile* time?
In a manner of speaking, yes, of course. But you've missed the critical
issue: when is
Laura Creighton writes:
> In a message of Tue, 10 Nov 2015 17:10:09 +1100, Ben Finney writes:
> >I am a Bear of Little Brain, but: Isn't anything that the *compiler*
> >does, by definition done at *compile* time?
>
> No.
>
> We used to have a pretty strict defintion about what a compiler was,
> a
On Tue, 10 Nov 2015 05:10 pm, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> Ben, I fear that you are not paying attention to me :-)
>
> Possibly, though I also think there's miscommunication in this thread.
>
> You speak of “compile time” and “run time”. You also speak of what the
> compile
In a message of Tue, 10 Nov 2015 17:10:09 +1100, Ben Finney writes:
>Steven D'Aprano writes:
>
>> Ben, I fear that you are not paying attention to me :-)
>
>Possibly, though I also think there's miscommunication in this thread.
>
>You speak of “compile time” and “run time”. You also speak of what
Op 10-11-15 om 00:29 schreef Ben Finney:
>
> Who is doing what to whom? The user of the library isn't doing anything
> to the library author, so what is it the library author would consent
> to? Instead, you seem to be trying to assert a *power* of the library
> author to restrict the library user.
On 11/9/2015 9:37 PM, Steven D'Aprano wrote:
The compiler doesn't need to decide *in advance* whether the attribute might
have changed. It knows whether it has changed or not *at runtime*.
You are using 'compiler' when you should, to avoid confusion, use
'interpreter'.
It's one thing to sa
Steven D'Aprano writes:
> Ben, I fear that you are not paying attention to me :-)
Possibly, though I also think there's miscommunication in this thread.
You speak of “compile time” and “run time”. You also speak of what the
compiler can do, at run time.
I am a Bear of Little Brain, but: Isn't
On Tue, 10 Nov 2015 06:45 am, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> The compiler doesn't need to decide in advance whether or not the
>> module attributes have been changed. It can decide that at runtime,
>> just before actually looking up the attribute. In pseudo-code:
>>
>> if a
Antoon Pardon writes:
> Op 07-11-15 om 04:43 schreef Ben Finney:
> > Python assumes the programmers using it are consenting adults. Doing
> > harmful things is difficult but not forbidden.
>
> I find that to be contradictory. Why should you make something difficult
> if you are consenting adults?
Laura Creighton writes:
> In a message of Tue, 10 Nov 2015 06:45:40 +1100, Ben Finney writes:
> >So the remaining space of code that is safe for the proposed
> >optimisation is trivially small. Why bother with such optimisations, if
> >the only code that can benefit is *already* small and simple?
In a message of Tue, 10 Nov 2015 06:45:40 +1100, Ben Finney writes:
>So the remaining space of code that is safe for the proposed
>optimisation is trivially small. Why bother with such optimisations, if
>the only code that can benefit is *already* small and simple?
You have things backwards.
The r
BartC writes:
> On 09/11/2015 01:04, Ben Finney wrote:
> > There isn't a way for the compiler to *know*, in all cases, whether
> > module attributes will be updated during the lifetime of the program
>
> In what way can an attribute be updated, other than deleting it
> altogether?
* Bind a new n
Steven D'Aprano writes:
> The compiler doesn't need to decide in advance whether or not the
> module attributes have been changed. It can decide that at runtime,
> just before actually looking up the attribute. In pseudo-code:
>
> if attribute might have changed:
> use the slow path j
On 09/11/2015 01:04, Ben Finney wrote:
Chris Angelico writes:
Hmm, then I was misunderstanding what BartC was advocating. I didn't
think it would *fail* in the presence of dynamic attributes, but
merely *perform suboptimally* (and presumably worse than current
CPython).
There isn't a way for
Steven D'Aprano writes:
> The compiler doesn't need to decide in advance whether or not the module
> attributes have been changed. It can decide that at runtime, just before
> actually looking up the attribute. In pseudo-code:
>
> if attribute might have changed:
> use the slow path ju
Op 07-11-15 om 04:43 schreef Ben Finney:
> Bartc writes:
>
>> Is there no way then in Python to declare:
>>
>>pi = 3.141519 # etc
>>
>> and make it impossible to override?
> No, and it would be a bad thing if that were something a library author
> could forbid.
>
> Python assumes the progr
On 2015-11-08, Marko Rauhamaa wrote:
> Grant Edwards :
>
>> On 2015-11-07, Marko Rauhamaa wrote:
>>> "const" is a very ineffective tool that clutters the code and forces
>>> you to sprinkle type casts around your code.
>>
>> But it allows the compiler to warn you if you pass a pointer to a
>> rea
On Mon, Nov 9, 2015 at 11:22 PM, BartC wrote:
> I tried this code:
>
> a=10
> print (a)
>
> del a
> #print (a)
>
> a=20
> print (a)
>
> That sort of confirms what you are saying: that names don't even come into
> existence until the first time they are encountered. They don't just contain
> None,
On 09/11/2015 02:23, Steven D'Aprano wrote:
On Mon, 9 Nov 2015 09:35 am, BartC wrote:
import m
a=10
b=20
c=30
m.f()
The set of global names the compiler knows will be ("m","a","b","c").
Wrong. Up to the line "c=30", the set of names the compiler can infer are m,
a, b and c. Once the line "m
On Mon, 9 Nov 2015 12:04 pm, Ben Finney wrote:
> There isn't a way for the compiler to *know*, in all cases, whether
> module attributes will be updated during the lifetime of the program
> (short of, as pointed out elsewhere, running the entire program under
> all possible conditions).
>
> So th
Hi, Chris Angelico ,
Thank you for your help ! :-)
From: Chris Angelico
Date: 2015-11-06 18:30
To: wa...@travelsky.com
CC: python-list
Subject: Re: Question about math.pi is mutable
On Fri, Nov 6, 2015 at 1:33 PM, wa...@travelsky.com wrote:
> Hello, python-list guys:
>
> I am
Ben Finney wrote:
We
should certainly not have a compiler that makes needless difference to
code behaviour under test conditions versus non-test conditions.
Indeed. Volkswagen tried a version of that recently,
and it didn't end well...
--
Greg
--
https://mail.python.org/mailman/listinfo/pytho
On Mon, 9 Nov 2015 09:35 am, BartC wrote:
> Suppose this is the python program:
>
> import m
> a=10
> b=20
> c=30
> m.f()
>
> The set of global names the compiler knows will be ("m","a","b","c").
Wrong. Up to the line "c=30", the set of names the compiler can infer are m,
a, b and c. Once the l
Chris Angelico writes:
> Hmm, then I was misunderstanding what BartC was advocating. I didn't
> think it would *fail* in the presence of dynamic attributes, but
> merely *perform suboptimally* (and presumably worse than current
> CPython).
There isn't a way for the compiler to *know*, in all cas
On Sun, 8 Nov 2015 11:39 pm, BartC wrote:
>> shutil.copyfileobj(Source(), Dest())
>>
>
> OK, so here, it is necessary to resolve "copyfileobj" by seeing if
> "shutil" is something that contains a name "copyfileobj" that hap
On Mon, Nov 9, 2015 at 11:50 AM, Ben Finney wrote:
> You misunderstand me. I'm not saying the optimisations would be
> crippled. I am saying that, in order to achieve those optimisations, the
> *test code* would be crippled.
>
> I am pointing out that the assumption necessary for the optimisation
Chris Angelico writes:
> On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney
> wrote:
> > Chris Angelico writes:
> >
> >> Testing/mocking is a completely separate consideration (eg you can
> >> inject a shadow for a built-in name)
> >
> > Not for the purpose of making compiler optimisations, as BartC
On Sun, 8 Nov 2015 11:28 pm, Chris Angelico wrote:
> On Sun, Nov 8, 2015 at 10:19 PM, BartC wrote:
>> I've never understood why this seems to be necessary in Python. Why do
>> names have to be looked up? (I'm assuming this is searching by name in
>> some sort of table.)
>
> Yes, if by "searching
On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney wrote:
> Chris Angelico writes:
>
>> Testing/mocking is a completely separate consideration (eg you can
>> inject a shadow for a built-in name)
>
> Not for the purpose of making compiler optimisations, as BartC is
> advocating.
>
> The compiler definite
Chris Angelico writes:
> Testing/mocking is a completely separate consideration (eg you can
> inject a shadow for a built-in name)
Not for the purpose of making compiler optimisations, as BartC is
advocating.
The compiler definitely should not treat “is this code part of a test
suite?” as a rel
On 09/11/2015 00:00, Ben Finney wrote:
BartC writes:
Is this typical Python code? Creating global objects in other modules
(or writing all over essential data structures in a library module).
Not “creating global objects”, but changing the referent of a name in
some other module. Yes, that's
On Mon, Nov 9, 2015 at 11:00 AM, Ben Finney wrote:
> BartC writes:
>
>> Is this typical Python code? Creating global objects in other modules
>> (or writing all over essential data structures in a library module).
>
> Not “creating global objects”, but changing the referent of a name in
> some ot
BartC writes:
> Is this typical Python code? Creating global objects in other modules
> (or writing all over essential data structures in a library module).
Not “creating global objects”, but changing the referent of a name in
some other module. Yes, that's quite a common technique. Does that
su
On 08/11/2015 23:13, Dennis Lee Bieber wrote:
On Sun, 8 Nov 2015 18:58:36 +, BartC declaimed the
following:
But then, you say that additional attributes, potentially millions of
different ones, can be invented at runtime. Although I don't see how it
can remove names that are part of the so
BartC writes:
> On 08/11/2015 21:00, Ben Finney wrote:
> > The namespace can change dynamically, which is another way of what
> > people have been trying to tell you all through this thread.
> >
> > The compiler *cannot* know what the names will be at every single
> > point they'll be looked un i
On 08/11/2015 21:00, Ben Finney wrote:
BartC writes:
I've never understood why this seems to be necessary in Python. Why do
names have to be looked up? (I'm assuming this is searching by name in
some sort of table.)
No, it is literally looking the name up as a key in a namespace
dictionary —
BartC writes:
> I've never understood why this seems to be necessary in Python. Why do
> names have to be looked up? (I'm assuming this is searching by name in
> some sort of table.)
No, it is literally looking the name up as a key in a namespace
dictionary — which is just like any other Python
On Nov 8, 2015 12:01 PM, "BartC" wrote:
>
> But then, you say that additional attributes, potentially millions of
different ones, can be invented at runtime. Although I don't see how it can
remove names that are part of the source code: if "A.B" is in the file,
then surely "A" and "B" always have
On 08/11/2015 18:01, Chris Angelico wrote:
On Mon, Nov 9, 2015 at 4:54 AM, BartC wrote:
That would be true for locals as well. But as far as I can tell from the
CPython source code, byte-codes uses an index to represent a local, which
represents an entry into a linear table.
I can't quite see
On Mon, Nov 9, 2015 at 4:54 AM, BartC wrote:
> That would be true for locals as well. But as far as I can tell from the
> CPython source code, byte-codes uses an index to represent a local, which
> represents an entry into a linear table.
>
> I can't quite see why that can't be done for global nam
On 08/11/2015 15:59, Michael Torrie wrote:
On 11/08/2015 04:19 AM, BartC wrote:
That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.
I've never understood why this seems to be necessary in Python. Why do
names have to be look
On 11/08/2015 04:19 AM, BartC wrote:
>> That elegant dynamism comes at a cost: method lookup is not a constant
>> memory offset. Rather, it is a dictionary lookup.
>
> I've never understood why this seems to be necessary in Python. Why do
> names have to be looked up? (I'm assuming this is searc
On Mon, Nov 9, 2015 at 12:42 AM, BartC wrote:
> Sorry, you'll have to assume I'm very stupid.
>
> What exactly is being looked up, and in what?
>
> From what I can understand in your example:
>
> * You are calling shutil.copyfileobj with two arguments, which happen to be
> instances of classes Sou
BartC :
>>> On 08/11/2015 11:50, Marko Rauhamaa wrote:
import shutil
class Source:
def __init__(self):
self.remaining = "hello world"
def read(self, count):
On 08/11/2015 12:43, Marko Rauhamaa wrote:
BartC :
On 08/11/2015 11:50, Marko Rauhamaa wrote:
import shutil
class Source:
def __init__(self):
self.remaining = "hello world"
def read(self, count):
BartC :
> On 08/11/2015 11:50, Marko Rauhamaa wrote:
>>
>> import shutil
>>
>> class Source:
>> def __init__(self):
>> self.remaining = "hello world"
>>
>> def read(self, count):
>> if count <= 0:
On 08/11/2015 11:50, Marko Rauhamaa wrote:
BartC :
On 08/11/2015 11:02, Marko Rauhamaa wrote:
That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.
I've never understood why this seems to be necessary in Python. Why do
names
On Sun, Nov 8, 2015 at 10:19 PM, BartC wrote:
> I've never understood why this seems to be necessary in Python. Why do names
> have to be looked up? (I'm assuming this is searching by name in some sort
> of table.)
Yes, if by "searching" you include hash-table lookup. A CPython
dictionary is a *h
On 08/11/2015 11:30, Steven D'Aprano wrote:
On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:
This is what I mean about people not understanding it!
I'm pretty sure I understand what *I* mean by constant, and what Pascal
means by it, and why the Pascal meaning doesn't quite match what Python can
do.
BartC :
> On 08/11/2015 11:02, Marko Rauhamaa wrote:
>> That elegant dynamism comes at a cost: method lookup is not a constant
>> memory offset. Rather, it is a dictionary lookup.
>
> I've never understood why this seems to be necessary in Python. Why do
> names have to be looked up? (I'm assuming
On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:
> On 08/11/2015 02:59, Steven D'Aprano wrote:
>> On Sun, 8 Nov 2015 02:01 am, Bartc wrote:
>>
>>> Neither have the simplicity of concept of Pascal's 'const', which is
>>> just a named value. Not a variable that won't change once initialised,
>>> not a para
Steven D'Aprano :
> So... you have no need for Python to be fast, and even less need for
> Python code to be correct...
Correct. If I didn't think so, I'd still be using Java instead of
Python.
> Or perhaps you mean that you don't need help writing correct code,
> because your code is perfect...
On 08/11/2015 11:02, Marko Rauhamaa wrote:
Bartc :
(In the case of Python, the main obstacle is that a constant name from
inside an imported module is not visible when this module is compiled
to byte-code. So it has to assume it can be anything.)
Which it can.
That elegant dynamism com
On Sun, 8 Nov 2015 08:44 pm, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
>>> Correct. That's not Python's fault, however. Python should not try to
>>> placate the performance computing people. (Alas, it is now trying to
>>> do just that with t
On 08/11/2015 03:50, Steven D'Aprano wrote:
On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
Your point of view is really down-to-earth. It's slightly analogous to
protesting against Unicode because you only ever need ASCII.
I don't think so, but in any case, Bart is *way* oversimplifying
Bartc :
> (In the case of Python, the main obstacle is that a constant name from
> inside an imported module is not visible when this module is compiled
> to byte-code. So it has to assume it can be anything.)
Which it can.
Optimizing for naive floating-point constants could be done but has
bare
On 08/11/2015 02:59, Steven D'Aprano wrote:
On Sun, 8 Nov 2015 02:01 am, Bartc wrote:
Neither have the simplicity of concept of Pascal's 'const', which is
just a named value. Not a variable that won't change once initialised,
not a parameter that won't be changed nor any addressable location.)
Paul Rubin :
> Marko Rauhamaa writes:
>> Point is, the consequences of "proper" use of const are so annoying even
>> standard library functions would rather grossly abuse it than tolerate
>> compiler warnings everywhere.
>
> I'm not sure what the C standard says about that example, but C++ is
> m
Steven D'Aprano :
> On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
>> Correct. That's not Python's fault, however. Python should not try to
>> placate the performance computing people. (Alas, it is now trying to
>> do just that with the introduction of static typing annotation.)
>
> That is fa
Marko Rauhamaa writes:
> Point is, the consequences of "proper" use of const are so annoying even
> standard library functions would rather grossly abuse it than tolerate
> compiler warnings everywhere.
I'm not sure what the C standard says about that example, but C++ is
much stricter about those
Am 08.11.15 um 08:45 schrieb Marko Rauhamaa:
Grant Edwards :
On 2015-11-07, Marko Rauhamaa wrote:
"const" is a very ineffective tool that clutters the code and forces
you to sprinkle type casts around your code.
But it allows the compiler to warn you if you pass a pointer to a
read-only dat
Grant Edwards :
> On 2015-11-07, Marko Rauhamaa wrote:
>> "const" is a very ineffective tool that clutters the code and forces
>> you to sprinkle type casts around your code.
>
> But it allows the compiler to warn you if you pass a pointer to a
> read-only data to a function that expects a pointe
Steven D'Aprano writes:
> Surely that is obvious? I don't speak much C, but I would expect that inside
> the functions, const parameters can be read, but not assigned to. "*const"
> is a mystery to me though.
There's a program (and now a website) called cdecl that can decode these:
char *const e
On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
> Bartc :
>
>> Not just my option. From this 2010 paper for example ('High performance
>> implementation of Python for CLI ...' by Antonio Cuni):
>>
>> "As a language, Python is very hard to implement efficiently: the
>> presence of highly dynami
On 2015-11-07, Marko Rauhamaa wrote:
> Grant Edwards :
>
>> I take it you don't write embedded code that runs from ROM? I do. The
>> const keyword is the most valuable addition to the C language since
>> the function prototype. Without it, you used to have to jump through
>> all sorts of hoops to
On Sun, 8 Nov 2015 04:46 am, Marko Rauhamaa wrote:
> Bartc :
>
>> (Yes, 'const' in C is a waste of time, and half the people using it
>> don't appear to know what it means.
>
> It cannot mean anything meaningful; it's completely useless.
>
> For example, what could one think of standard library
On Sun, 8 Nov 2015 02:01 am, Bartc wrote:
> Neither have the simplicity of concept of Pascal's 'const', which is
> just a named value. Not a variable that won't change once initialised,
> not a parameter that won't be changed nor any addressable location.)
Unfortunately the concept of "named valu
On Sun, Nov 8, 2015 at 10:32 AM, Ben Finney wrote:
> I recommend you ignore that request; “Bartc” is fine as a name here,
> IMO.
Given that LARTC means Linux Advanced Routing and Traffic Control, I'm
guessing Bartc is all about *BSD networking? :)
ChrisA
--
https://mail.python.org/mailman/listi
Bartc writes:
> On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote:
> > Bartc wrote:
> > ^
> > Please fix.
>
> What's the problem?
As far as I can tell, you're being asked to change that to your “real”
name, whatever that is supposed to mean.
I recommend you ignore that request; “Bartc” i
On 07/11/2015 23:02, Bartc wrote:
On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote:
Bartc wrote:
^
Please fix.
What's the problem?
He is the problem. I assume it's because he thinks he's a dog, cat or
some other animal.
--
My fellow Pythonistas, ask not what our language can do
On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote:
Bartc wrote:
^
Please fix.
What's the problem?
--
https://mail.python.org/mailman/listinfo/python-list
Grant Edwards :
> I take it you don't write embedded code that runs from ROM? I do. The
> const keyword is the most valuable addition to the C language since
> the function prototype. Without it, you used to have to jump through
> all sorts of hoops to get read-only data placed into read-only memo
Bartc :
> (Yes, 'const' in C is a waste of time, and half the people using it
> don't appear to know what it means.
It cannot mean anything meaningful; it's completely useless.
For example, what could one think of standard library functions whose
prototypes are:
char *strstr(const char *hays
On 2015-11-07, Marko Rauhamaa wrote:
> Marko Rauhamaa :
>
>> In my work, I currently use bash, Python and C. For many, many tasks,
>> bash is superior to Python. For others, Python can't compete with C.
>> Yet the vast gap between bash and C is nicely filled with Python.
>
> And, by the way, the i
On 07/11/2015 14:23, Marko Rauhamaa wrote:
Bartc :
In my work, I currently use bash, Python and C. For many, many tasks,
bash is superior to Python. For others, Python can't compete with C. Yet
the vast gap between bash and C is nicely filled with Python.
The gap between Python and C is stil
On 07/11/2015 14:28, Marko Rauhamaa wrote:
Marko Rauhamaa :
In my work, I currently use bash, Python and C. For many, many tasks,
bash is superior to Python. For others, Python can't compete with C.
Yet the vast gap between bash and C is nicely filled with Python.
And, by the way, the introdu
Marko Rauhamaa :
> In my work, I currently use bash, Python and C. For many, many tasks,
> bash is superior to Python. For others, Python can't compete with C.
> Yet the vast gap between bash and C is nicely filled with Python.
And, by the way, the introduction of the "const" keyword was maybe th
Bartc :
> Not just my option. From this 2010 paper for example ('High performance
> implementation of Python for CLI ...' by Antonio Cuni):
>
> "As a language, Python is very hard to implement efficiently: the
> presence of highly dynamic constructs makes static analysis of
> programs extremely di
In a message of Sat, 07 Nov 2015 13:00:37 +, Bartc writes:
>Not just my option. From this 2010 paper for example ('High performance
>implementation of Python for CLI ...' by Antonio Cuni):
>
>"As a language, Python is very hard to implement efficiently: the
>presence of highly dynamic constr
On 07/11/2015 12:15, Ben Finney wrote:
Bartc writes:
To my mind, Python allows far too much freedom in being able to change
anything at any time.
You're welcome to that opinion. I don't see you present a reason why it
should affect anyone else's opinion of Python, though.
Not just my optio
Bartc writes:
> To my mind, Python allows far too much freedom in being able to change
> anything at any time.
You're welcome to that opinion. I don't see you present a reason why it
should affect anyone else's opinion of Python, though.
> Yet Python has to assume 100% of the time that it could
On 07/11/2015 11:35, Ben Finney wrote:
Bartc writes:
On 07/11/2015 03:43, Ben Finney wrote:
Bartc writes:
Is there no way then in Python to declare:
pi = 3.141519 # etc
and make it impossible to override?
No, and it would be a bad thing if that were something a library author
Bartc writes:
> On 07/11/2015 03:43, Ben Finney wrote:
> > Bartc writes:
> >
> >> Is there no way then in Python to declare:
> >>
> >> pi = 3.141519 # etc
> >>
> >> and make it impossible to override?
> >
> > No, and it would be a bad thing if that were something a library author
> > cou
On 07/11/2015 03:43, Ben Finney wrote:
Bartc writes:
Is there no way then in Python to declare:
pi = 3.141519 # etc
and make it impossible to override?
No, and it would be a bad thing if that were something a library author
could forbid.
Python assumes the programmers using it are
Bartc writes:
> Is there no way then in Python to declare:
>
>pi = 3.141519 # etc
>
> and make it impossible to override?
No, and it would be a bad thing if that were something a library author
could forbid.
Python assumes the programmers using it are consenting adults. Doing
harmful th
On Sat, 7 Nov 2015 09:26 am, Thomas 'PointedEars' Lahn wrote:
^
> Bartc wrote:
> ^
> Please fix.
Why? There's nothing wrong with somebody signing their posts "Bartc". It is
no more silly than somebody calling themselves "PointedEars". Please sto
On Sat, 7 Nov 2015 09:19 am, Thomas 'PointedEars' Lahn wrote:
> It is certainly possible for attributes of (instances of) new-style
> classes (starting with Python 3.2 at the latest) to be read-only by
> declaring them a property that does not have a setter, or one that has a
> setter that throws
On 11/6/2015 5:26 PM, Thomas 'PointedEars' Lahn wrote:
Bartc wrote:
import math
math.pi=0
print (math.pi)
In Python, presumably 'pi' is just another variable, and variables can
be written to.
“pi” is the name of an attribute of the module object referred to by “math”.
(Perhaps math.pi w
1 - 100 of 112 matches
Mail list logo
