Re: Feeding the trolls
by building a custom py-based mail client maybe ^^_ Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ On Wed, 20 Jun 2018, 17:18 D'Arcy Cain, wrote: > On 2018-06-20 08:10 AM, Tim Golden wrote: > > [... snip discussions about Bart's language ...] > > > > Wearing my moderator hat > > > > Can we take the "Bart's language vs Python Show" to some other forum, > > please? We've already gone over this ground again and again and it isn't > > helping the signal-to-noise ratio here on the Python list / > > comp.lang.python > > Thank you. Many of us have blocked rick and bart years ago. If you are > just going to feed the trolls we have to see their nonsense anyway. > Just email them privately if you really feel the need to vent. > > One of these days I will have to figure out how to block replies to the > trolls as well. > > -- > D'Arcy J.M. Cain > Vybe Networks Inc. > http://www.VybeNetworks.com/ > IM:da...@vex.net VoIP: sip:da...@vybenetworks.com > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
nltk related issue
Folks,
I am trying to run a simple example associated with nltk.
I get some error and I don't know what the issue is.
I need some guidance please.
I am using python canopy distribution
The following is the code:
inputstring = ' This is an example sent. The sentence splitter will split on
sent markers. Ohh really !!'
from nltk.tokenize import sent_tokenize
sentences = sent_tokenize(inputstring)
print sentences
The following is the error report:
LookupErrorTraceback (most recent call last)
D:\Projects\Initiatives\machine learning\programs\nltk_1.py in ()
2 from nltk.tokenize import sent_tokenize
3
> 4 sentences = sent_tokenize(inputstring)
5
6 print sentences
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\site-packages\nltk\tokenize\__init__.pyc
in sent_tokenize(text, language)
94 :param language: the model name in the Punkt corpus
95 """
---> 96 tokenizer = load('tokenizers/punkt/{0}.pickle'.format(language))
97 return tokenizer.tokenize(text)
98
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\site-packages\nltk\data.pyc
in load(resource_url, format, cache, verbose, logic_parser, fstruct_reader,
encoding)
812
813 # Load the resource.
--> 814 opened_resource = _open(resource_url)
815
816 if format == 'raw':
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\site-packages\nltk\data.pyc
in _open(resource_url)
930
931 if protocol is None or protocol.lower() == 'nltk':
--> 932 return find(path_, path + ['']).open()
933 elif protocol.lower() == 'file':
934 # urllib might not use mode='rb', so handle this one ourselves:
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\site-packages\nltk\data.pyc
in find(resource_name, paths)
651 sep = '*' * 70
652 resource_not_found = '\n%s\n%s\n%s' % (sep, msg, sep)
--> 653 raise LookupError(resource_not_found)
654
655
LookupError:
**
Resource u'tokenizers/punkt/english.pickle' not found. Please
use the NLTK Downloader to obtain the resource: >>>
nltk.download()
Searched in:
- 'D:\\Users\\sharanb/nltk_data'
- 'C:\\nltk_data'
- 'D:\\nltk_data'
- 'E:\\nltk_data'
-
'D:\\Users\\sharanb\\AppData\\Local\\Enthought\\Canopy\\edm\\envs\\User\\nltk_data'
-
'D:\\Users\\sharanb\\AppData\\Local\\Enthought\\Canopy\\edm\\envs\\User\\lib\\nltk_data'
- 'D:\\Users\\sharanb\\AppData\\Roaming\\nltk_data'
- u''
**
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Michael Torrie wrote: Pointers are for a different conceptual model, a different (virtual) machine architecture. And even in many lower-level languages that do have pointers, they're not much like the wild, undisciplined version that you get in C and C++. In Pascal, for example (and derivatives like Modula) the only legitimate use for a pointer is to reference a heap-allocated memory block -- they can't point into the middle of arbitrary data structures. I think Pascal does a pretty good job of abstracting the essential features of the underlying hardware, and it does it without needing anything like a C-style pointer. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Michael Torrie wrote: And I posit that most efficient interpreters don't use switch/case at all, but rather jump tables. Not always true. If the number of cases is small enough, a tree of branches could be faster due to cacheing and pipelining issues. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
You're right. While pointers can be made to fit, it would be an awkward fit into Python and could introduce overheads even when not used. My use of them is frequently when straddling boundaries between languages (a pointer in one environment points to the data of another), or when working just outside the language's object system, or using pointers to raw machine types that are not reference counted. This would not be disciplined enough for Python. So forget I mentioned them even though they could open up interesting possibilities such as reference parameters. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
The actual interpreter code is irrelevant. Switch would be a feature of the language being interpreted, not of the interpreter. If the task is to match an expression X against a variety of values, then expressing that as a switch means the interpreter /could/ use a jump table (of labels within the byte code), rather than execute a chain of X==Y tests within byte code. So, evaluate X once then it could be a single byte code op. At least, it will know that exactly the same X value is being tested. So you evaluate it once then keep it on the stack. Think of Switch as another kind if hint. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/20/2018 03:35 AM, bart4...@gmail.com wrote: > Pointers are merely an extra level of indirection; they can be made to fit. I'm hard pressed to think of any way in which pointers could fit into Python given the way python variables work and given the virtual machien architecture and abstraction that python presents to programemrs. Pointers are for a different conceptual model, a different (virtual) machine architecture. I programmed for many years when I was a young without pointers and never needed them in the language I was using which broadly abstracted memory. When I learned C and C++, I learned how to work with pointers because they were intrinsically a part of the programming paradigm these languages espouse. Both languages are extremely low-level, with very little abstraction between you and the Von Neumann machine. Given your experience with programming and making your own programming languages, I'm often surprised by your assertions. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 06/20/2018 05:53 AM, bart4...@gmail.com wrote: > I suggest that such features just make life a little simpler. (And > make writing an efficient interpreter a little bit easier.) And I posit that most efficient interpreters don't use switch/case at all, but rather jump tables. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Tue, 19 Jun 2018 16:25:50 -0700, bart4858 wrote: > Some of that can be done. It may not need specific support. > > But my intention is to have an ordinary language for everyday coding not > one that can only be understood by CS professors. > > Mine is unusual in that I can drop features I rarely use, which means > that everything in it gets good use. Including multi-level breaks. > only because no one else is using your language & you do not have to worry about breaking the code of your userbase. I think you are suffering from NIH* syndrome & are reinventing the wheel for no particular reason other than "Because you can" > And the core language can stay small (or smallish - it's not Forth). > Which I think is where we came in. * Not Invented Here -- To be a kind of moral Unix, he touched the hem of Nature's shift. -- Shelley -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, 20 Jun 2018 13:59:40 +, Grant Edwards wrote: > On 2018-06-20, Alister via Python-list wrote: > >> Annotations were invented by the Nazi's on the explicit instruction of >> Hitler. there, can someone now invoke Godwins law & call this >> discussion closed :-) > > I'm pretty sure I read somewhere that Godwin's law doesn't apply when > one invokes Hitler/Nazis for the purpose of stopping the thread... damn protocol nazi -- Pure drivel tends to drive ordinary drivel off the TV screen. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
If you're genuinely interested in how pointers might work I'll try and write that up when I get back to a real machine, and will do it in the form of a link. Since people are clearly unhappy with discussing features that ought to be in Python in a Python forum. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 2018-06-20, Alister via Python-list wrote: > Annotations were invented by the Nazi's on the explicit instruction > of Hitler. there, can someone now invoke Godwins law & call this > discussion closed :-) I'm pretty sure I read somewhere that Godwin's law doesn't apply when one invokes Hitler/Nazis for the purpose of stopping the thread... -- Grant Edwards grant.b.edwardsYow! I joined scientology at at a garage sale!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, 20 Jun 2018 03:13:09 +, Steven D'Aprano wrote: > On Tue, 19 Jun 2018 12:13:40 -0700, Jim Lee wrote: > >> On 06/19/2018 04:13 AM, Ed Kellett wrote: >>> I think we're all--still--missing the larger point that "easy to >>> remove" is a completely stupid metric for judging language features. >>> Seriously. Not a little bit stupid. >> >> Not if you think of the feature as analogous to cancer. > > That would take it so far beyond the stupidity event horizon that no > human language has an adjective for how stupid it is. > > Besides, annotations aren't cancer. They're obviously terrorism. Any > fool can see that. Annotations were invented by the Nazi's on the explicit instruction of Hitler. there, can someone now invoke Godwins law & call this discussion closed :-) -- Do what comes naturally. Seethe and fume and throw a tantrum. -- https://mail.python.org/mailman/listinfo/python-list
Feeding the trolls
On 2018-06-20 08:10 AM, Tim Golden wrote: > [... snip discussions about Bart's language ...] > > Wearing my moderator hat > > Can we take the "Bart's language vs Python Show" to some other forum, > please? We've already gone over this ground again and again and it isn't > helping the signal-to-noise ratio here on the Python list / > comp.lang.python Thank you. Many of us have blocked rick and bart years ago. If you are just going to feed the trolls we have to see their nonsense anyway. Just email them privately if you really feel the need to vent. One of these days I will have to figure out how to block replies to the trolls as well. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:da...@vex.net VoIP: sip:da...@vybenetworks.com -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
It isn't about my language versus Python. It is about the surprising number of simple features that are missing and that people are claiming don't matter, despite the considerable efforts made to provide them via add-ons. But I'm glad you stepped because making these posts via a smartphone AND google groups is a rather painful experience. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
[... snip discussions about Bart's language ...] Wearing my moderator hat Can we take the "Bart's language vs Python Show" to some other forum, please? We've already gone over this ground again and again and it isn't helping the signal-to-noise ratio here on the Python list / comp.lang.python Thanks TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, 20 Jun 2018 03:43:17 -0700, bart4858 wrote: > I'm saying > that Python which is always touted as a 'simple' language suitable for > beginners, is missing a surprising number of basics. You call them "basics". Must of us call most of them "unnecessary bloat". What we call "the basics", like the object execution module which you hate so much, *you* call "unnecessary bloat". THAT is the blub paradox, which you have completely failed to grok. I consider a seamless and easy way to open, incrementally read line by line, and close, a Unicode text file like this: with open(somefile, "r", encoding='spam', errors='eggs') as f: # for some value of spam and eggs :-) for line in f: process(line) to be "the basics". If your language doesn't do that, to me it is too primitive to use. You, on the other hand, probably consider the idea of context managers and iterators and Unicode to be unnecessary bloat, and think that any language which doesn't have a 1970-style Pascal read()/ readln() function is missing "the basics". -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, Jun 20, 2018 at 9:53 PM, wrote: > Pointers are perhaps a more technical feature. Switch and case, the latter a > more general version of switch, are universal. > > > Repeat n times is universal. While it is trivial to implement with other > constructs, it as an annoyance and distraction that is easily fixed. > > Now you will probably say it is possible to do without loops at all, or > without selecting from one of multiple execution paths (by using functional > approaches). I suggest that such features just make life a little simpler. > (And make writing an efficient interpreter a little bit easier.) > Interesting that you want a "repeat N times" construct rather than "for _ in range(n):", for efficiency; but you're happy to have pointers, which prevent many forms of optimization. The instant you have a pointer, you are forced to store that data at that location in memory, in case something dereferences that pointer. Python, on the other hand, is free to optimize things down to a stack, so long as there's no semantic difference. Also: how do you do memory management when you have pointers? Or do you give that job to the programmer? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Pointers are perhaps a more technical feature. Switch and case, the latter a more general version of switch, are universal. Repeat n times is universal. While it is trivial to implement with other constructs, it as an annoyance and distraction that is easily fixed. Now you will probably say it is possible to do without loops at all, or without selecting from one of multiple execution paths (by using functional approaches). I suggest that such features just make life a little simpler. (And make writing an efficient interpreter a little bit easier.) -- https://mail.python.org/mailman/listinfo/python-list
Re: command line utility for cups
On Wed, 2018-06-20 at 12:36 +0200, George Fischhof wrote: > Hi, > You can also try click library from pypi, that is a very good command line > stuff. > > George Thank you for the tip. I am away of click and it's awesomeness, but am hesitant because it's not apart of stdlib. I have gotten bitten too often. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, Jun 20, 2018 at 8:43 PM, wrote: > Yeah, people keep bringing that up when they run out of arguments. > > So, every programmer must always use the most advanced, most esoteric > features possible at every opportunity? Coding should only be for the elite? > > There is a place for various levels of programming language. I'm saying that > Python which is always touted as a 'simple' language suitable for beginners, > is missing a surprising number of basics. The whole point of the Blub Paradox is that you, from your perspective, perceive pointers and such as "basics", whereas someone who is ACTUALLY new to programming does not want or need them. And I can say this for certain because I frequently work with people who have never written a line of code in their lives. Python has tools that help them to solve real-world problems. It does not have toys that let you write high-level C code. Since you apparently have never used the bulk of Python's features, you don't value them. They are above you on the Blub scale. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: command line utility for cups
Thanks Peter! That's pretty slick. I will get it working for sure now. Regards, Brian -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Yeah, people keep bringing that up when they run out of arguments. So, every programmer must always use the most advanced, most esoteric features possible at every opportunity? Coding should only be for the elite? There is a place for various levels of programming language. I'm saying that Python which is always touted as a 'simple' language suitable for beginners, is missing a surprising number of basics. That these are useful is demonstrated by the cumbersome add-ons that need to be used to provide that functionality. Often in over the top ways and often in a bewildering variety of ways in the case of records. -- https://mail.python.org/mailman/listinfo/python-list
Re: command line utility for cups
Peter Otten <__pete...@web.de> ezt írta (időpont: 2018. jún. 20., Sze
12:22):
> Brian Oney via Python-list wrote:
>
> > Dear all,
> >
> > I am having trouble with argparse. I am trying to translate the following
> > line to a sleek python script:
> >
> > lpr -o media=legal -o sides=two-sided-long-edge filename
> >
> > Now where I am.
> >
> > import argparse
> > parser = argparse.ArgumentParser(description='Print stuff with cups')
> > parser.add_argument('--printer', '-p',
> > help='Use this printer, try running: lpstat -a')
> > parser.add_argument('--options', '-o',
> > help='Options for this printer, try running: \
> > lpoptions -p PRINTER -l')
> >
> > parser.parse_known_args(['-o', 'sides=one-sided', '-o', 'test=crap'])
> > Namespace(options='test=crap', printer=None))
> >
> > How should I deal with multiple options being fed into my script?
> >
> > Thanks!
>
> Try action="append". You may also provide a type=split_func argument to
> split the key=value pairs:
>
> >>> import argparse
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument("-o", action="append", type=lambda p: p.split("=",
> 1))
> _AppendAction(option_strings=['-o'], dest='o', nargs=None, const=None,
> default=None, type= at 0x7feef70a8510>, choices=None,
> help=None, metavar=None)
> >>> parser.parse_args(["-o", "a=b", "-o", "c=d"])
> Namespace(o=[['a', 'b'], ['c', 'd']])
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
Hi,
You can also try click library from pypi, that is a very good command line
stuff.
George
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: command line utility for cups
Brian Oney via Python-list wrote:
> Dear all,
>
> I am having trouble with argparse. I am trying to translate the following
> line to a sleek python script:
>
> lpr -o media=legal -o sides=two-sided-long-edge filename
>
> Now where I am.
>
> import argparse
> parser = argparse.ArgumentParser(description='Print stuff with cups')
> parser.add_argument('--printer', '-p',
> help='Use this printer, try running: lpstat -a')
> parser.add_argument('--options', '-o',
> help='Options for this printer, try running: \
> lpoptions -p PRINTER -l')
>
> parser.parse_known_args(['-o', 'sides=one-sided', '-o', 'test=crap'])
> Namespace(options='test=crap', printer=None))
>
> How should I deal with multiple options being fed into my script?
>
> Thanks!
Try action="append". You may also provide a type=split_func argument to
split the key=value pairs:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("-o", action="append", type=lambda p: p.split("=",
1))
_AppendAction(option_strings=['-o'], dest='o', nargs=None, const=None,
default=None, type= at 0x7feef70a8510>, choices=None,
help=None, metavar=None)
>>> parser.parse_args(["-o", "a=b", "-o", "c=d"])
Namespace(o=[['a', 'b'], ['c', 'd']])
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On Wed, Jun 20, 2018 at 7:35 PM, wrote: > (Sorry no idea how to do quoting on this mobile app I have to use.) > > Those examples of using network features are merely examples of function > calls. This is what I'm talking about with basic language features. > > Pointers are merely an extra level of indirection; they can be made to fit. > > A few things might need language help, or help from its runtime. So that if I > wanted a pointer to the first byte of this programs image on windows, I'd > have to do: > > P := makeref(0x40', byte) > > Which I then access as P^. The stuff you're talking about, imo, is at a > completely different level. Someone could take core Python and repackage it > with a completely different set of libraries. What happened to the network > stuff? > http://wiki.c2.com/?BlubParadox ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
(Sorry no idea how to do quoting on this mobile app I have to use.) Those examples of using network features are merely examples of function calls. This is what I'm talking about with basic language features. Pointers are merely an extra level of indirection; they can be made to fit. A few things might need language help, or help from its runtime. So that if I wanted a pointer to the first byte of this programs image on windows, I'd have to do: P := makeref(0x40', byte) Which I then access as P^. The stuff you're talking about, imo, is at a completely different level. Someone could take core Python and repackage it with a completely different set of libraries. What happened to the network stuff? -- https://mail.python.org/mailman/listinfo/python-list
command line utility for cups
Dear all,
I am having trouble with argparse. I am trying to translate the following line
to a sleek python
script:
lpr -o media=legal -o sides=two-sided-long-edge filename
Now where I am.
import argparse
parser = argparse.ArgumentParser(description='Print stuff with cups')
parser.add_argument('--printer', '-p',
help='Use this printer, try running: lpstat -a')
parser.add_argument('--options', '-o',
help='Options for this printer, try running: \
lpoptions -p PRINTER -l')
parser.parse_known_args(['-o', 'sides=one-sided', '-o', 'test=crap'])
Namespace(options='test=crap', printer=None))
How should I deal with multiple options being fed into my script?
Thanks!
Cheers,
Brian
--
https://mail.python.org/mailman/listinfo/python-list
