On Wed, Jan 30, 2019 at 12:09:55AM +, Alex Shafer wrote:
> 2) strings are special and worthy of a "special case" because strings
> tend to be human readable and are used in all kinds of user interface.
So are ints, floats, bools, lists, tuples, sets, dicts, etc.
We already have a "stringify
Thanks Steven for your reply.
For me, assembling a string from various variables is a much more
common programing task, because that's how users except software to
communicate with them, be it on CLI, GUI, or through Web.
It doesn't matter if your software works and the user doesn't
understand it
On Wed, Jan 30, 2019 at 2:45 AM David Mertz wrote:
> Done! Does that really need to be in the STDLIB?
Well, Robert suggested to define it in the python startup script. The
issue I'm having with that is that it will make my software harder to
distribute: it will require the user to hack their star
I'm not disagreeing by any mean. I'm just saying assembling strings is
a common programing task and that we have two different methods with
the same name and inconsistent signatures and that it's error-prone.
I'm most certainly *not* advocating for breaking compatibility or
whatnot.
___
On Wed, Jan 30, 2019 at 8:50 PM Jamesie Pic wrote:
>
> For me, assembling a string from various variables is a much more
> common programing task, because that's how users except software to
> communicate with them, be it on CLI, GUI, or through Web.
>
> It doesn't matter if your software works an
On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
wrote:
>>
>> Raises an error. Why should:
>>
>> “”.join([2, “2”]) not raise an error as well?
>
> I agree
What do you think could be the developer intent when they do
",".join([2, "2']) ?
If the intent is clearly to assemble a string, as it loo
On Wed, Jan 30, 2019 at 7:14 AM Robert Vanden Eynde
wrote:
> But 🦆 duck typing is nasty... I don't want that in the stdlib (but in a pip
> package, sure!)
Not only do I actually like your implementation, but I also love duck
typing. For me duck typing means freedom, not barrier.
--
∞
_
This thought is motivated by this bug report:
https://bugs.python.org/issue35857
If you import a module, then edit the .py file that goes with it, and
then an exception occurs, the stack trace can show the wrong line.
It doesn't happen very often, but when it does happen, it can be very
perple
On Wed, Jan 30, 2019 at 9:21 AM Steven D'Aprano wrote:
>
> If you don't like the two built-in stringify functions, you can write
> your own, and they still work with for-loops, comprehensions and map().
I don't disagree, after all, there are many NPM packages that contain
really short functions,
On Wed, Jan 30, 2019 at 11:17 AM Jamesie Pic wrote:
> often mistake because switching over from os.path.join and str.join.
I didn't mean "replacing an os.path.join call with an str.join call",
I mean that I'm calling str.join 2 seconds after os.path.join, and
forgot about the inconsistency we hav
On 1/30/2019 5:07 AM, Jamesie Pic wrote:
On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
wrote:
Raises an error. Why should:
“”.join([2, “2”]) not raise an error as well?
I agree
What do you think could be the developer intent when they do
",".join([2, "2']) ?
If the intent is clearl
On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
>
> Most places where you need to talk to humans, you'll end up either
> interpolating the values into a template of some sort (see: percent
> formatting, the format method, and f-strings), or plug individual
> values straight into method call
On Wed, Jan 30, 2019 at 11:24 AM Eric V. Smith wrote:
> Your examples show literals, but I literally (heh) never use str.join
> this way. I always pass it some variable. And 100% of the time, if that
> variable (say it's a list) contains something that's not a string, I
> want it to raise an excep
On Wed, 30 Jan 2019 at 3:48 PM, Steven D'Aprano wrote:
> This thought is motivated by this bug report:
>
> https://bugs.python.org/issue35857
>
> If you import a module, then edit the .py file that goes with it, and
> then an exception occurs, the stack trace can show the wrong line.
>
> It doesn
On Wed, Jan 30, 2019 at 11:07:52AM +0100, Jamesie Pic wrote:
> What do you think could be the developer intent when they do
> ",".join([2, "2']) ?
I don't know what your intent was, although I can guess, but I do know
that I sure as hell don't want a dumb piece of software like the
interpreter
Wow, thanks for your great reply Steven ! It really helps me get a
better understanding of what I'm trying to do and move forward in my
research !
Some values are not going to be nice as strings, so I think I'm more
going to try to make a convenience shortcut for str map join, for when
I want to g
Oops, fixing my last example:
readable = mapjoin(
'hello',
f'__{name}__',
sep='\n',
# key=format_record, could be used here
)
Signature would be like (illustrating defaults): mapjoin(*args,
sep='\n', key=str)
___
Python-ideas mailing lis
Hi,
At the end this long thread because 2 functions doing quite the same
thing have the same name but not the same signature and it's confusing
for some people (I'm one of those)
|str.||join|(/iterable/)
|os.path.||join|(/path/, /*paths/)
There are strong arguments about why it's implemented l
On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
> Most places where you need to talk to humans, you'll end up either
> interpolating the values into a template of some sort (see: percent
> formatting, the format method, and f-strings), or plug individual
> values straight into method calls
Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
might also want to throw in a "key" kwarg, that could be none by
default to keep BC, but also allow typecasting:
' '.join('a', 2, key=str)
--
∞
___
Python-ideas mailing list
Python-idea
I think Steve's suggestion fails in this situation. Suppose wibble.py
contains a function fn. Now do
import wibble
fn = wibble.fn
# Modify and save wibble.py
reload(wibble)
fn()
I've posted a message to this effect in the original bug
https://bugs.python.org/msg334553
Please note t
On Fri, 4 Jan 2019 at 19:03, Abe Dillon wrote:
> Currently PEP-8 prescribes all caps for constants and uses the all cap
> variable "FILES" as an example in a different section. It also appears to be
> the defacto-standard for enums (based on the documentation)
>
> I don't think it's necessary to
I really don't get the "two different signatures" concern. The two
functions do different things, why would we expect them to automatically
share a signature.
There are a zillion different open() functions or methods in the standard
library, and far more in third party software. They each have var
I've been bitten by this and it always costs me several minutes of confusion.
+1
> On 30 Jan 2019, at 11:17, Steven D'Aprano wrote:
>
> This thought is motivated by this bug report:
>
> https://bugs.python.org/issue35857
>
> If you import a module, then edit the .py file that goes with it, an
On Wed, Jan 30, 2019 at 10:33 PM Jamesie Pic wrote:
>
> On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
>
> > Most places where you need to talk to humans, you'll end up either
> > interpolating the values into a template of some sort (see: percent
> > formatting, the format method, and f-
> -Original Message-
> From: Python-ideas list=sdamon@python.org> On Behalf Of Jonathan Fine
> Sent: Wednesday, January 30, 2019 6:40 AM
> To: python-ideas
> Subject: Re: [Python-ideas] Stack traces ought to flag when a module has
> been changed on disk
>
> I think Steve's suggest
> I think using reload should raise warnings, since it doesn't work, and the
> reload case shouldn't be the killer of this really good idea.
In Python2, reload is in __builtin__ module (and so available without
import at the Python console).
Since Python 3.4 this functionality is in the importlib
On Wed, 30 Jan 2019 at 16:34, Alex Walters wrote:
>
>
> > -Original Message-
> > From: Python-ideas > list=sdamon@python.org> On Behalf Of Jonathan Fine
> > Sent: Wednesday, January 30, 2019 6:40 AM
> > To: python-ideas
> > Subject: Re: [Python-ideas] Stack traces ought to flag when
> On 30 Jan 2019, at 10:07, Jamesie Pic wrote:
>
> On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
> wrote:
>>>
>>> Raises an error. Why should:
>>>
>>> “”.join([2, “2”]) not raise an error as well?
>>
>> I agree
>
> What do you think could be the developer intent when they do
> ",".jo
Thanks for your email Barry. This is indeed a good point and the
proposal has changed a bit since then. It's more "add a key kwarg to
str.join where you can set key=str yourself if you want".
___
Python-ideas mailing list
Python-ideas@python.org
https://m
> Is it that really obnoxious?
EXTREMELY!
> Does using upper case for constants measurably slows down coders? Can
you cite the actual papers describing such experiments that lead to this
conclusion ?
https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read
https
Text in color or against black backgrounds is harder to read than black on
white.
See for example:
https://trevellyan.biz/graphic-design-discussion-how-color-and-contrast-affect-readability-2/
Text where different words in the same sentence are in different colors is
even harder to read.
And I th
On Wed, Jan 30, 2019 at 3:43 AM Jonathan Fine wrote:
> I think Steve's suggestion fails in this situation. Suppose wibble.py
> contains a function fn. Now do
>import wibble
>fn = wibble.fn
># Modify and save wibble.py
>reload(wibble)
>fn()
>
Sure -- but this is just a warning
> Capitalizing constants may be slightly harder to read but constants in
code are the minority and emphasizing them is precisely the point.
The question I'm trying to get everyone to actually think about:
Is the communication of constancy via ALL CAPS so important that it must be
in PEP-8 despite
On Thu, Jan 31, 2019 at 8:23 AM Abe Dillon wrote:
>
> > Capitalizing constants may be slightly harder to read but constants in code
> > are the minority and emphasizing them is precisely the point.
>
> The question I'm trying to get everyone to actually think about:
>
> Is the communication of co
[Steven D'Aprano]
> > ALL_CAPS_IS_OBNOXIOUS
> >
> > It destroys the visual flow of code
> Does it? This claim doesn't ring true to me. To me, "visual flow of
> code" is the way it flows down and across the page, not the shape of the
> individual words.
It does. Your field of vision is two-dimens
On 30Jan2019 15:22, Abe Dillon wrote:
Capitalizing constants may be slightly harder to read but constants in
code are the minority and emphasizing them is precisely the point.
The question I'm trying to get everyone to actually think about:
Is the communication of constancy via ALL CAPS so im
[ChrisA]
> Nobody is saying that the *entire document* should be in all caps.
I've never claimed as much. Most of the reasons all caps harm readability
hold true whether you're talking about a single word or entire document.
[ChrisA]
> Are English paragraphs hard to read because tokens like "H
On Thu, Jan 31, 2019 at 9:41 AM Abe Dillon wrote:
>
> [ChrisA]
>>
>> Nobody is saying that the *entire document* should be in all caps.
>
>
> I've never claimed as much. Most of the reasons all caps harm readability
> hold true whether you're talking about a single word or entire document.
You h
[Steven D'Aprano]
> I've just watched it, ... it is a great video.
I'm really glad you did. I don't think many have, which I can't really
blame anyone for because it's rather long, but if all this thread
accomplishes is a few more people seeing that video, it'll have been worth
it.
[Steven D'Ap
>
> > [ChrisA]
> >>
> >> Nobody is saying that the *entire document* should be in all caps.
> >
> >
> > I've never claimed as much. Most of the reasons all caps harm
> readability hold true whether you're talking about a single word or entire
> document.
> You have implied it by making the claim ab
On Wed, Jan 30, 2019 at 03:51:22PM -0600, Abe Dillon wrote:
> [Steven D'Aprano]
>
> > > ALL_CAPS_IS_OBNOXIOUS
> > >
> > > It destroys the visual flow of code
> > Does it? This claim doesn't ring true to me. To me, "visual flow of
> > code" is the way it flows down and across the page, not the shap
Let's see if this gets any download at all: https://pypi.org/project/mapjoin/
Sorry for this obscenity xD
Thank you all for your replies !
Have a great day
Best regards
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mail
On Wed, Jan 30, 2019 at 01:47:56PM -0600, Abe Dillon wrote:
> > Is it that really obnoxious?
>
> EXTREMELY!
I don't agree with you that the use of one or two words in a sentence
for EMPHASIS is obnoxious, and I don't writing a one-word sentence is a
good test of that.
In any case, even if it i
[Steven D'Aprano]
> I'm not disputing that,
I mean, you literally wrote:
[Steven D'Aprano]
> To me, "visual flow of code" is the way it flows down and across the
> page, *not* the shape of the
> individual words.
So it sounded a lot like you were.
[Steven D'Aprano]
> I'm disputing your cla
On Wed, Jan 30, 2019 at 5:54 PM Jamesie Pic wrote:
>
> What do you think about the cost of typing caps ? Surely, shift
> aggravates repeated strain injury.
We spend more time reading code than typing it— even more so with code
completion.
It’s a style *guide* folks — let it go!
- CHB
> -
> I'm just saying assembling strings is
> a common programing task and that we have two different methods with
> the same name and inconsistent signatures
No, we don’t — one is for assembling paths, one for generic strings.
And in recent versions, there is a new totally different way to assembl
On Thu, Jan 31, 2019 at 2:24 AM Steven D'Aprano wrote:
>
> Consequently the cost of reading the all-caps word is tiny, and the
> benefit is greater.
>
What do you think about the cost of typing caps ? Surely, shift
aggravates repeated strain injury.
--
∞
[Christopher Barker]
> It’s a style *guide* folks — let it go!
While I don't harbor any delusions that this is going anywhere (given the
feedback so far), that's a double edged sword. It's also an extremely
benign request, why fight so hard?
On Wed, Jan 30, 2019 at 8:00 PM Christopher Barker
w
On Thu, Jan 31, 2019 at 1:05 PM Abe Dillon wrote:
>
> [Christopher Barker]
>>
>> It’s a style *guide* folks — let it go!
>
>
> While I don't harbor any delusions that this is going anywhere (given the
> feedback so far), that's a double edged sword. It's also an extremely benign
> request, why f
On Wed, Jan 30, 2019, 4:23 PM Abe Dillon Consider that math.pi and math.e are constants that are not all caps,
> have you ever been tempted to re-bind those variables?
>
I generally use 'from math import pi as PI' because the lower case is
confusing and misnamed.
_
Thank you Christopher for the heads up. Using paths as an example were
really poor, they distract readers from the actual problem that is
assembling a human readable string.
Maybe pointless, but on the basis of 30 seconds to run my test suite,
see my failure, correct it, and run it again to be at
[Calvin Spealman]
> Why not allow excepts on fo loops, for example?
Why not, indeed...
I've heard there's a non-insignificant performance penalty for setting up a
try statement, so it might be important to only set a for-loop up as a
guarded for-loop upon reading the "except" statement (if the
On Wed, Jan 30, 2019 at 12:37:45PM +0100, Jamesie Pic wrote:
> Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
> might also want to throw in a "key" kwarg, that could be none by
> default to keep BC, but also allow typecasting:
>
> ' '.join('a', 2, key=str)
Please don't misrepr
On Thu, Jan 31, 2019 at 5:09 PM Steven D'Aprano wrote:
>
> On Wed, Jan 30, 2019 at 12:37:45PM +0100, Jamesie Pic wrote:
> > Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
> > might also want to throw in a "key" kwarg, that could be none by
> > default to keep BC, but also allow
On Wed, Jan 30, 2019 at 08:27:41PM -0600, Abe Dillon wrote:
> I've heard there's a non-insignificant performance penalty for setting up a
> try statement, so it might be important to only set a for-loop up as a
> guarded for-loop upon reading the "except" statement (if the compiler can
> handle su
On Wed, Jan 30, 2019 at 05:41:56PM -0600, Abe Dillon wrote:
> I don't know how to make myself more clear. I haven't been talking about
> entire documents. Some of the links I provided discuss tests conducted on
> entire documents. That is not relevant to this discussion.
Then why on earth are you
On 1/30/2019 6:41 PM, Abe Dillon wrote:
I think continued discussion is pretty useless. 1. Most everything
relevant has been said, likely more than once, and 2. The required
core-developer support does not exist.
PEP 8 was written by Guido with input from other core developers. As
Chris
58 matches
Mail list logo
