getencoder
encoder = getencoder('rot-13')
r13 = encoder('hello world')[0]
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Apr 25, 2013, at 03:34 PM, Lennart Regebro wrote:
>In the case of JSON objects, they are intended for data exchange, and
>hence in the end need to be byte strings.
Except that they're not.
http://bugs.python.org/issue10976
-Barry
___
object is *not* an instance of the enum class. In fact, it seems
completely weird to me that C.a would be an instance of the enum class. It
seems very rare that a class has attributes that are instances of that class.
It's not even easy to do with traditional syntax.
class Foo:
a = Foo
these
methods to the class you set in __value_factory__.
No need to conflate the classes, which I think just adds unnecessary
complexity and confusion.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
duplicate, deprecated syntax.
Does this look similarly odd?
>>> isinstance(C[1], C)
False
given that ``C[1] is C.a``?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
>>> isinstance(Z.d, Z)
True
>>> isinstance(Z.d, X)
False
>>> isinstance(Y.z, Y)
True
>>> isinstance(Y.z, Z)
False
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t with the documentation
in the next version of flufl.enum.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t;>
class Methods(Enum):
set = 1
get = 2
delete = 3
What is "Methods.get"?
Catching the ValueError ``Methods[5]`` would raise doesn't seem so bad.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
als is *not* a class -- it just uses the class syntax as a convenient
>way to set up the names used to construct the new type. (This subtlety
>is why the metaclass hook is reputed to make peoples' brains explode).
Thanks for the great explanation! :)
- -Barry
-BEGIN PGP SIGNAT
item objects, it just returns an already existing one.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
>>> B.a is A.a
True
>>> X = Enum('X', 'a b c')
>>> Y = X('Y', (('d', 4), ('e', 5)))
>>> Y.a is X.a
True
That's a nice symmetry.
-Barry
signature.asc
Description: PGP signature
__
you
>define enums.
Is it enough that isinstance(Color.red, Color) returns True, or do you
really-and-truly want them to be instances of Color?
I still think it's weird, but I could accept the former if you're flexible on
the latter, which in some sense is just an implementation det
oring the instances on the class as attributes is
>mostly for convenience; we could just as easily not, and change the repr of
>enumerators to ' ant [int=1]'.
So I guess you would still expect these to hold true:
>>> Animal.ant
ve with that, but we should admit that it will will happen :)
What's the definition order here?
>>> Methods = Enum('Methods', {'set': 8, 'get': 15, 'delete': 16})
-Barry
___
Python-Dev mailing
On Apr 22, 2013, at 10:55 AM, Tim Delaney wrote:
>Would it be worthwhile storing a sorted version of the enum keys here? Or
>do you think the current space vs speed tradeoff is better?
It's an implementation detail that doesn't bother me too much either way.
-Barry
signature
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
>On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw wrote:
>> On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
>>
>>>Iteration order matters a lot if you don't want people complaining about
>>>enums being
aving attributes which are
actual instances of itself.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
'll ever be able to
get full coverage over common Python types.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ogrammers issue...
Correct. flufl.enum.IntEnums will blow up earlier, when the class is defined
assigning the attributes to non-int values.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
gt;need to intermix the two.
I agree with this.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ion values created in subclasses.
That's a shame, because disallowing subclassing to extend an enum will break
my existing use cases. Maybe I won't be able to adopt stdlib.enums after
all. :(
-Barry
___
Python-Dev mailing list
Python-Dev@pyth
remove the `if base._enum` check? I mean, can we be
consenting adults here or not?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
FWIW, I have use cases for extending through
inheritance and haven't had any kind of semantic confusion. But then again, I
haven't particularly needed to do type checks or isinstance checks, and I
haven't needed to put methods on enums either.
-Barry
_
the "AUTUMN is-a Seasons" position that Ethan
>and Guido take. It's inconsistent with the "AUTUMN is-a
>Seasons_VALUE" implementation of Flufl.Enum.
I think this sums it up perfectly. I get that using class definition syntax
is what sends people down Ethan's path
t;, you should only map
values to items, and not attribute names to items, and definitely not both.
Let getattr() do attribute name lookup just like normal.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
them. I think `is` reads
better in context, and identity checks are usually preferred for singletons,
which enum items are. You can use equality checks, but think about this:
if thing == None:
vs.
if thing is None:
-Barry
___
Python-Dev mail
l be True, I'd love it if someone showed me
>how.
class Foo:
a = object()
b = object()
class Bar(Foo):
c = object()
>>> Foo.a is Bar.a
True
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
more class-like because you're using
the class syntax, then you shouldn't explicitly break this one class-like
behavior just to protect some users from themselves. There doesn't even seem
to be an easy way to override the default behavior if you really wanted to do
it.
-Barry
_
On May 01, 2013, at 12:19 AM, Glenn Linderman wrote:
>Can Things('foo') lookup by name and Things['foo'] lookup by value? Or does
>that confuse things too?
I think it confuses things too much. Why isn't getattr() for lookup by name
good enough? It
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
>On 04/30/2013 11:29 PM, Ethan Furman wrote:
>> On 04/30/2013 11:18 PM, Barry Warsaw wrote:
>>> On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
>>>
>>>> But as soon as:
>>>>
>>&g
On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
>Barry Warsaw wrote:
>> Why isn't getattr() for lookup by name
>> good enough?
>
>Because it will find things that are not enum items,
>e.g. '__str__'.
Why does that matter?
-Barry
___
;
>Class where every instance is a subclass of int.
>'''
>
>So why don't we just drop IntEnum from the API and tell users they should
>do the above explicitly, i.e.:
+1
-Barry
___
Python-Dev mailing list
Python-Dev@
a = 'a'
... b = 'b'
...
>>> int(Foo.a)
Traceback (most recent call last):
File "", line 1, in
TypeError: __int__ returned non-int (type str)
...remove Enum.__int__()...
>>> class Bar(int, Enum):
... a = 1
... b = 2
...
t;Good Thing.
But then, Foo.a.value is good enough.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
>So, for the second time: How can Color.red and MoreColor.red be the same
>object when they are of different types?
It's a moot point now given Guido's pronouncement.
-Barry
___
Py
On May 02, 2013, at 10:18 PM, Georg Brandl wrote:
>5) accept that convenience-created enums have restrictions such as no
>picklability and point them out in the docs?
That would work fine for me, but ultimately I'm with Guido. I just don't want
to have to pass the module
convenience API, you can't pickle. If
>> it used the class API, you can.
>
>A good reason to ditch the function-based syntax.
Why? Not everything is picklable. Oh well.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
ove suggestion doesn't address. IMHO, it's not
worth giving up the functional API for picklability if the technical problems
cannot be resolved, especially given we already have the same problem for
namedtuples.
-Barry
___
Python-Dev mailing list
27;s no guarantee you could pass it straight to int() or any
other conversion type. So you pretty much have to be prepared to capture
exceptions anyway.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ded, rsplit the
string and use the prefix as __module__. If not given, fallback to the
_getframe() hack for those implementations where it's available.
The same could probably be done to namedtuples.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
h
>:-).
Assuming the picklability of functional API created Enums is fixed (sorry,
another threadsplosion still awaits me), if you *really* have to have
autonumbering, use the functional API. IMHO, the class API doesn't need them.
-Barry
___
Python-
ion, although there
would be some discussion around what is blessed private API and what is
YOYO[1] API.
-Barry
[1] You're own your own.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
on various aspects of enum behavior :).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
nd hardcode the module name. Then typing the module incorrectly is very
>easy, and the mistake is easily overlooked because it won't be noticed
>until you actually try to pickle a member.
Seems reasonable. The `module` argument should be keyword-only, and obviously
namedtuple sho
On May 09, 2013, at 04:01 PM, Guido van Rossum wrote:
>I have reviewed the latest version of PEP 435 and I see that it is
>very good. I hereby declare PEP 435 as Accepted. Congratulations go to
>Barry, Eli and Ethan for pulling it through one of the most thorough
>reviewing and
On May 10, 2013, at 05:14 PM, Nick Coghlan wrote:
> I 396 Module Version Numbers Warsaw
I do want to eventually return to this PEP, but I probably won't any time
soon.
-Barry
___
Python-Dev mailing list
Py
t;I didn't know there was a PEP for that. I hereby reject it. No point
>wasting more time on it.
Done.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
stdlib.
As Eli mentions, making the socket constants enums seems like a good test
case.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-
can't see how
this bug could be exploited as a security vulnerability.
Thoughts?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 15, 2013, at 06:06 PM, Tres Seaver wrote:
>On 05/15/2013 04:58 PM, Barry Warsaw wrote:
>> This leads me to hypothesize that the bug is due to an as yet
>> unidentified race condition during installation of Python source co
#x27;s a flaw in
importlib we haven't identified yet.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
writing to the same file.
Sadly, no. I've never seen it on any of my own desktops or servers, and none
of the bug reporters have been able to provide a reproducible test case. I
tried some smaller test cases to see if I could trigger pyc writing race
conditions, but failed to reproduce it ther
inotify' but with more words...)
No, it's all different kinds of machines, at different times, on different
files. So far, there's no rhyme or reason to the corruptions that I can
tell. We're trying to instrument things to collect more
lete. We're definitely seeing issues
post-landing of this fix, so I need to do some more analysis to see if that
fix was enough. If it wasn't, and we're not doing atomic renames, than that
could explain the permanent corruptions.
Cheers,
-Barry
[1] http://bugs.debian.org/cgi-bin/
, *please* get in touch with me, preferably
before you fix it ;). I'd like to do some additional analysis on a broken
system in semi-realtime.
Cheers,
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJRllovAAoJEBJutWOnSwa/+kgP/iyqwiKJvSszzPITSSU8lOps
age installs. Note
that the symlinks are to the .py files, not the pyc files.
Fortunately we almost don't care about this anymore. We dropped 2.6 in Ubuntu
a while ago and we'll very likely drop 2.6 in Debian Jessie. We don't care
about any Python 3s earlier than 3.2, and g
e to change py_compile.py to do atomic renames. Whether that
would be an appropriate fix for 3.2, 3.3 and 2.7 is a different discussion.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
ht be interesting, but I bet
backporting atomic renames to py_compile.py will fix the problem, or at least
band-aid over it. ;)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
On May 17, 2013, at 01:19 PM, David Malcolm wrote:
>Fedora/RH pregenerate the .pyc files during rpm creation, and they exist
>as part of the rpm payload.
Good to know, thanks. Do you use `$PYTHON -m py_compile` to generate the pyc
files at build time?
-Barry
signature.asc
Descriptio
t;with [prefix] instead of []. Then py_compile would amount to
> pyc =
> marshal.dump(codeobject, file, pyc)
That wouldn't be a backportable change, and right now I'm trying to stay
focused on fixing this specific problem. ;)
-Barry
_
it
ordering assumptions caused broken code when run in one implementation or
another.
Or in other words, if dicts are to be ordered, let's make it an explicit
language feature that we can measure compliance against.
-Barry
___
Python-Dev mailing list
Pyt
have value and should not
be broken without careful consideration.
You make excellent points about Python 3 adoption and the "canary-like" nature
of doctests.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
but - outside of doctest-based tests - there's typically very
>little explanatory text in testing code.
+1
A rule-of-thumb I use is what I call the FORTH rule[1]. If you should be able
to understand what your own test is trying to accomplish a week later,
other
it, but I'm
pretty sure you can 2to3 your doctests too.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ation as you go, brings
the win of TDD to your documentation.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
end, if we can reach some
consensus, I'd be willing to put together an informational PEP and some
scripts that might be of general use.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
On May 28, 2013, at 10:15 PM, Nick Coghlan wrote:
>Would anyone object if I went ahead and posted patches for making
>these changes to the main repo?
When you say "post[ed] patches", do you mean you want to put them some place
for us to review? If so, sure, go ahead of
hat PEP 8 already says.
Exactly so.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
able to explicitly override the shebang line
interpreter, e.g.
$ head /usr/bin/foo
#! /usr/bin/python3 -Es
$ python3.4 /usr/bin/foo
...
One other person mentioned they like to be able to execfile() - or the Python
3 moral equivalent - the /usr/bin script, wh
n script uses /usr/bin/env
and breaks the world. We also recommend using -Es to isolate the environment
as much as possible.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
uot;3" to scripts generated by packages which happen to use Python
>3, as it will just sort of perpetuate its otherness.
tox
https://bitbucket.org/hpk42/tox/issue/96/cant-have-a-python-3-setuppy
-Barry
signature.asc
Description: PGP signature
___
erence as it places the version next to the
>thing that it's a version of.)
>
>or
>
>/usr/bin/foo-py3-2 (Confusing as the 2 is bare. Something like
>/usr/bin/foo-py3-v2 is slightly better but still not as nice as the
>previous IMHO)
Definitely the former,
ould really like to see all scripts provide a -m equivalent for
command line invocation. This might be a little awkward for < Python 2.7
(where IIRC -m doesn't work with packages).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
htt
f Python being used to execute them.
Agreed. I'm trying to tease out some conventions we can recommend for when
this can't be the case for whatever reason.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python
to borrow any implementation details from wheels,
just the file naming conventions (compatibility tags) described in PEP 425.
It would still be up to upstream package or distro tools to fiddle the
installed file names.
-Barry
signature.asc
Description:
On May 28, 2013, at 08:02 PM, Antoine Pitrou wrote:
>On Tue, 28 May 2013 13:27:18 -0400
>Barry Warsaw wrote:
>> On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>>
>> >How about always running the version specific targets, e.g.
>> >nosetests-2.7?
>>
ers.
>My current feeling is that I wouldn't use this same system for interpreters
>which are not mostly compatible (for instance, python2 vs python3). but I
>also haven't devoted much actual time to thinking about whether that might
>have some advantages.
Seems like for Python, that
nloads even though we only
>started shipping it upstream as part of the Python 3.3 installer)
We're getting pretty close to a real idea here. :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
d to this:
http://bugs.python.org/issue17977
+1 for changing the default to True.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
d I'm -0, but from a decidedly
Linux-distro bias), it must be easily disabled. I generally like the way PEP
431 handles the tzdata, so I think we should do the same here.
-Barry
[1] This gives us headaches in upstreams like coverage caused by bundling
externally available JavaScript librarie
inds me of one other thing. We have to make sure that the APIs
(e.g urlopen()) continue to allow us to use self-signed certificates, if for
no other reason than for testing purposes. OTOH, taking this away would be a
backward incompatible change in API so probably wouldn't happen anyway.
-Ba
with urlopen(). I don't think people will want to do that
in production, but it will be useful for testing (e.g. guess how I found
issues 17977 :).
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.o
depend on
>it, they won't need to bundle their own certs and ubuntu/debian can just
>modify the one location instead of needing to modify it for every package
>that does it.
Can we do the same for the JavaScript libraries? :)
-Barry
signature.asc
Description: PGP signature
___
On Jun 07, 2013, at 09:06 AM, Ethan Furman wrote:
>Oh, and I just realized this is probably why the flufl.enum docs import from
>a preexisting module instead of creating a new class on the spot.
Exactly. ;)
-Barry
___
Python-Dev mailing list
nly how I thought of them in flufl.enum, and indeed the `is`
test in my own test suite proves that it works.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
?
The last upload was on 2009-08-25. Maybe Ben Finney's abandoned it and
wouldn't mind giving up the enum PyPI name?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
27;ve already
adjusted for the lack of inheritance - mostly I have to see what effect it
will have on the database layer).
OTOH, if folks really depend on the differences in flufl.enum, I will probably
at least continue to maintain it, but not add any new features.
-Barry
od!
Merge proposal: http://tinyurl.com/l2fq38l
Branch: https://code.launchpad.net/~barry/mailman/pep435
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
help
>(easily, at least).
As do I. I think it still makes sense for us to include a working distclean,
especially since it's a very common target for make-based builds.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://m
the value. (Note that even though I don't use IntEnums, my values are all
integers. It's just not worth it to change all my imports.)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
aking a different perspective.
The latter, but I think PEP 435 made the right choices, at least for the
stdlib version. It doesn't bother me that I had to switch them when porting.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://m
kin to "protected" in C++.
Besides, Python doesn't really have any strong notion of privateness, so
saying "non-public" means "just because you can, doesn't mean you should".
-Barry
___
Python-Dev mailing list
P
On Jul 15, 2013, at 09:56 PM, Antoine Pitrou wrote:
>If you really want another word (I am personally fine with "private"),
>"internal" it should be.
I would be fine with "internal", since that's how PEP 8
APIs imported by
>a module are always considered an implementation detail. Other modules
>should not rely on indirect access to such imported interfaces unless they
>are an explicitly documented part of the containing module's API (such
>as ``os.path`` or a package ``__init__`` mo
On Jul 15, 2013, at 08:23 PM, Chris McDonough wrote:
>On Mon, 2013-07-15 at 18:40 -0400, Barry Warsaw wrote:
>> Working from what I think is the latest version.
>>
>> In general, i'd rather be prescriptive of future conventions than
>> descriptive of current c
hat PEP 8 is supposed to cover, right? :)
Right! It doesn't bother me at all that this particular recommendation may be
followed by third parties too. :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to get the pep8 developers to adjust their tool,
most recently e.g. the closing brace/bracket/paren for multiline collections.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ule, but that's only one part of
the keeping-things-up-to-date problem.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Jul 16, 2013, at 11:48 PM, Nick Coghlan wrote:
>For the general case, the patch I posted to the issue tracker sets the
>precedence as docs -> __all__ -> leading underscore.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@pyt
e to pep8's notion of what PEP
8 says [1].
In other cases, Someone Out There runs pep8 over your code, and files bugs on
all the complaints that get produced. That can definitely lead to churn and
waste, especially on big, established code bases.
-Barry
[1] which I do not always agree wi
601 - 700 of 2826 matches
Mail list logo
