Yuval Greenfield added the comment:
Replacing `utf8` with `utf-8` is the best workaround in my situation. Using the
`utf8` alias is required to reproduce the issue based on my testing and the
cited issue (https://bugs.python.org/issue20844).
Thank you for the reference
Yuval Greenfield added the comment:
Note I am aware the actual problem is "utf8" vs "utf-8". But for some reason on
Windows the exception does not reflect that.
--
___
Python tracker
<https://bug
New submission from Yuval Greenfield :
These lines fail on Windows in a surprising way:
# -*- coding: utf8 -*-
import threading
print("threading %s" % threading)
Normally they would throw this:
```File
"C:\Python36\Lib\site-packages\missinglink_kernel\callback
Yuval Greenfield added the comment:
Ping. Has this been postponed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6818
___
___
Python-bugs-list
Changes by Yuval Greenfield ubershme...@gmail.com:
--
nosy: +ubershmekel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17927
___
___
Python-bugs
Yuval Greenfield ubershme...@gmail.com added the comment:
So, anybody for or against this patch? I'd really like to see this feature make
its way in...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13968
Yuval Greenfield ubershme...@gmail.com added the comment:
This isn't a bug and should be closed. It's more of a stack overflow question.
If you'd like to change this fundamental behavior of a very common operation in
python you should make a proposal to the python ideas mailing list at
http
Yuval Greenfield ubershme...@gmail.com added the comment:
If we're modifying zipfile, please consider adding the reviewed patch for
ZipFile.remove at http://bugs.python.org/issue6818
--
nosy: +ubershmekel
___
Python tracker rep...@bugs.python.org
Yuval Greenfield ubershme...@gmail.com added the comment:
I'm not sure I understand how http://bugs.python.org/review/6818/show works.
I've looked all over and only found remarks for zipfile.remove.patch and not
for zipfile.remove.2.patch which addressed all the aforementioned issues.
Also, I
Yuval Greenfield ubershme...@gmail.com added the comment:
I added the doublestar functionality to iglob and updated the docs and tests.
Also, a few readability renames in that module were a long time coming.
I'd love to hear your feedback.
--
Added file: http://bugs.python.org
New submission from Yuval Greenfield ubershme...@gmail.com:
This is the line in question:
http://hg.python.org/cpython/file/293180d199f2/Lib/http/server.py#l527
I was trying to test out a few html files using python -m http.server and it
took 4 seconds for each request, it was completely
Changes by Yuval Greenfield ubershme...@gmail.com:
--
type: - performance
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14622
___
___
Python-bugs
Yuval Greenfield ubershme...@gmail.com added the comment:
I agree with Antoine on this. Though the suggested patch is wrong. I believe we
should leave address_string alone. Simply stop the log_message method from
using it.
Either way we'd be changing the log format but if we don't have
Yuval Greenfield ubershme...@gmail.com added the comment:
I found this comprehensive description of the '**' convention at
http://www.codeproject.com/Articles/2809/Recursive-patterned-File-Globbing that
can translate directly to unittests.
I'd like to fix the patch for these specs but should
Yuval Greenfield ubershme...@gmail.com added the comment:
I don't have a strong opinion on rglob vs glob so whichever way the majority
here thinks is fine by me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13968
Yuval Greenfield ubershme...@gmail.com added the comment:
On Sun, Apr 1, 2012 at 4:42 PM, Serhiy Storchaka rep...@bugs.python.org wrote:
For ** globbing see http://ant.apache.org/manual/dirtasks.html#patterns
They mention that mypackage/test/ is interpreted as if it were
mypackage/test/** so
New submission from Yuval Greenfield ubershme...@gmail.com:
I ran the following code:
import time
time.sleep(10)
print 1 / 0
And then modified the source before it hit the exception, python prints out the
wrong lines from the new source file.
e:\Dropbox\dev\python
Changes by Yuval Greenfield ubershme...@gmail.com:
--
nosy: +ubershmekel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8087
___
___
Python-bugs
Yuval Greenfield ubershme...@gmail.com added the comment:
I noticed this implementation on PyPI http://packages.python.org/rglob/ which
sort of has rglob defined as
def rglob(pattern, base='.'):
Which seems like the most comprehensible way of doing this, though not the most
compact
Yuval Greenfield ubershme...@gmail.com added the comment:
Raymond Hettinger, by simple do you mean a single argument rglob function? Or
do you mean you prefer glob doesn't get a new function?
--
___
Python tracker rep...@bugs.python.org
http
Yuval Greenfield ubershme...@gmail.com added the comment:
Thanks for the bug find Antoine, I worked surprisingly hard trying to make this
right in more edge cases and while fixing it I noticed rglob/globtree has 3
options:
* Behave like a glob for every subdirectory. Meaning that every
Yuval Greenfield ubershme...@gmail.com added the comment:
I have to say that the non-obvious subtleties you point out in your rglob
make me think I personally would probably opt to use Nick's module directly
instead, so that I was sure what I was getting.
I didn't notice these corner cases
Yuval Greenfield ubershme...@gmail.com added the comment:
* Behave like a glob for every subdirectory. Meaning that every
relative path gets a '*/' prepended to it. Eg rglob('c/d') started
from the directory 'a' will yield 'a/b/c/d'.
That's what I would expect. That way, rglob('__init__.py
Yuval Greenfield ubershme...@gmail.com added the comment:
This would be quirky. I don't think '..' should be treated specially.
(there's also the symlinks problem)
Again with 'a/b/c/d' and let's add a file 'a/b/png'.
If the curdir is 'c' and you use rglob('../pn*') you won won't find '../png
Yuval Greenfield ubershme...@gmail.com added the comment:
That depends how you implement it. If you detect that .. exists and
glob for pn* inside it, you will probably find ../png.
Yes, that's what I meant by a single exemption for double dots. The solution
should start the walk from wherever
Yuval Greenfield ubershme...@gmail.com added the comment:
you should use the same algorithm for all globs (e.g. a/*.py), shouldn't
you?
That specific string would start the walk from the current directory IIUC.
--
___
Python tracker rep
Yuval Greenfield ubershme...@gmail.com added the comment:
Given
/home/a
/home/a/k.py
/home/a/c/j.py
/home/b/z.py
/home/b/c/f.py
and a current directory of /home/a, we'd have:
pattern matches
--- ---
*.pyk.py, c/j.py
c/*.py c/j.py
c
Yuval Greenfield ubershme...@gmail.com added the comment:
As R. David Murray has suggested I think there may be a middle ground.
def rglob(fn_filter, root='.'):
That would mean the default use case is still easy to remember as rglob('*.py')
and also there aren't any explanations needed
New submission from Yuval Greenfield ubershme...@gmail.com:
This is a feature I've wanted to use in too many times to remember. I've made a
patch with an implementation, docs and a test. I've named the function rglob
and tried to stay within the conventions of the glob package
Yuval Greenfield ubershme...@gmail.com added the comment:
I'd say it's very close to a duplicate but maybe isn't so. If walkdir is added
then rglob can be implemented using it.
I'd say rglob to walkdir is like urlopen to http.client. One is the
stupid and simple function (that still has
Changes by Yuval Greenfield ubershme...@gmail.com:
--
nosy: +ubershmekel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9285
___
___
Python-bugs
Yuval Greenfield ubershme...@gmail.com added the comment:
I use python a lot with Hebrew and many websites have internationalization
which may involve unicode paths. I agree that saying unicode paths are rare
is inaccurate.
If the current situation isn't fixed though - you just can't use
Yuval Greenfield ubershme...@gmail.com added the comment:
Another option btw is to use utf-16, which will work but it's a bit ugly as
well:
os.listdir(os.path.abspath(u'.').encode('utf-16'))
[]
os.path.abspath(u'.')
u'C:\\Users\\alon\\Desktop\\\u05e9\u05dc\u05d5\u05dd'
os.path.abspath(u
Yuval Greenfield ubershme...@gmail.com added the comment:
It won't break existing code. Ignoring this problem here only moves the
exception to whenever the data returned is first used.
Any code this fix breaks is already broken.
--
___
Python
Yuval Greenfield ubershme...@gmail.com added the comment:
An example error with abspath and bytes input:
os.path.abspath('.')
'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5'
os.path.abspath(b'.')
b'C:\\Users\\yuv\\Desktop\\YuvDesktop
New submission from Yuval Greenfield ubershme...@gmail.com:
For Python 2:
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
os.path.abspath('.')
'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??'
os.path.abspath(u'.')
u'C:\\Users\\yuv
New submission from Yuval Greenfield ubershme...@gmail.com:
When trying to use urllib to open a page from a server with NTLM authentication
python raises urllib.error.HTTPError: HTTP Error 401: Unauthorized
A python 3 code example: http://codepad.org/axPomYHw
This was a bit confusing for me
Yuval Greenfield ubershme...@gmail.com added the comment:
I noticed it's not only that python doesn't support NTLM, it's that I used
Basic Auth which isn't NTLM. So I modified the patch to pertain to basic auth
and digest as well.
--
Added file: http://bugs.python.org/file21574
New submission from Yuval Greenfield ubershme...@gmail.com:
Just try and review any patch diff, eg
http://bugs.python.org/review/6818/diff/2113/4194 and click Expand 10 after
on either side (top or bottom) of the diff chunk. Notice that a duplicate line
is introduced.
--
messages
Yuval Greenfield ubershme...@gmail.com added the comment:
Fixed the bugs Martin pointed out and added the relevant tests. Sadly I had to
move some stuff around, but I think the changes are all for the better. I
wasn't sure about the right convention for the 2 constants I added btw
Yuval Greenfield ubershme...@gmail.com added the comment:
I fixed the bugs I found, added tests and documentation. What do you guys think?
--
keywords: +patch
Added file: http://bugs.python.org/file21063/zipfile.remove.patch
___
Python tracker rep
41 matches
Mail list logo
