Re: [Python-ideas] Attribute-Getter Syntax Proposal

[Chris Barker - NOAA Federal via Python-ideas]

>
> Rather than using map in this way, I would recommend a list comprehension:

Exactly! I really don’t get why folks want to use map() so much when
the comprehension syntax is often cleaner and easier. It was added for
a reason :-)

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Chris Barker - NOAA Federal via Python-ideas]

> Alex Shafer via Python-ideas wrote:
>> 1) I'm in favor of adding a stringify method to all collections
>
> Are you volunteering to update all the collection
> classes in the world written in Python? :-)

To be fair, we could add an implementation to the sequence ABC, and
get pretty far.

Not that I’m suggesting that — as I said earlier, Python is all about
iterables,  not sequences, anyway.

Also, despite some folks’ instance that this “stringify’ method is
something many folks want -.I’m not even sure what it is.

I was thinking it was:

def stringify(self, sep):
 return sep.join(str(i) for i in self)

Which, by the way would work for any iterable :-)

If you want a language designed specifically for text processing, use Perl.

Python is deliberately strongly typed, so that:

2 + “2”

Raises an error. Why should:

“”.join([2, “2”]) not raise an error as well?

And aside from repr or ascii, when I turn numbers into text, I usually
want to control the formatting anyway:

“ “.join(f”{n:.2f}” for n in seq)

So having str() called automatically for a join wouldn’t be that useful.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

[Chris Barker - NOAA Federal via Python-ideas]

>>> and the test for an iterator is:
>>>
>>>   obj is iter(obj)

Is that a hard and fast rule? I know it’s the vast majority of cases,
but I imagine you could make an object that behaved exactly like an
iterator, but returned some proxy object rather that itself.

Not sure why one would do that, but it should be possible.

- CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

[Chris Barker - NOAA Federal via Python-ideas]

Perhaps I got confused by the early part of this discussion.

My point was that there is no “map-like” object at the Python level.
(That is no Map abc).

Py2’s map produced a sequence. Py3’s map produced an iterable.

So any API that was expecting a sequence could accept the result of a
py2 map, but not a py3 map. There is absolutely nothing special about
map here.

The example of range has been brought up, but I don’t think it’s
analogous — py2 range returns a list, py3 range returns an immutable
sequence. Because that’s as close as we can get to a sequence while
preserving the lazy evaluation that is wanted.

I _think_ someone may be advocating that map() could return an
iterable if it is passed a iterable, and a sequence of it is passed a
sequence. Yes, it could, but that seems like a bad idea to me.

But folks are proposing a “map” that would produce a lazy-evaluated
sequence. Sure — as Paul said, put it up on pypi and see if folks find
it useful.

Personally, I’m still finding it hard to imagine a use case where you
need the sequence features, but also lazy evaluation is important.

Sure: range() has that, but it came at almost zero cost, and I’m not
sure the sequence features are used much.

Note: the one use-case I can think of for a lazy evaluated sequence
instead of an iterable is so that I can pick a random element with
random.choice(). (Try to pick a random item from. a dict), but that
doesn’t apply here—pick a random item from the source sequence
instead.

But this is specific example of a general use case: you need to access
only a subset of the mapped sequence (or access it out of order) so
using the iterable version won’t work, and it may be large enough that
making a new sequence is too resource intensive.

Seems rare to me, and in many cases, you could do the subsetting
before applying the function, so I think it’s a pretty rare use case.

But go ahead and make it — I’ve been wrong before :-)

-CHB




Sent from my iPhone

> On Dec 11, 2018, at 6:47 AM, Steven D'Aprano  wrote:
>
>> On Mon, Dec 10, 2018 at 05:15:36PM -0800, Chris Barker via Python-ideas 
>> wrote:
>> [...]
>> I'm still confused -- what's so wrong with:
>>
>> list(map(func, some_iterable))
>>
>> if you need a sequence?
>
> You might need a sequence. Why do you think that has to be an *eager*
> sequence?
>
> I can think of two obvious problems with eager sequences: space and
> time. They can use too much memory, and they can take too much time to
> generate them up-front and too much time to reap when they become
> garbage. And if you have an eager sequence, and all you want is the
> first item, you still have to generate all of them even though they
> aren't needed.
>
> We can afford to be profligate with memory when the data is small, but
> eventually you run into cases where having two copies of the data is one
> copy too many.
>
>
>> You can, of course mike lazy-evaluated sequences (like range), and so you
>> could make a map-like function that required a sequence as input, and would
>> lazy evaluate that sequence. This could be useful if you weren't going to
>> work with the entire collection,
>
> Or even if you *are* going to work with the entire collection, but you
> don't need them all at once. I once knew a guy whose fondest dream was
> to try the native cuisine of every nation of the world ... but not all
> in one meal.
>
> This is a classic time/space tradeoff: for the cost of calling the
> mapping function anew each time we index the sequence, we can avoid
> allocating a potentially huge list and calling a potentially expensive
> function up front for items we're never going to use. Instead, we call
> it only on demand.
>
> These are the same principles that justify (x)range and dict views. Why
> eagerly generate a list up front, if you only need the values one at a
> time on demand? Why make a copy of the dict keys, if you don't need a
> copy? These are not rhetorical questions.
>
> This is about avoiding the need to make unnecessary copies for those
> times we *don't* need an eager sequence generated up front, keeping the
> laziness of iterators and the random-access of sequences.
>
> map(func, sequence) is a great candidate for this approach. It has to
> hold onto a reference to the sequence even as an iterator. The function
> is typically side-effect free (a pure function), and if it isn't,
> "consenting adults" applies. We've already been told there's at least
> one major Python project, Sage, where this would have been useful.
>
> There's a major functional language, Haskell, where nearly all sequence
> processing follows this approach.
>
> I suggest we provide a separate mapview() type that offers only the lazy
> sequence API, without trying to be an iterator at the same time. If you
> want an eager sequence, or an iterator, they're only a single function
> call away:
>
>list(mapview_instance)
>iter(mapview_instance)  # or just stick to map()
>
> Rather than trying to guess whether people want to 

Re: [Python-ideas] Relative Imports

[Chris Barker - NOAA Federal via Python-ideas]

This is somewhat unpleasant to me, especially while developing something
and trying to test it quickly.
I just want to be able to use same relative imports and run single file
with `python3 test_main.py` for example.


I had the same frustration when I first tried to use relative imports.

Then I discovered setuptools’ develop mode (now pip editable install)

It is the right way to run code in packages under development.

-CHB


Running files as modules every time is tiring. This is my problem.
I could not come up with a concrete solution idea yet i am thinking on it.
Open to suggestions.

Thank you all for your help!

On Fri, Nov 9, 2018 at 4:16 PM Steven D'Aprano  wrote:

> On Fri, Nov 09, 2018 at 03:51:46PM -0800, danish bluecheese wrote:
> > └── src
> > ├── __init__.py
> > ├── main.py
> > └── test
> > ├── __init__.py
> > └── test_main.py
> >
> > assume the structure above. To be able to use relative imports with such
> > fundamental structure either i can go for sys.path hacks or could run as
> a
> > module from one further level parent.
>
> I don't understand. From the top level of the package, running inside
> either __init__ or main, you should be able to say:
>
> from . import test
> from .test import test_main
>
> From the test subpackage, you should be able to say:
>
> from .. import main
>
> to get the src/main module, or
>
> from . import test_main
>
> to get the test/test_main module from the test/__init__ module.
>
> (Disclaimer: I have not actually run the above code to check that it
> works, beyond testing that its not a SyntaxError.)
>
> What *precisely* is the problem you are trying to solve, and your
> proposed solution?
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Chris Barker - NOAA Federal via Python-ideas]

> This violates the Liskov Substitution Principle.

If we REALLY had a time machine, then dict would subclass frozendict,
and we’d be all set.

But to what extent do we need to support ALL the ways to check for an
interface?

Personally, I think EAFTP is the most “Pythonic”, but if folks want to
check up front, then isn’t that what ABCs are for? In which case , we
already have Mapping and MutableMapping.

So if you have code that checks for Mapping when you need it mutable,
then that’s arguably a bug.

And if you code checks for dict directly, then it’s arguably unpythonic.

