RE: does the order in which the modules are placed in a file matters ?
For the general modules it doesn't matter, however using if you are using any non-standard packages, and If there are duplicate names in any of the modules and if you import them with a "*" (as some packages suggest), it can cause you to end up referring to an object you were not intending to. For example, if you have found a package called "foo", and the instructions on it are to import it as: from foo import * Then you have another package called "bar" with the same instructions... so now you have: from foo import * from bar import * In both of these there is a class called "snafu", when you do this: from foo import * from bar import * SITUATION = snafu() You are going to get bar.snafu(), not foo.snafu() This can of course be gotten around by doing: import foo import bar SITUATION = foo.snafu() (or a number of other approaches using "as" etc...) Note, using * is dis-recommended, though pretty often done, for more information on using *, see: https://docs.python.org/2/tutorial/modules.html#importing-from-a-package Dan Strohl -Original Message- From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On Behalf Of Chris Angelico Sent: Wednesday, December 16, 2015 8:14 AM Cc: python-list@python.org Subject: Re: does the order in which the modules are placed in a file matters ? On Thu, Dec 17, 2015 at 3:09 AM, Ganesh Pal wrote: > Iam on python 2.7 and linux .I need to know if we need to place the > modules in a particular or it doesn't matter at all > > order while writing the program > > For Example > > import os > import shlex > import subprocess > import time > import sys > import logging > import plaftform.cluster > from util import run The order of the import statements is the order the modules will get loaded up. As a general rule this won't matter; when it comes to standard library modules, you can generally assume that you can put them in any order without it making any difference. It's common to order them in some aesthetically-pleasing way (maybe alphabetical order, or maybe sort them by the length of the name - whatever you like). There is a broad convention that standard library modules get imported first, and modules that are part of the current project get imported afterwards. But even that doesn't usually matter very much. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Question on keyword arguments
I have approached this in a few different ways, depending on the use case.
I have done the "return_type=list" before, though I don't really like it...
it's too easy to forget or mistype the exact name used for the switch. If you
do this, I also recommend setting some class or module variables to the text
strings and pass those back and forth.
I have also returned a different type depending on what is being requested...
so, if the function user requests data that has multiple objects, return a
list, if they request something that has just one object, return that object.
This also has potential problems if the number of returned objects is not
consistently predictable, you would have to always test your returned object to
see how to handle it.
I like the other suggestions thrown out as well, (having multiple methods and
having one method and a converting function).. They are good, easy to read and
use methods as long as you know at design time what type of object you want
(which is probably the norm).
Another approach that I like (where it makes sense) is to return another
(custom) object that can act like either... that way, you have the content in
hand and can use it either way. This approach works well when there is a high
overhead in creating the data, that you don't want to have to do again, and you
don't mind having a few more objects hanging around until cleaned up.
So, define a return object like:
from collections import UserList
class TestResponse(UserList):
def __str__(self):
return '\0xfe%s' % '\0xfe'.join(self.data)
...and return that object.
that way, you can iterate over it, treat it as a list, or whatever, or if you
do print(str(TestResponse)), you get your r'0xfeONE\0exfeTWO\0xfeTHREE'
In the end, your decision should be made based on:
1. What would the developer using this EXPECT to get back? (if the user
normally expects one or the other, do that, if this is for a "public module", I
would expect the list is more likely the common response. This list is
probably not the right place for that question though, unless this is a very
general utility, you want to ask the people coding in the domain that would
mostly be using your function.)
2. What is the most likely response type? (if it is common to get it back
different ways, or use it multiple times, this is probably mostly the same as
#1, but can be different)
3. What will be the easiest to read and document? Returning a list is easy to
read and expectable, but not if you have to then jump through some loops to
convert it to something else immediately.
4. Is there a large enough benefit in processing that you want to be able to
use it multiple ways without having to regenerate the list. (note that this is
the last criteria, unless performance is really critical, readability and
predictability is normally much more important than what is probably minor
performance tuning.)
Dan Strohl
> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
> Behalf Of Peter Otten
> Sent: Thursday, February 18, 2016 6:37 AM
> To: python-list@python.org
> Subject: Re: Question on keyword arguments
>
> grsm...@atlanticbb.net wrote:
>
> > Would this be the correct way to return a list as a default result.
>
> If it does what you want it to do it is "correct" as in "complies with
> specification".
>
> > Also, would the list be the preferable result (to a python programmer) ?
>
> A list as a return value is OK as is any other object, however,
>
> > def test(command, return_type='LIST'):
>
> passing the desired result type as an argument is usually not a good idea.
>
> > """ Go to database and return data"""
> > if return_type == 'LIST':
> > result = ['ONE', 'TWO', 'THREE']
> > else:
> > result = r'0xfeONE\0exfeTWO\0xfeTHREE'
> > return result
> >
> > if __name__ == '__main__':
> > print(test('cmd'))
> > print(test('cmd', 'LIST'))
> > print(test('cmd', None))
> > print(test('cmd', 'string'))
>
> Make it separate functions instead:
>
> def test(command):
> return ["ONE", "TWO", "THREE"]
>
> def test_as_string(command, sep=","):
> return sep.join(test(command))
>
> if __name__ == '__main__':
> print(test("cmd"))
> print(test_as_string("cmd"))
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Considering migrating to Python from Visual Basic 6 for engineering applications
Disadvantages of python... (compared to VB) That's a hard one, but here are my thoughts: (keep in mind that these kinds of discussions are subjective and much is based on the background and experience of the coder, these are also assuming that 100% of your audience is on windows, as soon as you start talking about cross platform support, VB gets much harder to use (yes, you could use it on Linus, via a web based app, or an emulator if you HAD to). - I find that VB is much easier at making quick GUI apps (for windows). - VB is easier to integrate with office apps and other windows specific things (there are some python modules that will access office files etc, but if you want to have an engineering app that directly integrates / interacts with excel, VB is probably better. - I find VB is easier to package and distribute. (there are some good utilities that will take Python and package it into an exe, along with all of the needed pieces, interpreter, etc, but those all require some level of work to setup and make work... not a lot sometimes, but certainly more than "click compile" and copy the .exe file. - VB is often, for simple apps, often simpler to learn for non-programmers. (I know I will get slammed for that one). For complex apps, I find VB harder to do things than Python, but for example, if I wanted to make a quick windows calculator, I would probably go to VB first.) My approach is generally: I use Python for: - server apps, web based apps, plugins, modules, library development, or apps that I want to be able to expand later with plugins, console apps and utilities (things that I am only going to run from the CLI anyway), performance focused apps (unless I need to go all the way to C for performance), anything that might ever need to be cross platform, apps that interact with other (non-Microsoft) apps. I use VB for: Quick user focused, non-web apps, apps that are used in or directly with Microsoft Office apps, apps that I am developing for someone else that is a VB programmer (or non-programmer but might poke at them).. apps that I need to distribute to lots of less controlled workstations that don't have python on them already. These days, I find that I am using VB much less than Python, most of the reasons that I would pick VB can be overcome by developing a cloud app instead of a local app, but there are still times that VB is the right tool (for me at least). > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On > Behalf Of wrong.addres...@gmail.com > Sent: Thursday, February 18, 2016 7:33 AM > To: python-list@python.org > Subject: Re: Considering migrating to Python from Visual Basic 6 for > engineering > applications > > torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti: > > On 18 February 2016 at 11:32, Chris Angelico wrote: > > > On Thu, Feb 18, 2016 at 10:11 PM, wrote: > > >> Almost everything points positively for Python. Thanks to all of you who > have responded. But please also tell me the disadvantages of Python. If I > start > using Python, I should be aware of the price I am paying. Speed is not a big > problem for me, so an interpreted language is fine. Is packaging/installing > very > messy? Do I create dozens of files for a simple program calculating the sum of > two numbers and product of two numbers in text boxes with one command to > be clicked? Can I learn this much in the first couple of hours? > > >> > > > > > > There are a few warts, particularly on Windows, as regards packaging > > > and third-party modules. Anything that's written in pure Python is > > > fairly easy; stuff that's written in C is sometimes a bit hairy. But > > > that's a limitation on the "extended library" of PyPI, not the stuff > > > that comes with Python itself. > > > > For packaging/installing it really depends on what you're trying to > > do. You have to understand that Python is used in many very different > > ways in different environments and ecosystems so there just isn't a > > single way of doing it. > > > > It sounds to me as if all of your needs can be solved in pure Python > > code possibly using some of the popular extension modules from PyPI. > > In this case it's actually very easy to package/install. You can > > package your code simply by zipping it up with a __main__.py file. > > Someone who wants to install it will simply have a two step process: > > first install Python (and possibly a few dependencies) and then obtain > > the zip file with your code in it. > > > > -- > > Oscar > > This form of packing is not desirable. I can't ask other people to install > Python on > their machines, and I also would not want show most of the code doing the > calculations. > > Another question I have is regarding reading numerical data from text files. > Is it > necessary to read one character at a time, or can one read like in Fortran and > Basic (something like Input #5
RE: Considering migrating to Python from Visual Basic 6 for engineering applications
I totally agree with Chris here, try it out, do some simpler things to get your feet wet before committing to redoing hundreds of thousands of lines of code in it. Find a few of the "deal breakers" and try to solve them in Python (create a hello world app in python, then package it in an exe and distribute it to some friends).. VB is a fine language, and is likely to suit your needs as well... even if we all believe that Python is better, the effort to convert from one to the other may not make sense. I would also suggest taking a few steps back and seeing if there is a different overall architectural approach that makes sense. If you are using a heavy weight local app, what about a web app? What about doing a combination approach? Have a back end running on a server with Python, that feeds a VB app on a client for displaying and manipulating data? (then a Java app for mobile clients or Linux ones?) Also, looking at existing frameworks and expandable apps out there that you might be able to do less work but still meet your goals with because 80% of the work was done for you... things like django, splunk, tableau, etc... Dan > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On > Behalf Of Chris Angelico > Sent: Thursday, February 18, 2016 8:06 AM > Cc: python-list@python.org > Subject: Re: Considering migrating to Python from Visual Basic 6 for > engineering > applications > > On Fri, Feb 19, 2016 at 2:49 AM, wrote: > > Thanks. You have guided me quite well, and I am almost ready to declare > > that I > will use Python for the next few decades. > > > > Don't declare like that - just start using it, and see what you think > :) But I would be very much surprised if Python doesn't get added to your > toolbelt. A good programmer should always keep a selection of tools handy - > seldom is one tool the right one for every job. > > > Imagine I want to read in two (or a few) numbers from a text file, display > > them > in two (or more) text boxes, calculate their sums and products, may be take > logarithms of them, and display them in other two text boxes or labels, and > make some bar charts, scatter plots, and later draw curves and surfaces on a > computer screen. Do I really need PyPi or other external stuff for this? Is > Python > well equipped for this? > > > > You could do all of that with just the standard library, but then your only > choice > of GUI library is Tkinter, which is derived from Tcl/Tk. > If you don't like how that looks (either in your code, or in the resulting > GUI), > you'll need to turn to PyPI for an alternative (eg something derived from GTK > or > wxWindows or Qt). I'm not sure how the graphing capabilities of Tkinter are, > so > you might want to grab matplotlib too - again, it'll give you a lot more > flexibility > than you would have if you restrict yourself to *just* the standard library. > But I think you could do all of that - certainly most of it - with just the > language > and standard library. > > > I will have to learn GUI creating quickly after I know the basics of > > reading and > writing text files, and doing simple mathematical calculations. > > > > Reading and writing text files is easy, as is basic mathematics. > You'll have that down in an hour or two, most likely, and then you'll have > time to > play GUIs. > > > Later I can imagine using things like sending an SMS from a phone running > > this > on Android, or placing a graph in a WhatsApp message, make a call to someone > and tell him the temperature is now too high, etc. These things might need > external libraries, but I can learn this later on. > > > > Those things will most likely require external libraries. But most of them are > probably possible. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE:
I am sorry, though I have to say that I would find it hard working with a large
snake every day as well. Luckily, there is a programing language (called
Python) that could help in developing a snake removing application pretty
easily.
If, however you are actually talking about the programming language, then if
you are asking for help in understanding it, or better being able to work with
it, a little more information would probably help others help you. If you are
simply making a statement that you are unable to work with it and have no
interest in trying, then I am sorry that you feel that way, and encourage you
to try a different language. (I would even try to recommend one, if we knew
more about WHY you can't work with python.)
If you are just trying to vent, I get that... though I would think that
constructive venting would work better; ("I can't work with that damn python
because it just won't install for me, I keep getting this stupid error 'blah'").
If you are trying to start an argument, or trolling, I suggest trying something
more controversial... "Python is the worst language in the world because you
have to indent everything exactly, that is a really stupid design!", that, I
suspect would get a really good argument going!
In any case, responding to your *actual* statement, good luck with finding
co-workers that you can work with, I know how frustrating it can be not liking
your co-workers.
Dan
> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
> Behalf Of Shamanov
> Sent: Monday, February 29, 2016 11:20 AM
> To: python-list@python.org
> Subject:
>
> I can't work with Python
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
python PEP suggestion
All,
I wanted to run the following thought past the list as a possible PEP
enhancement suggestion to see if it feels like something that is worth
proposing. I know it is not in the PEP format at this point, I can, and will,
clean it up if needed, I am just trying to throw it against the wall at this
point to see if it resonates... (or if it falls flat and goes "splat" ).
Thoughts?
Dan Strohl
New special method name to allow for more flexible object type casting/access,
and extend type() to cast objects using this special method name.
Overview:
Have a new special method name that would allow a given objects to request
information from another object in a given type, or to cast an object into a
different type, and extend the built in type() function to use this.
Rationale:
There is currently __str__, __int__, and __bool__ that allow me to tell an
object how it should reply to a request for these types of basic data types.
However if I want to access a copy of the objet in dict form, or as a list, or
if I am trying to convert something using json, there is no standard way of
doing that for a custom object (I know I can do __getitem__ and/or __iter__,
but I many processes don't try these if the object is not a subclass of dict or
list/tuple)
Proposal:
What I am proposing is something like:
object.__cast__(self, to_class):
"""
to_class: the class type that you wish to return.
"""
-and-
Class type(object, to_class):
"""
With two arguments, will attempt to cast "object"
into "to_class" if possible. This would be done by something like the
following:
(with 1 and 3 arguments, will work as currently
designed)
"""
Type(object, to_class):
If isinstance(to_class, (int, str,
bool)):
Return
to_class(object)
Else:
Try:
Return object.__cast__(to_class):
Except
AttributeError:
#
yes, I know this should be more readable!
Raise TypeError('object x could not be converted to type y")
This allows for more customization on how a developer would want to return this
object in various forms, and if, for example, the custom object was passed to
something like json.dumps, it could try converting the object to something it
recognizes first, or even try doing something like type(custom_object, json)
and see what returned.
So, in implementation I might do something like:
def __conv__(self, to_class):
if isinstance(to_class, (json, dict)):
return self._data_dict
elif isinstance(to_class, ElementTree):
return self._get_xml_dict()
else:
raise TypeError('could not convert
object to class')
This allows for developers of classes that operate on data passed to be able to
define a process that they would use to accept unknown objects, without having
to worry about handling all of the different potential object types, and pass
the responsibility for how to structure the information to the developer of the
custom object.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Script to extract text from PDF files
Its possible (likely) that I came into this in the middle, so sorry if this was already thrown out... but have you looked at any of the following suggestions? https://pypi.python.org/pypi?%3Aaction=search&term=pdf+convert&submit=search http://stackoverflow.com/questions/6413441/python-pdf-library https://www.binpress.com/tutorial/manipulating-pdfs-with-python/167 -Original Message- From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On Behalf Of Scott Werner Sent: Friday, November 06, 2015 2:30 PM To: python-list@python.org Subject: Re: Script to extract text from PDF files On Tuesday, September 25, 2007 at 1:41:56 PM UTC-4, brad wrote: > I have a very crude Python script that extracts text from some (and I > emphasize some) PDF documents. On many PDF docs, I cannot extract > text, but this is because I'm doing something wrong. The PDF spec is > large and complex and there are various ways in which to store and > encode text. I wanted to post here and ask if anyone is interested in > helping make the script better which means it should accurately > extract text from most any pdf file... not just some. > > I know the topic of reading/extracting the text from a PDF document > natively in Python comes up every now and then on comp.lang.python... > I've posted about it in the past myself. After searching for other > solutions, I've resorted to attempting this on my own in my spare time. > Using apps external to Python (pdftotext, etc.) is not really an > option for me. If someone knows of a free native Python app that does > this now, let me know and I'll use that instead! > > So, if other more experienced programmer are interested in helping > make the script better, please let me know. I can host a website and > the latest revision and do all of the grunt work. > > Thanks, > > Brad As mentioned before, extracting plain text from a PDF document can be hit or miss. I have tried all the following applications (free/open source) on Arch Linux. Note, I would execute the commands with subprocess and capture stdout or read plain text file created by the application. * textract (uses pdftotext) - https://github.com/deanmalmgren/textract * pdftotext - http://poppler.freedesktop.org/ - cmd: pdftotext -layout "/path/to/document.pdf" - - cmd: pdftotext "/path/to/document.pdf" - * Calibre - http://calibre-ebook.com/ - cmd: ebook-convert "/path/to/document.pdf" "/path/to/plain.txt" --no-chapters-in-toc * AbiWord - http://www.abiword.org/ - cmd: abiword --to-name=fd://1 --to-TXT "/path/to/document.pdf" * Apache Tika - https://tika.apache.org/ - cmd: "/usr/bin/java" -jar "/path/to/standalone/tika-app-1.10.jar" --text-main "/path/to/document.pdf" For my application, I saw the best results using Apache Tika. However, I do still encounter strange encoding or extraction issues, e.g. S P A C E D O U T H E A D E R S" and "\nBroken \nHeader\n". I ended up writing a lot of repairing/cleaning methods. I welcome an improved solution that has some intelligence like comparing the extract plain text order to a snapshot of the pdf page using OCR. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: python PEP suggestion
You mentioned that it is a bit contrary to how Python currently works, I am not
sure I understand that, can you elaborate a bit?
"Conditional execution, indexing (__index__), numeric conversions (__float__
also), and displaying are special cases related to syntax operations.
You have left out the use of abstract base classes. An iterable that can be
used as a mapping can register itself as a mapping. Json could check whether
something is a sequence or mapping and iterate to get values or pairs of
values."
All of the above is true, and all of the above are various tools that can work
(and I have used most of them from time to time). However, there is a limit to
how many different types of special methods that should be built in, built in,
what if I want to build an object that would return a datetime or bytearray
object as needed, or something more esoteric, or if I wanted to provide
different types of data depending on the calling object?
What I thinking about is something that allows the called object to return
information based on the calling object, (or at least based on what the calling
object wants to ask for) in a manner that makes the most sense.
This _seems_ like it fits pretty well with Python's module / library /
orientation... the library authors often do not know anything about the ones
using their objects (and should not have to). With something like this, it
allows the library author to have a "standard" way of saying, "I want data in
this format". That could be simply saying "I am json and want data that will
work for me", or it could be saying "I want a datetime from you". Then, even
if the called / passed object is not mappable, or is a subclass of something
totally different, the called object has the ability to respond in a way that
the author of the called object chooses.
If, for example, I choose to implement an object as a mapping object (using
__getitem__, subclassing userdict, using collections.abc.Mapping, or whatever),
I am in general only going to be able to answer a call to object[key] one way.
I could certainly do a custom method or property but then we get back to both
authors needing to coordinate more.
Functions that unnecessarily restrict inputs to subclasses of list or dict will
not be solved by this.
Yup, it doesn't solve everything, it just provides another tool that people
*could* use to write interoperable libraries and objects.
Of course, the tranformation would be unidirectional.
Again, yup, just like if I implemented "MyObject.__str__()", it does not
guarantee that I did "MyObject('a_string')" it would work (and often doesn't).
The excessive indents of 31 and 15 spaces make the rest of this post
unnecessarily hard to read.
Sorry about that, damn outlook tabs being expanded to stupid numbers I guess.
I will do better next time..
Does any of that help?
Dan
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Terry Reedy
Sent: Sunday, November 08, 2015 2:27 PM
To: python-list@python.org
Subject: Re: python PEP suggestion
On 11/6/2015 1:21 PM, Dan Strohl wrote:
> All,
>
> I wanted to run the following thought past the list as a possible PEP
> enhancement suggestion to see if it feels like something that is worth
> proposing. I know it is not in the PEP format at this point, I can, and
> will, clean it up if needed, I am just trying to throw it against the wall at
> this point to see if it resonates... (or if it falls flat and goes "splat"
> ).
>
> Thoughts?
At first glance, plausible, but I am not sure needed, and it seems a bit
contrary to how Python currently works.
> New special method name to allow for more flexible object type
> casting/access, and extend type() to cast objects using this special method
> name.
>
> Overview:
>
> Have a new special method name that would allow a given objects to request
> information from another object in a given type, or to cast an object into a
> different type, and extend the built in type() function to use this.
>
> Rationale:
> There is currently __str__, __int__, and __bool__ that allow me to
> tell an object how it should reply to a request for these types of
> basic data types. However if I want to access a copy of the objet in
> dict form, or as a list, or if I am trying to convert something using
> json, there is no standard way of doing that for a custom object (I
> know I can do __getitem__ and/or __iter__, but I many processes don't
> try these if the object is not a subclass of dict or list/tuple)
Conditional execution, indexing (__index__), numeric conversions (__float__
also), and displaying are special cases related to syntax operations.
Functions that unnecessarily re
RE: Clickable hyperlinks
The best bet (unless you know that you are outputting to a specific place, like
html or excel) is to always include the "https://"; or "http://"; since most of
the consoles / terminals that support clickable links are parsing them based on
"seeing" the initial "http://";. If your output just looks like
"mysite.com/coolpage.html", many systems will simply ignore them.
At one point I had made a class that you could pass the link to, and then you
could request different output based on your needs... so basically something
like:
>> url = url_class("mysite.com/coolpage.html")
>> print(url)
"http://mysite.com/coolpage.html";)
>> print(url.plain)
"mysite.com/coolpage.html"
>> print(url.html('My Site"))
'http://mysite.com/coolpage.html";>My Site'
(or whatever... I think I actually just sub-classed url.parse or something)
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Devin Jeanpierre
Sent: Tuesday, January 03, 2017 12:57 PM
To: pyt...@deborahswanson.net
Cc: comp.lang.python
Subject: Re: Clickable hyperlinks
Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The way to
make an URL clickable is to use a terminal that makes URLs clickable, and print
the URL:
print("%s: %s" % (description, url))
-- Devin
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
> Excel has a formula:
>
> =HYPERLINK(url,description)
>
> that will put a clickable link into a cell.
>
> Does python have an equivalent function? Probably the most common use
> for it would be output to the console, similar to a print statement,
> but clickable.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Re: Clickable hyperlinks
Keeping mind how this all works...
Python is providing the data, the console/terminal/app handles how that data is
displayed. There is no specification for text output to be hyperlinked (that
I know about at least), so while some apps may handle specific coding to tell
them that "this text should be a hyperlink", most will either parse the text
looking for hyper-linkable string, or more commonly, just output the text as
text.
If you control the app that is displaying info to the user (such as using QT or
another GUI tool), or generating html yourself, you can control if a text
string is a hyperlink or not, and what to do with the hyperlink when clicked.
So, if you want clickable links, you would need to find a console/terminal that
supported them.
Some references:
https://opensource.com/life/15/11/top-open-source-terminal-emulators (see
Gnome)
http://unix.stackexchange.com/questions/63417/is-there-a-terminal-app-that-allows-filenames-to-be-clickable
http://superuser.com/questions/654116/configure-os-x-terminal-to-detect-urls-and-make-them-clickable
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/url-launching.html
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Deborah Swanson
Sent: Tuesday, January 03, 2017 1:35 PM
To: 'Devin Jeanpierre'
Cc: 'comp.lang.python'
Subject: RE: Re: Clickable hyperlinks
Devin Jeanpierre wrote, on January 03, 2017 12:57 PM
>Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The
way to
>make an URL clickable is to use a terminal that makes URLs clickable,
and
>print the URL:
>
>
>print("%s: %s" % (description, url))
>
>
>
>
>-- Devin
I'm sorry, I should have said a GUI console because I wouldn't expect a
text-based console to produce clickable links. But it appears that a simple GUI
console can't do it either. I have 3 GUI consoles and in all 3, when I ask:
print("%s: %s" % ("python.org list",
"https://mail.python.org/mailman/listinfo/python-list";))
I get:
python.org list: https://mail.python.org/mailman/listinfo/python-list
(Outlook made the url clickable here, the python GUI consoles just output plain
text.)
Pretty clearly the output is plain text because your format parameters are %s.
Maybe the trick, if there is one, is in a format parameter for urls.
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
Excel has a formula:
=HYPERLINK(url,description)
that will put a clickable link into a cell.
Does python have an equivalent function? Probably the most common use for it
would be output to the console, similar to a print statement, but clickable.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Clickable hyperlinks
The best bet (unless you know that you are outputting to a specific place, like
html or excel) is to always include the "https://"; or "http://"; since most of
the consoles / terminals that support clickable links are parsing them based on
"seeing" the initial "http://";. If your output just looks like
"mysite.com/coolpage.html", many systems will simply ignore them.
At one point I had made a class that you could pass the link to, and then you
could request different output based on your needs... so basically something
like:
>> url = url_class("mysite.com/coolpage.html")
>> print(url)
"http://mysite.com/coolpage.html";)
>> print(url.plain)
"mysite.com/coolpage.html"
>> print(url.html('My Site"))
'http://mysite.com/coolpage.html";>My Site'
(or whatever... I think I actually just sub-classed url.parse or something)
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Devin Jeanpierre
Sent: Tuesday, January 03, 2017 12:57 PM To: pyt...@deborahswanson.net
Cc: comp.lang.python
Subject: Re: Clickable hyperlinks
Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The way to
make an URL clickable is to use a terminal that makes URLs clickable, and print
the URL:
print("%s: %s" % (description, url))
-- Devin
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
> Excel has a formula:
>
> =HYPERLINK(url,description)
>
> that will put a clickable link into a cell.
>
> Does python have an equivalent function? Probably the most common use
> for it would be output to the console, similar to a print statement,
> but clickable.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Re: Clickable hyperlinks
Keeping mind how this all works...
Python is providing the data, the console/terminal/app handles how that data is
displayed. There is no specification for text output to be hyperlinked (that
I know about at least), so while some apps may handle specific coding to tell
them that "this text should be a hyperlink", most will either parse the text
looking for hyper-linkable string, or more commonly, just output the text as
text.
If you control the app that is displaying info to the user (such as using QT or
another GUI tool), or generating html yourself, you can control if a text
string is a hyperlink or not, and what to do with the hyperlink when clicked.
So, if you want clickable links, you would need to find a console/terminal that
supported them.
Some references:
https://opensource.com/life/15/11/top-open-source-terminal-emulators (see
Gnome)
http://unix.stackexchange.com/questions/63417/is-there-a-terminal-app-that-allo
ws-filenames-to-be-clickable
http://superuser.com/questions/654116/configure-os-x-terminal-to-detect-urls-an
d-make-them-clickable
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/url-launching.html
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Deborah Swanson
Sent: Tuesday, January 03, 2017 1:35 PM To: 'Devin Jeanpierre'
Cc: 'comp.lang.python'
Subject: RE: Re: Clickable hyperlinks
Devin Jeanpierre wrote, on January 03, 2017 12:57 PM
>Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The
way to
>make an URL clickable is to use a terminal that makes URLs clickable,
and
>print the URL:
>
>
>print("%s: %s" % (description, url))
>
>
>
>
>-- Devin
I'm sorry, I should have said a GUI console because I wouldn't expect a
text-based console to produce clickable links. But it appears that a simple GUI
console can't do it either. I have 3 GUI consoles and in all 3, when I ask:
print("%s: %s" % ("python.org list",
"https://mail.python.org/mailman/listinfo/python-list";))
I get:
python.org list: https://mail.python.org/mailman/listinfo/python-list
(Outlook made the url clickable here, the python GUI consoles just output plain
text.)
Pretty clearly the output is plain text because your format parameters are %s.
Maybe the trick, if there is one, is in a format parameter for urls.
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
Excel has a formula:
=HYPERLINK(url,description)
that will put a clickable link into a cell.
Does python have an equivalent function? Probably the most common use for it
would be output to the console, similar to a print statement, but clickable.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Request for comments: use-cases for delayed evaluation
I could easily see using all of the examples; I run into this pretty regularly. What about something like the following (which, honestly is really a combination of other examples). If I have a function that has multiple parameters, each of which might be expensive, but it might break out earlier depending on how each one is evaluated... for example: (pretending that "$" is a flag that says "evaluate later", and $(arg) is how you say "evaluate now") def combine_unless_none(*$args, sep=', '): """ if any arg evaluates to None, return '', otherwise join""" for arg in args: tmp_arg = $(arg) If tmp_arg is None: return " return sep.join(args) -- https://mail.python.org/mailman/listinfo/python-list
RE: why does list's .remove() does not return an object?
On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
> I don't understand what this would return? x? You already have x. Is
> it meant to make a copy? x has been mutated, so I don't understand the
> benefit of making a copy of the 1-less x. Can you elaborate on the
> problem you are trying to solve?
>
> --Ned.
>
>
> assignment to another var
>
Though I don’t know what the OP was specifically looking for I could see a
benefit to returning the item deleted.
So, lets take as an example I have an object like:
class ListItem(object):
def __init__(self, key, data):
self.key = key
self.data = data
def __eq__(other):
return other == self.key
and I do something like:
i1 = ListItem('hello', 'foobar')
l2 = ListItem('goodby', 'snafu')
l = [i1, i2]
So, lets say I have a need where I want to do something like a remove, but I
also want to be able to get the .data variable from the object I am removing,
it would be nice to be able to simply do
x = l.remove('hello')
print(x.data)
Yes, I could do a index/pop to get this, or I could keep a separate dict of the
objects as well for lookups, or a number of other techniques, but it would be
easier to simply get it back during the remove().
Dan Strohl
--
https://mail.python.org/mailman/listinfo/python-list
RE: "Data blocks" syntax specification draft
On 5/19/18 10:58 PM, Mikhail V wrote: >> I have made up a printable PDF with the current version of the syntax >> suggestion. >> >> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf >> >> After some of your comments I've made some further re-considerations, >> e.g. element separation should be now much simpler. >> A lot of examples with comparison included. >> >> >> Comments, suggestions are welcome. >> > >Mikhail, you have a completely different esthetic for syntax than the rest of >the Python world. Your proposal seems to have almost nothing in common with >existing Python syntax. Your approach to >whitespace is different. You've >ignored existing words (tuple, str) in favor of new shorthands (t, s). You >use semicolon and asterisk for something new. Parentheses enclosing strings!? > >This is never going to be adopted as Python syntax. It's too different. > >That's fine: make a new file format. Write a library that can read and write >this format. Propose it to people, and get them using it. We have xml, ini, >json, yaml, and toml. Now we can also have data >blocks. Mikhail, I'm afraid I would have to agree with Ned, in looking at it, this did not seem to be any less complex than existing python structures, nor was it significantly less typing (in many cases) after you put the /// in there. Also there were several places where it's not deterministic enough around data types... how would it handle a tuple like: test=(0x991, 0x01, 'Hello', 123e334562.9, 1, '1', "This is a single string (including this)", custom_object) I get the idea of trying to remove some of those extra punctuation marks, but they exist for a reason, and removing them just leads to a more complex world of "sometimes you use them and sometimes you don’t". For the dictionary type, with odd elements being keys and even being values, that can get really hard to visually parse if you have a long block in a row... for example: ///d abc def ghi jkl mno pqr stu vwx yz1 ab2 cd4 Would break, but... where? Which parts are supposed to be keys v. values? You mentioned ease of import of data in your summary, I haven't seen any data files that use a format like this, so I don’t offhand see that value, but if it is, as Ned mentioned, then doing a translator object for it makes sense. Approach this like a new data format (like XML, JSON, etc) Then also, if it ends up taking off, you are better placed to come back and say "see, everyone's using this format, Python should handle it by default". Finally, you mentioned several "main problems". Those I totally agree with, but I don’t think you realize how complex they are. The parser would have nightmares trying to parse some of these structures into tokens without having a totally different parser engine just for that, and there are lots of corner cases that would break this approach and would need a different approach, requiring a long list of caveats, and at least personally, I just don't see the value there. The few places where it seems like it would be a benefit are pretty small, and the places where it makes things more complex seem common. Dan Strohl -- https://mail.python.org/mailman/listinfo/python-list
RE: "Data blocks" syntax specification draft
> -Original Message-
>
> I think it would be appropriate to propose an alternative to TQS for this
> specific purposes. Namely for making it easier to implement parsers and
> embedded syntaxes.
>
> So what do I have now with triple quoted strings - a simple example:
>
> if 1:
> s = """\
> print ("\n") \\
> foo = 5
> """
>
> So there is a _possibility_ in the sense it is possible to do, so let's say I
> have a
> lib with a parser, etc. Though now a developer and a user will face quite real
> issues:
>
> - TQS itself has its specific purpose already in many contents,
> which may mean for example hard-coded syntax highlighting
> - there a lot of things happening here: e.g. in the above example
> I use "\n" which I assume a part of string, or \\ - but it is interpreted.
> Maybe some other things regarding escaping. This particular
> issue maybe a blocker for making use of TQS in some data cases,
> Say if the target source text need these very characters.
>
Yup, I can see this, I do use """ in a number of ways, often to comment out
large chunks of code. (OK, I probably should not, but I do).
> - indentation is the part of TQS. That is of couse by design
> so and it's quite logical, though it is hard-coded behaviour and thus
> does not make the presentation a natural part of blocks containing
> this string.
> - appearance: imagine you have some small chunks of embedded
> code parts and you will still have the closing """ everywhere -
> that would be really hairy.
>
>
And yup, that does cause some challenges sometimes.
>
> Explanation:
> [here i'll use same symbol /// for the data entry point, but of course it can
> be
> changed if a better idea comes later. Also for now, just for simplicity - the
> rule
> is that the contents of a block starts always on the new line.
>
> So, e.g. this:
>
> data = /// s4
> first line
> last line
> the rest python code
>
> - will parse the block and knock out leading 4 spaces.
> i.e. if the first line has 5 leading spaces then 1 space will be left in the
> string.
> Block parsing terminates when the next line does not satisfy the indent
> sequence (4 spaces in this case).
> Another obvious type: tabs:
OK, I CAN see this as a potentially useful suggestion. There are a number of
times where I would like to define a large chunk of text, but using tqs and
having it suddenly move to the left is painful visually. Right now, I tend to
either a) do it anyway, b) do it in a separate module and import the variables,
or c) do it and parse the string to remove the extra spaces.
Personally though, I would not hard code it to knock out 4 leading spaces. I
would have it handle spaces the same was that the existing parser does, if
there are 4 spaces indending the next line, then it removes 4 spaces, if there
are 6 spaces, it removes 6 spaces, etc... ignoring additional spaces within the
data-string object. Once it hits a line that has the same number if indenting
spaces as the initial token, the data-string object is finished.
>
> data = /// t1
> first line
> last line
> the rest python code
>
> Will do the same but with one tabstop character.
>
Tabs / spaces should be handled as normal (up to the data-string object starts,
after which, it pulls off the first x tabs or spaces, and leaves anything else)
> Actually that's it!
> Some further ideas:
>
> data = /// ts
> - "any whitespace" (mimic current Python behaviour)
>
> data = /// s# or
> data = /// t
> - simply count amount of spaces (tabs) from first
> line and proceed, otherwise terminate.
>
> data = /// "???"
> ??? abc foo bar
> ???
>
> - defines indent character by string: crazy idea but why not.
>
Nope, don't like this one... It's far enough from Python normal that it seems
unlikely to not get through, and (personally at least), I struggle to see the
benefit.
> Language parameter, e.g.:
> data = /// t1."yaml"
>
> -this can be reserved for future usage by code analysis tools or dynamic
> syntax highlighting.
>
I can see where this might be interesting, but again, I just don't see the
need, if the spec returns a string, you can use that string in any parser you
want. If you want to customize how it's handled, then you can always create a
custom object for it.
> That's just a rough specification.
>
> What should it give as result:
>
To me, this seems like a simply additional specification for a TQS, with the
only enhancement being that it's an indented TQS basically, so the return is a
string.
> 1. No clash with current TQS rules - less worries
> about reserved characters.
>
> 2. Built-in indentation parsing parameter makes it more or
> less natural continuation of Python blocks and is char-precise,
> which is very important here.
>
> 3. Independent of the indent of containing block!
>
> 4. Parameter descriptor can be developed in such manner
>that it allows more customisation and additions
RE: "Data blocks" syntax specification draft
First of all, I suggest splitting this into a separate proposal (new thread) that way you will avoid confusion for people who are still considering the older proposal, and for the (probably many) people who have stopped reding the old thread due to some of the more heated conversations in there. > > Though hard-coded knock-out is also very useful, e.g. for this: > > data = /// s4 > First line indented more (8 spaces) > second - less (4 spaces) > rest code > > So this will preserve formatting. > True, but in everything, there is a balance between flexibility and complexity. Nothing else in python (that I can think of) forces people to use 4 spaces, that's merely a style thing. If I want to use 2 spaces, I can, I've seen modules that use 3 spaces for indenting and it works fine. So, the flexibility of adding the ability to further indent the first line seems to me to be outweighed by the added complexity of this being "different". > > >> data = /// "???" > >> ??? abc foo bar > >> ??? > >> > >> - defines indent character by string: crazy idea but why not. > >> > > > > Nope, don't like this one... It's far enough from Python normal that > > it seems unlikely to not get through, and (personally at least), I struggle > > to > see the benefit. > > Heh, that was merely joke - but OTOH one could use it for hard-coded indent > sequences: > Yeah, I get it (now ), I would caution against making jokes in the middle of an already controversial thread. When they are missed, they tend to be used against your suggestion. > data = /// "" > First line indented more (8 spaces) > second - less (4 spaces) > rest code > > A bit sloppy look, but it generalizes some uses. But granted - I don't see > much > real applications besides than space and tab indented block anyway - so it's > under question. > > > >> Language parameter, e.g.: > >> data = /// t1."yaml" > >> > >> -this can be reserved for future usage by code analysis tools or > >> dynamic syntax highlighting. > >> > > > > I can see where this might be interesting, but again, I just don't see > > the need, > > I think you're right - if need a directive for some analysis tool then one > can > make for example a consideration to precede the whole statement with a > directive, say in a comment: > > # lang "yaml" > data = /// t > first line > last line > rest > > Again, you're complicating the thought without really providing enough benefit to it to justify the complication. Something to keep in mind when you look at most languages, the simpler the language primitives the better, added flexibility can (and should) be added later in modules and functions. But primitives should have as few caveats as possible, they should work pretty much anywhere with very little needed documentation. To me, the idea of an indented TQS idea (data-string, data block, whatever) Is interesting. Extra features are fine, but when they start making it "more complex" to use, then you should back off. > > > Also I am thinking about this - there might be one useful 'hack". > One could even allow single-line usage, e.g.; (with a semicolon) > > data = /// s2: first line > > - so this would start parsing just after colon : > "pretending it is block. > This may be not so fat-fingered-proof and 'inconsistent', but in the end of > the > day, might be a win actually. > > If you are thinking about this road, what about instead making another reserved word and approaching it like class or def, for example; datablock data: first line second line Then you can also add functions without "breaking" python approaches like: datablock data(foo, bar, blah): First line Second line (*having thrown this out, I don’t know the parser/compiler well enough to know if this would cause more problems or not). Being honest, I'm not sure that even these would be enough to get it added without a stronger case, but the further you stray from the python norms, the less likely it is to even get consideration. -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)
> > > Personally though, I would not hard code it to knock out 4 leading > > spaces. I would have it handle spaces the same was that the existing > > parser does, if there are 4 spaces indending the next line, then it > > removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc... > > ignoring additional spaces within the data-string object. Once it > > hits a line that has the same number if indenting spaces as the > > initial token, the data-string object is finished. > > How about this? > > x = > Here is a multi-line string > with > indentation. > > > This would be equivalent to > > x = 'Here is a multi-line string\nwith\n indentation.' > Looks right to me, I don't know if the quad quote overloads the ' and " character too much, but I'm not against it. > Rules: > > * The leading and trailing must be aligned vertically. > * The contents of the string must be indented at least as far as the >delimiters (and with consistent tabs/spaces). >This leading white space is ignored. > * All the leading white space beyond this 'left edge' is preserved. > * The newlines after the leading and before the trailing are >ignored, all the others preserved. (I thought about preserving the >trailing newline, but it is easier to add one than remove one.) > > hp > > These sound good to me. -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)
> > How about we instead just use the rules from PEP 257 so that there aren't two > different sets of multi-line string indentation rules to have to remember? > > https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation > I like that, better to be closer to the existing standards. One could then see this as an extension of the doc-strings. > Also, how about using a string prefix character instead of making quad-quote > meaningful? Apart from being hard to visually distinguish from triple-quote, > this would break existing triple-quote strings that happen to start with the > quote character, e.g What?' she asked.''' > > I don't know if 'i' would be the right prefix character for this, but it's > unused > and is short for 'indented': > Or go with a different character (or set of characters) altogether... like $, \, ~, ^, < ? (good catch on it catching on hello' I am not in this''', I forgot about that behavior) I'm not against a prefix character, just throwing out alternatives. (though, to me, the 'i' indicated int) -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)
> This is of course not a problem if the *trailing* quote determines the > indentation: > > a_multi_line_string = i''' >Py- > thon > ''' I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting, which is something that I would want to stay away from changing. > > In any case, Chris made a good point that I agree with. This doesn't > > really need to be syntax at all, but could just be implemented as a > > new string method. > > Depending on the details, not quite. A method wouldn't get the horizontal > position of the leading quote. It could infer the position of the trailing > quote, > though. > What about if we used Chris's approach, but added a parameter to the method to handle the indent? For example, Test = """ Hello, this is a Multiline indented String """.outdent(4) The outdent method could look like: string.outdent(size=None) """ :param size : The number of spaces to remove from the beginning of each line in the string. Non space characters will not be removed. IF this is None, the number of characters in the first line of the string will be used. If this is an iterable, the numbers returned from each iteration will be used for their respective lines. If there are more lines than iterations, the last iteration will be used for subsequent lines. This solves the problem in a very pythonic way, while allowing the flexibility to handle different needs. -- https://mail.python.org/mailman/listinfo/python-list
Override built in types... possible? or proposal.
Is it possible to override the assignment of built in types to the shorthand
representations? And if not, is it a reasonable thought to consider adding?
For example, right now, if I do:
test = "this is a string",
I get back str("this is a string"). What if I want to return this as
my_string("this is a string") (OK, I know I have a recursive issue in my
example, but hopefully you get the point).
Or;
Test = ['item1', 'item2', 'item3'] returns a list, what if I want to add
functionality to all lists in my module? (and yes, I know I could simply not
do [] and always do my_list('item1', 'item2', 'item3']
I am envisioning something in the header like an import statement where I could
do;
override str=my_string
override list=my_list
This would only be scoped to the current module and would not be imported when
that module was imported.
Thoughts?
Dan Strohl
--
https://mail.python.org/mailman/listinfo/python-list
RE: Override built in types... possible? or proposal.
> > > > I am envisioning something in the header like an import statement > > where I could do; > > > > override str=my_string > > override list=my_list > > > > This would only be scoped to the current module and would not be > imported when that module was imported. > > > > Thoughts? > > > > Dan Strohl > > > > My problem with this idea is that it breaks expectations. If I know one > thing as > a Python programmer, it's that 'Bob' is a str. Each time and every time. If > you > could override the meaning of basic constant identifiers to where I have no > idea how they behave, that creates an easy thing to miss that changes the > entire meaning of the things you've written. > True, though, to determine what almost anything is, you should look at the imports anyway, just in case I happened to do something like; Import my_sys as sys > What's the use case here? And why is that use case better than, for instance, > simply defining a function in the module that does the things you want done > to strings? Not everything has to be an object method. It's not necessarily better, it simply provides more flexibility in how things are approached. In most cases I would probably define a function for something as you suggested, or define a new class and just instantiate that object instead when needed, but I can see a time when it would be nice to be able to simply say, "I really want to handle all of my dictionaries in this module in a certain way", then not have to worry about it. To me, one of the things I like about Python is that I can override many of the way things are handled via sub-classes, magic methods, importing "as" etc... this is simply an extension of that existing flexibility. And yes, it gives developers another tool they can shoot themselves pretty easily in the foot with if they aren't careful in how they use it, but so many of the good tools do that already. Honestly, I am not so locked into this that I would scream about it not working, but there have been times when it would have been helpful in the past, so I figured I would bring it up and see what others thought. Dan -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings
> > I would prefer to remove the padding, like this: > > Test = """ > |Hello, this is a > | Multiline indented > |String > """.outdent(padding='|') > > Or write it like this? > > Test = """|Hello, this is a > | Multiline indented > |String > """.outdent(padding='|') > > Hmm, the sign of Zorro! :-) > > I'm starting to like outdent(), but that may be my TIMTOWTDIism speaking. > I can see both outdent(padding="|") and outdent(size=4) being useful in various cases. If this ends up being the recommendation, I would also suggest adding str.indent(), it evens out the methods and most of the time I use the textwrap functions it is either indent or outdent, so this would clean up those pieces. So... how does one go about suggesting changes to the built in types? I could take a whack at the code for it, but my C skills are no where near what should probably be needed for something this close to the core of the language. I'm not sure if adding a couple of methods is a PEP type of thing. Dan Strohl -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings
> > It would probably have to go via python-ideas, but if it gets the OK there I > doubt it would need a PEP. > Cool, thanks! > There are a few key questions I'd expect to see come up. > > Why does this need to be a string method? Why can't it be a standalone > function? Maybe you should publish an implementation on PyPI, collect some > data on how popular it is, and then if it's widely used, propose it for > inclusion > in the stdlib at that point? By making it a string method, you're also > restricting > its use to users of recent versions of Python, whereas a PyPI implementation > would work for everyone. Good point, so, basically, there already is a function for this built in textwrap.dedent() and textwrap.indent(), I would think (hope) that that would answer that question. -- https://mail.python.org/mailman/listinfo/python-list
RE: Indented multi-line strings
> > > No-one is saying a method is *worse* than a standalone function - they are > just saying it's *not sufficiently better* to justify creating a string > method that > replicates an existing stdlib function. > What about performance? I would expect a string method to perform better than a stdlib function. (no?) Especially if it's something that could be used commonly it seems like having that function be of higher performance would be a benefit? At least for me, when I do use this, it's often in places like logging where it could well be called a lot. Dan -- https://mail.python.org/mailman/listinfo/python-list
RE: syntax difference (type hints)
> -Original Message-
> From: Python-list On
> Behalf Of Schachner, Joseph
> Sent: Monday, June 18, 2018 7:58 AM
> To: Ed Kellett ; python-list@python.org
> Subject: RE: syntax difference (type hints)
>
> EXTERNAL MAIL: python-list-bounces+d.strohl=f5@python.org
>
> Assuming that we want Python to remain a dynamically typed (but strongly
> typed) language, I believe the proposed type hints are only necessary for
> function definitions, where the caller really needs to know the types of
> arguments to pass in. At the moment that purpose is (I think adequately)
> served by def strings, triple quoted strings immediately following the
> function
> declaration. When I do code reviews for Python developed here, if the
> argument names of a function do not hint at the type they should be and there
> is no def string then I insist that something be added. Often what gets added
> is a def string that says something about what the function does and explains
> what argument types are expected.
>
> -- Joseph S.
>
I like having the option to add type hints to various things, including
functions, but also classes, and the methods, and attributes of a class.
While I don't add them to every one of these every time, if I write a function
that I expect to be used by someone else, I will annotate it. Similarly, if I
write a class that I expect to be instantiated or sub-classed as part of a
library, I will annotate that as well, including any attributes that I expect
to be used or changed.
I haven't totally utilized the new type hinting yet, I am still often still
documenting in the triple quoted strings using epytext type hinting, but that
doesn't really handle things like "a list of strings", or even worse, " a
dictionary that looks like dict("key1":1, "key2":"foobar") in a "standard" way
(that I have found at least), or cases where an argument can be a string OR an
int, or a list. (I use the string/list option pretty regularly when I have
functions that can handle one object, or multiple ones, and I've already used
the * to break out something else). I'm looking forward to finding the time to
figure out how to best annotate those types of things.
And I have found that having these things well annotated does help my IDE
(PyCharm) to keep me from making simple mistakes.
In the end, I figure that I don't see any real downside to the new type
hinting, if I use it, great, if not, that's fine as well. I would certainly
not be supportive of making it required in order to compile though.
--
https://mail.python.org/mailman/listinfo/python-list
RE: __init__ patterns
I will put imports into my __init__ files, so that I can import things from the module directly instead of having to import from a file in the module. I almost never put code in the __init__'s, I have a couple of times put in something that was designed to modify which routine was imported (i.e., pull this module in if it's a windows box, or that one for other. Or, use this routine for py 2.x and that one for 3.x. Even there, I prefer to do it in the files themselves, but sometimes it's just easier to do it at the __init__ level. I may also put common documentation in the __init__ file that explains the file structure for the module, how to interact with it, etc... For many shared functions, I try to maintain a common helper module that is shared by a number of programs, or a helper file in a module if I need to rather than putting it in the __init__ Dan > -Original Message- > From: Python-list On > Behalf Of Tim > Sent: Thursday, August 30, 2018 6:01 AM > To: python-list@python.org > Subject: __init__ patterns > > EXTERNAL MAIL: python-list-bounces+d.strohl=f5@python.org > > I saw a thread on reddit/python where just about everyone said they never > put code in their __init__ files. > > Here's a stackoverflow thread saying the same thing. > https://stackoverflow.com/questions/1944569/how-do-i-write-good-correct- > package-init-py-files > > That's new to me. I like to put functions in there that other modules within > the module need. > Thought that was good practice DRY and so forth. And I never do 'from > whatever import *' > Ever. > > The reddit people said they put all their stuff into different modules and > leave > init empty. > > What do you do? I like my pattern but I'm willing to learn. > > thanks, > --Tim > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: how to setup for localhost:8000
If you got an empty page with no errors (and no warnings trying to get there...) it is likely that your server is working, and you are trying to access it correctly, but the server is not serving anything. Most of the time, if the server is not present, you will get a timeout error saying the browser could not connect to server xxx. Or the site can't be reached, or something. I am not however much of an expert in figuring out WHY it isn't showing anything (I used a different lib for http servers), but I am sure someone else on this list is. I can only tell you that you probably at least launched the server correctly. Have you tried the example on the page in the docs? (about 3/4 of the way down). https://docs.python.org/3/library/http.server.html If that doesn't work, it's possible you have a firewall or browser rule blocking something... and it if does work, you can look back at your code to see what might be wrong. (I suggest playing with the log_request, log_error, and log_message parameters to figure out what is happening.) OF course, that all assumes that someone else smarter than I on this list doesn't come forth and just say... "well, just do this, and poof, all will be good". Sorry it's not more. Dan > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of wrh8...@gmail.com > Sent: Thursday, April 14, 2016 1:50 PM > To: python-list@python.org > Subject: Re: how to setup for localhost:8000 > > On Thursday, April 14, 2016 at 2:23:36 PM UTC-4, Andrew Farrell wrote: > > What happens when you type > > > > http://localhost:8000 > > > > Into the address bar of your browser as this is running? > > > > On Thu, Apr 14, 2016 at 12:46 PM, wrote: > > > > > Hi, > > > > > > I am working on window 7 and Python 3.5 to setup a localhost:8000 > > > but it did not get through as shown below: > > > > python -m http.server > > > Serving HTTP on 0.0.0.0 port 8000 ... > > > > > > But it did not show the results. > > > > > > Can someone help me how to setup the localhost? > > > > > > Thanks, > > > Wen-Ruey > > > > > > -- > > > https://mail.python.org/mailman/listinfo/python-list > > > > > hi Andrew, > > Yes. after I type http:\\localhost:8000, the browser did not show anything > except a empty page without any errors. > > Thanks, > Wen-Ruey > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: How to print a part of a string?
As with lots of things in python, there are lots of ways of approaching this, here are some hints for you to think about (in no particular order): - REGEX - replace() - string[:y] - split() And of course, you could consider creating a table with every possible string that could start with "ABC", and it's matching non-"ABC" string, then lookup the string in the table and get your match, it's a bit brute forcey, but it would work (eventually) Good luck in your homework! Dan > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of durgadevi1 > Sent: Friday, April 15, 2016 5:13 AM > To: python-list@python.org > Subject: How to print a part of a string? > > Hello all, > > I have another homework problem. > > I have a textfile. It contains lines of string. > > I am required to only print out a certain part of the string. > > For example the textfile contain: > > ABC X N > BCD Q E > ABC W A > > > I need to print all the parts that come after only ABC. > > That means I need to print only X from the first line and W from > the second line. > > I'm not sure of what code to use to achieve that. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Controlling the passing of data
In addition to Peter's points, - I would suggest breaking out the list comprehensions into standard for loops and/or functions. That makes it easier to read and troubleshoot. (you can always re-optimize It if needed.) - Peter's point about making things into functions will also help troubleshooting. You can better test the data going into and out of the function. In my code, I will often have the file access and data processing as separate functions, then the main routine just calls the function to get data, passes that data to a function that manipulates it, and then pass the results to a function that writes it out. This allows for much easier testing and troubleshooting of the individual functions. (sometimes I will reassemble them into one function when I am done, depending on my needs) More importantly though in terms of your getting help for your problem, the post is unclear (to me at least) in terms of what you are trying to achieve and what isn't working, Try considering the following suggestions: - It is unclear what the problem is that you are having, you say you are trying to do x, and you are having problems in a part after a comment, but none of the comments say "this is breaking". I assume you are talking about the comment that starts "Here I need to traverse", but don't know for sure, and even if it is, you don't specify what the problem actually is; are you receiving an exception message (please let us know what it is), is it running, but not doing anything? is it returning incorrect data? or??? - When posting, rather than commenting out code that you aren't using right now, and code that is working and not related to the problem, I recommend just deleting them so that people don't have to try to work through it for example, just remove the GetArgs function and just say fileList = "/xml_dir", and the section at the end that is all commented out, just remove it. You should just have the minimum needed to replicate the problem. This will also help in troubleshooting, when I have a problem like this, and I can't figure out what is going on, I will copy the code to a new file and make a program that will handle a specific set of data, and try to do the one thing that is breaking, removing all the rest of the stuff, and test the results.. so, for example, copy a sample of the xml with a couple of data items into a string var, and have a program that processes that and checks to see if at the end you end up with a list of the right values by printing a list rather than muddying the waters with file access, and writing out csv's. (by the way, this is a great time to start working with unit testing if you aren't already, it is simple to create this as a test case and you will find that if you start doing testing along the way, the time it takes to troubleshoot errors along the way will go down dramatically.) - Be clear at the end what you expect to get, especially if it is not what you are getting... so, either in the code as a comment, or in a descriptive paragraph, have a section that said something like: "At the end of the snippet, meetdata, racedata, clubdata, and raceid should be a list of dictionaries with the data from the xml" (or whatever... possibly with an example of what you would expect). This is even more important if the problem you are having is that the code is not returning correct data. This may not be as needed if the code is simply blowing up at line xx, though it would still help people understand your goal. - For the example at least (you may choose to do differently in your live code), use nice explanatory variable names and don't rename imports, so it would be clearer to say "import pandas", then "frames = pandas.DataFrame[])". That way the reader doesn't have to keep referring to the imports to figure out what is going on. Remember, you are asking a large number of people for help, most of which are pretty busy already, so the more you can do to simplify and show the exact problem, the more (and more useful) help you are likely to receive. To this lists credit, even if you are completely unclear in your question, you will likely get *something* back, (as you saw with Peters response), but what you get back is more likely to be a general suggestion rather than a specific fix for your problem. Dan Strohl > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of Peter Otten > Sent: Thursday, April 28, 2016 6:40 AM > To: python-list@python.org > Subject: Re: Controlling the passing of data > > Sayth Renshaw wrote: > > > In my file here I needed to traverse and modify the XML file I don't > > want to restore it or put it in a new variable or other format I just >
RE: online python courses
I've heard good things about codeacademy.com and learnpython.org. Also, I've heard that pycharm educational edition is helpful. (https://www.jetbrains.com/pycharm-edu/ ) I haven't personally tried any of these though, so your mileage may vary. Good Luck! Dan Strohl > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of ldompel...@casema.nl > Sent: Thursday, April 28, 2016 7:15 AM > To: python-list@python.org > Subject: online python courses > > I am follows on this moment two online pythoncourses from > code.tutsplus.com But I am interested in following more online > pythoncourses. > Maby someone have some links to websites for me what handles python > online courses. > > thanks > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Controlling the passing of data
If I am reading this correctly... you have something like (you will have to
excuse my lack of knowledge about what kinds of information these actually are):
1234
first
5678
second
And you want something like:
nominations = [(1,1234), (2,5678)]
meetings = [(1,'first'),(2,'second')]
if that is correct, my suggestion is to do something like (this is psudeo code,
I didn't look up the exact calls to use):
nomination_list = []
meeting_list = []
for race_element in xml_file('race'):
id = race_element.get_attr('id')
for nomination_element in race_element('nomination'):
nomination = nomination_element.get_text()
nomination_list.append((id, nomination))
for meeting_element in race_element('meeting'):
meeting = meeting_element.get_text()
meeting_list.append((id, meeting))
> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org]
> On Behalf Of Sayth Renshaw
> Sent: Thursday, April 28, 2016 7:00 AM
> To: python-list@python.org
> Subject: Re: Controlling the passing of data
>
>
> >
> > Your actual problem is drowned in too much source code. Can you
> > restate it in English, optionally with a few small snippets of Python?
> >
> > It is not even clear what the code you provide should accomplish once
> > it's running as desired.
> >
> > To give at least one code-related advice: You have a few repetitions
> > of the following structure
> >
> > > meetattrs = ('id', 'venue', 'date', 'rail', 'weather',
> > > 'trackcondition')
> >
> > > meet = d('meeting')
> >
> > > meetdata = [[meet.eq(i).attr(x)
> > > for x in meetattrs] for i in range(len(meet))]
> >
> > You should move the pieces into a function that works for meetings,
> > clubs, races, and so on. Finally (If I am repeating myself so be it):
> > the occurence of range(len(something)) in your code is a strong
> > indication that you are not using Python the way Guido intended it.
> > Iterate over the `something` directly whenever possible.
>
> Hi Peter
>
> > meetattrs = ('id', 'venue', 'date', 'rail', 'weather',
> > 'trackcondition')
>
> is created to define a list of attr in the XML rather than referencing each
> attr
> individually I create a list and pass it into
>
> > meetdata = [[meet.eq(i).attr(x)
> > > for x in meetattrs] for i in range(len(meet))]
>
> This list comprehension reads the XML attr by attr using meet = d('meeting')
> as the call to pyquery to locate the class in the XML and identify the attr's.
>
> I do apologise for the lack of output, I asked a question about parsing that I
> always seem to get wrong over think and then find the solution simpler than
> I thought.
>
> The output is 4 tables of the class and selected attributes eg meetattrs =
> ('id',
> 'venue', 'date', 'rail', 'weather', 'trackcondition') from the meeting class
> of the
> XML.
>
> In order to give flexibility and keep the relational nature they have defined
> in
> the table I found when exporting the nominations section via pandas to csv
> that i had no way to determine which id belonged to each race that is there
> was no race_id in the nominations to relate back to the race, and also no
> meeting id in the raceid to relate it back to the meeting.
>
>
> So I wanted to traverse all the classes Meeting, Race and Nomination and
> insert the id of the class into its direct children only and since there were
> many races a meeting and many nomnations a race I need to ensure that it is
> the direct children only.
>
> It was otherwise working as parsed output in code supplied using to push to
> pandas and use its csv write capability.
>
> So I inserted
>
> for race_el in d('race'):
> race = pq(race_el)
> race_id = race.attr('id')
>
> for nom_el in race.items('nomination'):
> res.append((pq(nom_el).attr('raceid', race_id)))
>
> which traverses and inserts the race_id into the child nominations. However,
> my boggles is how to pass this to the list comprehension that was working
> without changing the data from XML or creating another intermediate step
> and variable. Just to parse it as it was but with the extra included race_id.
>
>
> Thanks
>
> Sayth
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: What should Python apps do when asked to show help?
I would suggest using argparse https://docs.python.org/3/library/argparse.html as it handles all of that natively... including validating arguments, showing errors, help, etc... however, assuming you don't want to; Send it to stdout, that allows the user to redirect it if they want to (and plays better with other dev-ops tools) Don't run it through a pager, the user can do that if needed... HOWEVER - If you have enough help that you need to page it, consider moving much of it to application documentation (either hosted, or as a doc / txt file). The command line help should simply be enough hints to remember what the various parameters are, not a full explanation about what it can do (unless the app is really simple). - Alternatively, you can have a multi-level help approach where the user can type "app_name argument /help" and get more detailed information about that specific argument. > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of alister > Sent: Thursday, April 28, 2016 9:45 AM > To: python-list@python.org > Subject: Re: What should Python apps do when asked to show help? > > On Fri, 29 Apr 2016 02:33:56 +1000, Steven D'Aprano wrote: > > > I have an application written in Python which accepts -h or --help to > > show help. I can: > > > > (1) print the help text to stdout; > > > > (2) run the help text through a pager; > > > > (3) do something else? > > > > > > Many command line tools simply output help to stdout (or stderr, if > > they're evil), which makes it easy to redirect the help to a file, > > pass it to grep, etc. For example: > > > > [steve@ando ~]$ wget --help | wc -l 136 > > > > Other tools automatically launch a pager, e.g. man. (Admittedly, man > > --help does not use a pager.) The Python help system, pydoc, does the > > same. > > > > I was thinking that my application could use pydoc: > > > > def do_help(): > > import pydoc pydoc.pager(HELPTEXT) > > > > or just print the help text: > > > > def do_help(): > > # Do I really need to show this??? > > print(HELPTEXT) > > > > > > but I was thinking of doing both: give my application a subcommand or > > an option to display help directly in a pager, while -h and --help > > print to stdout as normal. > > > > What do you think? Too clever? > > Send it to stdout, this gives the user the most choice. > > if there is enough that I want it paged then I will pipe it to a pager. > > do one job, do it well and don't reinvent the wheel unnecessarily. > > > > -- > Nobody shot me. > -- Frank Gusenberg, his last words, when asked by police > who had shot him 14 times with a machine gun in the Saint > Valentine's Day Massacre. > > Only Capone kills like that. > -- George "Bugs" Moran, on the Saint Valentine's Day > Massacre > > The only man who kills like that is Bugs Moran. > -- Al Capone, on the Saint Valentine's Day Massacre > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: What should Python apps do when asked to show help?
Yeah, if I am handling arguments from the command line, I use argparse, if I am doing a cli based app (so, going back and forth in interacting with the command line), I would look at clint (https://github.com/kennethreitz/clint) As many people have said here, don’t reinvent the wheel. Dan From: John Wong [mailto:gokoproj...@gmail.com] Sent: Thursday, April 28, 2016 10:06 AM To: Dan Strohl Cc: alister ; python-list@python.org Subject: Re: What should Python apps do when asked to show help? On Thu, Apr 28, 2016 at 1:02 PM, Dan Strohl via Python-list mailto:python-list@python.org>> wrote: I would suggest using argparse https://docs.python.org/3/library/argparse.html as it handles all of that natively... including validating arguments, showing errors, help, etc... however, assuming you don't want to; Totally agree with this approach. Command line should stick with argparse. Personally I'd stick with argparse and not other open source projects which is built on argparse (or optparse, the one you don't want to use, but eh some people decided to do that anyway because of some limitations in argparse). In fact you shouldn't need to implement -h/--help when you use argparse. If a user is going to use the command line, you can almost always assume the user can use -h/--help, or for those familiar with Linux just provide a man page. After all, what you need is a very clear documentation upfront prior to the installation so your users can refer to that for ultimate help. -- https://mail.python.org/mailman/listinfo/python-list
RE: What should Python apps do when asked to show help?
I would hesitate to take this approach unless the tool was one that only I was going to be using, and I knew exactly what environments it was going to be in. I know that many of the system items in python work differently in different operating systems, and different os's report things differently as well as different ways of launching things. So, for example, I have seen cases where tools such as webmin will try to run a command line tool, and end up hung because they are waiting on a keypress for the next screen... While I might do it as a way of setting a default, I would still want to have the ability to force a pager, or force no pager. I've been bit too many times by programmers doing things automatically for me that I didn't want. I think that most people who use command line tools these days will be able to figure out how to pipe it to "more" if needed (or whatever). Dan > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of Irmen de Jong > Sent: Thursday, April 28, 2016 10:08 AM > To: python-list@python.org > Subject: Re: What should Python apps do when asked to show help? > > On 28-4-2016 18:33, Steven D'Aprano wrote: > > > > but I was thinking of doing both: give my application a subcommand or > > an option to display help directly in a pager, while -h and --help > > print to stdout as normal. > > > > What do you think? Too clever? > > An idea: Use just one help option, then > > if sys.stdout.isatty(): > #use a pager to display help text > else: > #print all help text normally > > > Irmen > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: What should Python apps do when asked to show help?
Yup.. another reason to use something like argparse... you define the argument descriptions, help, and when you raise an error, it automatically handles the output, sending it to the right place (stderr/stdout)... as well as allowing you to define different levels of verbosity easily... (or not if you don't want) Argparse isn't the best tool in the world, and there are some things that annoy me about it sometimes, but it works pretty well within its boundaries. (and if the code's already written, I'm not suggesting that it be re-written just to move it to a common library. > -Original Message- > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] > On Behalf Of Random832 > Sent: Thursday, April 28, 2016 10:30 AM > To: python-list@python.org > Subject: Re: What should Python apps do when asked to show help? > > On Thu, Apr 28, 2016, at 13:06, Chris Angelico wrote: > > On Fri, Apr 29, 2016 at 2:33 AM, Steven D'Aprano > > wrote: > > > Many command line tools simply output help to stdout (or stderr, if > > > they're evil), > > > > I'm not sure stderr is particularly more evil than stdout, but > > whatever > > :) > > When a tool has very long help and sends it to stderr: > > $ foo --help > ok, it's scrolled off the top, and I could just scroll up, but it's so long > I'll have to > search for what I want anyway. > $ foo --help | less > *help flashes on the screen, then blank ~~ screen from less* > #@!@#$#$!#$!@#$@#!$@!#$!@#$!@#$!@#$!@#$ > $ foo --help 2>&1 | less > > Basically the only reason this ever happens is that programmers get lazy and > use the same function for usage errors as for --help. A usage error message > *should* go to stderr (in order to show up if the program's output has been > redirected to null, and so as not to be silently piped to something that > expects the program's normal output), but it should be short. Help should go > to stdout because the user actually requested it. > > The obvious exception, and probably the bad example that people are > following, is programs that don't actually *have* --help, but briefly > summarize all their options and the meanings of positional arguments in the > usage error. People start with that, and then expand it to a full-blown GNU- > style --help message, but continue sending it to stderr. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Need help understanding list structure
Take a look at the docs for print() https://docs.python.org/3.5/library/functions.html#print str() https://docs.python.org/3.5/library/stdtypes.html#str repr() https://docs.python.org/3.5/library/functions.html#repr When you do "print(object)", python will run everything through str() and output it. Str() will try to return a string representation of the object, what actually comes back will depend on how the objects author defined it. If object.__str__() has been defined, it will use that, if __str__() is not defined, it will use object.__repr__(). If object.__repr__() has not been defined, it will something that looks like "object_name object at xxx". So, as to your specific questions / comments: > At the risk of coming across as a complete dunder-head, I think my confusion > has to do with the type of data the library returns in the list. Any kind of > text > or integer list I manually create, doesn't do this. Actually, they do, but strings and integers have well defined __str__ and __repr__ methods, and behave pretty well. So... think about what is actually being passed to the print() function in each case: > print(type(myList)) Passing the string object of the results of type(myList) > print(len(myList)) Passing the integer object returning from len(myList) > print(myList[0]) Passing the gedcom ELEMENT object found at location 0 in the list > print(myList[0:29]) Passing a list object created by copying the items from location 0 to location 29 in the original list > print(myList) Passing the entire list object > for x in myList: > print(x) Passing the individual gedcom ELEMENT objects from the list. So, in each of these cases, you are passing different types of objects, and each one (string, integer, list, gedcom) will behave differently depending on how it is coded. > Why does printing a single item print the actual text of the object? If you are printing a single item (print(myList[0]), you are printing the __str__ or __repr__ for the object stored at that location. > Why does printing a range print the "representations" of the objects? If you are printing a range of objects, you are printing the __str__ or __repr__ for the RANGE OBJECT or LIST object, not the object itself, which apparently only checks for a __repr__() method in the contained gedcom ELEMENT objects, which is not defined (see below). > Why does iterating over the list print the actual text of the objects? When iterating over the list, you are printing the specific items again (just like when you did print(myList[0]) ) > How can I determine what type of data is in the list? Try print(type(myList[0])), which will give you the type of data in the first object in the list (though, keep in mind that the object type could be different in each item in the list). If we look at the gedcom library (assuming you are talking about this one: https://github.com/madprime/python-gedcom/blob/master/gedcom/__init__.py) at the end of the file you can see they defined __str__() in the ELEMENT object, but there is no definition for __repr__(), which matches what we surmised above. If you want to fix it by editing the gedcom library, you could simply add a line at the end like: __repr__() = __str__() Hope that helps. Dan Strohl -- https://mail.python.org/mailman/listinfo/python-list
RE: Need help understanding list structure
> I added a __repr__ method at the end of the gedcom library like so: > > def __repr__(self): > """ Format this element as its original string """ > result = repr(self.level()) > if self.pointer() != "": > result += ' ' + self.pointer() > result += ' ' + self.tag() > if self.value() != "": > result += ' ' + self.value() > return result > > and now I can print myList properly. > > Eric and Michael also mentioned repr above, but I guess I needed someone > to spell it out for me. Thanks for taking the time to put it in terms an old > dog > could understand. > Glad to help! (being an old dog myself, I know the feeling!) One other point for you, if your "__repr__(self)" code is the same as the "__str__(self)" code (which it looks like it is, at a glance at least), you can instead reference the __str__ method and save having a duplicate code block... some examples: = Option 1: This is the easiest to read (IMHO) and allows for the possibility that str() is doing something here like formatting or whatever. (in this case it shouldn't be though). However, to call this actually is taking multiple steps (calling object.__repr__, whch calls str(), which calls object.__str__(). ) def __repr__(self): return str(self) = Option 2: this isn't hard to read, and just takes two steps (calling object.__repr__(), which calls object.__str__(). def __repr__(self): return self.__str__() Option 3: it's not that this is hard to read, but since it doesn't follow the standard "def blah(self):" pattern, sometimes I overlook these in the code (even when I put them there). This however is the shortest since it really just tells the object to return object.__str__() if either object.__repr__() OR object.__str__() is called. __repr__ = __str__ This probably doesn't matter much in this case, since it probably isn't called that much in normal use (though there are always exceptions), and in the end, Python is fast enough that unless you really need to slice off a few milliseconds, you will never notice the difference, but just some food for thought. -- https://mail.python.org/mailman/listinfo/python-list
RE: Use __repr__ to show the programmer's representation (was: Need help understanding list structure)
> > One other point for you, if your "__repr__(self)" code is the same as > > the "__str__(self)" code (which it looks like it is, at a glance at > > least), you can instead reference the __str__ method and save having a > > duplicate code block... > > Alternatively, consider: the ‘__repr__’ method is intended to return a > *programmer's* representation of the object. Commonly, this is text which > looks like the Python expression which would create an equal > instance:: Definitely true per what _repr__ is supposed to do per python docs. However, in this case, that might not have solved the problem if the goal was to return the same as a __str__. (Though to be fair, I don’t really know what the actual problem was, so I might provide a different approach with a different goal ). I also have never actually used repr() to create code that could be fed back to the interpreter (not saying it isn’t done, just that I haven’t run into needing it), and there are so many of the libraries that do not return a usable repr string that I would hesitate to even try it outside of a very narrow use case. Personally, I normally use __repr__ to give me a useful troubleshooting representation of the object... but that representation might not be exactly the same as what would recreate the object since I might show information that is dynamic to the current state (like, the name of the parent instead of just a pointer or something). I know that isn’t per the rules, but in the end, it makes it easier for me to troubleshoot the code. Having said that, Ben is totally correct in terms of the "right" way to do it, my earlier suggestion was not "right". Dan -- https://mail.python.org/mailman/listinfo/python-list
RE: Wanted Python programmer to join team
> My team is getting more projects that it can handle so we are looking for > Python programers to join. You will be given tasks to complete full or part of > the project. > > Skype: piefektas > > Contact me now with short description about yourself, your skills and > projects you have worked on. > Sorry... nope. You lost me with using an email address like "netcrime4" and using "gmail" as your address. As a suggestion next time, try using a more professional address, such as one for a company, and one that does not suggest that the work might not be totally legit. (NOTE: I am NOT saying you aren’t legit, nor that the work is criminal, just that the impression you gave was less than professional, and even if I was looking, I would not consider contacting someone who presented that way.) -- https://mail.python.org/mailman/listinfo/python-list
RE: reduction
> My problem. I have lists of substrings associated to values: > > ['a','b','c','g'] => 1 > ['a','b','c','h'] => 1 > ['a','b','c','i'] => 1 > ['a','b','c','j'] => 1 > ['a','b','c','k'] => 1 > ['a','b','c','l'] => 0 # <- Black sheep!!! > ['a','b','c','m'] => 1 > ['a','b','c','n'] => 1 > ['a','b','c','o'] => 1 > ['a','b','c','p'] => 1 > > I can check a bit of data against elements in this list and determine whether > the value to be associated to the data is 1 or 0. > > I would like to make my matching algorithm smarter so I can reduce the total > number of lists: > > ['a','b','c','l'] => 0 # If "l" is in my data I have a zero > ['a','b','c'] => 1 # or a more generic match will do the job > > I am trying to think of a way to perform this "reduction", but I have a > feeling I > am reinventing the wheel. > Well, you are right about it being vague . Ultimately, this would depend on knowing more about what you are trying to achieve and what types of data you are actually using, as well as what the ranges of potential values are. So, for your simple example, I would do exactly what you suggested (check for the "l" and call it zero, otherwise check for the prefix and call it one. but, if there are lots of potential different black sheep, and/or other potential answers, this would get complex pretty quickly. Ian Kelly noted using a trie structure, allowing searching by prefix's, that could make sense if your lists always differ at the end as in your example, but might not make sense if the data is more random. There are lots of searching, sorting, and organizing modules and data structures out there, but without a bit more info, I am not sure that any response is going to be better than any other. Some things to consider are, - what is predictable, and what is not... and how do you determine the value from the predictable parts. (your example was very predictable; hence it was very easy) - how is the determination handled? (Math? String matching?) (if the method of determining it can be handled with math, you may be able to craft a formula to figure it out faster) - how many of each object type are you looking at? (if you are comparing < 100 objects, sometimes brute force is much easier anyway, if > 1,000,000, using a database or other method may be required) And some options to look at: - trie structure (as Ian noted) (good if the data varies based on how "deep" in the tree you are.) - regex search/match (good for more text based comparisons than you "seem" to be suggesting) - build a custom class that has the intelligence to determine the value for each object itself. (good for more complex issues, but probably increases the size of each object) - create an index or caching structure of some sort as you find the objects, (good for saving computation time if the determination is "hard" and you hit the same ones again and again) - create a dictionary structure instead of a list. (good for fast lookups with known data) - using something like pandas or another data analysis library (SciPy, NumPy, iPython Notebook). (especially good if your data is more numbers based than you seem to be indicating) - writing the data to a database and using that for matching. (good If you have LOTS of data to compare). Some of these are probably overkill, some probably won't work at all for what you are trying to achieve. Dan -- https://mail.python.org/mailman/listinfo/python-list
RE: Encapsulation in Python
> I've been studying Object Oriented Theory using Java. Theoretically, all
> attributes should be private, meaning no one except the methods itself can
> access the attribute;
>
> public class Foo {
> private int bar;
> ...
Why? I mean sure, lots of them should be, but if I am doing something like:
class person:
age = 21
name = 'Cool Dude'
And if I am not doing anything with the information, why make it private... I
am only going to crete a getter/setter that directly accesses it anyway.
Sure, if I think I am going to do something with it later, I will often "hide"
it using one method or another...
class person():
_name = ('Cool','Dude')
def fname(self):
return self._name[0]
>
> Normally in Java, we would write getters and setters to set/get the attribute
> bar. However, in Python, we normally create a class like so;
>
> class Foo(object):
> bar = 0
> ...
>
> And we usually don't write any getters/setters (though they exist in Python, I
> have not seen much projects making use of it).
>
Lots of projects do use these, but mostly (in my experience) these are
libraries that are designed to provide easy to use classes / methods to
developers so that they don’t have to figure things out. Implementing
getters/setters is more complex and takes more code (and is more to
troubleshoot / go wrong). So, if you don’t need it, why not stick with
something simple?
> We can easily encapsulate (data hiding) Foo's class using the '_'
> (underscore) when creating a new attribute, however, this would require all
> attributes to have a underscore.
Keep in mind that this doesn’t really hide the data, I can still access it
(foo._bar = 0), even using the double underscore doesn’t actually "hide" the
data, it just makes it harder to accidently override in instances. The
underscore is simply a convention that most people choose to use to suggest
that _this is an internal var and should be used with caution.
> According to this answer [1], it's acceptable to to expose your attribute
> directly (Foo.bar = 0), so I wonder where the encapsulation happens in
> Python? If I can access the attribute whenever I want (with the except of
> using a underscore), what's the best way to encapsulate a class in Python?
Encapsulation can happen if the developer wants it by using any of a number of
approaches (__getattr__/__setattr__, __getattribute__, __get__/__set__,
property(), @property, etc...), python allows the developer to define where it
makes sense to use it, and where not to.
> Why aren't most of the projects not using getters/setters and instead they
> access the variable directly?
I don’t know about "most" projects... but getters/setters (in one form or
another) are used often in lots of projects... but like I mentioned above, if
the project doesn’t need to encapsulate the info, why do it? (keep in mind
that I can always rewrite the class and add encapsulation later if I need to).
One note here, be careful of getting too caught up in using any single language
(no matter which one) to define Object Oriented Theory, each approaches it in
its own way, and each has its own benefits and challenges. This is a perfectly
valid question (and a good one), but don’t let yourself get into the trap of
feeling that Java is the definitive/best/only approach to OO (or Python for
that matter, or C++, or whatever!).
Dan Strohl
>
> Regards,
>
> Ben Mezger
>
> [1] - http://stackoverflow.com/q/4555932
--
https://mail.python.org/mailman/listinfo/python-list
RE: Replace weird error message?
Actually, I think that was the complete code... give it a try...
"{:02}".format("1")
produces the error listed.
I agree the error is not very clear, since the "=" was not passed, it seems
like an incorrect error. What about something like:
"ValueError: '=' and '0' padding are not allowed in string format specifiers"
> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org]
> On Behalf Of Joel Goldstick
> Sent: Wednesday, March 16, 2016 11:39 AM
> Cc: python-list@python.org
> Subject: Re: Replace weird error message?
>
> can you show the complete code? It doesn't start with "{:02} I don't think
>
> On Wed, Mar 16, 2016 at 2:34 PM, the.gerenuk--- via Python-list < python-
> l...@python.org> wrote:
>
> > The following error message, makes it a bit hard to understand what
> > went wrong
> >
> > >>> "{:02}".format("1")
> > Traceback (most recent call last):
> > File "", line 1, in
> > ValueError: '=' alignment not allowed in string format specifier
> >
> > (this can happen easily if you read in text files and forget to
> > convert)
> >
> > Do you think some better error message should be used?
> >
> > For example a hint that "0" does work for the given argument.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
>
>
>
> --
> Joel Goldstick
> http://joelgoldstick.com/
> http://cc-baseballstats.info/
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Users of namedtuple: do you use the _source attribute?
I have never used it personally. It always looked interesting, but I never ran
into a need to generate the source for it.
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Steve D'Aprano
Sent: Monday, July 17, 2017 9:58 AM
To: python-list@python.org
Subject: Users of namedtuple: do you use the _source attribute?
collections.namedtuple generates a new class using exec, and records the source
code for the class as a _source attribute.
Although it has a leading underscore, it is actually a public attribute. The
leading underscore distinguishes it from a named field potentially called
"source", e.g. namedtuple("klass", ['source', 'destination']).
There is some discussion on Python-Dev about:
- changing the way the namedtuple class is generated which may
change the _source attribute
- or even dropping it altogether
in order to speed up namedtuple and reduce Python's startup time.
Is there anyone here who uses the namedtuple _source attribute?
My own tests suggest that changing from the current implementation to one
similar to this recipe here:
https://code.activestate.com/recipes/578918-yet-another-namedtuple/
which only uses exec to generate the __new__ method, not the entire class, has
the potential to speed up namedtuple by a factor of four.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
RE: Best way to assert unit test cases with many conditions
Ganesh;
I'm not 100% sure what you are trying to do.. so let me throw out a few things
I do and see if that helps...
If you are trying to run a bunch of similar tests on something, changing only
(or mostly) in the parameters passed, you can use self.subTest().
Like this:
Def test_this(self):
For i in range(10):
with self.subTest('test number %s) % i):
self.assertTrue(I <= 5)
With the subTest() method, if anything within that subTest fails, it won't stop
the process and will continue with the next step.
If you are trying to run a single test at the end of your run to see if
something messed something up (say, corrupted a file or something), you can,
(at least with the default unittest) name your test something like
test_zzz_do_this_at_end, and unless you have over-ridden how the tests are
being handled (or are using a different testing environment), unittest should
run it last (of the ones in that TestCase class).
From: https://docs.python.org/2/library/unittest.html#organizing-test-code
"Note that the order in which the various test cases will be run is determined
by sorting the test function names with respect to the built-in ordering for
strings."
--
https://mail.python.org/mailman/listinfo/python-list
