Hi,
I'm wondering if it's possible and consistent that loosen 'as' assignment, for
example:
>>> import psycopg2 as pg
>>> import psycopg2.extensions as pg.ex
You can't now assign to an attribute in as statement but are there some reasons?
To be honest, I'll be satisfied if the statement above be
On Fri, Jun 15, 2018 at 11:54:42PM -0400, Brian Allen Vanderburg II via
Python-ideas wrote:
> An idea I had is that it could be possible for a decorator function to
> declare a parameter which, when the function is called as a decorator,
> the runtime can fill in various information in the parame
Just a small idea that could possibly be useful for python decorators.
An idea I had is that it could be possible for a decorator function to
declare a parameter which, when the function is called as a decorator,
the runtime can fill in various information in the parameters for the
decorator to us
On 16Jun2018 02:42, Mikhail V wrote:
Now I have slightly different idea. How is about special-casing of this
as a shortcut for append:
L[] = item
Namely just use the fact that empty slice is SyntaxError now.
Now we're just making typing errors into working code.
Also, that isn't an empty sl
On Fri, Jun 15, 2018, 6:18 PM Mikhail V wrote:
> On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote:
>
> > One of those links was discussing extend, not append.
>
> Yes and so what? ... What is different with append?
Luckily for extend, it's similar to the "obvious" semantics of ``a += b``
w
Mikhail V wrote:
But I see from various posts in the web and SO - people
just want to spell it compact, and keep the 'item' part clean of
brackets.
Where have you seen these posts?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https:/
On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote:
> One of those links was discussing extend, not append.
Yes and so what? Does this makes it automatically not related to
the wish to choose more compact spelling, despite it is not
recommended way. What is different with append?
Similar posts
On 6/15/2018 8:42 PM, Greg Ewing wrote:
Mikhail V wrote:
It s just very uncommon to see standalone statements like:
x.method()
for me it came into habit to think that it lacks the left-hand part
and =.
You must be looking at a very limited and non-typical
corpus of Python code. Mutating meth
Michael Selik wrote:
The += operator was meant as an alias for ``x = x + 1``. The
fact that it mutates a list is somewhat of a surprise.
That's very much a matter of opinion. For every person who
thinks this is a surprise, you can find another that thinks
it's obvious that += should mutate a li
One of those links was discussing extend, not append. The other wanted a
repeated append, best solved by a list comprehension. Neither makes a good
case for your suggestion.
On Fri, Jun 15, 2018, 5:40 PM Mikhail V wrote:
> On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote:
> >
> >
> > On Fri
Mikhail V wrote:
It s just very uncommon to see standalone statements like:
x.method()
for me it came into habit to think that it lacks the left-hand part and =.
You must be looking at a very limited and non-typical
corpus of Python code. Mutating method calls are
extremely common in most Pyth
On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote:
>
>
> On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote:
>>
>> there is just nothing against append() method.
>
>
> Then why break the Zen: there should be only one obvious way?
I think the question could be applied to 99% proposals
>> But I see
On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote:
> there is just nothing against append() method.
>
Then why break the Zen: there should be only one obvious way?
But I see from various posts in the web and SO - people just want to spell
> it compact, and keep the 'item' part clean of brackets.
On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge wrote:
> * people doing heavy numerical work and wanting code as readable as possible
IME serious numerical work doesn't use approximate equality tests at
all, except in test assertions.
> * teaching mostly beginners about finite precision for float
On Sat, Jun 16, 2018 at 3:02 AM, Chris Angelico wrote:
> On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote:
>> Now I have slightly different idea. How is about special-casing of this
>> as a shortcut for append:
>>
>> L[] = item
>>
>> Namely just use the fact that empty slice is SyntaxError now.
>
On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote:
> Now I have slightly different idea. How is about special-casing of this
> as a shortcut for append:
>
> L[] = item
>
> Namely just use the fact that empty slice is SyntaxError now.
>
> I understand this is totally different approach than operator
Now I have slightly different idea. How is about special-casing of this
as a shortcut for append:
L[] = item
Namely just use the fact that empty slice is SyntaxError now.
I understand this is totally different approach than operator
overloading and maybe
hard to implement, but I feel like it loo
On Fri, Jun 15, 2018 at 3:12 PM Richard Damon
wrote:
> On 6/15/18 1:38 PM, Andre Roberge wrote:
> > I have a suggestion to make inspired by the current discussion about
> > trigonometric functions in degrees, and the desire to have them show
> > "exact" values in some special cases.
> >
> > I sug
On 6/15/18 1:38 PM, Andre Roberge wrote:
> I have a suggestion to make inspired by the current discussion about
> trigonometric functions in degrees, and the desire to have them show
> "exact" values in some special cases.
>
> I suggest that it would be useful to have operators for performing
> **a
On 6/15/18 1:25 PM, Mikhail V wrote:
> On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote:
>> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
>>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>>>
If you would like to prove the need for this operator, one piece of
evidence
On Fri, 15 Jun 2018 14:38:22 -0300
Andre Roberge
wrote:
>
> Here's a sample session for demonstration purpose...
>
> $ python -m experimental
> experimental console version 0.9.5. [Python version: 3.6.1]
>
> ~~> 0.1 + 0.2
> 0.30004
> ~~> 0.1 + 0.2 == 0.3
> False
> ~~> from __exp
On Fri, Jun 15, 2018 at 10:25 AM Mikhail V wrote:
> very uncommon to see standalone statements like: x.method()
>
Python has many such mutation methods. It sounds like you're judging the
frequency of code patterns across all languages instead of just Python.
Even then, I don't think that's true.
I have a suggestion to make inspired by the current discussion about
trigonometric functions in degrees, and the desire to have them show
"exact" values in some special cases.
I suggest that it would be useful to have operators for performing
**approximate** comparisons. I believe that such operat
On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote:
> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>>
>>> If you would like to prove the need for this operator, one piece of evidence
>>> you can provide is a count of the number of
On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>
>> If you would like to prove the need for this operator, one piece of evidence
>> you can provide is a count of the number of times someone writes
>> "list.append" for an iterable vs "+="
On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
> If you would like to prove the need for this operator, one piece of evidence
> you can provide is a count of the number of times someone writes
> "list.append" for an iterable vs "+=" and encloses a str or other type in a
> throw-away list t
On 6/13/18 7:21 AM, Stephan Houben wrote:
>
>
> Op wo 13 jun. 2018 13:12 schreef Richard Damon
> mailto:rich...@damon-family.org>>:
>
> My first comment is that special casing values like this can lead to
> some very undesirable properties when you use the function for
> numerical
>
On Fri, Jun 15, 2018 at 10:10:19AM +0200, Michel Desmoulin wrote:
> Fantastic idea. Would this make sense on var() too ? It's not exactly
> the same usage context.
No. The point of vars() is to return the actual namespace dict used by
an object. It's not primarily an introspection tool, it is th
Le 14/06/2018 à 11:27, Steve Barnes a écrit :
> Currently when working with interactive sessions using the dir() or
> dir(module) built in is incredibly useful for exploring what
> functionality is available in a module. (Especially the regrettable
> libraries or modules that add really valuab
Le 14/06/2018 à 07:29, Steven D'Aprano a écrit :
> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>
>>> Attaching an entire module to a type is probably worse than
>>> adding a slew of extra methods to the type.
>>>
>>
>> Not my point.
>>
>> str.re would not be the re module,
30 matches
Mail list logo