That being said, it probably is best not to break working code.

Would there be unpleasant consequences to making dict a subclass of FrozenDict ?

Or maybe come up with a new name: after all, lists and tuples are
independent, even though you *could* think of a tuple as a FrozenList
...

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] support toml for pyproject support

[Chris Barker - NOAA Federal via Python-ideas]

If I had the energy to argue it I would also argue against using TOML
> in those PEPs.


I partook in that discussion, and I still have no idea why TOML was chosen,
over, say, a defined subset of YAML, or a slightly extended JSON.

But the folks that were highly invested  and putting the work in made a
choice, so here we are.

 But if it’s in the PEPs, it seems time to define a version used ( 1.0
would be good, but often that’s actually pretty arbitrary) and get an
implementation into the stdlib.

If the TOML folks don’t think it’s stable enough for that, I’ve got to
wonder if it was a good choice!

We’re have enough trouble with really slow adoption of the new ways of
doing packaging, not even providing the tools seems to really defeat the
purpose.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A GUI for beginners and experts alike

[Chris Barker - NOAA Federal via Python-ideas]

> If you're talking about my PyGUI project, using it with
> wPython doesn't really make sense.

Now that you say that, I think I’m mingling memories — there was
another project that attempted to wrap TKInter, wxPython, QT .. I
always thought that was ill advised.

> The goal is to provide exactly one high-quality
> implementation for each platform, with as few layers as
> practicable between the Python API and the platform's native
> GUI facilities.

So kinda like wxWidgets but in Python — which would be nice. wxPython
definitely suffers from its C++ underpinnings.

> Implementations on top
> of wxPython, Qt etc. could probably be created,

QT might make some sense— you need something on top of X, don’t you?

>> I'd also make sure that you CAN "drop down" into the lower level toolkit 
>> fairly smoothly, if you do need something more complex that the basics.
>
> PyGUI provides everything you need to create a custom widget,
> without needing to go down to a lower level.

In that context, I was thinking about the OP’s concept— very high
level, pretty much declarative. It’s going to run into limitations
fast. So there should be s way to customize user interaction.

Too bad all the cool kids are doing web dev these days — hard to get
help with a desktop GUI project :-(

> Pyjamas seems to be something like that:
>
> https://pypi.org/project/Pyjamas/

Or it was 6 years ago :-(

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A GUI for beginners and experts alike

[Chris Barker - NOAA Federal via Python-ideas]

while True:
   button, (a,b) = form.Read()
   try:
   answer = int(a) + int(b)
   output.Update(answer)
   except:
   pass


Whoa! You really want people to write their own event loop? That seems like
a bad idea to me.

If you want people to not have to think about events much, maybe look at
traitsui for ideas.

http://docs.enthought.com/traitsui/

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Jump to function as an an alternative to call function

[Chris Barker - NOAA Federal via Python-ideas]

By the way— really kludgy, doesn’t exec() do what you want here:

Note


The default *locals* act as described for function locals()
 below:
modifications to the default *locals* dictionary should not be attempted.
Pass an explicit *locals*dictionary if you need to see effects of the code
on *locals* after function exec()
 returns.


Though great still may not effect the current local namespace.


But I’d be really surprised if there were no way to modify the local
namespace — you can mess with pretty much anything else in Python.


-CHB



Sent from my iPhone

On Aug 17, 2018, at 12:46 PM, Chris Barker  wrote:

On Thu, Aug 16, 2018 at 12:37 PM, Chris Angelico  wrote:

>
> I've no idea what interpreter you're using, but it doesn't work for me.
>

That was in iPython, with python3.6.2 -- I wouldn't have expected it to be
different in this case though -- really odd.

OK -- tired again, and it indeed it failed -- so I'm really confused. You
can see my console output -- it did indeed work at least once.



> You've changed a cached dictionary but haven't actually created a local
>

which still makes me wonder WHY locals() returns a writable dict...

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python docs: page: In what ways in None special

[Chris Barker - NOAA Federal via Python-ideas]

> None is keyword, and just like any other keyword, it can't be re-bound.


>> it's only a keyword because Python doesn't otherwise have a way of creating 
>> non-rebindable names.  It's purpose is to represent the singular object of 
>> NoneType, and in that sense it's a literal as much as [] or "".

We’re getting kind of pedantic here, but no, it’s not “as much as” —
[] and “” create new instances of a list or string.

For the purposes of this document, however, these are pretty esoteric
distinctions.

What the docs should make clear is that None ( and True and False ) is
a singleton— None will always refer to the SAME None object.

And that can be demonstrated by showing that you can’t rebind the name None.

But I think it’s misleading to say that that is the same as:

42 = “something else”

None is syntactical a name like any other — what’s special about is
that it can’t be rebound.

-CHB

>
> --
> Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Chris Barker - NOAA Federal via Python-ideas]

>
> Do we often call functools.partial on arbitrary callable objects that we
> don't know in advance?

For my part, I don’t think I’ve ever used partial in production code.
It just seems easier to simply fo it by hand with a closure ( Am I
using that term right? I still don’t quite get the terminology)

And if I had a callable class instance I wanted to “customize”, I’d
likely use an OO approach — parameterize the instance, or subclass.

So yeah, partial is probably used primarily with “regular” functions.

But then, I don’t know that we need any easier syntax anyway — maybe
I’d be more likely to use it, but it kind of feels like a feature
that’s there so we can write more functional code for the sake of
writing more functional code.

If someone’s really interested in this, a search on gitHub or
something to see how it’s used in the wild could be enlightening.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python docs page: In what ways is None special

[Chris Barker - NOAA Federal via Python-ideas]

I agree that some more docs on the specialness of None (and, to a
lessor extent, True and False).

A few comments:

> None is a keyword
> ==
 None = 0
> SyntaxError: can't assign to keyword

One of the implications of this is that “None” will always be the
Singleton None object — so you can (and should) use:

Something is None

To test for None.

> The Command Line Interpreter hides None
> =
 None

That’s a good one to highlight!

>
> None is false in a boolean context
> ==
 bool(None)
> False

Maybe this belongs more in a discussion of “Falseyness”

> Procedures return None
> ==
 a = [3,1,2]
 b = a.sort()
 a, b
> ([1, 2, 3], None)

This is less about None than about the convention that mutating
methods return None. Maybe that discussion belongs elsewhere.

> Dictionary get returns None if not found
> ==
 {}.get('dne') is None
> True

Belongs with dict docs really, and not really true — dict.get()
returns the default value, which is None be default.

> None is default return value
> =
 def fn(): pass
> ...
 fn() # No response!
 print(fn()) # Here's why.
> None

Yup.

> None is used as a sentinel default value
> ==
> Particularly useful when default value must be determined
> in body of function.
> ---
> def insort_right(a, x, lo=0, hi=None):
># ...
>if hi is None:
>hi = len(a)
> ---

This is also a convention — and primarily applies to mutable defaults,
which you hardly ever want to assign directly.

So a good example of None being used as a sentinel, but nog really
anything special about None.

-CHB
> /
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python docs page: In what ways is None special

[Chris Barker - NOAA Federal via Python-ideas]

>lot. Actually, the ?. and ?[
> operators seem like they'd be much more useful if I did more JSON
> processing -

This has been mentioned a lot in this discussion—

Maybe what we need is a smarter JSON processing package, rather than
new operators.

Granted, these operators would help the authors of suck a package(s),
but if the bulk of users didn’t need them, then no point in adding
them to the language.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting str.rreplace()

[Chris Barker - NOAA Federal via Python-ideas]

I starting g reading this thread in the middle, on a phone.

But was very confused for a while because I didn’t notice that there
were two ‘r’s at the beginning of .rreplace

Just sayin’

-CHB

Sent from my iPhone

> On Jul 19, 2018, at 9:29 AM, Paul Moore  wrote:
>
>> On 19 July 2018 at 16:25, Eric V. Smith  wrote:
>> It currently does something: it replaces all instances, just as if you
>> hadn't supplied a count (see my example below). You can't change its
>> behavior.
>
> ... without a deprecation cycle. Which is of course not worth it for
> something which could much more easily be done by adding an rreplace
> function - which is the real point of the comment.
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Performance improvements via static typing

[Chris Barker - NOAA Federal via Python-ideas]

A note here:

Earlier in the conversation about standardizing type hinting, I (among
others) was interested in applying it to C-level static typing (e.g.
Cython).

Guido made it very clear that that was NOT a goal of type hints —
rather, they were to be used for dynamic, python style types — so a
“list” is guaranteed to act like a list in python code, but not to
have the same underlying binary representation.

We could still use the same syntax for things like Cython, but they
would have a different meaning.

And a JIT compiler may not benefit from the hints at all, as it would
have to check the actual type at run-time anyway.

-CHB


Sent from my iPhone

> On Jul 20, 2018, at 2:32 AM, Stefan Behnel  wrote:
>
> Michael Hall schrieb am 19.07.2018 um 15:51:
>> While I am aware of projects like Cython and mypy, it seems to make sense
>> for CPython to allow optional enforcement of type hints, with compiler
>> optimizations related to it to be used. While this would not receive the
>> same level of performance benefits as using ctypes directly, there do
>> appear to be various gains available here.
>
> Well, first of all, a C level type check at runtime is quite fast compared
> to a byte code dispatch with stack argument handling, and can be done
> regardless of any type hints. There are various code patterns that would
> suggest a certain type ("x.append()" probably appends to a list, "x.get()"
> will likely be a dict lookup, etc.), and that can be optimised for without
> static type declarations and even without any type hints.
>
> Then, the mere fact that user code says "a: List" does not help in any way.
> Even "a: list" would not help, because any behaviour of that "list" might
> have been overridden by the list subtype that the function eventually 
> receives.
>
> The same applies to "x: float". Here, in order to gain speed, the compiler
> would have to generate two separate code paths through the entire function,
> one for C double computations, and one for Python float subtypes. And then
> exponentiate that by the number of other typed arguments that may or may
> not contain subtypes. Quite some overhead.
>
> It's unclear if the gain would have any reasonable relation to the effort
> in the end. Sure, type hints could be used as a bare trigger for certain
> optimistic optimisations, but then, it's cheap enough to always apply these
> optimisations regardless, via a C type check.
>
> Stefan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Multi-core reference count garbage collection

[Chris Barker - NOAA Federal via Python-ideas]

> You wrote:
> > I'd argue that the ref counts are not interesting at all, only a
> > side effect of one possible solution to the object life time problem.
>
> I'm happy for you to regard multi-core reference counting (MCRC) as a toy 
> problem, which won't become part of useful software.

Perhaps the point was that reference counting is only one of the
issues (race conditions?) the GIL solves.

So a GIL - free reference counting scheme may not prove to be helpful.

If that were it, we could (optionally) turn off reference counting in
multi-threaded code, and run a garbage collector once in a while
instead.

After all, cPython’s (mostly) deterministic garbage collection is not
guaranteed by the language standard.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if we were to ever shorten `A if A else B` (was: PEP 505: None-aware operators)

[Chris Barker - NOAA Federal via Python-ideas]

> my vote would go to `A otherwise B` since it's unambiguous, the case you care 
> about the state  of comes first, and it doesn't trip your brain up looking 
> for 'if'. :)

And I’d hope “otherwise” is a rare variable name :-)

