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 tr

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&R(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/