I meant to exclude md5 and sha1, e.g. hash functions with known problems.
SHA224 would be a weird choice but it wouldn't personally offend me
otherwise. It would be fun to see how many wheel handlers support
non-sha256 hash functions.
On Mon, Mar 29, 2021 at 9:56 PM Theallredman via Python-Dev <
p
Sorry that this is a bit off-topic. cffi would be a user of any new C API.
I've tried to make sure ABI3 is supported in setuptools and wheel, with
varying success. Apparently virtualenvs and Windows have problems. I'm
excited about the possibility of a better C API and possibly ABI.
__
It can be done exactly as passing a void* when registering a C callback,
and getting it passed back to your callback function.
https://cffi.readthedocs.io/en/latest/ref.html#ffi-new-handle-ffi-from-handle
https://bitbucket.org/dholth/kivyjoy/src/aaeab79b2891782209a1219cd65a4d9716cea669/kivyjoy/con
Was it regular cffi or cffi's embedding API, which is used a bit
differently than regular cffi, that "seems to only solve a fraction of the
problem"? Was just playing around with the embedding API and was impressed.
In Python:
@ffi.def_extern()
def uwsgi_pyexample_init():
print("init called")
re
On Tue, Sep 10, 2019 at 8:38 PM Matt Billenstein wrote:
> On Tue, Sep 10, 2019 at 10:42:52AM -0400, Daniel Holth wrote:
> > I stopped using Python 3 after learning about str(bytes) by finding it
> in my
> > corrupted database. Ever since then I've been anxious abou
On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka
wrote:
> 22.06.19 01:08, Daniel Holth пише:
> > Thanks. I think I might like an option to disable str(bytes) without
> > disabling str != bytes. Unless the second operation would also corrupt
> > output.
> >
> > Ca
The answer bytes == str is just False. That doesn't put b'' in your
database by accident. It could be useful to separate the two kinds of
warnings.
On Fri, Jun 21, 2019, 18:57 Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> On 22.06.2019 1:08, Daniel Ho
, 2019, 13:05 Christian Heimes wrote:
> On 18/06/2019 18.32, Daniel Holth wrote:
> > set([u"foo", b"foo]) will error because the two kinds of string have the
> > same hash, and this causes a comparison. Is that correct?
>
> Yes, it will fail with -bb, because it turn
set([u"foo", b"foo]) will error because the two kinds of string have the
same hash, and this causes a comparison. Is that correct?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mai
This sounds exactly like what people used to do with eggs. You could have
multiple versions of a package on the path as eggs and then require a
version at runtime. The approach has problems. Ruby also abandoned a
strategy where random app code depends on package management code at
runtime.
One bet
Easily solved with the totally evil ninja mode pattern of module
initialization. It has yet to catch on.
def ninja():
global exported
import os
def exported():
# do something
ninja()
del ninja
On Mon, Jan 9, 2017 at 1:13 PM Sven R. Kunze wrote:
> Interesting to see that othe
A nice recent blog post about paths encoding in a media player.
http://beets.io/blog/paths.html . It's not merely the porting that makes it
hard.
On Mon, Aug 29, 2016, 19:32 Victor Stinner wrote:
> 2016-08-24 17:44 GMT+02:00 Steve Dower :
> > I know Nick and Victor like the idea of a -X flag (or
#1 sounds like a great idea. I suppose surrogatepass solves approximately
the same problem of Rust's WTF-8, which is a way to round-trip bad UCS-2?
https://simonsapin.github.io/wtf-8/
#2 sounds like it would leave several problems, since mbcs is not the same
as a normal text encoding, IIUC it depe
You may know that there are approximately 3 pypi maintainers, all
overworked and one paid. It is amazing that it works at all. I don't know
anything about that particular decision though.
On Wed, Jul 13, 2016 at 1:21 PM Dmitry Trofimov <
dmitry.trofi...@jetbrains.com> wrote:
> Hi,
>
> as you prob
I was using Py_LIMITED_API under 3.5 and PY_SSIZE_T_CLEAN was set, this
causes some functions not in the limited api to be used and the resulting
extension segfaults in Linux. Is that right?
Thanks,
Daniel
___
Python-Dev mailing list
Python-Dev@python.o
Yes, not too long ago I installed "every" Python package on Ubuntu, and
Python basically would not start. Perhaps some plugin system was trying to
import everything and caused a segfault in GTK. The "short sys.path" model
of everything installed is importable has its limits.
On Thu, Jul 7, 2016 at
It would be a codec. base64_text in the codecs module. Probably 1 line
different than the existing codec. Very easy to use and maintain. Less
surprising and less error prone for everyone who thinks base64 should
convert between bytes to text. Sounds like an obvious win to me.
On Wed, Jun 15, 2016
In that case could we just add a base64_text() method somewhere? Who would
like to measure whether it would be a win?
On Wed, Jun 15, 2016 at 8:34 AM Steven D'Aprano wrote:
> On Tue, Jun 14, 2016 at 09:40:51PM -0700, Guido van Rossum wrote:
> > I'm officially on vacation, but I was surprised tha
IMO this is more a philosophical problem than a programming problem. base64
has a dual-nature. It is both text and bytes. At least it should fit in a
1-byte-per-character efficient Python 3 unicode string also.
___
Python-Dev mailing list
Python-Dev@pytho
OpenSSL sucks. Python would only have to bundle a reference implementation
of the new hash algorithm(s), and unlike TLS suites they tend to just work.
BLAKE2 is important, since it removes the last objection to replacing MD5 -
speed - that has made it hard for cryptography fans to convince MD5 use
re and what I
should polish to get it in.
Thanks,
Daniel Holth
On Thu, May 19, 2016 at 6:34 AM Christian Heimes
wrote:
> On 2016-05-19 04:30, Nick Coghlan wrote:
> > On 18 May 2016 at 23:20, Daniel Holth wrote:
> >> I would like to take another stab at adding a threadlocal "st
hen how to
access the same value from both Python and CPython code. The structs were
there but it was just hard to understand. Can someone explain it to me?
Thanks,
Daniel Holth
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
On Thu, Apr 23, 2015 at 9:55 AM, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 23 Apr 2015 09:15:44 -0400
> Daniel Holth wrote:
>
> []
>
>> >> Also ask why no one used type specifier, they are possible since
>> >> Python 3.0 ?
>> >> Be
On Thu, Apr 23, 2015 at 5:59 AM, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 23 Apr 2015 10:43:52 +0200
> Wolfgang Langner wrote:
>
> []
>
>> Also ask why no one used type specifier, they are possible since
>> Python 3.0 ?
>> Because it is the wrong way for Python.
>
> That's an example of how pe
On Tue, Apr 21, 2015 at 1:10 PM, Guido van Rossum wrote:
> On Tue, Apr 21, 2015 at 9:17 AM, R. David Murray
> wrote:
>>
>> Please be respectful rather than inflammatory. If you read what I
>> wrote, I did not say that I was going to stop contributing, I
>> specifically talked about that gut reac
7:23, "Alexander Belopolsky" <
> alexander.belopol...@gmail.com> 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
> > > >
That might mostly do what you want, since tox could install any
additional test requirements based on its configuration.
On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky
wrote:
>
> On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth wrote:
>>
>> > Is there a recommended w
On Tue, Feb 24, 2015 at 1:31 PM, Alexander Belopolsky
wrote:
>
> On Tue, Feb 24, 2015 at 11:44 AM, Paul Moore wrote:
>>
>> And if pip won't work, it would be good to
>> know why.
>
>
> Is there a recommended way to invoke pip from setup.py? When I specify
> "tests_require=" and run "python setup
On Sun, Feb 15, 2015 at 1:45 PM, Serhiy Storchaka wrote:
> On 15.02.15 18:21, Thomas Wouters wrote:
>>
>> which requires that extension modules are stored uncompressed (simple)
>> and page-aligned (harder, as the zipfile.ZipFile class doesn't directly
>> support page-aligning anything
>
>
> It is
Go ahead, make my pep.
I will appreciate seeing it happen.
On Feb 15, 2015 8:47 AM, "Nick Coghlan" wrote:
> 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
> >> standard
On Wed, Oct 1, 2014 at 1:59 PM, Mark Shannon wrote:
> Hi,
>
> http://speed.python.org/
> could do with some love.
+1
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
On Thu, Jun 5, 2014 at 11:59 AM, Paul Moore wrote:
> On 5 June 2014 14:15, Nick Coghlan wrote:
>> As I've said before in other contexts, find me Windows, Mac OS X and
>> JVM developers, or educators and scientists that are as concerned by
>> the text model changes as folks that are primarily focu
On Wed, Jun 4, 2014 at 10:12 AM, Steven D'Aprano wrote:
> On Wed, Jun 04, 2014 at 01:14:04PM +, Steve Dower wrote:
>> I'm agree with Daniel. Directly indexing into text suggests an
>> attempted optimization that is likely to be incorrect for a set of
>> strings.
>
> I'm afraid I don't understa
MicroPython is going to be significantly incompatible with Python
anyway. But you should be able to run your mp code on regular Python.
On Wed, Jun 4, 2014 at 9:39 AM, Serhiy Storchaka wrote:
> 04.06.14 04:17, Steven D'Aprano написав(ла):
>
>> Would either of these trade-offs be acceptable while
If we're voting I think representing Unicode internally in micropython
as utf-8 with O(N) indexing is a great idea, partly because I'm not
sure indexing into strings is a good idea - lots of Unicode code
points don't make sense by themselves; see also grapheme clusters. It
would probably work great
Can of worms, opened.
On Jun 4, 2014 7:20 AM, "Chris Angelico" wrote:
> On Wed, Jun 4, 2014 at 9:12 PM, Paul Sokolovsky wrote:
> > An alternative view is that the discussion on the tracker showed Python
> > developers' mind-fixation on implementing something the way CPython does
> > it. And I di
- micropython is designed to run on a machine with 192 kilobytes of
RAM and perhaps a megabyte of FLASH. The controller can execute
read-only code directly from FLASH. There is no dynamic linker in this
environment. (It also has a UNIX port).
- However it does include a full Python parser and REPL,
Fortunately, Unicode provides us with the COMBINING LOW LINE
character, combining the horizontal space-savings of camelCase with
the underscore-indicates-separation properties of _. And it's a valid
Python identifier.
convertx̲mlt̲oj̲son
On Thu, Apr 24, 2014 at 12:25 PM, Chris Angelico wrote:
On Fri, Apr 18, 2014 at 12:55 PM, Paul Moore wrote:
> On 18 April 2014 16:58, Nick Coghlan wrote:
>> As part of thrashing out the respective distribution ecosystem roles
>> of pip and conda (still a work in progress), we're at least converging
>> on the notion that there are actually now *two* ma
On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou wrote:
> Le 15/04/2014 19:09, Daniel Holth a écrit :
>
>> In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+".
>>
>> My feeling has long been that the speed of getting at th
and encourage all optimizers to optimize.
On Tue, Apr 15, 2014 at 12:47 PM, Antoine Pitrou wrote:
> Le 15/04/2014 17:42, Daniel Holth a écrit :
>
>> I find Python's startup time to be very sluggish. I wish it was less
>> than 50 milliseconds (0.05 seconds) including runni
I find Python's startup time to be very sluggish. I wish it was less
than 50 milliseconds (0.05 seconds) including running hg, which is the
common threshold for "instant". On my machine 'python -c ""' takes
about 0.05 seconds but 'python3 -c ""' takes 0.125 seconds. I will be
very happy to see any
IIRC it is no longer the case that ZIP imports (involving only one
file for a lot of modules) are much faster than regular FS imports?
On Tue, Apr 15, 2014 at 10:34 AM, Eric Snow wrote:
> On Tue, Apr 15, 2014 at 1:45 AM, Chris Angelico wrote:
>> Specific use-case that I can see: Mercurial. In a
On Tue, Apr 8, 2014 at 12:08 AM, Nick Coghlan wrote:
>
> On 7 Apr 2014 21:58, "MRAB" wrote:
>>
>> On 2014-04-08 02:45, Guido van Rossum wrote:
>>>
>>> So what? Aren't we allowed to have fun? :-)
>>>
>> Next thing you know, he'll be threatening people with The Comfy Chair!
>
> You may want to take
On Thu, Mar 27, 2014 at 2:53 PM, Guido van Rossum wrote:
> So what's the use case for Python 2/3 compatible code? IMO the main use case
> for the PEP is simply to be able to construct bytes from a combination of a
> template and some input that may include further bytes and numbers. E.g. in
> asyn
I feel not including %s is nuts. Should I write .replace('%b', '%s')?
All I desperately need are APIs that provide enough unicode / str type
safety that I get an exception when mixing them accidentally... in my
own code, dynamic typing is usually a bug. As has been endlessly
discussed, %s for bytes
I love it.
On Tue, Mar 25, 2014 at 6:37 PM, Ethan Furman wrote:
> Okay, I included that last round of comments (from late February).
>
> Barring typos, this should be the final version.
>
> Final comments?
>
> -
> PEP: 46
pypy's transparent proxy feature:
http://pypy.readthedocs.org/en/latest/objspace-proxies.html#transparent-proxies
On Thu, Mar 20, 2014 at 1:56 PM, Larry Hastings wrote:
> On 03/20/2014 12:49 AM, Nick Coghlan wrote:
>
> So long as Graham's willing to go along with it, he doesn't have to to
> be
On Tue, Jan 14, 2014 at 1:52 PM, Guido van Rossum wrote:
> On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker wrote:
>> On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov
>> wrote:
>>>
>>> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.
>>
>>
>> please no -- that's the source of a lot o
On Mon, Jan 13, 2014 at 4:59 PM, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman
> wrote:
>> On 1/13/2014 12:09 PM, Guido van Rossum wrote:
>>
>> Yeah, the %s behavior with a string argument was a messy attempt at
>> compromise. I was hoping to mimick a common use of %
On Mon, Jan 13, 2014 at 3:11 PM, Yury Selivanov wrote:
> On January 13, 2014 at 3:08:43 PM, Daniel Holth (dho...@gmail.com) wrote:
>>
>> I see it now. b"foo%sbar" % b'baz' should also expand to b"foob'foo'bar"
>>
>> Instead of
I see it now. b"foo%sbar" % b'baz' should also expand to b"foob'foo'bar"
Instead of "%b" could "%j" mean "I should have used + or join() here
but was too lazy" and work on str too?
On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy wrote:
> On 1/13/2014 1:40 PM, Brett Cannon wrote:
>
>> > So bytes for
On Mon, Jan 13, 2014 at 12:42 PM, R. David Murray wrote:
> On Mon, 13 Jan 2014 12:41:18 +0100, Antoine Pitrou
> wrote:
>> On Sun, 12 Jan 2014 18:11:47 -0800
>> Guido van Rossum wrote:
>> > On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
>> > > On 01/12/2014 04:47 PM, Guido van Rossum wrot
On Sun, Jan 12, 2014 at 9:18 PM, Guido van Rossum wrote:
> On Sun, Jan 12, 2014 at 6:07 PM, Daniel Holth wrote:
>> Is there a formatting character that means "anything except a unicode
>> string" to prevent accidentally interpolating a Unicode string into a
>&g
On Sun, Jan 12, 2014 at 8:27 PM, Ethan Furman wrote:
> On 01/12/2014 04:47 PM, Guido van Rossum wrote:
>>
>>
>> %s seems the trickiest: I think with a bytes argument it should just
>> insert those bytes (and the padding modifiers should work too), and
>> for other types it should probably work lik
On Sat, Jan 11, 2014 at 4:28 PM, Terry Reedy wrote:
> On 1/11/2014 1:44 PM, Stephen J. Turnbull wrote:
>
>> We already *have* a type in Python 3.3 that provides text
>> manipulations on arrays of 8-bit objects: str (per PEP 393).
>>
>> > BTW: I don't know why so many people keep asking for use c
So the customer you're looking for is the person who cares a lot about
encodings, knows how to do Unicode correctly, and has noticed that
certain valid cases not limited to imperialist simpletons (dealing
with specific common things invented before 1996, dealing with mixed
encodings, doing what Nic
On Wed, Jan 8, 2014 at 2:17 PM, Stefan Behnel wrote:
> Victor Stinner, 06.01.2014 14:24:
>> Abstract
>>
>> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
>> Python 3.5.
>
> Here is a counterproposal. Let someone who needs this feature write a
> library that does byte s
On Tue, Jan 7, 2014 at 10:36 AM, Stephen J. Turnbull wrote:
> Daniel Holth writes:
>
> > Isn't it true that if you have bytes > 127 or surrogate escapes then
> > encoding to latin1 is no longer as fast as memcpy?
>
> Be careful. As phrased, the question makes no
+1
I have always been delighted that it is possible to manipulate binary
data in Python using string operations. It's not just immoral
non-Unicode text processing. A poor man's ASN.1 generator is an
example of a very non-text thing that might be convenient to write
with a few %s fill-in-the-blanks
On Dec 18, 2013 11:54 AM, "Tim Peters" wrote:
> [Daniel Holth]
> > But who could forget njzrs' wasp UAV software line 107, using
> > int=float?
> https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107
>
> I could forget it
But who could forget njzrs' wasp UAV software line 107, using
int=float?
https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107
On Wed, Dec 18, 2013 at 10:49 AM, Guido van Rossum wrote:
> BTW, I bet a lavish dinner at PyCon that it is *only* Zope/ZODB that
> does this.
On Thu, Nov 21, 2013 at 4:12 PM, Paul Moore wrote:
> On 21 November 2013 21:02, Greg Ewing wrote:
>> Is that much different from package authors having to
>> release binaries for different versions of Python,
>> if they want to support older versions?
>>
>> Having multiple binaries for the same x
+1 on unsorted repr(). It makes it obvious that the collection is not sorted.
On Thu, Nov 21, 2013 at 1:10 PM, Christian Heimes wrote:
> Am 21.11.2013 18:57, schrieb Tim Peters:
>> Best to change the failing tests. For example, _they_ can sort the
>> dict keys if they rely on a fixed order. Sor
On Tue, Oct 15, 2013 at 8:02 AM, Steven D'Aprano wrote:
> On Tue, Oct 15, 2013 at 10:20:03AM +0200, Victor Stinner wrote:
>> Both issues are related and should be fixed in the *same* commit.
>> Python should provide an option to encode explicitly filenames to
>> UTF-8. Or maybe better: encode to U
FYI zipfile does do UTF-8
(http://hg.python.org/cpython/file/d7ebe03fa752/Lib/zipfile.py#l368).
Only the non-Unicode encodings might need some help. I like that the
patch is only concerned with decoding. Is it necessary to support
writing non-UTF8 encodings?
On Tue, Oct 15, 2013 at 10:20 AM, Victo
Sounds like you are suggesting we get a raspberry pi. All sorts of dumb
waste shows up when you run code on those.
El oct 8, 2013 4:46 p.m., "Guido van Rossum" escribió:
> Let's agree to disagree then. I see your methodology used all around me
> with often problematic results. Maybe devs should h
On Fri, Sep 27, 2013 at 12:15 PM, R. David Murray wrote:
> On Fri, 27 Sep 2013 15:26:41 +0100, Paul Moore wrote:
>> On 27 September 2013 15:08, Stephen J. Turnbull wrote:
>> >> New users on Windows and Mac OS X. I've heard many more complaints
>> > > from folks running tutorials about the pip b
https://pypi.python.org/pypi/apipkg provides a much more effective way
to denote API than an _
On Wed, Jul 17, 2013 at 12:20 PM, R. David Murray wrote:
> On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy wrote:
>> On 7/16/2013 9:39 AM, R. David Murray wrote:
>> > On Tue, 16 Jul 2013 23:19:21 +1000
cffi makes this kind of constant-grabbing very easy. However this is a
tiny module so no problem with having a C version.
On Thu, Jun 20, 2013 at 11:04 AM, Thomas Wouters wrote:
>
>
>
> On Thu, Jun 20, 2013 at 8:01 AM, Brett Cannon wrote:
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 10:14 AM, Eric V.
On Tue, May 28, 2013 at 2:04 PM, Barry Warsaw wrote:
> On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>
>>Wheel has no mechanism for renaming scripts (or any file) based on the
>>Python version used to install. Instead you would have to build
>>python-version-specific p
On Tue, May 28, 2013 at 1:30 PM, Barry Warsaw wrote:
> On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>
>>You probably already know this, but I'll mention it anyway. This
>>probably matters a lot for nose and pyflakes, but I'd say that for tox
>>it should not, it basically just scripts exec
Everyone seems to like the first half of this simple PEP adding the
extensions. The 3-letter extension for windowed apps can be "pzw"
while the "pyz" extension for console apps stays the same.
The second half, the tool
https://bitbucket.org/dholth/pyzaa/src/tip/pyzaa.py?at=default is less
mature,
As the PEP author I declare we can have 3-letter extensions. It is not
a big deal.
Daniel Holth
On Mon, May 6, 2013 at 4:30 PM, Richard Oudkerk wrote:
> So the bug would just cause .pyzw files to be opened with py instead of pyw?
> Won't this be harmless?
>
> I think the worst
On Thu, Apr 25, 2013 at 10:07 AM, Barry Warsaw wrote:
> On Apr 25, 2013, at 03:34 PM, Lennart Regebro wrote:
>
>>In the case of JSON objects, they are intended for data exchange, and
>>hence in the end need to be byte strings.
>
> Except that they're not.
>
> http://bugs.python.org/issue10976
>
>
y from within a virtualenv when you write
> "/usr/bin/python", so using "/usr/bin/env" instead is actually required.
>
> Stefan
Pushed as Draft PEP 441, tooling prototyped (with less than awesome
CLI) at https://bitbucket.org/dholth/pyzaa or
https://crate.io/packages/pyza
https://docs.google.com/document/d/1MKXgPzhWD5wIUpoSQX7dxmqgTZVO6l9iZZis8dnri78/edit?usp=sharing
PEP: 4XX
Title: Improving Python ZIP Application Support
Author: Daniel Holth
Status: Draft
Type: Standards Track
Python-Version: 3.4
Created: 30 March 2013
Post-History: 30 March 2013, 1
The new "distlib" also provides that feature
On Apr 1, 2013 4:58 PM, "Éric Araujo" wrote:
> Hello,
>
> Le 01/04/2013 16:51, Grigory Petrov a écrit :
> > But what python code is responsible for creation of this bootstrapper
> > executables? I have searched python 2.7.3 source code for some time, b
Yes, it would probably make more sense to split the editor and shell
processes as many Python IDEs do, with IDLE running in CPython and the
user's computation running in the chosen interpreter.
On Sat, Mar 30, 2013 at 8:35 AM, Maciej Fijalkowski wrote:
> On Sat, Mar 30, 2013 at 5:26 AM, Antoine P
Jim Fulton is right that weird failures are a characteristic of zipped
eggs, so one of the #1 requests for setuptools is how to prohibit
zipping from ever happening. This is an important reason why wheel is
billed as an installation format -- fewer users with pitchforks. It's
very cool that it work
I showed IDLE to my 6-year-old on the Raspberry Pi and I'm convinced
it is cool. Gave up on trying to (slowly) install bpython. We were
multiplying large numbers and counting to 325,000 in no time. It might
not be for *me* but I'm not going to teach my daughter a large IDE any
time soon.
__
On Wed, Mar 20, 2013 at 3:54 PM, Barry Warsaw wrote:
> On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:
>
>>I didn't hear any at the sprint here.
>
> JFDI! :)
>
> -Barry
+1 why are we still talking show me the patches
___
Python-Dev mailing list
Py
est_suite:
nose.collector; document the extension; write some tool to actually
parse the metadata and invoke the tests; it may become a core feature
in the next version, or having a monolithic specification may become
less important.
Thanks,
Daniel Holth
>> As a community, we know how important tests are, so I think our tools should
>> reflect that and make it easy for those tests to be expressed. As a selfish
>> side-effect, I want to reduce the amount of guesswork I need to perform in
>> order to know how to run a package's test when I `$vcs clo
On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw wrote:
> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>
>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>>setuptools feature. PEP 426 has an extension mechanism that could do
>>the
On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ wrote:
> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw wrote:
>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>>
$ python -m unittest discover
$ python setup.py test
$ python setup.py nosetests
$ python -m nose test
$ no
On Wed, Feb 27, 2013 at 4:18 AM, Ronald Oussoren wrote:
>
> On 27 Feb, 2013, at 10:06, Maciej Fijalkowski wrote:
>
>> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren
>> wrote:
>>>
>>> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>>>
Hello.
I would like to discuss on the
+1
On Tue, Feb 26, 2013 at 12:14 PM, Maciej Fijalkowski wrote:
> On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky wrote:
> >
> >
> >
> > On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski
> > wrote:
> >>
> >> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky
> wrote:
> >> >
> >> > On Tue, Feb 26,
On Tue, Feb 19, 2013 at 5:10 PM, M.-A. Lemburg wrote:
> On 19.02.2013 23:01, Daniel Holth wrote:
> > On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg wrote:
> >
> >> On 19.02.2013 14:40, Nick Coghlan wrote:
> >>> On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lembur
On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg wrote:
> On 19.02.2013 14:40, Nick Coghlan wrote:
> > On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
> >> * PEP 426 doesn't include any mention of the egg distribution format,
> >> even though it's the most popular distribution format at t
On Tue, Feb 19, 2013 at 3:25 PM, Paul Moore wrote:
> On 19 February 2013 13:40, Nick Coghlan wrote:
> >> If a tools wants to support metadata 2.0, it has to support all
> >> the complicated stuff as well, i.e. handle the requires fields,
> >> the environment markers and version comparisons/sorti
On Tue, Feb 19, 2013 at 11:26 AM, Paul Moore wrote:
> On 19 February 2013 13:59, Nick Coghlan 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.
On Feb 19, 2013 6:57 AM, wrote:
> > I've never seen environment markers being used or supported
> > in the wild.
> >
> > I'm not against modernizing the format, but given that version 1.2
> > has been out for around 8 years now, without much following,
> > I think we need to make the implementati
On Sun, 17 Feb 2013 20:11:23 +1000
Nick Coghlan wrote:
>
> Major changes since the last draft:
>
> 1. Metadata-Version is 2.0 rather than 1.3, and the field now has the
> same major.minor semantics as are defined for wheel versions in PEP
> 427 (i.e. if a tool sees a major version number it doesn'
Version: $Revision$
Last-Modified: 07-Aug-2012
Author: Daniel Holth
BDFL-Delegate: Nick Coghlan
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Jul-2012
Python-Version: 3.4
Post-History: 8-Aug-2012, 18-Oct-2012, 15-Feb-2013
Abstract
This PEP specifies a tagging
On Fri, Feb 15, 2013 at 12:27 PM, Erik Bray wrote:
> On Sun, Feb 3, 2013 at 5:24 PM, Vinay Sajip
> wrote:
> > Éric Araujo netwok.org> writes:
> >
> >> Looks like we agree that a basic tool able to bootstrap the packaging
> >> story is needed :)
> >
> > Agreed. Just because distutils can't easil
On Wed, Feb 13, 2013 at 7:10 AM, Serhiy Storchaka wrote:
> On 13.02.13 10:52, Larry Hastings wrote:
>
>> I've always hated the "".join(array) idiom for "fast" string
>> concatenation--it's ugly and it flies in the face of TOOWTDI. I think
>> everyone should use "x = a + b + c + d" for string conc
He is being self deprecating. Its also true that python dev can't recommend
bento wholesale. That is fine with me.
On Feb 3, 2013 5:36 PM, "Vinay Sajip" wrote:
> Simon Cross gmail.com> writes:
>
> > For the record, all the reasons listed at [1] appear trivial.
>
> In Bento's author's own words -
They can be signed with pypi detached signatures already. It works now
exactly as for sdist.
The innovation was supposed to be in convenience for the signer, in
allowing keys to be trusted per package and for a list of dependencies and
the expected signing keys to be shared easily. Does anyone have
I did think that updating distutils to have basic support for the packaging
PEPs was a decent idea, but then it wound up being more or less rewritten
entirely like I've been cajoled into doing with PEP 426 (Metadata). I don't
know whether distutils(1) can survive the minimum changes required for
wh
1 - 100 of 194 matches
Mail list logo
