On Mon, Oct 24, 2016 at 05:37:29PM -0700, Chris Barker - NOAA Federal wrote:
> > On Oct 24, 2016, at 3:54 PM, Chris Angelico wrote:
>
> > . But in any case,
> > this is a question you can't even ask until replace() accepts multiple
> > arguments. Hence I'm +1 on the notion of simultaneous replace
>
> As a practicing economist, I wonder what use cases you're referring
> to. I can't think of any use cases where if one previous value is
> useful, having all previous values available (ie, an arbitrary
> temporal structure, at the modeler's option) isn't vastly more useful.
>
Well, see the ite
I was thinking of posting something like the first suggestion myself. Both
would be a great additions.
On Monday, October 24, 2016 at 6:10:52 PM UTC-4, Ryan Gonzalez wrote:
>
> I personally find it kind of annoying when you have code like this:
>
>
> x = A(1, B(2, 3))
>
>
> and Python's error me
On 25 October 2016 at 03:16, Chris Barker wrote:
> On Sat, Oct 22, 2016 at 9:17 AM, Nick Coghlan wrote:
>
>>
>> This is actually a case where style guidelines would ideally differ
>> between between scripting use cases ... and
>> library(/framework/application) development use cases
>
>
> Hmm --
Also, for something like this:
In [1]: class A:
...: pass
...:
In [2]: A(x=2)
---
TypeError Traceback (most recent call last)
in ()
> 1 A(x=2)
TypeError: object() takes no param
On 25 October 2016 at 03:32, Chris Barker wrote:
> On Sat, Oct 22, 2016 at 8:22 PM, Nick Coghlan wrote:
>> The big refactoring benefit that this feature would offer over with
>> statements is that it doesn't require a structural change to the code
>> - it's just wrapping an existing expression in
On 25 October 2016 at 11:59, Stephen J. Turnbull
wrote:
> On the semantic side,
> constructs like closures and generators (which they may be cargo-
> culting!) mean that it's harder to link resource management to
> (syntactic) function calls than a new developer might think. (Isn't
> that Nathani
Thos are great idea. I love the current trend of trying to give better
error messages.
Another pet peave of mine: TypeError not providing at least 'raiser'
'accepted type', 'given value' and 'given value type'.
E.G, int() does an ok job:
>>> int(foo)
ValueError: invalid literal for
On Wed, Oct 26, 2016 at 12:20 AM, Michel Desmoulin
wrote:
> list, set and tuple less not as good:
>
> >>> tuple(foo)
>
> TypeError: 'int' object is not iterable
>
> No raiser, no value given. It's hard to find out what's the problem is. The
> biggest issue here is that if you have a long l
Danilo J. S. Bellini writes:
No attribution. Please attribute, at least when you mix quotes from
different people.
> > As a practicing economist, I wonder what use cases you're referring
> > to. I can't think of any use cases where if one previous value is
> > useful, having all previous val
On 25 October 2016 at 23:20, Michel Desmoulin wrote:
> Should we make a PEP with all of those ?
No, incrementally improving error messages doesn't require PEP level
advocacy - it just requires folks doing the development and review
work of updating them without breaking anything, and adjusting th
On 25 October 2016 at 15:02, Stephen J. Turnbull
wrote:
> I did. They are very persuasive ... up to the point where you ask for
> syntax for something that appears (now that you've done it, kudos!) to
> be perfectly do-able with a function.
This is an important point by the way. Ideas on this li
On Tue, Oct 25, 2016 at 05:18:46AM -0200, Danilo J. S. Bellini wrote:
> > [...]. From what
> > I remember, the conclusion reached was that there are too
> > many degrees of freedom to be able to express reduction
> > operations in a comprehension-like way that's any clearer
Danilo, if you are goi
On 25 October 2016 at 04:37, Steven D'Aprano wrote:
>> I would be happy to see a somewhat more general and user friendly
>> version of string.translate function.
>> It could work this way:
>> string.newtranslate(file_with_table, Drop=True, Dec=True)
> Mikhail, I appreciate that you have many ide
On 2016-10-25 4:33 AM, Nick Coghlan wrote:
I'm starting to think that we instead need a way
to let them easily say "This resource, the one I just created or have
otherwise gained access to? Link its management to the lifecycle of
the currently running function or frame, so it gets cleaned up wh
Mikhail V writes:
> Good. But of course if I do it with big tables, I would anyway
> need to parse them from some table file.
That is the kind of thing we can dismiss (for now) as a "SMOP" =
"simple matter of programming". You know how to do it, we know how to
do it, if it needs optimization,
On 2016-10-25 00:18, Danilo J. S. Bellini wrote:
Well, see the itertools.accumulate examples yourself then, the ones at
docs.python.org... We can start with something really simple like
interest rates or uniform series, but... before arguing here, please
convince other people to update the Wikip
On 24/10/2016 06:11, Danilo J. S. Bellini wrote:
For example, a product:
>>> [prev * k for k in [5, 2, 4, 3] from prev = 1]
[1, 5, 10, 40, 120]
That makes sense for me, and seem simpler than:
>>> from itertools import accumulate, chain
>>> list(accumulate(chain([1], [5, 2, 4, 3]), lambda pr
We have a syntax to create strings with variables automatically inferred
from its context:
>>> name = "Guido"
>>> print(f'Hello {name}')
Hello Guido
Similarly, I'd like to suggest a similar feature for building dictionaries:
>>> foo = 1
>>> bar = 2
>>> {:bar, :foo}
{'bar': 1, 'foo', 2}
And a
On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico wrote:
> On Wed, Oct 26, 2016 at 12:20 AM, Michel Desmoulin
> wrote:
>> list, set and tuple less not as good:
>>
>> >>> tuple(foo)
>>
>> TypeError: 'int' object is not iterable
>>
>> No raiser, no value given. It's hard to find out what's th
On Tue, Oct 25, 2016 at 6:20 AM, Michel Desmoulin
wrote:
> Some things deserve a big explanation to solve the problem. It would be nice
> to add a link to official tutorial in the documentation.
>
> E.G, encoding is a big one:
>
>In [8]: b'é' + 'é'
> File "", line 1
>b'é' + 'é'
>
On 25 October 2016 at 20:11, Michel Desmoulin wrote:
> Similarly, I'd like to suggest a similar feature for building dictionaries:
>
foo = 1
bar = 2
{:bar, :foo}
> {'bar': 1, 'foo', 2}
I don't see a huge advantage over
>>> dict(foo=foo, bar=bar)
Avoiding having to repeat the vari
I've seen a lot of syntax proposals recently that are based around
providing better ways of writing "one liner" styles of code.
Typically, the proposals seem to get into trouble because:
1. They duplicate things that can already be done, just not in a
single expression/statement.
2. They are seen
Le 25/10/2016 à 22:27, Paul Moore a écrit :
On 25 October 2016 at 20:11, Michel Desmoulin wrote:
Similarly, I'd like to suggest a similar feature for building dictionaries:
foo = 1
bar = 2
{:bar, :foo}
{'bar': 1, 'foo', 2}
I don't see a huge advantage over
dict(foo=foo, bar=bar)
Avoi
On 25 October 2016 at 20:17, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO. If someone's willing to do the work to make the
On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico wrote:
> > >>> tuple(foo)
> >
> > TypeError: 'int' object is not iterable
> >
> > No raiser, no value given. It's hard to find out what's the problem is.
> The
> > biggest issue here is that if you have a long line with tuple() in the
> > mi
So, based on everyone's feedback, I just created this:
http://bugs.python.org/issue28536
On Mon, Oct 24, 2016 at 5:07 PM, Ryan Gonzalez wrote:
> I personally find it kind of annoying when you have code like this:
>
>
> x = A(1, B(2, 3))
>
>
> and Python's error message looks like this:
>
>
> Ty
On Mon, Oct 24, 2016 at 7:00 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Chris Barker writes:
>
> > I think the "better error message" option is the way to go,
> > however. At least until we all have better Unicode support in all
> > our tools
>
> I don't think "
Also, as an extension of this idea, would it be possible to improve errors
like this:
class X: pass
X() # object() takes no parameters
to show the actual type instead of just 'object'?
On Tue, Oct 25, 2016 at 4:48 PM, Ryan Gonzalez wrote:
> So, based on everyone's feedback, I just created th
But that's something of a solved problem. IPython offers a rich
> interactive environment, for people who find the limitations of the
> standard interactive prompt frustrating. Would it be worth the
> standard Python documentation promoting IPython for that role?
+1 iPython really makes it easier
Would recommend bpython, it is lighter-weight and accessible to newbies, in the
sense that a manual is not needed. It just starts helping out as you type.
http://bpython-interpreter.org/
___
Python-ideas mailing list
Python-ideas@python.org
https://m
On Wed, Oct 26, 2016 at 8:50 AM, Chris Barker wrote:
> that was kind of a throwaway comment, but I think it's a LONG way out, but
> ideally, the OWTDI would be "curly quotes". The fact that in ASCII, a single
> quote and a apostrophe are teh same, and that there is no distinction
> between opening
On Sat, Oct 22, 2016 at 9:02 AM, Nick Coghlan wrote:
> On 20 October 2016 at 07:02, Nathaniel Smith wrote:
>> The first change is to replace the outer for loop with a while/pop
>> loop, so that if an exception occurs we'll know which iterables remain
>> to be processed:
>>
>> def chain(*iterables
On 25 October 2016 at 19:10, Stephen J. Turnbull
wrote:
> So my previous thought on it was, that there could be set of such functions:
>
> str.translate_keep(table) - this is current translate, namely keeps
> non-defined chars untouched
> str.translate_drop(table) - all the same, but droppin
...Doh. I spent all that time evaluating the function-scoped-cleanup
proposal from the high-level design perspective, and then immediately
after hitting send, I suddenly realized that I'd missed a much more
straightforward technical problem.
One thing that 'with' blocks / for-scoped-iterclose do i
On 25 October 2016 at 23:50, Chris Barker wrote:
>that was kind of a throwaway comment,
>but I think it's a LONG way out, but ideally,
>the OWTDI would be "curly quotes". The fact that in ASCII,
>a single quote and a apostrophe are teh same,
>and that there is no distinction between opening
>and
On Tue, Oct 25, 2016 at 2:55 PM, Chris Barker wrote:
>
>
>> But that's something of a solved problem. IPython offers a rich
>> interactive environment, for people who find the limitations of the
>> standard interactive prompt frustrating. Would it be worth the
>> standard Python documentation prom
On 14/10/2016 07:00, Greg Ewing wrote:
Neil Girdhar wrote:
At the end of this discussion it might be good to get a tally of how
many people think the proposal is reasonable and logical.
I think it's reasonable and logical.
I concur. Two points I personally find in favour, YMMV:
(1) [*subs
On Tue, Oct 25, 2016 at 04:55:21PM -0500, Ryan Gonzalez wrote:
> Also, as an extension of this idea, would it be possible to improve errors
> like this:
>
>
> class X: pass
> X() # object() takes no parameters
>
>
> to show the actual type instead of just 'object'?
My wild guess is that the ca
On Tue, Oct 25, 2016 at 12:17:56PM -0700, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO.
I think its even lower than most
Yeah, I just checked the source and tried changing it. Seems to work well.
On Tue, Oct 25, 2016 at 8:11 PM, Steven D'Aprano
wrote:
> On Tue, Oct 25, 2016 at 04:55:21PM -0500, Ryan Gonzalez wrote:
> > Also, as an extension of this idea, would it be possible to improve
> errors
> > like this:
> >
On 26 October 2016 at 00:53, Mikhail V wrote:
> On 25 October 2016 at 23:50, Chris Barker wrote:
>
>>that was kind of a throwaway comment,
>>but I think it's a LONG way out, but ideally,
>>the OWTDI would be "curly quotes". The fact that in ASCII,
>>a single quote and a apostrophe are teh same,
>
On Tue, Oct 25, 2016 at 05:15:58PM +0200, Mikhail V wrote:
[...]
> >Or it can take a mapping (usually a dict) that maps either characters or
> >ordinal numbers to a new string (not just a single character, but an
> >arbitrary string) or ordinal numbers.
> >
> >str.maketrans({'a': 'A', 98: 66,
On Tue, Oct 25, 2016 at 1:55 PM, Rob Cliffe
wrote:
>
> >>> [prev * k for k in [5, 2, 4, 3] from prev = 1]
> [1, 5, 10, 40, 120]
>
> That makes sense for me, and seem simpler than:
>
> >>> from itertools import accumulate, chain
> >>> list(accumulate(chain([1], [5, 2, 4, 3]), lambda prev, k: prev *
This is a nice summary of quotation marks used in various languages:
https://en.wikipedia.org/wiki/Quotation_mark#Specific_language_features
On Tue, Oct 25, 2016 at 9:37 PM, Mikhail V wrote:
> On 26 October 2016 at 00:53, Mikhail V wrote:
> > On 25 October 2016 at 23:50, Chris Barker wrote:
>
On 26 October 2016 at 03:40, Steven D'Aprano wrote:
> in a "table.txt" file, and typing:
>
> {
> 123: 456,
> 124: 457,
> 125: 458,
> # two hundred more lines
> }
>
>
> in a "table.py" file? The difference is insignificant. And the Python
> version can be cleaned up:
>
Ok, you have opened my eyes
46 matches
Mail list logo
