Thomas 'PointedEars' Lahn wrote:
>> I haven't read the descriptor protocol as yet.
>
> You should. You should also trim your quotations to the relevant
> minimum, and post using your real name.
>
I don't take advice from people on USENET who DON'T have a long history
of helping ME - unless I'
On 3/12/2016 8:20 PM, Steven D'Aprano wrote:
Yeah, we get it. The CPython interpreter is plenty fast enough for whatever
you use it for. Good for you! Millions aren't so lucky. They are looking
for something faster, because for them, you can never have too much speed.
When you are trying to solv
On Sun, Mar 13, 2016 at 2:36 PM, Rick Johnson
wrote:
> On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote:
>> Also, if currentModule.py is pulling foo from modX, then modZ.py is an
>> implementation detail. You don't necessarily want to go straight
>> there; tracing the chain is
On Sat, Mar 12, 2016 at 9:57 PM, Aaron Christensen <
aaron.christen...@gmail.com> wrote:
>
>
> On Sat, Mar 12, 2016 at 5:03 AM, dieter wrote:
>
>> Aaron Christensen writes:
>> > I am running the following versions of software:
>> >
>> > Python 3.5
>> > psycopg2==2.6.1
>> > Postgres 9.4.5
>> >
>>
On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote:
> Also, if currentModule.py is pulling foo from modX, then modZ.py is an
> implementation detail. You don't necessarily want to go straight
> there; tracing the chain is more likely to be the correct behaviour.
> Suppose modX.py
On Sun, 13 Mar 2016 02:36 am, alister wrote about building up strings by
repeated concatenation:
> So you are bench marking python performance on a programming paradigm
> that is not good python practice.
>
> A pointless exercise
> what may be the best way to achieve a rsult in one language is n
On Saturday, March 12, 2016 at 10:45:43 AM UTC-6, Ian wrote:
> On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson
> wrote:
> > At run-time, i don't care how large a "module namespace" may
> > be. Sometimes a module namespace will be small, with only a
> > few exposed symbols, but sometimes, a module na
On Sat, Mar 12, 2016 at 5:03 AM, dieter wrote:
> Aaron Christensen writes:
> > I am running the following versions of software:
> >
> > Python 3.5
> > psycopg2==2.6.1
> > Postgres 9.4.5
> >
> > I have 2 tables. Table User has UserId (serial PK), LastName, FirstName,
> > Gender, DateOfBirth, and
On Sat, Mar 12, 2016 at 5:26 AM, Peter Otten <__pete...@web.de> wrote:
> Aaron Christensen wrote:
>
> > Hello,
> >
> > I am running the following versions of software:
> >
> > Python 3.5
> > psycopg2==2.6.1
> > Postgres 9.4.5
> >
> > I have 2 tables. Table User has UserId (serial PK), LastName, F
On 13/03/2016 02:01, Steven D'Aprano wrote:
On Sun, 13 Mar 2016 10:57 am, BartC wrote:
I use 'const' everywhere in other languages, most often in the form of
sophisticated sets of enums. A single project might have 1000 or even
2000. (Example that defines a set of byte-codes:
http://pastebin.co
Mark Lawrence writes:
> BartC would still be a complete idiot, as the complete crap that he's
> been spewing over the last days puts him into the same league as the
> RUE, possibly worse. It is so obvious that he knows nothing about
> Python that I find it stunning that you can even contemplate
>
On Sun, 13 Mar 2016 10:57 am, BartC wrote:
> I use 'const' everywhere in other languages, most often in the form of
> sophisticated sets of enums. A single project might have 1000 or even
> 2000. (Example that defines a set of byte-codes:
> http://pastebin.com/q1UwjKmK)
>
> How does Python manage
On Sun, Mar 13, 2016 at 12:32 PM, Mark Lawrence wrote:
>
> Python works and is extremely successful. If it were made even faster it
> would be even more successful. BartC would still be a complete idiot, as
> the complete crap that he's been spewing over the last days puts him into
> the same le
On 13/03/2016 01:20, Steven D'Aprano wrote:
On Sun, 13 Mar 2016 04:02 am, Mark Lawrence wrote:
So I am clearly not the only programmer in the world who couldn't care
less about speed.
For somebody who couldn't care less, you sure do keep going on and on and on
and on and on and on and on abo
On Sun, 13 Mar 2016 04:02 am, Mark Lawrence wrote:
> So I am clearly not the only programmer in the world who couldn't care
> less about speed.
For somebody who couldn't care less, you sure do keep going on and on and on
and on and on and on and on about it.
Yeah, we get it. The CPython interpr
On 12/03/2016 23:57, BartC wrote:
On 12/03/2016 22:10, Marko Rauhamaa wrote:
Chris Angelico :
I completely agree with you that the keyword should mean "write-once"
or "never rebind".
That would be possible. I'm afraid that would result in people
sprinkling these "constant" keywords everywher
On 12/03/2016 22:10, Marko Rauhamaa wrote:
Chris Angelico :
I completely agree with you that the keyword should mean "write-once"
or "never rebind".
That would be possible. I'm afraid that would result in people
sprinkling these "constant" keywords everywhere to make the program
supposedly ru
Chris Angelico :
> On Sun, Mar 13, 2016 at 9:10 AM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> I completely agree with you that the keyword should mean
>>> "write-once" or "never rebind".
>>
>> That would be possible. I'm afraid that would result in people
>> sprinkling these "constant" key
On Sun, Mar 13, 2016 at 9:10 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> I completely agree with you that the keyword should mean "write-once"
>> or "never rebind".
>
> That would be possible. I'm afraid that would result in people
> sprinkling these "constant" keywords everywhere to make th
On 12/03/2016 19:26, Thomas 'PointedEars' Lahn wrote:
BartC wrote:
On 12/03/2016 12:13, Marko Rauhamaa wrote:
Why, look at the *English* page on Hillary Clinton:
Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born
October 26, 1947) is an American politician.
htt
Chris Angelico :
> I completely agree with you that the keyword should mean "write-once"
> or "never rebind".
That would be possible. I'm afraid that would result in people
sprinkling these "constant" keywords everywhere to make the program
supposedly run faster. -- Something like that has happen
On Sun, Mar 13, 2016 at 3:22 AM, Steven D'Aprano wrote:
> On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote:
>
>
Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy; there currently isn't a
way, and I'm not sure whether FAT P
On Sun, Mar 13, 2016 at 6:24 AM, Thomas 'PointedEars' Lahn
wrote:
> Marko Rauhamaa wrote:
>
>> […] HTML markup is all ASCII.
>
> Wrong. I am creating HTML documents whose source code contains Unicode
> characters every day.
>
> Also, the two of you fail to differentiate between US-ASCII, a 7-bit
On Sun, Mar 13, 2016 at 3:49 AM, Rick Johnson
wrote:
> Imagine this scenario:
>
>
> # currentModule.py #
>
> from modX import foo
>
> def bar():
> return foo()
>
> ###
> # modX.py #
> ###
> from m
BartC wrote:
> On 12/03/2016 12:13, Marko Rauhamaa wrote:
>> Why, look at the *English* page on Hillary Clinton:
>>
>> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born
>> October 26, 1947) is an American politician.
>> https://en.wikipedia.org/wiki/Hillary_Clinton>
>
Marko Rauhamaa wrote:
> […] all keyboards can produce ASCII and no keyboard can produce all of
> Unicode.
Both claims are wrong.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
> […] HTML markup is all ASCII.
Wrong. I am creating HTML documents whose source code contains Unicode
characters every day.
Also, the two of you fail to differentiate between US-ASCII, a 7-bit
character encoding, and 8-bit or longer encodings which can *also* encode
ch
On Sat, 12 Mar 2016 16:42:47 +, BartC wrote:
> On 12/03/2016 15:30, Chris Angelico wrote:
>> On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote:
>
>>> However, I was going to revise my benchmark to use strings instead of
>>> integers, to show how much slower they would be. But the program was
>>>
On 12/03/2016 18:07, Marko Rauhamaa wrote:
BartC :
No it's very easy. In Python terms:
def f(): return "One"
def g(): return "Two"
h=f
h() returns "One". Later you do h=g, and h() returns "Two". No need
for f and g themselves to be dynamic. h just needs to be a variable.
Well, what do you
BartC :
> No it's very easy. In Python terms:
>
> def f(): return "One"
> def g(): return "Two"
>
> h=f
>
> h() returns "One". Later you do h=g, and h() returns "Two". No need
> for f and g themselves to be dynamic. h just needs to be a variable.
Well, what do you make of this:
>>> def f(): r
On 12/03/2016 16:56, Steven D'Aprano wrote:
On Sun, 13 Mar 2016 12:42 am, BartC wrote:
Ad-hoc attributes I don't have as much of a problem with, as they can be
handy. But predefined ones also have their points. (For one thing, I
know how to implement those efficiently.)
However, when you have
Veek. M wrote:
> Veek. M wrote:
>> class TypedProperty(object):
>> def __init__(self,name,type,default=None):
>> self.name = "_" + name
>> self.type = type
>> self.default = default if default else type()
>>
>> def __get__(self,instance,cls):
>> return geta
On 12/03/2016 16:42, BartC wrote:
On 12/03/2016 15:30, Chris Angelico wrote:
On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote:
However, I was going to revise my benchmark to use strings instead of
integers, to show how much slower they would be. But the program was 10%
faster with strings!
So
On Sun, 13 Mar 2016 12:42 am, BartC wrote:
> Ad-hoc attributes I don't have as much of a problem with, as they can be
> handy. But predefined ones also have their points. (For one thing, I
> know how to implement those efficiently.)
>
> However, when you have a function call like this: M.F(), whe
On Friday, March 11, 2016 at 6:52:42 PM UTC-6, Gregory Ewing wrote:
> Rick Johnson wrote:
> > I have witnessed the mayhem that occurs when a language does
> > not mandate module encapsulation (Ruby, i'm looking directly
> > at you), and while i agree with the Python designers
> > that modules m
On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson
wrote:
> At run-time, i don't care how large a "module namespace" may
> be. Sometimes a module namespace will be small, with only a
> few exposed symbols, but sometimes, a module namespace will
> expose thousands of symbols.
Thousands, really? What sy
On 12/03/2016 15:30, Chris Angelico wrote:
On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote:
However, I was going to revise my benchmark to use strings instead of
integers, to show how much slower they would be. But the program was 10%
faster with strings!
So there's something funny going on.
On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote:
>>> Definitely agree with this. Having a way to declare that a name is
>>> "truly constant" would be extremely handy; there currently isn't a
>>> way, and I'm not sure whether FAT Python is looking into this or not.
"Constants" would be a new l
On Sat, 12 Mar 2016 10:31:39 +, BartC wrote:
> On 12/03/2016 10:06, alister wrote:
>> On Fri, 11 Mar 2016 22:24:45 +, BartC wrote:
>>
>>> On 11/03/2016 21:59, Mark Lawrence wrote:
On 11/03/2016 18:57, BartC wrote:
>>>
def test():
s=""
for i in range(1000
On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote:
> That explains why you rarely use integers, if you prefer to use strings even
> when there is a choice!
>
> However, I was going to revise my benchmark to use strings instead of
> integers, to show how much slower they would be. But the program was 10
On Sat, 12 Mar 2016 11:08:25 +, BartC wrote:
>
> >> You're not mistaken. There are no "character constants" in Python.
> >> (Note that the definition would be Unicode codepoints, rather than
> >> ASCII values.) I don't often miss them, though.
>
>> Yes, a complete non-issue.
>
> Really?
On 12/03/2016 12:10, Chris Angelico wrote:
On Sat, Mar 12, 2016 at 10:08 PM, BartC wrote:
Writing: a=65 generates this byte-code for the right-hand-side:
LOAD_CONST 1 (65) An integer
But writing instead: a=ord('A') generates this:
LOAD_GLOBAL 0 (ord)
LOAD_CONS
On Saturday, March 12, 2016 at 3:43:16 AM UTC-6, dieter wrote:
> > archives, and then stuff the link down your big fat mouth?
> ^^^
>
> What happened that you use language like this? Obviously,
> you disagree with Steven - but this should no
BartC :
> Ad-hoc attributes I don't have as much of a problem with, as they can
> be handy. But predefined ones also have their points. (For one thing,
> I know how to implement those efficiently.)
I wonder how large a proportion of all references are top-level. My
hunch is that it is well below
BartC :
> On 12/03/2016 12:13, Marko Rauhamaa wrote:
>> BartC :
>>
>>> If you're looking at fast processing of language source code (in a
>>> thread partly about efficiency), then you cannot ignore the fact
>>> that the vast majority of characters being processed are going to
>>> have ASCII codes.
On 12/03/2016 11:51, Marko Rauhamaa wrote:
BartC :
What's big deal with dynamism anyway? I could never understand
Python's obsession with it.
For me, 'dynamic' means that a variable has a dynamic type; that's
all. But you know at compile-time (or when looking at source code)
whether a name is
On Sat, Mar 12, 2016 at 8:42 PM, dieter wrote:
> Rick Johnson writes:
>> On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote:
>> ...
>> Are you sure about that? Heck, i posted code quite a few
>> years back that "seg faulted like a mutha". Do you want to
>> retract your statement
On Sun, Mar 13, 2016 at 12:18 AM, BartC wrote:
> On 12/03/2016 12:13, Marko Rauhamaa wrote:
>>
>> BartC :
>>
>>> If you're looking at fast processing of language source code (in a
>>> thread partly about efficiency), then you cannot ignore the fact that
>>> the vast majority of characters being pr
On 12/03/2016 12:13, Marko Rauhamaa wrote:
BartC :
If you're looking at fast processing of language source code (in a
thread partly about efficiency), then you cannot ignore the fact that
the vast majority of characters being processed are going to have
ASCII codes.
I don't know why you would
On 03/12/2016 04:40 AM, alister wrote:
On Fri, 11 Mar 2016 19:15:48 -0500, Fillmore wrote:
I not sure if you were being accused of being lazy as such but actually
being given the suggestion that there are other places that you can find
these answers that are probably better for a number of reason
On Sat, Mar 12, 2016 at 11:28 PM, Steven D'Aprano wrote:
> On Sat, 12 Mar 2016 11:10 pm, Chris Angelico wrote:
>
>> On Sat, Mar 12, 2016 at 10:08 PM, BartC wrote:
> You're not mistaken. There are no "character constants" in Python.
> (Note that the definition would be Unicode codepoints,
On Sat, Mar 12, 2016 at 10:50 PM, BartC wrote:
> On 12/03/2016 02:20, Chris Angelico wrote:
>>
>> On Sat, Mar 12, 2016 at 12:16 PM, BartC wrote:
>
>
>>> 'Switch' testing benchmark. The little program show below reads a text
>>> file
>>> (I used the entire CPython C sources, 6MB), and counts the n
On Sat, 12 Mar 2016 11:10 pm, Chris Angelico wrote:
> On Sat, Mar 12, 2016 at 10:08 PM, BartC wrote:
You're not mistaken. There are no "character constants" in Python.
(Note that the definition would be Unicode codepoints, rather than
ASCII values.) I don't often miss them, though.
On 12.03.2016 00:18, Fillmore wrote:
Playing with ArgumentParser. I can't find a way to override the -h and
--help options so that it provides my custom help message.
I remember everything being a lot easier using argh instead of argparse.
https://pypi.python.org/pypi/argh#examples
The doc
BartC :
> If you're looking at fast processing of language source code (in a
> thread partly about efficiency), then you cannot ignore the fact that
> the vast majority of characters being processed are going to have
> ASCII codes.
I don't know why you would optimize for inputting program source
On Sat, Mar 12, 2016 at 10:08 PM, BartC wrote:
>>> You're not mistaken. There are no "character constants" in Python.
>>> (Note that the definition would be Unicode codepoints, rather than
>>> ASCII values.) I don't often miss them, though.
>
>> Yes, a complete non-issue.
>
>
> Really? The issue a
BartC :
> What's big deal with dynamism anyway? I could never understand
> Python's obsession with it.
>
> For me, 'dynamic' means that a variable has a dynamic type; that's
> all. But you know at compile-time (or when looking at source code)
> whether a name is a variable, or a function, class, m
On 12/03/2016 02:20, Chris Angelico wrote:
On Sat, Mar 12, 2016 at 12:16 PM, BartC wrote:
'Switch' testing benchmark. The little program show below reads a text file
(I used the entire CPython C sources, 6MB), and counts the number of
characters of each category in upper, lower, digit and oth
On 12/03/2016 11:08, BartC wrote:
On 12/03/2016 06:48, Marko Rauhamaa wrote:
Chris Angelico :
Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy;
I don't think it would be all that handy. I'm afraid all this type
hinting will turn Pyt
On 12/03/2016 06:48, Marko Rauhamaa wrote:
Chris Angelico :
Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy;
I don't think it would be all that handy. I'm afraid all this type
hinting will turn Python into a poor man's Java.
It's
On 12/03/2016 10:31, BartC wrote:
On 12/03/2016 10:06, alister wrote:
On Fri, 11 Mar 2016 22:24:45 +, BartC wrote:
On 11/03/2016 21:59, Mark Lawrence wrote:
On 11/03/2016 18:57, BartC wrote:
def test():
s=""
for i in range(1000):
s+="*"
print (len(s))
t
On Sat, Mar 12, 2016 at 9:34 PM, BartC wrote:
>> The act of "fixing" it, as you say, would change the semantics of the
>> language in a fundamental and major way. Strings by definition are
>> immutable in Python.
>
>
> Yet INPLACE_ADD is a valid byte-code even when operating on strings.
That's b
On 12/03/2016 10:06, alister wrote:
On Fri, 11 Mar 2016 22:24:45 +, BartC wrote:
On 11/03/2016 21:59, Mark Lawrence wrote:
On 11/03/2016 18:57, BartC wrote:
def test():
s=""
for i in range(1000):
s+="*"
print (len(s))
test()
The minor snag that you mi
On 12/03/2016 01:15, Michael Torrie wrote:
On 03/11/2016 03:24 PM, BartC wrote:
On 11/03/2016 21:59, Mark Lawrence wrote:
On 11/03/2016 18:57, BartC wrote:
def test():
s=""
for i in range(1000):
s+="*"
print (len(s))
test()
The minor snag that you might li
Aaron Christensen wrote:
> Hello,
>
> I am running the following versions of software:
>
> Python 3.5
> psycopg2==2.6.1
> Postgres 9.4.5
>
> I have 2 tables. Table User has UserId (serial PK), LastName, FirstName,
> Gender, DateOfBirth, and DateEnrolled. Table UserProfile has
> UserProfileId
On Fri, 11 Mar 2016 22:24:45 +, BartC wrote:
> On 11/03/2016 21:59, Mark Lawrence wrote:
>> On 11/03/2016 18:57, BartC wrote:
>
>> def test():
>> s=""
>> for i in range(1000):
>> s+="*"
>> print (len(s))
>>
>> test()
>
>> The minor snag that you might like to corr
Aaron Christensen writes:
> I am running the following versions of software:
>
> Python 3.5
> psycopg2==2.6.1
> Postgres 9.4.5
>
> I have 2 tables. Table User has UserId (serial PK), LastName, FirstName,
> Gender, DateOfBirth, and DateEnrolled. Table UserProfile has UserProfileId
> (serial, PK),
On Fri, 11 Mar 2016 17:53:45 -0500, Larry Martell wrote:
> On Fri, Mar 11, 2016 at 4:49 AM, Steven D'Aprano
> wrote:
>
>> On Fri, 11 Mar 2016 02:28 pm, rubengoods...@yahoo.com wrote:
>>
>> > I am having trouble installing the Python software.
>>
>> Make sure your computer is turned on. I can't t
On Fri, 11 Mar 2016 16:26:02 -0500, Fillmore wrote:
> On 3/11/2016 4:15 PM, Mark Lawrence wrote:
>>
>> https://docs.python.org/3/library/csv.html#csv.Dialect.doublequote
>>
>>
> thanks, but my TSV is not using any particular dialect as far as I
> understand...
>
> Thank you, anyway
Every variati
On Fri, 11 Mar 2016 19:15:48 -0500, Fillmore wrote:
> On 3/11/2016 7:12 PM, Martin A. Brown wrote:
>>
>> Aside from your csv question today, many of your questions could be
>> answered by reading through the manual documenting the standard
>> datatypes (note, I am assuming you are using Python 3).
Rick Johnson writes:
> On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote:
> ...
> Are you sure about that? Heck, i posted code quite a few
> years back that "seg faulted like a mutha". Do you want to
> retract your statement, or will i need to search the
> archives, and then stu
71 matches
Mail list logo
