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:[email protected]] On
Behalf Of Devin Jeanpierre
Sent: Tuesday, January 03, 2017 12:57 PM
To: [email protected]
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:[email protected]] 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:[email protected]] On
Behalf Of Devin Jeanpierre
Sent: Tuesday, January 03, 2017 12:57 PM To: [email protected]
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:[email protected]] 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 ; [email protected] > Subject: RE: syntax difference (type hints) > > EXTERNAL MAIL: [email protected] > > 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: [email protected] > Subject: __init__ patterns > > EXTERNAL MAIL: [email protected] > > 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:[email protected]] > On Behalf Of [email protected] > Sent: Thursday, April 14, 2016 1:50 PM > To: [email protected] > 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:[email protected]] > On Behalf Of durgadevi1 > Sent: Friday, April 15, 2016 5:13 AM > To: [email protected] > 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:[email protected]] > On Behalf Of Peter Otten > Sent: Thursday, April 28, 2016 6:40 AM > To: [email protected] > 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 > > want to alter it and let it flow onto the list comprehensions as they were. > > That looks like an arbitrary limitation to me. It's a bit like "I want to > repair m
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:[email protected]] > On Behalf Of [email protected] > Sent: Thursday, April 28, 2016 7:15 AM > To: [email protected] > 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:[email protected]]
> On Behalf Of Sayth Renshaw
> Sent: Thursday, April 28, 2016 7:00 AM
> To: [email protected]
> 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:[email protected]] > On Behalf Of alister > Sent: Thursday, April 28, 2016 9:45 AM > To: [email protected] > 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:[email protected]] Sent: Thursday, April 28, 2016 10:06 AM To: Dan Strohl Cc: alister ; [email protected] 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:[email protected]>> 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:[email protected]] > On Behalf Of Irmen de Jong > Sent: Thursday, April 28, 2016 10:08 AM > To: [email protected] > 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:[email protected]] > On Behalf Of Random832 > Sent: Thursday, April 28, 2016 10:30 AM > To: [email protected] > 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:[email protected]]
> On Behalf Of Joel Goldstick
> Sent: Wednesday, March 16, 2016 11:39 AM
> Cc: [email protected]
> 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-
> [email protected]> 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:[email protected]] On Behalf Of Steve D'Aprano Sent: Monday, July 17, 2017 9:58 AM To: [email protected] 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
