[issue513866] Float/long comparison anomaly

Change by admin : -- github: None -> 36040 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45862] Anomaly of eval() of list comprehension

Mark Dickinson added the comment: True: there's another detail here that's needed to explain the behaviour. The first "for" clause in a list comprehension is special: it's evaluated in the enclosing scope, rather than in the local function scope that the list comprehension creates. See the

[issue45862] Anomaly of eval() of list comprehension

David Pratten added the comment: Hi Mark, Thanks.   The anomaly is that the print("eg def2", ...)  works.  Should it not fail in the same way that print("eg def4", ...) does. David On 22/11/2021 7:36:31 PM, Mark Dickinson wrote: Mark Dickinson added the comment: T

[issue45862] Anomaly of eval() of list comprehension

Mark Dickinson added the comment: See also #41216 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45862] Anomaly of eval() of list comprehension

Mark Dickinson added the comment: Thanks for the report. The behaviour is by design: see #5242 (especially msg81898) for an explanation. Closing this issue as a duplicate of #5242. -- nosy: +mark.dickinson resolution: -> duplicate stage: -> resolved status: open -> closed

[issue45862] Anomaly of eval() of list comprehension

g def1', [b for b in a_anomaly]) print('eg def2', eval('[b for b in a_anomaly]')) print('eg def3', [e for e in emp for b in a_anomaly if e["mgr"] == b["empno"]]) print('eg def4', eval('[e for e in emp for b in a_anomaly if

[issue12508] Codecs Anomaly

Change by Irit Katriel : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker ___

[issue38508] Tracing events anomaly when creating a multi-line list

Fabio Zadrozny added the comment: If it's a feature and not a bug, seems ok to me (I reported mainly because I thought the behavior was odd, but I guess it makes sense). -- resolution: -> not a bug stage: -> resolved status: open -> closed ___

[issue38508] Tracing events anomaly when creating a multi-line list

Serhiy Storchaka added the comment: Considering the code as: x = { 1, 2 } It first gets constant 1. Then gets constant 2. Then build a set. Then assign it to the variable. Obviously that the variable is assigned at line 1, so you would get a backward line in any case. The set display is

[issue38508] Tracing events anomaly when creating a multi-line list

: snippet33.py messages: 354845 nosy: fabioz priority: normal severity: normal status: open title: Tracing events anomaly when creating a multi-line list type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48665/snippet33.py ___ Python tracker

Re: f-string anomaly

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

Re: f-string anomaly

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)

Re: f-string anomaly

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

Re: f-string anomaly

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,

Re: f-string anomaly

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

Re: f-string anomaly

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 >

Re: f-string anomaly

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,

Re: f-string anomaly

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

Re: f-string anomaly

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

f-string anomaly

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:',

f-string anomaly

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)

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

ry for machine learning >and machine intelligence. It is developed by Google and became open source in >November 2015." It obviously has a python binding as there are numerous >questions tagged with both. I searched SO for "[tensorflow] ANOMALY" and the 29 hits were about anom

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

Kaoru Kitamura added the comment: Understood. Thank you. -- resolution: remind -> ___ Python tracker ___

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

R. David Murray added the comment: Well, it's not obvious that it has anything to do with CPython itself. You should probably work with the community responsible for tensorflow, whatever that is, and if they find a bug in CPython you can come back here with a report.

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

Kaoru Kitamura added the comment: Does somebody know what causes above? -- resolution: -> remind ___ Python tracker ___

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

