Ken Kundert writes:
> Lele,
> I am using Python3.6. d has to be an object of mydict.
My bad, sorry, I completely missed the premise :-|.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@m
Lele,
I am using Python3.6. d has to be an object of mydict.
Here is the code that exhibits the problem:
import sys, os
from inform import error, os_error
class mydict(dict):
def __format__(self, template):
print('Template:', template)
return
On 2018-05-14 20:24, Lele Gaifax wrote:
Ken Kundert writes:
Lele,
I'm afraid I was unclear. The ... in the code snippet was intended
to imply that these lines were appended to the end of the original code,
where d was defined.
Ok, but then I get a different behaviour:
Python 3.6.5
Ken Kundert writes:
> Lele,
> I'm afraid I was unclear. The ... in the code snippet was intended
> to imply that these lines were appended to the end of the original code,
> where d was defined.
Ok, but then I get a different behaviour:
Python 3.6.5 (default, May 11 2018, 13:30:17)
Lele,
I'm afraid I was unclear. The ... in the code snippet was intended
to imply that these lines were appended to the end of the original code,
where d was defined.
-Ken
On 05/14/2018 12:30 AM, Lele Gaifax wrote:
> Ken Kundert writes:
>
>> I tried adding k and v to the local namespace:
>>
On 2018-05-14 04:08, Terry Reedy wrote:
> On 5/13/2018 3:22 PM, Ken Kundert wrote:
>
> Please do not double post.
>
>> I am seeing an unexpected difference between the behavior of the string
>> format method and f-strings.
>
> Read
> https://docs.python.org/3/reference/lexical_analysis.html#form
Ken Kundert writes:
> I tried adding k and v to the local namespace:
>
> ...
> k = 6
> v = 9
> print(f'Email: {d:{{k}} {{v}}}')
>
> I still got:
>
> NameError: name 'k' is not defined
This is not what I get:
Python 3.6.5 (default, May 11 2018, 13:30:17)
[GCC 7.3.0]
Terry,
Thanks for your response.
I apologize about the double posting. I am well aware how doing so is
bad form. My double posting was unintentional; it occurred when my news
reader misbehaved.
What I did in my code was to put double braces inside the format_spec,
which the syntax specificati
On 5/13/2018 3:22 PM, Ken Kundert wrote:
Please do not double post.
I am seeing an unexpected difference between the behavior of the string
format method and f-strings.
Read
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals
carefully.
Here is an example:
I am seeing an unexpected difference between the behavior of the string
format method and f-strings in Python3.6.
Here is an example:
import sys, os
from inform import error, os_error
class mydict(dict):
def __format__(self, template):
print('Template:', template)
I am seeing an unexpected difference between the behavior of the string
format method and f-strings.
Here is an example:
import sys, os
from inform import error, os_error
class mydict(dict):
def __format__(self, template):
print('Template:', template)
On Thursday 08 December 2016 02:17, Rustom Mody wrote:
> Trying to write some code using sets (well frozen sets)
> And was hit by this anomaly
>
> This is the behavior of lists I analogously expect in sets:
>
>>>> []
> []
>>>> [[]]
> [[]]
>>&
On 2016-12-07 15:33, Ned Batchelder wrote:
On Wednesday, December 7, 2016 at 10:18:32 AM UTC-5, Rustom Mody wrote:
Trying to write some code using sets (well frozen sets)
And was hit by this anomaly
This is the behavior of lists I analogously expect in sets:
>>> []
[]
>>>
On Wednesday, December 7, 2016 at 10:18:32 AM UTC-5, Rustom Mody wrote:
> Trying to write some code using sets (well frozen sets)
> And was hit by this anomaly
>
> This is the behavior of lists I analogously expect in sets:
>
> >>> []
> []
> >>> [[]]
&g
Trying to write some code using sets (well frozen sets)
And was hit by this anomaly
This is the behavior of lists I analogously expect in sets:
>>> []
[]
>>> [[]]
[[]]
>>>
ie the empty list and the list of the empty list are different things
However
(with
f= fro
[Mr. Lawrence spaketh:]
> Do we really have to feed this guy, he's worse than the RUE?
While it may seem like an impossible goal, is it unworthy? Is there something
*better* for high-level, interpreted languages to be good for?
The truth is, that all the theory is worked out, as well as the hea
Op 13-05-15 om 02:19 schreef Gregory Ewing:
> Antoon Pardon wrote:
>> But that doesn't answer the question why the developers chose "True"
>> to be a
>> keyword and "int" to be a looked-up name.
>
> Probably because True, False and None are very frequently
> used constants.
I don't care about the
Op 12-05-15 om 15:56 schreef Steven D'Aprano:
> On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
>
>> Op 11-05-15 om 16:13 schreef Chris Angelico:
>>
>>> Why does Python have most built-ins as simply looked-up names that can
>>> be overridden? Because otherwise, there would be a veritable ton of
On Wednesday 13 May 2015 02:22, Skip Montanaro wrote:
> I did find this interesting blog post about encapsulation and
> test-driven development:
>
> https://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-
development-part-i-encapsulation/
>
> I found the author's perspective interes
On Tuesday, May 12, 2015 at 10:43:44 AM UTC-5, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> > Name one "significant and important" use case for shadowing built-in types.
> > Functions, I don't have a problem with, but types are more fundamental
> > than functions.
>
On Wednesday, May 13, 2015 at 7:47:03 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > You made TRUE into FALSE!!
>
> The answer is: yes! Haskell can do that.
>
>Prelude> let 2+2=5 in 2+2
>5
:-)
And we come back to the OP.
It *looks* like this is some profound question about O
Rustom Mody writes:
> You made TRUE into FALSE!!
The answer is: yes! Haskell can do that.
Prelude> let 2+2=5 in 2+2
5
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday, May 13, 2015 at 6:17:41 AM UTC+5:30, John Ladasky wrote:
> On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:
>
> > Try overriding None, True or False in python3 and see what happens.
>
> Much fun was able to be had in Python 2, though:
>
> Python 2.7.6 (default,
On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:
> Try overriding None, True or False in python3 and see what happens.
Much fun was able to be had in Python 2, though:
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "cre
Antoon Pardon wrote:
But that doesn't answer the question why the developers chose "True" to be a
keyword and "int" to be a looked-up name.
Probably because True, False and None are very frequently
used constants. Making them keywords means that things
like 'while True:' don't incur the overhea
On 5/12/2015 9:56 AM, Steven D'Aprano wrote:
The consensus among the core developers is:
* in general, the harm and inconvenience from accidentally
shadowing built-ins is not great, and it usually easy to
spot, debug and prevent;
* when it comes to built-in functions (e.g. sum, map, pow)
On Tue, May 12, 2015 at 9:34 AM, zipher wrote:
>> * when it comes to built-in functions (e.g. sum, map, pow)
>> and types (e.g. int, str, list) there are significant and
>> important use-cases for allowing shadowing;
>
> Name one "significant and important" use case for shadowing built-in type
On Tue, May 12, 2015 at 10:34 AM, zipher wrote:
>> The general principle here is of consenting adults: Python allows you to
>> shadow built-ins because sometimes it is useful, and the good outweighs the
>> potential harm.
>
> I think you'll have to give examples, either from the developer communit
On 12/05/2015 16:43, Chris Angelico wrote:
On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
* when it comes to built-in functions (e.g. sum, map, pow)
and types (e.g. int, str, list) there are significant and
important us
On 05/12/2015 04:55 AM, Antoon Pardon wrote:
Op 11-05-15 om 16:13 schreef Chris Angelico:
Why does Python have most built-ins as simply looked-up names that can
be overridden? Because otherwise, there would be a veritable ton of
keywords:
But that doesn't answer the question why the developers
On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
>> * when it comes to built-in functions (e.g. sum, map, pow)
>> and types (e.g. int, str, list) there are significant and
>> important use-cases for allowing shadowing;
>
> Na
On 2015-05-12, alex23 wrote:
> On 12/05/2015 1:39 AM, zipher wrote:
>> On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
>>> That Python, like COBOL, is an eminently practical language.
>>
>> LOL! Good one.
>
> I would make an incredibly substantial wager that you've never develo
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
> The consensus among the core developers is:
> * in general, the harm and inconvenience from accidentally
> shadowing built-ins is not great, and it usually easy to
> spot, debug and prevent;
Where is that the consensus? Pl
On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
> Op 11-05-15 om 16:13 schreef Chris Angelico:
>
>> Why does Python have most built-ins as simply looked-up names that can
>> be overridden? Because otherwise, there would be a veritable ton of
>> keywords:
>
> But that doesn't answer the questi
Op 11-05-15 om 17:44 schreef Steven D'Aprano:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
>> The point is that all too often someone wants to defend a specific choice
>> the developers have made and cites some general rule or principle in
>> support, ignoring the fact that python breaks
On 12/05/2015 06:02, alex23 wrote:
On 12/05/2015 1:39 AM, zipher wrote:
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
That Python, like COBOL, is an eminently practical language.
LOL! Good one.
I would make an incredibly substantial wager that you've never developed
an
Op 11-05-15 om 16:13 schreef Chris Angelico:
> Why does Python have most built-ins as simply looked-up names that can
> be overridden? Because otherwise, there would be a veritable ton of
> keywords:
But that doesn't answer the question why the developers chose "True" to be a
keyword and "int" to
Op 11-05-15 om 16:03 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> The point is that all too often someone wants to defend a specific
>> choice the developers have made and cites some general rule or
>> principle in support, ignoring the fact that python breaks that
>> rule/principle in other are
Steven D'Aprano wrote:
With programming languages, the designer can take the same route as Pascal
or Java, and define standard functions as keywords that cannot be shadowed
or redefined.
Nit: Pascal's standard types and functions are not reserved
words, they're predeclared identifiers, much as
On 12/05/2015 1:39 AM, zipher wrote:
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
That Python, like COBOL, is an eminently practical language.
LOL! Good one.
I would make an incredibly substantial wager that you've never developed
anything of note in either Python or
On Tue, 12 May 2015 06:48 am, Mel Wilson wrote:
> On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:
>
>> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
>>
>>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>>>
I have to admit being surprised by this, too. I am just now stud
On Tue, 12 May 2015 02:43 am, zipher wrote:
> For example, have you ever contemplated this:
>
> class WeightedVertex(vertex_common(Vertex(dict))):
> """test class"""
No.
> That currently isn't valid Python code,
Yes it is. You just have to arrange matters so that
vertex_common(Vertex(dict))
On 5/11/2015 8:34 AM, Grant Edwards wrote:
> Yow! YOU PICKED KARL
> MALDEN'S NOSE!!
I'd bet most people familiar with Karl Malden wouldn't have a
problem picking his from a selection of twenty random noses. :)
Emile
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
>
>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>>
>>> I have to admit being surprised by this, too. I am just now studying
>>> on how to write my own classes in Python, and hav
On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote:
> On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
> > I also bought the idea of everything as an object, it has a unbeatable
> > purity to it. But we won't ever get to the point were OOP is like the
> > purity of math because t
On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>
>> I have to admit being surprised by this, too. I am just now studying on
>> how to write my own classes in Python, and have come to realize that
>> doing this is *possible*, but the *surpris
On Monday, May 11, 2015 at 10:44:51 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
> > The point is that all too often someone wants to defend a specific choice
> > the developers have made and cites some general rule or principle in
> > support, ignoring t
On 11/05/2015 16:48, Skip Montanaro wrote:
On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
I also bought the idea of everything as an object, it has a unbeatable purity
to it. But we won't ever get to the point were OOP is like the purity of math
because the greatest utility of OOP is workin
On Tue, 12 May 2015 12:23 am, zipher wrote:
> On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote:
>> 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
On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
> I also bought the idea of everything as an object, it has a unbeatable purity
> to it. But we won't ever get to the point were OOP is like the purity of
> math because the greatest utility of OOP is working with real-world data.
> And that rea
On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
> The point is that all too often someone wants to defend a specific choice
> the developers have made and cites some general rule or principle in
> support, ignoring the fact that python breaks that rule/principle in other
> area's.
"It's a fre
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
> On 2015-05-11, Skip Montanaro wrote:
> >> Python is in production use in hundreds of thousands of
> >> organisations. It has been heavily used for over twenty years, in
> >> everything from quick and dirty one line scripts to hun
On 2015-05-11, Skip Montanaro wrote:
>> Python is in production use in hundreds of thousands of
>> organisations. It has been heavily used for over twenty years, in
>> everything from quick and dirty one line scripts to hundred-thousand
>> LOC applications.
>
> Mark> Yeah, so was COBOL. Boom.
>
On Monday, May 11, 2015 at 9:52:16 AM UTC-5, Skip Montanaro wrote:
> Steven> Python is in production use in hundreds of thousands of
> organisations. It
> Steven> has been heavily used for over twenty years, in everything
> from quick and
> Steven> dirty one line scripts to hundred-thousand LOC app
On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote:
> Antoon Pardon :
>
> > The point is that all too often someone wants to defend a specific
> > choice the developers have made and cites some general rule or
> > principle in support, ignoring the fact that python breaks that
> > r
Further posts on this thread should delete pydev-list or
gmane.comp.python.devel. It was a mistake by the troll to ever post
this there.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Steven> Python is in production use in hundreds of thousands of
organisations. It
Steven> has been heavily used for over twenty years, in everything
from quick and
Steven> dirty one line scripts to hundred-thousand LOC applications.
Mark> Yeah, so was COBOL. Boom.
Your point being?
The software
On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote:
> 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 Programm
On Mon, May 11, 2015 at 11:38 PM, Antoon Pardon
wrote:
> "We allow buitins to be overridden", doesn't sound as a very accurate
> description of the underlining reason, when you know that things have
> been removed from builtins and made a keyword in order to prevent them
> from being overridden.
Antoon Pardon :
> The point is that all too often someone wants to defend a specific
> choice the developers have made and cites some general rule or
> principle in support, ignoring the fact that python breaks that
> rule/principle in other area's.
Granted, but you have set the trap for them by
On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
> I have to admit being surprised by this, too. I am just now studying on
> how to write my own classes in Python, and have come to realize that
> doing this is *possible*, but the *surprise* to me is why the language
> design allowed this to ac
Op 11-05-15 om 14:34 schreef Steven D'Aprano:
> On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
>
>> There is no
>> a priori reason why we should turn "True" into a keyword and allow
>> "int" in the builtins.
> Why should there be an *a priori* reason?
I don't say there should be an *a priori*
Op 11-05-15 om 13:58 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Which is exactly the point! They were turned into keywords because the
>> developers didn't want to allow them being overridden. There is no a
>> priori reason why we should turn "True" into a keyword and allow "int"
>> in the buil
On Mon, May 11, 2015 at 2:40 AM, Mark Lawrence wrote:
> On 10/05/2015 20:12, boB Stepp wrote:
>> I'm surprised that this thought has not been added to the "Zen Of
>> Python", as I see it as more and more recurrent as I continue my
>> studies. What I would like to comprehend is what is the essenti
On Mon, May 11, 2015 at 2:44 AM, Chris Angelico wrote:
> On Mon, May 11, 2015 at 5:12 AM, boB Stepp wrote:
>>> Common Python thought:: "We're all adults here."If you want to override
>>> a builtin within your own namespace, who are we to stop you?
>>
>> I'm surprised that this thought has no
On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
> There is no
> a priori reason why we should turn "True" into a keyword and allow
> "int" in the builtins.
Why should there be an *a priori* reason?
There's no a priori reason why I speak English, instead of communicating
through the medium of
On 11/05/2015 02:18, zipher wrote:
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 keyw
Antoon Pardon :
> Which is exactly the point! They were turned into keywords because the
> developers didn't want to allow them being overridden. There is no a
> priori reason why we should turn "True" into a keyword and allow "int"
> in the builtins.
>
> We are only allowed to be adults, for as f
On 11/05/2015 12:39, Antoon Pardon wrote:
Op 11-05-15 om 12:40 schreef Mark Lawrence:
On 11/05/2015 11:15, Antoon Pardon wrote:
Op 10-05-15 om 19:28 schreef Gary Herron:
Common Python thought:: "We're all adults here."If you want to
override a builtin within your own namespace, who are w
Op 11-05-15 om 12:40 schreef Mark Lawrence:
> On 11/05/2015 11:15, Antoon Pardon wrote:
>> Op 10-05-15 om 19:28 schreef Gary Herron:
>>
>>> Common Python thought:: "We're all adults here."If you want to
>>> override a builtin within your own namespace, who are we to stop you?
>>> Besides, it's
On 11/05/2015 11:15, Antoon Pardon wrote:
Op 10-05-15 om 19:28 schreef Gary Herron:
Common Python thought:: "We're all adults here."If you want to
override a builtin within your own namespace, who are we to stop you?
Besides, it's still available as __builtins__.int (unless you've also
ov
Op 10-05-15 om 19:28 schreef Gary Herron:
> Common Python thought:: "We're all adults here."If you want to
> override a builtin within your own namespace, who are we to stop you?
> Besides, it's still available as __builtins__.int (unless you've also
> overridden that).
This is a common p
On 10 May 2015 at 17:34, Mark Rosenblitt-Janssen
wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
class int(str): pass
>
int(3)
> '3'
It's not wrong as such. It is allowed to define your own class that
subclasses a builtin class, and it's allowed to shadow buil
On Mon, May 11, 2015 at 5:12 AM, boB Stepp wrote:
>> Common Python thought:: "We're all adults here."If you want to override
>> a builtin within your own namespace, who are we to stop you?
>
> I'm surprised that this thought has not been added to the "Zen Of
> Python", as I see it as more and
On 10/05/2015 20:12, boB Stepp wrote:
On Sun, May 10, 2015 at 12:28 PM, Gary Herron wrote:
Common Python thought:: "We're all adults here."If you want to override
a builtin within your own namespace, who are we to stop you?
I'm surprised that this thought has not been added to the "Zen
I am in process learning Python and normally hang out on the Tutor
list, but monitor this one hoping to learn what I can. This thread is
of interest to me from the standpoint of trying to understand the
Python way of doing things.
On Sun, May 10, 2015 at 12:28 PM, Gary Herron wrote:
> On 05/10/20
On Monday, May 11, 2015 at 2:58:09 AM UTC+2, 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
> every
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 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
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):
>>>
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 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
> > 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: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
> 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 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
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
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 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
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 Tue, 3 Feb 2009 05:22:01 -0800 (PST), Mr SZ wrote:
>
> I was looking at the thread functionality of IMAP4rev1 servers with the
> threading extension. Here is my output with debug=8 :
>
>
>
> 02:23.02 > GDJB3 UID THREAD references UTF-8 (SEEN)
> 02:23.02 < * THREAD (3)(2)(
1 - 100 of 197 matches
Mail list logo