- CHB

>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)

[Chris Barker - NOAA Federal via Python-ideas]

On Jul 6, 2018, at 2:10 AM, Steven D'Aprano  wrote:


I would consider statistics

to have similarities - median, mean etc are aggregate functions.


Not really, more like reduce, actually -/ you get a single result.

Histograms

are also doing something similar to grouping.

.(Yes, a few statistics apply to
nominal and ordinal data too,


And for that, a generic grouping function could be used.

In fact, allowing Counter to be used as the accumulater was one suggestion
in this thread, and would build s histogram.

Now that I think about it, you could write a key function that built a
histogram for continuous data as well.

Though that might be a bit klunky.

But if someone thinks that’s a good idea, a PR for an example would be
accepted:

https://github.com/PythonCHB/grouper

-CHB






-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow a group by operation for dict comprehension

[Chris Barker - NOAA Federal via Python-ideas]

> On Jun 28, 2018, at 5:30 PM, Chris Barker - NOAA Federal 
>  wrote:
>
> So maybe a solution is an accumulator special case of defaultdict — it uses a 
> list be default and appends by default.
>
> Almost like counter...

Which, of course, is pretty much what your proposal is.

Which makes me think — a new classmethod on the builtin dict is a
pretty heavy lift compared to a new type of dict in the collections
module.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow a group by operation for dict comprehension

[Chris Barker - NOAA Federal via Python-ideas]

> I think you accidentally swapped variables there:
> student_school_list
> vs student_by_school

Oops, yeah. That’s what I get for whipping out a message before catching a bus.

(And on a phone now)

But maybe you could wrap the defaultdict constructor around a
generator expression that transforms the list first.

That would get the keys right. Though still not call append for you.

So maybe a solution is an accumulator special case of defaultdict — it
uses a list be default and appends by default.

Almost like counter...

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add a __cite__ method for scientific packages

[Chris Barker - NOAA Federal via Python-ideas]

I think this is a fine idea, but could be achieved by convention, like
__version__, rather than by fiat.

And it’s certainly not a language feature.

So Nathaniel’s right — the thing to do now is work out the convention,
and then advocate for it.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

[Chris Barker - NOAA Federal via Python-ideas]

I don’t think anyone would argue that there would be use cases for
__max__ and __min__  special methods.

However, there is substantial overhead to adding new magic methods, so
the question is not whether it would be useful in some special cases,
but whether it would be useful enough in common enough cases to be
worth the overhead.

For example, we had a discussion on this list about adding a
__sort_key__ magic method, so that classes could make themselves
efficiently sortable.

That was not deemed generally useful enough to be worth it.

In this case, I think numpy arrays are a good example to think about
(as supposed to range objects :-) )

Numpy arrays can certainly find their max and min more efficiently
than the generic functions, and are “proper” sequences that can be
used in generic code.

But they also have a particular signature for max and min (axis
parameter) so really don’t map well to a dunder.

They also have their own ways of doing all sorts of things that are
different than a “typical” iterarable.

I expect that is the case for other special data structures like trees, etc.

So I don’t think this rises to the level of generally universal enough
for a magic method.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Chris Barker - NOAA Federal via Python-ideas]

>> However -- if this is really such a good idea -- wouldn't someone have make
>> a C lib that does it? Or has someone? Anyone looked?
>
> No, there's nothing magical about C. You can do it in pure Python.

Sure, but there are a number of FP subtleties around the edge cases.

So wrapping (or translating) an existing (well thought out) lib might
be an easier way to go.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making Path() a built in.

[Chris Barker - NOAA Federal via Python-ideas]

>>> For the startup time, you could keep it around as builtin but save the
>>> import time until someone actually uses it.
>>
>> That would mean creating a system of lazy imports, which is an
>> entirely separate proposal.
>
> It's that complicated ? I know it's not exactly properties on a class,
> but I thought there were other cases, even if I couldn't name one.
> Dont mind me, then.

It wouldn’t be THAT hard to wrote lazy-import code for pathlib.

But there has been a lot of discussion lately about Python startup time.

One approach is to create a lazy-import system that could be generally
used to help startup time.

So I expect that an expensive to import built in will not get added
unless that problem is generically solved.

And as for Steven’s other points:

There has been a fair bit of discussion here and on Python-dev about
pathlib. The fact is that it is still not ready to be a full featured
replacement for os.path, etc.

And a number of core devs aren’t all that interested in it becoming
the “one obvious way”.

So I think we are no where near it becoming a built in.

But if you like it, you can help the efforts to make it even more
useful, which would be good in itself, but is also the Path (pun
intended) to making it the “one obvious way”.

If it’s useful enough, people will use it, even if the have to import it.

There was a recent thread about adding functionality to the Oath
object that seems to have petered out— maybe contribute to that
effort?

One more point:

A major step in making pathlib useful was adding the __path__
protocol, and then adding support for it in most (all) of the standard
library.

Another step would be to make any paths in the stdlib (such as
__file__) Path objects (as suggested in this thread) but that would
bring up the startup costs problem.

