Re: [Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]
On Mon, Dec 1, 2014 at 12:37 PM, Jim J. Jewett wrote: > I think even the proponents concede that git isn't better enough > to justify a switch in repositories. There are also many who find the Bitbucket tools more usable than the Github tools. I'm not aware of any functional differences (though I don't often use Github myself), but the Bitbucket UIs have a much cleaner feel to them. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 553: Built-in debug()
On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote: > Environmental variables tend to be a pain on Windows and nigh unusable by > beginners. Leaving that aside, I see these problems with trying to use one > for IDLE's *current* debugger. > > pdb is universal, in the sense of working with any python run with actual or > simulated stdin and stdout. IDLE's idb is specific to working with IDLE. So > one could not set an EV to 'idlelib.idb.start' and leave it while switching > between IDLE and console. Would it work for IDLE to set the environment variable for the child process? The user certainly should not need to be involved in that. That doesn't address the issue of setting up the communications channel before breakpoint() is called, but allows the breakpointhook that gets used to work with whatever has been arranged. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: snapshots and releases coming up in the next several days
On Wed, Sep 13, 2017 at 12:35 PM, Ned Deily wrote: > Lots of releases coming up soon! There's a "Python Release Schedule" calendar on Google Calendar that used to be maintained, but that appears to have been dropped, though I found it useful. Is there any sort of calendar feed available with this schedule that's currently maintained? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iso8601 parsing
On Wed, Oct 25, 2017 at 10:37 PM, Wes Turner wrote: > What would you call the str argument? Does it accept strptime args or only > ISO8601? There'd be no reason to accept a format. That wouldn't make sense. A .fromiso(s:str) should only accept an ISO 8601 string, though I'd advocate tolerating both space and "T". > Would all of that string parsing logic be a performance regression > from the current constructor? Does it accept None or empty string? It's an alternate constructor, so should not impact the existing constructor (though it could employ the existing constructor to get work done). It should not accept anything but a valid ISO 8601 string. > Should the date time constructor support nanos= (just like time_ns())? No. It should support exactly up to 6 decimal digits to populate the microsecond field. > ENH: Add nanosecond support to the time and datetime constructors This should be left for a separate change, if we determine it should be implemented for the datetime and timedelta types. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista wrote: > I was reading PEP 257 and it says that all public methods from a class > (including __init__) should have a docstring. > > Why __init__? > > It's behaviour is well defined (inits the instance), and the > initialization parameters should be described in the class' docstring > itself, right? __init__ is not always the only constructor for a class; each constructor's arguments should be documented as part of the constructor. The class docstring should provide summary information for the class as a whole. I can also imagine cases where the __init__ isn't considered public, though I suspect that's exceedingly rare in practice. (Can't think of a case I've actually run across like that.) > Should we remove "__init__" (the class method, *not* the package file) > as to require docstrings in the PEP? I don't think so. The advice seems sound to me. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote:
> - a single os.fspath() with an allow_bytes parameter
> (mostly True in os and os.path, mostly False everywhere
> else)
-0
> - a str-only os.fspathname() and a str/bytes os.fspath()
+1 on using separate functions.
> I'm partial to the first choice as it is simplicity itself to know when
> looking at it if bytes might be coming back by the presence or absence of a
> second argument to the call; otherwise one has to keep straight in one's
> head which is str-only and which might allow bytes (I'm not very good at
> keeping similar sounding functions separate -- what's the difference between
> shutil.copy and shutil.copy2? I have to look it up every time).
I do the same, but... this is one of those cases where a caller will
usually be passing a constant directly. If passed as a positional
argument, it'll just be confusing ("what's True?" is my usual reaction
to a Boolean positional argument). If passed as a keyword argument
with a descriptive name, it'll be longer than I'd like to see:
path_str = os.fspath(path, allow_bytes=True)
Names like os.fspath() and os.fssyspath() seem good to me.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
On Wed, Apr 13, 2016 at 12:27 PM, Paul Moore wrote: > -1 on fssyspath - the "system" representation is bytes on POSIX, but > not on Windows. Let's be explicit and go with fsbytespath(). Depends on the semantics; if we're expecting it to return str-or-bytes, os.fssyspath() seems fine. If only returning bytes (not sure that ever makes sense on Windows, since I don't use Windows), then I'd be happy with os.fsbytespath(). -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pathlib - current status of discussions
On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: > > try: > callme = path.__fspath__ > except AttributeError: > pass > else: > path = callme() +1 for this variant; I really don't like masking errors inside the __fspath__ implementation. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding NewType() to PEP 484
On Sun, May 29, 2016 at 4:53 PM, Guido van Rossum wrote:
> I am currently in favor of Distinct Type [Alias].
I actually like distinguished type better:
A = typing.distinguish("A", int)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Negative timedelta strings
On Fri, Mar 28, 2014 at 5:19 PM, Greg Ewing wrote: > ISO 8601 doesn't seem to define a representation for > negative durations, though, so it wouldn't solve the > original problem. Aside from the horribleness of the ISO 8601 notation for a duration, it's best not to confuse the notions of duration and delta. Notionally, a delta contains more information than a duration. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote: > While it seems ConfigParser doesn't do any escaping as all, I'm > thinking it should at least raise some exception when such a value is > trying to be set. > > I'd expect writing something and then reading it back via the same > configparser to *always* result in the same data, as long as writing > worked without error. > > Thoughts? Should I submit a bug report? I believe you should, if only to provide a place to record why no change gets made. Had ConfigParser been more careful from the beginning, that would have been really good. At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote: > I leave it to someone to carefully read the doc, but a brief glance > indicates "There are nearly as many INI format variants as there are > applications using it. configparser goes a long way to provide support for > the largest sensible set of INI styles available." So I wonder whether the > thought-to-be-buggy behavior is actually buggy with respect to *all* the > supported styles or just some of them. Given that most variants are completely undocumented, answering this is sufficiently intractable for me to call it intractable. We've also run into compatibility issues because some applications treated the "parser" object as an in-memory configuration database throughout the process lifetime, updating values with non-string values of various sorts. Given the age of the module, the existing number of uses of undocumented accidents of implementation is very large. Fixing "bugs" like this has an excellent track record of uncovering these uses, so... we've grown a bit wary. It's not unheard of for projects to fork their own copies of configparser because of changes to the stdlib version. (No, I haven't done a census of such cases, but I do know of at least one in a popular package.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman wrote: > Perhaps an enhancement request then: a way to provide a regex that keys > must match, with an exception raised when a key doesn't. That way the > safety belt could be used when desired. You can subclass the parser class you're using and override the ``optionxform`` method to perform the checks you want for option names. I don't know if current versions provide a similar hook to validate section names; providing *that* would be an excellent enhancement. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote: > I think that a line beginning with "#spam" is ambiguous, it isn't clear > if it is intended as a comment "spam" or a key starting with #, so by > the Zen, configparser should refuse to guess. Seriously? Perhaps the second paragraph here could be strengthened a little: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure But that seems clear to me. Lines starting with the comment prefix are comments. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano wrote:
> But the entry in question wasn't a line, it was a key=value pair in a
> dict. Here's that line again:
>
> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>
> or it could have been:
>
> cp['DEFAULT'][';foo'] = 'bar'
>
> Either way, if there's no way to escape comment characters, I think it
> is a bug that you can insert illegal keys into the cp object in the
> first place.
Fair enough.
I'm not trying to argue that it isn't a bug, but that risk of breaking
currently-working applications with data they consider acceptable is
high. Many use configparser for input only, and make no use of the
serialization feature. Those applications can be broken by adding a
constraint on the data that's allowed, regardless of what we think of
their keys.
Chaning this in an application for which it's safe (easier to know at
the application level) is easy enough:
import configparser
import re
class ProtectionistParser(configparser.RawConfigParser):
_rx = re.compile(r"[a-z]([-a-z]*[a-z])?$") # or whatever
makes sense for your app
def optionxform(self, opt):
if self._rx.match(opt) is None:
raise ValueError("don't like this: %r" % opt)
return opt
Maybe the "strict" mode is considered new enough that this isn't as
significant a risk, and it could be allowed when that's enabled; I'm
sure Łukasz will have a carefully considered opinion (and I'll defer
to him in the end).
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?
On Thu, Jul 5, 2018 at 9:02 PM Alexander Belopolsky wrote: > What happened to the "consenting adults" philosophy? Just anecdotally, I've run into a number of professionals recently who've come out of Java environments who really dislike the "consenting adults" approach. While they value much that Python offers them, they still really want some of the hand-holding languages like Java give them. What exactly they identify as "compelling" varies based on their past experiences, but it's not completely without reason. The reasoning is often tied to providing APIs "less-experienced" programmers can use without breaking things. Some of these programmers at least claim to understand that bigger risks come from not dealing with API boundaries that check input values carefully, or that don't deal cleanly with exception propagation; that seems to be fairly difficult for many. The idiomatic models I've found most desirable in Python are not as widely valued as I'd hope. It's hard to say what that tells us, and I think we'd want more quantifiable evidence before drawing conclusions. The prevalence of expectation that an API constrains the mechanics of how it is used is something I find surprising. While I can suspect that it's misguided, I keep running into situations where code needs to be maintained by people who just aren't as familiar with the idioms I'm accustomed to, so... considering the issue has value. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime.timedelta total_microseconds
On Tue, Feb 26, 2019 at 10:20 PM Terry Reedy wrote: > To me, total_x implies that there is a summation of multiple timedeltas, > and there is not. Do you believe this is a particularly dominant perception? I don't, but specific backgrounds probably play into this heavily. I'd expect to total a bunch of timedelta values using sum([d0, d1, ..., dn]). Given we already have total_seconds(), it's not clear avoiding additional methods is meaningful, unless we're going to deprecate total_seconds(). Not really a win in my book. I'd rather stick with the existing pattern, if anything even needs to be done. I'm quite happy to use d.total_seconds() * 100 as long as the accuracy is sufficient. Someone with more floating point expertise can probably think of a reason that's not good enough, in which case... an appropriate method wouldn't be poorly named as total_microseconds. > I might prefer one method, .convert? with an argument > specifying the conversion unit, 'microseconds', 'seconds', ... . Using a function that takes a units indicator (as d.convert(units='microseconds')) seems like a poor choice; most uses will hard-code exactly one value for the units, rather than passing in a variable. Getting a more specific name seems reasonable. > It is also not obvious is answer is rounded to nearest second > or not. No, but that's a problem we have now with total_seconds(). Best handled by maintaining the pattern and documenting the behavior. While fractional microseconds aren't a thing with timedelta values now (and probably not in any near future), it seems good to keep these floats so things stay consistent if we can ever get better clocks. :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays
On Mon, Jul 8, 2019 at 3:59 PM Barry Warsaw wrote: > I’m not a super active moderator, but I do have to say that it’s so much > easier to clear the queue now that the list is on Mailman 3. That said, > it still takes active participation in order to review held messages. ... > Volunteers are welcome! :) Does Mailman 3 notify moderators when candidates for moderation enter the queue? If so, I'll step up to help out. MM3 knows me as "[email protected]". -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/VRQSQMPOH5NTJN46N6W5CAPTAGPHWSF3/
[Python-Dev] Re: Remove formatter module
On Tue, Nov 24, 2020 at 10:59 AM Stéfane Fermigier wrote: > I've run a quick search on GitHub and the only meaningful reference I could > find is the Grail browser (which had its last release, AFAICT, in 1999). > > http://grail.sourceforge.net/ Oh, the memories! Looking at docs, I can vaguely recall using the API, but... it definitely doesn't belong in the stdlib. -Fred -- Fred L. Drake, Jr. "There is nothing more uncommon than common sense." --Frank Lloyd Wright ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2IBAT5XCAX4WZ4RHUR22IZ5A2B3U7KPW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
On Thu, Feb 25, 2021 at 5:35 AM Wes Turner wrote: > The challenge with version conflicts is often less that you need to go > update the constraints (which has little to do with sysadmin'ing, TBH) and > more that you have insufficient *integration tests* and you're relying upon > something else running the per-package tears. > Sometimes, auto-correct really does understand! Your point is right on target, and really can't be understated. -Fred -- Fred L. Drake, Jr. "There is nothing more uncommon than common sense." --Frank Lloyd Wright ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KZX2DOJBICJWJ3Y6EMUA2F675TMSYSPV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?
On Wed, Apr 14, 2021 at 4:19 PM Paul Moore wrote: > PS I see Barry plans on rejecting the PEP, which I think is probably > the right decision, given the way this thread has developed. > Barry makes good plans. Putting the version into the sources is a bit of an anti-pattern. IMO. -Fred -- Fred L. Drake, Jr. "There is nothing more uncommon than common sense." --Frank Lloyd Wright ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HPAU4PMIGPPG2R7RJIL6QDS2WYACBCRV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?
On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett wrote: > I don't have a deep answer, but I do think __version__ should be specified > (or at least mentioned) at > https://docs.python.org/3/reference/datamodel.html Given the intent to reject PEP 394, I can't imagine any good would come of that. Drop a __version__ in your modules if you find it valuable, but otherwise, there's nothing to do here. -Fred -- Fred L. Drake, Jr. "There is nothing more uncommon than common sense." --Frank Lloyd Wright ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/3QHBGEIDDJEHZP5Q2I3ZGQ73FZ6SPDAQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)
I found this article about what's up with FreeNode:
https://arstechnica.com/gadgets/2021/05/freenode-irc-has-been-taken-over-by-the-crown-prince-of-korea/
-Fred
On Wed, May 26, 2021 at 11:48 AM Guido van Rossum wrote:
> Could someone provide more background on this event? Are there wars going
> on between different IRC providers?!?
>
> On Wed, May 26, 2021 at 6:43 AM Victor Stinner
> wrote:
>
>> By the way, #python also moved to Libera Chat:
>> https://www.pound-python.org/
>>
>> The PSF (Group Contact) owns #python*, #pypa* and #psf* channels on
>> Libera.
>>
>> I updated the IRC informations in the Python devguide.
>>
>> I'm still migrating #python-dev-notifs bots to Libera.
>>
>> Victor
>>
>> On Wed, May 26, 2021 at 12:46 PM Victor Stinner
>> wrote:
>> >
>> > Hi,
>> >
>> > The #python-dev IRC channel moves from Freenode to Libera Chat:
>> > https://libera.chat/ I'm connected as vstinner, see you there ;-) Join
>> > the channel if you would like to talk about the development of Python
>> > itself (the VM, bytecode, stdlib, etc.)!
>> >
>> > Moreover, bots notifications (GitHub, buildbots, bugs.python.org) are
>> > now in a new dedicated channel #python-dev-notifs so humans can talk
>> > together again! :-) The migration is on-going, right now some
>> > notifications are still on Freenode.
>> >
>> > --
>> >
>> > Yesterday evening, Freenode admins decided to take the control of the
>> > #python-fr channel on Freenode (which now redirects to a new
>> > ##python-fr channel), only because the channel topic contained
>> > "libera"! The french Python association ("AFPy") managing #python-fr
>> > lost control and decided to migrate to Libera Chat (libera.chat).
>> > Announcement in french:
>> > https://www.afpy.org/posts/actualites/1622023152
>> >
>> > I'm disappointed by how the events are going. At least, it motivated
>> > me to move bots notfications ;-)
>> >
>> > Victor
>> > --
>> > Night gathers, and now my watch begins. It shall not end until my death.
>>
>>
>>
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> Python-Dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/R3YTKHTUPMF3W5UH2YP4ACXHBXTQLQUE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0
On Sun, Feb 17, 2013 at 1:45 PM, Daniel Holth wrote: > Not likely to matter for a while as the current md v1 tools don't understand > this new obsolescence rule :-) Using a separate file for post-obsolescence-rule metadata versions would allow coexistance, which would likely improve adoption. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0
On Sun, Feb 17, 2013 at 4:21 PM, Nick Coghlan wrote: > As Daniel pointed out, easy_install and pip also don't follow this rule yet, > so it won't really have any impact if we never get to metadata 3.0. Actually, my point was that using a separate filename for version 2.0 would allow provision of both 1.x and 2.0, so version 2.0 metadata can be deployed as tool support becomes available, instead of having to wait until 1.x tools are replaced. Once tools are following the new rule about version compatibility, there's less worry about this (at least on my part). -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft wrote: > Let's not add anything to the stdlib till it has real world usage. Doing > otherwise is putting the cart before the horse. 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. I'd rather see a successful packaging story develop than bundle it into the standard library. The later just isn't that interesting any more. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python
On Wed, Feb 20, 2013 at 5:45 PM, R. David Murray wrote: > (Wikipedia says: "Programs for reading documents may not be required to > read the external subset.", which would seem to confirm that.) Validating parsers are required to read the external subset; this doesn't apply to the parsers distributed for Python today. Even when loading external resources, I don't think there's anything in the XML specification that says how they have to be loaded, or how to deal with an error when they are (and refusing to load because of resource limits is reasonably just another error with respect to the parser). While I'd hate to make XML processing more painful than it often is, there's no injunction not to be reasonable. Security concerns and resource limits are cross-cutting concerns, so it's not wrong to provide safe defaults. Doing so *will* be backward incompatible, and I'm not sure there's a good way to gauge the extent of the breakage. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python
On Wed, Feb 20, 2013 at 7:38 PM, Nick Coghlan wrote: > Christian's suggested approach sounds sane to me: Definitely. A strong +1 from me, FWIW these days. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Wed, Feb 27, 2013 at 8:30 AM, Antoine Pitrou wrote: > I don't think extra-strong typing of constants is really useful in > practice; it smells a bit like private methods to me. I think checking that a value comes from a particular enum *is* a degree of hand-holding. For libraries or frameworks whose users aren't expected to know them exhaustively, making reasonable checks of parameters can substantially reduce the number of ways it can be used incorrectly. Outside performance critical code, this is a win. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?
On Thu, Mar 14, 2013 at 9:33 PM, Terry Reedy wrote: > Is the code change an all-version bugfix or a default-only enhancement? > I can see it both ways, but a decision is required to act. This is actually backward-incompatible, so should not be considered a simple bugfix. If determined to be desirable, it should not be applied to any version before 3.4. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Structural cleanups to the main CPython repo
On Tue, May 28, 2013 at 9:07 AM, Nick Coghlan wrote: > Unfortunately, I don't know any other short word for "things with main > functions that we ship to end users" :) We used to call such things "programs", but that term may no longer be in popular parlance. :-) Or is it just too long? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 modernisation
On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou wrote: > Something magic about 99? I'm guessing it's short enough you can say you tried, but long enough to annoy traditionalists anyway. I'm annoyed already. :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Our failure at handling GSoC students
On Tue, Aug 6, 2013 at 3:51 PM, Antoine Pitrou wrote: > I definitely agree, but this is part of our failure too. I'd say this is strictly our failure, not the students'. This isn't really a new problem, I don't think, though the shape of this collection of patches makes it obvious. I haven't been active with GSoC the last couple of years, but if we don't have any sort of guide for mentors, we probably should, and this is an issue that should be mentioned as one that requires discussion with the students. That's our role as a community and as mentors when it comes to GSoC. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 4:29 PM, Oleg Broytman wrote: > I have seen exactly 0 (zero) sites that support Persona. Can you > point me? We have an internal app that uses Persona, but we did that mostly to play with it. I've not run across any sites that use Persona in the wild, either. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practice for documentation for std lib
On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wrote: > It would be great if the docstring contained a link to the online > documentation. The docstring itself, or the presentation generated by help() ? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practice for documentation for std lib
On Mon, Sep 23, 2013 at 3:01 PM, Terry Reedy wrote:
> 'Return' versus 'Returns', exact uppercase word match, is a little over 3 to
> 1. I am sure I have seen 'Return' and similiar directive forms ('Print',
> 'Store', 'Compare', etc) recommended as current doc style, as prefered by
> the current doc crew.
I don't know about the current crew, but this dates way back to
Guido's initial LaTeX documentation, and Guido's strong preference on
this.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Smoothing the transition from Python 2 to 3
On Wed, Jun 8, 2016 at 5:33 PM, Ryan Gonzalez wrote: > What about something like "unpythonic" or similar? Or perhaps... antipythy? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Smoothing the transition from Python 2 to 3
On Thu, Jun 9, 2016 at 6:16 PM, Ethan Furman wrote: > That's awfully close to antipathy [1], my path module on PyPI. Good point. Increasing confusion would not help. > Besides, I liked the suggestion from the -ideas list: Python 2therescue. ;) Nice; I like that too. :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?
On Mon, Oct 10, 2016 at 4:17 AM, Larry Hastings wrote: > Given that the weakref doesn't have a reference to the object--merely a weak > reference, different thing--whose reference is it borrowing? As others have said, it doesn't really matter who's reference it was; just that there was another at the time it was returned. Clearly it can't be considered valid once additional Python code might be run. > FWIW, yes, this is playing merry hell with the Gilectomy. If there are two > threads, and one calls PyWeakref_GetObject(obj), and there's only one > reference to obj, and the other thread blows it away... now what? It's my > contention that this API is simply untenable under the Gilectomy, and that > it needs to change to returning a new (strong) reference. +1 for this change. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote: > While I agree with the general suggestion of deprecating distutils as a > publicly-visible module (in favour of encouraging users to rely on > setuptools), it seems to me that the argument of facilitating the > development of third-party build systems is what already encouraged the > official policy of not adding features to distutils (more than 10 > years ago, IIRC). My recollection is that we decided to stop changing distutils because too many 3rd party extensions (often included directly in the packages that needed them) using undocumented parts fo distutils directly (since there was no substantially documented API for distutils in the beginning). Every time anything changed, something was broken for somebody. Since that affected not only the developers hooking in to distutils but the users of their packages, touching distutils caused too much pain. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6SO72DJWM7F77FFWGMIHCD2IWRMD5JAP/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] "setuptools has divided the Python community"
On Mar 27, 2009, at 3:24 PM, [email protected] wrote: I thought one of the arguments for zip files was a performance increase (reduced stat(2) calls, etc). I may misremember though. You're memory is working fine, but I don't think the way eggs are used accomplishes that. The measurements that supported that performance assertion were made by putting the standard library in a single ZIP, and using that. I don't have measurements handy, but I recall being told by someone who did that using a *lot* of separate ZIP files wasn't as effective. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote: One of the motivations for deprecating this (and for using this specific example) was that Matthias Klose, the Python packager for Debian, said he never uses bdist_rpm. Given that Debian doesn't use RPMs, isn't that expected? I'm actually in favor of removing the bdist_* from the standard library, and allowing 3rd-party tools to implement whatever they need for the distros. But I don't think what you're presenting there supports it. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Mar 27, 2009, at 5:22 PM, M.-A. Lemburg wrote: Perhaps someone should start working on a tool called "FryingPan" to create "Omelettes", ie. all eggs squashed into a single ZIP file... ;-) I've certainly suggested such a tool in various conversations, but it usually comes down to not wanting to build a separate ZIP for (potentially) every script. In practice, I suspect it's a lot better than this. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
On Mar 28, 2009, at 9:33 AM, Eric Smith wrote: To be concrete, I think distutils should support (among other things): - entry points for plugins - entry points as used for producing console and windowed "scripts" This strikes me as a nice-to-have, but: 1. I don't think they're two distinct features. 2. I'm not convinced these should go in distutils. I'd rather see an API to get resources from a package, and conventions can be developed among tool developers on how to store that information in a named resource. - dependency declarations for other python packages This is the most important requirement here, I think. As part of this, I'd want to be able to say things like "PIL, with JPEG and PNG support compiled in." - dependency declarations for non-python packages This would be very nice to have, but I suspect this is actually much more difficult than Python package dependencies, especially with any pretense at cross-platform expressions of dependencies. PJE pointed out "A library that targets Python 2.4 and 2.5 and uses wsgiref, sqlite, ctypes, or ElementTree, for example, may have different dependencies depending on the version it is being installed in." Is that something we want to support? Even simple cases present issues with regard to this. For example, I work on a project that relies on the uuid module, so we declare a dependency on Ka-Ping Ye's uuid module (since we're using Python 2.4). How should we write that in a version-agnostic way if we want to use the standard library version of that module with newer Pythons? -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote: - - docs - - i18n / locales On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote: Unfortunately, the distutils don't currently have a way to specify these. There actually is a way to identify documentation files via setup.cfg, but I don't know if the RPM packagers (or others) use that information. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote: is the presence of None values in sys.modules considered an implementation detail? If not, it should be documented what the None values mean to the interpreter. As I recall, they're an optimization. But since sys.modules is itself documented, and many applications actually use it, I think it's worth explaining that the None values can reasonably be expected, and what they indicate. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Aug 19, 2009, at 6:01 PM, Peter Moody wrote: just to double check, it's fine for IPNetwork to remain hashable if set_prefix() actually returned a new object, correct? The name would be confusing, though. Perhaps using_prefix() would be more clear. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?
On Aug 31, 2009, at 4:47 PM, Antoine Pitrou wrote: I am really not opinionated on this one. I was just pointing out that choosing a non-obvious solution generally requires good reasons to do so. The marshal format compaction sounds like premature optimization, since nobody seems to have formulated such a request. Every time I've been bitten by the wrong co_filename values (usually from tracebacks), changing the way marshal creates code objects to use a values passed in has been the thing that made the most sense to me. The feature request that's involved here, getting correct co_filename values, can be implemented in different ways, sure. This particular change produces the least impact in the because it *doesn't* change the mutability of code objects. I for one appreciate that, mostly because I'm simply wary of making code objects mutable in this way having unexpected side effects in some library. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc/maintainers.rst
On Thu, Sep 17, 2009 at 10:38, Georg Brandl wrote: So the plan would be to consolidate these into another set of rst docs, having them in the repo, editable by every committer, as well as published somewhere on python.org (devdocs.python.org or somesuch). On Sep 17, 2009, at 1:56 PM, Brett Cannon wrote: dev.python.org would be nice to have, from which we can simply redirect www.python.org/dev/ to dev.python.org. www.python.org/dev/ can then get cleaned up be made simpler to navigate and more obvious for how people can get started. Many years ago, we decided to add docs.python.org with the "current" version of the documentation, so people would be able to find the docs more easily. Since then, we've had problems with keeping docs.python.org and www.python.org/doc/ in sync, and with different styles being applied to the sites. One of the reasons www.python.org/doc/ was considered less discoverable was the about of only-sometimes-interesting information there; docs.python.org contains only "current" docs (for some vague notion of current and only, given that dev builds and both Python 2 and Python 3 versions). Some claimed that having "docs" at the front of the URL helped, though I don't recall why. I don't know whether users consider the docs more discoverable than they used to; if anyone can provide information about that (now sure what indicator would make even sense), that might be informative. The overload problem is one we *don't* have for developer documentation; the difficulty is in discovering what exists at all. +1 on moving the developer docs to subversion +0 on exposing them online -0 on adding another domain name -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw wrote: > Maybe. I haven't been following this entire thread, but I don't see much > point in making it easy to go from getopt to argparse. I'm with you on this; specific getopt uses are more likely to be switched to opt/argparse than to shift gradually via hybrid APIs. > The two are so > different that I think you're either going to jump all in or not. Maybe > that's just me though as I really don't see much use for getopt any more > (even for throwaway scripts). Heh. I never liked getopt anyway. :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
On Mon, Oct 5, 2009 at 4:58 AM, Fredrik Lundh wrote: > Oh, it was just yet another Zope developer behaving like an ass. Why > am I not surprised? Actually, most of us Zope developers prefer sdist packages, not eggs. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum wrote: > User ratings and comments are the > future for "app store" style sites such as PyPI Interestingly, I consider sites like PyPI as developer resources rather than the more end-user-centric "App Store" sites. While I don't consider it bad to provide support for commenting and rating, I find it much less valuable than for end-user-centric sites. But then, some may find me a bit retro. :-/ -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan wrote: > When it comes to comments and recommendations for selecting software > packages, developers *are* the end users :) Yes, most certainly. But developers as consumers are very different from application users as consumers, which is what I was getting at. The convenience interfaces for commenting on a library are far less valuable for developers, IMO, since developers are expected to better understand how their context impacts their perception. Useful feedback from a developer just doesn't fit will into the giant-pile-of-comments UIs conventional for non-developers. If I'm wrong about that, then I'm saddened by the state of the profession. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python byte-compiled and optimized code
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar wrote: > 1) Is the byte-compiled .pyc file and optimized .pyo file > platform-independent?(including python versions 3.x) Yes. > If yes, is it > guaranteed to stay that way in future? Yes. > 2) If the the generation of .pyc file fails (say, due to write protected > area), does that stop the script execution? No. It only means the bytecode won't be cached. > 3) Is it possible to redirect the location of the generation of .pyc files > to other than that of the corresponding .py files? I think some support for this has been developed, at least experimentally, but I'm not sure if it's part of a stable release or not. It's more likely in Python 3.x, which I'm significantly less familiar with. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Top-posting on this list
On Sat, Oct 10, 2009 at 8:02 PM, Greg Ewing wrote: > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), and makes things harder to read as well. That's > just senseless. Most importantly, insufficient trimming makes many of us start to ignore threads we'd otherwise want to read more carefully or participate in, because the tedium of wading through all the quotes to make sure we catch all the content. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can 3.1 still be built without complex?
On Thu, Oct 15, 2009 at 11:06 AM, Antoine Pitrou wrote: > We have trouble staying > compatible with lots of build options (see how --without-threads is little > exercised). I don't know if folks deploying on embedded platforms are using these options (directly or indirectly), but expect that's the primary audience. Hopefully somebody who's doing that can tell us if they're using the defines, and what versions of Python they're currently using. Then we can determine whether the should be supported. If they should be, there should be buildbot's set up for relevant configurations. Otherwise removal is best. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Refactoring installation schemes
On Wed, Nov 4, 2009 at 5:16 PM, David Lyon wrote: > I would even go so far as to use the python 3 as a carrot for > the new work. The packaging story is in such bad shape that it needs the work regardless, and keeping it to Python 3 would significantly reduce the set of potential volunteers. > imho The biggest and best thing that you could do for python > packaging is to do a refactor of the .EGG format. > > What I mean here, is *take* the egg, and run with it. Modernise > it and revamp it into a platform independent thing. People > 'get' the egg idea, they just hate the current implementation. There's certainly work on that, but... is it that people hate the format? Or working with setuptools? The fact that there's more than one egg format doesn't help, so you may be right. > Call it the new Tarek egg... The tegg? ;-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE as default Python editor
On Wed, Nov 11, 2009 at 12:59 PM, Echo wrote: > We just need a PyEmacs. Written in python, extensible in elist and > python. Nice and simple ;-D I'd even give up the elisp support if I could have Python in my Emacs. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson wrote: > Could you mention what specific changes are causing problems? I'd be glad to head Lennart confirm this, but I suspect this is primarily changes in exception messages; 2.7 in many places provides better messages. I found some of this with a few of the Zope-related packages that I tried testing under pre-2.7 versions of Python. If this is what Lennart's referring to, I consider this to be a problem with the tests. Unfortunately, doctest lends itself to having tests that check these sorts of implementation details, and the Zope community has certainly succumbed to that temptation. Evolving the tests to avoid depending on these sorts of implementation details is reasonable, IMO, and cuold even be considered a bugfix by the Zope community. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
On Wed, Dec 9, 2009 at 12:23 PM, Lennart Regebro wrote: > You remember which one? Sorry, that was several months back. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Sun, Dec 27, 2009 at 8:28 PM, Arfrever Frehtes Taifersar Arahesis wrote: > 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, > <4'. Maybe. MRAB wrote: > Requires-Python: 3 ~ 4 Ugh. -1 -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improved Traceback Module
The traceback support from the zc.twist package might be interesting as well; not sure how well that's isolated from the rest of the package though: http://pypi.python.org/pypi/zc.twist/ -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 7:41 AM, anatoly techtonik wrote: > It will still require workarounds and bridges to make API in user > scripts convenient, i.e. I'm not entirely sure what you intended the "It" to refer to here. My take on this is that bundling a version of pytz in the standard library will simply generate more ways to deal with timezones. Using pytz as an external dependency is easy and provides a high level of update support. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 26, 2010 at 3:59 PM, Lennart Regebro wrote: > I'm worrying that adding such a > thing to stdlib will do so in an unfinished state, and we'll just en > up with yet another state of semi-brokenness. I valid worry, and compelling. As I've alluded to before, leaving it out and allowing applications to just use pytz (or whatever else) is entirely reasonable. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Release blocker: urllib2 issue 7540
Regarding: http://bugs.python.org/issue7540 The change made in response to this issue report breaks existing uses of Python 2.6.4. The mechanize library frequently re-initializes the data in the request without re-using the request. This worked fine in the past, and does not trigger the problem reported without the request being re-used. Applications (including tests) that use mechanize now break with this TypeError. This includes much (if not all) of the Zope community, which uses mechanize via zope.testbrowser. The proper response to this issue for Python 2.6 is to make no code changes (though a documentation enhancement may be in order). This change should be reverted from all branches. Python 2.6.5 should be blocked until this is done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Desired changes to Hg emails to python-checkins
On Thu, Mar 4, 2010 at 3:20 PM, Brett Cannon wrote: > 1) I miss not having the affected files listed in the subject line. > 2) The To field is set to [email protected] which gets rejected as an invalid > email address if you reply. Would be better to set it to python-checkins so > that the habitual reply to a checkin won't get rejected. I concur on both points. You are not alone. :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Wed, Mar 10, 2010 at 7:46 AM, Nick Coghlan wrote: > All of this discussion about the class names is ignoring the main > benefit of using the string names: Another benefit of strings is that data-driven argparse configuration will usually be slightly simpler. Some of us find things like that useful. :-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl
On Thu, Mar 25, 2010 at 2:16 PM, Larry Hastings wrote: > My understanding is that requiring a recompile is okay This has always been a point of contention. I'm not even sure what the current official position is. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
On Tue, Apr 27, 2010 at 4:38 PM, "Martin v. Löwis" wrote: > Done! Thanks, Martin! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw wrote: > but in fact, the scripts make Resolution optional (it's kind of a pain to make > it required just for Standards Track PEPs - contributions welcome). It will also be a pain to retroactively update older PEPs with the newly-required metadata; leaving it optional (in practice) seems acceptable. It should only apply to newly-resolved PEPs, which is also likely a pain to build into the script. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: > it would still be a good idea to > introduce some of them in minor releases in 2.7. I know, this > deviating from the process, but it could be an option considering that > 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UserDict in 2.7
On Tue, Jun 22, 2010 at 2:21 AM, Raymond Hettinger wrote: > I had thought there was a conscious decision to not change any existing > classes from old-style to new-style. I thought so as well. Changing any class from old-style to new-style risks breaking applications in obscure & mysterious ways. (Yes, we've been bitten by this before; it's a real problem.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] State of json in 2.7
On Tue, Jun 22, 2010 at 12:56 PM, Benjamin Peterson wrote: > Never have externally maintained packages. Seriously! I concur with this. Fortunately, it's not a real problem in this case. There's the (maintained) simplejson package, and the unmaintained json package. And simplejson works with older versions of Python, too, :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UserDict in 2.7
On Tue, Jun 22, 2010 at 7:17 PM, Raymond Hettinger wrote: > Benjamin fixed the UserDict and ABC problem earlier today in r82155. > It is now the same as it was in Py2.6. Thanks, Benjamin! -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
On Thu, Jun 24, 2010 at 4:55 PM, Barry Warsaw wrote: > Which is probably another reason not to use foo.so.X.Y for Python extension > modules. Clearly, foo.so.3.2 is the man page for the foo.so.3 system call. The ABI ident definitely has to be elsewhere. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration readiness
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote: > The two sets of repositories use different conversion tools and rules. > They have nothing in common (different changeset IDs, different > metadata, different branch/clone layout). I'd love to see a more detailed description of this, including why someone new to Mercurial would choose one over the other. This information really belongs in www.python.org/dev/ rather than only in the mailing list. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] query: docstring formatting in python distutils code
On Wed, Jul 7, 2010 at 2:27 PM, Georg Brandl wrote: > I know, and this is what I originally intended for Sphinx. However, the calls > for automatic doc generation are very loud, and it's understandable that most > project can't afford writing their documentation twice. The ability to provide extended content beyond what's provided in the docstring using the auto* constructs may make it feasible to start avoiding some of those DRY violations for Python's standard library; I'm enjoying those for another project. I hope we don't end up in a position where we can't use the auto* constructs in the Python documentation. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] query: docstring formatting in python distutils code
On Wed, Jul 7, 2010 at 4:58 PM, Georg Brandl wrote: > Let's say we were okay with giving up single-source docs, It's not clear that this is a goal. > one potential > problem is that autodoc needs to import the modules in question, which > can become a problem, on one hand for platform-specific modules, on the > other because the Python building the docs is not necessarily the Python > that is documented. This is an excellent point. I'm less worried about the platform-specific issues, since we can decide that those in particular can't use the auto* support, but the need to build docs for different versions/implementations of Python is an interesting use case. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] query: docstring formatting in python distutils code
On Thu, Jul 8, 2010 at 5:21 PM, Georg Brandl wrote: > Problem is, in the case of help() we have no way of knowing whether the > given __doc__ string is supposed to be (mini)reST. Of course, reverting > to showing the plain content on parsing errors is one possibility, but > I can still imagine instances where something is successfully interpreted > as reST, but intended to be read and understood verbatim by the author. The docstring processing PEP provides for this: http://www.python.org/dev/peps/pep-0258/#id42 -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] query: docstring formatting in python distutils code
On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky wrote: > I am against mark-up in doc-strings, but this problem can be easily > solved by placing a magic character at __doc__[0] to indicate that the > rest is (mini)reST. Or __docformat__ can be set appropriately. See: http://www.python.org/dev/peps/pep-0258/#id42 -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] query: docstring formatting in python distutils code
On Fri, Jul 9, 2010 at 2:51 AM, Georg Brandl wrote: > Yes, but[tm] it is not always easy to find the correct module to look for > __docformat__ when given an object. True. That PEP was written before decorators were common, in particular. That's changed the landscape in substantial ways. It may be that at this point, there's no good way to deal with formatting in docstrings at anything other than the project level, where policies for the code can be set if desired. Ideally, the format of a docstring would be captured along with the docstring itself. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can ftp url start with file:// ?
On Fri, Jul 9, 2010 at 2:04 PM, Bill Janssen wrote: > I'd suggest that > HTTP is a better (more likely to succeed) default choice in this century. FTP access also more often reflected the actual file hierarchy of the machine, so trying that path as a system path is more likely to work that I'd expect to see for HTTP. Really, I'd expect any non-local file: URLs to be kicked back to the application, and let it decide to re-write if it wants to. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Fri, Jul 9, 2010 at 3:35 PM, MRAB wrote: > I concentrated my efforts on the matching speed because regexes tend to > be compiled only once, and are cached anyway, so I don't think it's as > important. I think most here will agree with that, but it might be good to keep in mind that the sre implementation has already made that trade-off once. I don't remember what the compilation slowdown was at the time, but I'd be surprised if Google can't find it, given sufficient fu. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can ftp url start with file:// ?
On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran wrote: > I see the reason. But I doubt if this is a reliable approach. Also > when the scheme begins with file:// it should not be confused with > ftp, so I think, that portion of code in urllib which work that way > should be removed. I'm not trying to defend the current behavior of defaulting to FTP as a good thing; it's definitely surprising. I am trying to rationalize it so I can be sure I understand why it might have been done to start with. My own preference is to kick out any non-local references with an exception that can be detected (possibly derived from ValueError) so that applications that want rewrite (hopefully with user agreement!) can do so. (Checking for non-local file: URLs on input might be better, of course.) -Fred -- Fred L. Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman wrote: > Doesn't absolute import help? Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord wrote: > I'm sure Brett will love this idea, but if it was impossible to reimport the > script being executed as __main__ with a different name it would solve these > problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
I wrote: > Indeed! And I'd be quite content with such a solution, since I > consider scripts and modules to be distinct. On Mon, Jul 12, 2010 at 5:59 PM, Antoine Pitrou wrote: > Except that modules can often be executed as scripts... Rest assured, I'm well aware of the history, and don't seriously expect the situation to change. Not all of us consider modules and scripts synonymous; I've considered them distinct for quite some time. The problem with a script being importable as a module, masking the intended module, is simply a symptom of this misfeature that has been identified as commonly biting newcomers. Glyph Lefkowitz wrote: > but ... isn't the whole point of 'python -m' to make scripts and modules > _not_ be distinct? That was never how I understood the intention. The point was to make modules that could be used as scripts easier to use as scripts. There have been proposals for main-functions in modules that would be invoked as a default entry point; those make -m more attractive. I'd be more likely to use -m if those were part of the package. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan wrote: > Making sure both __main__ and the corresponding importable name refers > to the same module object seems reasonable. One detail that may not have been obvious when I described the persistent object problem; when class references are pickled, they should be for the "real" name of the module, not __main__. Loading the file as __main__ and adding an alias in sys.modules simply isn't sufficient. Existing instances could be loaded, but new instances would cause references to the classes defined in __main__. To some degree, this sort of problem can be easily handled using a "don't do that" approach, and this isn't likely to burn someone just learning Python on the first day. (Well, maybe in the afternoon, once they've got the basics down.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan wrote: > Fred's point about the practice of changing __name__ in the main > module corrupting generated pickles is one I hadn't thought of before > though. Not sure about changing __name__ anywhere... I don't do that. When an "application" is defined more by operations on persistent data then what top-level script is run, we (Zope Corp.) often have many different __main__s that run with the same database; there's generally not any point in thinking of the script as a module at all; the fact that it's available as sys.modules['__main__'] isn't important. We generally avoid the problem by applying the don't-do-that rule. Our actual scripts are always generated, and don't live in module-space. Understanding what not to do is an important aspect of teaching, though. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mkdir -p in python
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano wrote: > It refers to the guideline that you shouldn't have a single function > with two (or more) different behaviour and an argument that does > nothing but select between them. In particular, when that argument is almost never given a variable value, but is specified using a constant at the call site. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mkdir -p in python
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam wrote:
> It doesn't fall under the single constant rule if done this way.
If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.
The guideline has little to do with the type of the value, but the
number of possible values ("small") and whether they're normally given
as constants in the code.
If there's more than one, and combinations then to vary, then keeping
them as args makes sense.
Also, if we don't know what we want the functionality to be, as you
suggest, then worry about that is premature. :-) Let's decide on the
required functionality first.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] :program: markup in .rst documentation
Switching to "python -m" is generally good where it applies (as in this case). The original intent for :option: and :program: were in their use as references rather than in sample command lines. Georg should be the final arbiter, but I'd be in favor of ``...`` for command lines. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker status
On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen wrote: > Is the tracker OK now? It's working for me. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #2651 - KeyError does not round trip strings
2010/8/4 Łukasz Langa : > 1. The patch makes KeyError behave analogically to IOError so that the first > arg is now a message and the second is the actual key. I agree with Antoine; there's no point to this. > 2. Some people suggest adding e.key to KeyError. I like the idea but in my > opinion currently it is not implementable in a reliable way. This is interesting and useful. I'd be really happy to see e.key be present if the key is known (because it was specifically provided to the constructor: KeyError(key=...)), or not present if the key isn't known. (The idea is much less interesting if code can't distinguish between the key-is-known and the key-not-known cases.) The runtime and standard library should be adjusted to provide the key whenever possible, of course. Though I doubt this would break anything, we've lived without this long enough that the it doesn't represent a sufficient failing that the moratorium should be broken. It can wait. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #2651 - KeyError does not round trip strings
On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan wrote: > and use a default message of > "'Key not found: %r' % key" if the key argument is supplied without an > explicit message I suspect you meant a default message of 'Key not found: %r' % (key,) since `key` might be a 1-tuple. :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #2651 - KeyError does not round trip strings
2010/8/4 Łukasz Langa : > Shall we do an e.index for IndexErrors as well? I don't recall stumbling over that need, but the parallel makes it tempting. I expect is should be a separate patch, though. Antoine's right about using keyword args from C, though. I'd expect a new helper function that handles this specific case, since it's likely to be common. Whether it used a keyword are or just performed a setattr after the exception is created doesn't really matter. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 9, 2010 at 8:56 AM, Nick Coghlan wrote: > Longer term, the buildbot setup should be modified to run the cleanup > step even if the compilation step fails. Running "make clean" after checkout/update should work as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Wed, Aug 11, 2010 at 11:22 AM, Éric Araujo wrote: > Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use > .pythonx.y or .python/x.y is a subissue to discuss after general agreement). +0.5 I'd like to see a more complete proposal, including: - what to do with Windows, Mac OS X - backward compatibility considered (seems straightforward, but seemings are often wrong) - cross-platform API to locate these files (should be able to address the b/w compat issues) Seems like a good idea to have a "registry" of files known to be placed there (a wiki page should be sufficient; if the API is used to create the directory, it can drop in a README.txt pointing to that page). -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Summary Lists on Issue Tracker
On Wed, Aug 11, 2010 at 11:28 AM, Mark Dickinson wrote: > Well, perhaps I'm the only person bothered by this (and when I say > 'bothered', it's not exactly keeping me up at nights). I'm not going to lose sleep over it either, but the logo-link is generally considered very non-discoverable. Keeping a query in the sidebar doesn't seem a huge price to pay. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Wed, Aug 11, 2010 at 10:58 PM, Éric Araujo wrote: > Considering the FHS or the XDG Base > Directory specifications, there is a precedent in distinguishing user > config (edited by the user through a text editor or settings graphical > window), program data (state) and cache (files for speedups that can > safely be deleted). Right. The wording in that PEP is ambiguous at best, but the inclusion of the Python version number in the listed path suggests that this is for automatically managed stat (like those trashy *.pth files some tools worry about), not for something the human user is going to manipulate directly. That PEP is particularly concerned with package management per user (a dodgy proposition at best), so everything there is about package management tool support, not user-manipulated configuration data. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