Kaoru Kitamura <kkaoru1...@gmail.com> added the comment: The below is the output of error. :\Users\kitamura>activate tensorflow パラメーターの書式が違います - [0x7FFD92395AD0] [0x7FFD8F53DFE0] ANOMALY: meaningless REX prefix used [0x7FFD8F555A20] ANOMALY: meaningless REX prefix used [0x7FFD905417D0

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

Serhiy Storchaka added the comment: Could you please provide the output as a text instead of a picture? -- nosy: +serhiy.storchaka ___ Python tracker

[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY

t work. Does anyone have any suggestions? -- components: Windows files: error_capture.png messages: 308977 nosy: Kitamura, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY type:

Re: sets anomaly

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: > >>>> [] > [] >>>> [[]] > [[]] >>&

Re: sets anomaly

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: >>> [] [] >>>

Re: sets anomaly

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: > > >>> [] > [] > >>>

sets anomaly

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

Re: anomaly

[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

Re: anomaly

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 keywords:

Re: anomaly

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 specific

Re: anomaly

On 12/05/2015 16:43, Chris Angelico wrote: On Wed, May 13, 2015 at 1:34 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

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,

Re: anomaly

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

Re: anomaly

On Tue, May 12, 2015 at 10:34 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

On Tue, May 12, 2015 at 9:34 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

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 overhead

Re: anomaly

Rustom Mody rustompm...@gmail.com 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

Re: anomaly

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

Re: anomaly

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, Mar 22

Re: anomaly

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, credits

Re: anomaly

Op 11-05-15 om 16:03 schreef Marko Rauhamaa: Antoon Pardon antoon.par...@rece.vub.ac.be: 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

Re: anomaly

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

Re: anomaly

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 be a

Re: anomaly

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 that

Re: anomaly

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 dreamingforw...@gmail.com 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

Re: anomaly

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 interesting.

Re: anomaly

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 question why

Re: anomaly

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?

Re: anomaly

On 2015-05-12, alex23 wuwe...@gmail.com 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

Re: anomaly

On Wed, May 13, 2015 at 1:34 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

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 everything

Re: anomaly

On Mon, May 11, 2015 at 5:12 AM, boB Stepp robertvst...@gmail.com 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

Re: anomaly

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 is

Re: anomaly

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 point this out

Re: anomaly

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 gher...@digipen.edu

Re: anomaly

On 10/05/2015 20:12, boB Stepp wrote: On Sun, May 10, 2015 at 12:28 PM, Gary Herron gher...@digipen.edu 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

Re: anomaly

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 python

Re: [Python-Dev] anomaly

On 10 May 2015 at 17:34, Mark Rosenblitt-Janssen dreamingforw...@gmail.com 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

Re: anomaly

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

Re: anomaly

Antoon Pardon antoon.par...@rece.vub.ac.be: 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

Re: anomaly

On Mon, May 11, 2015 at 2:40 AM, Mark Lawrence breamore...@yahoo.co.uk 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

Re: anomaly

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 still

Re: anomaly

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 we

Re: anomaly

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 dance.

Re: anomaly

On Mon, May 11, 2015 at 2:44 AM, Chris Angelico ros...@gmail.com wrote: On Mon, May 11, 2015 at 5:12 AM, boB Stepp robertvst...@gmail.com 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

Re: anomaly

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

Re: anomaly

Op 11-05-15 om 13:58 schreef Marko Rauhamaa: Antoon Pardon antoon.par...@rece.vub.ac.be: 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

Re: anomaly

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* reason, but

Re: anomaly

Antoon Pardon antoon.par...@rece.vub.ac.be: 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

Re: anomaly

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

Re: anomaly

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

Re: anomaly

On Mon, May 11, 2015 at 11:38 PM, Antoon Pardon antoon.par...@rece.vub.ac.be 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

Re: anomaly

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

Re: anomaly

On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote: Antoon Pardon antoon.par...@rece.vub.ac.be: 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

Re: anomaly

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 Programming

Re: anomaly

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

Re: anomaly

On 2015-05-11, Skip Montanaro skip.montan...@gmail.com 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

Re: anomaly

On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote: On 2015-05-11, Skip Montanaro skip.montan...@gmail.com 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

Re: anomaly

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 free

Re: anomaly

On Mon, May 11, 2015 at 10:11 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

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 have come to

Re: anomaly

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

Re: anomaly

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

Re: anomaly

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

Re: anomaly

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)) returns a

Re: anomaly

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 studying on how to

Re: anomaly

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 the fact

Re: anomaly

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 dreamingforw...@gmail.com 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

Re: anomaly

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 of OOP (on

Re: anomaly

On 11/05/2015 16:48, Skip Montanaro wrote: On Mon, May 11, 2015 at 10:11 AM, zipher dreamingforw...@gmail.com 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

Re: anomaly

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 *surprise* to

Re: anomaly

On 10/05/2015 23:59, Mark Rosenblitt-Janssen wrote: On 5/10/15, Mark Rosenblitt-Janssen dreamingforw...@gmail.com 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

Re: anomaly

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

Re: anomaly

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') 2 #- an

Re: anomaly

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 dreamingforw...@gmail.com wrote: Here's something that might be wrong in Python (tried on v2.7): class int(str): pass This defines a new

  1   2   3   >