Re: What should Python apps do when asked to show help?
On Fri, 29 Apr 2016 03:00 pm, Rustom Mody wafted information-rich pheromones into the air, where they diffused rapidly: > Quite bewildered by this thread... > Are we in 2016? > [Reminds me of the bizarre claim that world has not moved on from text] (For the benefit of those of us still stuck in the 2000s, I have transcribed Rustom's pheromones into the obsolete medium of text.) > eg I am on on Ubuntu 16.4 (vanilla) right now. > This means that when I pull up a terminal I get gnome-terminal. > Which means that when the screen fills up I get a scroll bar Yes. So do I. Of course, some applications (like screen) interfere with that, but even when you have a scroll bar, having to scroll back more than a few pages is a PITA. If you set the number of scrollback lines too low, you run out and the things you are interested in disappears past the top... and if you set it too high, it's too hard to locate the section that you actually want. The bottom line is, screen real estate is a valuable resource, but even more valuable is human attention, and pagers are a way of managing attention. Screen space is not necessary rare, but neither is it something that we can just consume thoughtlessly. Hence we have a whole range of options available to us, to make the most of screen space: - multiple windows; - multiple tabs within each window; - scroll bars within each tab; - and pagers. Think of a pager as being somewhat like a popup window for text: at the very low cost of a single line of space in your terminal, you can "pop up" the text, read it, and dismiss it again without using up any of the screen space in your scrolling text view. (Apart from that one line.) > IOW pager functionality is quite builtin in shells nowadays Apart from those where they're not. > Why replicate and cause annoyance? If you don't want to use the functionality, don't. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
def __init__(self,cls):
Dear Group, Please explain the following in details. " def __init__(self,cls): self.cls = cls " Thanks in Advance. San -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Friday, April 29, 2016 at 3:07:09 PM UTC+5:30, Steven D'Aprano wrote: > On Fri, 29 Apr 2016 03:00 pm, Rustom Mody wafted information-rich pheromones > into the air, where they diffused rapidly: > > Why replicate and cause annoyance? > > If you don't want to use the functionality, don't. You asked about calling up pagers!! JFTR I find git behavior annoying -- as it seems do others -- but Ive figured getting round it by calling it with -w (show in web browser) is ok (with me) With python's help I find it annoying and Ive not figured out how to not get paging -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic style
On Fri, 29 Apr 2016 10:48 am, Gregory Ewing wrote: > MRAB wrote: > >> Is it worthy of being in the Zen of Python? > > +1. Maybe something along the lines of: > > Dunder methods are for defining, not calling. > Unless you're a dunderhead[1]. > > [1] Meant in the sense of an enthusiast, cf. gearhead. I think that the advice to not call dundermethods directly is excellent advice, but it doesn't belong in the Zen. Look at the Zen: it's all pretty abstract: Beautiful is better than ugly. Explicit is better than implicit. etc. There's very little[1] concrete advice in the way of specificities such as: - don't use floats for money; - use namedtuple for the equivalent of a C struct or Pascal record; - composition should be preferred over inheritance; etc. "Don't use dunders" is much closer to the second, more specific type of advice which doesn't really fall into the Zen's bailiwick. Better suited for the Zen would be: "Not everything needs to be a one-liner." which is nicely abstract and also completely useless for deciding which things should and shouldn't be, as good koans ought to be. [1] By which I mean none. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does pathlib not have is_readable() & things like that?
On 2016-04-28, Grant Edwards wrote:
> On 2016-04-28, Adam Funk wrote:
>> On 2016-04-26, Random832 wrote:
>>
>>> On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote:
I recently discovered pathlib in the Python 3 standard library, & find
it very useful, but I'm a bit surprised that it doesn't offer things
like is_readable() and is_writable. Is there a good reason for that?
>>>
>>> Well, one reason would be EAFP. Just try to open the file and see if it
>>> gives you a PermissionError.
>>
>> I understand that in general, but the tool I'm working on here takes a
>> command-line option to specify an output directory, & I'd rather not
>> start processing the data (which involves GETting from a REST service,
>> processing, and PUTting back modifications to the data) only to crash
>> after the first batch because of a user error.
>
> Then open the output file before you do the GET.
I guess I could, but fetching the data actually involves a whole lot
of GET requests (the first one includes cross-references to the URLs
where the rest of the data is found), some BeautifulSoup processing, &
a lot of other processing to produce a big dict, which I then write
out as json using what I think is the best way (output_file is an
instance of pathlib.Path):
with output_file.open(mode='w', encoding='UTF-8', errors='replace') as f:
json.dump(output, f, sort_keys=True, indent=2)
> Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK)
That's what I'm doing now, but I prefer to give the user the error
message early on.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Controlling the passing of data
Sayth Renshaw wrote:
>
>>
>> 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.
You misunderstood me. I do understand what your code does, I just have no
idea what you want to do, in terms of the domain, like e. g.
"Print horses with the last three races they took part in."
Why does this matter? Here's an extreme example:
bars = []
for foo in whatever:
bars.append(foo.baz)
What does this do? The description
"It puts all baz attributes of the items in whatever into a list"
doesn't help. If you say "I want to make a list of all brands in the car
park I could recommend a change to
brand = set(car.brand for car in car_park)
because a set avoids duplicates. If you say "I want to document my
achievements for posterity" I would recommend that you print to a file
rather than append to a list and the original code could be changed to
with open("somefile") as f:
for achievement in my_achievements:
print(achievement.description, file=f)
Back to my coding hint: Don't repeat yourself. If you move the pieces
>> > 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))]
into a function
def extract_attrs(nodes, attrs):
return [[nodes.eq(i).attr(name) for name in attrs]
for i in range(len(nodes))]
You can reuse it for clubs, races, etc.:
meetdata = extract_attrs(d("meeting"), meetattrs)
racedata = extract_attrs(d("race"), raceattrs)
If you put the parts into a dict you can generalize even further:
tables = {
"meeting": ([], meetattrs),
"race": ([], raceattrs),
}
for name, (data, attrs) in tables.items():
data.extend(extract_attrs(d(name), attrs))
>
> 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.
So you want to go from a tree structure to a set of tables that preserves
the structure by adding foreign keys. You could try a slightly different
approach, so
Re: Controlling the passing of data
Sayth Renshaw wrote:
>
>>
>> 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.
You misunderstood me. I do understand what your code does, I just have no
idea what you want to do, in terms of the domain, like e. g.
"Print horses with the last three races they took part in."
Why does this matter? Here's an extreme example:
bars = []
for foo in whatever:
bars.append(foo.baz)
What does this do? The description
"It puts all baz attributes of the items in whatever into a list"
doesn't help. If you say "I want to make a list of all brands in the car
park I could recommend a change to
brand = set(car.brand for car in car_park)
because a set avoids duplicates. If you say "I want to document my
achievements for posterity" I would recommend that you print to a file
rather than append to a list and the original code could be changed to
with open("somefile") as f:
for achievement in my_achievements:
print(achievement.description, file=f)
Back to my coding hint: Don't repeat yourself. If you move the pieces
>> > 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))]
into a function
def extract_attrs(nodes, attrs):
return [[nodes.eq(i).attr(name) for name in attrs]
for i in range(len(nodes))]
You can reuse it for clubs, races, etc.:
meetdata = extract_attrs(d("meeting"), meetattrs)
racedata = extract_attrs(d("race"), raceattrs)
If you put the parts into a dict you can generalize even further:
tables = {
"meeting": ([], meetattrs),
"race": ([], raceattrs),
}
for name, (data, attrs) in tables.items():
data.extend(extract_attrs(d(name), attrs))
>
> 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.
So you want to go from a tree structure to a set of tables and preserve the
structural information:
for meeting in meetings
meeting_table.append(...m
Re: Why does pathlib not have is_readable() & things like that?
Adam Funk writes:
> On 2016-04-28, Grant Edwards wrote:
>>
>> Then open the output file before you do the GET.
>
> I guess I could, but fetching the data actually involves a whole lot
> of GET requests (the first one includes cross-references to the URLs
> where the rest of the data is found), some BeautifulSoup processing, &
> a lot of other processing to produce a big dict, which I then write
> out as json using what I think is the best way (output_file is an
> instance of pathlib.Path):
>
> with output_file.open(mode='w', encoding='UTF-8', errors='replace') as f:
> json.dump(output, f, sort_keys=True, indent=2)
It doesn't matter how much work it actually is. Make it conceptually a
single unit:
def get_output(): ...
with output_file.open(mode='w',
encoding='UTF-8',
errors='replace') as f:
output = get_output()
json.dump(output, f,
sort_keys=True,
indent=2)
>> Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK)
>
> That's what I'm doing now, but I prefer to give the user the error
> message early on.
Then do that early on.
--
https://mail.python.org/mailman/listinfo/python-list
Re: def __init__(self,cls):
> On 2016-04-29, at 11:47, San wrote: > > Dear Group, please explain the following in details. Thanks in Advance. > > def __init__(self,cls): >self.cls = cls Is this homework? Why don't you explain it first in your own words, then let us comment on it? Greetings, -- https://mail.python.org/mailman/listinfo/python-list
Re: Controlling the passing of data
> because a set avoids duplicates. If you say "I want to document my
> achievements for posterity" I would recommend that you print to a file
> rather than append to a list and the original code could be changed to
>
> with open("somefile") as f:
> for achievement in my_achievements:
> print(achievement.description, file=f)
>
>
> Back to my coding hint: Don't repeat yourself. If you move the pieces
>
> >> > 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))]
>
> into a function
>
> def extract_attrs(nodes, attrs):
> return [[nodes.eq(i).attr(name) for name in attrs]
> for i in range(len(nodes))]
>
> You can reuse it for clubs, races, etc.:
>
> meetdata = extract_attrs(d("meeting"), meetattrs)
> racedata = extract_attrs(d("race"), raceattrs)
>
> If you put the parts into a dict you can generalize even further:
>
> tables = {
>"meeting": ([], meetattrs),
>"race": ([], raceattrs),
> }
> for name, (data, attrs) in tables.items():
> data.extend(extract_attrs(d(name), attrs))
>
I find that really cool. Reads well to, hadn't considered approaching it that
way at all.
> So you want to go from a tree structure to a set of tables that preserves
> the structure by adding foreign keys. You could try a slightly different
> approach, something like
>
> for meeting in meetings:
> meeting_table.append(...meeting attrs...)
> meeting_id = ...
> for race in meeting:
> race_table.append(meeting_id, ...meeting attrs...)
> race_id = ...
> for nomination in race:
> nomination_table.append(race_id, ...nomination attrs...)
>
> I don't know how to spell this in PyQuery -- with lxml you could do
> something like
>
> meeting_table = []
> race_table = []
> nomination_table = []
> tree = lxml.etree.parse(filename)
> for meeting in tree.xpath("/meeting"):
> meeting_table.append([meeting.attrib[name] for name in meetattrs])
> meeting_id = meeting.attrib["id"]
> for race in meeting.xpath("./race"):
> race_table.append(
> [meeting_id] + [race.attrib[name] for name in raceattrs])
> race_id = race.attrib["id"]
> for nomination in race.xpath("./nomination"):
> nomination_table.append(
> [race_id]
> + [nomination.attrib[name] for name in horseattrs])
>
> Not as clean and not as general as I would hope -- basically I'm neglecting
> my recommendation from above -- but if it works for you I might take a
> second look later.
I need to play around with this just to understand it more, really like it.
Might try and implement your advice from before and put it in a function.
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
Hello, >What is a good place where I can find out more about writing >manpage? I don't know of a single place where manpage authorship is particularly documented. This seems to be one of the common target links. In addition to introducing the breakdown of manpages by type (section) and providing some suggestions for content, it introduces the *roff markup: http://www.schweikhardt.net/man_page_howto.html It's been many years since I have written that stuff directly. I prefer one of the lightweight, general documentation or markup languages. So, below, I'll mention and give examples for creating manpages from reStructuredtext, AsciiDoc and Plain Old Documentation. With the reStructuredText format [0] [1], you can convert an .rst file to a manpage using two different document processors; you can use sphinx-build from the sphinx-project [2] or rst2man from the docutils project. The outputs are largely the same (as far as I can tell). There's also the AsciiDoc [3] format, which is a near to text and reads like text, but has a clear structure. With the tooling (written in Python), you can produce docbook, latex, html and a bunch of other output formats. Oh, and manpages [4], too. There is a tool called 'asciidoc' which processes AsciiDoc formats into a variety of backend formats. The 'a2x' tool converts AsciiDoc sources into some other (x) desired output. If you don't like .rst or AsciiDoc, there's also the Plain Old Documentation (POD) format. This is the oldest tool (of which I'm aware) which other than the direct *roff processing tools. You run 'pod2man' (written in Perl) on your .pod file. POD is another dead simple documentation language, supported by the pod2man [5] tool. For more on the format, read also 'man 1 perlpod'. sphinx-build: the sphinx documentation system is geared for handling project-scoped documentation and provides many additional features to reStructuredText. It can produce all kinds of output formats, HTML single-page, help, multipage, texinfo, latex, text, epub and oh, yeah, manpages. It's a rich set of tools. If you wish to use sphinx, I can give you an example .rst file [6] which I recently wrote and the following instructions for how to process this with sphinx. When processing docs with sphinx, a 'conf.py' file is required. It can be generated with an ancillary tool from the sphinx suite: I know that I always find an example helpful. So, here are some examples to help you launch. mkdir sampledir && cd sampledir sphinx-quickstart # -- and answer a bunch of questions # -- examine conf.py and adjust to your heart's content #confirm that master_doc is your single document for a manpage #confirm that there's an entry for your document in man_pages sphinx-build -b man -d _build/doctrees . _build/man # -- or grab the files from my recent project [6] and try yourself rst2man: even more simply, if you don't need the kitchen sink... wget https://gitlab.com/pdftools/pdfposter/raw/develop/pdfposter.rst rst2man < pdfposter.rst > pdfposter.1 # -- will complain about this, but still produces a manpage # :10: (ERROR/3) Undefined substitution referenced: "VERSION". man ./pdfposter.1 asciidoc (a randomly selected example asciidoc file [7]): wget https://raw.githubusercontent.com/DavidGamba/grepp/master/grepp.adoc a2x -f manpage grepp.adoc man ./grepp.1 perlpod: wget https://api.metacpan.org/source/RJBS/perl-5.18.1/pod/perlrun.pod pod2man --section 1 < perlrun.pod > perlrun.1 man ./perlrun.1 I know there are other tools for generating manpages; the original *roff tools, visual manpage editors, DocBook, help2man, manpage generators from argparse.ArgumentParser instances, And, of course, make sure to use version control for your documentation. These git manpages may be helpful for the uninitiated (joke, joke): https://git-man-page-generator.lokaltog.net/ # -- humour! Good luck, -Martin [0] http://docutils.sourceforge.net/docs/user/rst/quickref.html [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html [2] http://www.sphinx-doc.org/en/stable/rest.html [3] http://www.methods.co.nz/asciidoc/ [4] http://www.methods.co.nz/asciidoc/chunked/ch24.html [5] http://perldoc.perl.org/pod2man.html [6] https://raw.githubusercontent.com/tLDP/python-tldp/master/docs/ldptool-man.rst [7] https://raw.githubusercontent.com/DavidGamba/grepp/master/grepp.adoc -- Martin A. Brown http://linux-ip.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
Wow. Thank you for that very informative post! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does pathlib not have is_readable() & things like that?
On Fri, Apr 29, 2016 at 6:51 AM, Jussi Piitulainen
wrote:
> Adam Funk writes:
>> On 2016-04-28, Grant Edwards wrote:
>
>>> Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK)
>>
>> That's what I'm doing now, but I prefer to give the user the error
>> message early on.
>
> Then do that early on.
Note that on Windows os.access only checks if a file is read-only.
There's a proposed update to check the file security. The patch needs
to be updated and needs to be reworked, but it's a low priority. For
the most part calling os.access isn't recommended.
--
https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
On Friday, April 29, 2016 at 7:35:55 PM UTC+5:30, Ethan Furman wrote: > Wow. Thank you for that very informative post! > > -- > ~Ethan~ For emacs junkies there is also org-e-man [1] http://orgmode.org/worg/org-tutorials/org-e-man-documentation.html [2] https://github.com/tkf/org-mode/blob/master/contrib/lisp/org-e-man.el [No I havent used this but I use org mode heavily] -- https://mail.python.org/mailman/listinfo/python-list
Re: Query regarding python 2.7.11 release
>From searching bugs.python.org, I see that issues referencing CVE-2014-7185, CVE-2013-1752, and CVE-2014-1912 have all been marked as closed. I don't see any issues referencing CVE-2014-4650 via Python's bug tracker, but did spot it on Red Hat's. It appears to be related to issue 21766 ( http://bugs.python.org/issue21766) which has been marked closed, fixed. So, yes, looks like they're all fixed. On Thu, Apr 14, 2016 at 3:26 AM Gaurav Rastogi -X (garastog - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco) wrote: > Hi, > > We are currently using Python 2.6.7 in our product. > We have received below vulnerabilities from field: > > CVE-2014-7185 > > Integer overflow in bufferobject.c in Python before 2.7.8 allows > context-dependent attackers to > obtain sensitive information from process memory via a large size and > offset in a "buffer" function. > > CVE-2013-1752 > > python: multiple unbound readline() DoS flaws in python stdlib > > CVE-2014-1912 > > python: buffer overflow in socket.recvfrom_into() > > CVE-2014-4650 > > It was discovered that the CGIHTTPServer module incorrectly handled URL > encoded paths. > A remote attacker could use this flaw to execute scripts outside of the > cgi-bin directory, or disclose source of scripts in the cgi-bin directory > > > Currently I can see the 2.7.11 is the latest release as per the below link: > https://www.python.org/downloads/ > > Could you please suggest if the above mentioned vulnerabilities are > resolved in the latest release? > > Regards > Gaurav > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
How to download a flash video from this site?
Hi, I am looking for a way to download a flash video from the page: https://hrti.hrt.hr/#/video/show/2203605/trebizat-prica-o-jednoj-vodi-i-jednom-narodu-dokumentarni-film The html code bellow the page is fairly simple, but I can't figure out how to get the file. In case somebody have an idea, you can login to the site with: Username: [email protected] Password: public Regards. -- https://mail.python.org/mailman/listinfo/python-list
Compiling extensions on Python 2.7, Windows 10 64 bit
Dear list, I have been trying to compile wxPython Phoenix (https://github.com/wxWidgets/Phoenix) from source on Windows 10 64 bit, Python 2.7 64 bit, using the very handy Microsoft Visual C++ Compiler for Python 2.7 (https://www.microsoft.com/en-us/download/details.aspx?id=44266). I started with Python 2.7.8, then wiped out that installation and used Python 2.7.11: cleaned the build directory, everything, and rebuilt the Phoenix modules from scratch. Upon starting the Phoenix demo, I got the same error message I had with Python 2.7.8: D:\MyProjects\Phoenix\demo>python Main.py Traceback (most recent call last): File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 1955, in Notify self.notify() File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 3034, in Notify self.result = self.callable(*self.args, **self.kwargs) File "Main.py", line 2601, in ShowMain frame = wxPythonDemo(None, "wxPython: (A Demonstration)") File "Main.py", line 1531, in __init__ self.SetOverview(self.overviewText, mainOverview) File "Main.py", line 2130, in SetOverview self.nb.SetPageText(0, os.path.split(name)[1]) SystemError: ..\Objects\longobject.c:998: bad argument to internal function The error message refers (apparently) to this Python bug: https://bugs.python.org/issue23842 But I assumed that it had been fixed way before 2.7.11. Now I am stuck and I have no idea on what to try next. Does anyone have suggestions/comments on where I should look for/what I should do/what I should change in order to get the extension running on Python 2.7? Thank you in advance for your suggestions :-) . Andrea. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling extensions on Python 2.7, Windows 10 64 bit
Andrea, On Fri, Apr 29, 2016 at 3:45 PM, wrote: > Dear list, > > I have been trying to compile wxPython Phoenix > (https://github.com/wxWidgets/Phoenix) from source on Windows 10 64 bit, > Python 2.7 64 bit, using the very handy Microsoft Visual C++ Compiler for > Python 2.7 (https://www.microsoft.com/en-us/download/details.aspx?id=44266). > > I started with Python 2.7.8, then wiped out that installation and used Python > 2.7.11: cleaned the build directory, everything, and rebuilt the Phoenix > modules from scratch. > > Upon starting the Phoenix demo, I got the same error message I had with > Python 2.7.8: > > D:\MyProjects\Phoenix\demo>python Main.py > > Traceback (most recent call last): > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 1955, in > Notify > self.notify() > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 3034, in > Notify > self.result = self.callable(*self.args, **self.kwargs) > File "Main.py", line 2601, in ShowMain > frame = wxPythonDemo(None, "wxPython: (A Demonstration)") > File "Main.py", line 1531, in __init__ > self.SetOverview(self.overviewText, mainOverview) > File "Main.py", line 2130, in SetOverview > self.nb.SetPageText(0, os.path.split(name)[1]) > SystemError: ..\Objects\longobject.c:998: bad argument to internal function > > The error message refers (apparently) to this Python bug: > > https://bugs.python.org/issue23842 > > But I assumed that it had been fixed way before 2.7.11. Now I am stuck > and I have no idea on what to try next. > > Does anyone have suggestions/comments on where I should look for/what I > should do/what I should change in order to get the extension running on > Python 2.7? > > Thank you in advance for your suggestions :-) Did you try with python 3.x? IIUC, Phoenix should be made for python 3.x, and classic is for 2.7 series. Thank you. . > > Andrea. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Python path and append
On Mon, Apr 25, 2016 at 8:51 PM, Steven D'Aprano wrote: > See here for the *start* of a more professional approach: > > http://code.activestate.com/recipes/579097-safely-and-atomically-write-to-a-file/ What else would I need to know/consider in order to have a *complete* professional approach? -- boB -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling extensions on Python 2.7, Windows 10 64 bit
Andrea, On Fri, Apr 29, 2016 at 4:27 PM, Andrea Gavana wrote: > Hi, > > > On Friday, 29 April 2016, Igor Korot wrote: >> >> Andrea, >> >> On Fri, Apr 29, 2016 at 3:45 PM, wrote: >> > Dear list, >> > >> > I have been trying to compile wxPython Phoenix >> > (https://github.com/wxWidgets/Phoenix) from source on Windows 10 64 bit, >> > Python 2.7 64 bit, using the very handy Microsoft Visual C++ Compiler for >> > Python 2.7 >> > (https://www.microsoft.com/en-us/download/details.aspx?id=44266). >> > >> > I started with Python 2.7.8, then wiped out that installation and used >> > Python 2.7.11: cleaned the build directory, everything, and rebuilt the >> > Phoenix modules from scratch. >> > >> > Upon starting the Phoenix demo, I got the same error message I had with >> > Python 2.7.8: >> > >> > D:\MyProjects\Phoenix\demo>python Main.py >> > >> > Traceback (most recent call last): >> > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 1955, >> > in Notify >> > self.notify() >> > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 3034, >> > in Notify >> > self.result = self.callable(*self.args, **self.kwargs) >> > File "Main.py", line 2601, in ShowMain >> > frame = wxPythonDemo(None, "wxPython: (A Demonstration)") >> > File "Main.py", line 1531, in __init__ >> > self.SetOverview(self.overviewText, mainOverview) >> > File "Main.py", line 2130, in SetOverview >> > self.nb.SetPageText(0, os.path.split(name)[1]) >> > SystemError: ..\Objects\longobject.c:998: bad argument to internal >> > function >> > >> > The error message refers (apparently) to this Python bug: >> > >> > https://bugs.python.org/issue23842 >> > >> > But I assumed that it had been fixed way before 2.7.11. Now I am >> > stuck and I have no idea on what to try next. >> > >> > Does anyone have suggestions/comments on where I should look for/what I >> > should do/what I should change in order to get the extension running on >> > Python 2.7? >> > >> > Thank you in advance for your suggestions :-) >> >> Did you try with python 3.x? >> >> IIUC, Phoenix should be made for python 3.x, and classic is for 2.7 >> series. >> > > > No, Phoenix is meant to work on Python 2 and 3 at the same time. That's the > very reason it was created. But is it compiling with python 3.x? Because the bug should be definitely fixed there. Thank you. > > Andrea. > > > > -- > -- https://mail.python.org/mailman/listinfo/python-list
Re: How to download a flash video from this site?
On Sat, Apr 30, 2016 at 5:21 AM, wrote: > I am looking for a way to download a flash video from the page: > > https://hrti.hrt.hr/#/video/show/2203605/trebizat-prica-o-jednoj-vodi-i-jednom-narodu-dokumentarni-film > > The html code bellow the page is fairly simple, but I can't figure out how to > get the file. Since you're asking on this list, I'll assume you're using Beautiful Soup and/or youtube-dl. You'll need to go into more detail about what you're trying to do, and where the Python problem is. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling extensions on Python 2.7, Windows 10 64 bit
Hi, On Friday, 29 April 2016, Igor Korot wrote: > Andrea, > > On Fri, Apr 29, 2016 at 3:45 PM, > > wrote: > > Dear list, > > > > I have been trying to compile wxPython Phoenix ( > https://github.com/wxWidgets/Phoenix) from source on Windows 10 64 bit, > Python 2.7 64 bit, using the very handy Microsoft Visual C++ Compiler for > Python 2.7 (https://www.microsoft.com/en-us/download/details.aspx?id=44266 > ). > > > > I started with Python 2.7.8, then wiped out that installation and used > Python 2.7.11: cleaned the build directory, everything, and rebuilt the > Phoenix modules from scratch. > > > > Upon starting the Phoenix demo, I got the same error message I had with > Python 2.7.8: > > > > D:\MyProjects\Phoenix\demo>python Main.py > > > > Traceback (most recent call last): > > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 1955, > in Notify > > self.notify() > > File "C:\Python27\lib\site-packages\wxPhoenix\wx\core.py", line 3034, > in Notify > > self.result = self.callable(*self.args, **self.kwargs) > > File "Main.py", line 2601, in ShowMain > > frame = wxPythonDemo(None, "wxPython: (A Demonstration)") > > File "Main.py", line 1531, in __init__ > > self.SetOverview(self.overviewText, mainOverview) > > File "Main.py", line 2130, in SetOverview > > self.nb.SetPageText(0, os.path.split(name)[1]) > > SystemError: ..\Objects\longobject.c:998: bad argument to internal > function > > > > The error message refers (apparently) to this Python bug: > > > > https://bugs.python.org/issue23842 > > > > But I assumed that it had been fixed way before 2.7.11. Now I am > stuck and I have no idea on what to try next. > > > > Does anyone have suggestions/comments on where I should look for/what I > should do/what I should change in order to get the extension running on > Python 2.7? > > > > Thank you in advance for your suggestions :-) > > Did you try with python 3.x? > > IIUC, Phoenix should be made for python 3.x, and classic is for 2.7 series. > > No, Phoenix is meant to work on Python 2 and 3 at the same time. That's the very reason it was created. Andrea. -- -- https://mail.python.org/mailman/listinfo/python-list
web facing static text db
Hi folks, I have a very specific set of requirements for a task and was wondering if anyone had good suggestions for the best set of tools: * store text documents (about 10 pages) * the data set is static (i.e. only lookups are performed, no delete, no edit, no addition) * only one operation required: lookup of pages by matching words in them * very simple web frontend for querying the words to be matched * no authentication or authorization, frontend completely public * deployment at webfaction * deadline: yesterday :) Which web framework and db engine would you recommend? So far I'm familiar with turbogears but would be willing to learn anything if sufficiently basic since my needs are pretty basic (I think). Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- https://mail.python.org/mailman/listinfo/python-list
Re: web facing static text db
On Sat, Apr 30, 2016 at 8:29 AM, Fetchinson . via Python-list wrote: > * store text documents (about 10 pages) > * the data set is static (i.e. only lookups are performed, no delete, > no edit, no addition) > * only one operation required: lookup of pages by matching words in them > * very simple web frontend for querying the words to be matched > * no authentication or authorization, frontend completely public > * deployment at webfaction > * deadline: yesterday :) > > Which web framework and db engine would you recommend? PostgreSQL has decent facilities for text search. You can access that from Python using the psycopg2 module, and use something like Flask to help you put together your front end. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
about special characters
Hello everyone, I am trying to use python 27 copying some of my folders and files to another directory. My code works good for other files but I have some problem to copy files that have some special characters in the filename. like filenames contain Greek "δ" or latin "š". it always gave a error that "No such file or directory:" Any help will be appreciate! Thanks! Regards, Jianling -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
Jianling Fan writes: > I am trying to use python 27 copying some of my folders and files to > another directory. (There has never been a Python 27. I assume Python 2.7 is what you meant.) > My code works good for other files but I have some problem to copy > files that have some special characters in the filename. like > filenames contain Greek "δ" or latin "š". You may already know that Python 2 handles international text a lot less consistently than Python 3. Is it at all feasible for you to use Python 3 instead? Text handling is specifically a big advantage of Python 3. > it always gave a error that "No such file or directory:" Please give a complete, small example: * The actual filenames. * The exact filesystem encoding that filesystem uses. Be sure to verify that! * A very small, but complete, Python program which exhibits the behaviour. We will need to be able to run the same program. * The complete error output (the full traceback). -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does pathlib not have is_readable() & things like that?
On 2016-04-29, eryk sun wrote:
> On Fri, Apr 29, 2016 at 6:51 AM, Jussi Piitulainen
> wrote:
>> Adam Funk writes:
>>> On 2016-04-28, Grant Edwards wrote:
>>
Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK)
>>>
>>> That's what I'm doing now, but I prefer to give the user the error
>>> message early on.
>>
>> Then do that early on.
>
> Note that on Windows os.access only checks if a file is read-only.
> There's a proposed update to check the file security. The patch needs
> to be updated and needs to be reworked, but it's a low priority. For
> the most part calling os.access isn't recommended.
I'm sure there are probably other ways that it fails also. That's why
it's almost always simpler and better to just open the file in write
mode and see if it works.
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On 2016-04-30 00:52, Ben Finney wrote: Jianling Fan writes: I am trying to use python 27 copying some of my folders and files to another directory. (There has never been a Python 27. I assume Python 2.7 is what you meant.) My code works good for other files but I have some problem to copy files that have some special characters in the filename. like filenames contain Greek "δ" or latin "š". You may already know that Python 2 handles international text a lot less consistently than Python 3. Is it at all feasible for you to use Python 3 instead? Text handling is specifically a big advantage of Python 3. it always gave a error that "No such file or directory:" Please give a complete, small example: * The actual filenames. * The exact filesystem encoding that filesystem uses. Be sure to verify that! * A very small, but complete, Python program which exhibits the behaviour. We will need to be able to run the same program. * The complete error output (the full traceback). It might be a Unicode problem, i.e. trying to work with bytestrings (str) instead of Unicode strings (unicode) and using the wrong encoding. -- https://mail.python.org/mailman/listinfo/python-list
Re: def __init__(self,cls):
On Fri, 29 Apr 2016 07:47 pm, San wrote: > Dear Group, > > Please explain the following in details. > > " > def __init__(self,cls): > self.cls = cls The answer is the same as the answer you were given when you asked this question on the tutor mailing list. Did you read the answers you were given there? Your question: https://mail.python.org/pipermail/tutor/2016-April/108689.html My answer then: https://mail.python.org/pipermail/tutor/2016-April/108707.html The difference here is that you take a single argument called "cls". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: > Jianling Fan writes: > >> I am trying to use python 27 copying some of my folders and files to >> another directory. > > (There has never been a Python 27. I assume Python 2.7 is what you meant.) I believe that Python X.Y shows up as "PythonXY" under Windows. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On Sat, 30 Apr 2016 09:33 am, Jianling Fan wrote: > Hello everyone, > > I am trying to use python 27 copying some of my folders and files to > another directory. > My code works good for other files but I have some problem to copy > files that have some special characters in the filename. like > filenames contain Greek "δ" or latin "š". > it always gave a error that "No such file or directory:" > > Any help will be appreciate! Please put yourself in our shoes. Read your message above, and, imagine that you know NOTHING else about your program than what you write above. What answer would you give? Please tell us what you have actually done. How do you copy the files? How do you enter the file names? What OS are you using? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Not x.islower() Versus x.isupper Output Results
Greetings, I was playing around with a piece of code to remove lowercase letters and leave behind uppercase letters from a string when I got unexpected results. string = 'Whiskey Tango Foxtrot' list(filter((lambda x: not x.islower()), string)) ['W', ' ', 'T', ' ', 'F'] Note the space characters in the list. list(filter((lambda x: x.isupper()), string)) ['W', 'T', 'F'] Note that there are no space characters in the list. Shouldn't the results between 'not x.islower()' and 'x.isupper()' be identical? The final form of this code is this: list(filter(str.isupper, string)) ['W', 'T', 'F'] Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Not x.islower() has different output than x.isupper() in list output...
Greetings, I was playing around with a piece of code to remove lowercase letters and leave behind uppercase letters from a string when I got unexpected results. string = 'Whiskey Tango Foxtrot' list(filter((lambda x: not x.islower()), string)) ['W', ' ', 'T', ' ', 'F'] Note the space characters in the list. list(filter((lambda x: x.isupper()), string)) ['W', 'T', 'F'] Note that there are no space characters in the list. Shouldn't the results between 'not x.islower()' and 'x.isupper()' be identical? The final form of this code is this: list(filter(str.isupper, string)) ['W', 'T', 'F'] Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Fri, 29 Apr 2016 07:53 pm, Rustom Mody wrote: > On Friday, April 29, 2016 at 3:07:09 PM UTC+5:30, Steven D'Aprano wrote: >> On Fri, 29 Apr 2016 03:00 pm, Rustom Mody wafted information-rich >> pheromones into the air, where they diffused rapidly: >> > Why replicate and cause annoyance? >> >> If you don't want to use the functionality, don't. > > You asked about calling up pagers!! Right. And options -h/--help will behave exactly as people have requested, by printing to stdout. > JFTR I find git behavior annoying -- as it seems do others `git --help` behaves as the Unix standard: it prints help output to stdout. Is that the annoying behaviour? `git help ` and `git --help` call `man`. Is that the annoying behaviour? Then presumably `man` is also annoying, and the advise I was given to just use man pages is bad advice. > -- but Ive > figured getting round it by calling it with -w (show in web browser) is ok > (with me) You would rather output be shown in a web browser than paged in your terminal? That's weird, but okay, whatever floats your boat. > With python's help I find it annoying and Ive not figured out how to not > get paging o_O Okay, now I'm feeling as if you had said "I find it annoying to be fit and healthy, I've not found a way to feel sufficiently sick, tired and out-of-shape all the time." But I see your point. The pydoc documentation itself is lacking. But from reading the source code, I see that if you set the PAGER environment variable to your preferred pager, it will use that. So setting it to "cat" should work. I've just tested this under Linux, and it works for me: [steve@ando ~]$ PAGER=cat python3.3 Python 3.3.0rc3 (default, Sep 27 2012, 18:44:58) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux Type "help", "copyright", "credits" or "license" for more information. py> help(len) Help on built-in function len in module builtins: len(...) len(object) -> integer Return the number of items of a sequence or mapping. py> -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() has different output than x.isupper() in list output...
On Fri, Apr 29, 2016, at 06:17 PM, Christopher Reimer wrote: > Greetings, > > I was playing around with a piece of code to remove lowercase letters > and leave behind uppercase letters from a string when I got unexpected > results. > > string = 'Whiskey Tango Foxtrot' > > list(filter((lambda x: not x.islower()), string)) > > ['W', ' ', 'T', ' ', 'F'] > > Note the space characters in the list. > > list(filter((lambda x: x.isupper()), string)) > > ['W', 'T', 'F'] > > Note that there are no space characters in the list. > > Shouldn't the results between 'not x.islower()' and 'x.isupper()' be > identical? Absolutely not. There are characters which are neither uppercase or lowercase: specifically, whitespace in your situation. "x.islower()" is true for everything that is lowercase, and false for everything else. (Including things which have no case). If you invert with not, then its false for everything that is lowercase, but true for everything else: including things which have no case. "x.isupper()" is true for everything that is uppercase, and false for everything else. This is therefore a narrower test then "not x.islower()" x.isupper() is a narrower, more specific test then "not x.islower()". If you used "not x.isupper()" you'd get the whitespace in it too (along with all the lower case characters). If isupper/islower were perfect opposites of each-other, there'd be no need for both. But since characters can be upper, lower, or *neither*, you run into this situation. -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() Versus x.isupper Output Results
On Sat, 30 Apr 2016 11:14 am, Christopher Reimer wrote: > Shouldn't the results between 'not x.islower()' and 'x.isupper()' be > identical? Of course not. py> "2 #".islower(), "2 #".isupper() (False, False) py> not "2 #".islower(), "2 #".isupper() (True, False) "Is Lower" versus "Is Upper" is not a dichotomy. There are: - lowercase characters, like "abc" - uppercase characters, like "ABC" - characters which are neither lowercase nor uppercase, like "2 #" In unicode, there are also: - titlecase characters, like "DžLjῼ" If those characters don't show up for you, they are: U+01C5 LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON U+01C8 LATIN CAPITAL LETTER L WITH SMALL LETTER J U+1FFC GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI So not islower() is very different from isupper. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python path and append
On Sat, 30 Apr 2016 06:26 am, boB Stepp wrote: > On Mon, Apr 25, 2016 at 8:51 PM, Steven D'Aprano > wrote: > >> See here for the *start* of a more professional approach: >> >> http://code.activestate.com/recipes/579097-safely-and-atomically-write-to-a-file/ > > What else would I need to know/consider in order to have a *complete* > professional approach? When I know, I'll tell you. I think the answer depends in part on what you're trying to do. The requirements for, say, an ACID-compliant database are much heavier than for most applications. As far as regular applications go, I'd like to see: - the above tested and debugged for Windows and MacOS; - should it save the previous version of the file? - if so, how many backup files should it keep? - should it try to sync and flush the disk on saving the file? - anything I haven't thought of? Some of those (like the keeping of backups) is probably something that should be given as an option to the end-user. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
Steven D'Aprano writes: > On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: > > > (There has never been a Python 27. I assume Python 2.7 is what you > > meant.) > > I believe that Python X.Y shows up as "PythonXY" under Windows. Then that's a bug which should be fixed, IMO. An MS Windows user (i.e., not me) would be well placed to describe the behaviour in a bug report. -- \“Most people, I think, don't even know what a rootkit is, so | `\ why should they care about it?” —Thomas Hesse, Sony BMG, 2006 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() Versus x.isupper Output Results
On Sat, 30 Apr 2016 11:31 am, Steven D'Aprano wrote: > In unicode, there are also: > > - titlecase characters, like "DžLjῼ" To be clear, each of those three characters is considered titlecased individually. The three of them together is not considered a title-cased string. "Is Title" is not just for Unicode. In Python 2, strings (ASCII byte strings) also have an istitle() method: py> "Dz".istitle() True py> "DZ".istitle() False -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() has different output than x.isupper() in list output...
On 4/29/2016 6:29 PM, Stephen Hansen wrote: If isupper/islower were perfect opposites of each-other, there'd be no need for both. But since characters can be upper, lower, or *neither*, you run into this situation. Based upon the official documentation, I was expecting perfect opposites. str.islower(): "Return true if all cased characters [4] in the string are lowercase and there is at least one cased character, false otherwise." https://docs.python.org/3/library/stdtypes.html?highlight=islower#str.islower str.isupper(): "Return true if all cased characters [4] in the string are uppercase and there is at least one cased character, false otherwise." https://docs.python.org/3/library/stdtypes.html?highlight=isupper#str.isupper Here's the footnote that may or not be relevant to this discussion: "[4] Cased characters are those with general category property being one of “Lu” (Letter, uppercase), “Ll” (Letter, lowercase), or “Lt” (Letter, titlecase)." A bug in the docs? Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On 04/29/2016 06:20 PM, Steven D'Aprano wrote: On Fri, 29 Apr 2016 07:53 pm, Rustom Mody wrote: JFTR I find git behavior annoying -- as it seems do others `git --help` behaves as the Unix standard: it prints help output to stdout. Is that the annoying behaviour? No. `git help ` and `git --help` call `man`. Is that the annoying behaviour? Yes. Then presumably `man` is also annoying, No. and the advise I was given to just use man pages is bad advice. The advice to call man from --help is bad; the advice to have a man page for use with man is not. With python's help I find it annoying and Ive not figured out how to not get paging o_O Okay, now I'm feeling as if you had said "I find it annoying to be fit and healthy, I've not found a way to feel sufficiently sick, tired and out-of-shape all the time." And exactly what is healthy and fit about calling "help(something)" and then having that help disappear? I find that *extremely* annoying. But I see your point. The pydoc documentation itself is lacking. But from reading the source code, I see that if you set the PAGER environment variable to your preferred pager, it will use that. So setting it to "cat" should work. I've just tested this under Linux, and it works for me: So I have to cripple my shell to get pydoc help to work nicely? Neat! Actually, not so much. :( -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() has different output than x.isupper() in list output...
On Sat, Apr 30, 2016 at 11:55 AM, Christopher Reimer
wrote:
> On 4/29/2016 6:29 PM, Stephen Hansen wrote:
>>
>> If isupper/islower were perfect opposites of each-other, there'd be no
>> need for both. But since characters can be upper, lower, or *neither*, you
>> run into this situation.
>
>
> Based upon the official documentation, I was expecting perfect opposites.
>
> str.islower(): "Return true if all cased characters [4] in the string are
> lowercase and there is at least one cased character, false otherwise."
>
> https://docs.python.org/3/library/stdtypes.html?highlight=islower#str.islower
>
> str.isupper(): "Return true if all cased characters [4] in the string are
> uppercase and there is at least one cased character, false otherwise."
>
> https://docs.python.org/3/library/stdtypes.html?highlight=isupper#str.isupper
>
> Here's the footnote that may or not be relevant to this discussion: "[4]
> Cased characters are those with general category property being one of “Lu”
> (Letter, uppercase), “Ll” (Letter, lowercase), or “Lt” (Letter, titlecase)."
>
> A bug in the docs?
>>> def case(ch):
... return (
... ("Lower " if ch.islower() else "") +
... ("Upper " if ch.isupper() else "") +
... unicodedata.category(ch)
... )
Both functions require that there be at least one cased character:
>>> case("@")
'Po'
And then each one requires a specific character class:
>>> case("a")
'Lower Ll'
>>> case("A")
'Upper Lu'
Other classes don't count:
>>> case("\u01C5")
'Lt'
There are three categories of "cased characters". Both functions check
for exactly one of those categories. Thus they are not opposites.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Fri, Apr 29, 2016, at 22:09, Ethan Furman wrote: > So I have to cripple my shell to get pydoc help to work nicely? Neat! > Actually, not so much. :( If you don't want a pager with pydoc, when exactly do you want it? -- https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
"Martin A. Brown" writes: > Hello [Steven D'Aprano], > > >What is a good place where I can find out more about writing manpage? Writing them directly in GNU troff markup is easy enough http://liw.fi/manpages/>. For writing manual pages programmatically via Python code, I am working on a ‘manpage’ library. It is not yet at PyPI, but Steven may find the existing library https://notabug.org/bignose/python-manpage> useful. It's free software under the GNU GPL v3 or later. Steven, if you want to use that library for making manual pages, I'd love to get feedback. Currently it works on an ArgumentParser instance (to get the program's name and option help), and a Distutils distribution (to get the boader metadata about the package). What ‘manpage’ doesn't yet have is a more generic way to specify the metadata of a manual page. Everything is done by directly modifying a Document instance. I have yet to decide a data format for the data which specifies a manual page. Getting several more code bases using this library would make it clearer what use cases are important, and thereby inform a data format for the specification. Please experiment! -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Saturday, April 30, 2016 at 7:47:11 AM UTC+5:30, Random832 wrote: > On Fri, Apr 29, 2016, at 22:09, Ethan Furman wrote: > > So I have to cripple my shell to get pydoc help to work nicely? Neat! > > Actually, not so much. :( > > If you don't want a pager with pydoc, when exactly do you want it? - I start a python interpreter - ... Am pottering around for a while - ... Need help on something... [So with Steven's solution of PAGER=cat Ive to restart python!! Leaving that aside...] - ... help can do one of two valid things [remember I am on a modern windowing system] -- start help inline, inband (cat) -- start help out of band (browser, yelp, etc ie some other app) Instead it does some ½-assed fall-between-the-stools of both -- https://mail.python.org/mailman/listinfo/python-list
Writing manual pages using Python code (was: manpage writing)
"Martin A. Brown" writes: > Hello [Steven D'Aprano], > > >What is a good place where I can find out more about writing manpage? Writing manual pages directly in standard GNU troff markup is simple enough http://liw.fi/manpages/>. It's not a pretty markup language, but it's workable. For writing manual page documents programmatically via Python code, I am working on a ‘manpage’ library. It is not yet at PyPI, but Steven may find the existing library https://notabug.org/bignose/python-manpage> useful. It's free software under the GNU GPL v3 or later. Steven, if you want to use that library for making manual pages, I'd love to get feedback. Currently it works on an ArgumentParser instance (to get the program's name and option help), and a Distutils distribution (to get the boader metadata about the package). What ‘manpage’ doesn't yet have is a more generic way to specify the metadata of a manual page; the above inputs are the only ones that I've tested. Everything is done by directly modifying a Document instance. I have yet to decide a data format for the data which specifies a manual page. If several more code bases could use this library to generate manual pages, that would make it clearer what use cases are important, and thereby inform a data format for the specification. Please experiment! -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On 4/29/2016 9:48 PM, Ben Finney wrote: Steven D'Aprano writes: On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: (There has never been a Python 27. I assume Python 2.7 is what you meant.) I believe that Python X.Y shows up as "PythonXY" under Windows. As a directory name that also omits the space, yes. Start Menu entries have both the space and and the '.'. Then that's a bug which should be fixed, IMO. An MS Windows user (i.e., not me) would be well placed to describe the behaviour in a bug report. I disagree. .0, .1, etc, would look like extensions, but are not. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On Fri, Apr 29, 2016 at 8:48 PM, Ben Finney wrote: > Steven D'Aprano writes: >> On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: >> >> > (There has never been a Python 27. I assume Python 2.7 is what you >> > meant.) >> >> I believe that Python X.Y shows up as "PythonXY" under Windows. > > Then that's a bug which should be fixed, IMO. An MS Windows user (i.e., > not me) would be well placed to describe the behaviour in a bug report. It's Python X.Y in the start menu and Python X.Y.Z in sys.version. The default installation directory is PythonXY (for 3.5.0 it was "Python 3.5"; this was reverted in 3.5.1), and the DLL is pythonXY.dll. The executables are python.exe and pythonw.exe. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Fri, Apr 29, 2016, at 22:27, Rustom Mody wrote: > On Saturday, April 30, 2016 at 7:47:11 AM UTC+5:30, Random832 wrote: > > On Fri, Apr 29, 2016, at 22:09, Ethan Furman wrote: > > > So I have to cripple my shell to get pydoc help to work nicely? Neat! > > > Actually, not so much. :( > > > > If you don't want a pager with pydoc, when exactly do you want it? > > - I start a python interpreter > - ... Am pottering around for a while > - ... Need help on something... > [So with Steven's solution of PAGER=cat Ive to restart python!! > Leaving that aside...] > - ... help can do one of two valid things [remember I am on a modern > windowing > system] > -- start help inline, inband (cat) > -- start help out of band (browser, yelp, etc ie some other app) > > Instead it does some ½-assed fall-between-the-stools of both That doesn't answer the question of why, if you (Well, Ethan, but you're taking the same position here) hate pagers so much, why you can't just set PAGER=cat in your profile once, now, and never see one again. How does this "cripple your shell"; if you hate pagers so much why do you want man or git to use one any more than pydoc? -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
Terry Reedy writes: > On 4/29/2016 9:48 PM, Ben Finney wrote: > > Steven D'Aprano writes: > > > >> On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: > >> > >>> (There has never been a Python 27. I assume Python 2.7 is what you > >>> meant.) > >> > >> I believe that Python X.Y shows up as "PythonXY" under Windows. > > As a directory name that also omits the space, yes. Start Menu entries > have both the space and and the '.'. Okay. So as you describe the behaviour on MS Windows, it doesn't support the OP's choice of saying “python 27” to specify Python 2.7 — MS Windows appears to be irrelevant to that. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
Random832 writes: > On Fri, Apr 29, 2016, at 22:27, Rustom Mody wrote: > > Instead it does some ½-assed fall-between-the-stools of both > > That doesn't answer the question of why, if you (Well, Ethan, but > you're taking the same position here) hate pagers so much That's not a question relevant here; nobody inthe discussion has a position fairly characterised as “hate pagers so much”. So you're arguing against a straw man. Rather, the position being argued is that they *do* like pagers; they like pagers enough that they want the existing ‘PAGER’ environment variable setting to remain untouched. And, simulatenously, they want Python's help to not use a pager at the interactive prompt. -- \“The difference between religions and cults is determined by | `\ how much real estate is owned.” —Frank Zappa | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: about special characters
On 2016-04-30 03:35, eryk sun wrote: On Fri, Apr 29, 2016 at 8:48 PM, Ben Finney wrote: Steven D'Aprano writes: On Sat, 30 Apr 2016 09:52 am, Ben Finney wrote: > (There has never been a Python 27. I assume Python 2.7 is what you > meant.) I believe that Python X.Y shows up as "PythonXY" under Windows. Then that's a bug which should be fixed, IMO. An MS Windows user (i.e., not me) would be well placed to describe the behaviour in a bug report. It's Python X.Y in the start menu and Python X.Y.Z in sys.version. The default installation directory is PythonXY (for 3.5.0 it was "Python 3.5"; this was reverted in 3.5.1), and the DLL is pythonXY.dll. The executables are python.exe and pythonw.exe. There's an option in Windows to hide the extension. I wondered whether that had something to do with it. It turns out that it applies only to file names, not folder names, so you can have multiple files apparently with the same name, but folder names remain distinct. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Saturday, April 30, 2016 at 8:06:46 AM UTC+5:30, Random832 wrote: > On Fri, Apr 29, 2016, at 22:27, Rustom Mody wrote: > > On Saturday, April 30, 2016 at 7:47:11 AM UTC+5:30, Random832 wrote: > > > On Fri, Apr 29, 2016, at 22:09, Ethan Furman wrote: > > > > So I have to cripple my shell to get pydoc help to work nicely? Neat! > > > > Actually, not so much. :( > > > > > > If you don't want a pager with pydoc, when exactly do you want it? > > > > - I start a python interpreter > > - ... Am pottering around for a while > > - ... Need help on something... > > [So with Steven's solution of PAGER=cat Ive to restart python!! > > Leaving that aside...] > > - ... help can do one of two valid things [remember I am on a modern > > windowing > > system] > > -- start help inline, inband (cat) > > -- start help out of band (browser, yelp, etc ie some other app) > > > > Instead it does some ½-assed fall-between-the-stools of both > > That doesn't answer the question of why, if you (Well, Ethan, but you're > taking the same position here) hate pagers so much, why you can't just > set PAGER=cat in your profile once, now, and never see one again. How > does this "cripple your shell"; if you hate pagers so much why do you > want man or git to use one any more than pydoc? I dont get whats so hard to get in this: When we need pagers we know where to get them When we dont, please dont thump them on us I dont know that anyone has taken the "I-HATE-pagers' view so much as "Let me get them when I want them" -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Fri, Apr 29, 2016, at 22:46, Rustom Mody wrote: > I dont get whats so hard to get in this: > When we need pagers we know where to get them And if you set PAGER=cat (thus "crippling your shell"), you will likewise know where to get them when you want to page the output from man or git. Why is pydoc less of a "place where a pager should be used by default" than man or git (diff, log, etc), if you accept the latter? > When we dont, please dont thump them on us > I dont know that anyone has taken the "I-HATE-pagers' view so much as > "Let me get them when I want them" Sure. And if you set PAGER=cat, then you won't ever see a pager unless you specifically request one. Everyone wins. -- https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
On Saturday, April 30, 2016 at 7:55:47 AM UTC+5:30, Ben Finney wrote: > "Martin A. Brown" writes: > > > Hello [Steven D'Aprano], > > > > >What is a good place where I can find out more about writing manpage? > > Writing them directly in GNU troff markup is easy enough > http://liw.fi/manpages/>. > > For writing manual pages programmatically via Python code, I am working > on a 'manpage' library. It is not yet at PyPI, but Steven may find > the existing library https://notabug.org/bignose/python-manpage> > useful. It's free software under the GNU GPL v3 or later. > > Steven, if you want to use that library for making manual pages, I'd > love to get feedback. Currently it works on an ArgumentParser instance > (to get the program's name and option help), and a Distutils > distribution (to get the boader metadata about the package). > > What 'manpage' doesn't yet have is a more generic way to specify the > metadata of a manual page. Everything is done by directly modifying a > Document instance. I have yet to decide a data format for the data which > specifies a manual page. > > Getting several more code bases using this library would make it clearer > what use cases are important, and thereby inform a data format for the > specification. Please experiment! Some general thoughts and comments: Documentation in linux is a train-wreck in slow motion -- 30 years of slow motion!! tl;dr If you want to be helpful to the community please dont create a new format Instead try to make existing formats interoperate/work better with each other In more detail: First there was man Then gnu/rms created info to better man with hypertext capabilities However another hypertext standard beat the gnu standard -- html [No I am not talking of quality just general acceptance] As with all things rms, its taking him decades to realize this defeat [Latest makeinfo is 18 times slower than previous version!! https://lists.gnu.org/archive/html/bug-texinfo/2013-01/msg00012.html ] In the meantime the so called lightweight formats have multiplied: rst, textile, markdown, asciidoc etc with their own 'stacks' Alongside siloed, incompatible help systems: manpages, infodocs, yelp... -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Sat, 30 Apr 2016 12:49 pm, Ben Finney wrote: > Random832 writes: > >> On Fri, Apr 29, 2016, at 22:27, Rustom Mody wrote: >> > Instead it does some ½-assed fall-between-the-stools of both >> >> That doesn't answer the question of why, if you (Well, Ethan, but >> you're taking the same position here) hate pagers so much > > That's not a question relevant here; nobody inthe discussion has a > position fairly characterised as “hate pagers so much”. So you're > arguing against a straw man. > > Rather, the position being argued is that they *do* like pagers; they > like pagers enough that they want the existing ‘PAGER’ environment > variable setting to remain untouched. So they want the PAGER environment variable to specify what pager they want... > And, simulatenously, they want > Python's help to not use a pager at the interactive prompt. ...so long as applications don't actually make use of that PAGER environment variable to determine the pager they want to use. (1) If you want man, and nothing else in the universe, to automatically use a pager, then set MANPAGER="less" (or whatever you wish to use), and unset PAGER. (2) If you don't want *anything* to use a pager, then unset both MANPAGER and PAGER. You may have to report a feature request / bug report for applications which force their own pager. (3) In Python specifically, you can trivially and easily tell help() to output directly to stdout. (At least on Linux, I haven't tested it elsewhere.) Simply use PAGER=cat on the command line you use to launch the interactive environment. This will affect no other running or future processes (apart from subprocesses launched from your interactive Python session), allowing you to keep your PAGER for everything else. (4) If you want more than that, then patches are welcome :-) Seriously, I'm thinking that a keyword argument to help might be useful: help(object, pager=None) where: - pager=None gives the current behaviour; - pager="foo" calls out to the external program "foo"; - pager=callable passes the help text to callable(). pager=print would do exactly what people are asking for, and you could then create your own wrapper to change the default: help = functools.partial(builtins.help, pager=print) I think that would make it easier to test help(). Thoughts? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
Steven D'Aprano writes: > So they want the PAGER environment variable to specify what pager they > want... > > ...so long as applications don't actually make use of that PAGER > environment variable to determine the pager they want to use. This at least does not baldly misrepresent the position being made :-) -- \“My doctor told me to stop having intimate dinners for four. | `\ Unless there are three other people.” —Orson Welles | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
Rustom Mody writes: > As with all things rms, its taking him decades to realize this defeat > [Latest makeinfo is 18 times slower than previous version!! > https://lists.gnu.org/archive/html/bug-texinfo/2013-01/msg00012.html Wait, what's it written in now? > In the meantime the so called lightweight formats have multiplied: > rst, textile, markdown, asciidoc etc Pandoc can interconvert between most of those... maybe texinfo should be folded into it if it's not already. -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Sat, Apr 30, 2016, at 00:06, Ben Finney wrote: > Steven D'Aprano writes: > > > So they want the PAGER environment variable to specify what pager they > > want... > > > > ...so long as applications don't actually make use of that PAGER > > environment variable to determine the pager they want to use. > > This at least does not baldly misrepresent the position being made :-) I still don't understand how it's a misrepresentation. They said they don't want stuff (where "stuff" includes pydoc but it's not clear why or where it ends) to automatically use a pager without being requested, and provided absolutely no criteria by which pydoc is special and shouldn't behave the same as git and man do (since the entire reason PAGER=cat is an unacceptable solution is that it "cripples" git and man). -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Saturday, April 30, 2016 at 9:46:19 AM UTC+5:30, Random832 wrote: > On Sat, Apr 30, 2016, at 00:06, Ben Finney wrote: > > Steven D'Aprano writes: > > > > > So they want the PAGER environment variable to specify what pager they > > > want... > > > > > > ...so long as applications don't actually make use of that PAGER > > > environment variable to determine the pager they want to use. > > > > This at least does not baldly misrepresent the position being made :-) > > I still don't understand how it's a misrepresentation. They said they > don't want stuff (where "stuff" includes pydoc but it's not clear why or > where it ends) to automatically use a pager without being requested, and > provided absolutely no criteria by which pydoc is special and shouldn't > behave the same as git and man do (since the entire reason PAGER=cat is > an unacceptable solution is that it "cripples" git and man). Also environment variables are a nuisance and an antipattern: http://peterlyons.com/problog/2010/02/environment-variables-considered-harmful -- https://mail.python.org/mailman/listinfo/python-list
Re: What should Python apps do when asked to show help?
On Fri, Apr 29, 2016, at 23:23, Steven D'Aprano wrote: > Seriously, I'm thinking that a keyword argument to help might be useful: > > help(object, pager=None) I'd call it something more generic like "output". > where: > > - pager=None gives the current behaviour; > > - pager="foo" calls out to the external program "foo"; > > - pager=callable passes the help text to callable(). > > > pager=print would do exactly what people are asking for, and you could > then > create your own wrapper to change the default: > > help = functools.partial(builtins.help, pager=print) > > > I think that would make it easier to test help(). Thoughts? For testing purposes, help could return the result of the output function, so that you can use lambda x: x to have it return the help text. More general thoughts: It might also be useful to move the pager machinery from pydoc to an independent module. It's got, among other things, a simple pager written in pure python, for use as a fallback. There's a lot of stuff that could be improved in the pager stuff, while we're at it. Probably needs a single function to handle "use external program as a pager", rather than having a bunch of logic embedded in getpager() which only works for os.environ['PAGER']. The "pager" function doesn't behave "properly" (in its intended behavior of calling the expensive getpager() once when it is first called and subsequently reusing the cached value) if a reference to it is stored elsewhere (e.g. by importing it to another module); it should store the cached pager function somewhere else rather than by replacing itself. The pure-python pager only works on unix-style ttys, an analogous function could be written for windows using msvcrt.getwch. -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() has different output than x.isupper() in list output...
Christopher Reimer wrote:
str.islower(): "Return true if all cased characters [4] in the string
are lowercase and there is at least one cased character, false otherwise."
str.isupper(): "Return true if all cased characters [4] in the string
are uppercase and there is at least one cased character, false otherwise."
A string consisting of a single space doesn't contain any
cased characters, so both islower(" ") and isupper(" ")
return false according to these rules. The docs are correct.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: manpage writing [rst, asciidoc, pod] was [Re: What should Python apps do when asked to show help?]
On Saturday, April 30, 2016 at 9:36:42 AM UTC+5:30, Paul Rubin wrote: > Rustom Mody writes: > > As with all things rms, its taking him decades to realize this defeat > > [Latest makeinfo is 18 times slower than previous version!! > > https://lists.gnu.org/archive/html/bug-texinfo/2013-01/msg00012.html > > Wait, what's it written in now? Have you any data that its moved on? At that point what I gleaned was that original makeinfo was in C New one was rewritten in perl. [Yeah they could have taken a leaf out of pandoc -- written in haskell] -- https://mail.python.org/mailman/listinfo/python-list
Re: Not x.islower() has different output than x.isupper() in list output...
On Fri, Apr 29, 2016, at 06:55 PM, Christopher Reimer wrote: > On 4/29/2016 6:29 PM, Stephen Hansen wrote: > > If isupper/islower were perfect opposites of each-other, there'd be no > > need for both. But since characters can be upper, lower, or *neither*, > > you run into this situation. > > Based upon the official documentation, I was expecting perfect opposites. > > str.islower(): "Return true if all cased characters [4] in the string > are lowercase and there is at least one cased character, false > otherwise." The thing is, your use of filter is passing a string of 1 character long to your function, and so when it comes up against a string " ", there are no cased characters. Therefore, false. The documentation holds true. Your use of filter is breaking "Whiskey Tango Foxtrot" into ["W", "h", "i", ... "o" t"] and calling not x.islower() vs x.isupper() on each. When it comes up against " ", it doesn't pass the documented definition of what islower defines. The official documentation is accurate. -- Stephen Hansen m e @ i x o k a i . i o -- https://mail.python.org/mailman/listinfo/python-list
