Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Directory name changes are not managed#1

Open
dfranganillo wants to merge 11 commits into
mathom:mastermathom/python-inotify:masterfrom
dfranganillo:masterdfranganillo/python-inotify:masterCopy head branch name to clipboard
Open

Directory name changes are not managed#1
dfranganillo wants to merge 11 commits into
mathom:mastermathom/python-inotify:masterfrom
dfranganillo:masterdfranganillo/python-inotify:masterCopy head branch name to clipboard

Conversation

@dfranganillo

Copy link
Copy Markdown

Whenever a directory name changes, even though the wd is the same, _wds and _paths directories are not updated.

@mathom

mathom commented Jun 26, 2013

Copy link
Copy Markdown
Owner

Thanks for the contribution! I'll definitely be taking a look at this after work.

@bos has an upstream repository at https://bitbucket.org/bos/python-inotify/ (though it's in mercurial). I actually made this so my coworkers could easily use it as we're a git shop. If he would prefer to run the mirror on github I'd be glad to swap this repository over to him 😀

@dfranganillo

Copy link
Copy Markdown
Author

Wow, I really searched for the original repo of the original author @bos , sorry I didn't found it!! Anyway, I cannot find any differences between your repo and the original from bos so being it an almost forgotten repo we could continue from this point onwards.

@mathom

mathom commented Jun 27, 2013

Copy link
Copy Markdown
Owner

Just a little update!

I've hooked up nosetests to our setup.py so we can add some unit tests for this stuff (and the core functionality). It's in the new tests branch: https://github.com/mathom/python-inotify/tree/tests

@dfranganillo

Copy link
Copy Markdown
Author

I've pushed some more commits, one of them is quite critical as it solves a big memory leak.

@mathom

mathom commented Mar 28, 2014

Copy link
Copy Markdown
Owner

Hey, thanks for the update. I'll review them when I get a chance. Sorry for not getting on your earlier changes - I've been quite busy!

@dfranganillo

Copy link
Copy Markdown
Author

No problem!

Comment thread inotify/watcher.py Outdated

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which exceptions are being caught here? We usually try to avoid blanket exceptions like this.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed that ugly exception :/

Comment thread inotify/watcher.py Outdated

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment about exception. We generally avoid them because they can mask deeper issues in the code. If you want you can catch a specific instance of an exception class I'd be 100% onboard.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this one was trying to ignore _remove exceptions and I forgot to
remove the handler.

2014-03-28 16:47 GMT+01:00 Matthew Thompson notifications@github.com:

In inotify/watcher.py:

@@ -177,11 +192,15 @@ def read(self, bufsize=None):

     events = []
     for evt in inotify.read(self.fd, bufsize):
  •        events.append(Event(evt, self._wds[evt.wd][0]))
    
  •        if evt.mask & inotify.IN_IGNORED:
    
  •            self._remove(evt.wd)
    
  •        elif evt.mask & inotify.IN_UNMOUNT:
    
  •            self.close()
    
  •        try:
    
  •            if evt.mask & inotify.IN_IGNORED:
    
  •                self._remove(evt.wd)
    
  •            elif evt.mask & inotify.IN_UNMOUNT:
    
  •                self.close()
    
  •            else:
    
  •                events.append(Event(evt, self._wds[evt.wd][0]))
    
  •        except:
    

See above comment about exception. We generally avoid them because they
can mask deeper issues in the code. If you want you can catch a specific
instance of an exception class I'd be 100% onboard.

Reply to this email directly or view it on GitHubhttps://github.com//pull/1/files#r11071646
.


Daniel Franganillo Corrales

@mathom

mathom commented Mar 28, 2014

Copy link
Copy Markdown
Owner

Sorry if it seems like I'm nitpicking - we use this for a fairly important piece of our infrastructure so I'd want to make sure it's up to our internal standards before merging. 😄

@dfranganillo

Copy link
Copy Markdown
Author

No problem, there's always room to learn something 👍

@mrm-david

Copy link
Copy Markdown

I was wondering if there's any chance that it'll be merged someday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.