r and coroutine objects can't take
> attributes. Maybe I should ask for that feature instead.
>
> Either feature would allow the concept of a coroutine that is also a thunk.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/l
t;
> <https://www.python.org/dev/peps/pep-0526/>
> [3] Not having to specify values for enums.
> <https://www.python.org/dev/peps/pep-0435/#not-having-to-specify-values-for-enums>
>
> ___
> Python-ideas mailing list
> Pyth
On Tue, Nov 28, 2017 at 12:17 PM, Serhiy Storchaka
wrote:
> 28.11.17 21:45, Guido van Rossum пише:
>
>> These look like good improvements. I think you should make an issue on
>> bugs.python.org <http://bugs.python.org> describing your proposal and if
>> you can
to print FATAL
is surely going to break some people's log parsers. :-(
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
other way around, making critical an alias for
fatal, and switching them around in the docs? No code will be invalidated
but it will encourage people to use the simpler, more direct term.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing
s at once. Basically if you think you'll need to wait for Python 4 to
get your favorite change to the language, you can forget it. You need to
come up with a plan to introduce the change without breaking existing code
or at least a clear deprecation schedule.
--
--Guido v
names (debug, info) so extra length results in wasted
> space that is very rarely needed.
>
> Hopefully someone else finds these useful. Neither depends on the other.
>
> -Mike
> ___
> Python-ideas mailing list
> Python-id
On Mon, Nov 27, 2017 at 1:32 PM, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 8:24 AM, Guido van Rossum
> wrote:
> > On Mon, Nov 27, 2017 at 1:18 PM, Greg Ewing >
> > wrote:
> >>
> >> Chris Angelico wrote:
> >>>
> >&g
mething to itertools to make it more readable rather than going
straight to new syntax?)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
to rhyme with the use of a lone
'*' in function signatures, it would actually mean the opposite: in
signatures it means "don't allow any more". These opposite meanings would
cause some confusion.
--
--Guido van Rossum (python.org/~guido)
___
ing
change. And how do you influence people? Not by opening with an insult.
(Also if you think that none of this matters because we're all rational
actors, grow up. :-)
--Guido
On Mon, Nov 27, 2017 at 12:17 PM, Brett Cannon wrote:
>
>
> On Tue, 21 Nov 2017 at 14:57 Nick Timkovich
&
for emoticons as a separators?
>>
>
> Yes, if someone insisted that emoticons were superior to underscores as
> separators and implied I was an idiot for not agreeing with that.
>
> --- Bruce
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
ill be technical problems
>> with supporting this, but are there any benefits?
>>
>>
>> https://perldoc.perl.org/perlre.html
>> https://www.unicode.org/reports/tr31/tr31-4.html#Pattern_Syntax
>> https://unicode.org/L2/L2005/05012r-pattern.html
>>
>> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
unctions are picklable. Maybe
a discussion of how to make deprecated functions picklable could be in an
Appendix? And another example of how to implement more functional lazy
loading. Or even more complete examples could be maintained as a separate
GitHub repo (like Ethan did for PEP 561).
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Nov 10, 2017 at 8:54 AM, Ivan Levkivskyi
wrote:
> On 10 November 2017 at 17:43, Guido van Rossum wrote:
>
>> There seem to be some action items from this thread that I haven't seen
>> reflected in the PEP source code yet.
>> [...snip...]
>> Then the
_dir__
> > method to check if __all__ is defined and use it to generate the
> > result if it exists. This seems like a logical enhancement to me,
> > and I'm planning on writing a patch to implement this. Whether it
> > would be accepted is still an open issue though
e that it will speed up "import typing" a lot
then that would be a powerful argument for the PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Nov 7, 2017 at 6:26 PM, Steven D'Aprano wrote:
> On Tue, Nov 07, 2017 at 01:53:00PM -0800, Guido van Rossum wrote:
> > On Tue, Nov 7, 2017 at 2:29 AM, אלעזר wrote:
> >
> > > The dangers of eval and exec are obvious and well known to advanced
> users,
>
On Mon, Nov 6, 2017 at 5:27 PM, Barry Warsaw wrote:
>
> Guido van Rossum wrote:
>
> > This is beginning to sound like the most attractive solution. We could
> > possibly do away with typing_extensions. Are there precedents of how to
> > bundle a module in this way? O
found using grep, unlike
some other unsafe patterns.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Nov 6, 2017 at 10:36 PM, Stéfane Fermigier wrote:
>
>
> On Tue, Nov 7, 2017 at 2:58 AM, Guido van Rossum wrote:
>
>> On Mon, Nov 6, 2017 at 2:34 AM, Stéfane Fermigier
>> wrote:
>>
>>> 4) 10 years ago, when I was working on the EDOS project (
&
I call YAGNI on everything in this thread.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
e BeOpen adventure and GPL-compatibility.
>
> Cheers,
> -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/
>
--
--Gu
sm in Python Programs", by Beatrice
Akerblom and Tobias Wrigstad:
> https://people.dsv.su.se/~beatrice/python/dls15_large_images.pdf
<https://people.dsv.su.se/~beatrice/python/dls15_large_images.pdf>
<https://people.dsv.su.se/~beatrice/python/dls15_large_images.pdf>
Thanks for the link!
--
und like the most attractive solution. We could
possibly do away with typing_extensions. Are there precedents of how to
bundle a module in this way? Or is it going to be another special case like
pip?
--
--Guido van Rossum (python.org/~guido)
___
Python-i
On Fri, Nov 3, 2017 at 7:45 AM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 1:35 AM, Guido van Rossum wrote:
> > [A copy from https://github.com/python/typing/issues/495 to get more
> > people's attention to this issue.]
> >
> > I'm wondering if we should
r, at the cost of an extra pip install (but they'll need
one anyway for mypy).
Thoughts?
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Cod
ib -- they have their own cert store).
On Wed, Nov 1, 2017 at 7:36 PM, Nathaniel Smith wrote:
> On Wed, Nov 1, 2017 at 7:41 AM, Guido van Rossum wrote:
> > Can you write 1-2 paragraphs with the argument for each?
> >
> > On Tue, Oct 31, 2017 at 10:01 PM, Nathaniel S
Can you write 1-2 paragraphs with the argument for each?
On Tue, Oct 31, 2017 at 10:01 PM, Nathaniel Smith wrote:
> On Oct 31, 2017 4:42 AM, "Nick Coghlan" wrote:
>
> On 31 October 2017 at 02:29, Guido van Rossum wrote:
>
>> What's your proposed process to
On Tue, Oct 31, 2017 at 12:24 PM, MRAB wrote:
> On 2017-10-31 18:44, Guido van Rossum wrote:
>
>> On Tue, Oct 31, 2017 at 11:41 AM, MRAB > <mailto:pyt...@mrabarnett.plus.com>> wrote:
>>
>> regex gets updated when the Unicode Consortium releases an update
reated as features (or perhaps as bugfixes, I'm not
sure) but this means they generally don't get backported.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listi
OK, go ahead and write the PEP! I'm actually happy with the responses you
gave, so your last email will make a good start for some of the contents of
the PEP.
On Tue, Oct 31, 2017 at 9:19 AM, Nick Coghlan wrote:
> On 1 November 2017 at 00:53, Guido van Rossum wrote:
>
>> On
On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan wrote:
> On 31 October 2017 at 02:29, Guido van Rossum wrote:
>
>> What's your proposed process to arrive at the list of recommended
>> packages?
>>
>
> I'm thinking it makes the most sense to treat inclusion
Juancarlo Añez wrote:
>
>
> On Mon, Oct 30, 2017 at 12:29 PM, Guido van Rossum
> wrote:
>
>> What's your proposed process to arrive at the list of recommended
>> packages? And is it really just going to be a list of names, or is there
>> going to be some doc
weird Python
> idiosyncracy.
>
> Python IO such as open commits changes automatically, so I'm not sure why
> IMAP4 doesn't and only logs out.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python
wrote:
> On 31 October 2017 at 00:28, Guido van Rossum wrote:
>
>> I just feel that when you're talking about an org like PayPal they can
>> take care of themselves and don't need our help. They will likely have
>> packages they want installed everywhere that wou
t;
> The initial post on the above link summarizes the suggested implementation
> pretty well.
>
> --
> Regards,
> Ivan
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/lis
ime (yours,
too).
On Sun, Oct 29, 2017 at 10:24 PM, Nick Coghlan wrote:
> On 30 October 2017 at 04:56, Guido van Rossum wrote:
>
>> The two use cases you describe (scripters and teachers) leave me
>> luke-warm -- scripters live in the wild west and can just pip install
>>
e-packages.
I would really like to see what you'd add to the list besides requests -- I
really don't see why the teaching use case would need the regex module
(unless it's a class in regular expressions).
--Guido
On Sun, Oct 29, 2017 at 12:54 AM, Nick Coghlan wrote:
> On 29 O
he standard library plus
> independently versioned recommended packages.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
>
rhaps there is a good reason for not doing so?
>
> Best Regards,
> Ilya Kulakov
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://py
sily*
> implement your API on top of the PEP 564. You will be limited to
> nanosecond resolution, but in practice, all clocks are already limited
> to this resolution through operating system APIs:
> https://www.python.org/dev/peps/pep-0564/#sub-nanosecond-resolution
>
> Victor
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
16, 2017 at 2:44 AM, Guido van Rossum
> wrote:
>
>> Sorry, that's an in-joke. Koos is expressing his disappointment in the
>> rejection of PEP 555 in a way that's only obvious if you're Dutch.
>>
>>
> Hmm, or more accurately, it has to do with me goin
eration time
> representation (where the first gen is seconds as a 64 bit binary float and
> the second gen is nanoseconds as a 64 bit integer).
>
I hope we'll never see time_ns() and friends as the second generation --
it's a hack that hopefully we can retire in those glorious days
On Sun, Oct 15, 2017 at 6:58 PM, Guido van Rossum
> wrote:
> >
> > > I'd like to have time.time_ns() -- this is most parallel to
> st_mtime_ns.
> > >
> > >
> > Welcome to the list Guido! You sound like a C programmer. For many
> people,
> >
. And then
somehow we got hung up about fixing the problem in the example.
I want to back out of this entirely, because the problem (while it can be
demonstrated) is entirely theoretical, and the proposed solution is made
too complicated by attempting to solve the problem for generators as well
_
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas
some kind of
copy-on-write implementation, and switching out the current context should
be fast.) I also don't want to obsess over API abstraction. Finally I don't
want the design to be closely tied to `with`.
Maybe I need to write my own PEP?
--
--Guido van Rossum (python.org/~gui
for submission
> to an event loop, not the one that's active when they're created.
>
This caught my eye as wrong. Considering that asyncio's tasks (as well as
curio's and trio's) *are* native coroutines, we want complete isolation
between the context active
On Tue, Oct 10, 2017 at 5:34 AM, Nick Coghlan wrote:
> On 10 October 2017 at 01:24, Guido van Rossum wrote:
>
>> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote:
>>
>>> On 8 October 2017 at 08:40, Koos Zevenhoven wrote:
>>>
>>>> I do reme
is the_value
>>>
>>> with cvar.assign(the_value):
>>> gen = genfunc()
>>>
>>> next(gen)
>>>
>>> with cvar.assign(1234567890):
>>> try:
>>> next(gen)
>>> except StopIteration:
>>>
ss of whether we introduce this feature, .hex() is the way to
show what's going on here:
>>> 0.1.hex()
'0x1.ap-4'
>>> 0.2.hex()
'0x1.ap-3'
>>> 0.3.hex()
'0x1.3p-2'
>>> (0.1+0.2).hex()
16
> representation saves them all their approximation issues and their need
> still to use isclose() or friends.
>
Show them 1/49*49, and explain why for i < 49, (1/i)*i equals 1 (lucky
rounding).
--
--Guido van Rossum (python.org/~guido)
___
P
nto the
language -- just because something is a function doesn't mean it's an
expert operation.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
st vectors are
> going to use binary or hex representations, not decimal).
>
> 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/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
f a module does not have __all__ defined, then nothing changes for that
> module.
>
> Cody
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://py
Tue, Sep 12, 2017 at 9:30 PM, Guido van Rossum
> wrote:
> > I find this a disturbing trend.
>
> Which trend? Moving away from "consenting adults"? In the case of
> sys.modules, the problem is that assigning a bogus value (e.g. []) can
> cause the interpreter to
oint there's no way I am going
to read all the discussions.
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-i
about that everything's
easy.)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
sbane, 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/
>
--
--Guido van Rossum (python.org/~guido)
_
s()). And they
may already have to support that in order to support PEP 484's forward
references. Though perhaps there's a reason why such libraries currently
don't need to handle forward refs?
--
--Guido van Rossum (python.org/~guido)
___
all__ submodules are imported.
> INADA Naoki
>
>
> On Mon, Sep 11, 2017 at 12:17 PM, Guido van Rossum
> wrote:
> > I don't think submodules are automatically imported, unless there are
> import
> > statements in __init__.py.
> >
> > On Sun, Sep 10,
_
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python
rs, I kind of like the idea of support
> float.hex() here.
>
> Do we need a short PEP, since it changes the Python grammar? It may be
> nice to describe the exact grammar for float literals.
>
Yes, this needs a PEP.
--
--Guido van Rossum (python.org/~guido)
___
d"
> 5000 loops, best of 5: 81.1 usec per loop
>
> I'd like to write a patch if this idea will be accepted.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org
s://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
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/
>
--
--Guido van Rossum (python.org/~guido)
___
a separate API -- whoever needs it can just write their own.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
ially the same: [1]
>
> Another advantage, is that ContextKey implements a better caching,
> because it can have only one value cached in it, see [2] for details.
>
> [1] https://www.python.org/dev/peps/pep-0550/#new-apis
> [2] https://www.python.org/dev/peps/pep-0550/#contex
For security reasons. AFAIK HTTPS wasn't even invented at the time.
On Wed, Aug 23, 2017 at 11:44 AM, John Torakis
wrote:
>
>
> On 23/08/2017 21:41, Guido van Rossum wrote:
>
> This isn't ever going to be a standard feature. It's available as a
> third-party
this up at or around the first Python workshop at NIST in 1995
-- I was his guest at NIST for several months at the time.)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman
False
log_state = LogState()
(I think that for calls that construct empty instances of various types we
should just use the class name rather than some factory function. I also
think none of this should live in sys but that's separate.)
--
--Guido van Rossum (python.org/~guido)
___
>
> +1 confused :/
>
> --
> ~Ethan~
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
_
as and other
>> definitions (e.g. OpenAPI) automatically and without duplication.
>>
>> The proposed solutions are definitely not perfect and not the main point
>> of this email. The target is to describe the idea and motivation and start
>> a discussion.
>>
ds on
motivation and not enough on crisply explaining how the proposed feature
works (what state is stored where how it's accessed, and how it's
manipulated behind the scenes).
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing li
Thanks for the explanation. Can you make sure this is explained in the PEP?
On Aug 11, 2017 10:43 PM, "Yury Selivanov" wrote:
> > On Fri, Aug 11, 2017 at 10:17 PM, Guido van Rossum
> wrote:
> > > I may have missed this (I've just skimmed the doc), but what&#
I may have missed this (I've just skimmed the doc), but what's the
rationale for making the EC an *immutable* mapping? It's impressive that
you managed to create a faster immutable dict, but why does the use case
need one?
--
--Guido van Rossum (py
at the language design level.
>
I haven't come around to this yet. It looks like it will make explaining
comprehensions more complex, since the translation of "while X" into "if
not X: break" feels less direct than the translations of "for x in xs" or
"if
e the same
chaos.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
ng that spec, I think there's something missing: given a list (or
tuple!) of values, how do you turn it into an 'ntuple'? That seems a common
use case, e.g. when taking database results like row_factory in sqlite3.
--
--Guido van Rossum (python.org/~guido)
__
ain benefit of using a metaclass would be that
> it enables using normal class declaration syntax to define a
> namedtuple. That's not just an implementation detail!
Newer versions of the typing module do this:
https://docs.python.org/3/library/typing.html#typing.NamedTuple (and indeed
have a
metaclass conflict. If the namedtuple had no metaclass this would not be a
conflict. (This is one reason to love class decorators.)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.p
On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow
wrote:
> On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote:
> > Guido has decreed that namedtuple shall be reimplemented with speed in
> mind.
>
> FWIW, I'm sure that any changes to namedtuple will be kept as minimal
> as p
te:
>> >> the idea is to write it into a PEP and consider API/corner
>> >> cases/implementation/etc.
>> >
>> > Who's writing it?
>>
>> Guido, Hynek, and I met today. I'm writing up our notes, and hopefully
>> that will eventua
would Python be like if this idea were implemented" even if we
> never get very far with "how would we implement this idea in Python". And
> I would find it unfortunate if discussion of the former were prematurely
> restricted by worries about the latter.
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is no
> path, and leave a trail."
>--author unknown
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
on't know exactly.
>
> Victor
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Ros
at 8:33 PM, Nick Coghlan wrote:
> On 5 June 2017 at 07:00, Guido van Rossum wrote:
> > AFAK it was in whatever PEP introduced Unicode identifiers.
>
> Ah, indeed it is: https://www.python.org/dev/peps/pep-3131/#policy-
> specification
>
> Interestingly, that's strict
tement "import socket" and actually get the
> standard library's socket module as it expected - the developer of
> such a script would have to write "from . import socket" in order to
> reimport the main script as a module.
>
> Cheers,
> Nick.
&g
AFAK it was in whatever PEP introduced Unicode identifiers.
On Jun 3, 2017 11:24 PM, "Nick Coghlan" wrote:
> On 4 June 2017 at 05:02, Dan Sommers wrote:
> > On Sat, 03 Jun 2017 17:45:43 +, Brett Cannon wrote:
> >
> >> On Fri, 2 Jun 2017 at 15:56 Guido van
OK, I think this discussion is pretty much dead then. We definitely
shouldn't allow math operators in identifiers, otherwise in Python 4 or 5
we couldn't introduce them as operators.
On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano wrote:
> On Fri, Jun 02, 2017 at 04:29:16P
Are those characters not considered Unicode letters? Maybe we could add
their category to the allowed set?
On Jun 2, 2017 4:02 PM, "Ivan Levkivskyi" wrote:
> On 3 June 2017 at 00:55, Guido van Rossum wrote:
>
>> [...]
>> So, I am still in favor of the ru
ny expressions more similar to usual TeX,
> plus it will be useful for projects like SymPy.
>
> --
> Ivan
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-id
I think it's silliness and I don't even know how to type those characters.
On May 31, 2017 11:49 PM, "Serhiy Storchaka" wrote:
> What you are think about adding Unicode aliases for some mathematic names
> in the math module? ;-)
>
> math.π = math.pi
> math.τ = math.tau
> math.Γ = math.gamma
> ma
ng alternative to the current practices of
> emulating them with threads or coroutines pretty much requires the
> property of zero-copy ownership transfer.
>
But subinterpreters (which have independent sys.modules dicts) seem a poor
match for that. It feels as if you're speculatin
> interpreters.Interpreter.is_running()
> interpreters.Interpreter.destroy()
> interpreters.Interpreter.run(code)
> _______
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
ecause b) and d) change semantics and so it's not a
> small thing to make this change at this point since Python 3.6 has been
> released. So unless there's a major performance impact I'm reluctant to
> want to change it at this point.
>
> ____
ttrib = callable (myattrib)
>
> Stephan
>
> Op 19 mei 2017 20:25 schreef "Guido van Rossum" :
>
> For people who don't want to click on links:
>>
>> 1. Allow hash and equality to be based on object identity, rather than
>> structural identity,
>>
ilman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
’t thought much about this, except about if there’s indeed a need
> (and there is), but I can’t know if the solution if through decorators, or
> inheritance.
>
I suppose we could do it using either a class decorator or a metaclass --
we'll have to compare the pros and cons and
>
> On Tue, May 16, 2017 at 10:10 PM, Guido van Rossum
> wrote:
>
>> It's "class variable" because we (at least I) also routinely use
>> "instance variable".
>
>
> It is `getattr()`, `setattr()`, and a very long etc. in Python.
>
>
701 - 800 of 912 matches
Mail list logo
