On 30 Nov 2014 09:28, "Donald Stufft" wrote:
>
> As promised in the "Move selected documentation repos to PSF BitBucket
> account?" thread I've written up a PEP for moving selected repositories
from
> hg.python.org to Github.
>
> You can see this PEP online at: https://www.python.org/dev/peps/pep-
erator.
This change in semantics will make it possible to fix a latent defect
in contextlib.contextmanager, where using a subgenerator as part of
the context manager implementation may currently lead to inadvertently
suppressing StopIteration in the body of a covered with statement.
he use of non-free software to
participate in core Python community design processes.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
with the main CPython
repo.
Regards,
Nick.
P.S. I'll also bring up some of the RFEs raised in this discussion
around making it possible for folks to submit pull requests via
GitHub/BitBucket, even if the master repositories are hosted on PSF
infrastruct
On 3 Dec 2014 08:47, "Donald Stufft" wrote:
>
>
>> On Dec 2, 2014, at 5:42 PM, Guido van Rossum wrote:
>>
>> Before anyone gets too excited about Rietveld (which I originally wrote
as an APp Engine demo), AFAIK we're using a fork that only Martin von
Loewis can maintain -- and it's a dead-end for
4q4/60.html
I only posted that a few minutes ago, so we'll see what the existing
Kallithea contributors think of the idea :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
ally acceptable as
contributions to the upstream Roundup project, rather than needing to
be CPython specific.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
t;str(bytes_value)" traps when discussing the bytes/text changes.
Those do rather different things in Python 2 & 3, but won't emit an
error or warning in either version.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
repo if you have edits).
Thanks Guido, that explanation of the change looks great to me.
And thanks also to Chris and everyone else that helped with the rather
involved discussions!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 6 December 2014 at 14:40, Nick Coghlan wrote:
> On 6 December 2014 at 10:44, Benjamin Peterson wrote:
>> On Fri, Dec 5, 2014, at 18:16, Donald Stufft wrote:
>>> Do we need to update it? Can it just redirect to the 3 version?
>>
>> Technically, yes, of course.
current post-merge test runner to handle testing the esoteric systems that
> we can’t work into the pre-merge testing.
Yep, that's exactly the approach I had in mind for this problem.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
has even been working on
reference images for Apache/mod_wsgi hosting of Python web services:
http://blog.dscpl.com.au/2014/12/hosting-python-wsgi-applications-using.html)
You still end up with Vagrant as a required element for Windows and
Mac OS X, but that's pretty much a given fo
your own
tracker instance can be a single click operation on a normal
hyperlink. That also has the advantage of making it easy to share
changes to demonstrate UI updates. (OpenShift doesn't support running
containers directly yet, but that capability is being worked on in the
upstream OpenShi
On 9 Dec 2014 08:47, "Barry Warsaw" wrote:
>
> On Dec 09, 2014, at 09:31 AM, Ben Finney wrote:
>
> >Rather, I'm asking what, specifically, necessitates this situation.
> >
> >What would need to change, for the PSF to accept contributions to the
> >Python copyrighted works, without requiring the co
second values
* how to accept nanosecond values
* how to correctly unpickle old datetime pickle values
* how to update strptime() and strftime()
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-
d builds, and if
anyone starts being annoying with it, we have the option of just
disabling it entirely until we set up authentication for it.
Requiring authentication for the BuildBot triggers is likely an
improvement we should consider in the current infrastructure review
regardless,
s, the
inclusion of pip in Python 2.7 to improve the availability of
migration tools and backported modules, and the return of printf-style
binary interpolation support in Python 3.5, several of the concrete
challenges that make migration harder than it needs to be are being
addressed.
On 13 Dec 2014 05:19, "Petr Viktorin" wrote:
>
> Also keep in mind that not all Python libraries are on PyPI.
> For non-Python projects with Python bindings (think video players,
> OpenCV, systemd, Samba), distribution via PyPI doesn't make much
> sense. And since the Python bindings are usually s
ing the
migration (like
http://developerblog.redhat.com/2014/09/09/transition-to-multilingual-programming-python/)
are cold comfort when you're one of the ones actually doing the work
of supporting two parallel variants of the language.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
t.
That would be the release managers for the respective CPython releases
(in collaboration with the rest of python-dev).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.
*never* advised anyone
else to do the same. Even before experience showed the source
compatible approach was more practical, the original advice to third
party developers was to use 2to3 to automatically derive the Python 3
version from the Python 2 version and address any compatibility issues
by
folks are OK with this idea, I'll go ahead and make the appropriate
changes to PEP 1 and the PEP index generator. I'm also happy to file a
tracker issue, or write a short PEP, if folks feel making such a
change requires a little more formality in its own right.
Regards,
Nick.
--
On 18 December 2014 at 08:10, Barry Warsaw wrote:
> On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote:
>
>>However, I'd be happier if we could communicate that status more
>>explicitly through the PEP process, especially as I think such a
>>capability would be use
; Presumably, our test suite should be able to catch some (most?) of that
> breakage.
>
And if we're going to do something like that for 3.5, now's the time, since
we still have a lot of lead time on the 3.5 release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bris
as a reference for the detailed decision making
process that went into the changes that were made.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
ar scenarios.
It's a fair bit of work to make it happen though, so it will likely
remain a "wish list" item unless someone gets particularly inspired to
do something about it :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 7 January 2015 at 00:12, Antoine Pitrou wrote:
> On Tue, 6 Jan 2015 23:56:30 +1000
> Nick Coghlan wrote:
>> "pip" is problematic on Linux as well (due to the pip/pip3 split at
>> the system level). Hence this section in the stdlib docs:
>> https://docs.
andle CPython itself, rather than
attempting to build those flows directly into the existing Roundup and
Rietveld based approach.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-De
ctures would mainly be the domain of Richard Oudkerk (sbt) as
the lead maintainer for the module.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
pain stop :)
By bypassing the normal interpreter entirely, and instead creating
your own custom binary that embeds the CPython runtime, you get a lot
more flexibility and control in terms of what happens during the
startup sequence. It's not complete control (hence the need for PEP
432, or som
On 13 January 2015 at 06:02, Steve Dower wrote:
>> On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote:
>>> For the time being, things like PyInstaller, PyRun, Portable Python,
>>> etc are going to offer a better solution than anything we provide in
>>> the st
s
>
> Nice, that answered other questions as well! :)
It's worth noting that https://docs.python.org/3/c-api/stable.html is
the relevant reference in the main C API docs.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
the name of your
script for learning about how TCP sockets work" problem). We're aware
that annoys power users, but they're far better equipped to handle the
problem than if we inverted the situation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
gets us a round a couple of bootstrapping problems, where
generating some of those files requires a working Python interpreter,
which you may not have if you just cloned the source tree or unpacked
the tarball.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.co
On 25 Jan 2015 01:09, "Benjamin Peterson" wrote:
>
>
>
> On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
> > On 20 January 2015 at 10:53, Benjamin Peterson
> > wrote:
> > >
> > >
> > > On Mon, Jan 19, 2015, at 19:40, Neil Gir
On 26 Jan 2015 02:33, "R. David Murray" wrote:
>
> On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan
wrote:
> > It's far more developer friendly to aim to have builds from a source
> > check-out "just work" if we can. That's pretty much where we
On 26 Jan 2015 07:58, "Greg Ewing" wrote:
>
> Petr Viktorin wrote:
>>
>> On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar
wrote:
>>
>>> How do I disassemble a generated comprehension?
>>>
>> Put it in a function, then get it from the function's code's constants.
>
>
> It would be handy if dis had a
ould make the eval code harder to read, and various
introspection tasks (like "tell me all the names referenced from this
code object") significantly more difficult.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
t level, we're
well down into the weeds of needing to think about how the underlying
Python interpreter *works*, rather than just what it allows a Python
programmer to do.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
itten that to
depend on PEP 474, and propose replacing the current Rietveld patch
review workflow with an updated approach based on Kallithea and Zuul:
https://www.python.org/dev/peps/pep-0462/
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On 2 Feb 2015 04:56, "francis" wrote:
>
> Hi Nick,
>
> On 02/01/2015 08:46 AM, Nick Coghlan wrote:
> [...]
> > The updates to PEP 462, which covers proposed changes to the main
> > CPython workflow, were more significant, as I've now rewritten that to
&g
On 3 Feb 2015 01:26, "Brett Cannon" wrote:
>>>
>>
>>
>> Is there going to be discussion between the two approaches or should the
PEPs themselves address each other?
>
>
> Since PEPs are meant to act as a record of what was discussed on a topic
then it probably wouldn't hurt to incorporate why your
On 3 Feb 2015 06:46, "Antoine Pitrou" wrote:
>
>
> Hello,
>
> I'm now accepting PEP 475 - "Retry system calls failing with EINTR".
> You can read it at https://www.python.org/dev/peps/pep-0475/
>
> The implementation is more or less ready at
> http://bugs.python.org/issue23285, so you can expect i
https://lists.fedoraproject.org/pipermail/epel-devel/2014-January/009043.html
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/
On 10 Feb 2015 08:13, "Benjamin Peterson" wrote:
>
>
>
> On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote:
> > On 02/09/2015 01:28 PM, Benjamin Peterson wrote:
> > > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> > >>
> > >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
On 10 Feb 2015 19:24, "Terry Reedy" wrote:
>
> On 2/9/2015 7:29 PM, Neil Girdhar wrote:
>>
>> For some reason I can't seem to reply using Google groups, which is is
>> telling "this is a read-only mirror" (anyone know why?)
>
>
> I presume spam prevention. Most spam on python-list comes from the
On 10 Feb 2015 19:41, "Paul Moore" wrote:
>
> I agree completely with Donald here. The comprehension syntax has
> consistently been the part of the proposal that has resulted in
> confused questions from reviewers, and I don't think it's at all
> intuitive.
>
> Is it allowable to vote on parts of
On 10 Feb 2015 22:40, "Paul Moore" wrote:
>
> tl;dr - Having a shared per-user scripts directory on Windows
> (%APPDATA%/Python/Scripts) causes a number of potential issues when
> users install the same package in multiple Python versions. I'd like
> to suggest that this be changed to a versioned
On 11 Feb 2015 03:47, "Steve Dower" wrote:
>
> This is yet another attempt to try and change user behaviour, which I'm
not thrilled about, but I'm really starting to feel that this is the best
way out of a bad situation. It differs from the solutions used on Linux,
though there may be some value i
array
interoperate with any bytes-like object that results in the "left
operand wins" behaviour when you use them together.
I don't believe we deliberately designed it that way, it's just an
inherent consequence of having both types implement concatenation
based on th
elf, perhaps Steve Dower
would be an appropriate BDFL-Delegate?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
rosaic, but also more self-explanatory, "pyzapp", although
it looks like I may have suggested that to Daniel offline rather than
through the mailing list).
Regardless, the PEP's not controversial as far as I am aware, so it
would be nice if someone had the time to get it cleaned up and
for
ving it in a separate file rather than making the main
implementation file for os even larger does seem like an attractive
structural option though.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing lis
On 14 Feb 2015 01:47, "Paul Moore" wrote:
>
> On 13 February 2015 at 14:27, Steve Dower
wrote:
> > If py.exe starts defaulting to whatever is on PATH then I don't see the
> > point of it. Knowing that you'll get the latest 2.x version by default
is
> > quite handy (I'd be quite okay changing that
On 14 Feb 2015 03:43, "Nathaniel Smith" wrote:
>
> On 13 Feb 2015 02:09, "Victor Stinner" wrote:
> >
> > A alternative is to add a new _scandir.c module to host the new C
> > code, and share some code with posixmodule.c: remove "static" keyword
> > from required C functions (functions to convert
On 14 Feb 2015 07:31, "Paul Moore" wrote:
>
> (By the way, on a procedural note, how do I update a PEP? Do I just
> send an updated version to p...@python.org, or is there a better way?)
If you're happy to handle the PEP editor responsibilities described in PEP
1 yourself, you can also ask for co
On 14 Feb 2015 13:17, "Cameron Simpson" wrote:
>
> -1 on that. People will use it! Given the doco above, it should be
obvious under what circumstances one might choose to call stat, and making
that stat overt means it is less likely to be called unwisely.
>
> Since scandir is all about efficiency,
On 14 Feb 2015 07:39, "Isaac Schwabacher" wrote:
>
> On 15-02-13, Guido van Rossum wrote:
> > Are you willing to wait 10 days for an answer? I'm out of round
tuits for a while.
>
> IIUC, the argument is that the Liskov Substitution Principle is a
statement about how objects of a subtype behave re
On 14 Feb 2015 08:57, "Alexander Belopolsky"
wrote:
>
>
> On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar
wrote:
>>
>> Interesting:
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
>
>
> Let me humbly conjecture that the people who wrote t
ocedural API like that over offering
a public stateful object-oriented API, as the latter significantly
increases testing complexity without offering a sufficiently
compelling gain in expressiveness to justify the additional upfront
test development cost and the ongoing maintenance and support burde
comprehensive pex). It would be a short PEP,
but potentially still worth it for the improved visibility of the
decision when folks are trying to figure out what "pyz" and "pyzw"
files are later.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 15 February 2015 at 23:21, Paul Moore wrote:
> On 15 February 2015 at 08:59, Nick Coghlan wrote:
>> The other option would to cut PEP 441 way back to *just* be about
>> standardising and registering the file associations, and recommending
>> the use of pip to obtain the
IME prefix with IANA has been
vaguely kicking around on my todo list since we switched the PyPA
metadata PEPs over to using JSON. If anyone did decide to follow up on
that idea, the PSF Infrastructure working group mailing list would
likely be a suitable contact address to use (Infra already han
e wrapt may be a
better choice (and has the advantage of working today rather than only
in 3.5+)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
On 21 February 2015 at 04:47, Brett Cannon wrote:
> I just realized I actually never committed this change. Assuming no new
> objections I'll commit this in the near future (promise this time =).
Looks good to me :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
f text that primes my pattern
recognition, but doesn't change much across different error messages.
Regards,
Nick.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
>
at protocols you're working
with. By contrast, for IntEnum, we want that to be an
as-close-to-drop-in-as-is-feasible replacement for existing ints, so
there's a clear correct answer: we need to serialise it to JSON as an
integer, and lose the additional enum de
ting to
trust AC to do the right thing, so having it implicitly asking me to
check its work all the time ultimately become annoying rather than
reassuring :)
I assume some parts, like the header for the implementation function,
will always need to be generated inline in the hand-edited
impleme
On 24 February 2015 at 08:40, Nick Coghlan wrote:
> On 24 February 2015 at 07:39, Mark Lawrence wrote:
>> On 23/02/2015 21:27, Serhiy Storchaka wrote:
>>>
>>> On 23.02.15 21:58, Joao S. O. Bueno wrote:
>>>>
>>>> That happens all the time
r and the one that updated this part of the
interpreter startup sequence to handle the switch to importlib in 3.3.
The PEP itself doesn't actually touch any of that internal machinery
though, it just makes the capability a bit more discoverable and
user-friendly.
Regards,
Nick.
Documentation (and adding the missing test) sounds right to me.
We'd at least want a "versionchanged" note on the function itself, and an
entry in the porting section of the (3.3? 3.4?) what's new guide.
Is there anywhere else we might want to mention it?
Regards,
Nick.
_
On 25 Feb 2015 07:23, "Alexander Belopolsky"
wrote:
>
>
> On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth wrote:
> >
> > > Is there a recommended way to invoke pip from setup.py? When I
specify
> > > "tests_require=" and run "python setup.py test", the requirements get
> > > installed using setupt
On 25 Feb 2015 06:52, "Paul Moore" wrote:
>
> On 24 February 2015 at 20:32, Barry Warsaw wrote:
> >>To modify an archive could be done using
> >>
> >>python -m zipapp old.pyz new.pyz [-p interpreter]
> >>
> >>Default is to strip the shebang (no -p option). There's no option to
> >>omit the ta
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-terminated."
> Personal reality distortion fields are immune to contradictory evidence. -
> srean
> Check out my website: http://kirbyfan64.github.io/
>
> ___
On 27 Feb 2015 07:12, "Brett Cannon" wrote:
>
>
>
> On Thu, Feb 26, 2015 at 3:38 PM Ethan Furman wrote:
>>
>> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>>
>> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and
it is now accepted.
>>
>> Congratulations Thomas, Joshua, and
On 28 Feb 2015 06:16, "Chris Barker" wrote:
>
> Thank you Guido.
>
> It'll be nice to see this all come to something.
>
> Thanks to all who contributed to the discussion -- despite this being a
pretty simple function, I learned a lot and far more fully appreciate the
nuance of all of this.
The si
fter Python 3.5 comes out, and even then the appropriate list
would be python-de...@lists.fedoraproject.org rather than here.
Regards,
Nick.
P.S. For those that aren't already aware, I became a voting member of
Fedora's Environments & Stacks Working Group several months ago an
to Final status!
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opt
experience perspective, but I
think a release blocker docs issue would be a good way to go for
ensuring it gets resolved be the release goes out.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
On 10 Mar 2015 02:37, "Donald Stufft" wrote:
> >
> > I'm okay with this. Installing for all users is really something that
could be considered an advanced option rather than the default, especially
since the aim (AIUI) of the all-users install is to pretend that Python was
shipped with the OS. (I'
On 10 Mar 2015 06:51, "Neil Girdhar" wrote:
>
>
>
> On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka
wrote:
>>
>> On 09.03.15 17:48, Neil Girdhar wrote:
>>>
>>> So you agree that the ideal solution is composition, but you prefer
>>> inheritance in order to not break code?
>>
>>
>> Yes, I agree.
Huzzah! Thanks for working on this one folks, it should make the zipfile
execution support much easier for current and future Python users to
discover :)
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
d tests for the new
behaviour, and the language reference doc updates look surprisingly
minimal to me).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.py
e can
figure out a good way of automating that).
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
Unsubscribe:
https://m
he available amount of core
developer time we have is relative to the amount of work that *could*
be done :(
The only time that guideline doesn't apply is if the release manager
declares mandatory commit reviews while preparing a release, and I
think Larry uses a release branch for that these days in
managed to hand it over after running out of
time to pursue it myself.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
ndently of what they
system does.
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
Unsubscribe:
https://mail.python
ass namespace).
Since it introduces new behaviour that's visible to Python level code,
I've suggested that Martin roll the suggestion into his current PEP
487 (which adds __init_subclass__ to similarly tidy up a few
challenges with the way classes are currently initialised).
Cheers,
The name comes from the underlying C/POSIX concept (dirent in this
case), which is fairly common for the low level APIs in the os module.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pyt
On 21 March 2015 at 22:19, Antoine Pitrou wrote:
> On Sat, 21 Mar 2015 21:52:34 +1000
> Nick Coghlan wrote:
>> On 19 March 2015 at 07:51, Donald Stufft wrote:
>> > I’ve long wished that the OS had it’s own virtual environment. A lot of
>> > problems
>> >
eir notation, even though
he wasn't proposing to change Python itself to allow positional-only
parameter definitions.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.or
bly build the reverse mapping from module names to the packages
that installed them. The draft "python.exports" extension in PEP 459
is supposed to provide that missing piece:
https://www.python.org/dev/peps/pep-0459/#the-python-exports-extension
Cheers,
N
On 22 Mar 2015 19:22, "Serhiy Storchaka" wrote:
>
> On 21.03.15 13:46, Nick Coghlan wrote:
>>
>> On 19 March 2015 at 19:28, Serhiy Storchaka wrote:
>>>
>>> Here is list of my ready for review patches. It is incomplete and
contains
>>> o
On 23 Mar 2015 00:45, "Paul Moore" wrote:
>
> Something that hit me today, which might become a more common issue
> when the Windows installers move towards installing to the user
> directory, is that there appear to be some bugs in handling of
> non-ASCII paths.
>
> Two that I spotted are a failu
On 24 Mar 2015 07:59, "Gregory P. Smith" wrote:
>
>
> On Wed, Mar 18, 2015 at 9:48 AM Barry Warsaw wrote:
>>
>> On Mar 18, 2015, at 05:31 PM, Victor Stinner wrote:
>>
>> >Does it work to pass command line options to Python in the shebang?
>>
>> Yes, but only one "word", thus -Es or -I.
>>
>> We'v
there's an open tracker
issue I filed some time ago to suggest clarifying it but haven't found
the time to actually sit down and come up with readable wording:
http://bugs.python.org/issue17960
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
into the build system.
It likely makes sense to try to at least write down the status quo
regarding the externals repo as a new top level section in the
Developer's Guide. That way you'll at least have a shared
understanding of the starting point for any further improvements.
Cheers
On 26 March 2015 at 12:40, Zachary Ware wrote:
> On Mar 25, 2015 9:28 PM, "Nick Coghlan" wrote:
>>
>> On 26 March 2015 at 01:57, Steve Dower wrote:
>> > Zachary Ware wrote:
>> >> On Mar 25, 2015 4:22 AM, "Paul Moore" wrote:
>> &g
ikely that cycles will be cleared
properly, even if some of the objects involved have __del__ methods:
https://www.python.org/dev/peps/pep-0442/
However, I'll grant that neither of those can be backported the way
that traceback.TracebackException can be.
Cheers,
Nick.
--
Nick Coghlan |
f how we going
about defining inherited creation time behaviour without needing a
custom metaclass.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
201 - 300 of 6587 matches
Mail list logo
