Re: Why assert is not a function?
Am 03.03.2021 um 00:24 schrieb Chris Angelico: > On Wed, Mar 3, 2021 at 10:22 AM Mirko via Python-list > wrote: >> >> Am 02.03.2021 um 23:09 schrieb Stestagg: >>> Ignoring the question about this feature being particularly useful, it >> >> It is useful because "assert" is primarily (if not purely and >> exclusive) a debugging tool during development and testing. >> >> In production code you don't want any asserts, but logging. Having >> "assert" being a function would make it much harder to get rid of it >> in production code. >> > > Really? Yes. > if PRODUCTION: > def assert(*a, **kw): pass > > would work if it were a function :) With the "if PRODUCTION" being superfluously in the production code (not to mention the possible NameError otherwise). -- https://mail.python.org/mailman/listinfo/python-list
Re: What user-defined request error levels are recommended?
Am 30.04.2020 um 22:56 schrieb Dan Campbell: > On Thursday, April 30, 2020 at 4:42:41 PM UTC-4, Ed Leafe wrote: >> On Apr 30, 2020, at 15:14, dc wrote: >>> >>> Hi, what range of error codes are recommended, if we wanted to return a >>> user-defined code? >>> >>> Obviously, we don't want to use a code in the 200+ range, or the 400+ >>> range, e.g. >>> >>> I want to throw, or just return, a code that represents that the size of a >>> web page (len(response.content)) is less than the expected size. >> >> You can create your own internal codes as long as they don’t clash with the >> standard code. If the custom code is for a success, a 2xx code would be >> appropriate. If it is a user error, you could use a 4xx code. >> >> However, I would prefer to use the standard codes, and add a custom header >> with more information on the issue. >> >> >> -- Ed Leafe > > Ok, I'll try to find the the 400s list. My concern is that a future library > will use the 400+ code that I choose. > According to the German Wikipedia, some software vendors use 9xx for proprietary error codes, which have never been mentioned in the RFC. They are probably save for non-standard use. https://de.wikipedia.org/wiki/HTTP-Statuscode#9xx_%E2%80%93_Propriet%C3%A4re_Fehler -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem
Am 01.10.2020 um 22:17 schrieb Chris Angelico: > Maybe those usability improvements have already been done. Haven't doubted that. Maybe they are just not enough yet. > Renaming Idle to "Python IDE" would be a very bad idea, since there > are many other Python IDEs. You missed the "(or similar)" addition. ;-) Call it "IDLE - Python IDE" or "Python Editor (IDLE)" or whatever. Something that gives the newcomer a better clue than "IDLE". > Starting something immediately after installation completes might > help, but would probably just defer the issue to the *second* time > someone wants something. Probably not if they once have seen that there is some GUI editor and can barely recall it was something like "IDE", "Python Editor" or so. Again, will it help in *all* cases? No, but in some. > There is no simple foolproof solution. That's why people still get confused. That's what I mean. You dismiss suggestions on the grounds of "no simple foolproof solution" ie. a perfect solution. I'm not talking about solutions that will work in every case and solve all possible problems. I'm talking about incremental improvements which reduce some -- not remove all -- those troubles, But again, I'm not the one who has to deal with all this. :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem
Am 02.10.2020 um 11:58 schrieb Terry Reedy:
> On 10/1/2020 4:09 PM, Mirko via Python-list wrote:
>
>> Renaming "IDLE" to "Python IDE" (or similar) might also.
> "IDLE" intentionally echoes 'Idle', as in Eric Idle of Monty
> Python. It stands for "Integrated Development and Learning
> Environment". It is *a* Python IDE aimed especially at beginners
> (the 'Learning' part). (I should probably revised the doc a bit.)
>
> Changing a name in use around the world, in books and web sites and
> discussion posts and a Stackoverflow tag ('python-idle') is a bad
> idea. And, as Chris said, implying that it is *the* Python IDE is
> not a good idea either.
>
> I think changing the start menu entry
> "IDLE (Python 3.9 64 bit)"
> to something more descriptive, as suggested by Mirko, *is* a good idea.
>
> The current longest entry under "Python 3.9" is
> "Python 3.9 Module Docs (64-bit)"
> So
> "IDLE Shell/Editor (3.9 64-bit)"
> would fit. I opened a bpo issue with more discussion.
> https://bugs.python.org/issue41908
> Bpo users with an opinion should express it there.
>
> Terry Jan Reedy
>
Thanks!
Sorry, I have been a bit unclear in my second post. I never meant to
rename IDLE itself. Only the entries in the Startmenu, the possible
desktop icons and such.
If I had a say in all this, I would do:
- Rename the MSI as suggested by Eryk Sun.
- Add a folder named "Python.org " (or similar) to the
desktop with shortcuts to Python, IDLE and the CHM.
- Add a checkbox (default enabled) like "Start the IDLE Python
Editor/Shell" at the end of the installation procedure.
- Add a button like "Start the IDLE Python Editor/Shell" to the
Repair/Modify/Remove Dialog.
For all I know, the points 2 and 3 are very common with installation
procedures on Windows (and therefore likely expected by the users).
And no, this will not solve all problems. There will always be some
people who just don't get it. But I would be very surprised, if that
doesn't cut down the number of these beginner troubles by one or two
orders of magnitude.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Iteration over strings
Jay Loden schrieb: > Robert Dailey wrote: >> str = "C:/somepath/folder/file.txt" >> >> for char in str: >> if char == "\\": >> char = "/" > strings in Python are immutable - in other words, they cannot be updated in > place as you're doing above. However, that doesn't mean you can't achieve > what you're after. In Python, the way to approach this problem since you > cannot modify the string in place, is to create a new string object with the > desired content: Also note, that you are just extracting one char from the string into another variable (which you then change) and you are *not* getting any "reference" to the char in the string. As has been alreagy told, use the str.replace() function -- http://mail.python.org/mailman/listinfo/python-list
Re: Iteration over strings
Jay Loden schrieb: > > I have to agree with you WRT to the Python documentation, it does tend to be > lacking and difficult to find things at times. In this case the two ways I > can think of to look for something like this would have been: Hmm, I find the Python documentation just excellent. You are searching for a *string* related problem? Then just check the *string* class. Also try the dir() function, like dir(some_string_variable) If you come from a C++ background this should be familar to you. Check the appropriate class before trying some "procedural" way. Anyway, glad we could help :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Iteration over strings
Hexamorph schrieb: > Jay Loden schrieb: >> >> I have to agree with you WRT to the Python documentation, it does tend >> to be lacking and difficult to find things at times. Hmm, I find the Python documentation just excellent. You are searching for a *string* related problem? Then just check the *string* class. Also try the dir() function, like dir(some_string_variable) If you come from a C++ background this should be familar to you. Check the appropriate class before trying some "procedural" way. Anyway, glad we could help :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Iteration over strings
Jay Loden schrieb: > Well, I don't want to start a flamewar or anything like that Nothing like that intended here either :) OTOH, on most forums, lists, boards, etc, I am active, the constant fear about "flamewars" annoys me somewhat. As long as it doesn't get insulting, derogative or bull-headed it should be perfectly OK (even when it becomes somewhat hot-blooded) > [... ]What I don't like is how frequently I run into things that just aren't > documented *well* ;) As an example, reading the docs for the "socket" module > repeatedly tells you things like 'see the UNIX manual' instead of just > documenting the appropriate information. I realize these are simply thin > wrappers for C sockets, but that still assumes your audience is rather > intimately familiar with socket programming in C on UNIX. Well, OK, but that's the drawback of a language with it's origin in the Unix scene. The other way, imagine some VisualBasic for Linux implementation (and try to get some info about some COM object) Anyway, we are going OT... -- http://mail.python.org/mailman/listinfo/python-list
Re: piping into a python script
Donn Ingle wrote: > Paddy wrote: >> fileinput is set to process each file a line at a time unfortunately. > Wow. So there seems to be no solution to my OP. I'm amazed, I would have > thought a simple list of strings, one from stdin and one from the args, > would be easy to get. > > I *really* don't want to open each file, that would be insane. > > Perhaps I shall have to forgo the stdin stuff then, after all. > Hi! I'm not sure if I completely get what you want, but what's about this: #!/usr/bin/python import sys filelist = [] with_stdin=0 if len(sys.argv) > 1: for file in sys.argv[1:]: if file == "-": with_stdin=1 continue filelist.append(file) else: with_stdin=1 if with_stdin: for file in sys.stdin: filelist.append(file) for file in filelist: print "Processing file: %s" % file It's a bit clumsy, but seems to do what I guess you want. HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Operator overloading
[EMAIL PROTECTED] wrote: > > Diez B. Roggisch wrote: >> No, there is no way. You would change general interpreter behavior if >> you could set arbitrary operators for predefined types. >> >> Start grumping... > > Thank you, Diez. > > If I ever design a language, please remind me that complete, easy, > well-documented access to the working of the internals (and the > ability to change same) would be very, uh, what's the right word? > Pythonic? You mean you want the ability to change for example the + operator for ints to something like calculating the cosine instead of doing addition? That will break the whole system in general as other parts of the language (or modules, libraries and programs) rely on a certain inner behaviour. There are some languages in which you can do this (Lisp/Scheme for example) but messing with the internals is almost never done for good reasons. -- http://mail.python.org/mailman/listinfo/python-list
Re: Operator overloading
[EMAIL PROTECTED] wrote: > > Hexamorph wrote: >> You mean you want the ability to change for example the + operator >> for ints to something like calculating the cosine instead of doing >> addition? > > Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so > why shouldn't I define +45 to return cosine of 45, (presuming I needed > lots of cosines). I'd even let you define your own operators. Lots of > programmers really liked '++' and '--', for examples. Well, OK, the cosine example was badly chosen (it would still be very wired in terms of common syntax and semantics), but I think you got my point. Changing internal behaviour mostly causes more trouble as it's worth. In the end, you probably can access the parser to do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Index of maximum element in list
Henry Baxter wrote: > Oops, gmail has keyboard shortcuts apparently, to continue: > > def maxi(l): > m = max(l) > for i, v in enumerate(l): > if m == v: > return i > What's about l.index(max(l)) ? -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for a light weighted library/tool to write simple GUI above the text based application
Lorenzo E. Danielsson wrote: > [EMAIL PROTECTED] wrote: >> I think I was not specific/clear enough in my first posting. I know >> the curses library ( http://pyncurses.sourceforge.net ). It AFIK >> provides TUI (short for: Text User Interface or Textual User >> Interface). My needs are GUI, I mean "a nice VGA pictures" on the VGA >> LCD 10" display. >> >> Petr > > What you need then is something like SVGAlib (http;//svgalib.org). Only > really old people like myself know that it exists. I've never heard of > any Python bindings for it, but that might be where you come in. I > haven't looked at SVGAlib for years, and I'm not sure about the state of > the video drivers. I don't think that there's a Python binding for it. Svgalib never has gained enough popularity for anybody to write such bindings. However, as long as the video card supports VGA or VESA it should work. Another possibility might be using Xvesa (KDrive) which is a really tiny self-containing X server for VGA/SVGA/FBdev. With this you can atleast use simple GUI toolkits like Athena or TK or even use Xlib directly (if you don't fear that adventure) See: http://www.xfree86.org/current/Xvesa.1.html http://www.pps.jussieu.fr/~jch/software/kdrive.html HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Nice way to cast a homogeneous tuple
wheres pythonmonks wrote:
A new python convert is now looking for a replacement for another perl idiom.
In particular, since Perl is weakly typed, I used to be able to use
unpack to unpack sequences from a string, that I could then use
immediately as integers.
In python, I find that when I use struct.unpack I tend to get strings.
(Maybe I am using it wrong?)
def f(x,y,z): print x+y+z;
f( *struct.unpack('2s2s2s','123456'))
123456
(the plus concatenates the strings returned by unpack)
But what I want is:
f( *map(lambda x: int(x), struct.unpack('2s2s2s','123456')))
102
But this seems too complicated.
I see two resolutions:
1. There is a way using unpack to get out string-formatted ints?
2. There is something like map(lambda x: int(x) without all the
lambda function call overhead. (e.g., cast tuple)?
[And yes: I know I can write my own "cast_tuple" function -- that's
not my point. My point is that I want a super-native python inline
solution like (hopefully shorter than) my "map" version above. I
don't like defining trivial functions.]
W
In [31]: import re
In [32]: sum(int(x) for x in re.findall("..", s))
Out[32]: 102
To get a tuple instead of the sum, just do:
In [33]: tuple(int(x) for x in re.findall("..", s))
Out[33]: (12, 34, 56)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
rantingrick wrote: Well not if you are referring to how people "say" things. But what people "say" and the facts of reality are some times two different things. Heck we even have a few folks in this group who overuse the expression "used to" quite frequently in place of the more correct term "previously" -- i won't give names. Rick, do you know *ANY* other language other than English? Not everybody understands English on an Oxford level (and I doubt you do). You're just a loud-mouthing (probably incorrect English) idiot. (Spare your comments about personal attacks, you're not so stupid to not know why you regularly receive such comments) Lurking for long enough to know your style. Looking at your Unicode rant, combined with some other comments and your general "I am right and you are wrong because you disagree with me." style, I came to the conclusion, that you are either a faschist or the perfect role model for an imperialistic, foreign culture destroying, self-praising, arrogant, ignorant moron. When any object is "born" (whether it be a life form, or a planet, or even a class instance) "it" will be zero years old until 1 year of time has passed has passed. A year is not the smallest index. A year is 365 days is 8760 hours is 525600 is 31536000 minutes, and so on and so on and so on... That's *totally* different from array[0], array[1], etc. There is *NO* array[0.5]. Going down to the smalled possible time scale (quantum physics level ), what is the the correct index for "my baby is *just* born, hence it's X quantum leap old." where x might be 0 or 1. Yes, I know that this is nonsense (since such a discrete quantum leap doesn't even exists) but so is the whole discussion. Something starts at 0, others at 1. You only have to add/sub 1 depending on the situation. Mind-boggling, I must say! And really, even brand-new programmer will face *A LOT* harder problems than this. Programming is not stamp collecting! Programming requires a half working brain, and those who don't have that, should sort their stamps while watching some "Next top model" stuff on TV. "Make everything as simple as possible, but not simpler." - Einstein -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
Terry Reedy wrote: On 8/9/2010 11:16 AM, Grant Edwards wrote: Just for the record: I sincerely apologize for my rant. I usually don't loose control so heavily, but this "Rick" person makes me mad (killfile'd now) IOW, the "Ugly American". No! That's not what I said. I'm myself one of those "bad germans" and I *entirely* agree with Mr. Reedy's comment: Stereotypically bashing "Americans" is as ugly and obnoxious as bashing any other ethnic group. I have traveled the world and Americans are no worse, but are pretty much the same mix of good and bad. It is certainly off-topic and inappropriate for this group. -- http://mail.python.org/mailman/listinfo/python-list
Re: get python bit version as in (32 or 64)
On 19.10.2010 23:18, Vincent Davis wrote:
How do I get the bit version of the installed python. In my case, osx
python2.7 binary installed. I know it runs 64 bt as I can see it in
activity monitor. but how do I ask python?
sys.version
'2.7 (r27:82508, Jul 3 2010, 21:12:11) \n[GCC 4.0.1 (Apple Inc. build 5493)]'
In [1]: import platform
In [2]: platform.architecture()
Out[2]: ('32bit', 'ELF')
In [3]:
--
http://mail.python.org/mailman/listinfo/python-list
