Ethan!
--Guido
On Mon, Jun 25, 2018 at 12:15 PM Guido van Rossum wrote:
> OK, last call! I'll accept the current draft tomorrow unless someone
> pushes back.
>
> On Fri, Jun 22, 2018 at 8:37 AM Nick Coghlan wrote:
>
>> On 23 June 2018 at 01:16, Guido van Rossum wr
and found that there aren't use cases
known that are strong enough to need additional flexibility in the args of
a callable. (How is the code calling the callable going to know what
arguments are safe to pass?) If there really is a need we can address in a
future revision.
--
--Guido van Ros
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm
wrote:
>
>
> 18.05.2015, 02:50, Guido van Rossum kirjoitti:
>
> On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
> wrote:
>
>> Looking at PEP 484, I came up with two use cases that I felt were not
>> catered f
considered useful,
and we'll keep the issue open to remind us of it. Until then you'll have to
use plain "type" as the annotation (still better than "Any". :-)
On Mon, May 18, 2015 at 11:01 AM, Alex Grönholm
wrote:
>
>
> 18.05.2015, 18:05, Guido van Rossum kirjo
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)
___
Python-D
g the BDFL-Delegate (Mark
Shannon) approves.
--Guido
PEP: 484
Title: Type Hints
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum , Jukka Lehtosalo <
jukka.lehtos...@iki.fi>, Łukasz Langa
BDFL-Delegate: Mark Shannon
Discussions-To: Python-Dev
Status: Draft
Type: Standar
ary can do
> what it wants with that.
>
> What would it take to enable this kind of AST access in Python? Is it
> possible? Is it a good idea?
>
> -Ben
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pyth
__subclasscheck__. It's easily fixed.
>
> Realistically, I don't see typing.py being ready in time for 3.5.
> I'd be happy to be proved wrong.
>
> Cheers,
> Mark.
>
>
> P.S.
> I am worried by the lack of formal specification. It all seems a bit
what specifically were you referring to as "definitely
> cool" here: LINQ-style generator expressions that build SQL ala PonyORM, or
> the more general feature of enabling AST access?
>
> -Ben
>
> On Wed, May 20, 2015 at 10:31 PM, Guido van Rossum
> wrote:
>
>>
Things are looking up. I think we're down to a very small number of issues
where we still disagree -- hopefully you'll allow me some leeway. :-)
On Thu, May 21, 2015 at 8:45 AM, Mark Shannon wrote:
>
>
> On 21/05/15 16:01, Guido van Rossum wrote:
>
>> Hi Mark,
>
nting/issues) and I'll rectify those before
beta 2.
--Guido
PEP: 484
Title: Type Hints
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum , Jukka Lehtosalo <
jukka.lehtos...@iki.fi>, Łukasz Langa
BDFL-Delegate: Mark Shannon
Discussions-To: Python-Dev
Status: Draft
Type:
checking for non-native environments.
>
OK, I am saying it here. People writing type checkers can decide for
themselves what they want to support. (It is already the case that mypy can
check code for conformance with various Python versions, but mypy itself
must always run in Python 3.4 or lat
y defines a standard to be used by people implementing type checkers.
--
--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
Thanks Mark!
On May 22, 2015 1:52 PM, "Mark Shannon" wrote:
> Hello all,
>
> I am pleased to announce that I am accepting PEP 484 (Type Hints).
>
> Given the proximity of the beta release I thought I would get this
> announcement out now, even though there are some (very) minor details to
> iron
Congrats! Many thanks to all who contributed.
On May 22, 2015 2:45 PM, "Eric Snow" wrote:
> Hi all,
>
> After extended discussion over the last several months on import-sig,
> the resulting proposal for multi-phase (PEP 451) extension module
> initialization has finalized. The resulting PEP prov
l 2.6 What's New document was the
> real problem with making people aware of the addition of zip archive
> and directory execution support).
>
> Regards,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> __
But isn't that also a problem? It would make the existence of that member a
bit unpredictable.
On Saturday, May 23, 2015, Larry Hastings wrote:
>
>
> On 05/23/2015 09:46 PM, Guido van Rossum wrote:
>
> How will __definition_order__ be set in the case where __prepare__
kes it less convenient for library authors.
>
> If you still think that's not enough justification then we can table
> __definition_order__ for now.
>
Let's table it. It's hard to compare alternatives on a single dimension of
"which is a bigger change".
open-source projects, with a large variety of
different release schedules) to Python (which is a single,
centrally-controlled code base).
What do other projects that are at most 1 order of magnitude smaller or
larger than Python do? E.g. the Linux kernel, or Mysql, or Qt?
--
--Guido van Rossum (pyth
y in favor.
--
--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
open-source tool that can build PEX files)?
Łukasz has told me that at Facebook they have a similar system that they
are now using to deploy Python 3 binaries.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, May 28, 2015 at 5:58 PM, Victor Stinner
wrote:
> 2015-05-28 18:07 GMT+02:00 Guido van Rossum :
> > This patch could save companies like Dropbox a lot of money. We run a
> ton of
> > Python code in large datacenters, and while we are slow in moving to
> Python
on this thread whose
employer pays them to work on Python. And this thread originated when a
patch was being contributed by people who were also paid by their employer
to do all the dirty work (including benchmarks). And yet they were
(initially) given the cold shoulder by some "high and mighty" Py
track of suspended frames. So I'm
not sure exactly what information you think the interpreter has stored but
does not expose. Even asyncio/tasks.py does not have this bookkeeping -- it
keeps track of Tasks, which are an asyncio-specific class that wraps
certain coroutines, but not every coroutine
On Sat, Jun 13, 2015 at 12:22 AM, Nick Coghlan wrote:
> On 13 June 2015 at 04:13, Guido van Rossum wrote:
> > IOW I don't think that the problem here is that you haven't sufficiently
> > motivated your use case -- you are asking for information that just isn't
>
ve with f_executing). We could then easily provide a new method or
property on the frame object that returns the desired generator if the flag
is set or None if the flag is not set -- other Python implementations could
choose to implement this differently.
--
--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
implementation to address some beta compatibility
> issues with functools.singledispatch and Tornado.
>
> Cheers,
> Nick.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
nous assignment, do we allow asynchronous deletion as
>> well?
>>
>
> Yeah, we'd kind of be letting the camel's nose in
> here. There's no obvious place to stop until *every*
> dunder method has an async counterpart.
E
does and what you think it should do, instead?
--
--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/pyth
On Mon, Jun 22, 2015 at 3:03 AM, Nick Coghlan wrote:
> On 22 June 2015 at 08:46, Ivan Levkivskyi wrote:
> >
> >
> > On 21 June 2015 at 22:05, Guido van Rossum wrote:
> >>
> >> On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi
> >> wrote:
&
than killing the
> process (Idle or Command Prompt).
>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.
(issue 581232) time.sleep on windows was
> not interruptible and this was fixed. Is it possible the work on EINTR
> has broken that fix?
>
> (I don't currently have 3.5 installed on windows to test that theory...)
>
> On Sat, 04 Jul 2015 17:46:34 +0200, Guido van Rossum
> w
_
> 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)
Just my £0.02p worth.
>
Agreed. It's also probably easier to just ignore an obviously bad or poorly
thought-out idea than to try to engage the OP in lengthy explanations of
why that is so. After all there's a huge amount of subjectivity -- we won't
change our minds, but it takes forever
to do
without a bigger overhaul of our process -- which takes time and may well
already be underway.
On Tue, Jul 7, 2015 at 2:25 PM, Antoine Pitrou wrote:
> On Tue, 7 Jul 2015 14:14:49 +0200
> Guido van Rossum wrote:
> > FYI, do we have any indication that Raymond even read the com
l 7, 2015 at 2:32 PM, Maciej Fijalkowski wrote:
> On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum wrote:
> > FYI, do we have any indication that Raymond even read the comment? IIRC
> he
> > doesn't regularly read python-dev. I also don't think code review
> comment
icient to assign the tracker entry back to me.
>>
>
> Well, I'll open new issue and assign it to you for every your commit that
> looks questionable to me.
>
That sounds like a fine solution, and a good conclusion of the thread.
--
--Guido van Rossum (python.org/~guido)
_
gt; Popen.communicate() yourself?
>
> cheers,
>
> Chris
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman
Your +infinity could have easily been top posted -- particularly when
there's no in-line comments that require context.
just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,
Emile
On 7/19/2015 2:16 PM, Mark Lawrence wrote:
On 19/07/2015 22:06, Brett Cannon wrote:
There is a
Sorry for reviving this thread, but I was cornered at EuroPython with a
question about the status of this PEP. It seems the proposal ran out of
steam and has now missed the Python 3.5 train. What happened? Is the
problem unsolvable? Or could we get this into 3.6???
_
, 2015 at 6:22 PM, Lennart Regebro wrote:
> On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum
> wrote:
> > Sorry for reviving this thread, but I was cornered at EuroPython with a
> > question about the status of this PEP. It seems the proposal ran out of
> > steam and has n
t
(if it's ever created -- personally I think it's a waste) and change the
subject if you need me to chime in.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
do),
'; busy:', len(self.busy))
Can we allow the same in f-strings? E.g.
print(f'Todo: {len(self.todo)
}; busy: {len(self.busy)
}')
or is that too ugly? It could also be solved using implicit concatenation,
e.g.
print(f'Todo: {len(self.todo)};
HP Converged Cloud
> ___
> 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
;
> I'd prefer 3; that's what we normally do, and that's what I was
> expecting. So far people have done 1 and 2.
>
> Can we pick one approach and stick with it? Pretty-please?
>
>
> */arry*
>
> ___
> python-committers mailing lis
titutions). These token types can then be used in the
grammar. (A complication would be different kinds of string quotes; I
propose to handle that in the lexer, otherwise the number of open/close
token types would balloon out of proportions.)
--
--Guido van Rossum (python.org/~guido)
___
glance at the
> lexer and I can't see how to make the opening quotes agree with the
> closing quotes.
>
The lexer would have to develop another stack for this purpose.
> I think the i18n case (if we chose to support it) is better served by
(the interpolated expression cannot contain string quotes). However, I do
think we should support f"...{a['key']}...".
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
p debating this point -- any acceptable solution will have to
support (more-or-less) arbitrary expressions. *If* we end up also
attempting to solve i18n, then it will be up to the i18n toolchain to
require a stricter syntax. (I imagine this could be d
mplication would be different kinds of string
> quotes;
> > > I propose to handle that in the lexer, otherwise the number of
> > > open/close token types would balloon out of proportions.)
> >
> > This would save a few hundred
4.92
> spectral_norm 4.72
> normal_startup 4.39
> telco 3.88
> startup_nosite 3.7
> call_method 3.63
> unpack_sequence 3.6
> call_method_slots 2.91
> cal
>
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of
> Guido van Rossum
> Sent: Saturday, August 22, 2015 7:15 PM
> To: Patrascu, Alecsandru
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Profile Guided Optimization active by-default
>
> How abou
>
> Level 1: Backwards incompatible changes might be introduced in new Python
> releases (including micro releases)
>
> Level 2: Only backwards compatible changes (new APIs including) can be
> introduced in micro releases.
>
> Sorry for the confusion.
>
>
> Yury
>
we
> won't break existing code. That's why I propose to tweak our definition of
> provisional packages.
>
>
> Yury
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/
-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)
___
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
he expression in parens before evaluation. If the PEP is accepted, I'll
> fix that and update the issue.
No worries. (The parens thing was something I suggested to Eric this
afternoon. :-)
I'll say a few words about PEPs 501 and 502, but I'll start separate
threads.
--
--Guid
y to care about i-strings either.
- Logging: again, it's hard to beat the existing solution, which mostly
comes down to using %r instead of %s for any user-supplied or otherwise
unverified data.
- HTML quoting is an art and I'm skeptical that the proposal will even work
for tha
r f-strings -- they would
have to be added as a second string type. And the proliferation of similar
but different template string types cannot make anyone happy.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.or
On Sat, Sep 5, 2015 at 5:11 AM, Nick Coghlan wrote:
> On 5 September 2015 at 13:04, Guido van Rossum wrote:
> > I think it's too much effort for too little gain.
> >
> > The motivation feels very weak; surely writing
> >
> > os.system("echo "
On Sat, Sep 5, 2015 at 1:44 AM, haypo s wrote:
> 2015-09-05 5:01 GMT+02:00 Guido van Rossum :
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> >
On Sat, Sep 5, 2015 at 2:10 AM, haypo s wrote:
> 2015-09-05 5:01 GMT+02:00 Guido van Rossum :
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > t
Awesome! We need more people with those skills!
--Guido (on mobile)
On Sep 5, 2015 11:07 AM, "Yury Selivanov" wrote:
> On 2015-09-05 1:27 PM, David Mertz wrote:
>
>> I have to apologize profusely here. Just after I offered to do this (and
>> work even said it was OK in principle to do it on wor
e the discussion (on allowing or not complex
> expressions in f-string) into a short paragraph in the PEP?
>
> I don't follow python-ideas and I don't want to subscribe.
>
But you can at least read the PEP. There is a whole section "Supporting
full Python expressions&quo
ed for in other threads.
>
> Are people interested in a "rationale and best practices" for string
> interpolation pep?
>
> -Mike
>
>
> On 09/04/2015 08:15 PM, Guido van Rossum wrote:
>
>> The text of the PEP has too much on motivation and rationale: maybe th
policy we come up with.
>
> ___
> 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
>
>
-
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 lis
t; > I prefer to build the second parameter outside the f-string:
> > opts = '|'.join('--'+opt for opt in valid_opts)
> > print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
> >
> ___
> Python-Dev mailing l
wrote:
> Ok, I thought that's what you and others were asking for in previous
> threads.
>
> -Mike
>
>
>
> On 09/08/2015 10:32 AM, Guido van Rossum wrote:
>
>> Sounds awfully premature. Style guides are typically updated in response
>&
be as easy... :-)
--
--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
o silence a deprecation warning and you can make it so
>> that even if you use -Werror your deprecated module imports continue to
>> work without throwing an exception while all other deprecations do throw an
>> exception.
>>
>> Whatever decision we come to I will
I think we're getting into python-ideas territory here...
--Guido (on mobile)
___
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%4
``git rebase --interactive --preserve-merges
>> HEAD~5`` manually even for those who are happy to use command-line,
>> and this is where shell completion is of great help. Bash/zsh come
>> with programmable completion, often automatically installed and
>> enabled, so if you have bash/zsh and git installed, chances are you
>> are already done - just go and use it at the command-line.
>>
>> If you don't have necessary bits installed, install and enable
>> bash_completion package. If you want to upgrade your git completion to
>> the latest and greatest download necessary file from `git contrib
>> <https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
>>
>> Git-for-windows comes with git-bash for which bash completion is
>> installed and enabled.
>>
>>
>> bash/zsh prompt
>> ---
>>
>> For command-line lovers shell prompt can carry a lot of useful
>> information. To include git information in the prompt use
>> `git-prompt.sh
>> <
>> https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh
>> >`_.
>> Read the detailed instructions in the file.
>>
>> Search the Net for "git prompt" to find other prompt variants.
>>
>>
>> git on server
>> =
>>
>> The simplest way to publish a repository or a group of repositories is
>> ``git daemon``. The daemon provides anonymous access, by default it is
>> read-only. The repositories are accessible by git protocol (git://
>> URLs). Write access can be enabled but the protocol lacks any
>> authentication means, so it should be enabled only within a trusted
>> LAN. See ``git help daemon`` for details.
>>
>> Git over ssh provides authentication and repo-level authorisation as
>> repositories can be made user- or group-writeable (see parameter
>> ``core.sharedRepository`` in ``git help config``). If that's too
>> permissive or too restrictive for some project's needs there is a
>> wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
>> be configured to allow access with great granularity; gitolite is
>> written in Perl and has a lot of documentation.
>>
>> Web interface to browse repositories can be created using `gitweb
>> <https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
>> <http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
>> Perl and C). In addition to web interface both provide read-only dumb
>> http access for git (http(s):// URLs).
>>
>> There are also more advanced web-based development environments that
>> include ability to manage users, groups and projects; private,
>> group-accessible and public repositories; they often include issue
>> trackers, wiki pages, pull requests and other tools for development
>> and communication. Among these environments are `Kallithea
>> <https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
>> both are written in Python; pagure was written by Fedora developers
>> and is being used to develop some Fedora projects. `Gogs
>> <http://gogs.io/>`_ is written in Go; there is a fork `Gitea
>> <http://gitea.io/>`_.
>>
>> And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
>> perhaps the most advanced web-based development environment for git.
>> Written in Ruby, community edition is free and open source (MIT
>> license).
>>
>>
>> From Mercurial to git
>> =
>>
>> There are many tools to convert Mercurial repositories to git. The
>> most famous are, probably, `hg-git <https://hg-git.github.io/>`_ and
>> `fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
>> it was known under the name ``hg2git``).
>>
>> But a better tool, perhaps the best, is `git-remote-hg
>> <https://github.com/felipec/git-remote-hg>`_. It provides transparent
>> bidirectional (pull and push) access to Mercurial repositories from
>> git. Its author wrote a `comparison of alternatives
>> <
>> https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives
>> >`_
>> that seems to be mostly objective.
>>
>> To use git-remote-hg, install or clone it, add to your PATH (or copy
>> script ``git-remote-hg`` to a directory that's already in PATH) and
>> prepend ``hg::`` to Mercurial URLs. For example::
>>
>> $ git clone https://github.com/felipec/git-remote-hg.git
>> $ PATH=$PATH:"`pwd`"/git-remote-hg
>> $ git clone hg::https://hg.python.org/peps/ PEPs
>>
>> To work with the repository just use regular git commands including
>> ``git fetch/pull/push``.
>>
>> To start converting your Mercurial habits to git see the page
>> `Mercurial for Git users
>> <https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
>> At the second half of the page there is a table that lists
>> corresponding Mercurial and git commands. Should work perfectly in
>> both directions.
>>
>>
>> Copyright
>> =
>>
>> This document has been placed in the public domain.
>>
>>
>>
>> ..
>>Local Variables:
>>mode: indented-text
>>indent-tabs-mode: nil
>>sentence-end-double-space: t
>>fill-column: 70
>>coding: utf-8
>>End:
>>vim: set fenc=us-ascii tw=70 :
>> ___
>> 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-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
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)
___
Python-Dev mai
n-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)
___
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
acklevel=(2+stacklevel)).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
&g
. The
datetime-sig is now open for their discussion. However, proposals that
break backwards compatibility are a waste of everybody's time, so be
prepared to explain how your proposal does not break existing code that
works under Python 3.5.
--
--Guido van Rossum (python.
).timestamp() == dt.astimezone().timestamp()
> Regards,
> Nick.
>
> P.S. Thanks to whoever drew the diagrams for the In the Fold/Mind the
> Gap sections - I found them incredibly helpful in understanding the
> change!
>
You're welcome. It was a collaboration by myself and
mpatible types. < and > are supposed to fail but == is supposed to
return False (the __eq__ should return NotImplemented). If == ever raises
an exception, having two different objects as dict keys can cause random,
hard-to-debug failures.
--
--Guido van Rossum (python.org/~guido)
__
hould raise an exception in this case.
> That's why, whenever anyone is confused by anything they see in a
> Python program, they should post all their code verbatim to
> Python-Dev, prefaced with a "Doesn't work! Fix it." comment ;-)
>
Oh, it would be so much bet
; BTW, while the PEP doesn't spell this out, trichotomy can fail in some
> such cases (those where "==" would have returned True had it not been
> forced to return False - then "<" and ">" will also be False).
>
> I
On Tue, Sep 22, 2015 at 11:26 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum
> wrote:
>
>> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>>> such cases (those w
problems. Similarly a language with a special symbol for
> > string catenation would not have a non-commutative + and non-
> > distributive *. All I am saying is that I can live with the choices made
> > in datetime.
>
> Given that the alternative is suicide, I approve of that li
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
Your comments make total sense -- we're just short on people who can write
that kind of docs. :-(
On Mon, Sep 28, 2015 at 2:15 PM, Barry Warsaw wrote:
> On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:
>
> >I saw that you had a need for an asyncio tutorial. I wonder if
fo/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
--
> >
> >___
> >Python-Dev mailing list
> >Python-Dev@python.org
> >https://mail.python.org/mailman/listinfo/python-dev
> >Unsubscribe:
> >https://mail.
he
best language it can be.
--Guido
On Mon, Oct 5, 2015 at 1:18 PM, Ryan Gonzalez wrote:
> PSF. Nothing personal, of course...
>
>
> On October 5, 2015 3:01:11 PM CDT, Guido van Rossum
> wrote:
>>
>> "They"?
>>
>> On Mon, Oct 5, 2015 at 12:57 PM
ot sure that this is the best solution given the audience -- but
the type variable 'F' only needs to be defined once, so this might actually
work.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https:
simpler API, but randrange is more familiar for
> Python users due to similarity to range and because it is the public API in
> the random module (unlike to randbelow).
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
it between the three
> functions. There doesn't seem to be any use-case for the three argument
> version of randrange.
>
I'm fine with dropping the 3rd arg. But I find the argument to introduce a
new spelling for 1-arg randrange() weak.
I definitely thing that randint() is an att
Yes, randrange(n) does that.
--Guido (mobile)
On Oct 17, 2015 2:28 PM, "Brian Gladman" wrote:
> > Guido van Rossum wrote:
>
> > I'm fine with dropping the 3rd arg. But I find the argument to
> > introduce a new spelling for 1-arg randrange() weak.
>
&
OK, so just randbelow() then.
--Guido (mobile)
On Oct 17, 2015 2:13 PM, "Tim Peters" wrote:
> [Steven D'Aprano]
> >> ...
> >> I think it is fair to say that out of the three functions, there is
> >> consensus that randbelow has the most useful functionality in a crypto
> >> context. Otherwise, p
you should use one or the other. The only
> obvious example I've seen is the RingBuffer from the Python Cookbook:
>
> http://code.activestate.com/recipes/68429-ring-buffer/
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list
>
ethod, and quite tame in comparison.
--
--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/arch
OrderedDict. The corner cases impacted by the above
> compatibility concerns are borderline enough that I wanted to get some
> feedback. Thanks!
>
> -eric
>
>
> [1] http://bugs.python.org/issue25410
> [2] https://www.python.org/dev/peps/pep-0399/
> [3] https
On Mon, Oct 19, 2015 at 2:47 PM, Serhiy Storchaka
wrote:
> On 20.10.15 00:00, Guido van Rossum wrote:
>
>> Apart from Serhiy's detraction of the 3.5 bug report there wasn't any
>> discussion in this thread. I also don't really see any specific
>> question
ike these in PEP 399?
> They could go near the part that says "as close to the pure Python
> implementation as reasonable".
>
> -eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pytho
.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/l
ypes to have GC. Armin Rigo found previous examples where this
> special case caused problems, and I don't see what it buys anyway.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python
to use isinstance() to distinguish the cases. A type
checker would have to recognize this as a special case (so as not to
complain about the non-overloaded version). Jukka thinks it would be about
a day's work to implement in mypy; the work in typing.py would be a few
minutes.
Thoughts?
701 - 800 of 6462 matches
Mail list logo