I wonder if a Path-lite with the core functionality, but less startup
cost, would be useful here?

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making Path() a built in.

[Chris Barker - NOAA Federal via Python-ideas]

Sorry for the top-post — iPhone email sucks.

But: in regard to the whole “what paths to use to find resource files” issue:

The “current working directory” concept can be very helpful. You put
your files in a directory tree somewhere— could be inside the package,
could be anywhere else.

Then all paths in your app are relative to the root of that location.
So all your app needs to do is set the cwd on startup, and you’re good
to go. So you may use __file__ once at startup (or not, depending on
configuration settings)

Alternatively, in the simple web server example, you have a root path
that gets tacked on automatically in you app, so again, you use
relative paths everywhere.

The concept of non-python-code resources being accessible within a
package is really a separate issue than generic data files, etc. that
you may want to access and serve different way.

In short, if you have a collection of files that you want to access
from Python, and also might want to serve up with another application—
you don’t want to use a python resources system.

Now I’m a bit confused about the topic of the thread, but I do like
the idea of putting Path in a more accessible place. ( though a bit
concerned about startup time if it were a built in)

-CHB


Sent from my iPhone

> On Jun 5, 2018, at 6:30 AM, Michel Desmoulin  
> wrote:
>
> There are very few programs that never use any path operation.
>
> Opening a file is such a common one we have a built-in for it with
> open(), but you usually need to do some manipulation to get the file
> path in the first place.
>
> We have __file__, but the most common usage is to get the parent dir,
> with os or pathlib.
>
> Websites open static files and configurations file.
>
> GUI open files to be processed.
>
> Data processing open data source files.
>
> Terminal apps often pass files as a parameters.
>
> All those paths you may resolve, turn absolute, check against and so on.
> So much that pathlib.Path is one of the things I always put in a
> PYTHONSTARTUP since you need it so often.
>
> I think Path fits the bill for being a built-in, I feel it's used more
> often than any/all or zip, and maybe enumerate.
>
> Besides, it would help to make people use it, as I regularly meet dev
> that keep import os.path because of habits, tutorials, books, docs, etc.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add dict.append and dict.extend

[Chris Barker - NOAA Federal via Python-ideas]

> d.setdefault(key, value)

I though the OP wanted an error if the key already existed.

This is close, as it won’t change the dict if the key is already
there, but it will add it if it’s not.

@OP

Maybe post those five lines so we know exactly what you want — maybe
there is already a good solution. I know I spent years thinking “there
should be an easy way to do this” before I found setdefault().

-CHB

>
> :-)
>
> [snip]
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] String and bytes bitwise operations

[Chris Barker - NOAA Federal via Python-ideas]

>> actually, bytes are, well, bytes ;-) -- that is, 8 bits.
>
> Grammatically, you appear to be disagreeing with the assertion that
> bytes are numbers. Is that the case?

Um, yes. Though I think for the rest of the conversation, it’s a
distinction that doesn’t matter.

> If you want to be extremely technical, an "octet" is a group of eight
> bits (or eight musicians, but I haven't yet figured out how to send
> musicians down an ethernet cable), and a "byte" isn't as rigidly
> defined. But on modern PCs, you can fairly safely assume that they're
> synonymous.

Sure — a byte, I think, is the smallest unit of memory that can be
addressed. It could be more or less that 8 bytes, but that wasn’t the
point either.

> I suppose you could argue that a "byte" is a patch of
> storage capable of holding a number from 0 to 255, as opposed to being
> the number itself, but that's getting rather existential :)

No, I’m making the distinction that an eight bit byte is, well,  eight
bits, that CAN represent a number from 0 to 255, or it can represent
any other data type — like one eighth of the bits in a float, for
instance. Or a bit field, or 1/2 a 16 bit int.

> In Python, a "bytes" object represents a sequence of eight-bit units.
> When you subscript a bytes [1], you get back an integer with the value
> at that position.

And when you print it, you get the ascii characters corresponding to
each byte

So one element in a bytes object is no more an integer than a character

> So if a collection of them is called a "bytes" and
> one of them is an integer in range(0, 256), doesn't it stand to reason
> that a byte is a number?

We use a decimal number (and ascii) to represent the bytes, as it’s
more human readable and consistent with other python types.

> Maybe I'm completely misunderstanding your statement here.

Again, it doesn’t much matter, until you get to deciding how to
bitshift an entire bytes object.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Chris Barker - NOAA Federal via Python-ideas]

>
> UTC and leap seconds aren't a problem.

Of course they are a problem— why else would they not be implemented
in datetime?

But my point if that given datetimestamp or calculation could be off
by a second or so depending on whether and how leap seconds are
implemented.

It just doesn’t seem like a good idea to be handling months and
femptoseconds with the same “encoding”

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Sets, Dictionaries

[Chris Barker - NOAA Federal]

> There are two chances of this happening, zero or none.

That would be the empty set, yes?  ;-)

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2

[Chris Barker - NOAA Federal]

On Mar 23, 2018, at 7:26 AM, Steve Dower  wrote:

I had a colleague complaining to me the other day about having to search
multiple packages for the right function to move a file (implying: with the
same semantics as drag-drop).


Thanks Steve — I know there isn’t any kind of consensus about exactly what
should be part of a “most file operations” package/class, but I’ve found it
odd that there doesn’t even seem to be acknowledgment among longtime python
users that the current hodgepodge is pretty dysfunctional for new users.

One thing that’s been hammered home for me teaching newbies is that people
get very far with computing these days without ever having touched a
command line — certainly not a *nix one. Even the concept of a working
directory is foreign to many.

So telling them that they can create and manipulate paths in nifty ways
with the Path object, but then telling them to go to the os module to do
simple things like rename or delete a file, and then looking at the docs
for the os module, which starts with a bunch of references to other modules
you need for not quite as simple things (shutil) or more complex things
(tempfile). Then you look through the module and see a LOT of low level
cryptic and semi-platform dependent functions — not newbie friendly.

Heck, I’ve been using Python for almost 20 years and I still have go look
up whether it’s “delete” or “remove” or “unlink”. And there is so much in
os that ipython or IDE completion doesn’t help much.

So as not to only write a critical rant — here is a proposal of sorts:

The python standard library should have one-stop shopping for the basic
file system manipulations. “Basic” could be guided by “what users typically
do with a GUI file manager”

This could be yet another module, but given that navigating  the file
system ( I.e. path manipulation) is one of the things people typically do
with a file manager, it makes sense to add it all to pathlib, maybe even
all to the Path object. ( though maybe more advanced classes/functions
could be added to pathlib as way to put it all in one place, while not
expanding the Path namespace too much)

Of course, this will require a substantial amount of work to work out the
details in a PEP. I don’t have the time to do that, but if the OP or
someone else does, I’ll help.

-CHB






If there isn’t a pathtools library on PyPI yet, this would certainly be
valuable for newer developers. My view on Path is to either have everything
on it or nothing on it (without removing what’s already there, of course),
and since everything is so popular we should at least put everything in the
one place.



Top-posted from my Windows phone



*From: *Mike Miller 
*Sent: *Monday, March 19, 2018 10:51
*To: *python-ideas@python.org
*Subject: *Re: [Python-ideas] New PEP proposal -- Pathlib Module
ShouldContain All File Operations -- version 2





On 2018-03-18 10:55, Paul Moore wrote:

>> Should Path() have methods to access all file operations?

>

> No, (Counterexample, having a Path operation to set Windows ACLs for a
path).



Agreed, not a big fan of everything filesystem-related in pathlib, simply

because it doesn't read well.  Having them scattered isn't a great
experience

either.



Perhaps it would be better to have a filesystem package instead, maybe
named

"fs" that included all this stuff in one easy to use location.  File stuff
from

os, path stuff from os.path, pathlib, utils like stat, and shutil etc?

___

Python-ideas mailing list

Python-ideas@python.org

https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Chris Barker - NOAA Federal]

Sent from my iPhone
> A thought just occurred to me. Maybe we should just add a Boolean class to 
> numbers?

This makes lots of sense to me.

Bool is a subclass of int — might as well embrace that fact.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Temporary variables in comprehensions

[Chris Barker - NOAA Federal]

