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
Thomas 'PointedEars' Lahn wrote:
> In theory, it should be possible to substitute “math” with a reference to
> an object that acts as a proxy for the original “math” module object but
> whose base class declares the attributes for all the constants read-only.
#!/usr/bin/env python3
#-
Bartc wrote:
^
Please fix.
> On 06/11/2015 02:33, wa...@travelsky.com wrote:
>> As you can see in the attachment, why i can modify "math.pi"?
>> (in "mathmodule.c" "pi" is a "static const double")
>
> Python isn't C.
>
> Your attachment isn't visible, but it can be demonstrated eas
Chris Angelico wrote:
> On Sat, Nov 7, 2015 at 6:30 AM, Bartc wrote:
>> Is there no way then in Python to declare:
>>
>>pi = 3.141519 # etc
>>
>> and make it impossible to override?
>
> Nope. Even in C++, where classes can define certain things as const,
> private, and other such restric
Am 06.11.15 um 20:40 schrieb Chris Angelico:
On Sat, Nov 7, 2015 at 6:30 AM, Bartc wrote:
Is there no way then in Python to declare:
pi = 3.141519 # etc
and make it impossible to override?
Nope. Even in C++, where classes can define certain things as const,
private, and other such r
On Sat, Nov 7, 2015 at 6:30 AM, Bartc wrote:
> Is there no way then in Python to declare:
>
>pi = 3.141519 # etc
>
> and make it impossible to override?
Nope. Even in C++, where classes can define certain things as const,
private, and other such restrictions, you can always get around the
On 06/11/2015 16:12, Lorenzo Sutton wrote:
On 06/11/2015 13:30, Bartc wrote:
On 06/11/2015 02:33, wa...@travelsky.com wrote:
Hello, python-list guys:
I am a newbie of python from Beijing. China.
I have a question about "math.pi".
As you can see in the attachment, why i can mod
On 06/11/2015 13:30, Bartc wrote:
On 06/11/2015 02:33, wa...@travelsky.com wrote:
Hello, python-list guys:
I am a newbie of python from Beijing. China.
I have a question about "math.pi".
As you can see in the attachment, why i can modify "math.pi"?
(in "mathmodule.c" "pi"
Chris Angelico :
> Simply because, in Python, virtually everything can be changed. You're
> welcome to go in and say "math.pi = 3" if you like... and then you
> accept the consequences of that.
How far cosmology would have evolved by now if Albert Einstein had had
Python at his disposal. He could
On 06/11/2015 02:33, wa...@travelsky.com wrote:
Hello, python-list guys:
I am a newbie of python from Beijing. China.
I have a question about "math.pi".
As you can see in the attachment, why i can modify "math.pi"?
(in "mathmodule.c" "pi" is a "static const double")
Python
On Nov 6, 2015 3:20 AM, "wa...@travelsky.com" wrote:
>
> Hello, python-list guys:
>
> I am a newbie of python from Beijing. China.
> I have a question about "math.pi".
> As you can see in the attachment, why i can modify "math.pi"?
> (in "mathmodule.c" "pi" is a "static const doubl
On Fri, Nov 6, 2015 at 1:33 PM, wa...@travelsky.com wrote:
> Hello, python-list guys:
>
> I am a newbie of python from Beijing. China.
> I have a question about "math.pi".
> As you can see in the attachment, why i can modify "math.pi"?
> (in "mathmodule.c" "pi" is a "static const d
On Wed, 30 Sep 2015 23:30:47 +, Denis McMahon wrote:
> On Wed, 30 Sep 2015 11:34:04 -0700, massi_srb wrote:
>
>> firstly the description of my problem. I have a string in the following
>> form: .
>
> The way I solved this was to:
>
> 1) replace all the punctuation in the string with spa
On Oct 2, 2015 12:35 AM, "Denis McMahon" wrote:
>
> On Thu, 01 Oct 2015 01:48:03 -0700, gal kauffman wrote:
>
> > items = s.replace(' (', '(').replace(', ',',').split()
> >
> > items_dict = dict()
> > for item in items:
> > if '(' not in item:
> > item += '(0,0)'
> > if ',' not in
On Thu, 01 Oct 2015 15:53:38 +, Rob Gaddi wrote:
> There's a quote for this. 'Some people, when confronted with a problem,
> think “I know, I'll use regular expressions.” Now they have two
> problems.'
I actually used 2 regexes:
wordpatt = re.compile('[a-zA-Z]+')
numpatt = re.compile('[0-
On Thu, 01 Oct 2015 01:48:03 -0700, gal kauffman wrote:
> items = s.replace(' (', '(').replace(', ',',').split()
>
> items_dict = dict()
> for item in items:
> if '(' not in item:
> item += '(0,0)'
> if ',' not in item:
> item = item.replace(')', ',0)')
>
> name, raw_
On Wed, 30 Sep 2015 11:34:04 -0700, massi_srb wrote:
> Hi everyone,
>
> firstly the description of my problem. I have a string in the following
> form:
>
> s = "name1 name2(1) name3 name4 (1, 4) name5(2) ..."
>
> that is a string made up of groups in the form 'name' (letters only)
> plus possib
My example will give false positive if there is a space before a comma. Or
anything else by the conventions in the original string.
I tried to keep it as simple as I could.
If you want to catch a wider range of values you can use *simple* regular
expression to catch as much spaces as you want.
On O
On 2015-10-01 01:48, gal kauffman wrote:
> items = s.replace(' (', '(').replace(', ',',').split()
s = "name1 (1)"
Your suggestion doesn't catch cases where more than one space can
occur before the paren.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
items = s.replace(' (', '(').replace(', ',',').split()
items_dict = dict()
for item in items:
if '(' not in item:
item += '(0,0)'
if ',' not in item:
item = item.replace(')', ',0)')
name, raw_data = item.split('(')
data_tuple = tuple((int(v) for v in
raw_data.repla
On 9/30/2015 12:20 PM, Tim Chase wrote:
On 2015-09-30 11:34, massi_...@msn.com wrote:
I guess this problem can be tackled with regular expressions, b
... However, if you *want* to do it with
regular expressions, you can. It's ugly and might be fragile, but
##
On Wed, 30 Sep 2015 11:34:04 -0700, massi_srb wrote:
> firstly the description of my problem. I have a string in the following
> form: .
The way I solved this was to:
1) replace all the punctuation in the string with spaces
2) split the string on space
3) process each thing in the list to
On 2015-09-30 11:34, massi_...@msn.com wrote:
> firstly the description of my problem. I have a string in the
> following form:
>
> s = "name1 name2(1) name3 name4 (1, 4) name5(2) ..."
>
> that is a string made up of groups in the form 'name' (letters
> only) plus possibly a tuple containing 1 or
501 - 600 of 2803 matches
Mail list logo
