Re: Initial nose experience
Hi Roy, > I've been using unittest for many years, but have steadfastly (perhaps stubbornly) avoided newfangled improvements like nose. I finally decided to take a serious look at nose. Thanks for sharing your nose experience. What motivated you to migrate from unittest to nose? After years of using unittest, what would you say are the pros and cons of nose? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Outlook, sendinf an image in the body of email
> Problem is, this line is not understood: > > mail.BodyFormat = OlBodyFormat.olFormatHTML Try olBodyFormat (lower case 'o') Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex Question
Steven, Well done!!! Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Top-posting &c. (was Re: [ANNC] pybotwar-0.8)
Hi Steve, > I don't think I'm some sort of hyper-evolved mega-genius with a brain the > size of a planet, I'm just some guy. Based on reading thousands of your posts over the past 4 years, I'll have to respectfully disagree with you on your assertion that you are not some hyper-evolved genius with a brain the size of a planet. :) I've learned a ton from reading your posts - so much so that I think my brain is getting heavier[1]. Thank you and cheers! Malcolm >From a recent thread on this mailing list (hilarious) http://onceuponatimeinindia.blogspot.in/2009/07/hard-drive-weight-increasing.html -- http://mail.python.org/mailman/listinfo/python-list
Re: VPS For Python
> I will really appreciate if someone type the address of any of the following > for use with python > 1>Webhost > 2>Shell Account > 3>VPS Check out webfaction.com - they provide great support for Python. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASED] Python 3.3.0
> Agreed - this is a really nice release, thanks to all who put it together. +1 Thank you! Malcolm -- http://mail.python.org/mailman/listinfo/python-list
clicking on turtle
I have a problem with the standard "turtle" module. When a turtle has
a custom shape of type "compound", it doesn't seem to respond to click
events. No problem with polygon shapes.
Running python 3.2.3, turtle version 1.1b on Windows XP.
Here is my test file:
##
import turtle
square = ((0,0),(0,20),(20,20),(20,0))
turtle.addshape("sq1", square) # sq1 = polygon shape
s = turtle.Shape("compound")
s.addcomponent(square, "red")
turtle.addshape("sq2", s) # sq2 = compound shape
t1 = turtle.Turtle(shape="sq1")
t2 = turtle.Turtle(shape="sq2")
t2.fd(20) # set the turtles side by side
def click(x,y): print("click at",x,y)
t1.onclick(click)
t2.onclick(click)
turtle.mainloop()
##
When I run this and click on the black square (i.e. t1), the message
"click at..." gets printed on the console. When I click on the red
square (i.e. t2), nothing happens.
Bug or feature?
--Nicolas
--
http://mail.python.org/mailman/listinfo/python-list
Re: speaking at PyCon
Roy, > Let me add one suggestion -- never, ever, ever, type a URL into a browser > connected to the internet in front of a live audience. You never know when > you're going to make a typo and something *totally* not what you expected > will fill the screen. Great advice! Years ago I did a presentation on Python and then launched a browser to give a tour of the Python website. When I went to enter the URL, I accidentally typed in python.com (which at the time was an adult website) vs. python.org. Talk about getting your audience's attention!! Malcolm BTW: Great tips Eric - thanks for sharing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comments wanted: Proposed change to install layout
Van, > ... harmonize the install layout for Python between platforms. > 1) the 'Scripts' directory would change to 'bin'; > 2) python.exe would move to the 'bin' directory; and > 3) the installer for Windows would get the optional ability to add this directory to the PATH. 1 vote in support of your proposal. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-URL! - weekly Python news and links (Mar 31)
Thanks for all your hard work - I learned a lot by visiting the links you guys gathered over the years. Best regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Is there a better way to do this snippet?
I played around with a few things and this works but was wondering if there was a better way to do this. My first thought was list comprehension but could not get a figure out the syntax. tag23gr is a list of lists each with two items. g23tag is an empty dictionary when I run the for loop below. When is is complete each key is a graphic name who's values are a list of tags. for item in tag23gr: ... value, key = tuple(item) ... if(g23tag.get(key)): ... g23tag[key].append(value) ... else: ... g23tag[key] = [value] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Tkinter by John E Grayson
> Mark Lutz' "Programming Python" has extensive coverage of Tkinter (it's a huge book and devotes several chapters to Tkinter), and has been updated at regular intervals, most recently in the last year or two; I've found it a very helpful reference and guide to Tkinter programming. +1 I highly recommend Mark's book. An excellent resource on not only Tkinter, but many other Python topics as well. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Tkinter by John E Grayson
> Tk has gone through some dramatic improvements since that time. > One which has seen a lot of love is http://www.tkdocs.com/>. I agree with Ben. Tkinter (with ttk) is now a viable GUI framework. Key benefits of Tkinter/ttk to consider when evaluating other tool kits: 1. Tkinter/ttk is bundled with Python meaning distribution is almost painless. 2. Tkinter/ttk are very light weight in terms of the size they add to a distribution. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
DIR reports file timestamp and size, but os.path.getctime(), os.path.getsize() raise WindowsError [Error 5] Access is denied
Wondering if any of you have stumbled across the following behavior: I'm doing a recursive directory listing of my Windows folder and I can access the timestamps and file sizes of all files except the following 6 files: In the \windows\microsoft.net\framework\v2.0.50727\config folder: enterprisesec.config.cch.6824.14057640 security.config.cch.6824.14057640 In the \windows\\microsoft.net\framework64\v2.0.50727\config folder: \enterprisesec.config.cch.4412.14151427 enterprisesec.config.cch.6912.14056844 security.config.cch.4412.14151427 security.config.cch.6912.14056844 When I attempt to do any of the following on the above files, a WindowsError exception is raised with a value of "[Error 5] Access is denied: ...". os.path.getctime() os.path.getatime() os.path.getmtime() os.path.getsize() What's strange is that the DIR command from a cmd prompt returns timestamps and file sizes for the above files. Background; 64-bit Windows 7; 32-bit Python 2.7.2 Any ideas on how I can retrieve timestamps and file sizes like DIR without raising exceptions? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
Luis, Not the OP, but thank you for passing on the CoffeeScript recommendation - looks very interesting!! http://jashkenas.github.com/coffee-script/ Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
SQL Server 2008R2 databases via Python 2.7 and Windows XP and higher
Looking for some real-world advice on what is the best way to access MS SQL Server 2008R2 databases via Python 2.7 running under Windows XP, Vista, and Windows 7 and Windows Server 2005 and 2008. Based on my research, here's my list of choices: mxODBC [1]http://www.egenix.com/products/python/mxODBC/ pyOdbc 2.1.8 [2]http://code.google.com/p/pyodbc pyMSSQL 1.02 [3]http://code.google.com/p/pymssql Any tips or advice appreciated. Thanks, Malcolm References 1. http://www.egenix.com/products/python/mxODBC/ 2. http://code.google.com/p/pyodbc 3. http://code.google.com/p/pymssql -- http://mail.python.org/mailman/listinfo/python-list
Python 2.7.2 for Windows reports version as 2.7.0?
Just installed the 32-bit version Python 2.7.2 for Windows via the python-2.7.2.msi download. When I start Python via python.exe or Idle, the version info is reported as 2.7.0 vs. 2.7.2. Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version_info sys.version_info(major=2, minor=7, micro=0, releaselevel='final', serial=0) >>> Here's the info on python.exe 06/12/2011 03:09 PM26,624 python.exe 06/12/2011 03:06 PM 27,136 pythonw.exe Is this a bug or did I upgrade my version of Python 2.7 wrong? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.2 for Windows reports version as 2.7.0?
Hi Benjamin, > The file info is seems correct but I just checked the MSI and it's reporting that it's 2.7.2. How exactly are you running python.exe and IDLE- are you calling the full path, just calling "python" and using whichever python version is first on your path, or are you using an entry in the start menu? The only thing I can think of is that your 2.7.0 install is in a different location than your 2.7.2 install. So 2.7.2 installed correctly but you're still running the old one. Within the folder where the python.exe exists, I have tried the following, all of which report Python 2.7.0 vs. 2.7.2 python python.exe c:\python27 Confirming I'm running what I think I'm running: >>> import sys >>> sys.hexversion 34013424 >>> sys.executable 'C:\\Python27\\python.exe' >>> And confirming the exe files in my Python27 folder: Directory of C:\Python27 06/12/2011 03:09 PM26,624 python.exe 06/12/2011 03:06 PM27,136 pythonw.exe Anyone else having the same experience? Malcolm On Fri, Jun 17, 2011 at 5:55 PM, wrote: > Just installed the 32-bit version Python 2.7.2 for Windows via the > python-2.7.2.msi download. > > When I start Python via python.exe or Idle, the version info is reported as > 2.7.0 vs. 2.7.2. > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.2 for Windows reports version as 2.7.0?
Benjamin, I tried uninstalling and re-installing Python 2.7.2 without success ... I kept getting the proper exe's, but when run, the Python version continued to be reported as 2.7.0. Finally I installed for current user only (vs. all users) - the installation now correctly reports my version as 2.7.2. Hopefully this will help others. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.2 for Windows reports version as 2.7.0?
Hi Mark, > The version info comes from the DLL - I wonder if the DLL being found is > somehow old? > > Make sure: > > >>> import sys > >>> win32api.GetModuleFileName(sys.dllhandle) > > Is the DLL you expect. After uninstalling and reinstalling for the current user only (vs. all users), Python now reports the correct version number. And running your code above confirms that the proper DLL is being loaded (c:\Python27\Python27.dll). My original version of Python 2.7.0 was installed for all users and when I ran the 2.7.2 MSI I chose to install for all users as well. After running the 2.7.2 MSI, my Python exe's had the correct timestamps, but I failed to check the python27.dll timestamp to see if this file was out-of-date. I wonder if changing my install method to current user forced the installation of the updated python27.dll? And perhaps the default 2.7.2 installation in all users mode (when one is updating an existing 2.7 installation) doesn't update the Python27.dll under some conditions? Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Mac OS X 10.6.6 and MacPyhton 2.6 idle doesn't work
Benjamin, > You'll have to install Tcl yourself. The 2.6 binaries were compiled against a newer version than Apple ships. Does this requirement apply to Python 2.7 or Python 3.2 for the Mac or is this requirement Python 2.6 specific? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: HOWTO: Parsing email using Python part1
Alain, > I have written an article about parsing email using Python. The article is at > http://blog.magiksys.net/Parsing-email-using-python-header and the full content is here. Very helpful - thank you! Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Tips/lessons learned for writing a Python powered DSL?
Looking for tips and lessons learned (advice on what to do and not do) for writing a Python based DSL. Googling python dsl yields some wonderful content which I've just started to read. If there are specific articles or 3rd party libraries that you used to implement a DSL, I would appreciate hearing about them. Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Function docstring as a local variable
I'm not sure how a function can get a generic handle to itself, but if you're willing to hardcode the function name, then this technique works: def test(): """This is my doc string""" print test.__doc__ test() Outputs: This is my doc string Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
> Bah, when I started programming > on the Apple ][+, we had no > lower-case and a 40-column limit > on the TV display. Keyboards??? That was a luxery! We had mechanical switches that one had to physically push and pull to enter commands. And a 40 column display??? Unheard of! We were happy with several miniature flashlight bulbs! But you try and tell the young people today that... and they won't believe ya'. Fond memories! Malcolm Ref: http://totallytrygve.com/computer.php?item=188&picture=0 http://www.logikus.info/english.htm http://oldcomputermuseum.com/logix_kosmos.html http://www.classiccmp.org/pipermail/cctech/2007-October/086682.html http://www.computerhistory.org/collections/accession/102621921 http://www.classiccmp.org/dunfield/ (scanned manual) -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
Xah,
1. Is the following string considered legal?
[ { ( ] ) }
Note: Each type of brace opens and closes in the proper sequence. But
inter-brace opening and closing does not make sense.
Or must a closing brace always balance out with the most recent opening
brace like so?
[ { ( ) } ]
2. If there are multiple unclosed braces at EOF, is the answer you're
looking for the position of the first open brace that hasn't been closed
out yet?
Malcolm
--
http://mail.python.org/mailman/listinfo/python-list
Re: Validating Entry in tkinter
Peter, How would your examples work with text being inserted or deleted via the clipboard? Is there anything special that would have to happen for changes to a widget's value as the result of one of these events? Thank you, Malcolm (not the OP) -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Hi Terry, > Ethan's proposal was accepted on python-ideas. In Python 3.3, the classes for > the singletons None, Ellipsis, and NotImplemented will be callables that > return the singleton. Thanks for sharing this news. Its motivating to see this type of feedback loop because it encourages others (myself included!) to become more involved in the process. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython and TK
Azrael, > Isn't it maybe time to throw out TK once and for all? Python is missing one > of the most important aspects of todays IT industry. GUI development native > library (I mean a serious one). Check out enhancements to Tk like Ttk included in Python 2.7 and 3.1 and above. http://www.tkdocs.com/tutorial/styles.html Tk/Ttk is a much lighter weight GUI than wxPython and allows for commercial quality, cross-platform GUI development. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Diffs
Croepha, You may find it simpler and sufficiently efficient to compress your objects in whatever format they exist (pickle, json, xml, etc) and send the compressed equivalents vs. trying to diff on side and reassemble on the other side. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Reusable ways to wrapping thread locking techniques
I'm reviewing a lot of code that has thread acquire and release locks scattered throughout the code base. Would a better technique be to use -- http://mail.python.org/mailman/listinfo/python-list
Re: Reusable ways to wrapping thread locking techniques
Hit send too soon ... I'm reviewing a lot of code that has thread acquire and release locks scattered throughout the code base. Would a better technique be to use contextmanagers (for safe granular locking within a function) or decorators (function wide locks) to manage locks or am I making things too complicated? Am I reinventing the wheel by creating my own versions of above or are there off-the-shelf, debugged versions of above that one can use? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Interact with SQL Database using Python 2.4 or lower
> Personally, I'm a major fan of Webfaction -- from price to plans to what's > supported to actual effectiveness of their tech support. +1 Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing WebDAV server
Hi Fokke, Disclaimer: I have no experience with the Python WebDAV package you're using. But a thought: > In the config file it says: > "# main directory > directory = \Webdav" Perhaps you should qualify your directory path with a drive letter? I would try this 2 ways: directory = E:\Webdav And if that doesn't work: directory = E:/Webdav My thinking about the 2nd example is that perhaps the \W is getting interpreted as a control character vs. "backslash" "W". Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: slightly OT -- LaTeX
Hi Alan, Thanks for sharing that link - very interesting! http://www.pytex.org/ Malcolm (former LaTeX/TeX user from early 90's) -- http://mail.python.org/mailman/listinfo/python-list
Re: Hello, and request for help with 'dynamic grids'
Hi Simon, > I am a applications developer - originally from Windows using primarily Visual Foxpro, although I am familiar with a variety of other xbase derivatives. Check out dabodev.com. Dabo is a Python framework created by former VFP developers. Highly recommended. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
jQuery-like sliding container animations for Tkinter?
Any thoughts on the ability to implement jQuery-like sliding container animations in Tkinter? By jQuery animations I mean the smooth sliding effects one sees on many websites where containers slide in and out of visible view or smoothly shrink or grow? My working knowledge of Tkinter tells me that Tkinter's pack and grid layout techniques will not be optimal for the above type of animations. Is there a Tkinter technique or underlying TCL technique that might support these type of effects? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN]VTD-XML 2.10
Jimmy, How does VTD-XML compare to XML tools in the stdlib or to 3rd party alternatives like lxml? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Tools for Visual Studio from Microsoft - Free & Open Source
Roland, > http://pytools.codeplex.com Looks very impressive! Thank you for sharing this work. For others following this thread - this add-in to Visual Studio works with CPython 2.5 - 3.2 and is not dependent on .NET or IronPython - this project also brings HPC (high performance computing) and MPI support to CPython using the latest Microsoft API's for large scale data and computing Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: ttk styles
Peter, Sorry I can't be of much help, but I share the same interest as you. There may be some teaser info here although I can't claim to understand the technique. http://www.java2s.com/Open-Source/Python/3.1.2-Python/Demo/Demo/tkinter/ttk/notebook_closebtn.py.htm If you have any links/documentation to share, I would love to see what you've found so far. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex in if statement.
I agree with previous comments. There are plenty of good tutorials, I have sometimes found more useful for learning than the manuals. The manuals are good but I prefer examples. http://www.tutorialspoint.com/python/python_reg_expressions.htm http://www.awaretek.com/tutorials.html#regular Bill Sneddon -- http://mail.python.org/mailman/listinfo/python-list
Re: Proxy authentication required
On Mar 21, 7:02 pm, Chris Rebert wrote:
> On Mon, Mar 21, 2011 at 2:38 AM, gervaz wrote:
> > Hi all,
> > I've got to download some web pages but I'm behind a proxy. So far
> > this is what I've used without any successful result receiving the
> > error: "urllib.error.HTTPError: HTTP Error 407: Proxy Authentication
> > Required ( The ISA Server requires auth
> > orization to fulfill the request. Access to the Web Proxy filter is
> > denied. )":
>
> > hc = urllib.request.HTTPCookieProcessor()
> > hp = urllib.request.ProxyHandler({"http": "10.242.38.251:80",
> > "username": "domain\username", "password": "password"})
>
> Remember that backslash is used for string escapes in Python; so that
> should be "domain\\username" in order to get 1 literal backslash. I
> suspect this is the cause of your proxy authentication problem.
>
> > opener = urllib.request.build_opener(hc, hp)
>
> Are you sure that's the right order for the handlers? (I don't know myself.)
>
> > urllib.request.urlopen("http://www.google.it/";)
>
> Cheers,
> Chris
> --
> Windows, Y U use backslash for stuff!?http://blog.rebertia.com
did this a long time ago when behind a corporate proxy server worked
then might be a start for you
I am fuzzy on the details.
import httplib
import base64
import getpass
def getWebPage(userName='YourUserName',httpPage='http://
weather.noaa.gov/weather/current/KRIC.html',outFilePath=None):
# 1. connect to the proxy
h1 = httplib.HTTP("proxyconf",)
# 2. give the absolute URL in the request
h1.putrequest('GET', 'http://weather.noaa.gov/weather/current/
KRIC.html')
h1.putheader('Accept', 'text/html')
h1.putheader('Accept', 'text/plain')
password = getpass.getpass()
# 3. set the header with a base64 encoding of user-id:passwd
userString = "%s:%s" % (userName,password)
auth = "Basic " + base64.encodestring(userString)
h1.putheader('Proxy-Authorization', auth)
h1.endheaders()
# 4. get the page
errcode, errmsg, headers = h1.getreply()
print errcode
print errmsg
print headers
f=h1.getfile()
if(not outFilePath):
for line in f.readlines():
print line
else:
try:
outFile = open(outFilePath,'w')
# yada yaha
--
http://mail.python.org/mailman/listinfo/python-list
Re: Alphabetics respect to a given locale
Candide, Perhaps the Python Babel project has something that might help out? http://babel.edgewall.org/ If this works out for you can you share your learning with the rest of us? :) Thanks and good luck! Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Light weight IDE like pywin for os x 10.6
I have looked a while for this answer. Sorry if it right before me. I have move from Windows to os x. The thing I miss most is pywin. I know you can purchase or download full IDE's for python or even use Eclipse. I really liked the ability to switch from interactive interpreter to editor easily. The autocompletion is very helpful so idle does not quite cut it for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Light weight IDE like pywin for os x 10.6
On Apr 5, 1:26 pm, Detlev Offenbach wrote: > python wrote: > > I have looked a while for this answer. Sorry if it right before me. > > > I have move from Windows toosx. The thing I miss most is pywin. > > I know you can purchase or download fullIDE'sfor python or even use > > Eclipse. I really liked the ability to switch from interactive > > interpreter to editor easily. The autocompletion is very helpful so > > idle does not quite cut it for me. > > How about eric (http://eric-ide.python-projects.org)? > > Detlev > -- > Detlev Offenbach > det...@die-offenbachs.de I did look at it once. It does not seem light weight and could not figure out how to get interactive interpreter window. Maybe I was missing something. Someone suggested Editra http://editra.org/. This seems to meet my needs. Thanks, Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Dictionary from String?
On May 8, 12:43 pm, Benjamin Kaplan wrote:
> On Sun, May 8, 2011 at 8:20 AM, Greg Lindstrom wrote:
> > Is it possible to create a dictionary from a string value? Something along
> > these lines (but that works):
>
> >>>> mystring = "{'name':'greg','hatsize':'7 5/8'}"
> >>>> mystring
> > "{'name':'greg','hatsize':'7 5/8'}"
> >>>> dict(mystring)
> > Traceback (most recent call last):
> > File "", line 1, in
> > ValueError: dictionary update sequence element #0 has length 1; 2 is
> > required
>
> > I would like to return an undetermined (at call time) number of fields from
> > a postgres database (only 1 record) for a given request. My thought is that
> > I could build a dictionary in the form of a string, return the string and
> > then convert the string value to a dictionary. I can do that now, but I
> > have to parse the string and then build the dictionary. Any thoughts or
> > help you could provide would be appreciated.
>
> > --greg
>
> building the dictionary as a string seems like a hacky thing to do and
> you might want to reevaluate your methods. But if everything in the
> dict is a literal, you can do ast.literal_eval.
>
>
>
>
>
>
>
>
>
> > --
> >http://mail.python.org/mailman/listinfo/python-list
There are lots of possibilites and the "best" solution will very based
on your strings' structure. List of tuples convert to dict nicely for
example. So if your string can be parse to a list of tuples.
a = [ (chr(num),num) for num in range(48,58)]
[('0', 48), ('1', 49), ('2', 50), ('3', 51), ('4', 52), ('5', 53),
('6', 54), ('7', 55), ('8', 56)]
dict(a)
{'1': 49, '0': 48, '3': 51, '2': 50, '5': 53, '4': 52, '7': 55, '6':
54, '9': 57, '8': 56}
if your string looks something like your example above. The shlex
module might be helpful.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dictionary from String?
On May 9, 9:33 pm, python wrote:
> On May 8, 12:43 pm, Benjamin Kaplan wrote:
>
>
>
>
>
>
>
>
>
> > On Sun, May 8, 2011 at 8:20 AM, Greg Lindstrom
> > wrote:
> > > Is it possible to create a dictionary from a string value? Something
> > > along
> > > these lines (but that works):
>
> > >>>> mystring = "{'name':'greg','hatsize':'7 5/8'}"
> > >>>> mystring
> > > "{'name':'greg','hatsize':'7 5/8'}"
> > >>>> dict(mystring)
> > > Traceback (most recent call last):
> > > File "", line 1, in
> > > ValueError: dictionary update sequence element #0 has length 1; 2 is
> > > required
>
> > > I would like to return an undetermined (at call time) number of fields
> > > from
> > > a postgres database (only 1 record) for a given request. My thought is
> > > that
> > > I could build a dictionary in the form of a string, return the string and
> > > then convert the string value to a dictionary. I can do that now, but I
> > > have to parse the string and then build the dictionary. Any thoughts or
> > > help you could provide would be appreciated.
>
> > > --greg
>
> > building the dictionary as a string seems like a hacky thing to do and
> > you might want to reevaluate your methods. But if everything in the
> > dict is a literal, you can do ast.literal_eval.
>
> > > --
> > >http://mail.python.org/mailman/listinfo/python-list
>
> There are lots of possibilites and the "best" solution will very based
> on your strings' structure. List of tuples convert to dict nicely for
> example. So if your string can be parse to a list of tuples.
>
> a = [ (chr(num),num) for num in range(48,58)]
> [('0', 48), ('1', 49), ('2', 50), ('3', 51), ('4', 52), ('5', 53),
> ('6', 54), ('7', 55), ('8', 56)]
> dict(a)
> {'1': 49, '0': 48, '3': 51, '2': 50, '5': 53, '4': 52, '7': 55, '6':
> 54, '9': 57, '8': 56}
> if your string looks something like your example above. The shlex
> module might be helpful.
After re-reading your post saw you were reading from a database. Have
you looked at SQLAlchemy? It might have the functionality you are
trying to create.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
Irmen, > I'm going to share this thread, and the funny slideshow about Uncomment your > code, with my team at work :-) We're not a Python shop so I'm probably the > only one reading this Same here! > but as usual there is a lot of wisdom going on in this new[s]group that is > not only applicable to Python. +1 QOTW Malcolm -- http://mail.python.org/mailman/listinfo/python-list
3rd party tree/outline data structure module?
Before I reinvent the wheel, I'm wondering if anyone can recommend a 3rd party tree data structure module? (I do not need a GUI component) I've looked at ElementTree but I think(?) need something more flexible. I have a parser that reads a proprietary file format which defines an outline-like structure. (The file format is based on a legacy product). I need to create a tree data structure that supports the ability to dynamically, add, delete, and move nodes/branches. I would like the nodes to be based on my own node class. I also need to to walk the tree structure in various ways including given a node, find its previous and next nodes including moving up and down branches to find the next logical node and the ability to quickly find an element by its unique id. Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a way to globally set the print function separator?
Le 09/10/2017 à 18:22, John Black a écrit : I want sep="" to be the default without having to specify it every time I call print. Is that possible? >>> oldprint = print >>> def print(*args,**kwargs): ... oldprint(*args,**kwargs,sep='') ... >>> print(1,2,3) 123 -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > Perhaps what we want is not so much "attach docstrings to floats" but > "get documentation for a module attribute, not for the object referred > to". The reason this can't really work is that members are just variables with arbitrary values. It does not make sense for them to have doc strings. You *can* (and probably should!) document the members in the class' (or module's) doc string. That's really the only sensible place to do it. But remember that Python's idea of objects is more fluid than in other languages... You don't have constants, so you can arbitrarily change any object's member values to anything, even to the point of adding new ones at your whim. This probably would make more sense for constants, if Python had them. But you don't really need them, and there's no reason documenting the purpose of the members of a class or module in the parent object's doc string shouldn't be sufficient. -- https://mail.python.org/mailman/listinfo/python-list
ctypes help
Hello Pythonistas,
I'm starting to play with ctypes, as I'd like to provide Python
interfaces to a C/C++ library I have. For now I'm just messing with a
very simple piece of code to get things sorted out. I'm working with
this example C++ library, which just wraps a call to stat():
-=-=-=-=-=-=-
$ cat stat.cc
#include
#include
#include
extern "C" int my_stat(const char *path, struct stat *st)
{
return stat(path, st);
}
-=-=-=-=-=-=-
Then I compile this to a shared object with g++ -shared -fPIC in /tmp. My
attempt to wrap that looks as follows:
-=-=-=-=-=-=-
#!/usr/bin/python
import ctypes
libc = ctypes.CDLL("/tmp/my_stat.so")
stat = libc.my_stat
class Timespec(ctypes.Structure):
_fields_ = [("tv_sec", ctypes.c_longlong),
("tv_usec", ctypes.c_longlong)]
class Stat(ctypes.Structure):
_fields_ = [("st_dev", ctypes.c_ulong),
("st_ino", ctypes.c_ulong),
("st_mode", ctypes.c_ulong),
("st_nlink", ctypes.c_ulong),
("st_uid", ctypes.c_ulong),
("st_gid", ctypes.c_ulong),
("st_rdev", ctypes.c_ulong),
("st_size", ctypes.c_ulonglong),
("st_blksize", ctypes.c_ulonglong),
("st_blocks", ctypes.c_ulonglong),
("st_atim", Timespec),
("st_mtim", Timespec),
("st_ctim", Timespec)]
Stat_p = ctypes.POINTER(Stat)
stat.argtypes = [ctypes.c_char_p, Stat_p]
path = "/tmp"
c_path = ctypes.c_char_p(path)
st = Stat()
rc = stat(c_path, ctypes.byref(st))
print rc
print st.st_dev
print st.st_ino
print st.st_mode
print st.st_nlink
print st.st_uid
print st.st_gid
print st.st_size
print st.st_atim
print st.st_mtim
-=-=-=-=-=-=-
This crashes immediately on one system, actually does work as expected
on another, but crashes before exiting. Clearly I must be doing
something wrong, but what?
On the system I have handy at the moment, it does not print any output, and
backtrace looks like this:
$ ./my_ctypes.py
*** Error in `/usr/bin/python': corrupted size vs. prev_size:
0x027b8320 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f6444a907e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7e9dc)[0x7f6444a979dc]
/lib/x86_64-linux-gnu/libc.so.6(+0x81cde)[0x7f6444a9acde]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f6444a9d184]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_doallocate+0x55)[0x7f6444a861d5]
/lib/x86_64-linux-gnu/libc.so.6(_IO_doallocbuf+0x34)[0x7f6444a94594]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_overflow+0x1c8)[0x7f6444a938f8]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_xsputn+0xad)[0x7f6444a9228d]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0xc90)[0x7f6444a66e00]
/lib/x86_64-linux-gnu/libc.so.6(__fprintf_chk+0xf9)[0x7f6444b2fb89]
/usr/bin/python[0x53290c]
/usr/bin/python[0x511c1f]
/usr/bin/python(PyFile_WriteObject+0x533)[0x5116d3]
/usr/bin/python(PyEval_EvalFrameEx+0x3a8f)[0x4c7a8f]
/usr/bin/python(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python(PyEval_EvalCode+0x19)[0x4c2509]
/usr/bin/python[0x4f1def]
/usr/bin/python(PyRun_FileExFlags+0x82)[0x4ec652]
/usr/bin/python(PyRun_SimpleFileExFlags+0x191)[0x4eae31]
/usr/bin/python(Py_Main+0x68a)[0x49e14a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6444a39830]
/usr/bin/python(_start+0x29)[0x49d9d9]
--
https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: > > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > >> Perhaps what we want is not so much "attach docstrings to floats" but > >> "get documentation for a module attribute, not for the object referred > >> to". > > > > The reason this can't really work is that members are just variables > > with arbitrary values. It does not make sense for them to have doc > > strings. > > Did you read my post? Yes! Did you read mine? I tried to explain to you that what you're suggesting doesn't really fit Python's paradigm: Doc strings describe their owner class, not individual instances--the class' doc string is where the description of your class (or module--same thing) attributes should go. Of course, in most cases you can set the doc strings to whatever you want, but in doing so you wipe out the owner class' documentation. If others are using your code, they may not expect or want this, so that's mostly a bad idea. You need a new attribute to set the instance description, and you can in fact just add that yourself if you want to. Monkeypatch to your heart's content! In this paradigm, the class for pi in your example is float, i.e. a floating point number, where the doc string for that class would logically be "A floating point number"--but since this is obvious, there is no compelling reason to even have it. In fact, it DOES have it: >>> x = 1.3 >>> x.__doc__ 'float(x) -> floating point number\n\nConvert a string or number to a floating point number, if possible.' Fundamental types have read-only doc strings, because it's the only thing that makes sense. But know what? In fact, if you really want to, you *can* get your attrs to have descriptive doc strings... by defining your own class that inherits from float (or whatever): -=-=-=-=-=-=- $ cat pi.py #!/usr/bin/python class Pi(float): def __init__(self): self.__doc__ = "the constant pi" def __new__(cls, value = 3.1415927): return float.__new__(cls, 3.1415927) x = Pi() print x print x + 2 print x.__doc__ $ ./pi.py 3.1415927 5.1415927 the constant pi -=-=-=-=-=-=- But asking the standard modules to do this is mostly silly, because it doesn't fit the paradigm... It changes the purpose of the doc string, and obliterates the information it is INTENDED to convey. But since this is Python, you can still do it if you want to. -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
On Sat, Nov 18, 2017 at 10:49:40AM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 9:11 AM, Python wrote: > > Hello Pythonistas, > > > > I'm starting to play with ctypes, as I'd like to provide Python > > interfaces to a C/C++ library I have. For now I'm just messing with a > > very simple piece of code to get things sorted out. I'm working with > > this example C++ library, which just wraps a call to stat(): > > I would recommend you look into Cython, which can help you write C > code that links to Python without all the hassle of manually tracking > refcounts etc. (I also recommend using Python 3 instead of Python 2, > but that's a separate point.) Cython looks interesting, but none of your suggestions are options in my situation. -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 02:19:25PM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 2:12 PM, Python wrote: > > On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: > >> On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: > >> > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > >> >> Perhaps what we want is not so much "attach docstrings to floats" but > >> >> "get documentation for a module attribute, not for the object referred > >> >> to". > >> > > >> > The reason this can't really work is that members are just variables > >> > with arbitrary values. It does not make sense for them to have doc > >> > strings. > >> > >> Did you read my post? > > > > Yes! Did you read mine? I tried to explain to you that what you're > > suggesting doesn't really fit Python's paradigm: Doc strings describe > > their owner class, not individual instances--the class' doc string is > > where the description of your class (or module--same thing) attributes > > should go. > > I gave a detailed example of something that was NOT a docstring. That > was, in fact, the whole point of my post. Ah... Sorry, I didn't find that to be clear from your post, even after rereading it... I took it to mean that *conceptually* it was different from a doc string, but still actually using the doc string via some magic, the description of which I honestly found kind of vague and hand-wavey, not so much detailed. And TBH I still do, even now that I have a better idea what you're talking about. ¯\_(ツ)_/¯ Apologies for my confusion. -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
Eryk,
Thanks much for the excellent and highly detailed response! That made
a lot of things clear.
On Sat, Nov 18, 2017 at 10:56:27AM +, eryk sun wrote:
> On Fri, Nov 17, 2017 at 10:11 PM, Python wrote:
> >
> > I'm starting to play with ctypes, as I'd like to provide Python
> > interfaces to a C/C++ library I have. For now I'm just messing with a
> > very simple piece of code to get things sorted out. I'm working with
> > this example C++ library, which just wraps a call to stat():
>
> Calling POSIX system functions via ctypes can be difficult if they use
> struct layouts that vary with the target platform and architecture.
>
> > class Stat(ctypes.Structure):
> > _fields_ = [("st_dev", ctypes.c_ulong),
> > ("st_ino", ctypes.c_ulong),
> > ("st_mode", ctypes.c_ulong),
> > ("st_nlink", ctypes.c_ulong),
> > ("st_uid", ctypes.c_ulong),
> > ("st_gid", ctypes.c_ulong),
>
> For x64 the above incorrectly uses 64-bit integers for mode, uid, and
> gid. Also, it has mode and nlink flipped around in the x86 order
> instead of the new x64 order.
>
> > ("st_rdev", ctypes.c_ulong),
> > ("st_size", ctypes.c_ulonglong),
> > ("st_blksize", ctypes.c_ulonglong),
> > ("st_blocks", ctypes.c_ulonglong),
> > ("st_atim", Timespec),
> > ("st_mtim", Timespec),
> > ("st_ctim", Timespec)]
>
> Try to strictly adhere to the defined types. Don't use `long long` for
> a `long`, even if it happens to be the same size in a given
> architecture. Also, avoid using definitions from docs and man pages.
> Use the exact headers that the compiler sees. In this case, you missed
> the 3 reserved long-integer fields at the end on x64 builds. Your Stat
> struct is 128 bytes overall instead of the required 144 bytes. glibc
> will corrupt the heap when it writes to the last 16 bytes. The best
> case is that this immediately crashes Python.
>
> Below I've included an example ctypes wrapper for calling stat() on
> Linux x64 and x86 systems. I verified the sizes and offsets and tested
> in 64-bit Python. From a C test program, I also have the field sizes
> and offsets for the two 32-bit cases (with and without large file
> support), but I'd need to build 32-bit Python to verify that the
> ctypes wrapper is correct. I have no personal use for 32-bit Python,
> so I leave that part up to you.
>
> C header definitions from time.h, bits/typesizes.h, bits/types.h, and
> bits/stat.h:
>
> #define __DEV_T_TYPE __UQUAD_TYPE
> #define __INO_T_TYPE __SYSCALL_ULONG_TYPE
> #define __INO64_T_TYPE __UQUAD_TYPE
> #ifdef __x86_64__
> #define __NLINK_T_TYPE __SYSCALL_ULONG_TYPE
> #else
> #define __NLINK_T_TYPE __UWORD_TYPE
> #endif
> #define __MODE_T_TYPE __U32_TYPE
> #define __UID_T_TYPE __U32_TYPE
> #define __GID_T_TYPE __U32_TYPE
> #define __OFF_T_TYPE __SYSCALL_SLONG_TYPE
> #define __OFF64_T_TYPE __SQUAD_TYPE
> #define __BLKSIZE_T_TYPE __SYSCALL_SLONG_TYPE
> #define __BLKCNT_T_TYPE__SYSCALL_SLONG_TYPE
> #define __BLKCNT64_T_TYPE __SQUAD_TYPE
> #define __TIME_T_TYPE __SYSCALL_SLONG_TYPE
>
> struct timespec
> {
> __time_t tv_sec;
> __syscall_slong_t tv_nsec;
> };
>
> struct stat
> {
> __dev_t st_dev;
> #ifndef __x86_64__
> unsigned short int __pad1;
> #endif
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __ino_t st_ino;
> #else
> __ino_t __st_ino;
> #endif
> #ifndef __x86_64__
> __mode_t st_mode;
> __nlink_t st_nlink;
> #else
> __nlink_t st_nlink;
> __mode_t st_mode;
> #endif
> __uid_t st_uid;
> __gid_t st_gid;
> #ifdef __x86_64__
> int __pad0;
> #endif
> __dev_t st_rdev;
> #ifndef __x86_64__
> unsigned short int __pad2;
> #endif
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __off_t st_size;
> #else
> __off64_t st_size;
> #endif
> __blksize_t st_blksize;
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __blkcnt_t st_blocks;
> #else
> __blkcnt64_t st_blocks;
> #endif
> #ifdef __USE_XO
Re: urllib2 urlopen takes too much time
On Sun, Dec 03, 2017 at 09:49:45AM -0800, cpol...@vt.edu wrote: > On Tuesday, June 23, 2009 at 11:09:30 PM UTC-4, Aahz wrote: > > In article , > > =?UTF-8?Q?Filip_Gruszczy=C5=84ski?= wrote: > > > > > >I have encountered a performance problem using suds, which was traced > > >down to _socket.recv. I am calling some web services and each of them > > >uses about 0.2 sec and 99% of this time is spent on urllib2.urlopen, > > >while the rest of the call is finished in milliseconds. > > > > What happens if you use urlopen() by itself? > > I am having the same issue. Did you ever figure out a solution? > The time delay is also the same, from .2 to .25 sec. I need to stay > with urlopen though so I can do a custom request header Depending on your network conditions, this doesn't seem all that outrageous. Using tcpdump or some other packet sniffer should reveal what is going on, but most likely urlopen() needs to do all of the following, every time it is called: - resolve the address via DNS + 1 round trip: DNS request + response; possibly more if DNS doesn't have host entry and forwards... - initiate a TCP connection + three way handshake = 1.5 round trip times - send the request (.5 round trip) - wait for server processing (unknown time) - receive the response (.5 round trip time) If the DNS server is busy, or the SOAP server is busy, add that latency to the mix. Assuming NO latency due to server load, you're still looking at 3.5 round trips to service the request, or 7 one-way (possibly 6, if the ACK contains the request, which IIRC is allowed). .2s / 7 = ~29ms, so if the latency between server and client is 29ms or higher, that explains everything. On a LAN I'd hope for much better than 29ms latency (1ms is more typical), but it's not outside the realm of possibility depending on network architecture and load. Ping to the server will tell you that... if your network isn't blocking ICMP. If the C# app is faster, my guess would be it is caching the DNS response and/or maintaining persistent connections to the server, whereas urllib isn't, though that's just a guess... I'm not familiar with the implementations of either. But again, a packet sniffer should show you exactly what's happening and who is being slow. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
On Tue, Dec 05, 2017 at 06:23:04PM -0800, Rick Johnson wrote: > [bunch of old, irrelevant context snipped] > > item = seq[n:n+1] > > if item: > > process(item) > > else: > > do_without_item() > > When Python follows a logic clause like a train skating > along a set of railroad tracks, and finds itself in a *GHOST > TOWN*, that's not an action -- "Steve-o" -- it's a non- > action. Geez, seriously? The snippet is purely academic, obviously not a complete or useful program, intended to illustrate that python can take two different branches depending on whether or not the slicing operation yeilded a non-empty container, using uncomplicated syntax. It effectively serves that purpose. Moreover, in order for the example to make sense, we must assume the existence of unspecified code: The variables need to have been initialized previously, or else the snippet is non-functional. The if conditional would never be reached. We can as easily assume that the hypothetical example continues with other, unspecified code, and that the equally unspecified do_without_item() actually does something, which renders your argument completely invalid and pointless. The whole thing is entirely academic; continuing to argue this is an utter waste of time and bandwidth. -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Wed, Dec 06, 2017 at 10:35:58AM +1100, Steve D'Aprano wrote: > On Tue, 5 Dec 2017 07:58 pm, Lawrence D’Oliveiro wrote: > > > On Tuesday, December 5, 2017 at 3:39:26 AM UTC+13, Rick Johnson wrote: > >> > >> Sounds like your OS file associations are all botched-up ... > > > > Linux doesn’t do “OS file associations”. > > > Then how does my Linux box know that when I double-click on a text file, it > launches kwrite rather than (say) the Gimp or LibreOffice? The answer to that is (sadly) complicated. How it knows indeed depends on the context of the click, what desktop environment you're using, what application(s) you're using, and what configurations you've made to those things to address any file associations. There isn't one answer. On the same system, the answer could well be completely different for any two users, or even for the same user, given different application contexts. The latter is less true than it used to be, but still true nonetheless. Granted, this isn't a very useful answer, but it's the only one you can give that is certainly correct, without more context. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
On Wed, Dec 06, 2017 at 03:08:51PM -0800, Rick Johnson wrote: > The following is Terry's original: > > if item: > process(item) > else: > do_without_item() > > And here is the functioning equivalent, sans any fuzzy > semantics: > > if item: > process(item) > else: > pass > THIS IS FALSE. CALLING A FUNCTION IS NOT FUNCTIONALLY EQUIVALENT TO THE PASS STATEMENT. Therefore your entire premise is false, and the remainder of what you said is meaningless. -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Thu, Dec 07, 2017 at 01:29:11PM +1100, Steve D'Aprano wrote: > On Thu, 7 Dec 2017 08:22 am, Python wrote: > >> > Linux doesn’t do “OS file associations”. > >> > >> Then how does my Linux box know that when I double-click on a text file, it > >> launches kwrite rather than (say) the Gimp or LibreOffice? > > > > The answer to that is (sadly) complicated. > > Actually, no, the answer to my question is very simple: Lawrence is mistaken > about Linux not doing file associations. It does -- it is merely handled by > the desktop environment (if there is one). Pedantically speaking, this is only *probably true*, not certainly true (e.g. running Linux on a text console with something like midnight commander, some unrelated file manager while running a particular desktop environment, etc.). But more importantly, practically speaking, it still doesn't really provide much more help to the OP than Lawrence's answer. He may well know already that the desktop environment is what does the job (and probably does even, in broad terms, if he's familiar with computers in general), but have no idea how to configure it. A reasonably helpful answer would be one that mentioned a few of the likely possibilities (Gnome, KDE, Unity, /etc/mime.types, "other"), and gave hints for how to find out the answer for each. A thoroughly helpful answer would be, well, outside the scope of this list/group. Pedantry has its place, FWIW. In the computer field, as with other science and engineering disciplines, often precision is much more essential than in other fields. I personally find such precision is especially warranted if you take it upon yourself to criticize what someone else has said. Though, providing such precision via natural language often turns out to be more challenging than one would hope... -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
Hi Rick! On Wed, Dec 06, 2017 at 04:05:42PM -0800, Rick Johnson wrote: > Python wrote: > > [...] > > > THIS IS FALSE. CALLING A FUNCTION > > What *FUNCTION*? In this snippet (which again, we agreed was an incomplete academic example): if item: process(item) else: do_without_item() Can you please explain to me what sort of Python syntactical construct do_without_item() could be, other than a call to a Python callable object (i.e. a function)? Then, could you explain to me how that particular syntactical construct is in any way equivalent to the pass statement? Could you then explain to me how using that in the simple example given makes any sense whatsoever? [FWIW, if there is an answer to this, I am genuinely interested...] Since it can indeed be a function call, then if you can't do all of the above things, doesn't that imply that in the example given, do_witout_item() can't be anything BUT a function call? Even if it somehow doesn't by some logic that escapes me, for the purposes of this simple academic example, isn't it preferable to assume that it is the most obvious thing (i.e. a function call)? Isn't the else clause in fact NOT superfluous, because it illustrates that if the slice operation would be out of the container object's bounds, then item will be assigned a value that evaluates to false, enabling one to trigger the else clause of an if block to do something ONLY under that condition? > if "do_without_item()" had been defined, then you could call > it a function. But until you do, it's just a NameError. OK! Then could you explain to me how a NameError is equivalent to the pass statement? I thought one continued execution without any side effects, and the other required handling or else will stop the program. Isn't that in fact functionally nonequivalent? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
On Fri, Dec 08, 2017 at 05:12:35AM -0800, Rick Johnson wrote: > I have already backed my argument with multiple code > examples, exhaustive explanations Which were all false and/or nonsensical. > > if item: > > process(item) > > else: > > do_without_item() > > The above code sample is semantically equivalent to the > following real-life "situational logic": > > [man sits on couch and enjoys sports programming] > > if thirsty: > grab_beer_from_fridge() > else: > stay_on_couch() So what you're ultimately saying is you're making an *assumption* that the English phrase "do without item" MEANS to do nothing, and therefore do_without_item() MUST be defined as pass. However both of those things are FALSE, and once again your entire argument is completely invalid. It's also true that such an assumption is antithetical to the example. So, your assumption is both logically and contextually nonsensical. If you're on a sinking boat, and you could stop the boat from sinking if you had a rubber seal, but you don't have one, you're forced to do_without_item(). Does that mean you're going to sit in the boat and let it sink with you in it? By your arguments, apparently YOU must... But the rest of us would try to fix the leak another way, or failing that, get the hell out of the boat. I like our definition of do_without_item() better. Ned is right, you just need to be ingored. -- https://mail.python.org/mailman/listinfo/python-list
Re: urllib2 urlopen takes too much time
On Sun, Dec 03, 2017 at 09:49:45AM -0800, cpol...@vt.edu wrote: > On Tuesday, June 23, 2009 at 11:09:30 PM UTC-4, Aahz wrote: > > In article , > > =?UTF-8?Q?Filip_Gruszczy=C5=84ski?= wrote: > > > > > >I have encountered a performance problem using suds, which was traced > > >down to _socket.recv. I am calling some web services and each of them > > >uses about 0.2 sec and 99% of this time is spent on urllib2.urlopen, > > >while the rest of the call is finished in milliseconds. > > > > What happens if you use urlopen() by itself? > > I am having the same issue. Did you ever figure out a solution? > The time delay is also the same, from .2 to .25 sec. I need to stay > with urlopen though so I can do a custom request header Depending on your network conditions, this doesn't seem all that outrageous. Using tcpdump or some other packet sniffer should reveal what is going on, but most likely urlopen() needs to do all of the following, every time it is called: - resolve the address via DNS + 1 round trip: DNS request + response; possibly more if DNS doesn't have host entry and forwards... - initiate a TCP connection + three way handshake = 1.5 round trip times - send the request (.5 round trip) - wait for server processing (unknown time) - receive the response (.5 round trip time) If the DNS server is busy, or the SOAP server is busy, add that latency to the mix. Assuming NO latency due to server load, you're still looking at 3.5 round trips to service the request, or 7 one-way (possibly 6, if the ACK contains the request, which IIRC is allowed). .2s / 7 = ~29ms, so if the latency between server and client is 29ms or higher, that explains everything. On a LAN I'd hope for much better than 29ms latency (1ms is more typical), but it's not outside the realm of possibility depending on network architecture and load. Ping to the server will tell you that... if your network isn't blocking ICMP. If the C# app is faster, my guess would be it is caching the DNS response and/or maintaining persistent connections to the server, whereas urllib isn't, though that's just a guess... I'm not familiar with the implementations of either. But again, a packet sniffer should show you exactly what's happening and who is being slow. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python homework
On Tue, Dec 05, 2017 at 09:02:54PM +1200, ssghotra1997 wrote:
> for i in range(num):
> rolls = int(random.randint(1, 6))
> if rolls == 1:
> sides['One'] += 1
[...]
Using integers as the key makes the code a bit shorter... That
approach is also better if you're using a function where you don't
know the full range, or if the range is very large. In that case, you
don't need to initialize the dictionary; you can instead test if the
index exists in the dictionary already, and if not set its value to 1.
Much harder to do that if you use text keys (but not impossible--you
could write a function that converts numbers to their text names).
This is Python 2.7, but there's very little difference from the 3.x
version:
-=-=-=-=-=-=-=-
#!/usr/bin/python
import random
def roll_die(times):
sides = {1:0, 2:0, 3:0, 4:0, 5:0, 6:0}
for i in range(times):
roll = int(random.randint(1, 6))
sides[roll] += 1
return sides, max(sides,key=sides.get)
(rolls, max_side) = roll_die(50)
print rolls
print "%d was rolled the most: %d times." % (max_side, rolls[max_side])
-=-=-=-=-=-=-=-
Both versions have a flaw: If there is a tie, only one is printed:
$ ./sides.py
{1: 11, 2: 7, 3: 6, 4: 6, 5: 11, 6: 9}
1 was rolled the most: 11 times.
[So was 5.]
Here's a version that prints all sides that were rolled the maximum
number of times:
-=-=-=-=-=-=-=-
#!/usr/bin/python
import random
def roll_die(times):
sides = {1:0, 2:0, 3:0, 4:0, 5:0, 6:0}
max_rolls_sides = []
# roll the dice...
for i in range(times):
roll = int(random.randint(1, 6))
sides[roll] += 1
# find the first side which was rolled the maximum number
index = max(sides, key=sides.get)
# get the number of rolls for the side we just got
max_rolls = sides[index]
# now find all sides that have that number of rolls
for i in range(6):
current_side = i + 1
if sides[current_side] == max_rolls:
max_rolls_sides.append(current_side)
# return all those things in a tuple
return sides, max_rolls, max_rolls_sides
# roll the dice 50 times, and print the results
(rolls, max_roll, max_roll_sides) = roll_die(50)
print rolls
print "max rolls of %d was rolled on sides: %s." % (max_roll, max_roll_sides)
-=-=-=-=-=-=-=-
[The lines to calculate the index and the max_rolls can be combined,
but I left them explicitly separated as I felt it improved clarity.]
$ ./sides.py
{1: 11, 2: 11, 3: 7, 4: 6, 5: 9, 6: 6}
max rolls of 11 was rolled on sides: [1, 2].
$ ./sides.py
{1: 8, 2: 9, 3: 9, 4: 7, 5: 8, 6: 9}
max rolls of 9 was rolled on sides: [2, 3, 6].
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Learning
On Fri, Dec 15, 2017 at 04:51:09PM -0500, Bill wrote: > >I'm new to programming, can anyone guide me, how to start learning python > >programming language,...plz suggest some books also. > > > >Thanks all > > Are you sure you want to learn Python first? > Python does enough things "behind the scene" > that it makes me question the wisdom of that. > Other points of view are welcome, of course. > Learning the primitives of C++ first, may make for an easier transition. This suggestion seems completely backwards to me. One of Python's greatest strengths is its relative simplicity, as compared to lower level languages like C++ or assembly, or even other scripting languages like Perl (which is comparitively large lexicographically and syntactically). Part of the process of learning is being rewarded for what you have learned; Python does this exceptionally well by enabling the student to write useful programs with simple syntax in a very short time. Pyhon is extremely well suited to teaching basic programming skills like *using* data structures, flow control, subroutines, etc. *without* having to grasp more difficult concepts like addressing and pointers, static typing, low-level data structure implementation, etc.. Those topics would perhaps be better suited to a subsequent course, once the student has mastered (or at least gained familiarity) with some of the more introductory concents. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Thu, Feb 22, 2018 at 11:29:53PM +1100, Chris Angelico wrote: > > The idea of the Fibonacci benchmark is to test how effectively an > > implementation manages large numbers of recursive function calls. Then, > > fib(36) would normally involve 48,315,633 calls. > > > > This version does only 37, giving a misleading impression. > > Not overly misleading; the point of it is to show how trivially easy > it is to memoize a function in Python. This does not appear to me at all to be the point of the article. The point of the article seems to be that the Julia benchmarks compare unfairly the performance of Python to Julia, because they do not use algorithms that suit "the best way to use Python." But I have to agree with bartc, that is not at all the point of the benchmarks. The point of the benchmarks is to compare the performance of a particular algorithm or set of algorithms across a variety of languages. It's fine to say that this method of computing Fibonacci sequences is inefficient; but anyone who's spent any time on the problem knows that recursive function calls is not the most efficient way to calculate them in most languages. So it must follow logically that the point of the benchmark is not to prove that Julia is faster than Python at solving Fibonacci sequences, but rather that Julia is faster than Python at solving the class of problems that would be implemented in a similar manner as this particular implementation of Fibonacci sequences. No other interpretation makes any sense. And if that is the point, as logic dictates, then comparing the performance of algorithm A implemented in language X to the performance of a completely different algorithm B in language Y is generally both misleading and pointless. If you can prove that A is the most efficient alogorithm possible in X and B is the most efficient algorithm in Y, for solving the same problem, then and only then, you might have something. Otherwise, I think what you're saying is bunk. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Fri, Feb 23, 2018 at 01:27:53AM +, Steven D'Aprano wrote: > On Thu, 22 Feb 2018 17:53:30 +, bartc wrote: > > As I said, people keep missing the point. The fact this uses a grossly > > inefficient way of calculating Fibonacci seems to blind them to any > > other considerations. > > > > The actual result is irrelevant, so long as its correct. The important > > thing is those 50 million calls. > > Why do you care about the 50 million calls? That's crazy -- the important > thing is *calculating the Fibonacci numbers as efficiently as possible*. If you are writing practical programs, that's true. But the Julia benchmarks are not practical programs; they are designed to compare the performance of various language features across a range of languages. How is it a fair comparison to compare how Julia runs an algorithm that is not optimal in pretty much any language, to a completely different one with a much improved order of complexity, optimized specifically for Python? The article author even points out that the Fibonacci sequence problem can be solved using the same technique as he used for his Python solution, but makes no effort to benchmark it and then goes on to declare Python the winner anyway. That's just bad science. Many of the comments after the article repeatedly echo the same fundamental flaw that bartc raised: The benchmark isn't intended to determine the fastest way to calculate Fibonacci numbers; it's meant to measure the language's efficiency solving this class of problems in this way. > I don't give a flying fox about how fast the compiler can do those 48 > million calls And if you needed to write a program that HAD TO perform those 48 million calls, wouldn't you care then? Don't forget that in the real world, such reasons can include things like, "I don't know any other way to solve it and I need it done RFN," or, "My boss is a moron and insisted I do it this way..." [If you've never seen the latter, consider yourself lucky, but I sadly have.] > When comparing two compilers, you are ALWAYS comparing two different > programs. Such benchmarks still compare the efficiency with which the compiler turns the same algorithm you wrote in its provided syntax (ultimately) into executed instructions, and that's still a fair and useful comparison of the two languages, for solutions to problems of that particular class/structure/whatever. Knowing that a particular problem has a more efficient solution in the language you're using isn't always feasible; no one's knowledge of algorithms is exhaustive, and most of us have to care about deadlines way more than whether or not our implementations are exactly the most efficient ones possible. The average programmer typically has very little control or even awareness of what code the compiler generates. You can say that makes them shitty programmers but guess what? The world is full of shitty programmers. In that world, the real world, if you forbid these types of comparisons for being inherently unfair, simply because the compiler will obviously not generate *precisely* the same code, then you can not with any measure of sanity determine which language is the better tool to solve your problem of the day, given the tools you have at your disposal (including your own knowledge of algorithms). These types of benchmarks are useful for discovering what a given language is good at and what it is not. That information is useful to either allow you to choose the more efficient language for the solution you're going to implement, or perhaps even as a hint that the language you want to use may have a more efficient way to achieve the result you need. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Fri, Feb 23, 2018 at 03:11:36AM -0500, Terry Reedy wrote: > >>Why do you care about the 50 million calls? That's crazy -- the important > >>thing is *calculating the Fibonacci numbers as efficiently as possible*. > > >If you are writing practical programs, that's true. But the Julia > >benchmarks are not practical programs; they are designed to compare > >the performance of various language features across a range of > >languages. > > If that were so, then the comparison should use the fastest *Python* > implementation. Doing that would completely fail to accomplish the task of comparing the performance of recursive function calls in the two languages, which is what the benchmark was designed to do. So, no actually, it shouldn't. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Fri, Feb 23, 2018 at 01:38:01AM -0500, Terry Reedy wrote: > It is no secret that Python's interpreted function calls are slower > than function calls compiled to machine code and that Python's > infinite precision integer arithmetic is slower that machine int > arithmetic. So there is almost no point in combining both in a > naive drastically inefficient algorithm and declaring that Python is > slower. I never said the benchmarks chosen were awesome... :-) What I'm saying is this: 1. Insistence that the most efficient python implementation of Fib completely misses the point (and defeats the purpose) of the benchmarks, and as such the entire article is lost in the weeds. 2. Inasmuch as someone might want to measure the performance of recursive function calls in a particular language, the choice of recursively implementing fib is a fine one, and useful for that purpose. 3. If you want to say that choosing the most efficient implementation in Python is the only way to do a fair comparison, then you must also choose the most efficient implementation in Julia, which this is not, by all appearances. But again, this misses the point of the benchmark and defeats its purpose. Now if you want to complain that the purpose is silly, I won't even argue that... In 30 years of writing code I don't think I've ever imiplemented a recursive solution to any problem that wasn't purely academic. Maybe once or twice... maybe. But the purpose is what it is, and arguing that it must be done a different way is bogus. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sat, Feb 24, 2018 at 03:42:43AM +1100, Chris Angelico wrote: > >> If that were so, then the comparison should use the fastest *Python* > >> implementation. > > > > Doing that would completely fail to accomplish the task of comparing > > the performance of recursive function calls in the two languages, > > which is what the benchmark was designed to do. So, no actually, it > > shouldn't. > > > > Where does the author say that the benchmark is designed to compare > recursion? Chris, you're a smart guy... Are you suggesting that the reason the fibonacci sequence was selected as a benchmark is because it's such an amazingly useful problem that it, in and of itself, warrants having such a behchmark? Or, do you think the reason it makes sense to have such a benchmark is because, like the reason it's presented in pretty much every CS program ever, it presents an opportunity to consider a particular class of problems and different techniques for solving those problems, and the performance characteristics of those solutions? But, to answer your question more directly, here: https://julialang.org/benchmarks/ "It is important to note that the benchmark codes are not written for absolute maximal performance (the fastest code to compute recursion_fibonacci(20) is the constant literal 6765). Instead, the benchmarks are written to test the performance of identical algorithms and code patterns implemented in each language. For example, the Fibonacci benchmarks all use the same (inefficient) doubly-recursive algorithm..." Satisfied? > Recursion is sometimes a good way to describe an algorithm, but > rarely a good way to implement it at a low level. I'm well aware, and said the equivalent elsewhere. As I also said elsewhere, I never claimed it was a particularly useful benchmark. It is, nevertheless, designed to accomplish the stated goal, and does exactly that. You can decide for yourself how useful that goal is, but you can't really argue that it doesn't serve that purpose. So, by changing the algorithm, the article defeats the purpose of the benchmark. It makes some fine points about code optimization, but it completely fails at its stated purpose (to make the benchmarks more fair). The comparisons it makes are substantially less valid than the ones made by the Julia benchmarks, on account of optimizing only the algorithm used by Python, and not testing with a similarly optimized algorithm in Julia, but rather using its results for the intentionally unoptimized algorithm those benchmarks used. Even if testing optimized code is the point, as the article claims, it utterly fails to do that. Bad science. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Fri, Feb 23, 2018 at 06:14:22PM +, Steven D'Aprano wrote: > > I never said the benchmarks chosen were awesome... :-) What I'm saying > > is this: > > > > 1. Insistence that the most efficient python implementation of Fib > >completely misses the point (and defeats the purpose) of the > >benchmarks, and as such the entire article is lost in the weeds. > > The point of the benchmarks is to highlight how great Julia is For a particular set of common code patterns. You left that part out, and it's the crux of the issue. > and why people should choose it over Python. I'd argue not why, but WHEN. Or really I'd argue nothing of the sort... and simply point out that the benchmarks do exactly what the Julia team say they do. It's up to you to decide how useful that is. > The point of the article is to show how to take badly written, > unidiomatic, slow code written in Python, and modify it to be better, > faster code competitive (if not faster than) Julia, while remaining > within the Python ecosystem. Even if that was the point, the article fails, because it compares non-optimized Julia code to optimized Pyhton code. > We aren't limited to the two options the benchmarks suggest It actually suggested quite a lot more than that... benchmarks compared the performance of 12 languages, using exactly the same programming patterns (as near as I can tell anyway, I didn't scrutinize all of the code). -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sat, Feb 24, 2018 at 05:56:25AM +1100, Chris Angelico wrote: > No, not satisfied. Everything you've said would still be satisfied if > all versions of the benchmark used the same non-recursive algorithm. > There's nothing here that says it's testing recursion, just that (for > consistency) it's testing the same algorithm. There is no reason to > specifically test *recursion*, unless that actually aligns with what > you're doing. It seems abundantly clear to me that testing recursion is the point of writing a benchmark implementing recursion (and very little of anything else). Again, you can decide for yourself the suitability of the benchmark, but I don't think you can really claim it doesn't effectively test what it means to. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sat, Feb 24, 2018 at 06:16:38AM +1100, Chris Angelico wrote: > > It seems abundantly clear to me that testing recursion is the point of > > writing a benchmark implementing recursion (and very little of > > anything else). Again, you can decide for yourself the suitability of > > the benchmark, but I don't think you can really claim it doesn't > > effectively test what it means to. > > Where do you get that it's specifically a recursion benchmark though? > I can't find it anywhere in the explanatory text. I don't know how you could conclude it could be meant to test anything else. The code is: ## recursive fib ## fib(n) = n < 2 ? n : fib(n-1) + fib(n-2) What else is there of substance to test? Trigraphs? Addition? The comment even calls out that it is recursive. I further draw inference from the two statements: 1. "Instead, the benchmarks are written to test the performance of identical algorithms and code patterns implemented in each language." Calling out explicitly that it is algorithms that they are testing, and here the algorithm is a recursion. 2. "For example, the Fibonacci benchmarks all use the same (inefficient) doubly-recursive algorithm..." They expressly called out this algorithm as being inefficient, and expressly called it out as being double-recursion. I'll grant you they never explicitly said so unequivocally (that I saw--my reading of their site was not exhaustive), but I can't see any way an informed reader could conclude any different purpose other than benchmarking recursion. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Fri, Feb 23, 2018 at 01:41:17PM -0600, Python wrote: > On Sat, Feb 24, 2018 at 06:16:38AM +1100, Chris Angelico wrote: > > > It seems abundantly clear to me that testing recursion is the point of > > > writing a benchmark implementing recursion (and very little of > > > anything else). Again, you can decide for yourself the suitability of > > > the benchmark, but I don't think you can really claim it doesn't > > > effectively test what it means to. > > > > Where do you get that it's specifically a recursion benchmark though? > > I can't find it anywhere in the explanatory text. > > I don't know how you could conclude it could be meant to test anything > else. Actually I will make one small correction, which is to say that the benchmark tests the performance of algorithms which are predominated by many function calls, of which recursion is an obvious subset. But I think that's splitting hairs. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Mon, Feb 26, 2018 at 09:57:06AM +, Steven D'Aprano wrote: > Besides, if you want Python with no GIL so you can run threaded code, why > aren't you using IronPython or Jython? But this is just another oversimplified argument. In the real world there rather often exist constraints which have nothing to do with what is technically possible, but which make impractical or infeasible what may be technically possible. Python is often a preferred solution because it is often fantastic for rapid implementation and maintainability. The GIL's interference with threaded code performance has, for me at least, on several occasions been... disappointing (perf costs of removing it aside) because it gets in the way of choosing Python for such solutions. Jython and IronPython are simply not feasible options for me, for multiple reasons that have zero to do with their technical suitability. But back to the point of the thread, I think it's ironic that you're basically making the benchmarks' argument: Choose the tool which suits the solution you need. You argue we should use IronPython or Jython when threads are needed, and the Julia benchmarks *imply* (but never actually argue, AFAICT) that if you need a solution which relies on heavy use of function calls, since Python will be slower than Julia, you should therefore choose Julia instead. But that's only a sensible conclusion if all other things be equal, which of course they are not, neither for Julia vs. Python, nor for Python vs. Jython or IronPython (though likely the latter case is slightly closer to being true). -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote: > > Python is often a preferred solution because it is often fantastic for > > rapid implementation and maintainability. The GIL's interference > > with threaded code performance has, for me at least, on several > > occasions been... disappointing (perf costs of removing it aside) > > because it gets in the way of choosing Python for such solutions. > > Jython and IronPython are simply not feasible options for me, for > > multiple reasons that have zero to do with their technical > > suitability. > > Have you actually tried it and run into problems, Yes. It was years ago and I forget the details, but I even posted some sample code here and was told (quite possibly by you) that it was the GIL that was eating my lunch. Someone suggested writing the bits I wanted to thread as a C extension, which largely defeated the purpose of using Python. In at least one case I just used C++, and in another I just ignored the problem until it went away. -- https://mail.python.org/mailman/listinfo/python-list
Re: bool and int
On Wed, Jan 25, 2023 at 01:01:24PM +1100, Chris Angelico wrote: > On Wed, 25 Jan 2023 at 12:43, wrote: > > Python has a different philosophy than some other languages with strong > > typing. In some of those, you would not be allowed to add or multiply at > > random but would need to convert parts of your calculation to all be the > > same, such as a 32-bit integer. You could still do things like I mention > > above but only after consciously mapping your Boolean to an actual zero or > > one of the kind wanted. > > Python is strongly dynamically typed. You may be thinking of "static > typing" rather than "strong typing" here, You often insist on this but frankly it does not jibe with the definitions of "strongly typed language" that I was taught or that I still see used commonly, including in literature and on sites that aim to teach people about computer science, which basically amount to: 1. A language whose variables are defined by type, and can only hold that type, typically but not necessarily compiled. 2. A language which strongly enforces restrictions on mixing or operating on, and/or implicitly converting different data types, with the implication that the structure of types is well-defined and rigid. Python conforms to neither--its VARIABLES are normally untyped (though the object data they hold obviously is). Object instances can have new fields added to them on the fly, willy-nilly, and Python allows for any object which has an interface--or rather only the portion of interface you care about in the moment--like the one it expects, to be used in a given context, i.e. duck typing. Useful properties (when used carefully!) but not intuitively consistent with the idea of "strong typing" and potentially dangerous if care is not taken. When YOU say that Python is strongly typed, you're using some other definition--one that is perhaps technically correct, but seemingly quite a lot of people in the field--including active students, college professors, and seasoned professionsals--are unaware of... The above usages are common and widespread, widely accepted--which is inherently what makes word usages correct--and you very obviously know full well what people mean when they use them; so "correcting" people who use them seems rather unhelpful (certainly without detailing what you think it means), inappropriate, and arguably just simply wrong. It seems to serve no purpose other than to make communication harder, and possibly to irritate people. I would encourage you to consider ceasing the practice, so as to not needlessly detract from the otherwise usually good info you routinely provide... And FWIW if you want some references, a google search will return voluminous examples of people using the term as I described--from acadamia to business--but here are just a few: https://www.cs.cornell.edu/courses/cs1130/2012sp/1130selfpaced/module1/module1part4/strongtyping.html https://courses.yarrahills.vic.edu.au/moodle/mod/book/view.php?id=18778&chapterid=28 https://www.oreilly.com/library/view/mastering-c-and/9781785884375/ch02s02.html https://www.postgresql.org/docs/current/typeconv-overview.html https://www.sciencedirect.com/topics/computer-science/strongly-typed-language https://www.techtarget.com/whatis/definition/strongly-typed -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Mon, Jan 30, 2023 at 09:41:03AM -, mutt...@dastardlyhq.com wrote:
> >Because print() returns nothing (i.e., the statement x is None is True).
>
> I don't understand this. What was the point of the upheaval of converting
> the print command in python 2 into a function in python 3 if as a function
> print() doesn't return anything useful? Surely even the length of the
> formatted string as per C's sprintf() function would be helpful?
Python is far from the only language that allows functions to return
nothing explicit. Statically typed languages typically use the void
keyword or something similar to indicate this, and dynamically typed
languages often just don't explicitly return anything. [Some
languages, like Perl, just implicitly return the value of the last
expression, or something of the sort, but some do not.] In Pascal, in
fact, there are two different types of subroutines to distinguish
between those things: functions return a value, and procedures do not.
Modern languages commonly don't provide this distinction because by
and large it is unnecessary.
Typically the reason NOT to return a value is that the function is
designed to DO something, rather than to calculate some value.
Examples might be updating the appearance of a UI widget, printing
some information to the screen, or twiddling some bits in a register
(i.e. in-place update of a value). They don't need to return anything
because the "output" is whatever was done. In some languages it might
be typical to return a status indicating success or failure, but in
many languages this is unnecessary; status may be returned via a
parameter provided for the purpose, or in many languages, success can
be assumed, whereas failure will raise an exception.
If it's the case that you simply want to know the length of the string
that will be printed, you can, rather than expecting the I/O function
to tell that to you, figure it out for yourself ahead of time, e.g.
instead of:
username = "John Smith"
job = "Python programmer"
# this doesn't work as desired
len = print(f"{username} has occupation {job}.")
print(len)
...
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Sat, Feb 11, 2023 at 08:30:22AM +1100, Chris Angelico wrote:
> On Sat, 11 Feb 2023 at 07:36, Python wrote:
> > You would do this instead:
> >
> > message = f"{username} has the occupation {job}."
> > message_length = len(message)
> > print(message)
> > print(message_length)
> > ...
> >
>
> It's worth noting WHY output functions often return a byte count. It's
> primarily for use with nonblocking I/O, with something like this:
>
> buffer = b".."
> buffer = buffer[os.write(fd, buffer):]
>
> It's extremely important to be able to do this sort of thing, but not
> with the print function, which has a quite different job.
I would agree with this only partially. Your case applies to
os.write(), which is essentially just a wrapper around the write()
system call, which has that sort of property... though it applies also
to I/O in blocking mode, particularly on network sockets, where the
number of bytes you asked to write (or read) may not all have been
transferred, necessitating trying in a loop.
However, Python's print() function is more analogous to C's printf(),
which returns the number of characters converted for an entirely
different reason... It's precisely so that you'll know what the length
of the string that was converted is. This is most useful with the
*snprintf() variants where you're actually concerned about overrunning
the buffer you've provided for the output string, so you can realloc()
the buffer if it was indeed too small, but it is also useful in the
context of, say, a routine to format text according to the size of
your terminal. In that context it really has nothing to do with
blocking I/O or socket behavior.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Fri, Feb 10, 2023 at 05:48:53PM -0500, Thomas Passin wrote: > On 2/10/2023 4:55 PM, Python wrote: > > However, Python's print() function is more analogous to C's printf(), > > which returns the number of characters converted for an entirely > > different reason... It's precisely so that you'll know what the length > > of the string that was converted is. This is most useful with the > > *snprintf() variants where you're actually concerned about overrunning > > the buffer you've provided for the output string, so you can realloc() > > the buffer if it was indeed too small, but it is also useful in the > > context of, say, a routine to format text according to the size of > > your terminal. In that context it really has nothing to do with > > blocking I/O or socket behavior. > > But none of that applies to the Python print() function. There are no > buffers to overrun, no reason to know the length of the printed string, no > re-allocating of a buffer. Indeed. But the OP originally compared print to printf, and I was specifically addressing Chris' point about why I/O functions return the number of bytes written, which was relevant to, but maybe a bit of tangent to the original post. > I don't know why the print() function doesn't return anything You do though! :) You actually just explained why yourself... it's because it just doesn't need to. But FWIW, I wasn't addressing this point, because it had already been adequately covered in the thread. There's good reason why Python's print and C's printf work differently. In languages like C it makes sense that printf returns the length of the string. printf is the means of all three of: - formatting the string - counting its length - actually outputting the string to stdout (albeit indirectly). This sort of breaks the rule of, "do one thing, and do it well," but it does so in the name of efficiency. You might or might not want to actually know the length of the formatted string, depending on what you're doing with it. But the printf function basically needs to calculate it anyway so that it can tell the underlying system calls how many bytes to write (or tell stdio how many bytes it is adding to its buffers, or whatever), and then stuffing that length in a register to be returned to the caller is roughly free (it's probably using the register that it's going to return already to do the counting), and the caller can ignore it if it wants to. C aims to be as efficient as possible so this is a good strategy. Unlike C[*], since Python can already separate the formatting and length calculation from sending the data to stdout (I demonstrated how in my first post in the thread), it has no need for print to return the length. As I mentioned in my earlier post, if Python encounters an error condition it will raise an exception--which C can't do--so there's no reason to return a status either. What else would it return? Nothing else would really make sense. -=-=-=- * In C you could sprintf the string into a buffer, which would return its length, and then call printf on the buffer, but that would be much less efficient and a bit silly... UNLESS you actually needed to know the length of the string beforehand, e.g. to calculate where to put line breaks in a text justification routine, or something. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Wed, Jan 13, 2021 at 10:07:23AM +1100, Chris Angelico wrote: > On Wed, Jan 13, 2021 at 10:02 AM Igor Korot wrote: > > But for my dialogs (especially for dialogs where I need to ask for > > credentials) - I don't think I want > > WM to do my job. > > > > Again - we are talking positioning here and not size/client size. > > > > And I don't think I want you to do the WM's job. > > You're welcome to keep going to great effort to do the wrong thing, > but be aware that nobody will appreciate the work you're doing, and in > fact are more likely to curse you for it. Just save yourself a LOT of > hassle and let the WM do its job. It knows the user's wishes better > than you do. I think this is quite very, very far from true. It's been a while since I've used such tools, but I believe it is or was quite common for large, integrated applications like DAWs, graphical design software, etc. to remember where you placed your various floating toolbars and add-ons (and even much more detailed state about how you'd set the various widgets in them), and that users of such applications expect that. Obviously the software needs to be aware of, and compensate for, cases when the available display can't draw the various widgets in visible space on the desktop/canvas/whatever, but if the application wants to do all that, it seems like a perfectly wonderful feature to me. The last thing I want to do is spend 15 minutes to relocate and reconfgure UI elements to where and how I like them before I can even start working on a media project (or whatever). -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > And those X11 users will swear at you if you override their window > managers configured window placement. Application code should not care > about or try to control window geometry. Period. I think this is just plain wrong. If you, the user, want to override what you, the user, configured your window manager to do, for WHATEVER reason your little heart may desire, then the application needs to give you an interface to request it, and rather importantly the WM must necessarily honor it. The policy reallly ought to be: - If the user took the time to specify a geometry, do what it says (i.e. honor the placement the application asks for) - If not but the window manager has something configured for that application/widget/whatever, do what it says - Otherwise, resort to the window manager's default policy Arguably there ought to also be a way for the application to *suggest* a default geometry that the WM can override, but obviously providing a way to force the geometry gives rise to the opportunity for abuse by badly behaved developers. Don't use those apps. Fortunately, at least historically, in practice most X11 window managers more or less did all that anyway. I recall that when I switched to Gnome I had some trouble with this (as in, it just didn't work, generally, even if the relevant app allowed you to specify --geometry or similar), but AFAICT Gnome has long held to the notion that Gnome Gnows better than you do how you should run your apps, so when using Gnome all bets are off. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 11:58:34AM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 11:53 AM Python wrote: > Have you actually done any research by (a) asking people what they > actually prefer, and better still (b) silently watching over someone's > shoulder and seeing which one makes people more productive? As I said, though it's been a long while, I was actually a user of such applications myself. So I can tell you quite authoritatively that in those kinds of apps, *I* absolutely prefer that the app remember where my windows are and what's in them, no contest. And I would always use them alongside a slew of other apps--web browsers, text editors, mail clients, etc... most likely on a separate desktop, if I wasn't mobile, but necessarily on the same one if I was. > The results will differ based on whether the user in question has > basically just one primary application (an IDE, or some gigantic app > like Adobe PhotoShop) that they spend all their time in OK, so you admit that such apps do exist. But I guess you knew that the OP is not writing that sort of application, and know who its intended audience is, and their work habits and preferences... -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 12:27:19PM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 12:11 PM Python wrote: > > > > On Tue, Jan 12, 2021 at 06:43:39PM -, Grant Edwards wrote: > > > And those X11 users will swear at you if you override their window > > > managers configured window placement. Application code should not care > > > about or try to control window geometry. Period. > > > > I think this is just plain wrong. As a side note, from a purely technical standpoint, Grant's point is demonstrably factually false. A GUI application necessarily must "care about or try to control window geometry" so that if the user moves or resizes the application, enables or disables additional widgets, etc., the widgets it contains are redrawn such that they remain usable, possibly expanding the canvas they're drawn on or adding new GUI elements like scrollbars to ensure that (at least it does if it wants to be useful). GUI frameworks may provide a core that automatically handles this for you, but that is not always the case (as an extreme example, if you're writing the whole app from scratch in assembly language), and in any event the framework is part of the application... not the window manager. Just because you didn't write that code doesn't mean your app doesn't need those facilities. > I love how "I think" is allowed to trump decades of usability research. I love how your complete dismissal of everything I said is allowed to replace logical counterargument, particuarly when you ignored the fact that absolutely nothing I said actually contradicts any such years of usability research IN ANY WAY--I merely pointed out that if the application were to have ADDITIONAL flexibility for expert users in regard to placing and sizing windows, the application must necessarily care about and be able to control its window geometry. All the other behaviors remain consistent with usability standards--assuming the vendor implemented them properly, which is a big assumption. In fact, providing such extra semantics may allow the user to overcome bad UI when the vendor failed. > it is far FAR better to put control in the user's hands I love how you dismissed that the semantics I described gives MORE control to the user, not less, without actually sacrificing anything. I love how you dismissed that not all computer users and not all humans are the same, that there are variances and outliers within all usability studies, and indeed all studies of human behavior, and that flexibility and configurability have value for that reason. I love how you dismissed the perpectives and motivations of posters in this thread without understanding or even hearing them. For all you know Rich may just be doing it as an academic exercise, in which case whether or not it conforms to usability best practices is utterly irrelevant, even if it weren't already the case that giving more control to the user--something you just claimed to value--requires giving control to the app. -- https://mail.python.org/mailman/listinfo/python-list
Re: Application window geometry specifier
On Thu, Jan 14, 2021 at 03:02:05PM +1100, Chris Angelico wrote: > On Thu, Jan 14, 2021 at 2:43 PM Python wrote: > > > it is far FAR better to put control in the user's hands > > > > I love how you dismissed that the semantics I described gives MORE > > control to the user, not less, without actually sacrificing anything. > > Actually, you give control to the application, and then the > application has to choose to give it to the user. Right, because unless the user can somehow execute instructions directly on the CPU via some sort of direct cerebral link, all control the user has over the behavior of the applications comes... from the applications. > But apparently, this thread has devolved to this kind of total > dismissal For which you are entirely the cause. I simply responded in kind. Apparently you don't like it any more than the rest of us do. -- https://mail.python.org/mailman/listinfo/python-list
python documentation
Howdy Folks, I would like to suggest adding "Blythooon" to the list under "Other parties have re-packaged CPython" listed here: https://www.python.org/download/alternatives/ Blythooon can be found here: https://pypi.org/project/blythooon/ and the belonging installation step-by-step-guide video here: https://www.youtube.com/channel/UCOE8xqYS_2azFsFjBVEwVMg May I ask - how can I do that best? Thanks in advance and Best Regards Dominik -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
Hi Chris, thank you for your interest and thanks for asking. Blythooon is notable due to several reasons; let's compare it with some of the already listed (and thus obviously notable) 'distributions': 1) pythonxy seems not to be maintained anymore - the last version I found is from 2015. Blythooon is still maintained and the last version is from February 2021. 2) winpython seems not to support Python 2.7.* anymore. Blythooon supports Python 2.7.18. 3) When using Anaconda Python you might not only have to respect the anaconda/miniconda licenses but also the terms of service of the belonging website. For commercial uses that might pose some problems. If you have a peek into the text: https://www.python.org/download/alternatives/ You may find statements alike "we are not granting you permission to use the Repository for commercial activities" or "Your use of the Repository is at the sole discretion of Anaconda, which may deny you further use of the Repository or terminate this license at any time, for any reason, with or without cause." there... Companies tend to have problems with this :) Blythooon is a netinstaller which downloads from python.org and pypi.org. No comparable limitations are known to me for these sources. 4) Blythooon is not a distribution in the original sense; it is a netinstaller, which is able to download, (md5-)check and install a 'snapshot' of packages/versions: - Python 2.7.18 - Virtualenv 20.2.2 - PySide 1.2.2 - NumPy 1.16.6 - PyQtGraph 0.10.0 - Matplotlib 2.2.5 - SciPy 1.1.0 - PySerial 3.5 - Pyadaaah 0.90 and some further packages supporting said ones. This compilation has been carefully assembled to allow the development of advanced, production quality, scientific, Python 2.7 applications with Qt 4.8 based GUIs and the ability to display nice (live) plots (via PyQtGraph and/or Matplotlib). Blythooon obviously comes with some mathematical stuff alike NumPy or SciPy too. Said versions work together well. The developer does not need to find out, which versions work together well. Because that is not easy. Try e.g. PyQtGraph 0.11.* with PySide 1.2.* - you might be disappointed then, as well as if you would be trying PyQtGraph 0.10.* with PySide 1.2.4. All Blythooon installations, if not manually modified, are 100% compatible, as I said, it is more a 'snapshot' then a permanently self-updating distribution... Blythooon does not focus on up-to-dateness but on proven stability and compatibility. But, as Blythooon sets up a Python Runtime Environment just based on PIP, the developer naturally can tailor his installation further (e.g. by installing further packages or upgrading the existing). Blythooon is a (nearly fully) automatic netinstaller for Windows 10 only (at least yet, depending on the feedback, porting to Linux / macOS could be done easily - the netinstaller is based on the platform independent powershell). I hope, some aspects are notable enough... Best Regards Dominik On 2021-03-26 17:33, Chris Angelico wrote: On Sat, Mar 27, 2021 at 3:31 AM wrote: Howdy Folks, I would like to suggest adding "Blythooon" to the list under "Other parties have re-packaged CPython" listed here: What makes it notable? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation - addendum
Sorry, copy & paste obviously failed, here is the link I wanted to include: https://www.anaconda.com/terms-of-service On 2021-03-26 17:33, Chris Angelico wrote: On Sat, Mar 27, 2021 at 3:31 AM wrote: Howdy Folks, I would like to suggest adding "Blythooon" to the list under "Other parties have re-packaged CPython" listed here: What makes it notable? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
No, I am not encouraging, I am just offering the possibility. Python and its community once was not dogmatic. At least this was my impression when I started - after all Python originally had been designed to be multi paradigmatic. This spirit of freedom was one mayor reason for Python to grow so fast - from my POV. But freedom is constituted by freedom of choice. It might be a good thing to recommend people to switch to Python 3.*, it might be a bad idea to FORCE people to do so by taking away the possibility to install Python 2.7.*; some people tend to react badly when infantilised. If I am right, the Python 2.7.* installers still are provided on the python.org website. So long as this is done, I cannot see a reason not to list a 'distribution' using Python 2.7.* in said list, right? By the way, there is more, Blythooon offers beyond what I already have written in the last email. Otherwise please name me another comparable MINIMAL 'distribution', which is compiled specifically for scientific FRONTend development? In terms of diversity I also cannot see, why Blythooon MUST have something special to be listed? Is it not enough, that it is another one? But, in the end, this naturally is not my decision. Cheers, Dominik On 2021-03-26 22:57, Chris Angelico wrote: On Sat, Mar 27, 2021 at 7:49 AM wrote: Hi Chris, thank you for your interest and thanks for asking. Blythooon is notable due to several reasons; let's compare it with some of the already listed (and thus obviously notable) 'distributions': 2) winpython seems not to support Python 2.7.* anymore. Blythooon supports Python 2.7.18. Ah. That is indeed notable, but not in a good way. You are encouraging the use of an end-of-life version of Python, and your installer has very little to boast beyond that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. But to be honest, I see no reason to discuss that further, you seem to be quite determined - so be it. Ignore Blythooon. I have no disadvantage by that, as I would not have an advantage the other way round, so I am fine with it. Best Regards Dominik On 2021-03-27 04:44, Chris Angelico wrote: On Sat, Mar 27, 2021 at 2:15 PM wrote: No, I am not encouraging, I am just offering the possibility. Python and its community once was not dogmatic. At least this was my impression when I started - after all Python originally had been designed to be multi paradigmatic. This spirit of freedom was one mayor reason for Python to grow so fast - from my POV. But freedom is constituted by freedom of choice. It might be a good thing to recommend people to switch to Python 3.*, it might be a bad idea to FORCE people to do so by taking away the possibility to install Python 2.7.*; some people tend to react badly when infantilised. Why do you install 2.7.18? Isn't it a bad idea to FORCE people onto that particular version, instead of letting them run 2.7.9 or 2.7.1 if they choose? Does it infringe on their freedoms by offering only one version? If people want a specific version, they can get it. There's no reason to promote the use of outdated versions. If I am right, the Python 2.7.* installers still are provided on the python.org website. So long as this is done, I cannot see a reason not to list a 'distribution' using Python 2.7.* in said list, right? You have a pre-1.0 distribution of an end-of-life version of Python that works on a very specific platform. That's fine. But there's no reason to have it promoted anywhere. By the way, there is more, Blythooon offers beyond what I already have written in the last email. Otherwise please name me another comparable MINIMAL 'distribution', which is compiled specifically for scientific FRONTend development? In terms of diversity I also cannot see, why Blythooon MUST have something special to be listed? Is it not enough, that it is another one? Nope, not enough for it to be promoted. The page you linked to originally is a very short list of only those which are notable enough to be worth promoting. And from what I'm seeing, yours isn't. Move to Python 3 and leave the old version behind. It has been a year since Python 2 received any updates at all, and over a decade since 2.7 was originally released. Isn't it time it was finally permitted to rest in peace? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
Hi Dan, thank you very much for your kind hints - quite interesting idea to have a more detailed look into this direction! By the way, your response was the very first here, which I consider to have a constructive notion; at least I did not felt very welcome here by Chris until yet... In the last project I developed the frontend on said C# - WinForms basis (C# and .NET is quite awesome! Most of it meanwhile has even become crossplatform! By the way, as Spyder also has this "just 3" notion, I already switched to VSCodium and never regretted that - VSCodium is the best free IDE for Python as well as C# yet, if you ask me:) and just parts of the backend with IronPython (which also is nice, although it just has access to a limited set of libraries). It worked fine, but I do not like mixing languages if not necessary as I deem that to be a software design weakness and it naturally comes with some overhead. Imagine, if another person one day should continue this work, he must be fluent in Python AND C#, not so easy to find someone free who is on the market I guess... Blythooon solves the current issues well, so at the moment, there is no pressing reason for me to become frantic. But considering the long term, those thoughts are naturally real. The obvious trend to force people to switch to Python 3 might lead to people even eliminating the access to the old packages Blythooon is using. This sword of Damocles is a heavy burden. If anybody thinks that is a little too much seeing on the black side, then they should attentively follow what at the very moment is happening with the current Qt version... May I ask, do you have any knowledge or even experience about if resp. how good Tauthon and Pypy2 works together with Qt 4.8? From my experience the limitating factor during frontend development is nearly always the GUI part. Kivy seems to be nice, but scientific plotters alike PyQtGraph are Qt based and cannot easily be integrated in Kivy yet. Have a nice day, Best Regards Dominik On 2021-03-27 07:01, Dan Stromberg wrote: On Fri, Mar 26, 2021 at 10:37 PM Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: > By the way, some months ago I started trying to migrate to Python 3 and > gave up in favor of creating said compilation. Compatibility of Python > and its Packages decreased with V3 significantly. A whole lot of minor > and major incompatibilities between your subversions and belonging > packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. Chris, not everything you dislike is anti-Python FUD. Dominik, if you want something like Python 2.7, you likely should try Tauthon or Pypy2. Don't expect pip to work well on Tauthon; last I heard that was not happening. Also Pypy2 has some issues with C extension modules, and I'm not confident it'll pip well either. It's very worthwhile to move to 3.x, but CPython has a rather sad compatibility story when it comes to C extension modules; hopefully CFFI is going to fix that in the long term. If you're avoiding porting pure Python code, then that feels to me a bit like foot dragging, as the pure Python changes are not that big and are pretty much limited to the 2.7 -> 3.0 transition. I like to build versions of Python from 0.9 to 3.10alpha, for the sake of quickly ascertaining what features were introduced in what versions of CPython. IOW, there are good reasons to keep around old Pythons. Python history is interesting. -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
You write, that "Everyone claims that it's easier to move to some other language rather than to migrate to Python 3". Thank you for sharing this remarkable information! On 2021-03-27 06:36, Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python documentation
You say: "The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable." And I say, forcing people to do things they do not want to do is a little more questionable. There are reasons, why people "don't want to move to Python 3". Maybe you should concentrate more on developing Python 3 a little more attractive then in burning witches? But for my part, this discussion is ended, it does not lead to anything. At least in this point I agree with Chris. Cheers, have a good time Dominik On 2021-03-27 18:53, MRAB wrote: On 2021-03-27 17:03, pyt...@blackward.eu wrote: You write, that "Everyone claims that it's easier to move to some other language rather than to migrate to Python 3". Thank you for sharing this remarkable information! You've quoted him partially and incorrectly. He said "Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now." The point is that there are those who use Python 2 and don't want to move to Python 3, claiming that it's easier to switch from Python 2 to some other language than from Python 2 to Python 3. That's what seems questionable. On 2021-03-27 06:36, Chris Angelico wrote: On Sat, Mar 27, 2021 at 4:20 PM wrote: Chris, you seem to imply, that I have compiled said versions without reason and that the same would be possible on basis of Python 3 - which is simply not true. Maybe you are not enough acquainted with Qt and belonging libraries alike PyQtGraph. Maybe you are just not willing to see / accept these arguments. By the way, some months ago I started trying to migrate to Python 3 and gave up in favor of creating said compilation. Compatibility of Python and its Packages decreased with V3 significantly. A whole lot of minor and major incompatibilities between your subversions and belonging packages. This was one reason, why Java took the route to its own death. FUD. Lots and lots of FUD. More reasons to not promote your distribution. Use it if you will, but it doesn't merit any further visibility. With a view to the mid and long term future, this discussion even gives me cause to ponder about whether it doesn't make more sense to rely more on C# and WinForms for professional projects from now on. I am fluent in both too and it always makes sense to bet on the right horse at an early stage. If you prefer, go for it. Everyone claims that it's easier to move to rather than to migrate to Python 3, and I'm calling people's bluffs now. Go ahead and move to another language if it's easier - it's no skin off my nose. Or maybe it isn't easier, and that's just an empty argument. Funny how it keeps coming up. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there any way to make sense of these E-Mail subjects?
Chris Green wrote: Subject: [SPAM] =?UTF-8?B?8J+TtyBKb2huIEJheHRlci1C?= =?UTF-8?B?cm93biByZWNlbnRseSBw?= =?UTF-8?B?b3N0ZWQgYSBuZXcgcGhv?= =?UTF-8?B?dG8=?= It looks like some sort of mis-encoding of UTF-8 strings, can anyone suggest what might be going on and/or a way to get some sense out of this? It's not mis-encoding, it the standard way to embed non-ascii characters in the header. ?UTF-8?B? means base64 encoded utf-8, then the content is on multiple lines: $ base64 -d < t 📷 John Baxter-Brown recently posted a new photo email.header.decode_header should be able to handle it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unpacking lists in a f string
Paulo da Silva wrote:
Hi!
Let's say I have two lists of equal length but with a variable number of
elements. For ex.:
l1=['a','b','c']
l2=['j','k','l']
I want to build a string like this
"foo a j, b k, c l bar"
Is it possible to achieve this with f strings or any other
simple/efficient way?
'foo ' + ', '.join(f"{one} {two}" for one,two in zip(l1,l2)) + ' bar'
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does not Python accept functions with no names?
Abdur-Rahmaan Janhangeer wrote: Greetings list. Out of curiosity, why doesn't Python accept def (): return '---' () Where the function name is ''? For the same reason an empty sequence of characters cannot be a variable name. Do you know any language (or formal theory) that allows that? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does not Python accept functions with no names?
Barry wrote: On 20 Feb 2022, at 15:35, Abdur-Rahmaan Janhangeer wrote: Greetings list. Out of curiosity, why doesn't Python accept def (): return '---' () Where the function name is ''? Because there is no variable that is holding a ref to the code. So it’s pointless. Fun fact, it can be done, but it's (afaik) then (almost) unusable... >>> a Traceback (most recent call last): File "", line 1, in NameError: name 'a' is not defined >>> locals()['a'] = 42 >>> a 42 >>> locals()[''] = 42 >>> locals()[''] 42 >>> locals()[''] = (lambda x: x*42) >>> locals()[''](1) 42 -- https://mail.python.org/mailman/listinfo/python-list
Re: basic question on loop & type casting / list/str/array
Kiran Kumar wrote: Hi. Pls check on below poython 3.9.x code & suggest how can i keep the string intactst in 2nd loop... ? these are aws ec2 ids Don't loop through it then. -- https://mail.python.org/mailman/listinfo/python-list
Re: flask app convert sql query to python plotly
Abdellah ALAOUI ISMAILI wrote:
def query_tickets_status() :
query_result = pd.read_sql ("""
SELECT COUNT(*)count_status, status
FROM tickets
GROUP BY status""", con = mydc_db)
return query_result
labels_statut = query_tickets_status['status']
labels_statut = query_tickets_status()['status']
--
https://mail.python.org/mailman/listinfo/python-list
