On 9 October 2013 10:46, Nick Coghlan ncogh...@gmail.com wrote:
The PEP needs to state more clearly up front (preferably in the title) that
it's about *reserving* a Python level syntax that matches the syntax we
worked out for Argument Clinic at PyCon US. Explicitly stating that the
On 9 October 2013 13:38, Benjamin Peterson benja...@python.org wrote:
Generally, it needs to be a bit clearer that the intent of the PEP isn't to
say let's do this, it's to be explicit that acceptance of the Argument
Clinic PEP severely constrains the design space for possible solutions if we
On 9 October 2013 15:30, Larry Hastings la...@hastings.org wrote:
Only if I can stop writing other PEPs and replying to their discussion
threads!
So once again, why is this new PEP needed? :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
On 9 October 2013 15:53, Larry Hastings la...@hastings.org wrote:
My goal in writing the PEP was to codify existing practice, which meant
reflecting these (annoying!) corner cases accurately.
That's fair. But I would argue that we very much don't want to
encourage anyone ever duplicating that
On 9 October 2013 16:07, Larry Hastings la...@hastings.org wrote:
On 10/09/2013 04:38 PM, Paul Moore wrote:
For that matter, why does the syntax used by Argument Clinic have to
be the same as whatever future syntax is used in Python? If indeed,
any ever is? What benefit do we get given
On 9 October 2013 18:00, Ethan Furman et...@stoneleaf.us wrote:
On 10/09/2013 09:05 AM, Paul Moore wrote:
I remain -1 on forcing Python syntax to support all of these odd
corner cases (and positional-only is already a corner case,
range/addch are seriously so).
Considering the prevalence
On 27 September 2013 15:08, Stephen J. Turnbull step...@xemacs.org wrote:
New users on Windows and Mac OS X. I've heard many more complaints
from folks running tutorials about the pip bootstrapping process than
I ever have from the community at large about the GIL :P
I bet those users are
On 27 September 2013 15:39, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 27/09/2013 15:26, Paul Moore wrote:
So, for Windows users, installing a package becomes pip install XXX.
Apologies if this has already been said but it only works if you've already
installed an appropriate compiler
On 22 September 2013 13:54, Eli Bendersky eli...@gmail.com wrote:
IMHO the right way to think about it is that the .rst files are by far the
more important documentation. Sometimes we forget that most Python
programmers are people who won't go into the source to read docstrings.
While I agree
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com wrote:
The first time a method is called the bridge looks for an Objective-C selector
with the same name and adds that to the class dictionary. This works fine for
normal
method lookups, by overriding __getattribute__, but
On 19 September 2013 14:27, Donald Stufft don...@stufft.io wrote:
Major changes:
* Removal of the option to fetch pip from PyPI in order not to modify the
trust model of the Python installers
* Consequently rename the model from ``getpip`` to ``extractpip``
If extractpip (I agree, I don't
On 10 September 2013 13:24, Paul Moore p.f.mo...@gmail.com wrote:
On 10 September 2013 13:00, Nick Coghlan ncogh...@gmail.com wrote:
Is this just syntactic sugar for recursive lookup of a transformed version
in __missing__? Or a way of supplying a custom key function to a
dictionary
On 10 September 2013 13:00, Nick Coghlan ncogh...@gmail.com wrote:
Is this just syntactic sugar for recursive lookup of a transformed version
in __missing__? Or a way of supplying a custom key function to a
dictionary?
Not quite, because the dict should preserve the originally entered key.
On 10 September 2013 19:31, Antoine Pitrou solip...@pitrou.net wrote:
I think it would be a flaw to have this detail implementation-defined.
This would be like saying that it is implementation-defined which
of A,B,C is returned from A and B and C if all are true.
Ok, it seems everyone (except
On 10 September 2013 20:59, MRAB pyt...@mrabarnett.plus.com wrote:
try:
del d[k]
finally:
d[k] = v
That would raise a KeyError is the key was missing. A better way is:
d.pop(k, None)
Sorry, I was thinking of try...except: pass. But pop is indeed better.
Teach me to code stuff on
On 8 September 2013 20:19, Steven D'Aprano st...@pearwood.info wrote:
[...]
Is this satisfactory or do I need to go into more detail?
It describes only 7 functions, and yet you state there are 11. I'd
suggest you add a 1-line summary of each function, something like:
mean - calculate the
On 6 September 2013 13:21, Tim Golden m...@timgolden.me.uk wrote:
True, but then you're into determining a temporary name somewhere on the
same volume if possible and avoiding collisions etc. Again, I don't
think this is something we need to be doing by default in core Python.
Agreed.
There
On 6 September 2013 14:16, Richard Oudkerk shibt...@gmail.com wrote:
On 06/09/2013 1:55pm, Paul Moore wrote:
... If you rename the
file to anywhere but the same directory, you potentially have
permission issues.
Using the root directory avoids permission issues -- users always have write
On 27 August 2013 23:17, Guido van Rossum gu...@python.org wrote:
Thanks for your tiresome work
I'm guessing you meant tireless here :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 26 August 2013 17:40, Eli Bendersky eli...@gmail.com wrote:
Yes, exactly :-) Incremental, though, seems to support the conjecture
that it's the input. Which is true, but, since XMLParser is also
incremental in this sense, slightly confusing.
As a data point, until you explained the
On 12 August 2013 20:22, Brett Cannon br...@python.org wrote:
At the PyCon CA sprint someone discovered the formatter module had
somewhat low code coverage. We discovered this is because it's tested by
test_sundry, i.e. it's tested by importing it and that's it.
We then realized that it
On 30 July 2013 18:24, Martin v. Löwis mar...@v.loewis.de wrote:
Personally, I don't know how to do this so someone else would have to -
It seems that this was settled as fine as-is; if you ever wanted to
allow this to be specifically enabled, you'd have to do three things
Thanks, Martin -
On 28 July 2013 00:30, Steve Dower steve.do...@microsoft.com wrote:
Another issue to consider is that the modification to PATHEXT can't be
undone when Python is uninstalled, unless each installation adds another
.PY and each uninstall removes only one (so my PATHEXT would look like
On 28 July 2013 00:30, Steve Dower steve.do...@microsoft.com wrote:
And if you change the association after the fact, you're presumably just
as capable
of changing PATHEXT.
Not if the association is changed by another installer (presumably with
the user's explicit permission). It would be
On 23 July 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote:
On 23 July 2013 17:11, Martin v. Löwis mar...@v.loewis.de wrote:
Am 15.07.13 10:26, schrieb Paul Moore:
Does anyone have any objections to this? I could try to write a patch,
but I know next to nothing about building MSIs, so
On 27 July 2013 21:14, Steve Dower steve.do...@microsoft.com wrote:
Any chance of this being made optional when installing? It provides no
benefit for people who prefer to associate scripts with an editor and may
be a source of confusion/complaints.
Personally, I don't know how to do this
On 26 July 2013 08:50, Antoine Pitrou solip...@pitrou.net wrote:
(For those that haven't seen it, RhodeCode seems broadly comparable to
BitBucket feature wise, but because of the way it is licensed, the
source code is freely available to all, and running your own instance
is
On 23 July 2013 23:45, Victor Stinner victor.stin...@gmail.com wrote:
Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
*handles*, as indicated in its name. On Windows, file *descriptors*
are never inherited (are always closed) in child processes. I don't
think that it is
On 24 July 2013 10:12, Bohuslav Kabrda bkab...@redhat.com wrote:
- What should user get after using yum install python?
There are basically few ways of coping with this:
1) Just keep doing what we do, eventually far in the future drop python
package and never provide it again (= go on only
On 23 July 2013 17:11, Martin v. Löwis mar...@v.loewis.de wrote:
Am 15.07.13 10:26, schrieb Paul Moore:
Does anyone have any objections to this? I could try to write a patch,
but I know next to nothing about building MSIs, so if any of the
installer experts could help that would
On 15 July 2013 07:01, Raymond Hettinger raymond.hettin...@gmail.comwrote:
I would love to have PLY in the standard library.
It would open up a whole new world to some users
and be the basis for tool generation for others.
+1. Parser generators are useful tools - parsers are right on the
With the addition of the Python launcher (PEP 397), Python scripts on
Windows are executable in much the same way as on Unix. However, out of
the box it is still not quite possible to use Python scripts. This is
because the .py extension is not registered with Windows in the PATHEXT
environment
On 15 July 2013 09:40, Nick Coghlan ncogh...@gmail.com wrote:
Sounds good to me - in the long run it may allow us to drop the Windows
exe wrappers when installing scripts on Windows.
That's my motivation. In particular removing pip's exe wrappers to ease
some of the issues being flagged on
On 5 June 2013 02:32, Guido van Rossum gu...@python.org wrote:
Łukasz,
Congratulations! I've accepted PEP 443. I've already marked it as
Accepted in the repo. I've also applied some very minor edits in order
to make the text flow a little better in a few places. I think this is
a great PEP
On 3 June 2013 21:05, Chris Angelico ros...@gmail.com wrote:
+1 for having the default be safe, but this will have to be very
loudly announced (when migrating from 3.3 to 3.4, TLS connections
will cease to work if blah blah).
+1 on the default being safe, certainly. But with the proviso that
On 3 June 2013 22:46, Donald Stufft don...@stufft.io wrote:
Also, we should consider the issue for application users. Suppose I'm
using a Python application that downloads something from the web. I upgrade
to 3.4, and the app stops working because of a will cease to work case.
As an end user,
On 23 May 2013 15:58, Łukasz Langa luk...@langa.pl wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
The dispatch type is currently specified as a decorator
On 23 May 2013 17:00, Walter Dörwald wal...@livinglogic.de wrote:
Should it be possible to register multiple types for the generic function
with one register() call, i.e. should:
@fun.register(int, float)
def _(arg, verbose=False):
...
be allowed as a synonym for
On 5 May 2013 18:10, Paul Moore p.f.mo...@gmail.com wrote:
On 4 May 2013 16:42, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've taken a quick look at it, but I probably won't be able to make any
changes until the near the end of the coming week. Feel free to have a go;
OK, I have a patch
On 6 May 2013 20:46, Steve Dower steve.do...@microsoft.com wrote:
To summarise the bug, when PowerShell invokes a command based on an
extension in PATHEXT, only the first three characters of the extension are
used to determine the associated program. I tested this by creating a file
test.txta
On 4 May 2013 16:42, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've taken a quick look at it, but I probably won't be able to make any
changes until the near the end of the coming week. Feel free to have a go;
OK, I have a patch against the standalone pylauncher repo at
OK, I thought I'd take a look. I have never particularly needed enums in
real life, so I'm reading the PEP from the POV of a naive user who is just
thinking hey, neat, Python got enums, let's see how they work. I have
been skimming the discussions and my head has been exploding with the
On 5 May 2013 18:49, Guido van Rossum gu...@python.org wrote:
Summary - good job, I like the PEP a lot. But Python's enums are very
unlike
those of other languages, and I suspect that's going to be more of an
issue
than you'd hope...
We're pretty confident that we're doing about the
On 4 May 2013 07:48, Nick Coghlan ncogh...@gmail.com wrote:
We don't need examples of arbitrary data file extentions, we need
examples of 4 letter extensions that are known to work correctly when
placed on PATHEXT, including when called from PowerShell. In the
absence of confirmation that
On 4 May 2013 15:20, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
This will mean that scripts written with #!/usr/bin/env python will
behave the same on Unix and Windows in the presence of activated
virtualenvs.
Overall I think it's the right
On 2 April 2013 01:47, Daniel Holth dho...@gmail.com wrote:
This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP Applications”
and “Windowed Python ZIP Applications”, and providing some simple
tooling to manage the
While reviewing the behaviour of Vinay's distil installer tool (see
distutils-sig for details, but it's not relevant here) I have found what I
think is a flaw in the behaviour of the py.exe launcher for Windows.
To recap for people unfamiliar with the launcher, it emulates #! line
interpretation
Before I raise a bug for this, can someone confirm if I've simply missed
something? I don't see any way, either in the docs or in the helpstrings
from the codecs, of listing the codecs that have been registered.
FWIW, I picked this up when I was looking at writing a simple encoding
converter, and
On 30 April 2013 10:42, M.-A. Lemburg m...@egenix.com wrote:
It would be possible to get a list of registered codec search functions,
but there's no API to ask the search functions for a list of supported
codecs.
OK, so there's no way to determine in advance what values of enc will work
in
On 22 April 2013 12:39, Calvin Spealman ironfro...@gmail.com wrote:
if two lines is cumbersome, you're in for a cumbersome life a programmer.
One of which is essentially Python's equivalent of a declaration...
Paul
___
Python-Dev mailing list
On 12 April 2013 09:39, Antoine Pitrou solip...@pitrou.net wrote:
Ok, I've taken a look at the code. Right now lower() is used for two
purposes:
1. comparisons (__eq__ and __ne__)
2. globbing and matching
While (1) could be dropped, for (2) I think we want glob(*.py) to find
SETUP.PY
On 28 March 2013 13:42, Brett Cannon br...@python.org wrote:
importer, as I wanted to try a proof of concept importer based on the
new importlib stuff (which is intended to make writing custom
importers easier), and I really struggled to get something working.
Struggling how? With the finder?
On 28 March 2013 16:08, Brett Cannon br...@python.org wrote:
You only need SourceLoader since you are dealing with Python source. You
don't need FileLoader since you are not reading from disk but an in-memory
zipfile.
You should be implementing get_data, get_filename, and path_stats for
On 27 March 2013 21:19, Bradley M. Froehle brad.froe...@gmail.com wrote:
I implemented just such a path hook zipimporter plus the magic required
for C extensions --- as a challenge to myself to learn more about the Python
import mechanisms.
See https://github.com/bfroehle/pydzipimport.
On 23 March 2013 01:08, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
I don't understand what this is saying - can someone clarify the
reason behind this statement? What is different about a
non-system-wide installation that causes this issue (I assume
On 23 March 2013 12:55, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Mar 2013 12:57:02 +
Richard Oudkerk shibt...@gmail.com wrote:
On 23/03/2013 10:06am, Paul Moore wrote:
One example of a non-system-wide installation is a source build of Python.
PEP 405 venvs created from
On 21 March 2013 06:54, Devin Jeanpierre jeanpierr...@gmail.com wrote:
On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy tjre...@udel.edu wrote:
I think being frozen in the late 1990s is better than being frozen in the
early 1980s, like Command Prompt is. In fact, I think we should 'deprecate'
the
On 21 March 2013 10:32, Terry Reedy tjre...@udel.edu wrote:
On 3/21/2013 5:27 AM, Paul Moore wrote:
Can I suggest that debates about the capability of Windows command
line programming are off-topic here?
I respectfully disagree, unless you say that the whole thread is off topic
PEP 405 has this note:
On Windows, it is necessary to also copy or symlink DLLs and pyd files
from compiled stdlib modules into the env, because if the venv is
created from a non-system-wide Python installation, Windows won't be
able to find the Python installation's copies of those files when
On 27 February 2013 23:18, Armin Rigo ar...@tunes.org wrote:
from cffi import FFI
ffi = FFI()
ffi.cdef(
int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
)
lib = ffi.dlopen(USER32.DLL)
lib.MessageBox(ffi.NULL, Hello, world!, Title, 0)
Yeah, that's loads better
On 28 February 2013 09:06, Armin Rigo ar...@tunes.org wrote:
And I think
that even on 64-bit Windows, passing 0 as a NULL pointer is buggy,
because it will pass a 32-bit 0. (It may be that it doesn't actually
make a difference and works anyway, but I'm not sure.) Similarly, a
function that
On 27 February 2013 11:53, Maciej Fijalkowski fij...@gmail.com wrote:
I think it means you can't use the ABI version and specify the calling
convention. It's a reasonable bug report (the calling convention on
API version works though)
That would be a deal-breaker for my use case of quick
27 February 2013 18:24, Paul Moore p.f.mo...@gmail.com wrote:
On 27 February 2013 11:53, Maciej Fijalkowski fij...@gmail.com wrote:
I think it means you can't use the ABI version and specify the calling
convention. It's a reasonable bug report (the calling convention on
API version works
On 27 February 2013 19:08, Armin Rigo ar...@tunes.org wrote:
That's not correct: you can't indeed give the calling convention, but
it is not needed for the common case. What is not supported is only
Python-defined callbacks using the Windows-specific convention --- as
documented, there is a
On 27 February 2013 19:26, Paul Moore p.f.mo...@gmail.com wrote:
On 27 February 2013 19:08, Armin Rigo ar...@tunes.org wrote:
That's not correct: you can't indeed give the calling convention, but
it is not needed for the common case. What is not supported is only
Python-defined callbacks
On 26 February 2013 16:34, Eli Bendersky eli...@gmail.com wrote:
I'm cautiously +0.5 because I'd really like to see a strong comparison case
being made vs. ctypes. I've used ctypes many times and it was easy and
effortless (well, except the segfaults when wrong argument types are
declared :-).
On 26 February 2013 18:34, Maciej Fijalkowski fij...@gmail.com wrote:
One point which I *think* is correct, but which I don't see noted
anywhere. Am I right that cffi needs a C compiler involved in the
process, at least somewhere? If that's the case, then it is not a
suitable option for at
On 20 February 2013 04:07, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2013 09:37 PM, Paul Moore wrote:
On 20 February 2013 00:54, Fred Drake f...@fdrake.net wrote:
I'd posit that anything successful will no longer need to be added
On Tuesday, 19 February 2013, M.-A. Lemburg wrote:
The only tool in wide spread use that understands part of the 1.2 data
is setuptools/distribute, but it can only understand the Requires-Dist
field of that version of the spec (only because the 1.1 Requires field was
deprecated) and
On 19 February 2013 13:59, Nick Coghlan ncogh...@gmail.com wrote:
It's OK if people don't want to read the detailed rationale provided
for each of the major changes as part of the PEP, or if they want to
dispute a particular piece of that rationale. But merely going it's
too complicated! or
On 19 February 2013 20:36, Donald Stufft donald.stu...@gmail.com wrote:
2. There is currently no code that I am aware of that implements this
spec. I don't believe distlib does (yet - give Vinay 5 minutes and who
knows? :-)), pkg_resources as I said implements a different format,
and
On 20 February 2013 00:54, Fred Drake f...@fdrake.net wrote:
I'd posit that anything successful will no longer need to be added to
the standard library, to boot. Packaging hasn't done well there.
distlib may be the exception, though. Packaging tools are somewhat
unique because of the chicken
On 3 February 2013 11:27, Antoine Pitrou solip...@pitrou.net wrote:
I don't expect anything I want to do to be particularly controversial,
but I think it's worth trying to get it right (even if it delays wheel
support in pip for a few more weeks).
Will wheel be implemented in distutils?
On 3 February 2013 14:41, Daniel Holth dho...@gmail.com wrote:
The neat thing about wheel is that you can install them without having the
software used to build them. So we might try to provide a very simple wheel
installer script with Python that did not even depend on DistUtils. You
would be
On 12 December 2012 00:58, Nick Coghlan ncogh...@gmail.com wrote:
I'd prefer a more aggressive name for this like tzdata_override. My
rationale is that *nix users need to thoroughly aware that if they install
this package, they will stop benefiting from the automatic tz database
updates
On 12 December 2012 16:11, Brian Curtin br...@python.org wrote:
I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
update the info. This is what Java itself is doing anyway.
What would that do in an
On 11 December 2012 15:39, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Should the windows installer include the data package?
--
It has been suggested that the Windows installer should include the data
package. This would mean that an explicit
On 10 December 2012 16:35, Toshio Kuratomi a.bad...@gmail.com wrote:
I have no problems with Obsoletes, Conflicts, Requires, and Provides types
of fields are marked informational. In fact, there are many cases where
packages are overzealous in their use of Requires right now that cause
On 14 November 2012 12:04, Daniel Holth dho...@gmail.com wrote:
That has been tried already (setuptools, distribute, distutils2). Instead,
try bento (http://cournape.github.com/Bento/).
Hilariously everyone I've showed it to is immediately put off by the
indentation based syntax (who would
On 13 November 2012 10:26, M.-A. Lemburg m...@egenix.com wrote:
I agree with Martin. If the point is to to protect against cryptography
that is not used, then not using the de-facto standard in signing
open source distribution files, which today is PGP/GPG, misses that
point :-)
I agree as
On 27 October 2012 21:58, mar...@v.loewis.de wrote:
Zitat von Tim Delaney timothy.c.dela...@gmail.com:
To be clear - I'm *not* suggesting Cython become part of the required
build
toolchain. But *if* the Cython-compiled extensions prove to be
significantly faster I'm thinking maybe it
On 26 October 2012 08:54, Ronald Oussoren ronaldousso...@mac.com wrote:
It's nice and small. The encoder is just
base64.urlsafe_b64encode(digest).rstrip('=')
But is the size difference really important? The wheel file itself is
compressed, and the additional
amount of space needed on
On 22 October 2012 21:35, Daniel Holth dho...@gmail.com wrote:
On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth dho...@gmail.com wrote:
On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
The FAQ has this weird statement:
“This specification does not have an
On 3 October 2012 16:13, Larry Hastings la...@hastings.org wrote:
On 10/03/2012 04:55 PM, Nick Coghlan wrote:
Regardless of when the first alpha happens, I'll be promoting the hell
out of it, begging for feedback on any of these changes that are
available by then (which should be quite a few,
On 3 October 2012 17:34, R. David Murray rdmur...@bitdance.com wrote:
There *were* bug reports during the alpha phase. A number of regressions
were caught. Also, there were more alpha-phase bug reports than
I remember getting for 3.2. I remember thinking, wow, cool, we're
actually getting
On 29 September 2012 10:17, Stefan Krah ste...@bytereef.org wrote:
Tim Delaney timothy.c.dela...@gmail.com wrote:
If those numbers are similar in other benchmarks, would it be accurate and/or
reasonable to include a statement along the lines of:
comparable to float performance - usually no
On 29 September 2012 14:24, Eli Bendersky eli...@gmail.com wrote:
On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl ge...@python.org wrote:
On behalf of the Python development team, I'm delighted to announce the
Python 3.3.0 final release.
Yay :)
Agreed - this is a really nice release, thanks
On 14 September 2012 16:12, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I have set up a BitBucket repo called distlib, at
https://bitbucket.org/vinay.sajip/distlib/
This has the following bits of distutils2 / packaging, updated to run on 2.x
and
3.x with a single codebase, and including
On 16 September 2012 23:26, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I think all that's needed (at the same level of abstraction) is a method
write_installed_files(iterable_of_absolute_file_paths) which writes the file.
This code is already in the
On 14 September 2012 17:30, Daniel Holth dho...@gmail.com wrote:
we strongly recommend it be named as README.* and be
utf-8 encoded text.
I'd very strongly recommend that the encoding should be mandated. I'm
happy with UTF-8 (although I expect a lot of accidental latin-1
files, particularly
On 13 September 2012 12:32, Tarek Ziadé ta...@ziade.org wrote:
Here's my proposal - actually it's Nick's proposal but I want to make sure
we're on the same
page wrt steps, and I think that addresses Antoine concerns
1. create a new package, called pkglib (or whatever), located at hg
On 28 June 2012 11:36, Benoît Bryon ben...@marmelune.net wrote:
Also, I don't see what's so important about using
your company's name as a top-level namespace. You don't need it for
conflict avoidance: you can just as well use distinctive project names.
Using company's name as top-level
On 27 June 2012 12:34, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 27 Jun 2012 21:19:57 +1000
Nick Coghlan ncogh...@gmail.com wrote:
I thought the PEP actually covered it pretty well:
- if you don't want to worry about name conflicts for every module, pick
*one* short top level
On 27 June 2012 13:20, Paul Moore p.f.mo...@gmail.com wrote:
I agree. I only skimmed the PEP, but even on a skimming, I got the
impression that it was promoting the use of namespaces for ownership,
in a Java-like way. The part Nick quoted is substantially more
reasonable (assuming that's
On 22 June 2012 06:05, Nick Coghlan ncogh...@gmail.com wrote:
distutils really only plays at the SRPM level - there is no defined OS
neutral RPM equivalent. That's why I brought up the bdist_simple
discussion earlier in the thread - if we can agree on a standard
bdist_simple format, then we
On 22 June 2012 11:28, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote:
And I'm saying that would encourage a culture that's very dangerous from a
security perspective. Even if many uses binaries, it is important to
encourage a culture where it is always trivial (well, as trivial as we
On 22 June 2012 13:39, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Paul Moore writes:
End users should not need packaging tools on their machines.
I think
On 22 June 2012 13:09, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
Signed binaries may be a solution. My experience with signed binaries
has not been exactly positive, but it's an option. Presumably PyPI
would be the trusted authority? Would PyPI
Can I take a step back and make a somewhat different point.
Developer requirements are very relevant, sure. But the most important
requirements are those of the end user. The person who simply wants to
*use* a distribution, couldn't care less how it was built, whether it
uses setuptools, or
On 20 June 2012 10:12, Antoine Pitrou solip...@pitrou.net wrote:
I think the whole idea that distutils should be frozen and improvements
should only go in distutils2 has been misled. Had distutils been
improved instead, many of those enhancements would already have been
available in 3.2 (and
901 - 1000 of 1788 matches
Mail list logo