> Setting a new comprehension variable is not likely to be free, and may even be
> more costly than calling f(x) twice if f() is a cheap expression:
>
>[x+1 + some_func(x+1) for x in range(10)]
>
> could be faster than
>
>[y + some_func(y) for x in range(10) let y = x + 1]

A bit of a nit — function call overhead is substantial in python, so
if that is an actual function, rather than a simple expression, it’ll
likely be slower to call it twice for any but trivially small
iterables.


>[(y, y**2) let y = x+1 for x in (1, 2, 3, 4)]

Do we need the let?

[ g(y) for y = f(x) for c in seq]

Or, with expressions:

[y + y**2 for y = x+1 for x in (1,2,3)]

Maybe that would be ambiguous— I haven’t thought carefully about it.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Chris Barker - NOAA Federal]

>
> So as long as you are not expecting to ever need mypy you should be fine -- 
> however if you're sharing code at some point someone is probably going to 
> want to point mypy at it.

mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
less a reference implimentation, yes?

mypy support bool, as far as I can tell, will that not work for your case?

Even though the python bools are integer subclasses, that doesn’t mean
a type checker shouldn’t flag passing an integer in to a function that
expects a bool.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

[Chris Barker - NOAA Federal]

>
>  It's easier to make a good language fast than it is to make a fast language 
> good.  It's easier to hack a compiler or an interpreter to run slow code 
> faster than it is to hack the human brain to understand confusing code more 
> easily.  So I think the smart move is to take the languages that have 
> intrinsically good design from cognitive/semantic perspective (such as 
> Python) and support that good design with performant implementations.

A lot of smart people have worked on this — and this is where we are.
It turns out that keeping Python’s fully dynamic nature while making
it run faster if hard!

Maybe if more time/money/brains were thrown at cPython, it could be
made to run much faster — but it doesn’t look good.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Non-intrusive debug logging

[Chris Barker - NOAA Federal]

This strikes me as something a debugger should do, rather than the regular
interpreter.

And using comment-based syntax means that they would get ignored by the
regular interpreter— which is exactly what you want.

As for a decoration approach— that wouldn’t let you do anything on a line
by line basis.

-CHB



Sent from my iPhone

On Jan 25, 2018, at 2:44 AM, Stéfane Fermigier  wrote:

Some thoughts:

1. I too dislikes the idea of using comments as semantically significant
annotations.

I think it's quite OK for annotation that are aimed at external tools (e.g.
'# nocover' or '# noqa') but not for runtime behavior.

2. It's probably possible do do interesting things using decorators at the
function / class level.

The "q" project (https://pypi.python.org/pypi/q) already does some useful
things in that direction.

Still, when using q (or another decorator-based approach), you need to
first 'import q', which means that you can easily end up with spurious
'import q' in your code, after you're done debugging. Or even worse, commit
them but forget to add 'q' in your setup.py / requirements.txt / Pipfile,
and break CI or production.

3. Doing things unintrusively at the statement level seems much harder.

  S.


On Thu, Jan 25, 2018 at 6:54 AM, Steve Barnes 
wrote:

>
>
> On 24/01/2018 23:25, Larry Yaeger wrote:
> > Everyone uses logging during code development to help in debugging.
> Whether using a logging module or plain old print statements, this usually
> requires introducing one or (many) more lines of code into the model being
> worked on, making the existing, functional code more difficult to read.  It
> is also easy to leave logging code in place accidentally when cleaning up.
> I have a possibly odd suggestion for dramatically improving debug logging,
> in an almost automated fashion, without any of the usual problems.  I'm
> willing to jump through PEP hoops, but won't waste anyone's time arguing
> for the idea if others don't embrace it.
> >
> > In brief, make an extremely succinct comment, such as "#l" or "#dbgl",
> semantically meaningful.  If appended to a line of code, such as:
> >
> > x = 1
> > Y = 2
> > Z = 3
> > x = y + z  #l
> >
> > When executed the line would be logged (presumably to stdout) as
> something like:
> >
> > x=1 -> y=2 + z=3 -> 5
> >
> > In one log line you see the variables and their values, the operations
> being performed with them, and the result of the evaluated expression.
> >
> > Placing "#l" on a def Function() line would apply "#l" logging to every
> line in that function or method.
> >
> > That's it.  Adding these log requests would be easy and not clutter the
> code.  Removing them reliably would be a trivial global operation in any
> text editor.  The resulting debug information would be fully diagnostic.
> >
> > Of course there are lots of details and edge cases to consider.  There
> always are.  For example, what if x had not been previously defined?  A
> reasonable answer:
> >
> > x=. -> y=2 + z=3 -> 5
> >
> > In every case the solution should minimize volume of output while
> maximizing logged information.
> >
> > One can debate the precise formatting of the output.  The text used for
> the semantically meaningful comment string is open to debate.  The output
> pipe could be made controllable.  There are natural extensions to allow
> periodic and conditional logging.  I have ideas for reducing (already
> unlikely) collisions with existing comments.  But I want to keep this
> simple for now, and I think this captures the core of the idea.
> >
> > For your consideration.
> >
> > - larryy
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://eur02.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-
> ideas=02%7C01%7C%7C1833282b2db342f6476308d563825af0%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636524333870912999=
> K5Qd3iat2NG4h%2F1rgIf4C9FOmv8%2Fa%2FUN23I3jOiW0PU%3D=0
> > Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F=02%7C01%7C%
> 7C1833282b2db342f6476308d563825af0%7C84df9e7fe9f640afb435
> %7C1%7C0%7C636524333870912999=TcZ2QLkZ0rDntMEQvouNFFnzn7HBBB
> T64cb%2ByrdIDj8%3D=0
> >
>
> I thing that this idea has some merit, obviously with some details to be
> worked out as well.
>
> I would suggest, however, that if this feature is introduced it be
> controlled via a run-time switch &/or environment variable which
> defaults to off. Then rather than the developer having to do global
> replaces they simply turn off the switch (or reduce it to zero).
>
> It may also be preferable to use decorators rather than syntactically
> significant comments, (personally I don't like the latter having had too
> many bad experiences with them).
>
> --
> Steve (Gadget) Barnes
> Any opinions in this message are my personal opinions and 

Re: [Python-ideas] a sorting protocol dunder method?

[Chris Barker - NOAA Federal]

If by no brainer you mean the performance of __sort-key__ is always better
of __lt__


No. By no-brainer I meant that IF there is a __sort_key__ defined, then it
should be used for sorting, regardless of whether __lt__ is also defined.
(min and max should probably prefer  __lt__)

I will wask for a proof in the form of benchmarks with enough use-case
coverage.


Indeed — I was surprised that it helped so much, and didn’t seem to hurt
for the one example.

But the greater concern is that this will effect every sort (that doesn’t
provide a key function) so if there is any noticeable performance hit, that
probably kills the idea.

And the most risky example is lists of ints or floats — which are very fast
to compare. So adding a method lookup could be a big impact.

I’m not sure how to benchmark that without hacking the sorting C code
though.

I’d still love to know if my benchmark attempt was at all correct for
custom classes in any case.

-CHB





def outer_key(item):
return item.key()

so we get a function lookup each time it's used.

However, I'm confused by the results -- essentially NO Change. That extra
method lookup is coming essentially for free. And this example is using a
tuple as the key, so not the very cheapest possible to sort key.

Did I make a mistake? is that lookup somehow cached?

In [36]: run sort_key_test.py
1
key   0.012529s  1 calls
outer_key 0.012139s  1 calls
lt0.048057s 119877 calls

each run gives different results, but the lt method is always on order of
5X slower for this size list. Sometimes out_key is faster, mostly a bit
slower, than key.

Also, I tried making a "simpler" __lt__ method:

return (self.value1, self.value2) < (other.value1, other.value2)


but it was bit slower than the previous one -- interesting.


This is more expensive to execute then my version for 2 reasons.
1) my __lt__ did not need to create any tuples.
2) my __lt__ can exit after only looking at the value1's


Then I tried a simpler (but probably common) simple attribute sort:

def __lt__(self, other):
global lt_calls
lt_calls += 1

return self.value1 < other.value1

def key(self):
global key_calls
key_calls += 1

