On 25/04/2014 03:00, Chris Angelico wrote:
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote:
2) If you're starting a new project, follow PEP8 (or the standards for
the language you're using) to preserve CONSISTENCY.
Don't forget that PEP 8 is not the standard for the Python language,
only
On 25/04/2014 04:03, Barry Warsaw wrote:
On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote:
Don't forget that PEP 8 is not the standard for the Python language,
only the Python stdlib. Particularly, there's no strong reason to
follow some of its lesser advices (eg spaces rather than tabs, the
On 25/04/2014 13:09, Chris Withers wrote:
> On 25/04/2014 04:03, Barry Warsaw wrote:
>> On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote:
>>
>>> Don't forget that PEP 8 is not the standard for the Python language,
>>> only the Python stdlib. Particularly, there's no strong reason to
>>> follow so
On Fri, Apr 25, 2014 at 1:28 PM, Guido van Rossum wrote:
> On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote:
>>
>> On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote:
>> > 2) If you're starting a new project, follow PEP8 (or the standards for
>> >the language you're using) to preserve CONSISTEN
Chris Withers writes:
> On 25/04/2014 04:03, Barry Warsaw wrote:
> > I'd say it depends. If the code is going to be shared with
> > people outside of your organization (e.g. open source libraries),
> > then there's a strong motivation to be consistent throughout the
> > community, which mean
On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote:
>And from *outside* of your organization, it's a no-brainer. PEP 8 is
>what Python itself and most 3rd party OSS modules use. Getting your
>people to use PEP 8 will make it a lot easier for them to learn to
>read Python core and stdlib cod
ACTIVITY SUMMARY (2014-04-18 - 2014-04-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4600 (+21)
closed 28521 (+28)
total 33121 (+49)
Open issues wit
On 25 April 2014 10:36, Barry Warsaw wrote:
> On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote:
>
>>And from *outside* of your organization, it's a no-brainer. PEP 8 is
>>what Python itself and most 3rd party OSS modules use. Getting your
>>people to use PEP 8 will make it a lot easier fo
Hi,
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
Consider this example:
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar
Now when readin
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote:
> While it seems ConfigParser doesn't do any escaping as all, I'm
> thinking it should at least raise some exception when such a value is
> trying to be set.
>
> I'd expect writing something and then reading it back via the same
> configparse
On 4/25/2014 12:46 PM, Fred Drake wrote:
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
I'd expect writing something and then reading
On 04/25/2014 09:46 AM, Fred Drake wrote:
At this point, it would be a backward-incompatible change, so it's
unlikely such a change could be allowed to affect existing code.
All bug-fixes are backwards-incompatible, yet we fix them anyway. ;)
It seems to me the real question is do we fix it
On 4/25/2014 1:41 PM, Ethan Furman wrote:
On 04/25/2014 09:46 AM, Fred Drake wrote:
At this point, it would be a backward-incompatible change, so it's
unlikely such a change could be allowed to affect existing code.
All bug-fixes are backwards-incompatible, yet we fix them anyway. ;)
It see
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote:
> I leave it to someone to carefully read the doc, but a brief glance
> indicates "There are nearly as many INI format variants as there are
> applications using it. configparser goes a long way to provide support for
> the largest sensible set o
On 04/25/2014 11:54 AM, Fred Drake wrote:
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote:
I leave it to someone to carefully read the doc, but a brief glance
indicates "There are nearly as many INI format variants as there are
applications using it. configparser goes a long way to provide s
2014-04-25 18:10 GMT+02:00 Nick Coghlan :
>
> And if you're going to publish a tool to enforce your *personal* style
> guide and include your own custom rules that the "this is OK" examples
> in PEP 8 fail to satisfy, don't call it "pep8". Especially don't do
> that if you're then going to ignore a
On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman wrote:
> Perhaps an enhancement request then: a way to provide a regex that keys
> must match, with an exception raised when a key doesn't. That way the
> safety belt could be used when desired.
You can subclass the parser class you're using and ove
On 04/25/2014 12:45 PM, Florent wrote:
2014-04-25 18:10 GMT+02:00 Nick Coghlan:
And if you're going to publish a tool to enforce your *personal* style
guide and include your own custom rules that the "this is OK" examples
in PEP 8 fail to satisfy, don't call it "pep8".
Two cases where signale
On 04/25/2014 01:55 PM, Ethan Furman wrote:
> On 04/25/2014 12:45 PM, Florent wrote:
>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan:
>>>
>>> And if you're going to publish a tool to enforce your *personal* style
>>> guide and include your own custom rules that the "this is OK" examples
>>> in PEP 8 fai
On Apr 25, 2014, at 5:52 PM, Carl Meyer wrote:
> On 04/25/2014 01:55 PM, Ethan Furman wrote:
>> On 04/25/2014 12:45 PM, Florent wrote:
>>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan:
And if you're going to publish a tool to enforce your *personal* style
guide and include your own cu
On 25 April 2014 17:52, Carl Meyer wrote:
> On 04/25/2014 01:55 PM, Ethan Furman wrote:
>> On 04/25/2014 12:45 PM, Florent wrote:
>>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan:
> I think this fuss is unreasonable and unwarranted.
>
> I'd like to thank Florent for taking the time to maintain an
> ext
On 25 April 2014 18:26, Donald Stufft wrote:
>> If python-dev wants to control the precise behavior of pep8.py, bring it
>> into the standard library and adopt maintenance of it. Otherwise, please
>> give Florent some grace.
>>
>> Carl
>
> Carl’s post mirrors my own thoughts and it’s said much bet
On 04/25/2014 03:26 PM, Donald Stufft wrote:
pep8.py doesn’t violate PEP8, it just takes a stricter view of it.
If pep8 reports errors on things that PEP 8 says are okay, that's a violation.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.o
I think the tool's name is unfortunate. The first time I heard about it I
was having an in-person discussion with a developer who (I thought) said
that "PEP 8" was okay with his code (which I knew couldn't be the case) but
in fact he meant to say that (some configuration of) "pep8" didn't mind it.
2014-04-26 0:46 GMT+02:00 Nick Coghlan :
> Florent is claiming the endorsement of the PEP 8 authors
> and the consensus of python-dev for the tool's default behaviour
> (as noted above, this makes it personal for me, as I am a
> co-author of PEP 8).
You're a co-author of PEP 8 since less than a ye
On Apr 25, 2014, at 7:56 PM, Florent wrote:
> 2014-04-26 0:46 GMT+02:00 Nick Coghlan :
>> Florent is claiming the endorsement of the PEP 8 authors
>> and the consensus of python-dev for the tool's default behaviour
>> (as noted above, this makes it personal for me, as I am a
>> co-author of PEP
2014-04-26 1:46 GMT+02:00 Guido van Rossum :
> I think the tool's name is unfortunate. The first time I heard about it I
> was having an in-person discussion with a developer who (I thought) said
> that "PEP 8" was okay with his code (which I knew couldn't be the case) but
> in fact he meant to say
On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote:
> On 04/25/2014 03:26 PM, Donald Stufft wrote:
>>
>> pep8.py doesn’t violate PEP8, it just takes a stricter view of it.
>
> If pep8 reports errors on things that PEP 8 says are okay, that's a violation.
>
> --
> ~Ethan~
> __
On 25 April 2014 19:56, Florent wrote:
> 2014-04-26 0:46 GMT+02:00 Nick Coghlan :
>> Florent is claiming the endorsement of the PEP 8 authors
>> and the consensus of python-dev for the tool's default behaviour
>> (as noted above, this makes it personal for me, as I am a
>> co-author of PEP 8).
>
>
On 25 April 2014 21:29, Nick Coghlan wrote:
> On 25 April 2014 19:56, Florent wrote:
>> 2014-04-26 0:46 GMT+02:00 Nick Coghlan :
>>> Florent is claiming the endorsement of the PEP 8 authors
>>> and the consensus of python-dev for the tool's default behaviour
>>> (as noted above, this makes it per
On 04/25/2014 05:42 PM, Donald Stufft wrote:
On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote:
On 04/25/2014 03:26 PM, Donald Stufft wrote:
pep8.py doesn’t violate PEP8, it just takes a stricter view of it.
If pep8 reports errors on things that PEP 8 says are okay, that's a violation.
Being
I wrote the following code that works in Python 2.7 that takes the variables
passed to the function into a dictionary. The following call:
strA = 'a'
intA = 1
dctA = makeDict(strA, intA)
produces the following dictionary:
{'strA':'a', 'intA':1}
To access the names passed int
Florent writes:
> I wrote some words in the documentation, one year ago, to explain what
> is the purpose of the tool and its limitations. There's no claim of
> any endorsement implicit or explicit by the PSF, the PSU or any other
> python developer :-)
Of course there is an implicit claim of
On 4/25/2014 5:52 PM, Carl Meyer wrote:
- we aren't talking about real variance from the spirit or
recommendations of PEP 8
So the one example under discussion is:
foo = long_function_name(
var_one, var_two,
var_three, var_four)
and comes from http://legacy.python.org/dev/peps/pep-0008/#i
On Sat, Apr 26, 2014 at 1:11 PM, Andrew Konstantaras wrote:
> Can anyone point me in the direction to find this information? Any help is
> appreciated.
I'd recommend python-list rather than python-dev (the latter is for
the development *of* Python, rather than development *with* Python).
But to
On Apr 26, 2014, at 12:31 AM, Stephen J. Turnbull wrote:
> Florent writes:
>
>> I wrote some words in the documentation, one year ago, to explain what
>> is the purpose of the tool and its limitations. There's no claim of
>> any endorsement implicit or explicit by the PSF, the PSU or any other
On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote:
> On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin
> wrote:
> > While it seems ConfigParser doesn't do any escaping as all, I'm
> > thinking it should at least raise some exception when such a value is
> > trying to be set.
> >
> > I'd e
Carl Meyer writes:
> I'd like to thank Florent for taking the time to maintain an
> extremely-useful tool that makes it feasible to keep to a
> consistent PEP 8 style throughout a large codebase with many
> contributors,
I would too.
N.B. Nick's complaints are a sort of left-handed complimen
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote:
> I think that a line beginning with "#spam" is ambiguous, it isn't clear
> if it is intended as a comment "spam" or a key starting with #, so by
> the Zen, configparser should refuse to guess.
Seriously?
Perhaps the second paragraph here c
On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote:
> I agree that I’ve never taken the name to mean that you’re claiming any
> sort of endorsement. There are a *vast* number of projects that implement
> something that was defined somewhere else and I don’t think any reasonable
> person
40 matches
Mail list logo
