On 11/05/2015 07:15, Steven D'Aprano wrote:
On Monday 11 May 2015 11:46, zipher wrote:
By having methods like len() in your built-in namespace when it's really
only relevant to objects that are types of containers, you blur one
primary component of OOP: encapsulation.
Gosh, one would almost
On Monday 11 May 2015 10:14, Mark Rosenblitt-Janssen wrote:
> In case the example given at the start of the thread wasn't
> interesting enough, it also works in the other direction:
>
class str(int): pass
>
str('2')
> 2 #<- an integer!!!
Thank the gods that you're around to poi
On Monday 11 May 2015 11:46, zipher wrote:
> By having methods like len() in your built-in namespace when it's really
> only relevant to objects that are types of containers, you blur one
> primary component of OOP: encapsulation.
Gosh, one would almost think that Python's concept of OOP wasn't
On Monday 11 May 2015 10:57, zipher wrote:
> I guess everyone expects this behavior since Python implemented this idea
> of "everything is an object", but I think this branch of OOP (on the
> branch of the Tree of Programming Languages) has to be chopped off. The
> idea of everything is an object
Steven D'Aprano schrieb am 10.05.2015 um 11:58:
> Why is calling a function faster than bypassing the function object and
> evaluating the code object itself? And not by a little, but by a lot?
>
> Here I have a file, eval_test.py:
>
> # === cut ===
> from timeit import Timer
>
> def func():
>
On Monday, May 11, 2015 at 9:29:31 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 11 May 2015 06:43 am, Chris Seberino wrote:
>
> > I'm thinking that for the VERY beginning, Scheme is the fastest language
> > to get beginners up and running writing code due to the extremely minimal
> > simple synta
On Mon, 11 May 2015 03:00 am, Terry Reedy wrote:
> Decoding a string only makes sense for rot-13
Or any other string-to-string encoding.
As has been discussed on python-ideas and python-dev many times, the idea of
a codec is much more general than just bytes -> string and string -> bytes.
It can
On Mon, 11 May 2015 07:08 am, BartC wrote:
> On 10/05/2015 10:58, Steven D'Aprano wrote:
>> from timeit import Timer
>>
>> def func():
>> a = 2
>> b = 3
>> c = 4
>> return (a+b)*(a-b)/(a*c + b*c)
>>
>>
>> code = func.__code__
>> assert func() == eval(code)
>>
>> t1 = Timer("eva
On Mon, 11 May 2015 06:43 am, Chris Seberino wrote:
> I'm thinking that for the VERY beginning, Scheme is the fastest language
> to get beginners up and running writing code due to the extremely minimal
> simple syntax.
Do you believe that learning syntax is the hardest part for beginners to get
On Monday, May 11, 2015 at 9:02:07 AM UTC+5:30, Ian wrote:
> Is exec what you're looking for?
Now Now Ian!
In classical times, corrupting the youth would fetch you a cup of hemlock.
Community service it is nowadays.
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, May 10, 2015 at 9:31 PM, Ian Kelly wrote:
> On Sun, May 10, 2015 at 7:39 PM, zipher wrote:
>> Similarly, you'd want:
>>
> encode(codestr)
>>
>> to instantiate all objects in the codestr. You can't do this with eval,
>> because it doesn't allow assignment (eval(n=2) returns "InvalidS
On Sun, May 10, 2015 at 7:39 PM, zipher wrote:
> Similarly, you'd want:
>
encode(codestr)
>
> to instantiate all objects in the codestr. You can't do this with eval,
> because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").
Is exec what you're looking for?
>>> exec('n = 2
On Mon, 11 May 2015 03:28 am, Gary Herron wrote:
> On 05/10/2015 09:48 AM, Rustom Mody wrote:
>> On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
>>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
>>>
zipher writes:
> On Sunday, May 10, 2015 at 9:18:55 PM UTC-5, Chris Angelico wrote:
> > That actually has nothing to do with it. You're still quoting
> > without citation.
>
> Well, I replied right at the point of my correspondent (Alex23).
That's not the issue :-)
The omission Chris is referri
On Monday, May 11, 2015 at 2:46:38 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Seberino :
>
> > Instead of learning only Scheme or only Python for a one semester
> > intro course, what about learning BOTH? Maybe that could somehow get
> > the benefits of both?
> >
> > I'm thinking that for the VERY
On Sunday, May 10, 2015 at 9:18:55 PM UTC-5, Chris Angelico wrote:
> On Mon, May 11, 2015 at 12:11 PM, zipher wrote:
> >> Please take care of your quoting. You just quoted two other posts, and
> >> I have no idea who said things without going and digging in the
> >> archive.
> >
> > I'm sorry. I'
On Mon, May 11, 2015 at 12:12 PM, Rustom Mody wrote:
> On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
>> And I still don't see how this has anything to do with your confusion
>> about shadowing the name 'int'.
>
> Speaking as a compiler-writer -- everything :-)
>
> In C 'int
On Mon, May 11, 2015 at 12:11 PM, zipher wrote:
>> Please take care of your quoting. You just quoted two other posts, and
>> I have no idea who said things without going and digging in the
>> archive.
>
> I'm sorry. I've been sleeping on the beach, away from civilization, a little
> too long, an
On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'.
Speaking as a compiler-writer -- everything :-)
In C 'int' is tagged off as different from 'myvar' earlier than say
'myva
> Please take care of your quoting. You just quoted two other posts, and
> I have no idea who said things without going and digging in the
> archive.
I'm sorry. I've been sleeping on the beach, away from civilization, a little
too long, and didn't see that this was a post from 6 years ago.
Feel
On Mon, May 11, 2015 at 6:43 AM, Chris Seberino wrote:
> Instead of learning only Scheme or only Python for a one semester intro
> course, what about learning BOTH? Maybe that could somehow
> get the benefits of both?
>
> I'm thinking that for the VERY beginning, Scheme is the fastest language
>
> > Okay. I apologize for thinking in C and believing "int" was a keyword. It
> > isn't in Python as you remind me. However, this is where I'm arguing the
> > purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an
>
On Mon, May 11, 2015 at 11:46 AM, zipher wrote:
>> > 3.) true OOP
>> > Now before you go and get all "huffy" over this statement, hear me
>> > out. Python is the best language in the world. But it damn sure has
>> > some warts! "len(this)" instead of "obj.length" max(that) instead of
>> > [1,2,3,4
On Mon, May 11, 2015 at 11:18 AM, zipher wrote:
> Okay. I apologize for thinking in C and believing "int" was a keyword. It
> isn't in Python as you remind me. However, this is where I'm arguing the
> purity has hammered practicality into the ground.
>
> Python is trying to be as elegant as L
> > 3.) true OOP
> > Now before you go and get all "huffy" over this statement, hear me
> > out. Python is the best language in the world. But it damn sure has
> > some warts! "len(this)" instead of "obj.length" max(that) instead of
> > [1,2,3,4,5].max().
>
> As the Zen says: '[P]racticality beats
> I'm thinking how interesting it would be to add code blocks to Python, so
> that arbitrary strings of code can be passed around. It would open up some
> interesting possibilities for self-modifying code and generic programming.
>
> My suggestion would be to use triple double-quoted strings
On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa wrote:
> Scheme is my favorite language. I think, however, it is a pretty
> advanced language and requires a pretty solid basis in programming and
> computer science.
>
> Python, in contrast, is a great introductory programming language. Sure,
> you
On 05/10/2015 05:10 PM, zljubisic...@gmail.com wrote:
No, we can't see what ROOTDIR is, since you read it from the config
file. And you don't show us the results of those prints. You don't
even show us the full exception, or even the line it fails on.
Sorry I forgot. This is the output of the
> > Instead of learning only Scheme or only Python for a one semester intro
> > course, what about learning BOTH? Maybe that could somehow
> > get the benefits of both?
>
> No. LISP-like languages are very different beasts, requiring different
> mind-sets. It's like going from geometry to arit
> Huh? Python has plenty of keywords, and indeed, none of them can be
> redefined or shadowed.But you would gain nothing (and lose a bit or
> dynamic-language freedom) by making int a keyword.
Okay. I apologize for thinking in C and believing "int" was a keyword. It
isn't in Python as y
On 05/10/2015 05:48 PM, zipher wrote:
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" that is a
On Sunday, May 10, 2015 at 3:43:25 PM UTC-5, Chris Seberino wrote:
> Instead of learning only Scheme or only Python for a one semester intro
> course, what about learning BOTH? Maybe that could somehow
> get the benefits of both?
>
> I'm thinking that for the VERY beginning, Scheme is the fastest
On Sunday, May 10, 2015 at 7:20:13 PM UTC-5, Mark Lawrence wrote:
> On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
> > In case the example given at the start of the thread wasn't
> > interesting enough, it also works in the other direction:
> >
> class str(int): pass
> >
> str('2')
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
> wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It
On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
class str(int): pass
str('2')
2 #<- an integer!!!
Mark
Thanks for this, I've not found anybody new for my dream
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
>>> class str(int): pass
>>> str('2')
2 #<- an integer!!!
Mark
--
https://mail.python.org/mailman/listinfo/python-list
2015-05-10 18:06 GMT+02:00 Chris Angelico :
> Whenever you start encoding and decoding, you need to know whether
> you're working with bytes->text, text->bytes, or something else. In
> the case of unicode-escape, it expects to encode text into bytes, as
> you can see with your second example - you
2015-05-10 20:39 GMT+02:00 Albert-Jan Roskam :
>
> Hi,
>
> I only have Python 2 on my phone, but I am suprised that you (and are able
> to) decode unicode strings. What result do you get when you do the
> following in Python 3:
>
> Python 2.7.2 (default, Oct 25 2014, 20:52:15)
> [GCC 4.9 20140827
On 10/05/2015 23:59, Mark Rosenblitt-Janssen wrote:
On 5/10/15, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
int(3)
'3'
Mark
Here's where this exploration came from. I've (once again) been
contemplating the OO natu
Along those lines, it makes no sense for mix-in classes to inherit
from Object at all -- they're neither expanding on object nor
specializing it.
For example, I'm refactoring my python Graph class so that people can
have different Vertex behaviors by using different composition of
mix-in classes.
Here's where this exploration came from. I've (once again) been
contemplating the OO nature.
It's clear to me that there needs to be a distinction between
specialization of an object vs. expansion of an object (a new term I'm
proposing to the OOP lexicon). The latter *adds* more functionality
(l
Chris Seberino :
> Instead of learning only Scheme or only Python for a one semester
> intro course, what about learning BOTH? Maybe that could somehow get
> the benefits of both?
>
> I'm thinking that for the VERY beginning, Scheme is the fastest
> language to get beginners up and running writing
> No, we can't see what ROOTDIR is, since you read it from the config
> file. And you don't show us the results of those prints. You don't
> even show us the full exception, or even the line it fails on.
Sorry I forgot. This is the output of the script:
C:\Python34\python.exe C:/Users/zoran/P
> > It works, but if you change title = title[:232] to title = title[:233],
> > you will get "FileNotFoundError: [Errno 2] No such file or directory".
>
>
> Which is a *completely different* error from
>
> SyntaxError: 'unicodeescape' codec can't decode bytes in position 2-3:
> truncated \U
On 10/05/2015 10:58, Steven D'Aprano wrote:
from timeit import Timer
def func():
a = 2
b = 3
c = 4
return (a+b)*(a-b)/(a*c + b*c)
code = func.__code__
assert func() == eval(code)
t1 = Timer("eval; func()", setup="from __main__ import func")
t2 = Timer("eval(code)", setup="
On Sun, 10 May 2015 13:43:03 -0700, Chris Seberino wrote:
> Instead of learning only Scheme or only Python for a one semester intro
> course, what about learning BOTH? Maybe that could somehow get the
> benefits of both?
>
> I'm thinking that for the VERY beginning, Scheme is the fastest languag
Instead of learning only Scheme or only Python for a one semester intro
course, what about learning BOTH? Maybe that could somehow
get the benefits of both?
I'm thinking that for the VERY beginning, Scheme is the fastest language
to get beginners up and running writing code due to the extremely m
-
On Sun, May 10, 2015 5:53 PM CEST Somelauw . wrote:
>In Python 3, decoding "€" with unicode-escape returns 'â\x82¬' which in my
>opinion doesn't make sense.
>The € already is decoded; if it were encoded it would look like this:
>'\u20ac'.
>So why is it doing this?
>
On 05/10/2015 09:48 AM, Rustom Mody wrote:
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" th
On 10/05/2015 17:48, Rustom Mody wrote:
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" that
On 5/10/2015 12:34 PM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
You are being hypnotized by the fact the 'int' is a builtin name.
Builtin names are not keywords and can intentionally be rebound. If you
rebind randomly, the result may seem
On 5/10/2015 11:53 AM, Somelauw . wrote:
In Python 3, decoding "€" with unicode-escape returns 'â\x82¬' which in
my opinion doesn't make sense.
Agreed. I think this is a bug in that it should raise an exception
instead. Decoding a string only makes sense for rot-13
The € already is decoded;
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
class int(str): pass
This defines a new class named "int" that is a subclass of str. It has
no relation to the builtin class int.
int(3)
> '3'
This crea
On 5/10/2015 5:58 AM, Steven D'Aprano wrote:
Why is calling a function faster than bypassing the function object and
evaluating the code object itself? And not by a little, but by a lot?
Here I have a file, eval_test.py:
# === cut ===
from timeit import Timer
def func():
a = 2
b = 3
Here's something that might be wrong in Python (tried on v2.7):
>>> class int(str): pass
>>> int(3)
'3'
Mark
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, May 10, 2015 at 10:14 AM, Peter Otten <__pete...@web.de> wrote:
> When there was an actual speed-up I also had a look at
> PyEval_GetGlobals/Locals() which in turn call
>
> PyEval_GetFrame()
>
> and
>
> PyEvalPyFrame_FastToLocalsWithError()
>
> whatever these do. (The first function reminde
Steven D'Aprano wrote:
> On Sun, 10 May 2015 08:43 pm, Peter Otten wrote:
>
>> A significant part of the extra time is apparently spent on stack
>> inspection:
>
> I don't know what you mean by "stack inspection", or how you come to that
> conclusion.
>
>
>> $ python3 -m timeit -s 'f = (lambda
On Mon, May 11, 2015 at 1:53 AM, Somelauw . wrote:
> In Python 3, decoding "€" with unicode-escape returns 'â\x82¬' which in my
> opinion doesn't make sense.
> The € already is decoded; if it were encoded it would look like this:
> '\u20ac'.
> So why is it doing this?
>
> In Python 2 the behaviour
In Python 3, decoding "€" with unicode-escape returns 'â\x82¬' which in my
opinion doesn't make sense.
The € already is decoded; if it were encoded it would look like this:
'\u20ac'.
So why is it doing this?
In Python 2 the behaviour is similar, but slightly different.
$ python3 -S
Python 3.3.3 (
On Sun, 10 May 2015 08:34 pm, Christian Gollwitzer wrote:
> Am 10.05.15 um 11:58 schrieb Steven D'Aprano:
>> Why is calling a function faster than bypassing the function object and
>> evaluating the code object itself? And not by a little, but by a lot?
>>
>> Here I have a file, eval_test.py:
>>
>
On Sun, 10 May 2015 08:43 pm, Peter Otten wrote:
> A significant part of the extra time is apparently spent on stack
> inspection:
I don't know what you mean by "stack inspection", or how you come to that
conclusion.
> $ python3 -m timeit -s 'f = (lambda: 42); code = f.__code__; ns = {}'
> 'f()
On Sun, May 10, 2015 at 9:25 PM, Dave Angel wrote:
> On 05/09/2015 11:33 PM, Chris Angelico wrote:
>> What you could have is "late-binding semantics, optional early binding
>> as an optimization but only in cases where the result is
>> indistinguishable". That would allow common cases (int/bool/st
On Fri, May 8, 2015 at 11:32 AM, Noah Kantrowitz wrote:
>
> On May 8, 2015, at 10:28 AM, Chris Angelico wrote:
>
>> On Fri, May 8, 2015 at 6:17 PM, wrote:
>>> I cannot access www.python.org.
>>> I always get
>>>
>>> Error 503 Backend is unhealthy
>>>
>>> Backend is unhealthy
>>>
>>> Guru Mediat
On 05/09/2015 11:33 PM, Chris Angelico wrote:
On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano
wrote:
This is the point where some people try to suggest some sort of complicated,
fragile, DWIM heuristic where the compiler tries to guess whether the user
actually wants the default to use early
"Johannes Bauer" wrote in message
news:min9t3$e56$1...@news.albasani.net...
On 10.05.2015 10:58, Frank Millman wrote:
> > It is then a simple extra step to say -
> >
> > EMPTY_L:IST = ()
> >
> > and if required -
> >
> > EMPTY_DICT = ()
> >
> > and expand the explanation to show why a tuple is
On 05/09/2015 09:51 PM, Vincent Davis wrote:
On Sat, May 9, 2015 at 5:55 PM, Dave Angel wrote:
1) you're top-posting, putting your response BEFORE the stuff you're
responding to.
I responded to my own email, seemed ok to top post on myself saying it was
resolved.
Yeah, I overreacted. Th
Steven D'Aprano wrote:
> Why is calling a function faster than bypassing the function object and
> evaluating the code object itself? And not by a little, but by a lot?
> Directly eval'ing the code object is easily more than twice as expensive
> than calling the function, but calling the function
Am 10.05.15 um 11:58 schrieb Steven D'Aprano:
Why is calling a function faster than bypassing the function object and
evaluating the code object itself? And not by a little, but by a lot?
Here I have a file, eval_test.py:
# === cut ===
from timeit import Timer
def func():
a = 2
b = 3
Why is calling a function faster than bypassing the function object and
evaluating the code object itself? And not by a little, but by a lot?
Here I have a file, eval_test.py:
# === cut ===
from timeit import Timer
def func():
a = 2
b = 3
c = 4
return (a+b)*(a-b)/(a*c + b*c)
co
On 10.05.2015 10:58, Frank Millman wrote:
> It is then a simple extra step to say -
>
> EMPTY_L:IST = ()
>
> and if required -
>
> EMPTY_DICT = ()
>
> and expand the explanation to show why a tuple is used instead.
>
> So if there was a situation where the overhead of testing for None became
(To clarify, I am *not* talking about this as a change to Python, so
all questions of backward compatibility are immaterial. This is "what
happens if we go back in time and have Python use late binding
semantics". This is the "alternate 1985" of Back to the Future.)
On Sun, May 10, 2015 at 3:20 PM
"Johannes Bauer" wrote in message
news:min3f0$2gh$1...@news.albasani.net...
On 08.05.2015 14:04, Dave Angel wrote:
> > It might be appropriate to define the list at top-level, as
> >
> > EMPTY_LIST=[]
> >
> > and in your default argument as
> > def x(y, z=EMPTY_LIST):
> >
> > and with the a
On 08.05.2015 14:04, Dave Angel wrote:
> It might be appropriate to define the list at top-level, as
>
> EMPTY_LIST=[]
>
> and in your default argument as
> def x(y, z=EMPTY_LIST):
>
> and with the all-caps, you're thereby promising that nobody will modify
> that list.
>
> (I'd tend to do
74 matches
Mail list logo