return self.value1

And that results in about a 6X speedup

In [42]: run sort_key_test.py
1
key   0.005157s  1 calls
outer_key 0.007000s  1 calls
lt0.041454s 119877 calls
time ratio: 5.922036784741144


And, interestingly (t me!) there is even a performance gain for only  a 10
item list! (1.5X or so, but still)


My guess is that this is because the __lt__ test on simple types is very
fast in python.

Barry


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

[Chris Barker - NOAA Federal]

It doesn't -- that's the point.

Currently it's assumed that the order base classes appear
in a class statement is the order that they must appear
in the MRO.


It’s not assumed — it’s how order is specified by the coder...

But that's not always true.


Isn’t it true by definition?

I'm suggesting that
the MRO algorithm should not assume that and should make
its own assessment of the required ordering.


Isn’t that impossible? It could determine that order doesn’t matter (no
name clashes), but when that’s the case, there’s nothing to do.

What am I missing?

-CHB


-- 
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Looking for input to help with the pip situation

[Chris Barker - NOAA Federal]

On Nov 13, 2017, at 1:53 PM, Paul Moore  wrote:

In principle, I agree with the ideas here, but there are some
practical issues that make them somewhat less straightforward than we
might like.


And practically beats principally ;-)

But yeah.


1) Add python2.exe and python3.exe files to the Windows installers


The only possible way we'd get a python2.exe is by adding it to future
releases of Python 2.7, and we shouldn't be recommending Python 2 for
new users anyway.


No, but it’s going to be in use for a while yet (2020, yes?).

And no, new users should not install py3, but new users may work in an org
that is using py2.

And I'm strongly -1 on promoting "python3.exe" as
the canonical way of getting Python 3.


So what is canonical? Not the py executable, for sure.

*maybe* we are at a point where we expect py3 to be the default on most
systems, but we DO need a way to tell people how to get py3 if:

Typing python gets them py2.

And it’s not an option to remove py2 or re-configure their systems to
change the default ( see your point below about Windows PATH priorities)

The python3 command is a result
of the Unix issues around switching to Python 3 as the default, and we
shouldn't perpetuate that approach on Windows, where it's unneeded.


But the exact same issues are there in windows (except the shebang line)
bit it’s pretty weird that py.exe respects “python3”, when there is no
python3.exe on the system...

And having multiple systems work the same way IS a laudable goal.

Having said that, I don't object to including versioned executables as
a convenience (if it is one). I just dislike promoting the use of them
via standard documentation.


Totally agree.

 1a) alternatively, we could add a "py" executable to the standard linux

builds, so there would be THAT one way to do it. But I think that's a "BAD

IDEA" --


I think that getting a "py" launcher on Unix is a lost cause at this
stage.


Fine — I never liked the idea :-)

Then "python2 -m pip install" would work everywhere (only with new

installations, but at least with newbies, that's a bit more likely ...)


No newcomer should *ever* be getting told to use "python2 -m pip
install". Maybe "python3 -m pip install",


Exactly — that was supposed to be an example. Both should work, but
probably:

Python -m pip install would be recommended, with “you can add 2 or 3 if it
doesn’t do the right thing.

 And of course not all Unix distributions come
with Python 3 installed


Exactly — which is why even newbies that install just python 3 end up with
both on their system.

(Mac OS being an obvious example, and I think
Nick mentioned CentOS and RHEL) so python3 won't work everywhere
either...


But it will give you an error, rather that python 2. That’s exactly what we
want!


2) Make adding to the PATH in Windows the default.

...

Unfortunately, adding Python to the *front* of PATH is not possible.


Well, darn. But we can still make it the default and it will sometimes
work. And all the more reason we need a “python3” executable.

There's also the problem that file associations (i.e., what does
double clicking on a .py/.pyw file do) don't follow the same rules, as
they go through the launcher.


I don’t see anything we can do with that. But I don’t recommend users use
that anyway.

The only really sensible "do what I expect" situation is a single
Python 3 installation on the user's machine.


Sure — but we can’t control that. All we can do is mitigate the damage.

For that case, adding
Python to PATH (it doesn't matter where as there's only one) is a
sensible option. The downside is that optimising for that case makes
the behaviour for other (more experienced) users worse. But it's not
unreasonable to make that trade-off.


Agreed. And not much worse.

3) Make --user be be automatic for pip install. Not actually the default,

but pip could do a user install if you don't have the permissions for a

non-user install.


The problem here is that the user scripts directory isn't on PATH.


How does that have anything to do with it? Either they can launch pip or
they can’t (the above are about that) this is about what should happen when
they do launch pip.


The various options here are under discussion on the pip tracker.


I’ll try to go there to comment.

 but there are
significant backward compatibility and behaviour change issues to
address first.


Always the challenge!

   python myscript.py
   pip install something_or_other

"just work" if the user previously had no Python on their PC.


And as many other configurations as possible :-)

I think the changes we should make should emphasize two things that perhaps
haven’t been given enough priority in the past:

1) things should work as much the same as possible across platforms.

2) making it easier for newbies is more important that for more experienced
folks.


It has a whole section at
https://docs.python.org/3/using/windows.html#python-launcher-for-windows.


What I can tell 

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

[Chris Barker - NOAA Federal]

But the point is that the compiler is recursive, and processing nested
constructs consumes the C stack. There are some guards against too deep
recursion (2.7 has less guards and more vulnerable), but it is hard to
prove that all vulnerabilities are fixed.

Your method (limiting the size of the input) helps against some attacks.
Other methods -- restricting the set of characters and the number of
parenthesis, braces and brackets.


Hmm — I’d never really thought about it, bust presumably ast.literal_eval
was designed for use in the compiler— or at least uses the compiler to do
its real work.

So maybe what we really need is a literal-eval that is DESIGNED to be a
safe Python literal parser.

Like a JSON parser but supporting the richer Python literal set.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Chris Barker - NOAA Federal]

> Nope.  I totally get that they don’t know what a shell or command prompt
> is.  THEY. NEED. TO. LEARN.  Hiding it is not a good idea for anyone.


I actually take this approach myself in my classes. However, I also have as
prerequisites for my classes:

Some Experience in some programming language

And

Basic familiarity with the command line.

I then let them use whatever dev. Environment they want, while supporting
and recommending a good editor and the command line.

However, If people want to learn python that don’t have those
prerequisites, then we suggest a different class designed for total newbies.

In THAT class,  we use a more proscribed dev environment so that everyone
is doing the same thing in the same way. It was IDLE, and has lately been
PyCharm.

And the intro to data analytics class uses Anaconda and the Jupyter
notebook.

My point?

We're not in the business of making judgements about who should and
shouldn't become Python programmers - we're in the business of making sure
that Python is accessible to as many people as possible by removing
irrelevant barriers to adoption,


Sure, but who is “we”? I think “we” is the python community, not the
cPython developers.

So providing an environment that makes it easy and obvious to install
packages is a great idea, but I think it’s the job of IDEs and other higher
level tools, not the REPL.

If we need to add a feature to Python itself to make it easier for IDEs and
the like to implement dynamic package adding, then by all means, let’s do
it.

Final note:

I DO see a lot of questions ( on mailing lists, etc) from folks that try to
type “pip install something” at the python command line.



whether that's translating documentation so folks can start learning with
instructions in their native language, or making it possible for them to
defer learning the idiosyncrasies of the Windows, Linux, and Mac OS X
command line environments.

On the latter front, the details of the development interfaces offered by
traditional desktop operating systems may *never* be relevant to the new
generation of folks coming through that are learning to program by
manipulating remote coding environments on tablets and other app-centric
devices, just as most developers nowadays are able to get by without even
learning C, let alone any flavour of assembly language. Our role in this
process isn't to create future generations that think and work in exactly
the same ways we do, it's to enable them to discover new ways of working
that build on top of whatever we create.

Jupyter notebooks are a decent example of this, where the difference
between a Python statement and a "command line statement" is just an
exclamation mark at the beginning of the line - exactly where the backing
environment lives is mostly a hidden implementation detail from the user's
perspective.

Eclipse Che and other online coding environments are another case - there,
the "command line" is a different window inside the editor app (this is
also going to be a familiar option for heavy IDE users on traditional
desktop operating systems).

