Emanuel Barry added the comment:
Unfortunately not. I no longer have the time or means to work on this, sorry. I
hope someone else can pick it up.
--
___
Python tracker
<https://bugs.python.org/issue28
Change by Emanuel Barry :
--
nosy: -ebarry
___
Python tracker
<https://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
Emanuel Barry added the comment:
Nice initiative! I like the idea of moving towards more inclusive
documentation; as an addition, I would recommend using they/them/their instead
- it's less clumsy to read (also, singular they is perfectly valid English) and
includes everyone, even those who
Emanuel Barry <ba...@dadadata.net> added the comment:
You don't have access to this feature, so I've deleted the message for you :)
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Emanuel Barry <ba...@dadadata.net>:
--
Removed message: https://bugs.python.org/msg316153
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Emanuel Barry <ba...@dadadata.net> added the comment:
`type` has a default `__format__` implementation which doesn't accept any
formatting options. This is expected behaviour.
--
nosy: +ebarry
resolution: -> not a bug
stage: -> resolved
status: op
Emanuel Barry <ba...@dadadata.net> added the comment:
Any valid variable name can be used as a an attribute; for example, "spam" is
valid while "spam-eggs" is not. This isn't unique to classes, but to all
assignments everywhere. If we allowed `o.exec = blah` then w
Emanuel Barry <ba...@dadadata.net> added the comment:
This is because `exec` is a keyword in Python 2, whereas in Python 3 it's a
function.
--
nosy: +ebarry
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pyth
Emanuel Barry <ba...@dadadata.net> added the comment:
The documentation is correct. The first argument in both of those cases is a
str, which may not be what you were expecting, but the calls are still valid.
--
nosy: +ebarry
resolution: -> not a bug
stage: -> resolved
Change by Emanuel Barry <ba...@dadadata.net>:
--
keywords: +patch
pull_requests: +5625
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Emanuel Barry <ba...@dadadata.net> added the comment:
I have created Issue32912 as a follow-up to this issue for 3.8.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Emanuel Barry <ba...@dadadata.net>:
This is a follow-up to Issue27364.
Back in Python 3.6, a silent warning was added for all invalid escape sequences
in str and bytes. It was suggested that it would remain a silent warning (which
still impacts tests, while not vi
Emanuel Barry <ba...@dadadata.net> added the comment:
This is a known issue, and is properly explained here:
https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
--
nosy: +ebarry
resolution: -> not a bug
stage: -&
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +haypo, serhiy.storchaka
stage: -> needs patch
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Emanuel Barry added the comment:
LGTM. Thanks for the patch!
--
nosy: +ebarry
stage: -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Changes by Emanuel Barry <ba...@dadadata.net>:
--
stage: needs patch -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Emanuel Barry added the comment:
That indeed looks like a bug. Well spotted :)
That code has been there since unittest.mock was added back in March 2012. If I
were to guess, I'd say that it should be `if name is None: name = ''`. Care to
submit a patch?
--
nosy: +ebarry
Emanuel Barry added the comment:
Barry: Sure, the docs example was just a quick write-up, you can word it
however you want!
Guido: Pretty much, except the other way around (when prune is False, i.e.
"don't remove empty strings").
The attached patch exposes the behaviour (it's
Changes by Emanuel Barry <ba...@dadadata.net>:
Removed file: http://bugs.python.org/file45853/split_prune_1.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Emanuel Barry added the comment:
Yes, I agree that being able to pass in a tuple would be really useful. As far
as rolling out a custom function goes, I'd sooner reach for re.split than do
that, so I don't really have a strong argument for either side. Feel free to
play with the patch or make
Emanuel Barry added the comment:
Here's an initial patch. It works exactly as discussed earlier, doesn't break
any tests, and retains full backwards compatibility. No doc changes (except for
the docstrings of str.[r]split) and no tests, as this is just a preliminary
patch to see if there's
Emanuel Barry added the comment:
Matthew: Yes, that's exactly the way I was going about it.
Thank you Raymond for your comments (and your informative answer on that SO
question).
I think that part of the problem is that no delimiter (or None) behaves
differently than with a delimiter. If we
Emanuel Barry added the comment:
Actually, there might be a way. We could make prune default to True if sep is
None, and default to False if sep is not None. That way, we get to keep the
existing behaviour for either case, while satisfying both of our use cases :)
If that's a bad idea
Emanuel Barry added the comment:
That would work for my case, but it wouldn't for Barry's (unless I missed
something). He wants a non-None argument to not leave empty strings, but I want
a None argument to leave empty strings... I don't think there's a
one-size-fits-all solution in this case
Emanuel Barry added the comment:
Changing the behaviour when sep is None is a big backwards-compatibility break,
and I'm not sure we'd even want that. It's logical to allow passing None to
mean the same thing as NULL (i.e. no arguments), and the behaviour in that case
has been like
Emanuel Barry added the comment:
I understand the feeling. However, in a project I maintain, we want the other
way around - to be able to never have an empty list, even if the string is
empty (we resorted to using re.split in the end, which has this behaviour).
Consider:
rest = re.split
Emanuel Barry added the comment:
Oh, nicely spotted! Apparently I was wrong, and it does create a key;
defaulting to __name__.
About the original issue, I don't think it's easily possible to fix, sadly.
--
___
Python tracker <rep...@bugs.python.
Emanuel Barry added the comment:
As a matter of fact, A.__module__ in this case is abc.ABCMeta.__module__. A
class body creates a __module__ key, while a direct metaclass call does not.
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.
Emanuel Barry added the comment:
Part of the copyright notice, as SilentGhost mentioned. This can't be removed.
--
nosy: +ebarry
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.pytho
Emanuel Barry added the comment:
Additionally, trying to access an attribute before assigning it will result in
an AttributeError on all subsequent accesses (even if set).
I didn't manage to get a segfault, however.
--
nosy: +ebarry
___
Python
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23722>
___
__
Emanuel Barry added the comment:
Let's just close this.
--
nosy: +ebarry
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Emanuel Barry added the comment:
Decorater: For very large projects, the switch from Python 2 to 3 is a
non-trivial task that can take up years of work, and there are many reasons why
one cannot switch.
On the issue, however, for all PyPi-related issues, please go to the PyPa
GitHub: https
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +Martin.Teichmann
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28797>
___
Emanuel Barry added the comment:
Ow!
I can confirm the bug still happens on latest trunk. Nice finding!
--
nosy: +ebarry, ned.deily, rhettinger, serhiy.storchaka
priority: normal -> release blocker
stage: -> needs patch
___
Python tracke
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28450>
___
__
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28751>
___
__
Changes by Emanuel Barry <ba...@dadadata.net>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28750>
___
__
Emanuel Barry added the comment:
That's how strings work, unfortunately. You can't end any string (raw or not)
with an odd number of backslashes. You could do the following to get around
this limitation:
>>> r"C:\Folder" "\\"
'C:\\Folder\\'
As a side note, pl
Changes by Emanuel Barry <ba...@dadadata.net>:
--
priority: high -> normal
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28028>
___
_
Emanuel Barry added the comment:
Even better than what I was aiming for :)
--
dependencies: -Convert warnings to SyntaxWarning in parser
priority: deferred blocker -> release blocker
___
Python tracker <rep...@bugs.python.org&
Emanuel Barry added the comment:
As Nick pointed out in an earlier message on this thread and as Serhiy observed
on GitHub issues, backporting this patch to 3.6 is a must. Large projects' use
of Python 3.6 has shown that it's hard to track down the actual cause of the
error; it only makes
Emanuel Barry added the comment:
Thank you Eric. Have you looked at making a new DeprecatedSyntaxWarning
subclass of both DeprecationWarning and SyntaxWarning? Hopefully that's of some
help.
I don't see a review link, but from a quick glance this looks good. Thanks
Emanuel Barry added the comment:
Cross-ping from #28128
I think it would be best to solve this issue, solving both #28128 and any
future warning-introducing feature or deprecation. I've marked this issue as a
dependency for #28128 as well as upping the priority. There are less than 7
weeks
Emanuel Barry added the comment:
Following Ned's email to Python-Dev, I'm upping the priority of this issue to
"deferred blocker".
I haven't had a lot of time to work on this, but I had time to think about it,
and I think that resolving #28028 would be the best way to solved this.
Emanuel Barry added the comment:
Could provide more information on the issue? Which program exactly is failing?
Is it the IDLE editor? If you don't know what you're using, you can provide a
screenshot as a last resort (but don't provide one if you can figure out the
program that freezes
Emanuel Barry added the comment:
This is not a regression, the documentation was just not fully updated when the
new feature was added. Patch looks good. This should probably be applied to the
3.5 branch as well.
--
nosy: +ebarry
stage: patch review -> commit review
versions: +Pyt
Emanuel Barry added the comment:
I see the function is private; is there any concern with extending the PyErr_*
API? I think it'd make sense to expose it, since it's a convenient way to do in
C what can already be done easily in Python, but I don't actually have a good
reason :)
Other than
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28410>
___
__
Emanuel Barry added the comment:
I'm not able to trigger an assertion error when running the latest trunk in
debug mode. I get a "valid" range_iterator object though, and using __reduce__
gives me direct access to `range(0, 0, 0)` (which is completely worthless).
Error or not, t
Emanuel Barry added the comment:
Ping. I'd like for this to get merged in beta 2; should I (or Eric if he wants
to) get to work on this? Is the DeprecatedSyntaxWarning subclass route still
desired?
--
___
Python tracker <rep...@bugs.python.
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28243>
___
__
Emanuel Barry added the comment:
Personally I'd be fine with only one warning, reporting the first invalid
escape. Presumably the string would be checked as a whole, or would get an r
prefix. Patch seems like a good start; bytes would also need updating in that
regard. Don't worry too much
Emanuel Barry added the comment:
This is a duplicate of issue27781.
--
nosy: +ebarry
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Change sys.getfilesystemencoding() on Windows to UTF-8
___
Python
Emanuel Barry added the comment:
Hmm, I see; I'll need to dig a bit deeper get to and understand that part of
the compile process better. I'll look up where SyntaxErrors are generated
(since they have access to at least the line number at that point), and try to
hook it up from
Emanuel Barry added the comment:
Thank you Nick for the useful feedback! I think that a subclass of
DeprecationWarning and SyntaxWarning would be a good idea; I'll play around
with that.
As far as when the warning should occur, I agree that erroring out at the
compile step isn't optimal
Emanuel Barry added the comment:
There definitely needs to be a better message for that. The problem is that the
parser doesn't have access to the whole string (of course; it's being
constructed!), so I think there are several possible venues here:
- Change DeprecationWarning to display
Emanuel Barry added the comment:
Besides converting the DeprecationWarning to a Syntax{Error,Warning}, I don't
see an easy way to include the offending line (or even file). The place in the
code where the strings are created has no idea *where* they are being defined.
AIUI, either we special
Emanuel Barry added the comment:
Hello, and thanks! I'll work on a patch this week, or at most next week. I will
make it so that it's completely uncontroversial to apply it to 3.6 as well
(won't change the actual feature, only prettify the error message), so no need
to worry about
Emanuel Barry added the comment:
Fair enough, but please open a new issue for that.
@Terry - you're welcome; that's exactly the reason I pushed for it :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
I actually did a clean rebuild and could not reproduce, so I'm guessing
something did go wrong on my side.
--
priority: deferred blocker -> normal
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
Emanuel Barry added the comment:
Fair enough; I can see why such an addition would be a good idea. But please
open a new issue for that (add me to nosy); I don't want this issue to be
further cluttered.
--
___
Python tracker <rep...@bugs.python.
Emanuel Barry added the comment:
I don't know what exactly happened that would make it crash, but after wiping
off everything and starting over, it works fine now. Sorry for the noise!
--
components: -Windows
priority: release blocker -> normal
resolution: -> not a bug
stage:
Emanuel Barry added the comment:
Huh, weird. I'm running a win32 build on a 64 bits machine, with VS2015. I
didn't have time to test on a clean checkout, I will do that first thing when
I'm back home tonight. I hope I did something wrong and there really isn't any
issue
Changes by Emanuel Barry <ba...@dadadata.net>:
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Emanuel Barry added the comment:
I compiled, I got a "Python stopped working" during compiling (but it went on
anyway), and then launched it from VS in Debugging mode. I did 'from test
import support' and then it crashed. VS said this line was the faulty one, and
didn't give me any
Emanuel Barry added the comment:
Latest, i.e. https://hg.python.org/cpython/rev/a477ef882a16
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
Thank you Nick! I just opened #28062 to fix the repr inconsistency between
functools.partial and any subclass :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Emanuel Barry:
This is a followup to #27137, where it was found out the repr of a partial
object includes the module (i.e. 'functools') only if it's not a subclass. This
behaviour is surprising at best. Attached patch streamlines the reprs of
partial objects to always
New submission from Emanuel Barry:
VS breaks at line Objects/dictobject.c:2339 - 'if
(mp->ma_keys->dk_usable * 3 < other->ma_used * 2)'
I don't have any more useful information; I'm running Windows 7.
--
components: Interpreter Core
messages: 275627
nosy: e
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28050>
___
__
Emanuel Barry added the comment:
Ping. The built-in dict was considerably changed in #27350; do any of these
issues still persist?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
The patch LGTM and applies fine. Looks like there's no need to wait for beta 2
after all; thanks Serhiy!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
Can this be merged even with the two failing tests? I have little to no time
available to fix it properly before the feature freeze. We can skip/silence
those tests for a bit; I'll open a new issue and fix it in time for beta 2
Emanuel Barry added the comment:
Thank you David for taking the time to review and commit this :)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28028>
___
__
Emanuel Barry added the comment:
All right, since you'll work on it I'm leaving it out. Removed it and
test_bytes (which you already fixed, thanks!) from new patch.
--
Added file: http://bugs.python.org/file44465/invalid_stdlib_escapes_5.patch
Emanuel Barry added the comment:
Thank you R. David for the review, here's a new patch with the one change.
--
Added file: http://bugs.python.org/file44463/invalid_stdlib_escapes_4.patch
___
Python tracker <rep...@bugs.python.org>
Changes by Emanuel Barry <ba...@dadadata.net>:
Added file:
http://bugs.python.org/file44457/invalid_stdlib_escapes_3_rebased_2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Emanuel Barry added the comment:
Thank you Serhiy for the comments! Here's a new patch. I'm fine with the
recursive repr tests failing for now; it's something I believe we can fix
during the beta phase if we don't have time before (fix as in modify the C
implementation to match the Python
Emanuel Barry added the comment:
Hi Nick, thank you for letting me know! I started trying to fix this, however I
found it very hard to fix the recursive repr issue. I've whipped up an
incomplete (but yet working) patch that fixes all but the recursive repr issue.
Only those two tests fail
Changes by Emanuel Barry <ba...@dadadata.net>:
Added file: http://bugs.python.org/file44435/invalid_stdlib_escapes_4.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Emanuel Barry <ba...@dadadata.net>:
Removed file:
http://bugs.python.org/file44433/invalid_stdlib_escapes_3_regen.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Emanuel Barry <ba...@dadadata.net>:
Added file:
http://bugs.python.org/file44433/invalid_stdlib_escapes_3_regen.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Emanuel Barry added the comment:
Rebased patch after Victor's commit in #16334. Also regenerated
invalid_stdlib_escapes_3 in the hopes that Rietveld picks it up.
--
Added file:
http://bugs.python.org/file44432/deprecate_invalid_escapes_both_4.patch
Emanuel Barry added the comment:
We're one week from the feature freeze, seems like a good time to merge this :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
Updated and rebased patch. There's a few file tweaks here and there to stay up
to date, otherwise it's mostly the same.
Martin, it may look like I've ignored your comments, but I'm trying to keep the
patches as simple as possible, and so I don't want to go
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ebarry, larry, ned.deily, rhettinger, serhiy.storchaka
priority: normal -> critical
stage: -> needs patch
title: five dictobject issues -> Various segfaults with dict
Changes by Emanuel Barry <ba...@dadadata.net>:
--
nosy: +ncoghlan, rhettinger
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Emanuel Barry added the comment:
Thanks for the report! I'm unable to reproduce, as `socket.AF_BLUETOOTH`
doesn't exist on my system, but surely someone else can.
--
keywords: +3.5regression
nosy: +ebarry, ned.deily
priority: normal -> high
stage: -> needs patch
Emanuel Barry added the comment:
Thanks Serhiy; it does look better to me too!
--
Added file:
http://bugs.python.org/file44322/deprecate_invalid_escapes_both_3.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Emanuel Barry added the comment:
Ping. I'd like to get this merged in time for 3.6. Is there anything I can do
to speed up the review?
Since the change itself is very straightforward, I think this would make sense
to merge it now and then fix the invalid escapes that are found during the beta
Emanuel Barry added the comment:
The patch doesn't apply. I manually copy-pasted the lines in the source and
generated a new one.
I would probably rephrase "these values hold no meaning and should not be used"
into "the values are not important" or somethi
New submission from Emanuel Barry:
The function does definitely exist for me. Please make sure your Python version
is up-to-date. Also, please post a short summary of the issue, and avoid
screenshots whenever possible; it's more work for you, makes it harder for us
to reproduce/follow (need
Emanuel Barry added the comment:
Martin: Indeed, seems like it's backwards for some reason. I'm not sure what
happened when I regenerated the index; I removed the patches now anyway. I
think the .gitattributes patch would be fine to go on its own.
It's my understanding that line endings don't
Changes by Emanuel Barry <ba...@dadadata.net>:
Removed file: https://bugs.python.org/file44220/fix_newlines_1.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Emanuel Barry <ba...@dadadata.net>:
Removed file: https://bugs.python.org/file44225/fix_newlines_2.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Emanuel Barry <ba...@dadadata.net>:
Added file: https://bugs.python.org/file44225/fix_newlines_2.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Emanuel Barry added the comment:
Whoops, turns out I was using the wrong approach for binary files. Here come
add_gitattributes_2.patch and fix_newlines_2.patch (thanks Zachary for pointing
this out).
--
Added file: https://bugs.python.org/file44224/add_gitattributes_2.patch
1 - 100 of 351 matches
Mail list logo
