Well the whole point is not to have to figure out how to implement that
right now.
On Wed, Oct 21, 2015 at 6:45 PM, Random832 wrote:
> Guido van Rossum writes:
> > The proposal is to allow this to be written as follows in
> > implementation (non-stub) modules:
> >
&g
On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>
>
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum wrote:
>
>> Well the whole point is not to have to figure out how to implement that
>> right now.
>>
>> On Wed, Oct 21, 2015 at 6:45 PM, Random83
On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan wrote:
> On 22 October 2015 at 19:51, Guido van Rossum wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith
> wrote:
> >> What would it Foo.__getitem__.__annotations__ contain in this situation?
> >> It'
s makes it much more tractable.
On Thu, Oct 22, 2015 at 10:51 AM, Guido van Rossum wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>
>>
>>
>> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum
>> wrote:
>>
>>> Well the whole point is not to h
nd imperative prefix, but is currently deferred until 3.7 at
>> the earliest (after we have a release worth's of experience with "f").
>>
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Pytho
Let me just unilaterally end this discussion. It's fine to disregard
the future possibility of using UTF-16 or -32 for Python source code.
Serhiy can happily rip out any comments or dead code dealing with that
possibility.
--
--Guido van Rossum (python.org/~
;
>
> def _get_https_context_factory():
> # Check for am environmental override of the default behaviour
> config_setting = os.environ.get(_https_verify_envvar)
> if config_setting is not None:
> if config_setting == '0':
>
ernal decision process (if it's a process -- sounds more
like an accident :-).
So, Alex, do you want to approve this PEP?
On Mon, Nov 16, 2015 at 3:54 PM, Nick Coghlan wrote:
> On 17 November 2015 at 09:07, Guido van Rossum wrote:
>> So I dropped the ball on this too -- I was goi
v@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https:/
ing in the full source code before compiling it
> sounds like a reasonable approach.
>
> We use the same simplification in eGenix PyRun's emulation of
> the Python command line interface and it has so far not
> caused any problems.
Curious how you do it? I'd actually be quite
OK, but what are you going to do about the interactive REPL?
On Tue, Nov 17, 2015 at 7:40 AM, Serhiy Storchaka wrote:
> On 17.11.15 05:00, Guido van Rossum wrote:
>>
>> If you free the memory used for the source buffer before starting code
>> generation you should be good.
running it with command line can have
> different behaviours in corner cases.
I'm confused. *Of course* these two behaviors differ, since Python
uses a different __name__. Not sure how this relates to the REPL.
--
--Guido van Rossum (python.org/~guido)
_
Oh, cool! Sorry for the disturbance.
On Tue, Nov 17, 2015 at 8:27 AM, Serhiy Storchaka wrote:
> On 17.11.15 18:06, Guido van Rossum wrote:
>>
>> OK, but what are you going to do about the interactive REPL?
>
>
> Nothing (except some simplification). This is a sep
Aha, so the only code path that's being replaced is the code that
reads the script file when invoking "python FILE" or "python wrote:
> On 18 November 2015 at 02:50, Guido van Rossum wrote:
>> On Tue, Nov 17, 2015 at 8:20 AM, Serhiy Storchaka
>> wrote:
&
s in the wild I'm going to speculate that you just made this up
based on the shell analogy (which isn't perfect).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Thu, Nov 19, 2015 at 1:47 AM, M.-A. Lemburg wrote:
> On 17.11.2015 16:22, Guido van Rossum wrote:
>> On Tue, Nov 17, 2015 at 1:59 AM, M.-A. Lemburg wrote:
>>>> [moving from read source line by line to reading all in one go]
>>> We use the same simplification
On Thu, Nov 19, 2015 at 3:51 AM, Serhiy Storchaka wrote:
> On 17.11.15 18:50, Guido van Rossum wrote:
>>
>> On Tue, Nov 17, 2015 at 8:20 AM, Serhiy Storchaka
>> wrote:
>>>
>>> Current implementation of import system went the same way. As a result
>>&
t non-ASCII file
> encodings.
>
> ChrisA
>
> [1] http://ftp.waf.io/pub/release/waf-1.7.16
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Pyt
#x27;ve learned our lesson (though we're in much
better shape than Perl :-).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mai
On Wed, Dec 2, 2015 at 8:57 AM, Barry Warsaw wrote:
> On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote:
>
> >I wholeheartedly agree with what Nick writes there
>
> As do I.
>
> One interesting point will be what *nix calls the /usr/bin thingie for
> Python
> 4
not completely an
> invented term.
>
> But that's not to say it's particularly obvious in this context...
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/pytho
On 12/4/2015 11:39 AM, MRAB wrote:
On 2015-12-04 19:22, Isaac Morland wrote:
On Fri, 4 Dec 2015, MRAB wrote:
> Constant folding is when, say, "1 + 2" replaced by "2".
Isn't that called backspacing? ;-)
Oops! I meant "1 + 1", of course. Or "3". Either would work. :-)
Oh, you must surely ha
It doesn't appear that the Awaitable class in Python
> has a `result` or `exception` field but `asyncio.Future` does.
>
> Would it make sense to shift from having `await` functions return a `
> *Future-like`* return object to returning a Future?
>
> Thanks,
> Roy
>
Agreed. (But let's hear from the OP first.)
On Tue, Dec 15, 2015 at 12:27 PM, Andrew Svetlov
wrote:
> Both Yury's suggestions sounds reasonable.
>
> On Tue, Dec 15, 2015 at 10:24 PM, Yury Selivanov
> wrote:
> > Hi Roy and Guido,
> >
> > On 20
e against the spirit of
> async/await.
>
Why would that be against the spirit? It's the only thing that will work
the way you're asking, and there is in fact already a function that does
this (asyncio.ensure_future()).
> Thanks,
> Roy
>
> On Tue, Dec 15, 2015 at 12
he same often don't behave the
same (e.g. variables in Python are entirely different beasts than in C#,
and also behave quite differently from variables in JavaScript). Also, if
you aren't giving up on changing Python, please move to python-ideas, which
is the designated place to discuss
with the Package Index
> <http://docs.python.org/dev/packaging/packageindex.html> [27] for
> details."
>
> but the provided link is broken (error 404).
>
> In the source file
> <https://hg.python.org/peps/file/52767ab7e140/pep-0423.txt> written
> by Guido v
er()`, otherwise it should get whatever is returned by
> `__aenter__` as a single argument. The returned Task object should also
> provide a reference to that object.
>
> Best regards,
> Ádám
>
> (http://szieberthadam.github.io/)
> _
too :)
>
This particular repo is managed by the "PEP editors":
https://www.python.org/dev/peps/pep-0001/#id29
In this case I've just pushed the fix. Thanks for reporting it!
--Guido
> Thanks,
> Tim
>
> 2015-12-18 17:41 GMT+01:00 Guido van Rossum :
>
>> Whi
ght one. However, I would like to
> signal that it would be nice to help developers with useful patterns and
> documentation to avoid RuntimeErrors and the frustration that goes with
> them.
>
Maybe you can help by submitting a patch that prevents this error! Are you
interested
29 AM, Glenn Linderman
wrote:
> On 12/18/2015 10:36 AM, Guido van Rossum wrote:
>
> I was opted to the signal module because `signal` documentation suggest
>> that
>> it alos supports Windows while asyncio documentation states that `loop.
>> add_signal_handler()` is UNIX o
On Fri, Dec 18, 2015 at 12:45 PM, Andrew Barnert wrote:
> On Dec 18, 2015, at 10:36, Guido van Rossum wrote:
>
> On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám
> wrote:
>
>> Thanks for your reply Guido!
>>
>> > - In theory, instead of waiting for a Future
Using an Event is slightly better because you just wait for it -- you don't
have to catch an exception. It's just not one of the better-known parts of
asyncio.
On Fri, Dec 18, 2015 at 1:42 PM, Andrew Barnert wrote:
> On Friday, December 18, 2015 1:09 PM, Guido van Rossum
>
Maybe we need to find a S.E.O. expert. I betcha some are lurking on this
list.
On Sat, Dec 19, 2015 at 2:55 AM, Nick Coghlan wrote:
> On 19 December 2015 at 03:44, Guido van Rossum wrote:
> > On Fri, Dec 18, 2015 at 9:34 AM, Tim Legrand >
> > wrote:
> >>
&
python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sat, Dec 19, 2015 at 1:40 PM, Matthias Urlichs
wrote:
> On 19.12.2015 20:25, Guido van Rossum wrote:
> > Perhaps you can add a check for a simple boolean 'stop' flag to your
> > condition check, and when you want to stop the loop you set that flag
> > and then
On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote:
> On Mon, Dec 21, 2015 at 9:02 AM, Alexander Belopolsky
> wrote:
> > On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum
> wrote:
> >>>
> >>>
> >>> It's 11 days. Which is pretty reaso
doesn't hurt asking around -- who knows what someone reading
this remembers (besides asking pedantic questions :-).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
such invariant for days -- they hold the sign bit.)
In essence, you'd have to look at all three attributes to figure out on
which side of 0 is was (or think of the right way to do it, which is to
compare to timedelta(0)). I might still go for it, if it wasn't too late by
over a decade (as Tim
On Sun, Dec 20, 2015 at 7:25 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum
> wrote:
>
>> but I would really like to see a change in the repr of negative
>>> timedeltas:
We're now thoroughly in python-ideas land.
On Mon, Dec 21, 2015 at 7:39 AM, Random832 wrote:
> Guido van Rossum writes:
> > I'm sure that one often catches people by surprise. However, I don't
> > think we can fix that one without also fixing the values of the
>
Would you be able to submit a patch to address the docstring issues?
--Guido (mobile)
On Dec 21, 2015 2:09 PM, "Chris Barker" wrote:
> On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote:
>
>>
>> Would there be value in changing the repr to use keyword arguments?
>>
>
> this thread got long,
I still think the repr change to use keywords has a good chance for 3.6.
--Guido (mobile)
On Dec 21, 2015 2:09 PM, "Chris Barker" wrote:
> On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote:
>
>>
>> Would there be value in changing the repr to use keyword arguments?
>>
>
> this thread got lo
Also there's a great talk by Allison Kaptur on YouTube about this topic:
https://www.youtube.com/watch?v=HVUTjQzESeo
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
nd
Allison Kaptur (who gave the talk I mentioned).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-d
Can you show the diffs you have so far? Somebody's got to look at your code.
--Guido (mobile)
On Dec 27, 2015 16:51, "Erik" wrote:
> Thanks for your help so far (I'm experimenting with the peephole optimizer
> - hence my question before as I was trying to work out how to know what the
> small in
lace('.', '/') + '/' in two locations. One where it checks
> for the path being a directory entry in the zip file and the second to
> return an implicit namespace path (instead of not found) if it is a
> match. I'll check the patch on the tracker and see if
s that claim to enforce the guidelines
from those PEPs. The tools' rigidity and simplicity reflects badly on the
PEPs, which try hard not to be rigid or simplistic.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ct it's too late to try and get the pep8 authors to rename
it; but I filed an issue with the pep257 project and they are going to
change the name: https://github.com/GreenSteam/pep257/issues/172 .
FWIW I am happy that the tools exist! They can be very useful and I use
pep8 myself. But I always l
lly not start failing -- the current issue notwithstanding. :-)
So if buildbots are a scarce resource it's fine to repurpose them for more
recent releases.
Oh, finally. I'm eager to answer this but I'm not actually the best
resource here -- I'm pretty rusty where it comes to our bu
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>
> ___
> Python-Dev mailing list
> Python
your own __bool__ to match the
> standard True/False meanings or if you have implemented your own __bool__
> to match some other scheme entirely.
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list
&
I'm +0. The editor I use is too smart to let me make this mistake, but I
don't object to recommending it. As usual, though, let's not start mindless
reformatting of existing code.
--
--Guido van Rossum (python.org/~guido)
___
Python-D
se two, with preference for the second on multiline ifs,
> seems quite readable to me.
>
> --
> ~Ethan~
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
>
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
__
actually
>> > acceptable to Guido).
>>
>> I thought that the above was your intentional compromise change given
>> the range of opinions ;-).
>>
>
> It is, but Guido is the author of PEP 7 and so I didn't want to check in
> the change without his approval
; Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 1/21/2016 10:42 AM, Paul Moore wrote:
On 21 January 2016 at 17:18, Brett Cannon wrote:
It's live: https://docs.python.org/devguide/#status-of-python-branches
Nice :-)
Minor nit, the status column says "end of life", but the text below
the table uses the term "end of line" (as does the com
pretty good at forwarding URLs from
renamed repos).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev
but).
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.
On 2/1/2016 9:20 AM, Ethan Furman wrote:
On 02/01/2016 08:40 AM, R. David Murray wrote:
On the other hand, if the distros go the way Nick has (I think) been
advocating, and have a separate 'system python for system scripts' that
is independent of the one installed for user use, having the syst
On 2/5/2016 9:37 AM, Alexander Walters wrote:
On 2/5/2016 12:27, Emile van Sebille wrote:
On 2/1/2016 9:20 AM, Ethan Furman wrote:
On 02/01/2016 08:40 AM, R. David Murray wrote:
On the other hand, if the distros go the way Nick has (I think) been
advocating, and have a separate 's
On 2/5/2016 10:38 AM, Brett Cannon wrote:
On Fri, 5 Feb 2016 at 10:34 Emile van Sebille mailto:em...@fenx.com>> wrote:
>> Except for that nasty licensing issue requiring source code.
>>
>> Emile
> Licensing requires, in the GPL at least, that
t;
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~g
ng on such case. IMHO the
> warning can help to detect bugs for developers who just learnt Python.
Hum. I'm not excited by this idea. It is not bad syntax. Have you
actually seen newbies who were confused by such things?
--
--Guido van Rossum (python.org/~guido)
_
On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner
wrote:
> Le 8 févr. 2016 8:14 PM, "Guido van Rossum" a écrit :
>> Hum. I'm not excited by this idea. It is not bad syntax.
>
> Do you see an use case for "constant statements" other than strings and
> e
On Mon, Feb 8, 2016 at 1:20 PM, Victor Stinner wrote:
> Le 8 févr. 2016 9:34 PM, "Guido van Rossum" a écrit :
>> If you want to do linter integration that should probably be
>> integrated with the user's editor, like it is in PyCharm, and IIUC
>> people can d
tax error rather than removing the warning.
Compared to other "lint warnings" this one is much nastier -- it is
also much more certain that it is a mistake. (Much more certain than
e.g. an undefined variable, which could still be legitimate code due
to dynamic updates to globals
On Mon, Feb 8, 2016 at 5:41 PM, MRAB wrote:
> On 2016-02-09 00:53, Guido van Rossum wrote:
>>
>> The warning for 'assert (cond, msg)' was specifically put in because
>> this is a nasty trap. It's *always* a mistaken attempt to write
>> 'assert cond
Personally I don't think it's worth the churn.
On Mon, Feb 8, 2016 at 5:49 PM, Chris Angelico wrote:
> On Tue, Feb 9, 2016 at 12:41 PM, MRAB wrote:
>> On 2016-02-09 00:53, Guido van Rossum wrote:
>>>
>>> The warning for 'assert (cond, msg)' was
cker may not be precise
for cases that only accept bytes, but hopefully it's more useful in
general this way.
> Is there any recommended way to test the validity and completeness of stub
> files? What's the recommended way to parse them?
That's also an open issue. For a quic
PEP 484) is one that has a default value. The "Optional[T]"
notation in PEP 484 means "Union[T, None]". They mean different
things.
>> Can you help improve the wording in the docs (preferably by filing an issue)?
>
> When I eventually understand what it means...
--
-
qualifier on its type
annotation (although it is inferred if the default is ``None``).
A mandatory argument may still have an ``Optional`` type if an
explicit value of ``None`` is allowed.
Should be live on docs.python.org with the next push (I don't recall
the delay, at most a day I
On Wed, Feb 10, 2016 at 10:01 AM, Phil Thompson
wrote:
> On 10 Feb 2016, at 5:52 pm, Guido van Rossum wrote:
[...]
> That should do it, thanks. A followup question...
>
> Is...
>
> def foo(bar: str = Optional[str])
>
> ...valid? In other words, bar can be omitted, bu
count EXTENDED_ARG as an instruction). The only
> downside is the transitional cost
>
> What'd be necessary for this to be pulled upstream?
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pytho
/mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
from following CPython)?
Reference: https://github.com/python/mypy/issues/1281
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pytho
I agree that the spirit of the PEP is to stop at the first coding
cookie found. Would it be okay if I updated the PEP to clarify this?
I'll definitely also update the docs.
On Tue, Mar 15, 2016 at 2:04 PM, Brett Cannon wrote:
>
>
> On Tue, 15 Mar 2016 at 13:31 Guido van Rossum
ements the specification given above has
>> been posted to the issue tracker. [12]_
>>
>>
>> References
>> ==
>>
>> .. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html
>>
>> .. [2] http://dlang.org/spec/lex.html#integerlite
r we may want to preserve that
behavior.
Should we recommend that everyone use tokenize.detect_encoding()?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
done there).
Should we recommend that everyone use tokenize.detect_encoding()?
On Wed, Mar 16, 2016 at 5:05 PM, Guido van Rossum wrote:
> On Wed, Mar 16, 2016 at 12:59 AM, M.-A. Lemburg wrote:
>> The only reason to read up to two lines was to address the use of
>> the shebang on Unix, not
as, if any. Then the rest of the logic can be
handled by the caller (including the logic of trying up to two lines).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
I don't care too much either way, but I think passing underscores to the
constructor shouldn't be affected by the context -- the underscores are
just removed before parsing the number. But if it's too complicated to
implement I'm fine with punting.
--Guido (mobile)
On Mar 19, 2016 6:24 AM, "Nick C
ng this exactly is left out
of the PEP, and handled by whoever adds this to Decimal. Having a PEP
to work from for the language spec and core builtins (int(), float()
complex()) is more important.
On Sat, Mar 19, 2016 at 10:24 AM, Stefan Krah wrote:
>
> Guido van Rossum python.org> writ
All that sounds fine!
On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah wrote:
> Guido van Rossum python.org> writes:
>> So should the preprocessing step just be s.replace('_', ''), or should
>> it reject underscores that don't follow the rules from the P
ail/python-ideas/2016-January/037704.html),
and having used that for a few months the two proposals mentioned
above handle a few corner cases that were possible but a bit awkward
in our experience.
--
--Guido van Rossum (python.org/~guido)
___
Python-De
an
implementation.
(Reference for provisional modules: https://www.python.org/dev/peps/pep-0411/)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Heh. I could add an example with a long list of parameters with long
names, but apart from showing by example what the motivation is it
wouldn't really add anything, and it's more to type. :-)
On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert wrote:
> On Mar 19, 2016, at 18:18, Gui
efully Jukka will correct me. :-)
Again, I'd like this to go out with 3.5.2, because it requires adding
something to typing.py (and again, that's allowed because PEP 484 is
provisional -- see PEP 411 for an explanation).
--
--Guido van Rossum (python.org/~guido)
___
On Thu, Mar 17, 2016 at 9:50 AM, Serhiy Storchaka wrote:
> On 17.03.16 16:55, Guido van Rossum wrote:
>>
>> On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka
>> wrote:
>>>>
>>>> Should we recommend that everyone use tokenize.detect_encoding()?
returns its argument.
For use cases see the issue. Also send feedback there please.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
Sorry, for PEP feedback it's best to use this issue in the typing
tracker: https://github.com/python/typing/issues/189 (the issue I
linked to was in the mypy tracker).
On Mon, Mar 21, 2016 at 9:15 AM, Guido van Rossum wrote:
> Here's one more thing we'd like to add to PEP 484.
This seemed pretty uncontroversial -- I've updated the PEP (including
a long(ish) example :-).
On Sat, Mar 19, 2016 at 6:54 PM, Guido van Rossum wrote:
> Heh. I could add an example with a long list of parameters with long
> names, but apart from showing by example what the motiv
This seemed pretty uncontroversial. I've updated the PEP.
On Sat, Mar 19, 2016 at 6:52 PM, Guido van Rossum wrote:
> Here's another proposal for a change to PEP 484.
>
> In https://github.com/python/typing/issues/72 there's a long
> discussion ending with a reasonable
tps://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d look for a TCL/TK forum or something.)
>
> Thanks!
>
> Stefan
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.o
___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
o be settled and kill pathlib.py
(And yes, I'm dead serious about the latter, rather Solomonic option.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
801 - 900 of 6462 matches
Mail list logo
