question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Regex on Part pins causes confusion

See original GitHub issue

When referring to pins by name, the regex interpretation causes confusion. I find it much clearer to refer to pins by name, rather than number. Is there a way of getting an exact match?

For example trying this part:

from skidl import *

j1 = Part('conn', 'USB_OTG')
print j1
print
print j1['D+']

As you can see, “D+” actually matches 5 pins!

 USB_OTG (): USB mini/micro connector
    Pin J1/1/VBUS/POWER-IN
    Pin J1/2/D-/PASSIVE
    Pin J1/3/D+/PASSIVE
    Pin J1/4/ID/PASSIVE
    Pin J1/5/GND/POWER-IN
    Pin J1/6/Shield/PASSIVE

[Pin J1/2/D-/PASSIVE, Pin J1/3/D+/PASSIVE, Pin J1/4/ID/PASSIVE, Pin J1/5/GND/POWER-IN, Pin J1/6/Shield/PASSIVE]

Yeah, I know I can write:

j1['^D\+$']

But that loses a lot of the clarity that I’m hoping to get from using SKiDL

Issue Analytics

  • State:open
  • Created 6 years ago
  • Comments:12 (1 by maintainers)

github_iconTop GitHub Comments

1reaction
chenzcommented, Feb 19, 2018

IMO, the change should be intrusive - i.e. regexp matching should only be used through dedicated “search” APIs, and name lookups should be implemented using simple string comparison or even dictionary lookups.

I only use name matching interactively from a repl when initially searching for stuff. From my code, I only ever want to look up a pin/part by it’s exact known name.

Implementing search and name-based getters separately also yields big performance gains when actually doing library searches, because the library loading code constantly checks if a part is already known by name… I experimented with this when initially checking out skidl, because searching the KiCAD library would take several minutes with python2 (with python3, it was quite a bit faster, but still too slow for interactive use). With string comparions, even with linear search it was then orders of magnitude faster (runtime was then bound by the shlex tokenizer).

0reactions
xesscorpcommented, Jun 5, 2020

I posted something about this issue on the forum.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Confusion with shell-globbing wildcards and Regex
I think your confusion is based on the differences between shell-globbing wildcards (the * character) and the regular expression symbol (the ...
Read more >
Improving the performance of regular expressions
One problem is when the regular expression does excessive backtracking; this can happen when there is more than one repetition operator in the ......
Read more >
Why Regular Expression is So Confusing? | Learn Web Tutorials
The reason why Regular Expression (also known as Regex) is so confusing is because they have symbols that means different things in different...
Read more >
Confusion about difference in GNU/macOS grep output when ...
This basically says, if the pattern matched ( r == 0 ) and if we are using -o ( oflag ), and if...
Read more >
An Introduction To Tableau Regular Expressions (REGEX)
Regular Expression Metacharacters Classes. In regular expressions, using the backslash with certain letters causes certain characters to do ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found