Can one make 'in' ungreedy?
I have a strange/minor problem in a Python program I use for mail
filtering.
One of the ways it classifies messages is by searching for a specific
string in square brackets [] in the Subject:, the section of code that
does this is:-
#
#
# copy the fields from the filter configuration file into better named
variables
#
nm = fld[0] # name/alias
dd = fld[1] + "/" # destination directory
tocc = fld[2].lower() # list address
sbstrip = '[' + fld[3] + ']'# string to match in and/or strip out
of subject
#
#
# see if the filter To/CC column matches the message To: or Cc: or if
sbstrip is in Subject:
#
if (tocc in msgcc or tocc in msgto or sbstrip in msgsb):
#
#
# set the destination directory
#
dest = mldir + dd + nm
#
#
# Strip out list name (4th field) from subject if it's there
#
if sbstrip in msgsb:
msg.replace_header("Subject", msgsb.replace(sbstrip, ''))
#
#
# we've found a match so assume we won't get another
#
break
So in the particular case where I have a problem sbstrip is "[Ipswich
Recycle]" and the Subject: is "[SPAM] [Ipswich Recycle] OFFER:
Lawnmower (IP11)". The match isn't found, presumably because 'in' is
greedy and sees "[SPAM] [Ipswich Recycle]" which isn't a match for
"[Ipswich Recycle]".
Other messages with "[Ipswich Recycle]" in the Subject: are being
found and filtered correctly, it seems that it's the presence of the
"[SPAM]" in the Subject: that's breaking things.
Is this how 'in' should work, it seems a little strange if so, not
intuitively how one would expect 'in' to work. ... and is there any
way round the issue except by recoding a separate test for the
particular string search where this can happen?
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can one make 'in' ungreedy?
On Mon, May 18, 2020 at 7:05 AM Chris Green wrote:
>
> I have a strange/minor problem in a Python program I use for mail
> filtering.
>
> One of the ways it classifies messages is by searching for a specific
> string in square brackets [] in the Subject:, the section of code that
> does this is:-
>
> #
> #
> # copy the fields from the filter configuration file into better named
> variables
> #
> nm = fld[0] # name/alias
> dd = fld[1] + "/" # destination directory
> tocc = fld[2].lower() # list address
> sbstrip = '[' + fld[3] + ']'# string to match in and/or strip out
> of subject
> #
> #
> # see if the filter To/CC column matches the message To: or Cc: or if
> sbstrip is in Subject:
> #
> if (tocc in msgcc or tocc in msgto or sbstrip in msgsb):
> #
> #
> # set the destination directory
> #
> dest = mldir + dd + nm
> #
> #
> # Strip out list name (4th field) from subject if it's there
> #
> if sbstrip in msgsb:
> msg.replace_header("Subject", msgsb.replace(sbstrip, ''))
> #
> #
> # we've found a match so assume we won't get another
> #
> break
>
>
> So in the particular case where I have a problem sbstrip is "[Ipswich
> Recycle]" and the Subject: is "[SPAM] [Ipswich Recycle] OFFER:
> Lawnmower (IP11)". The match isn't found, presumably because 'in' is
> greedy and sees "[SPAM] [Ipswich Recycle]" which isn't a match for
> "[Ipswich Recycle]".
>
> Other messages with "[Ipswich Recycle]" in the Subject: are being
> found and filtered correctly, it seems that it's the presence of the
> "[SPAM]" in the Subject: that's breaking things.
>
> Is this how 'in' should work, it seems a little strange if so, not
> intuitively how one would expect 'in' to work. ... and is there any
> way round the issue except by recoding a separate test for the
> particular string search where this can happen?
>>> sbstrip = "[Ipswich Recycle]"
>>> subject = "[SPAM] [Ipswich Recycle] OFFER:Lawnmower (IP11)"
>>> sbstrip in subject
True
Clearly something else is going on in your program. I would run it in
the debugger and look at the values of the variables in the case when
it fails when you think it should succeed. I think you will see the
variables do not hold what you think they do.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can one make 'in' ungreedy?
Larry Martell wrote:
> On Mon, May 18, 2020 at 7:05 AM Chris Green wrote:
> >
> > I have a strange/minor problem in a Python program I use for mail
> > filtering.
> >
> > One of the ways it classifies messages is by searching for a specific
> > string in square brackets [] in the Subject:, the section of code that
> > does this is:-
> >
> > #
> > #
> > # copy the fields from the filter configuration file into better named
> > variables
> > #
> > nm = fld[0] # name/alias
> > dd = fld[1] + "/" # destination directory
> > tocc = fld[2].lower() # list address
> > sbstrip = '[' + fld[3] + ']'# string to match in and/or strip
> > out of subject
> > #
> > #
> > # see if the filter To/CC column matches the message To: or Cc: or if
> > sbstrip is in Subject:
> > #
> > if (tocc in msgcc or tocc in msgto or sbstrip in msgsb):
> > #
> > #
> > # set the destination directory
> > #
> > dest = mldir + dd + nm
> > #
> > #
> > # Strip out list name (4th field) from subject if it's there
> > #
> > if sbstrip in msgsb:
> > msg.replace_header("Subject", msgsb.replace(sbstrip, ''))
> > #
> > #
> > # we've found a match so assume we won't get another
> > #
> > break
> >
> >
> > So in the particular case where I have a problem sbstrip is "[Ipswich
> > Recycle]" and the Subject: is "[SPAM] [Ipswich Recycle] OFFER:
> > Lawnmower (IP11)". The match isn't found, presumably because 'in' is
> > greedy and sees "[SPAM] [Ipswich Recycle]" which isn't a match for
> > "[Ipswich Recycle]".
> >
> > Other messages with "[Ipswich Recycle]" in the Subject: are being
> > found and filtered correctly, it seems that it's the presence of the
> > "[SPAM]" in the Subject: that's breaking things.
> >
> > Is this how 'in' should work, it seems a little strange if so, not
> > intuitively how one would expect 'in' to work. ... and is there any
> > way round the issue except by recoding a separate test for the
> > particular string search where this can happen?
>
> >>> sbstrip = "[Ipswich Recycle]"
> >>> subject = "[SPAM] [Ipswich Recycle] OFFER:Lawnmower (IP11)"
> >>> sbstrip in subject
> True
>
> Clearly something else is going on in your program. I would run it in
> the debugger and look at the values of the variables in the case when
> it fails when you think it should succeed. I think you will see the
> variables do not hold what you think they do.
Thanks for taking the trouble to look. It's a *bit* difficult to run
in the debugger as the program is a filter triggered by incoming
E-Mail messages. However I think I can fire stuff at it via stdin so
I'll see what I can fathon out doing that.
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can one make 'in' ungreedy?
>
> Thanks for taking the trouble to look. It's a *bit* difficult to run
> in the debugger as the program is a filter triggered by incoming
> E-Mail messages. However I think I can fire stuff at it via stdin so
> I'll see what I can fathon out doing that.
>
Cheapo debug trick: When your filter starts, have it open a file in /tmp
(or similar) with "a" mode, leaving that file object as a global variable.
Then at points of interest, print out useful values to that open file
object. Once you've got your logic sorted, either remove the code, comment
it out, or predicate its action based on some debug flag. Briefly, using
Larry's example:
DBG_FP = open("/tmp/ipswich", "a")
You might also want to print the message's message-id to DBG_FP at this
point. It will serve as a useful separator between debug output for
different messages.
Sometime later:
print("subject:", subject, file=DBG_FP)
print("ipswich?", ipswich in subject, file=DBG_FP)
And so on. If there is some conditional nesting/looping going on, it can be
useful to also include a unique number in each print call in case it's not
immediately apparent where a particular record in your file came from.
print(1, "subject:", subject, file=DBG_FP)
print(2, "ipswich?", ipswich in subject, file=DBG_FP)
I started using Python long before there were any fancy debuggers available
(never cottoned to pdb for some reason), so print statements were a very
common way to debug logic errors. I must confess to continuing to rely on
them instead of figuring out how to use modern IDEs (I'm still an Emacs guy
anyway, so IDEs seem to suck as a way to edit code).
Skip
--
https://mail.python.org/mailman/listinfo/python-list
python3 - Import python file as module
Hi,
I am a beginner to Python. I want to achieve the following:
My directory structure:
a
└── b
└── c
├── p
│ └── q
│ └── test.py
└── x
└── y
└── run.py
In my run.py file, I want to import everything from test.py(contains methods).
I have found relative path for test.py as "p.q".
I tried with exec() to import as : exec("from p.q import *"),
but this gives me >> "list out of index" error.
Then I tried with importlib.import_module with various combinations such as:
1. importlib.import_module('.test', package="p.q")
2. importlib.import_module('test', package="p.q")
3. importlib.import_module('p.q.test', package=None)
But I end up getting error as >> No module found "".
Can anyone help me with this situation?
Any help will be appreciated!
Thank you.
--
CONFIDENTIALITY. This email and any attachments are confidential to Alef
Edge Inc., and may also be privileged, except where the email states it can
be disclosed. If this email is received in error, please do not disclose
the contents to anyone, notify the sender by return email, and delete this
email (and any attachments) from your system.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can one make 'in' ungreedy?
Larry Martell wrote:
> On Mon, May 18, 2020 at 7:05 AM Chris Green wrote:
> >
> > I have a strange/minor problem in a Python program I use for mail
> > filtering.
> >
> > One of the ways it classifies messages is by searching for a specific
> > string in square brackets [] in the Subject:, the section of code that
> > does this is:-
> >
> > #
> > #
> > # copy the fields from the filter configuration file into better named
> > variables
> > #
> > nm = fld[0] # name/alias
> > dd = fld[1] + "/" # destination directory
> > tocc = fld[2].lower() # list address
> > sbstrip = '[' + fld[3] + ']'# string to match in and/or strip
> > out of subject
> > #
> > #
> > # see if the filter To/CC column matches the message To: or Cc: or if
> > sbstrip is in Subject:
> > #
> > if (tocc in msgcc or tocc in msgto or sbstrip in msgsb):
> > #
> > #
> > # set the destination directory
> > #
> > dest = mldir + dd + nm
> > #
> > #
> > # Strip out list name (4th field) from subject if it's there
> > #
> > if sbstrip in msgsb:
> > msg.replace_header("Subject", msgsb.replace(sbstrip, ''))
> > #
> > #
> > # we've found a match so assume we won't get another
> > #
> > break
> >
> >
> > So in the particular case where I have a problem sbstrip is "[Ipswich
> > Recycle]" and the Subject: is "[SPAM] [Ipswich Recycle] OFFER:
> > Lawnmower (IP11)". The match isn't found, presumably because 'in' is
> > greedy and sees "[SPAM] [Ipswich Recycle]" which isn't a match for
> > "[Ipswich Recycle]".
> >
> > Other messages with "[Ipswich Recycle]" in the Subject: are being
> > found and filtered correctly, it seems that it's the presence of the
> > "[SPAM]" in the Subject: that's breaking things.
> >
> > Is this how 'in' should work, it seems a little strange if so, not
> > intuitively how one would expect 'in' to work. ... and is there any
> > way round the issue except by recoding a separate test for the
> > particular string search where this can happen?
>
> >>> sbstrip = "[Ipswich Recycle]"
> >>> subject = "[SPAM] [Ipswich Recycle] OFFER:Lawnmower (IP11)"
> >>> sbstrip in subject
> True
>
> Clearly something else is going on in your program. I would run it in
> the debugger and look at the values of the variables in the case when
> it fails when you think it should succeed. I think you will see the
> variables do not hold what you think they do.
Absolutely right! It wasn't even this program had the problem, the
odd messages in the wrong place were arriving via my 'catchall' mail
filter which deposited stuff by an entirely different route into my
inbox! Typical - looking for the bug in the wrong program. :-)
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
Re: python3 - Import python file as module
[email protected] wrote: > Hi, > I am a beginner to Python. I want to achieve the following: > > My directory structure: > > a > └── b > └── c > ├── p > │ └── q > │ └── test.py > └── x > └── y > └── run.py > > In my run.py file, I want to import everything from test.py(contains > methods). > > I have found relative path for test.py as "p.q". > I tried with exec() to import as : exec("from p.q import *"), > but this gives me >> "list out of index" error. I do not recognize that error. Is this cut-and-paste? > Then I tried with importlib.import_module with various combinations such > as: 1. importlib.import_module('.test', package="p.q") > 2. importlib.import_module('test', package="p.q") > 3. importlib.import_module('p.q.test', package=None) Why are you trying import_module() or exec() when you know the location of the module you want to import? > But I end up getting error as >> No module found "". > > Can anyone help me with this situation? You need to make sure that a is in your sys.path and that the importing module is itself imported using the complete path. For example: Given $ tree . └── a └── b └── c ├── p │ └── q │ └── test.py └── x └── y └── run.py 7 directories, 2 files $ cat a/b/c/p/q/test.pydef hello(): print("Hello, world!") $ cat a/b/c/x/y/run.py from ...p.q.test import hello hello() you can run your run.py with $ python3 -m a.b.c.x.y.run Hello, world! but not with $ python3 a/b/c/x/y/run.py Traceback (most recent call last): File "a/b/c/x/y/run.py", line 1, in from ...p.q.test import hello SystemError: Parent module '' not loaded, cannot perform relative import because here run.py is a standalone script from Python's point of view rather than part of a package hierarchy. In general you can never go higher than the toplevel package, so this also fails: $ cd a/b/c $ python3 -m x.y.run Traceback (most recent call last): File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.4/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/petto/srcx/clpy/shivani/a/b/c/x/y/run.py", line 1, in from ...p.q.test import hello ValueError: attempted relative import beyond top-level package While this works $ cd .. $ python3 -m c.x.y.run Hello, world! it is a good idea to decide on the root package once and for all, and then only import starting from that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can one make 'in' ungreedy?
Chris Green wrote at 2020-5-18 11:50 +0100: > ... >So in the particular case where I have a problem sbstrip is "[Ipswich >Recycle]" and the Subject: is "[SPAM] [Ipswich Recycle] OFFER: >Lawnmower (IP11)". The match isn't found, presumably because 'in' is >greedy and sees "[SPAM] [Ipswich Recycle]" which isn't a match for >"[Ipswich Recycle]". `in` directly matches substrings; it is not greedy. -- https://mail.python.org/mailman/listinfo/python-list
Sphinx plugin to make easier-to-navigate class documentation
I'm writing to share a Sphinx plugin I wrote, which I think makes the documentation for large classes much easier to navigate and understand. The plugin is called `autoclasstoc` and you can find the documentation here: https://autoclasstoc.readthedocs.io/en/latest/ I wrote this plugin because, while restructured text and Sphinx are great in a lot of ways, I've always been disappointed by the options for documenting classes. `autoclass` is easy to use, but hard to read because all of the methods are just documented one after another with no index at the top. `autosummary` and `autogen` can be used together to create such an index, but they're more difficult to setup, and the index doesn't distinguish nicely between inherited and non-inherited methods. My plugin is modeled after the way `doxygen` (a popular documentation tool for C++ projects) works. The documentation for each class starts with an index of all it's methods/attributes. Inherited methods are organized by the class they inherit from, and collapsed so they don't distract too much from the methods actually defined in the class itself. I'm pretty happy with how the plugin turned out, and I hope that other people might find it useful, too. If you decide to give it a try, let me know (either here or, preferably, on Github) if there's anything you'd change. I'm happy to get feedback, because I threw this together pretty quickly and I'm sure there are use-cases I haven't fully considered yet. -Kale -- https://mail.python.org/mailman/listinfo/python-list
Re: Sphinx plugin to make easier-to-navigate class documentation
On 05/18/2020 09:46 AM, Kale Kundert wrote: I'm writing to share a Sphinx plugin I wrote, which I think makes the documentation for large classes much easier to navigate and understand. The plugin is called `autoclasstoc` and you can find the documentation here: https://autoclasstoc.readthedocs.io/en/latest/ This sounds pretty cool! You should also post this on [email protected] to reach a wider audience. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Determining index of range of values in a matrix
Hi All, I am using python for doing the following: I have a matrix which has dimension of 174*993. Each row of the matrix has some numbers in the range of 30-30.5. I would like to determine the index of the numbers in the range of 30-30.5 in each row. I can determine the index of the numbers in each row by using result1=np.where(np.logical_and(R[i,:]>= 30, R[i,:]<= 30.3)) But I would like to put the indexes in a matrix. That is difficult because the number of indexes in each row will be different. Can anyone help. Regards, Swaroop -- https://mail.python.org/mailman/listinfo/python-list
why no camelCase in PEP 8?
I've been using Python for about 18 years. Several things have changed in the language in those years. I don't disagree with most of it, but one of the things that annoys me is the disapproval of using camelCase to name symbols such as variables, functions, etc. I think PEP 8, the "Style Guide for Python Code" (https://www.python.org/dev/peps/pep-0008/), came out shortly after I began using Python. I think the old habits of the people I worked with and the relative lack of tools like Flake8 and Pylint led to the standard being ignored. However, now I see many developers really want to adhere to the standard. My preference for using camelCase (in PEP 8, AKA mixedCase) is putting me at odds with my colleagues, who point to PEP 8 as "the rules". I have reasons for my preferring camelCase. I suspect the reasons the PEP 8 authors have for not using it are probably as strong as my reasons. So our reasons probably nullify each other and what's left is simple preference. So, I'd like to know what was the reason behind favoring snake_case (AKA lower_case_with_underscores) in PEP 8 instead of camelCase. Does anyone in this group know? -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
On Tue, May 19, 2020 at 5:51 AM Lance E Sloan wrote: > > I've been using Python for about 18 years. Several things have changed in > the language in those years. I don't disagree with most of it, but one of > the things that annoys me is the disapproval of using camelCase to name > symbols such as variables, functions, etc. > > I think PEP 8, the "Style Guide for Python Code" > (https://www.python.org/dev/peps/pep-0008/), came out shortly after I began > using Python. I think the old habits of the people I worked with and the > relative lack of tools like Flake8 and Pylint led to the standard being > ignored. However, now I see many developers really want to adhere to the > standard. > > My preference for using camelCase (in PEP 8, AKA mixedCase) is putting me at > odds with my colleagues, who point to PEP 8 as "the rules". I have reasons > for my preferring camelCase. I suspect the reasons the PEP 8 authors have > for not using it are probably as strong as my reasons. So our reasons > probably nullify each other and what's left is simple preference. > > So, I'd like to know what was the reason behind favoring snake_case (AKA > lower_case_with_underscores) in PEP 8 instead of camelCase. > > Does anyone in this group know? PEP 8 is a style guide for the Python standard library. It is the rules you must comply with if you are submitting a patch *to Python itself*. Nobody ever requires you to comply with it for any other code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Subprocess Popen confusion
In article , [email protected] says... > > Dick Holmes wrote: > > > https://occovid19.ochealthinfo.com/coronavirus-in-oc > > > I'm trying to > > communicate using a continuing dialog between two > > processes on the same system. > > I think pexpect > > https://pexpect.readthedocs.io/en/stable/index.html > > does this naturally, but I don't know if Windows support is sufficient for > your needs. > > > I've looked at various mechanisms and the > > class that seems to fit my needs is Popen in the subprocess module, but > > I can't seem to get more than a single round-trip message through Popen. > > I first call Popen then poll using the identifier returned from the call > > and the poll seems to work. I then call the communicate function passing > > None as the value to send to the companion process stdin. I get the > > expected result, but I also get "Exception condition detected on fd 0 > > \\n" and "error detected on stdin\\n". Subsequent attempts to > > read/write/communicate with the subprocess fail because the file (stdxx > > PIPE) is closed. > > > > I can't tell from the documentation if the communicate function is a > > one-time operation. > > Yes, communicate() is one-off, > > > """Interact with process: Send data to stdin and close it. > Read data from stdout and stderr, until end-of-file is > reached. Wait for process to terminate. > ... > """ > > seems pretty clear. What would you improve? > > > I have tried using read but the read call doesn't > > return (I'm using winpdb-reborn to monitor the operations). > > Try readline(). Deadlocks may happen ;) > > > I'm using Python 3.7, Windows 10, winpdb-reborn 2.0.0, rpdb2 1.5.0. If > > it makes any difference, I'm trying to communicate with GDB using the MI > > interpreter. > > Per Peter's suggestion I tried readline and it works "as expected". I also discovered that the reason the read operations were stalling was that they followed a write and the write doesn't actually occur until "flush" is called even though the function call returns. There are undoubtedly some subtleties lurking about, but at least I'm making good progress. Thanks for the help! Dick -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
In comp.lang.python, Paul Rubin wrote: > I don't know if this was the explicit motivation for PEP 8, but it > has always seemed valid to me: > > https://en.wikipedia.org/wiki/Camel_case#Readability_studies There are three things cited there. One is a NYTimes story from 2009 "Against Camel Case" starting out with criticism of "iPhone" which the author describes but won't use as it it too difiguring. That's not a programmer talking about program identifiers. The other two are more relevant, two studies one from 2009 and one from 2010, each of which seems to reach a conclusion at odds with the other. The 2009 one finds camelCase easier to read than snake_case, and the 2010 one finds people recognize snake_case identifiers faster than camelCase ones. I don't think that Wikipedia page helps your case. I personally abhor the use of inappropriate mid-word caps in English, which fits the NYT piece, but am only mildly against them in code. I had some bad expierences with code that forced use of capital letters in college and that has tainted me against excess capitals ever since. This is a highly personal reason that I don't expect anyone else to share. Here's a simple argument against camel case: when it becomes necessary to join identifiers, camel case requires modification of the original unit while snake case just adds stuff to beginning and/or end. One noteworthy example is when a negated version is needed. camelCase -> noCamelCase snake_case -> no_snake_case One of those is easier to "grep" for than the other. Elijah -- grep-ability of code should on everyone's mond -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
On Tue, May 19, 2020 at 7:11 AM Eli the Bearded <*@eli.users.panix.com> wrote: > Here's a simple argument against camel case Here's an even simpler argument. XMLHttpRequest ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
Hello! We have now moved into a pros/cons discussion of snake vs camel-case, which wasn't the original question. But discussions about coding styles are always fun, so why not... :-) I agree with Eli's reasoning about the grep-ability. It's something that people don't often pay attention to, but that is actually really important. One more note about the readability: A good friend of mine is a great developer, but has incredibly poor eye-sight. For him it's very important that the code has easily recognizable patterns. Imagine you'd have to try to make sense of code when you could only squint at the screen and see everything fuzzy and you get the idea. For what are now immediately obvious reasons he prefers snake-case. His concerns about reading code and recognizable patterns have been a guide in the development of my own coding style for more than 20 years now and it has served me well. Juergen On Mon, 2020-05-18 at 21:07 +, Eli the Bearded wrote: > In comp.lang.python, Paul Rubin wrote: > > I don't know if this was the explicit motivation for PEP 8, but it > > has always seemed valid to me: > > > > https://en.wikipedia.org/wiki/Camel_case#Readability_studies > > There are three things cited there. One is a NYTimes story from 2009 > "Against Camel Case" starting out with criticism of "iPhone" which > the author describes but won't use as it it too difiguring. That's > not a > programmer talking about program identifiers. > > The other two are more relevant, two studies one from 2009 and one > from > 2010, each of which seems to reach a conclusion at odds with the > other. > The 2009 one finds camelCase easier to read than snake_case, and the > 2010 one finds people recognize snake_case identifiers faster than > camelCase ones. I don't think that Wikipedia page helps your case. > > I personally abhor the use of inappropriate mid-word caps in English, > which fits the NYT piece, but am only mildly against them in code. I > had > some bad expierences with code that forced use of capital letters in > college and that has tainted me against excess capitals ever since. > This > is a highly personal reason that I don't expect anyone else to share. > > Here's a simple argument against camel case: when it becomes > necessary > to join identifiers, camel case requires modification of the original > unit while snake case just adds stuff to beginning and/or end. One > noteworthy example is when a negated version is needed. > > camelCase -> noCamelCase > snake_case -> no_snake_case > > One of those is easier to "grep" for than the other. > > Elijah > -- > grep-ability of code should on everyone's mond -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
On Tue, 19 May 2020 09:55:04 +1200 Juergen Brendel wrote: > ... he prefers snake-case. That's not snake_case. That's kebab-case.¹ ¹ https://wiki.c2.com/?KebabCase -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
On Mon, 2020-05-18 at 19:28 -0400, Dan Sommers wrote: > On Tue, 19 May 2020 09:55:04 +1200 > Juergen Brendel wrote: > > > ... he prefers snake-case. > > That's not snake_case. That's kebab-case.¹ > > ¹ https://wiki.c2.com/?KebabCase :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: why no camelCase in PEP 8?
In comp.lang.python, Paul Rubin wrote: > Eli the Bearded <*@eli.users.panix.com> writes: >> One of those is easier to "grep" for than the other. > grep -i might help. Or might not, if I want case sensitivity in the rest of my RE. Elijah -- can, but doesn't want to, build REs that are flexible about partial sensitivity -- https://mail.python.org/mailman/listinfo/python-list
