[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

2022-07-16 Thread Stephen J. Turnbull 
Samuel Colvin writes:

 > Overall, I agree we should be using ISO8601 for exactly this reason (at
 > least for dates, for datetimes ISO8601 gets pretty wacky
 > )

I have never had a use for anything but -mm-ddThh:mm:ss (and very
occasionally -mm-ddZhh:mm:ss for international coordination).
What's wacky about that?  It's not terribly human-readable, but for
humans you can substitute a space for T (Z) and append a timezone or
offset if you want to disambiguate.

Sure, there is lots of optional syntax in ISO 8601, but when does one
need the wacky stuff in a release announcement?

Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IJXHA6YZVHKVTYTI2SO3OG7HUYVGASIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

2022-07-16 Thread Stephen J. Turnbull 
Paul Ganssle writes:

 > If you didn't already know what the square brackets did, how would
 > you try and find out?

First I'd look it up in Python Essential Reference (Hi, @dabeaz! it
won't be there, though ;-).  Then I'd go to the Language Reference for
"def" and "class".  And if that failed, then I'd go buy Barry Warsaw
lunch.

OK, not everybody has a personal relationship with senior core devs,
but is asking people to read the Language Reference really so bad?

 > An additional benefit is that I find some of these examples to be a bit 
 > visually cluttered with all the syntax:
 > 
 > def  func1[T](a:  T)  ->  T:  ...   # OK
 > class ClassA[S, T](Protocol): ... # OK

Looks like the boomer version (square*) of C++ template variables.  Of
course, people learn Python to escape from C++, so maybe that's not
persuasive.

* telling you how old I am without telling you how old I am

 > Which would look less cluttered with a prefix clause:
 > 
 > @with type T def  func1(a:  T)  ->  T:  ...   # OK
 > @with type S @with type T class ClassA(Protocol): ... # OK

For me, that's absolutely awful from a readability standpoint.  Put
the "def" or "class" 10-20 characters in from the margin?

I guess "stacked" it's no less readable than any decorator, but I also
don't like overloading the well-defined decorator notation with magic.

@with type T
def  func1(a:  T)  ->  T:  ...   # OK

@with type S
@with type T
class ClassA(Protocol): ... # OK

A thought: would it be possible to actually make it a with statement?

with Typevar() as T:
def func1(a: T) -> T

Of course there might have to be magic in Typevar, but it would be far
more palatable to me than giving unary @ two kinds of magic.

IMO YMMV of course.

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UTVCFIZ4CM3362JANAOBPEGJUTAWKSCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

2022-07-16 Thread Stefan Behnel 

Petr Viktorin schrieb am 15.07.22 um 13:18:
The discuss.python.org experiment has been going on for quite a while, and 
while the platform is not without its issues, we consider it a success. The 
Core Development category is busier than python-dev. According to staff, 
discuss.python.org is much easier to moderate.. If you're following 
python-dev but not discuss.python.org, you're missing out.


That's one of the reasons then why I pretty much lost track of the CPython 
development since d.p.o was introduced. It's sad, but it was just too much 
work for me (compared to threaded Newsgroups) to follow the discussions 
there, definitely more than I wanted to invest.


It's not the only reason, though, so please take a decision for the home of 
CPython discussions that suits the (currently) more active part of the 
development community.


Stefan

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TA5YNMEJURKMJHTSYTM5Z6G2YQ6UM5TP/
Code of Conduct: http://python.org/psf/codeofconduct/