And putting it in those terms makes me think that we should explicitly
exclude the default REPL from consideration here, as we've long taken the
position that that *isn't* a good teaching environment, and you certainly
can't access it remotely without some kind of other service in front of it
to manage the network connection (even if that service is just ssh).

That means I now see a few potential RFEs from this thread:

1. An import system feature that allows a running Python program to report
a timestamp (with the same granularity as pyc file timestamp headers) for
*when* the currently loaded modules were last modified. This could be as
simple as a new `__mtime__`  attribute in each module to store that number.
2. A new importlib.util API to check for potentially out of date modules in
sys.modules (those where a freshly calculated module mtime doesn't match
the stored __mtime__ attribute)
3. Support in IDLE for Jupyter-style "!" commands
4. Having IDLE call that importlib API and warn about any stale modules
after each command line operation

The first two features would be about enabling learning environments to
more easily detect when the currently loaded modules may not match what's
actually on disk (hot reloaders already do this by watching for filesystem
changes, but we're currently missing a simpler polling based alternative
that will also pick up package updates).

The second two would be about enhancing IDLE's capabilities in this area,
as we *do* suggest that as a reasonable initial learning environment, even
though there are also plenty of alternatives out there now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Chris Barker - NOAA Federal]

It's not 100% clear to me how my proposal below would work within a
> Jupyter Notebook, so that would also be an angle worth looking into.
>

I'm -1 on this as I view it as a tooling issue, not a language issue.


Agreed. And for the tool at hand, the notebook already controls the python
interpreter— it could have a “package installer” that you could run from
the notebook, but NOT with python code in the notebook.

If the Jupyter developers though it as a good idea.

I also wouldn't want to tie Python-the-language to pip-the-tool so tightly.


Exactly, I really wouldn’t want my students pip installing stuff from side
the REPL in the conda-based environment I’ve set up for them

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hexadecimal floating literals

[Chris Barker - NOAA Federal]

> And that's one of the reasons why the hexadecimal floating-point 
> representation exist:

I suspect no one here thinks  floathex representation is unimportant...

>
> To sum up:
> -  In some specific context, hexadecimal floating-point constants make it 
> easy for the programmers to reproduce the exact value. Typically, a software 
> engineer who is concerned about floating-point accuracy would prepare 
> hexadecimal floating-point constants for use in a program by generating them 
> with special software (e.g., Maple, Mathematica, Sage or some multi-precision 
> library). These hexadecimal literals have been added to C (since C99), Java, 
> Lua, Ruby, Perl (since v5.22), etc. for the same reasons.
> - The exact grammar has been fully documented in the IEEE-754-2008 norm 
> (section 5.12.13), and also in C99 (or C++17 and others)
> - Of course, hexadecimal floating-point can be manipulated with float.hex() 
> and float.fromhex(), *but* it works from strings, and the translation is done 
> at execution-time...

Right. But it addresses all of the points you make. The functionality
is there. Making a new literal will buy a slight improvement in
writability and performance.

Is that worth much in a dynamic language like python?

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality

[Chris Barker - NOAA Federal]

> You can define metrics. But as to what they mean? Well that is the question.

One big problem with metrics is that we tend to measure what we know
how to measure -- generally really not the most useful metric...

As for some kind of PEP or PEP-like document:

I think we'd have to see a draft before we have any idea as to whether
it's a useful document -- if some of the folks on this thread are
inspired -- start writing!

I, however, am skeptical because of two things:

1) most code-quality measures, processes, etc are not language
specific -- so don't really belong in a PEP

So why PEP 8? -- because the general quality metric is: " the source
code confirms to a consistent style" -- there is nothing language
specific about that. But we need to actually define that style for a
given project or organization -- hence PEP 8.

2) while you can probably get folks to agree on general guidelines--
tests are good! -- I think you'll get buried in bike shedding of the
details. And it will likely go beyond just the color of the bike shed.

Again -- what about PEP8? Plenty of bike shedding opportunities there.
But there was a need to reach consensus on SOMETHING-- we needed a
style guide for the standard lib. I'm not that's the case with other
"quality" metrics.

But go ahead and prove me wrong!

-CHB



>
> I was once told that you should measure a new metric for 2 years before you 
> attempting to use it to change your processes.
>
> Oh and what is the most important thing for a piece of work?
>
> I'd claim its the requirements. Get them wrong and nothing else matters.
>
> Oh and thank you for raising a very important topic.
>
> Barry
>
>
>>
>> @Jason, thanks for your example. When i discussed from this proposal with 
>> other devs of my team, they needed too example to have better idea of use. 
>> But i think, as wee need to avoid to talk about any tool name in the PEP, we 
>> need to avoid to give a code example. The aim of this proposal is to have a 
>> guideline on minimal metrics to have minimal quality. As you talked about, i 
>> ask to every devs of my team to respect the higher standard as possible. 
>> This, and the permanent request of my customers for the highest dev quality 
>> as possible, is the reason which explain this proposal.
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality

[Chris Barker - NOAA Federal]

> How do we handle different organizational requirements?
>
By keeping linting out of the code ( and certainly out of "official"
python), and in the organization's development process where it
belongs.

> @pylint([34])
> @pep([8,20])
> def f(a):
>   return math.sqrt(a)

Yeach! But that's just my opinion -- if you really like this idea, you
can certainly implement it in an external package. No need for a PEP
or anything of the sort.

> The other aspect that comes into code quality is unit tests. A decorator of 
> what test functions need to be run on a function (and pass) would also be 
> useful:
>
> def test_f_arg_negative(f):
>  try:
>return f(-1) == 1
>  except(e):
>return False# ValueError: math domain error
>
> @tests([test_f_arg_positive, test_f_arg_negative, test_f_arg_zero, 
> f_test_f_arg_int, test_f_arg_float])
> def f(a):
>   return math.sqrt(math.abs(a))

Again, I don't think it belongs there, but I do see your point. If you
like this idea--implement it, put it on PyPi, and see if anyone else
likes if as well.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

[Chris Barker - NOAA Federal]

a json-like format (pyson maybe ?).


I gonna pyson is a fine idea. But don't call it extended JSON ;-)

For me, the point would be to capture Python' s richer data types.

But would you need an OrderedDict?

As pointed out, in recent cPython ( and pypy) dicts are ordered by default,
but it's not part of the language spec)

And you can use ast.literal_eval as a pyson parser, so it's almost ready to
use :-)

-CHB


What do you think about ?

  Kind regards, Matteo.

--
  email:   nast...@alternativeoutput.it,   matteo.nast...@gmail.com
  web:   www.alternativeoutput.it   irc: #linux...@irc.freenode.net
 linkedin: http://lnkd.in/SPQG87
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] math.nextafter

[Chris Barker - NOAA Federal]

On Feb 24, 2017, at 10:28 AM, Mahmoud Hashemi  wrote:

By the way, it looks like math doesn't have machine epsilon either:
>
>
> https://en.wikipedia.org/wiki/Machine_epsilon
>
> Pretty sure machine epsilon is in the sys module's float_info object.


Ahh, thanks! I though I remembered it was somewhere.

Or are you saying it would be handy to alias sys.float_info.epsilon over to
the math module too?


That might be a good idea, yes. Particularly if other related functions are
added as being discussed.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Things that won't change (proposed PEP)

[Chris Barker - NOAA Federal]

> By saying that "these are things that will not change",

I agree -- these are not exactly " things that will not change" as they are:

"Things that have been discussed (often ad nausium) and considered and
definitively rejected"

And many of them are:

"Part of what makes Python Python"

I think some wordsmithing is in order to make that clear.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Settable defaulting to decimal instead of float

[Chris Barker - NOAA Federal]

While I think some variation of:

from __optional__ import decimal_literal

Might be reasonable, I'd probably rather see something like:

X = 1.1D

However: (thank you Chris and Stephen) --

Decimal is NOT a panacea, nor any more "accurate" than binary floating point.

It is still floating point, it is still imprecise, it still can't
represent all rational numbers, even within a range.

The ONLY advantage is that it gives people the warm and fuzzies
because they are used to being able to represent 1/10 exactly, while
not representing 1/3 exactly. But 1/10 is only special BECAUSE of
Decimal representation itself.

I actually think that the Decimal docs over-sell its usefulness.

For instance, it really isn't more suitable for money than binary
floating point if you round your outputs.

Decimal does provide variable precision, which does help. With a 64
bit float, you lose cent precision around a trillion dollars. But
that's a precision issue, not a binary vs Decimal issue. And a
float128 would work fine for more money than I'll ever have to deal
with!

If you really want to do money right, you should use a money type that
is exact and follows the appropriate accounting rules for rounding.
Probably fixed point.

(There are a couple money packages on pypi -- no idea if they are any good)

In short:

I'm wary of the idea that most people would be better off with
Decimal. It's really a special purpose type, and I think it's better
if the issues with floating point precision make themselves obvious
sooner than later.

-CHB

Sorry for the top-post -- I hate this phone email client

Sent from my iPhone

> On Jan 12, 2017, at 7:49 AM, Paul Moore  wrote:
>
>> On 12 January 2017 at 15:34, Victor Stinner  wrote:
>> 2017-01-12 13:13 GMT+01:00 Stephan Houben :
>>> Something like:
>>> from __syntax__ import decimal_literal
>>
>> IMHO you can already implement that with a third party library, see for 
>> example:
>> https://github.com/lihaoyi/macropy
>>
>> It also reminds me my PEP 511 which would open the gate for any kind
>> of Python preprocessor :-)
>> https://www.python.org/dev/peps/pep-0511/
>
> PEP 302 (import hooks) pretty much did that years ago :-) Just write
> your own processor to translate a new filetype into bytecode, and
> register it as an import hook. There was a web framework that did that
> for templates not long after PEP 302 got implemented (can't recall the
> name any more).
>
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] OS related file operations (copy, move, delete, rename...) should be placed into one module

[Chris Barker - NOAA Federal]

I agree that this has been a bit of a wart for a long time.

While the old “let’s treat strings as paths” modules are split up like you
said, pathlib can do what they do and more:
https://docs.python.org/3/library/pathlib.html


Exactly -- this is The Solution. It combines paths themselves with things
you are likely to do with paths.

It may well lack some nice features. If so, suggestions for that would be
the way to go.

The usefulness of pathlib has been hampered by the fact that path objects
couldn't be used in many stdlib functions. However, that has been remedied
in 3.6:


   - A new file system path protocol
    has been
   implemented to support path-like objects
   . All
   standard library functions operating on paths have been updated to work
   with the new protocol.

So we have a nice way forward.

-CHB




It’s also prettier and easier to use, especially when using autocompletion
(just type “path.is” and see what you can test the path for)

Best, Philipp

George Fischhof  schrieb am Do., 12. Jan. 2017 um
10:06 Uhr:

> Hi There,
>
> OS related file operations (copy, move, delete, rename...) should be
> placed into one module...
> As it quite confusing that they are in two moduls (os and shutil).
>
> I have read that one is higher level than other, but actually to use them
> I have to think which function can be found in which module.
>
> It is confuse for beginners, and makes the usage more complex instead of
> make it more simple (as Zen of Python says ;-) )
>
> An alias could good, not to cause incompatibility.
>
> Best regards,
> George
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How to respond to trolling

[Chris Barker - NOAA Federal]

 > the effect was dozens of messages with people falling over each
other trying to engage the OP,

Sure -- but all in one thread

> The respondents should have known better.

But we like to kibitz-- that's why (many of us) are on this list.

Anyway, all (most anyway) of the points brought up are :

A) not going to change
B) have been justified / explained in multiple blog posts, wiki pages,
and what have you.

So perhaps the best response would be:

"These are all fairly core Python design decisions -- do some googling
to find out why."

But it made me think that it would be good to have a single place that
addresses these kinds of thing to point people to.

There was the old "python warts" page, but this would be a "python
features page"

Maybe I'll start that if I find the roundtoits.

Or, if it already exists -- someone please point me to it.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Chris Barker - NOAA Federal]

 for range(1,1): means executing once to me.

The indexing/slicing approach was designed for indexing and slicing. Then
it made sense to have range() match. But range() is not part of the for
construction. It is a convenience function for providing an iterable of
integers. And you are welcome to write your own range-like iterable if you
want.

But if you want to look once, you'd use range(1), not range(1,2) anyway.
Clear as day.

And if you use: range(n, n+I), it is very clear that you will loop i times.

s[:n] + s[n:] == s// doesn't work. I don't think it should work though


Have you ever used a 1-based and closed-end indexing language that
supported slicing? I have (matlab), and these kinds of constructions are
really ugly and prone to error. It's not that you want to be able to divide
a sequence and immediately put it back together, it's that you often want
to do one thing with the first part of a sequence, and another with the
second part, and you don't want them to overlap.

len(s[:n]) == n   // works
len(s[:-n]) == n  // rather independent but would still work if
language is otherwise unchanged.
len(s[n:i]) == i - n  // doesn't work. Does it need to?


It's not that it HAS to - it's that it's much less likely that you will
make off by one errors if it does.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

[Chris Barker - NOAA Federal]

>> How common is this problem?
>
> Last 2 or 3 years, I don't recall having be bitten by such issue.

We just got bitten by this on our CI server. Granted, we could fix it
by properly configuring docker, but it would have been nice if it "
just worked"

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How we think about change [was: Reverse assignment operators...]

[Chris Barker - NOAA Federal]

> Because "+" and "+=" are operators which may be defined for any
> objects.  Paul explained *why* he chose to to do that elsewhere.  My
> point is that the semantics "a += b" *is* "type(a).__iadd__(a, b)" is
> true for all objects.

Well, yes. But it is defined in particular ways in the built in types
and the stdlib. And those ways are consistent-- I.e. They do the same
thing as __add__. And we REALLY wouldn't want it any other way.

But the __i*__ operators are a bit of a wart -- they mean different
things for mutable and immutable types.

This is because they were added to satisfy two use-cases:

Syntactic sugar for common and simple operations like incrementing an integer.

Compact syntax for in-place operations.

As numbers are immutable, you can't have in-place operations. Period.
So it was handy to use the same notation for both.

And I don't think anyone wanted to add TWO new sets of operators.

This dual use does cause confusion occasionally, but not that often in practice.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Easily remove characters from a string.

[Chris Barker - NOAA Federal]

> 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 replacements
> being supported.

Agreed -- there are a lot of edge cases to work out, and there is not
one way to define the API, but if folks think it's a good idea, we can
hash those out.

If anyone decides to take this on, be prepared for a lot of bike shedding!

-CHB


>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] More user-friendly version for string.translate()

[Chris Barker - NOAA Federal]

> Just a pair of usage cases which I was facing in my practice:

> So I just define a table like:
> {
> 1072: 97
> 1073: 98
> 1074: 99
> ...
> [which localizes Cyrillic into ASCII]
> ...
> 97:97
> 98:98
> 99:99
> ...
> [those chars that are OK, leave them]
> }
>
> Then I use os.walk() and os.rename() and voila! the file system
> regains it virginity
> in one simple script.

This sounds like a perfect use case for str.translate() as it is.

> 2. Say I have a multi-lingual file or whatever, I want to filter out
> some unwanted
> characters so I can do it similarly.

Filtering out is different-- but I would think that you would want
replace, rather than remove.

If you wanted names to all comply with a given encoding (ascii or
Latin-1, or...), then encoding/decoding (with error set to replace)
would do nicely.

-CHB


>
>
> Mikhail
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] More user-friendly version for string.translate()

[Chris Barker - NOAA Federal]

>>
> re.sub('[^0-9]', '', 'ab0c2m3g5')
>> '0235'
>>
>> Possibly because there's a lot of good Python builtins that allow you
>> to avoid the re module when *not* needed, it's easy to forget it in
>> the cases where it does pretty much exactly what you want,

There is a LOT of overhead to figuring out how to use the re module.
I've always though t it had it's place, but it sure seems like
overkill for something this seemingly simple.

If (a big if) removing "all but these" was a common use case, it would
be nice to have a way to do it with string methods.

This is a classic case of:

Put it on PyPi, and see how much interest it garners.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/